RFC1974 日本語訳
1974 PPP Stac LZS Compression Protocol. R. Friend, W. Simpson. August 1996. (Format: TXT=45267 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Friend
Request for Comments: 1974 Stac Electronics
Category: Informational W. Simpson
DayDreamer
August 1996
コメントを求めるワーキンググループR.友人要求をネットワークでつないでください: 1974年のStacエレクトロニクスカテゴリ: 情報のW.シンプソン空想家1996年8月
PPP Stac LZS Compression Protocol
ppp Stac LZS圧縮プロトコル
Status of this Memo
この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.
プロトコル[2]がPPPの上で圧縮プロトコルを交渉して、利用する方法を供給するPPP Compression Controlはリンクを要約しました。
This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets.
このドキュメントはStac LZSデータ圧縮アルゴリズムの使用について説明します、単一であるか複数の圧縮歴史で、PPPを圧縮するとパケットがカプセルに入れられたので。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Licensing ....................................... 2
1.2 Specification of Requirements ................... 3
2. LZS Packets ........................................... 3
2.1 Padding ......................................... 4
2.2 Zero Deletion/Insertion ......................... 4
2.3 Reliability and Sequencing ...................... 4
2.3.1 Reset-Request and Reset-Ack Packet Formats....... 5
2.4 Data Expansion .................................. 6
2.5 Packet Format ................................... 6
2.5.1 PPP Protocol .................................... 7
2.5.2 History Number .................................. 7
2.5.3 Check Value ..................................... 7
2.5.3.1 LCB ........................................ 7
2.5.3.2 CRC ........................................ 7
2.5.3.3 Sequence Number ............................ 8
2.5.3.3.1 History Synchronization with Sequence
Numbers Example ...................... 9
1. 序論… 2 1.1 認可します。 2 1.2 要件の仕様… 3 2. LZSパケット… 3 2.1 そっと歩きます… 4 2.2 削除/挿入のゼロを合わせてください… 4 2.3 信頼性であって配列すること… 4 2.3 .1 リセット要求とリセット-Ackパケット・フォーマット… 5 2.4 データ拡大… 6 2.5 パケット形式… 6 2.5 .1 pppプロトコル… 7 2.5 .2 歴史番号… 7 2.5 .3 値をチェックしてください… 7 2.5 .3 .1LCB… 7 2.5 .3 .2CRC… 7 2.5 .3 .3一連番号… 8 2.5 .3 .3 .1 一連番号の例との歴史同期… 9
Friend & Simpson Informational [Page 1] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[1ページ]のRFC1974Stac LZS1996年8月
2.5.4 History Synchronization Procedure ............... 10
2.5.5 Compressed Data ................................. 11
3. Sending Compressed Datagrams .......................... 12
3.1 Transmitter Process ............................. 12
3.2 Receiver Process ................................ 12
3.3 History Maintenance ............................. 13
3.4 History Resynchronization Mechanism ............. 14
4. Configuration Option Format ........................... 14
5. Definition of Extended Mode ........................... 16
5.1 Extended Mode Packet Format ..................... 16
5.2 Extended Mode Transmitter Process ............... 18
5.3 Extended Mode Receiver Process .................. 18
5.4 Extended Mode Synchronization ................... 19
SECURITY CONSIDERATIONS ...................................... 19
REFERENCES ................................................... 20
CHAIR'S ADDRESS ........................................... 20
AUTHORS' ADDRESSES............................................ 20
2.5.4 歴史同期手順… 10 2.5 .5 データを圧縮します… 11 3. 発信はデータグラムを圧縮しました… 12 3.1 送信機の過程… 12 3.2 受信機の過程… 12 3.3 歴史維持… 13 3.4歴史Resynchronizationメカニズム… 14 4. 設定オプション形式… 14 5. 拡張モードの定義… 16 5.1 モードパケット・フォーマットを広げています… 16 5.2 モード送信機の過程を広げています… 18 5.3 モード受信機の過程を広げています… 18 5.4 モード同期を広げています… 19 セキュリティ問題… 19の参照箇所… 20 議長のアドレス… 20人の作者のアドレス… 20
1. Introduction
1. 序論
Starting with a sliding window compression history, similar to LZ1 [3], Stac Electronics developed a new, enhanced compression algorithm identified as Stac LZS. The LZS algorithm is optimized to compress all file types as efficiently as possible. Even string matches as short as two octets are effectively compressed.
引窓圧縮歴史からの始め、LZ1[3]と同様です、Stac ElectronicsはStac LZSとして特定された新しくて、高められた圧縮アルゴリズムを開発しました。 LZSアルゴリズムは、できるだけ効率的にすべてのファイルの種類を圧縮するために最適化されます。 事実上、2つの八重奏が圧縮されるのと同じくらい急にマッチを結びさえしてください。
The Stac LZS compression algorithm supports both single compression history communication and multiple compression history communication.
Stac LZS圧縮アルゴリズムはただ一つの圧縮歴史コミュニケーションと複数の圧縮歴史コミュニケーションの両方を支持します。
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.
ただ一つの圧縮歴史は、実行するメモリの最小の量を必要としますが、複数の歴史実現と同じくらい多くの圧縮を提供しないかもしれません。
Often, many streams of information are interleaved over the same link. Each virtual link will transmit data that is independent of other virtual links. 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 at the address and phone number listed with the author's address for further information.
ソースと物のライセンスは非差別しているベースで手があいています。 また、ハードウェア実装も利用可能です。 詳細のための作者のアドレスで記載されたアドレスと電話番号でStac Electronicsに連絡してください。
Friend & Simpson Informational [Page 2] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[2ページ]のRFC1974Stac LZS1996年8月
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つであることを意味します。 オプションを含んでいる別の実現で共同利用するようにこのオプションを含んでいない実現を準備しなければなりません。
2. LZS Packets
2. LZSパケット
Before any LZS packets may be communicated, PPP must reach the Network-Layer Protocol phase.
どんなLZSパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません。
When the Compression Control Protocol (CCP) has reached the Opened state, and LZS is negotiated as the primary compression algorithm, exactly one Stac LZS 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.
いつ、Compression Controlプロトコル(CCP)がOpened状態に達して、LZSが一次圧密アルゴリズムとして交渉されて、ちょうど1個のStac LZSデータグラムがPPPプロトコル分野がタイプ十六進法00FD(圧縮されたデータグラム)を示すPPP情報分野で要約されるか、そして、タイプが00FBに魔法をかけます(個々のリンクはデータグラムを圧縮しました)。 圧縮が単一の物理的なリンクの上に交渉されるか、または圧縮が複数の物理的なリンクから成りながらただ一つのバンドルの上で交渉されるとき、タイプ十六進法00FDは使用されています。 圧縮が別々に同じ目的地への個々の物理的なリンクの上に交渉されるとき、タイプ十六進法00FBは使用されています。 詳しくは、PPP Compression Controlプロトコルを参照してください。
When CCP has not successfully reached the Opened state, or LZS is not the primary compression algorithm, exactly one LZS datagram is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 4021 (Stac LZS).
LZSが一次圧密アルゴリズムでない、いつCCPは首尾よくOpened状態に達していないか、そして、またはちょうど1個のLZSデータグラムがPPP情報分野で要約されます。そこで、PPPプロトコル分野は、タイプが4021(Stac LZS)人に魔法をかけるのを示します。
Note that in the latter case, use of LZS is terminated by the PPP
LCP Protocol-Reject. The default format is used: a single history
with no History Number field and no Check Value field (as if the
後者の場合では、LZSの使用がPPP LCPプロトコル廃棄物によって終えられることに注意してください。 省略時書式は使用されています: Numberがさばく歴史にもかかわらず、Check Value分野がないことのないただ一つの歴史、(
Friend & Simpson Informational [Page 3] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[3ページ]のRFC1974Stac LZS1996年8月
negotiated history count were 1).
交渉された歴史カウントは1です)。
The maximum length of the Stac LZS datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet.
PPPリンクの上に送られたStac LZSデータグラムの最大の長さはPPPの情報分野の最大の長さがパケットをカプセルに入れったのと同じです。
Prior to compression, the uncompressed data begins with the PPP Protocol ID Field. Protocol-Field-Compression MAY be used on this value, if it 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 layers.
元の情報分野はPPPプロトコルID Fieldのあとに続いています。 解凍されたデータ・フィールドの長さは圧縮されたデータ・フィールドと、より高いプロトコル層の許容サイズだけによって制限されます。
PPP Link Control Protocol packets MUST NOT be sent within Stac LZS packets. PPP Network Control Protocol packets MUST NOT be sent within Stac LZS packets.
Stac LZSパケットの中でPPP Link Controlプロトコルパケットを送ってはいけません。 Stac LZSパケットの中でPPP Network Controlプロトコルパケットを送ってはいけません。
2.1. Padding
2.1. 詰め物
The LZS Information field always ends with the last compressed data byte (also known as the <end marker>), which is used to disambiguate padding. This allows trailing bits as well as octets to be considered padding.
LZS情報分野はいつも最後に圧縮されたデータ・バイト(また、<エンドマーカー>として、知られている)で終わります。(それは、詰め物のあいまいさを除くのに使用されます)。 これは、八重奏と同様に引きずっているビットが詰め物であると考えられるのを許容します。
2.2 Zero Deletion/Insertion
2.2 削除/挿入がありません。
When the sender does not add Padding [1], any trailing zero octets MAY be removed prior to transmission. A single trailing zero octet MUST be appended upon receipt, after removal of any framing FCS.
送付者がPadding[1]を加えないとき、いくらか、トランスミッションの前に八重奏を全く引きずらないのを取り除くかもしれません。 どんな縁どりFCSの解任の後にも領収書で八重奏を全く引きずらないシングルを追加しなければなりません。
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 resetting 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 more than 1 Compression History is negotiated, the packet sequence MUST be preserved within specific History Numbers. There is no sequence requirement between different History Numbers.
1つ以上のCompression歴史が交渉されるとき、特定の歴史民数記の中にパケット系列を保存しなければなりません。 異なった歴史民数記の間には、系列要件が全くありません。
Friend & Simpson Informational [Page 4] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[4ページ]のRFC1974Stac LZS1996年8月
When one or more compression histories is negotiated on the link, the implementation MUST implement either a lower layer reliable link protocol, or keep the compressor and decompressor histories in synchronization, or both.
1つ以上の圧縮歴史がリンクに関して交渉されるとき、実現は、コンプレッサーと減圧装置が歴史であることを下層の信頼できるリンク・プロトコルを実行しなければならないか、または同期、または両方に保たなければなりません。
To maintain history synchronization, the implementation MUST use the Reset-Request and Reset-Ack messages of the Compression Control Protocol and MUST use an Option 17 check mode value of sequence numbers (and MAY implement other check mode values other than none). In this case the Data field of the CCP Reset-Request and Reset-Ack MUST contain the two octet History Number to be reset, most significant octet first.
実現は、歴史同期を維持するのに、Compression Controlプロトコルに関するReset-要求とReset-Ackメッセージを使用しなければならなくて、一連番号(そして、なにも以外の他のチェック最頻値を実行するかもしれない)のOption17チェック最頻値を使用しなければなりません。 この場合、CCP Reset-要求とReset-AckのData分野はリセットされるべき2八重奏歴史Numberを含まなければならなくて、最も重要な八重奏は1番目です。
If neither of these conditions are met on the data link, then the compression histories MUST be reset after transmitting each datagram.
これらの状態のどちらもデータ・リンクの上で会われないなら、各データグラムを送った後に、圧縮歴史をリセットしなければなりません。
The transmitter MAY clear a Compression History at any time. The receiver is implicitly notified of this event, and the decompression history will automatically be affected.
送信機はいつでも、Compression歴史をクリアするかもしれません。 受信機はこの出来事についてそれとなく通知されます、そして、減圧歴史は自動的に影響を受けるでしょう。
The transmitter MUST reset a history after a CCP Reset-Request for the given History Number.
送信機は与えられた歴史Numberを求めるCCP Reset-要求の後に歴史をリセットしなければなりません。
2.3.1 Reset-Request and Reset-Ack Packet Formats
2.3.1 リセット要求とリセット-Ackパケット・フォーマット
A summary of the CCP Reset-Request and Reset-Ack packet formats
for Stac LZS compressed links are shown below. The fields are
transmitted from left to right.
圧縮されたリンクが以下で見せられるStac LZSのためのCCP Reset-要求とReset-Ackパケット・フォーマットの概要。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
14 for Reset-Request;
14 リセット要求のために。
15 for Reset-Ack.
15 リセット-Ackのために。
Identifier
識別子
On transmission, the Identifier field MUST be changed whenever the
content of the Data field changes, and whenever a valid reply has
トランスミッションに関して、Data分野の内容が変化するときはいつも、Identifier分野を変えなければならなくて、a有効であるときはいつも、回答は変えました。
Friend & Simpson Informational [Page 5] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[5ページ]のRFC1974Stac LZS1996年8月
been received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
前の要求のために、受け取ります。 「再-トランスミッション」に関しては、Identifierは変わりがないかもしれません。
On reception, the Identifier field of the Reset-Request is copied
into the Identifier field of the Reset-Ack packet.
レセプションでは、Reset-要求のIdentifier分野はReset-AckパケットのIdentifier分野にコピーされます。
Data
データ
The Data field contains the two octet History Number of the
compression history that is to be reset, most significant octet
first. This History Number value is 1 when no history number is
present.
Data分野は最初に、リセットされることになっている、圧縮歴史の2八重奏歴史Number、最も重要な八重奏を含みます。 どんな歴史番号も存在していないとき、この歴史Number価値は1です。
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%大きいということであるかもしれません。 そして、いつも拡大にかかわらず圧縮されていた状態でパケットを送ることができます。
When the expansion plus compression header exceeds the size of the peer's MRU for the link, the PPP packet MUST be sent without compression, in the original PPP packet form with the "native" PPP Protocol ID number. The transmitter MUST reset the affected history.
拡大プラス圧縮ヘッダーが同輩のMRUのサイズをリンクに超えているとき、圧縮なしでPPPパケットを送らなければなりません、「ネイティブ」のPPPプロトコルID番号がある元のPPPパケットフォームで。 送信機は影響を受ける歴史をリセットしなければなりません。
If it is detected that most packets are expanding (for example, due to the use of already compressed data), then the transmitter SHOULD stop sending compressed packets, and reset the appropriate history. Data compression MAY be resumed on this data link later.
それが検出されるなら、ほとんどのパケットが広がっていて(例えば既に圧縮されたデータの使用のため)、次に、送信機SHOULDが、発信するのを止めるのが、パケットを圧縮して、適切な歴史をリセットしました。 データ圧縮は後でこのデータ・リンクの上で再開されるかもしれません。
2.5. Packet Format
2.5. パケット・フォーマット
A summary of the Stac LZS packet format is shown below. The fields are transmitted from left to right.
Stac LZSパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol | (History Number*) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Check Value*) | Compressed Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Note: these fields are variable length fields as described below.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル| (歴史番号*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (チェック値*) | データを圧縮します… +++++++++++++++++++++++++++++++++*注意: これらの分野は以下で説明されるように可変長フィールドです。
Friend & Simpson Informational [Page 6] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[6ページ]のRFC1974Stac LZS1996年8月
2.5.1. PPP Protocol
2.5.1. pppプロトコル
The PPP Protocol field is a 2 octet field described in the Point-
to-Point Protocol Encapsulation [1].
PPPプロトコル分野はポイントへのPointプロトコルEncapsulation[1]で説明された2八重奏分野です。
When the Stac LZS compression protocol is successfully negotiated
by the PPP Compression Control Protocol [2], the value is 00FD hex
or 00FB hex as described in section 2. This value MAY be
compressed when Protocol-Field-Compression is negotiated.
Stac LZS圧縮プロトコルがPPP Compression Controlプロトコル[2]によって首尾よく交渉されるとき、値は、セクション2で説明されるように00FD十六進法か00FB十六進法です。 プロトコル分野圧縮が交渉されるとき、この値は圧縮されるかもしれません。
2.5.2. History Number
2.5.2. 歴史番号
The history number field comprises 0, 1, or 2 octets.
歴史ナンバーフィールドは0、1、または2つの八重奏を包括します。
The number of the compression history which was used, ranging from
2 to the negotiated History Count. By default a History Count of
value 1 is supported and this field is not present.
2〜交渉された歴史Countまで及んで、費やされた圧縮歴史の数。 デフォルトで、価値1の歴史Countは支持されます、そして、この分野は存在していません。
If the negotiated History Count is less than 2, this field is
removed. There is no need for the field when no history is kept,
or only a single history is kept.
交渉された歴史Countが2歳未満であるなら、この野原を取り除きます。 歴史が全く保管されないか、またはただ一つの歴史だけが保管されるとき、分野の必要は全くありません。
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歳以上ですが、この分野が256よりそれほど1つの八重奏であるなら。 256以上の歴史が交渉されるなら、最初に、この分野は2つの八重奏、最も重要な八重奏です。
2.5.3. Check Value
2.5.3. 値をチェックしてください。
The check value field comprises 0, 1, or 2 octets. By default,
sequence number check is added to the packet (the field comprises
1 octet).
チェック値の分野は0、1、または2つの八重奏を包括します。 デフォルトで、一連番号チェックはパケットに加えられます(分野は1つの八重奏を包括します)。
2.5.3.1. LCB
2.5.3.1. LCB
A simple one octet Longitudinal Check Byte (LCB) MAY be used,
after successful negotiation of the LCB option. The LCB is the
Exclusive-OR of FF(hex) and each octet of the uncompressed
datagram (prior to the compression operation). 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 2.5.4.
簡単な1つの八重奏のLongitudinal Check Byte(LCB)はLCBオプションのうまくいっている交渉の後に使用されるかもしれません。 LCBはFF(十六進法)のExclusive-ORと解凍されたデータグラム(圧縮操作の前の)の各八重奏です。 領収書の上では、受信機はFF(十六進法)のExclusive-ORと減圧されたパケットの各八重奏を計算します。 この値が合っていないなら、その歴史が現れたので、容認されたLCB、当時のaは失敗を受けます。 失敗を受けてください。セクション2.5.4における歴史同期手順によると、扱われます。
2.5.3.2. CRC
2.5.3.2. CRC
A two octet Cyclic Redundancy Check (CRC) MAY be used, instead
of the LCB, after successful negotiation of the CRC option.
2八重奏Cyclic Redundancy Check(CRC)は使用されるかもしれません、LCBの代わりに、CRCオプションのうまくいっている交渉の後に。
Friend & Simpson Informational [Page 7] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[7ページ]のRFC1974Stac LZS1996年8月
The transmitter MUST initialize the CRC value to FFFF(hex) at
the beginning of each packet. The CRC computation is based on
the HDLC FCS-16 polynomial:
送信機はそれぞれのパケットの始めにFFFF(十六進法)にCRC値を初期化しなければなりません。 CRC計算はHDLC FCS-16多項式に基づいています:
x**16 + x**12 + x**5 + 1
x**16+x**12+x**5+1
The ones complement of the CRC is transmitted least significant
octet first, which contains the coefficient of the highest
term. On receipt, the receiver initializes the CRC to FFFF
(hex), and computes the CRC based on the formula above for each
octet of the decompressed packet. If the received CRC value
does not match the transmitted CRC value, then a receive
failure for that history has occurred. The receive failure is
handled according to the history synchronization procedure in
section 2.5.4.
最初に、CRCのもの補数が伝えられた最も重要でない八重奏です(最も高い用語の係数を含んでいます)。 領収書の上では、受信機は、FFFF(十六進法)にCRCを初期化して、減圧されたパケットの各八重奏のために上で公式に基づいたCRCを計算します。 容認されたCRC値が合っていないなら、その歴史が現れたので、伝えられたCRC値、当時のaは失敗を受けます。 失敗を受けてください。セクション2.5.4における歴史同期手順によると、扱われます。
2.5.3.3. Sequence Number
2.5.3.3. 一連番号
A one octet Sequence Number MAY be used, instead of a LCB or
CRC, after successful negotiation of the Sequence Number
option. After CCP has reached the open state, the transmitter
MUST set the value of the sequence number field (the sequence
number of the packet) to "1" and increment modulo 256 on
successive packets that contain data fields. The sequence
number is relative to the history number used.
1つの八重奏のSequence Numberは使用されるかもしれません、LCBかCRCの代わりに、Sequence Numberオプションのうまくいっている交渉の後に。 CCPが開口状態に達した後に、送信機は「データ・フィールドを含む連続したパケットの上の1インチと増分の法256」に一連番号分野(パケットの一連番号)の値を設定しなければなりません。 一連番号は数が費やした歴史に比例しています。
After CCP has reached the open state, the receiver MUST set its
internal reference value of the next expected sequence number
(the sequence number of next packet to be received) to "1".
CCPが開口状態に達した後に、受信機は次の予想された一連番号(次の受け取られるべきパケットの一連番号)の内部の基準値を「1インチ」に設定しなければなりません。
After a packet is received, the receiver MUST set the value of
its internal reference value of the next expected sequence
number for that history to the value of the sequence number
field of the received packet plus 1 modulo 256.
パケットが受け取られていた後に、受信機は容認されたパケットプラス1法256の一連番号分野の値へのその歴史に次の予想された一連番号の内部の基準値の値を設定しなければなりません。
If the sequence number of the received packet is not equal to
the internal reference value of the expected sequence number
for the same history, a receive failure for that history has
occurred. The receiver MUST silently discard the out of order
packet, and handle the failure according to the history
synchronization procedure in section 2.5.4.
容認されたパケットの一連番号が内部の参照と等しくないなら、同じ歴史、aがその歴史がそうしたので失敗を受けるので、期待している一連番号の値は起こりました。 セクション2.5.4における歴史同期手順によると、受信機は、静かに故障しているパケットを捨てて、失敗を扱わなければなりません。
The sequence number MUST NOT be reset by the transmitter when a
packet containing a Reset-Req is received. The receiver MUST
always maintain its sequence number references for all
supported histories.
Reset-Reqを含むパケットが受け取られているとき、一連番号は送信機によってリセットされてはいけません。 受信機は、いつもすべての一連番号参照が歴史をサポートしたと主張しなければなりません。
Friend & Simpson Informational [Page 8] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[8ページ]のRFC1974Stac LZS1996年8月
2.5.3.3.1 History Synchronization with Sequence Numbers Example
2.5.3.3.1 一連番号の例との歴史同期
Compressing Sender Decompressing Receiver
.... ....
send seq 101 -----------> recv seq 101
is 101 == 101? Ok.
forward packet for processing
set internal reference to 102
受信機を減圧する送付者を圧縮します… …、seq101を送ってください。----------->recv seq101は101 == 101ですか? OK、処理のための前進のパケットは102の内部の参照を設定しました。
send seq 102 -----------> recv seq 102
is 102 == 102? Ok.
forward packet for processing
set internal reference to 103
seq102を送ってください。----------->recv seq102は102 == 102ですか? OK、処理のための前進のパケットは103の内部の参照を設定しました。
send seq 103 ------X (packet lost)
seq103を送ってください。------X(失われたパケット)
send seq 104 -----------> recv seq 104
is 104 == 103? Send reset req!
silently discard packet
set internal reference to 105
seq104を送ってください。----------->recv seq104は104 == 103ですか? 静かにリセットreq!を送ってください、そして、105のパケットのセットの内部の参照を捨ててください。
(packet lost) X------- send reset request (ID=200)
post-increment the identifier.
(パケットは損をしました) X------- リセット要求(ID=200)ポスト増分に識別子を送ってください。
send seq 105 -----------> recv seq 105
is 105 == 105? Ok.
was reset ack received? No!
silently discard packet
set internal reference to 106
seq105を送ってください。----------->recv seq105は105 == 105ですか? OK、リセットackを受け取りましたか? いいえ、静かに106のパケットのセットの内部の参照を捨ててください。
<----------- send reset request again(ID=200)
(e.g. reset-ack time out)
<。----------- もう一度(ID=200)リセット要求を送ってください。(例えば、リセット-ackタイムアウト)
send seq 106 ------X (packet lost)
seq106を送ってください。------X(失われたパケット)
recv reset req <-----------
(after line delay)
(ID=200)
recvリセットreq<。----------- (線遅れの後の) (ID=200)
reset compression
history
send reset ack -----------> recv reset ack (ID=200)
(ID=200)
リセット圧縮歴史はリセットackを送ります。----------->recvリセットack(ID=200)(ID=200)
send seq 107 -----------> recv seq 107
is 107 == 106? Send reset req!
silently discard packet
set internal reference to 108
seq107を送ってください。----------->recv seq107は107 == 106ですか? 静かにリセットreq!を送ってください、そして、108のパケットのセットの内部の参照を捨ててください。
Friend & Simpson Informational [Page 9] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[9ページ]のRFC1974Stac LZS1996年8月
recv reset req <----------- send reset request (ID=201)
(ID=201) post-increment the identifier.
recvリセットreq<。----------- リセット要求(ID=201)(ID=201)ポスト増分に識別子を送ってください。
send seq 108 -----------> recv seq 108
is 108 == 108? Ok.
was reset ack received? No!
silently discard packet
set internal reference to 109
seq108を送ってください。----------->recv seq108は108 == 108ですか? OK、リセットackを受け取りましたか? いいえ、静かに109のパケットのセットの内部の参照を捨ててください。
send seq 109 -----------> recv seq 109
is 109 == 109? Ok.
was reset ack received? No!
silently discard packet
set internal reference to 110
seq109を送ってください。----------->recv seq109は109 == 109ですか? OK、リセットackを受け取りましたか? いいえ、静かに110のパケットのセットの内部の参照を捨ててください。
reset compression
history
send reset ack -----------> recv reset ack (ID=201)
(ID=201)
リセット圧縮歴史はリセットackを送ります。----------->recvリセットack(ID=201)(ID=201)
send seq 110 -----------> recv seq 110
is 110 == 110? Ok.
forward packet for processing
set internal reference to 111
seq110を送ってください。----------->recv seq110は110 == 110ですか? OK、処理のための前進のパケットは111の内部の参照を設定しました。
send seq 111 -----------> recv seq 111
is 111 == 111? Ok.
forward packet for processing
set internal reference to 112
.... ....
seq111を送ってください。----------->recv seq111は111 == 111ですか? OK、処理のための前進のパケットは112の内部の参照を設定しました… ....
2.5.4. History Synchronization Procedure
2.5.4. 歴史同期手順
On receipt, if Sequence Number one (1) follows any other number
than zero (0), or is otherwise out of sequence, or the LCB or CRC
is invalid, a CCP Reset-Request MUST be sent, containing the two
octet History Number (most significant octet first, and which is
the value 1 when no History Number is present), with a CCP
Identifier. Identifiers are incremented on each occurrence of an
out of sequence packet.
値はどれです。Sequence Number1(1)が(0)のゼロを合わせるよりいかなる他の数にも続くか、そうでなければ、系列から脱している、またはLCBかCRCが無効であるなら、領収書で、CCP Reset-要求を送らなければなりません、2八重奏歴史Numberを含んでいて(最も重要な八重奏、最初に、歴史Numberがないのが存在している1) CCP Identifierと共に。 識別子が各発生で増加される、順序が狂ってパケット。
Upon receipt of the Reset-Request, the transmitter MUST reset the
affected compression history, and transmit a CCP Reset-Ack packet
with the Identifier field and data (history number) field set to
the corresponding values of the Reset-Request. However, the
Sequence Number (if implemented) is not reset.
Reset-要求を受け取り次第、送信機は、Reset-要求の換算値に設定されたIdentifier分野とデータ(歴史番号)分野で、影響を受ける圧縮歴史をリセットして、CCP Reset-Ackパケットを伝えなければなりません。 しかしながら、Sequence Number(実行されるなら)はリセットされません。
Friend & Simpson Informational [Page 10] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[10ページ]のRFC1974Stac LZS1996年8月
For each packet that generates a receive failure, the receiver
MUST increment the Identifier and transmit a CCP Reset-Request.
For re-transmissions of existing receive failures, the Identifier
MUST NOT be incremented.
受信機はIdentifierを増加しなければなりません、そして、aを発生させる各パケットに関しては、失敗を受けてください、そして、CCP Reset-要求を伝えてください。 存在する再トランスミッションには、失敗を受けてください、そして、Identifierは増加されてはいけません。
After transmitting the Reset-Request packet, the receiver MUST
continue silently discarding valid compressed packets for the
corresponding history, until the correct CCP Reset-Ack Identifier
(corresponding to the Reset-Request) for that History Number is
received. Note that if sequence numbers are used, the receiver
MUST process the sequence number of a received packet according to
the procedures in section 2.5.4.
Reset-リクエスト・パケットを伝えた後に、受信機は、対応する歴史のために静かに有効な圧縮されたパケットを捨て続けなければなりません、その歴史Numberのための正しいCCP Reset-Ack Identifier(Reset-要求に対応する)が受け取られているまで。 一連番号が使用されているなら、セクション2.5.4における手順によると、受信機が容認されたパケットの一連番号を処理しなければならないことに注意してください。
2.5.5. Compressed Data
2.5.5. 圧縮されたデータ
The data field MUST contain only one datagram in compressed form.
The length of this field is always an integer number of octets.
There MUST BE only one end marker per block of compressed data.
データ・フィールドは圧縮形に1個のデータグラムだけを含まなければなりません。 いつもこの分野の長さは八重奏の整数です。 圧縮されたデータのブロックあたりの片端マーカーしかないに違いありません。
The form of the data field is one block of compressed data as
defined in 3.2 of X3.241-1994, and is repeated here for
informational purposes ONLY.
データ・フィールドのフォームは、3.2X3.241-1994で定義されるように1ブロックの圧縮されたデータであり、情報の目的だけのためにここで繰り返されます。
<Compressed Stream> := [<Compressed String>] <End Marker> <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes> <Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte) <Compressed Bytes> := <Offset> <Length>
<圧縮された流れの>:=[<はストリング>を圧縮した]<エンドマーカー><はストリング>:=生の0<バイト>を圧縮しました。| 1 <圧縮されたBytesの<b><b><Raw 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
<は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
<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…
Friend & Simpson Informational [Page 11] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[11ページ]のRFC1974Stac LZS1996年8月
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. 送信機の過程
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. Prior to the compression operation, if a Reset- Request is outstanding for the history buffer to be used or if the negotiated history count for this data link is 0, the history buffer is cleared.
ネットワークデータグラムが受け取られているとき、それは、特定の歴史バッファに割り当てられて、ANSI X3.241-1994によると、圧縮されたデータを形成するために処理されます。 圧縮操作の前に、歴史バッファはReset要求が歴史バッファが使用されるために傑出しているか、このデータ・リンクのための交渉された歴史カウントが0であるなら、きれいにされます。
Uncompressed data MUST be sent (in the original PPP packet form with the "native" PPP Protocol ID number) if compression causes enough expansion to cause the data compression datagram size to exceed the Information field's MRU. In this case, since the compressor has modified the history buffer before sending an uncompressed datagram, the history buffer MUST be cleared before the next datagram is processed.
データ圧縮データグラムサイズが拡大で情報フィールドのMRUを十分超えているなら、圧縮で解凍されたデータを送らなければなりません(「ネイティブ」のPPPプロトコルID番号がある元のPPPパケットフォームで)。 この場合、解凍されたデータグラムを送る前にコンプレッサーが歴史バッファを変更して以来、次のデータグラムが処理される前に歴史バッファをきれいにしなければなりません。
The output of the compression operation is placed in the information field of the datagram. 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 LCB field is present according the value of the check mode field, the LCB value MUST be computed as specified in section 2.5.3.1. and the resultant value placed in the LCB field. If the CRC field is present according the value of the check mode field, the CRC value MUST be computed as specified in section 2.5.3.2. and the resultant value placed in the LCB field. Upon reception of a CCP Reset-Request packet, the transmitting compressor MUST be cleared to an initial state, which includes clearing the history buffer. In addition to the reset of the compressor, a CCP Reset-Ack packet MUST be transmitted. The data field of this packet MUST be filled with the corresponding two octet history number, most significant octet first.
圧縮操作の出力はデータグラムの情報フィールドに置かれます。 一連番号分野がチェックモード分野の値存在しているなら、適切な歴史番号のための一連番号カウンタは増加していなければならなくて、値は一連番号分野に置かれます。 LCB分野がチェックモード分野の値存在しているなら、LCB値として.1と結果の値がLCB分野に置いたセクション2.5.3で指定されていた状態で計算しなければなりません。 CRC分野がチェックモード分野の値存在しているなら、CRC値として.2と結果の値がLCB分野に置いたセクション2.5.3で指定されていた状態で計算しなければなりません。 CCP Reset-リクエスト・パケットのレセプションでは、伝えるコンプレッサーを初期状態にきれいにしなければなりません。(それは、歴史バッファをきれいにするのを含んでいます)。 コンプレッサーのリセットに加えて、CCP Reset-Ackパケットを伝えなければなりません。 最初に、このパケットのデータ・フィールドは対応する2八重奏歴史番号で満たされて、最も重要な八重奏であるに違いありません。
3.2. Receiver Process
3.2. 受信機の過程
If a CCP Reset-Request packet is received, the local compression engine MUST be signaled that a Reset-Request has been received for the history number specified in the data field. If a CCP Reset-Ack packet is received, 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 is checked. If a receive failure has occurred, it MUST be handled according to the
CCP Reset-リクエスト・パケットが受け取られているなら、Reset-要求がデータ・フィールドで指定された歴史番号のために受け取られたと地方の圧縮エンジンに合図しなければなりません。 CCP Reset-Ackパケットが受け取られているなら、未払いのいずれも、指定された歴史をクリアしなければならないので、失敗を受けます。 いいえが受信されるなら、失敗は傑出しています、そして、一連番号分野が存在している、値はチェックされます。 aが受信されるなら、失敗は起こって、それを扱わなければなりません。
Friend & Simpson Informational [Page 12] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[12ページ]のRFC1974Stac LZS1996年8月
history resynchronization mechanism described 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 the compressed data block MUST be decompressed according to ANSI X3.241-1994. If the LCB or CRC fields are present on the received datagram, an LCB or CRC for the uncompressed data MUST be computed and checked against the received LCB or CRC according to sections 2.5.3.1. or 2.5.3.2., respectively. If a receive failure has occurred, it MUST be handled according to the History Resynchronization Mechanism described in section 3.4.
いいえが受信されるなら、失敗は検出されます、そして、データは示された減圧歴史バッファに割り当てられます、そして、ANSI X3.241-1994によると、圧縮されたデータ・ブロックを減圧しなければなりません。 LCBかCRC分野が容認されたデータグラムに存在しているなら、解凍されたデータのためのLCBかCRCが計算しなければならなくて、セクション2.5.3.1 2.5に従って、容認されたLCBかCRCに対して.2に、それぞれ.3をチェックしました。 aが受信されるなら、失敗は起こって、セクション3.4で説明された歴史Resynchronization Mechanismによると、それを扱わなければなりません。
If a CCP Reset-Ack packet is received, the receiving decompressor's corresponding history MAY be reset to an initial state. (However, due to the characteristics of the Stac LZS algorithm, a decompressor history reset is not required). After reset, any compressed or uncompressed data contained in the packet is processed.
CCP Reset-Ackパケットが受け取られているなら、受信減圧装置の対応する歴史は初期状態にリセットされるかもしれません。 (しかしながら、Stac LZSアルゴリズムの特性のため、減圧装置歴史リセットは必要ではありません。) リセットされた後に、パケットに含まれたどんな圧縮されたか解凍されたデータも処理されます。
On the occurrence of a receive failure, an implementation MUST transmit a CCP Reset-Request packet with the data field containing the two octet history number (most significant octet first) matching the history that had the failure. Once a receive failure has occurred, the data in any subsequent packets received for that history MUST be discarded until a CCP Reset-Ack packet containing a valid Identifier matching the Identifier that was sent with the last CCP Reset-Request packet is received. It is the responsibility of the receiver to ensure the reliability of the Reset-Request/Ack mechanism. This may require the transmission of additional CCP Reset-Request packets before a CCP Reset-Ack packet is received.
aの発生では、失敗を受けてください、実現がデータ・フィールドが2八重奏歴史番号を含んでいるCCP Reset-リクエスト・パケットを伝えなければならない、(最も重要な八重奏、1番目) 失敗を持っていた歴史を合わせます。 aがいったん受信されると、失敗は起こって、最後のCCP Reset-リクエスト・パケットと共に送られたIdentifierに合っている有効なIdentifierを含むCCP Reset-Ackパケットが受け取られているまで、その歴史のために受け取られたどんなその後のパケットのデータも捨てなければなりません。 Reset-要求/Ackメカニズムの信頼性を確実にするのは、受信機の責任です。 CCP Reset-Ackパケットが受け取られている前にこれは追加CCP 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, 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.
歴史Count分野は、歴史バッファの数が圧縮プロトコルのために維持されることを決定します。 例えば、それぞれの歴史バッファはデータ圧縮同輩の間の別々の論理的な接続の代理をするかもしれません。 歴史を維持するとき、同輩は、コンプレッサーとそれぞれの歴史バッファの減圧装置コピーの両方が確実にいつも同じになるようにするのにリンク誤り検出とシグナリングを使用しなければなりません。
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.
歴史Count分野を値に設定して、「0インチは、圧縮がコネクションレスベースにあることであることを示します」。 この場合、ただ一つの歴史バッファを使用されていて、あらゆるデータグラムの始めにきれいにしなければなりません。
When the History Count field is set to the value "1", a single history buffer is maintained by each of the data compression peers.
歴史Count分野が値に設定されるとき、「何1インチも、ただ一つの歴史バッファはデータ圧縮同輩各人によって維持されます」。
Friend & Simpson Informational [Page 13] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[13ページ]のRFC1974Stac LZS1996年8月
(A single logical connection.)
(単独の論理的な接続。)
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. History Resynchronization Mechanism
3.4. 歴史Resynchronizationメカニズム
The Stac LZS protocol utilizes CCP Reset-Request/Reset-Ack mechanism 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 using the LCB, CRC, or sequence number mechanisms, according to the value of the check mode field.
Stac LZSプロトコルは、もう片方の方向に交通に影響しないで圧縮されたリンクの一方向に受信機の故障を示すのにメカニズムを提供するのにリセットCCP Reset-要求/Ackメカニズムを利用します。 Aは受信されます。失敗はLCB、CRC、または一連番号メカニズムを使用することで決定しています、チェックモード分野の値に従って。
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 Stac LZS protocol provides a means to detect these error conditions: LCB or CRC 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.
Stac LZSプロトコルはこれらのエラー条件を検出する手段を提供します: 誤ったデータグラム、および一連番号のためのLCBかCRC、低下したか誤命令されたデータグラム同期の損失を修正するための手段があります: 失敗圧縮と減圧歴史の両方をクリアしてください、そして、セクション3.1と3.2における送信機と受信機の過程に従ってください。
4. Configuration Option Format
4. 設定オプション形式
Description
記述
The CCP Stac LZS Configuration Option negotiates the use of
Stac LZS on the link. By ultimate disagreement, no compression is
used.
CCP Stac LZS Configuration OptionはリンクにおけるStac LZSの使用を交渉します。 究極の不一致で、どんな圧縮も使用されていません。
All implementations must support the default values.
すべての実現がデフォルト値を支持しなければなりません。
Friend & Simpson Informational [Page 14] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[14ページ]のRFC1974Stac LZS1996年8月
A summary of the Stac LZS Configuration Option format is shown below. The fields are transmitted from left to right.
Stac LZS 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 |
+-+-+-+-+-+-+-+-+
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
タイプ
17
17
Length
長さ
5
5
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.
値0は、実現が、同輩が始めのCompression歴史からあらゆるパケットを取り除くと予想するのを示します。
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 field indicates support of LCB, CRC or Sequence
checking, and other future extensions to this standard. This
field comprises 2 sub-fields, and is considered to be bit-mapped.
The 3 least significant bits comprise 5 mutually exclusive values.
The upper 5 bits are all "Reserved" bit locations must be set to
"0" to allow for future backward-compatible extensions to this
standard.
Check Mode分野はLCB、CRCまたはSequenceのチェックしていて、他の将来の拡張子のサポートをこの規格に示します。 この分野は、2つのサブ分野を包括して、ビットによって写像されていると考えられます。 3つの最下位ビットが5つの互いに唯一の値を包括します。 上側の5ビットは「今後の後方コンパチブル拡大のためにこの規格に許容する0インチ」にすべての「予約された」ビット・ロケーションを設定しなければならないということです。
Friend & Simpson Informational [Page 15] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[15ページ]のRFC1974Stac LZS1996年8月
For compatibility, Sequence Numbers MUST be implemented; the other
four check modes MAY be implemented.
互換性において、Sequence民数記を実行しなければなりません。 他の4つのチェックモードが実行されるかもしれません。
Defined values:
定義された値:
0 None (MAY be implemented; however, MUST
implement history count of zero)
1 LCB (MAY be implemented)
2 CRC (MAY be implemented)
3 Sequence Number (MUST be implemented)
4 Extended Mode (MAY be implemented)
しかしながら、0、なにも、(実行されるかもしれません;、ゼロの歴史カウント) 1LCB(実行されるかもしれない)の2CRC(実行されるかもしれない)3Sequence Number(実行しなければならない)4Extended Modeを実行しなければなりません。(実行されるかもしれません)
0 1 2 3 4 5 6 7
+-------+-------+----------+-----+-----+-----+-----+-----+
| LCB/CRC/Seq#/Ext'd | Res | Res | Res | Res | Res |
+-------+-------+----------+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-------+-------+----------+-----+-----+-----+-----+-----+ | LCB/CRC/Seq#/Extはそうするでしょう。| Res| Res| Res| Res| Res| +-------+-------+----------+-----+-----+-----+-----+-----+
5. Definition of Extended Mode
5. 拡張モードの定義
When Check Mode 4 (Extended Mode) is successfully negotiated, the packet format is different from the format described above. The Extended Mode format is described below. Extended Mode only supports a history count of 1.
Check Mode4(拡張Mode)が首尾よく交渉されるとき、パケット・フォーマットは上で説明された形式と異なっています。 Extended Mode形式は以下で説明されます。 拡張Modeは1の歴史カウントを支持するだけです。
5.1. Extended Mode Packet Format
5.1. 拡張モードパケット・フォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol |A|B|C|D| Coherency Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compressed Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル|A|B|C|D| 一貫性カウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データを圧縮します… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPP Protocol
pppプロトコル
The PPP Protocol field is described in the Point-to-Point Protocol
Encapsulation [1].
PPPプロトコル分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。
When a compression protocol is successfully negotiated by
the PPP Compression Control Protocol [2], the value is hex 00FD.
Protocol-Field-Compression MUST NOT be used on this value when
extended mode is negotiated on the link, even if Protocol-Field-
Compression was successfully negotiated before data compression.
圧縮プロトコルがPPP Compression Controlプロトコル[2]によって首尾よく交渉されるとき、値は十六進法00FDです。 拡張モードがリンクに関して交渉されるとき、この値でプロトコル分野圧縮を使用してはいけません、プロトコル分野圧縮がデータ圧縮の前に首尾よく交渉されたとしても。
Friend & Simpson Informational [Page 16] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[16ページ]のRFC1974Stac LZS1996年8月
Bit A - PACKET_FLUSHED
ビットA--パケット_は洗い流しました。
This bit indicates that the history buffer has just been reset
before this packet was generated. Thus, this packet can ALWAYS
be decompressed because it is not based on any previous history.
This bit is typically sent to inform the peer that it has reset
its history buffer and that the peer can accept this packet
and re-synchronize.
このビットは、このパケットが発生する前に歴史バッファがちょうどリセットされたところであるのを示します。 その結果、このパケット、何か既往歴に基づいていないので、ALWAYSを減圧できますか? 同輩が歴史バッファをリセットして、このパケットを受け入れて、再連動できることを同輩に知らせるためにこのビットを通常送ります。
Bit B
ビットB
This bit is not used with Stac LZS compression.
このビットはStac LZS圧縮と共に使用されません。
Bit C - PACKET_COMPRESSED
ビットC--_が圧縮したパケット
This bit is used to indicate that the packet is compressed. A
value of 0 indicates uncompressed data, and a value of 1 indicates
compressed data.
このビットは、パケットが圧縮されるのを示すのに使用されます。 0の値は解凍されたデータを示します、そして、1の値は圧縮されたデータを示します。
Bit D
ビットD
This bit is not used with Stac LZS compression.
このビットはStac LZS圧縮と共に使用されません。
Coherency Count
一貫性カウント
The coherency count is used to assure that the packets are sent in
proper order and that no packet has been dropped. This count is
initialized to the value 0x000, and is always increased by 1 after
each PPP packet is sent. When all bits are 1, the count returns
to 0.
一貫性カウントは、適切なオーダーでパケットを送って、パケットを全く落としていないことを保証するのに使用されます。 このカウントを値0x000に初期化して、それぞれのPPPパケットを送った後に1ついつも増加させます。 すべてのビットが1であるときに、カウントは0に戻ります。
The coherency count is 12 bits so the decompressor must handle the
rollover case.
一貫性カウントが12ビットであるので、減圧装置はロールオーバーケースを扱わなければなりません。
Compressed Data
圧縮されたデータ
The compressed data begins with the protocol field. For example,
an IP packet may contain 0021 followed by an IP header. The
compressor will first try to compress the 0021 protocol field and
then move on to the IP header.
圧縮されたデータはプロトコル分野で始まります。 例えば、IPヘッダーによって後をつけられて、IPパケットは0021を含むかもしれません。 コンプレッサーは、0021年のプロトコル分野を圧縮して、次に、最初に、IPヘッダーに動こうとするでしょう。
Protocol-Field-Compression MUST NOT be used on this value when
extended mode is negotiated on the link, even if Protocol-Field-
Compression was successfully negotiated before data compression.
拡張モードがリンクに関して交渉されるとき、この値でプロトコル分野圧縮を使用してはいけません、プロトコル分野圧縮がデータ圧縮の前に首尾よく交渉されたとしても。
Zero deletion/insertion described in section 2.2 MUST NOT be
performed when extended mode is negotiated.
拡張モードが交渉されるとき、セクション2.2で説明されなかった削除/挿入を全く実行してはいけません。
Friend & Simpson Informational [Page 17] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[17ページ]のRFC1974Stac LZS1996年8月
5.2. Extended Mode Transmitter Process
5.2. 拡張モード送信機の過程
When a network datagram is received, it is processed according to ANSI X3.241-1994 to form compressed data. If a CCP Reset-Request has been received from the decompressor, the compressor must clear its history buffer before sending the next packet.
ネットワークデータグラムが受け取られているとき、ANSI X3.241-1994によると、それは、圧縮されたデータを形成するために処理されます。 減圧装置からCCP Reset-要求を受け取ったなら、次のパケットを送る前に、コンプレッサーは歴史バッファをきれいにしなければなりません。
Uncompressed data MUST be sent if the compression operation causes the compressed datagram to expand. In this case, since the compressor has modified the history buffer before sending an uncompressed datagram, the history buffer MUST be cleared before the next datagram is processed. The uncompressed data is placed in the information field of the datagram, and Bit-A MUST be set (indicating the history was cleared) and Bit-C MUST be clear (indicating uncompressed data) in the current packet's header. The value of the coherency counter is placed in the coherency count field and then the coherency counter is incremented.
圧縮されたデータグラムが圧縮操作で広がるなら、解凍されたデータを送らなければなりません。 この場合、解凍されたデータグラムを送る前にコンプレッサーが歴史バッファを変更して以来、次のデータグラムが処理される前に歴史バッファをきれいにしなければなりません。 解凍されたデータはデータグラムの情報フィールドに置かれます、そして、Bit-Aは用意ができなければなりません、そして、(歴史を示すのはクリアされました)Bit-Cは現在のパケットのヘッダーで明確であるに違いありません(表示はデータを解凍しました)。 一貫性カウンタの値は一貫性カウント分野に置かれます、そして、次に、一貫性カウンタは増加されています。
If the compression operation does not cause the compressed datagram to expand and if a received Reset-Request is outstanding, then the output of the compression operation is placed in the information field of the datagram, and Bit-A MUST be set (indicating the history was cleared) and Bit-C MUST be set (indicating compressed data) in the current packet's header. The value of the coherency counter is placed in the coherency count field and then the coherency counter is incremented.
圧縮されたデータグラムが圧縮操作で広がらないで、受信されたReset-要求が傑出しているなら、圧縮操作の出力はデータグラムの情報フィールドに置かれます、そして、Bit-Aは用意ができなければなりません、そして、(歴史を示すのはクリアされました)Bit-Cは現在のパケットのヘッダーのセットであるに違いありません(圧縮されたデータを示します)。 一貫性カウンタの値は一貫性カウント分野に置かれます、そして、次に、一貫性カウンタは増加されています。
If the compression operation does not cause the compressed datagram to expand and there is not a Reset-Request outstanding, then the output of the compression operation is placed in the information field of the datagram, and Bit-A MUST be clear (indicating the history was not cleared) and Bit-C MUST be set (indicating compressed data) in the current packet's header. The value of the coherency counter is placed in the coherency count field and then the coherency counter is incremented.
圧縮されたデータグラムが圧縮操作で広がらないで、また未払いのReset-要求がなければ、圧縮操作の出力はデータグラムの情報フィールドに置かれます、そして、Bit-Aは現在のパケットのヘッダーで(歴史がクリアされなかったのを示します)、Bit-Cを設定しなければならないのが(圧縮されたデータを示して)明確であるに違いありません。 一貫性カウンタの値は一貫性カウント分野に置かれます、そして、次に、一貫性カウンタは増加されています。
Upon reception of a CCP Reset-Request packet, the transmitting compressor MUST be cleared to an initial state, which includes clearing the history buffer. In addition to the reset of the compressor, the PACKET_FLUSHED bit MUST be set in the header of the next transmitted data packet.
CCP Reset-リクエスト・パケットのレセプションでは、伝えるコンプレッサーを初期状態にきれいにしなければなりません。(それは、歴史バッファをきれいにするのを含んでいます)。 コンプレッサーのリセットに加えて、次の伝えられたデータ・パケットのヘッダーにPACKET_FLUSHEDビットを設定しなければなりません。
5.3. Extended Mode Receiver Process
5.3. 拡張モード受信機の過程
When a data compression datagram is received from the peer, Bit-A and Bit-C MUST be checked. Prior to the decompression operation, if Bit-A is set, then the coherency count MUST be resynchronized to the received value in the coherency count field of the received packet,
同輩からデータ圧縮データグラムを受け取るとき、Bit-AとBit-Cをチェックしなければなりません。 減圧操作の前に、Bit-Aが用意ができているなら、一貫性カウントは容認されたパケットの一貫性カウント分野の容認された値に再連動しなければなりません。
Friend & Simpson Informational [Page 18] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[18ページ]のRFC1974Stac LZS1996年8月
and the receiving decompressor's corresponding history MAY be reset to an initial state. (However, due to the characteristics of the Stac LZS algorithm, a decompressor history reset is not required). After reset, any compressed or uncompressed data contained in the packet is processed, depending on the state of Bit-C.
そして、受信減圧装置の対応する歴史は初期状態にリセットされるかもしれません。 (しかしながら、Stac LZSアルゴリズムの特性のため、減圧装置歴史リセットは必要ではありません。) リセットされた後に、Bit-Cの状態によって、パケットに含まれたどんな圧縮されたか解凍されたデータも処理されます。
Prior to the decompression operation, if Bit-C is clear (indicating uncompressed data), then the decompression history buffer must not be modified and the decompressor is not involved with deencapsulation. If Bit-C is set (indicating compressed data) then the received packet is decompressed according to ANSI X3.241-1994.
減圧操作の前に、Bit-Cが明確であるなら(表示はデータを解凍しました)、減圧歴史バッファを変更してはいけません、そして、減圧装置は「反-カプセル化」にかかわりません。 Bit-Cが設定されるなら(圧縮されたデータを示して)、ANSI X3.241-1994によると、容認されたパケットは減圧されます。
If the received packet is corrupt, then a Reset-Request is sent and this packet is discarded. If the received packet contains an incorrect coherency count, a Reset-Request is sent and this packet is discarded.
容認されたパケットが不正であるなら、Reset-要求を送ります、そして、このパケットは捨てます。 容認されたパケットが不正確な一貫性カウントを含んでいるなら、Reset-要求を送ります、そして、このパケットは捨てます。
5.4. Extended Mode Synchronization
5.4. 拡張モード同期
Packets may be lost during transfer. If the decompressor maintained coherency count does not match the coherency count received in the compressed packet or if the decompressor detects that a received packet is corrupted, the decompressor drops the packet and sends a CCP Reset-Request packet. The compressor on receiving this packet resets the history buffer and sets the PACKET_FLUSHED bit in the next frame it sends. The decompressor on receiving a packet with its PACKET_FLUSHED bit set, resets its history buffer and sets its coherency count to the one shipped by the compressor in that packet.
パケットは転送の間、失われるかもしれません。 減圧装置の維持された一貫性カウントが圧縮されたパケットで受けられた一貫性カウントに合っていないか、または減圧装置がそれを検出するなら容認されたパケットが崩壊するなら、減圧装置は、パケットを落として、CCP Reset-リクエスト・パケットを送ります。 このパケットを受けるときのコンプレッサーは、歴史バッファをリセットして、それが送る隣のフレームにPACKET_FLUSHEDビットをはめ込みます。 PACKET_FLUSHEDビットでパケットを受けるときの減圧装置は、そのパケットでコンプレッサーによって出荷されたものに、セットして、歴史バッファをリセットして、一貫性カウントを設定します。
Thus synchronization is achieved without a Reset-Ack packet.
したがって、同期はReset-Ackパケットなしで達成されます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Friend & Simpson Informational [Page 19] RFC 1974 Stac LZS August 1996
友人とシンプソン情報[19ページ]のRFC1974Stac LZS1996年8月
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, July 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年7月の[2]底ならし革。
[3] Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
Data Compression", IEEE Transactions On Information Theory,
Vol. IT-23, No. 3, May 1977.
[3] LempelとA.とZiv、J.、「連続したデータ圧縮のための普遍的なアルゴリズム」、情報理論におけるIEEE取引、Vol.IT-23(No.3)は1977がそうするかもしれません。
[4] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
1994.
[4] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、ノベル、1994年7月。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl F. Fox
Ascend Communications
3518 Riverside Dr., Suite 101
Columbus, Ohio 43221
カールF.フォックスはオハイオ コミュニケーション3518リバーサイド博士、Suite101コロンブス、43221を昇ります。
(614) 451-1883
(614) 451-1883
EMail: karl@ascend.Com
メール: karl@ascend.Com
Authors' Addresses
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Robert Friend
Stac Technology
12636 High Bluff Drive
San Diego, CA 92130
(619) 794-4542
EMail: rfriend@stac.com
高い切り立っているDriveサンディエゴ、ロバート友人Stac Technology12636カリフォルニア92130(619)794-4542はメールされます: rfriend@stac.com
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com (preferred)
ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、ミシガン48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com(都合のよい)です。
Friend & Simpson Informational [Page 20]
友人とシンプソンInformationalです。[20ページ]
一覧
スポンサーリンク
