RFC1962 日本語訳
1962 The PPP Compression Control Protocol (CCP). D. Rand. June 1996. (Format: TXT=18005 bytes) (Updated by RFC2153) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
Network Working Group D. Rand
Request for Comments: 1962 Novell
Category: Standards Track June 1996
The PPP Compression Control Protocol (CCP)
PPP 圧縮制御プロトコル (CCP)
Status of this Memo
このメモの位置づけ
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書は、Internet community のための Internet standards track
protocol を明細に記述し、改良のための討議と提案を要求する。このプロ
トコルの標準化状態とステータスについては、"Internet Official
Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの
配布は、無制限である。
-----------------------------------------------------------------------
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
also defines an extensible Link Control Protocol.
Point-to-Point Protocol (PPP) [1] は、point-to-point リンク上でマル
チプロトコルデータグラムを運ぶための標準方式を提供する。PPP は、拡張
可能な Link Control Protocol も定義する。
This document defines a method for negotiating data compression over
PPP links.
この文書は、PPP リンク上で、データ圧縮を取り決めるための方式を定義す
る。
-----------------------------------------------------------------------
Table of Contents
目次
1. Introduction .......................................... 1
2. Compression Control Protocol (CCP) .................... 2
2.1 Sending Compressed Datagrams .................... 3
3. Additional Packets .................................... 4
3.1 Reset-Request and Reset-Ack ..................... 4
4. CCP Configuration Options ............................. 5
4.1 Proprietary Compression OUI ..................... 7
4.2 Other Compression Types ......................... 8
SECURITY CONSIDERATIONS ...................................... 9
REFERENCES ................................................... 9
ACKNOWLEDGEMENTS ............................................. 9
CHAIR'S ADDRESS .............................................. 9
AUTHOR'S ADDRESS ............................................. 9
1. 序論 .................................................. 1
2. 圧縮制御プロトコル (CCP) .............................. 2
2.1 圧縮されたデータグラムの送信 .................... 3
3. 追加のパケット ........................................ 4
3.1 Reset-Request と Reset-Ack ...................... 4
4. CCP 構成オプション .................................... 5
4.1 専売の圧縮 OUI .................................. 7
4.2 その他の圧縮タイプ .............................. 8
セキュリティに関する考察 ..................................... 9
参考文献 ..................................................... 9
謝辞 ......................................................... 9
議長のアドレス ............................................... 9
著者のアドレス ............................................... 9
-----------------------------------------------------------------------
1. Introduction
1. 序論
In order to establish communications over a PPP link, each end of the
link must first send LCP packets to configure and test the data link
during Link Establishment phase. After the link has been
established, optional facilities may be negotiated as needed.
PPP リンク上で通信を確立するために、それぞれリンクの終端は、Link
Establishment フェーズの間、データリンクを設定しテストするための LCP
パケットを最初に送信しなければならない。リンクが確立された後で、オプ
ション手段は、必要なら取り決められるかもしれない。
One such facility is data compression. A wide variety of compression
methods may be negotiated, although typically only one method is used
in each direction of the link.
そのような手段の 1 つは、データ圧縮である。リンクのそれぞれの方向で
典型的にたった 1 つの方式のみが使用されるけれども、広範囲にわたるさ
まざまな圧縮方式は取り決められるかもしれない。
A different compression algorithm may be negotiated in each
direction, for speed, cost, memory or other considerations, or only
one direction may be compressed.
異なった圧縮アルゴリズムは、それぞれの方向で取り決められるかもしれな
い。これは、スピード、コスト、メモリまたは他の考慮すべきことによって
である。そうでなければ、片方向のみが圧縮されるかもしれない。
-----------------------------------------------------------------------
2. Compression Control Protocol (CCP)
2. 圧縮制御プロトコル (CCP)
The Compression Control Protocol (CCP) is responsible for
configuring, enabling, and disabling data compression algorithms on
both ends of the point-to-point link. It is also used to signal a
failure of the compression/decompression mechanism in a reliable
manner.
Compression Control Protocol (CCP) は、point-to-point リンクの両端で
データ圧縮アルゴリズムを設定、可能、不可能にすることに責任がある。こ
れは、信頼できる方法で圧縮/伸長メカニズム失敗の証拠となるためにも使
用される。
CCP uses the same packet exchange mechanism as the Link Control
Protocol (LCP). CCP packets may not be exchanged until PPP has
reached the Network-Layer Protocol phase. CCP packets received
before this phase is reached should be silently discarded.
CCP は、Link Control Protocol (LCP) と同じパケット交換メカニズムを使
用する。PPP が Network-Layer Protocol フェーズに達するときまで、CCP
パケットは交換されないかもしれない。このフェーズが達せられる前に受信
された CCP パケットは、黙って廃棄されるべきである。
The Compression Control Protocol is exactly the same as the Link
Control Protocol [1] with the following exceptions:
Compression Control Protocol は、次に述べる例外とともに Link Control
Protocol [1] と厳密に同じである。
Frame Modifications
フレーム変更
The packet may utilize any modifications to the basic frame format
which have been negotiated during the Link Establishment phase.
パケットは、基本フレーム形式へのどんな変更をも利用するかもしれな
い。基本フレーム形式は、Link Establishment フェーズの間に取り決め
られている。
Data Link Layer Protocol Field
データリンク層プロトコルフィールド
Exactly one CCP packet is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type hex 80FD
(Compression Control Protocol).
厳密に、ある CCP は PPP Information フィールド内でカプセル化され
る。そして PPP Protocol フィールドは、16 進数でタイプ 80FD
(Compression Control Protocol) を指し示す。
When individual link data compression is used in a multiple link
connection to a single destination, the PPP Protocol field
indicates type hex 80FB (Individual link Compression Control
Protocol).
個々のリンクデータ圧縮が単一終点への複数リンクコネクションで使用
される時、PPP Protocol フィールドは 16 進数でタイプ 80FB
(Individual link Compression Control Protocol) を指し示す。
Code field
コードフィールド
In addition to Codes 1 through 7 (Configure-Request, Configure-
Ack, Configure-Nak, Configure-Reject, Terminate-Request,
Terminate-Ack and Code-Reject), two additional Codes 14 and 15
(Reset-Request and Reset-Ack) are defined for this protocol.
Other Codes should be treated as unrecognized and should result in
Code-Rejects.
コード 1 から 7 (Configure-Request, Configure-Ack, Configure-
Nak, Configure-Reject, Terminate-Request, Terminate-Ack と Code-
Reject) に加えて、2 つの追加コード 14 と 15 (Reset-Request と
Reset-Ack) がこのプロトコルのために定義される。他のコードは認識不
可能であるとして扱われるべきであり、そして Code-Rejects という結
果になるべきである。
Timeouts
タイムアウト
CCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation should be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time.
PPP が Network-Layer Protocol フェーズに達するまで、CCP パケット
は交換されないかもしれない。実装は、Configure-Ack や他の応答待ち
がタイムアウトする前に終わる Authentication と Link Quality
Determination を待つように準備されるべきである。これは、ユーザ介
入や設定可能な合計時間の後でのみ、実装はあきらめると示唆される。
Configuration Option Types
設定オプションタイプ
CCP has a distinct set of Configuration Options.
CCP は、Configuration Options の明確なセットを持つ。
2.1. Sending Compressed Datagrams
2.1. 圧縮されたデータグラムの送信
Before any compressed packets may be communicated, PPP must reach the
Network-Layer Protocol phase, and the Compression Control Protocol
must reach the Opened state.
なんらかの圧縮されたパケットが伝達されるかもしれない (という状態の)
その前に、PPP は Network-Layer Protocol フェーズに達していなければな
らなく、そして Compression Control Protocol は Opened (開かれた) 状
態に達していなければならない。
One or more compressed packets are encapsulated in the PPP
Information field, where the PPP Protocol field indicates type hex
00FD (Compressed datagram). Each of the compression algorithms may
use a different mechanism to indicate the inclusion of more than one
uncompressed packet in a single Data Link Layer frame.
1 つか、さらに多くの圧縮されたパケットは、PPP Information フィールド
内にカプセル化される。そして PPP Protocol フィールドは、16 進数でタ
イプ 00FD (Compressed datagram) を指し示す。圧縮アルゴリズムのそれぞ
れは、単一 Data Link Layer フレーム中の 2 つ以上の圧縮されないパケッ
ト包含を指し示すために異なったメカニズムを使用するかもしれない。
When using multiple PPP links to a single destination, there are two
methods of employing data compression. The first method is to
compress the data prior to sending it out through the multiple links.
The second is to treat each link as a separate connection, that may
or may not have compression enabled. In the second case, the PPP
Protocol field MUST be type hex 00FB (Individual link compressed
datagram).
単一終点へと複数の PPP リンクを使用する時、データ圧縮を使用する 2 つ
の方法がある。最初の方法は、複数リンクを通してデータを外へと送信する
より前に、データを圧縮することである。2 つめは、独立したコネクション
として、それぞれのリンクを扱うことである。この独立したコネクションは
圧縮が可能であるかもしれないし、可能でないかもしれない。2 つめのケー
スで、PPP Protocol フィールドは、16 進数でタイプ 00FB (Individual
link compressed datagram) でなければならない (MUST)。
Only one primary algorithm in each direction is in use at a time, and
that is negotiated prior to sending the first compressed frame. The
PPP Protocol field of the compressed datagram indicates that the
frame is compressed, but not the algorithm with which it was
compressed.
それぞれの方向での、ある主要なアルゴリズムのみがその時点で使用されて
いる。そしてそれは、最初の圧縮されたフレームを送信するより前に取り決
められる。圧縮されたデータグラムの PPP Protocol フィールドは、フレー
ムが圧縮されたことを指し示す。しかしそのフィールドは、フレームが圧縮
されるのに使用したアルゴリズムを指し示さない。
The maximum length of a compressed packet transmitted over a PPP link
is the same as the maximum length of the Information field of a PPP
encapsulated packet. Larger datagrams (presumably the result of the
compression algorithm increasing the size of the message in some
cases) may be sent uncompressed, using its standard form, or may be
sent in multiple datagrams, if the compression algorithm supports it.
PPP リンク上で転送される圧縮されたパケットの最大長は、PPP のカプセル
化されたパケットの Information フィールドの最大長と同じである。より
大きいデータグラム (たぶん一部のケースで、メッセージサイズを増加する
圧縮アルゴリズムの結果) は、標準形式を使用して、圧縮されずに送信され
るかもしれない。もしくは、複数データグラムで送信されるかもしれない。
これは、その圧縮アルゴリズムが複数データに関してサポートする場合であ
る。
Each of the compression algorithms must supply a way of determining
if they are passing data reliably, or they must require the use of a
reliable transport such as LAPB [3]. Vendors are strongly encouraged
to employ a method of validating the compressed data, or recognizing
out-of-sync compressor/decompressor pairs.
圧縮アルゴリズムのそれぞれは、それら圧縮アルゴリズムが確実にデータを
渡すかどうか決定する方法を供給しなければならない。または圧縮アルゴリ
ズムのそれぞれは、LAPB [3] のような信頼できるトランスポートの使用を
必要としなければならない。圧縮されたデータが有効か確認、または out-
of-sync (同期なし) 圧縮/伸長器ペアを認める方法の使用を、ベンダは強く
奨励される。
-----------------------------------------------------------------------
3. Additional Packets
3. 追加のパケット
The Packet format and basic facilities are already defined for LCP
[1].
Packet 形式と基本手段は、LCP [1] のために、すでに定義される。
Up-to-date values of the CCP Code field are specified in the most
recent "Assigned Numbers" RFC [2]. This specification concerns the
following values:
CCP Code フィールドの最新値は、最も最近の "Assigned Numbers" RFC [2]
で明細に述べられる。この仕様書は、次の値に関することである:
14 Reset-Request
15 Reset-Ack
3.1. Reset-Request and Reset-Ack
3.1. Reset-Request と Reset-Ack
Description
記述
CCP includes Reset-Request and Reset-Ack Codes in order to provide
a mechanism for indicating a decompression failure in one
direction of a compressed link without affecting traffic in the
other direction. A decompression failure may be determined by
periodically passing a hash value, performing a CRC check on the
decompressed data, or other mechanism. It is strongly suggested
that some mechanism be available in all compression algorithms to
validate the decompressed data before passing the data on to the
rest of the system.
他方向への traffic に影響することなしに、圧縮されるリンク片方向の
伸長失敗を指し示すメカニズムを提供するために、CCP は Reset-
Request と Reset-Ack コードを含む。伸長失敗は、2 つの方法により確
定されるかもしれない。それは、伸長されるデータの CRC チェックをお
こなってハッシュ値を定期的に渡すか、もしくは他のメカニズムによる
方法である。これは、システムの残り (の部分) へデータを渡す前に、
伸長されるデータが有効であるか確認するため、あるメカニズムがすべ
ての圧縮アルゴリズムで利用可能であることを強く勧められる。
A CCP implementation wishing to indicate a decompression failure
SHOULD transmit a CCP packet with the Code field set to 14
(Reset-Request), and the Data field filled with any desired data.
Once a Reset-Request has been sent, any Compressed packets
received are discarded, and another Reset-Request is sent with the
same Identifier, until a valid Reset-Ack is received.
伸長失敗を指し示すことを望む CCP 実装は、次に述べる情報を持つ CCP
パケットを転送すべきである (SHOULD)。その情報とは、14 (Reset-
Request) にセットされた Code フィールドと、なんらかの望まれたデー
タで満たされた Data フィールドである。いったん Reset-Request が送
信されると、受信されるどんな Compressed (圧縮された) パケットも廃
棄される。そして有効な Reset-Ack が受信されるまで、他の Reset-
Request は、同じ Identifier とともに送信される。
Upon reception of a Reset-Request, the transmitting compressor is
reset to an initial state. This may include clearing a
dictionary, resetting hash codes, or other mechanisms. A CCP
packet MUST be transmitted with the Code field set to 15 (Reset-
Ack), the Identifier field copied from the Reset-Request packet,
and the Data field filled with any desired data.
Reset-Request 受信の上で、転送する圧縮器 (圧縮モジュール) は、初
期状態にリセットされる。これは、辞書のクリア、ハッシュコードのリ
セットや他のメカニズムを含むだろう。CCP パケットは、次に述べる情
報とともに転送されなければならない (MUST)。その情報とは、15
(Reset-Ack) にセットされた Code フィールドと、その Reset-Request
パケットからコピーされた Identifier フィールドとなんらかの望まれ
たデータで満たされた Data フィールドである。
On receipt of a Reset-Ack, the receiving decompressor is reset to
an initial state. This may include clearing a dictionary,
resetting hash codes, or other mechanisms. Since there may be
several Reset-Acks in the pipe, the decompressor MUST be reset for
each Reset-Ack which matches the currently expected identifier.
Reset-Ack 受信の上で、受信する伸長器 (伸長モジュール) は、初期状
態にリセットされる。これは、辞書のクリア、ハッシュコードのリセッ
トや他のメカニズムを含むだろう。パイプ中にいくつもの Reset-Acks
があるかもしれないので、伸長器は、それぞれの Reset-Ack のためにリ
セットされなければならない (MUST)。この Reset-Ack は、現在期待さ
れた識別子にマッチするものである。
A summary of the Reset-Request and Reset-Ack packet formats is shown
below. The fields are transmitted from left to right.
Reset-Request と 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;
Reset-Request のための値 14
15 for Reset-Ack.
Reset-Ack のための値 15
Identifier
識別子
On transmission, the Identifier field MUST be changed whenever the
content of the Data field changes, and whenever a valid reply has
been received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
転送の上で、Data フィールドの中身が変わるたびに、かつ有効な reply
が前の request に対して受信されるたびに、Identifier フィールドは
変更されなければならない (MUST)。再送のために、Identifier は変更
されないままかもしれない (MAY)。
On reception, the Identifier field of the Reset-Request is copied
into the Identifier field of the Reset-Ack packet.
受信の上で、Reset-Request の Identifier フィールドは、Reset-Ack
パケットの Identifier フィールドにコピーされる。
Data
データ
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the peer's established
MRU minus four.
Data フィールドは、zero または多くの octets である。そして、その
フィールドは、送信側により使用する解釈されないデータを含む。この
データは、なんらかの binary 値からなる。そしてその長さは、zero か
ら、peer の確立された MRU に 4 を引いた値の間のどんな長さからでも
成るだろう。
訳注) 4 を引くという部分の説明で、4 とは、上の図で Code,
Identifier と Length の合計長 4 octets のことを言う。
-----------------------------------------------------------------------
4. CCP Configuration Options
4. CCP 構成オプション
CCP Configuration Options allow negotiation of compression algorithms
and their parameters. CCP uses the same Configuration Option format
defined for LCP [1], with a separate set of Options.
CCP Configuration Options は、圧縮アルゴリズムとそれらのパラメータ取
り決めを与える。CCP は、別の Options セットを持つ、LCP [1] のために
定義された同じ Configuration Option 形式を使用する。
Configuration Options, in this protocol, indicate algorithms that the
receiver is willing or able to use to decompress data sent by the
sender. As a result, it is to be expected that systems will offer to
accept several algorithms, and negotiate a single one that will be
used.
このプロトコルで Configuration Options は、次に述べるアルゴリズムを
指し示す。そのアルゴリズムとは、送信側により送信されたデータを伸長す
るために、受信側が使用することを望んだり、または使用することが出来る
ものである。結果として、次のことが期待される。それは、いくつかのアル
ゴリズムを受け入れ、使用されるだろう単一のアルゴリズムを取り決めるこ
とを、システムが提供することである。
There is the possibility of not being able to agree on a compression
algorithm. In that case, no compression will be used, and the link
will continue to operate without compression. If link reliability
has been separately negotiated, then it will continue to be used,
until the LCP is re-negotiated.
ある圧縮アルゴリズムに同意出来ない可能性がある。このケースで、圧縮は
使用されることはない。そしてそのリンクは、圧縮なしに処理し続けるだろ
う。もしリンク信頼性が別々に取り決められるなら、その後 LCP が再び取
り決められるまで、これ (リンク信頼性) は使用され続けるだろう。
We expect that many vendors will want to use proprietary compression
algorithms, and have made a mechanism available to negotiate these
without encumbering the Internet Assigned Number Authority with
proprietary number requests.
われわれは、次のことを期待する。それは多くのベンダが、専売圧縮アルゴ
リズムを使用することを望んだり、専売値要請を持つ Internet Assigned
Number Authority を妨げることなしに、これらを取り決めるために利用可
能なメカニズムを構成することである。
The LCP option negotiation techniques are used. If an option is
unrecognized, a Configure-Reject MUST be sent. If all protocols the
sender implements are Configure-Rejected by the receiver, then no
compression is enabled in that direction of the link.
LCP オプション取り決め技術は、使用される。もしオプションが認められな
いなら、Configure-Reject は送信されなければならない (MUST)。もし送信
側が実装するすべてのプロトコルが受信側により Configure-Rejected とな
るなら、それから圧縮はリンクのその方向で可能にならない。
If an option is recognized, but not acceptable due to values in the
request (or optional parameters not in the request), a Configure-NAK
MUST be sent with the option modified appropriately. The Configure-
NAK MUST contain only those options that will be acceptable. A new
Configure-Request SHOULD be sent with only the single preferred
option, adjusted as specified in the Configure-Nak.
もしオプションは認められるが request (もしくはその request 内にない
オプションパラメータ) での値のために受理可能でないなら、Configure-
NAK は、適切な方法で変更されたオプションとともに送信されなければなら
ない (MUST)。その Configure-NAK は、受理可能なそれらオプションのみを
含まなければならない (MUST)。新しい Configure-Request は、Configure-
NAK で特定されるとして適合する、単一の好まれるオプションのみとともに
送信されるべきである (SHOULD)。
Up-to-date values of the CCP Option Type field are specified in the
most recent "Assigned Numbers" RFC [2]. Current values are assigned
as follows:
CCP Option Type フィールドの最新値は、最も最近の "Assigned Numbers"
RFC [2] で明細に述べられる。現在の値は、次の通りに割り当てられる:
CCP Option Compression type
0 OUI
1 Predictor type 1
2 Predictor type 2
3 Puddle Jumper
4-15 unassigned
16 Hewlett-Packard PPC
17 Stac Electronics LZS
18 Microsoft PPC
19 Gandalf FZA
20 V.42bis compression
21 BSD LZW Compress
255 Reserved
The unassigned values 4-15 are intended to be assigned to other
freely available compression algorithms that have no license fees.
割り当てられていない値 4-15 は、他の圧縮アルゴリズムへと割り当て
られるために意図される。それらの圧縮アルゴリズムは、自由に利用可
能で、ライセンス料がないのをいう。
4.1. Proprietary Compression OUI
4.1. 専売の圧縮 OUI
Description
記述
This Configuration Option provides a way to negotiate the use of a
proprietary compression protocol.
この Configuration Option は、専売圧縮プロトコル使用を取り決める
ための方法を提供する。
Since the first matching compression will be used, it is
recommended that any known OUI compression options be transmitted
first, before the common options are used.
最初にマッチした圧縮が使用されるので、共通オプションが使用される
前に、なんらかの知られた OUI 圧縮オプションが最初に転送されること
が推奨される。
Before accepting this option, the implementation must verify that
the Organization Unique Identifier identifies a proprietary
algorithm that the implementation can decompress, and that any
vendor specific negotiation values are fully understood.
このオプションを受理する前に、実装は次のことを確かめなければなら
ない。それは、実装が伸長処理できる専売アルゴリズムを Organization
Unique Identifier が識別することと、どんなベンダにおいても特定の
取り決め値が完全に理解されることを確かめることである。
A summary of the Proprietary Compression OUI Configuration Option
format is shown below. The fields are transmitted from left to
right.
Proprietary Compression OUI 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 | OUI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OUI | Subtype | Values...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| タイプ | 長さ | OUI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OUI | サブタイプ | 値...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
0
値 0
Length
長さ
>= 6
6 以上
IEEE OUI
IEEE 組織一意識別子
The vendor's IEEE Organization Unique Identifier (OUI), which is
the most significant three octets of an Ethernet Physical Address,
assigned to the vendor by IEEE 802. This identifies the option as
being proprietary to the indicated vendor. The bits within the
octet are in canonical order, and the most significant octet is
transmitted first.
これは、ベンダの (持つ) IEEE Organization Unique Identifier (OUI)
である。この OUI は、IEEE 802 によりベンダへと割り当てられた
Ethernet Physical Address の上位 3 octets である。これは、指し示
されたベンダに対して所有者であるとのオプションを指し示す。octets
内の bits は、正式の順序である。そして、最上位 octets は最初に転
送される。
訳注) canonical order とは、次のことであると思われる。
b7b6b5b4b3b2b1b0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----
| 1 octet | 2 octet | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----
すなわち、octet 内の bit 番号は右から左へと増えていくこ
とを言っているのだと思われる。
Subtype
サブタイプ
This field is specific to each OUI, and indicates a compression
type for that OUI. There is no standardization for this field.
Each OUI implements its own values.
このフィールドは、それぞれの OUI への詳細であり、その OUI のため
の圧縮タイプを指し示す。このフィールドのための標準は存在しない。
それぞれの OUI は、それ自身の値を実装する。
Values
値
This field is zero or more octets, and contains additional data as
determined by the vendor's compression protocol.
このフィールドは、zero または多くの octets である。このフィールド
は、ベンダの圧縮プロトコルにより決定されるとして追加のデータを含
む。
4.2. Other Compression Types
4.2. 他の圧縮タイプ
Description
記述
These Configuration Options provide a way to negotiate the use of
a publicly defined compression algorithm. Many compression
algorithms are specified. No particular compression technique has
arisen as an Internet Standard.
これら Configuration Options は、公開して定義された圧縮アルゴリズ
ムの使用を取り決めるための方法を提供する。多くの圧縮アルゴリズム
は、具体的に挙げられる。特定の圧縮技術は、Internet Standard とし
て現れることはない。
These protocols will be made available to all interested parties,
but may have certain licensing restrictions associated with them.
For additional information, refer to the compression protocol
documents that define each of the compression types.
これらのプロトコルは、すべての関係ある (通信している) パーティに
利用可能とさせる。しかしこれらのプロトコルは、それらと関連される
特定のライセンス制限を持つかもしれない。追加の情報については、圧
縮タイプのそれぞれを定義する圧縮プロトコル文書を参照しなさい。
A summary of the Compression Type Configuration Option format is
shown below. The fields are transmitted from left to right.
Compression Type 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 | Values...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
タイプ
1 to 254
1 から 254
Length
長さ
>= 2
2 以上
Values
値
This field is zero or more octets, and contains additional data as
determined by the compression protocol.
このフィールドは、zero か多くの octets である。そしてこのフィール
ドは、圧縮プロトコルにより決定されるとして、追加のデータを含む。
-----------------------------------------------------------------------
Security Considerations
セキュリティに関する考察
Security issues are not discussed in this memo.
セキュリティ問題は、このメモで論じられない。
-----------------------------------------------------------------------
References
参考文献
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[3] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
-----------------------------------------------------------------------
Acknowledgments
謝辞
Bill Simpson helped with the document formatting.
Bill Simpson は、この文書形式を手伝ってくれた。
-----------------------------------------------------------------------
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
working group は、現在の議長を通して連絡されてもよい:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.com
-----------------------------------------------------------------------
Author's Address
著者のアドレス
Questions about this memo can also be directed to:
このメモに関する質問は、(次のアドレスへと) 聞くこともできる:
Dave Rand
Novell, Inc.
2180 Fortune Drive
San Jose, CA 95131
+1 408 321-1259
EMail: dlr@daver.bungi.com
-----------------------------------------------------------------------
Copyright (C) The Internet Society (1996). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
一覧
スポンサーリンク
