RFC1553 日本語訳
1553 Compressing IPX Headers Over WAN Media (CIPX). S. Mathur, M.Lewis. December 1993. (Format: TXT=47450 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Mathur
Request for Comments: 1553 M. Lewis
Category: Standards Track Telebit Corporation
December 1993
コメントを求めるワーキンググループS.マートゥルの要求をネットワークでつないでください: 1553年のM.ルイスカテゴリ: 標準化過程テレビット社の1993年12月
Compressing IPX Headers Over WAN Media (CIPX)
青白いメディアの上にIPXヘッダーを圧縮します。(CIPX)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX can provide a compression ratio of approximately 2:1 including both IPX header and data. This method can be used on various type of WAN media, including those supporting PPP and X.25.
このドキュメントはIPXデータグラム(CIPX)のヘッダーを圧縮するためのメソッドを説明します。 このメソッドで、低い速度広域ネットワーク(WAN)メディアの上の性能をかなり向上させるのは可能です。 正常なIPXパケットトラフィックのために、CIPXはIPXヘッダーとデータの両方を含むおよそ2:1の圧縮比を提供できます。 PPPとX.25をサポートするものを含む様々なタイプのWANメディアでこのメソッドを使用できます。
This memo ia a product of the Point-to-Point Protocol Extensions (PPPEXT) Working Group of the IETF. Comments should be sent to the authors and the ietf-ppp@ucdavis.edu mailing list.
IETFのPointからポイントへのプロトコルExtensions(PPPEXT)作業部会のこのメモia a製品。 作者と ietf-ppp@ucdavis.edu メーリングリストにコメントを送るべきです。
Specification of Requirements
要件の仕様
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.
「必要である」というこの単語、または形容詞が、定義が仕様に関する絶対条件であることを意味します。
MUST NOT
必須NOT
This phrase means that the definition is an absolute
prohibition of the specification.
この句は、定義が仕様の絶対禁止であることを意味します。
Mathur & Lewis [Page 1] RFC 1553 CIPX December 1993
マートゥルとルイス[1ページ]RFC1553CIPX1993年12月
SHOULD
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 should be
understood and carefully weighed before choosing a
different course.
「推薦される」というこの単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意は、理解されて、異なったコースを選ぶ前に、慎重に熟慮されるべきです。
MAY
5月
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.
「任意である」というこの単語、または形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
Introduction
序論
Internetwork Packet Exchange (IPX) is a protocol defined by the Novell Corporation [1]. It is derived from the Internet Datagram Protocol (IDP) protocol of the Xerox Network Systems (XNS) family of protocols. IPX is a datagram, connectionless protocol that does not require an acknowledgment for each packet sent. The IPX protocol corresponds to the network layer of the ISO model.
インターネットワークPacket Exchange(IPX)はノベル社[1]によって定義されたプロトコルです。 プロトコルのゼロックスNetwork Systems(XNS)ファミリーのインターネットデータグラムプロトコル(IDP)プロトコルからそれを得ます。 IPXがデータグラムである、各パケットのための承認を必要としないコネクションレスプロトコルが発信しました。 IPXプロトコルはISOモデルのネットワーク層に対応しています。
Usually, there is a transport layer protocol above IPX. The most common transport protocol is the Netware Core Protocol (NCP), which is used for file server access. The Sequenced Packet Exchange (SPX) is the reliable connection-based transport protocol commonly used by applications.
通常、IPXの上にトランスポート層プロトコルがあります。 最も一般的なトランスポート・プロトコルはNetware Coreプロトコル(NCP)です。(そのプロトコルはファイルサーバーアクセサリーに使用されます)。 Sequenced Packet Exchange(SPX)はアプリケーションで一般的に使用される信頼できる接続ベースのトランスポート・プロトコルです。
The IPX packet consists of a 30 octet IPX header, usually followed by the transport layer protocol header. The NCP header is 6 octets in length. The SPX header is 12 octets in length.
IPXパケットは通常、トランスポート層プロトコルヘッダーによってついて来られた30八重奏IPXヘッダーから成ります。 NCPヘッダーは長さが6つの八重奏です。 SPXヘッダーは長さが12の八重奏です。
Two strategies are described below for compressing IPX headers. This specification requires that implementations of CIPX support both IPX header compression strategies. These header compression algorithms are based on those Van Jacobson described [2] for TCP/IP packets. The first strategy is to compress only the IPX header. This compression algorithm can be used to compress any IPX packet, without affecting the transport protocol. This algorithm compresses a 30 octet IPX header into a one to seven octet header.
2つの戦略が、IPXヘッダーを圧縮するために以下で説明されます。 この仕様は、CIPXの実装が両方のIPXヘッダー圧縮戦略をサポートするのを必要とします。 これらのヘッダー圧縮アルゴリズムはそれらに基づいてヴァン・ジェーコブソンがTCP/IPパケットのための[2]について説明したということです。 最初の戦略はIPXヘッダーだけを圧縮することです。 トランスポート・プロトコルに影響しないでどんなIPXパケットも圧縮するのにこの圧縮アルゴリズムを使用できます。 このアルゴリズムは1〜7八重奏ヘッダーに30八重奏IPXヘッダーを圧縮します。
The second strategy is to compress the combined IPX and NCP headers. This algorithm compresses only NCP packets with NCP type of 0x2222 and 0x3333. This algorithm compresses a 36 octet NCP/IPX
2番目の戦略は結合したIPXとNCPヘッダーを圧縮することです。 このアルゴリズムは0×2222と0×3333人のNCPタイプでNCPパケットだけを圧縮します。 このアルゴリズムは36八重奏NCP/IPXを圧縮します。
Mathur & Lewis [Page 2] RFC 1553 CIPX December 1993
マートゥルとルイス[2ページ]RFC1553CIPX1993年12月
header into a one to eight octet header.
1〜8八重奏ヘッダーへのヘッダー。
Lastly, it is possible and many times desirable, to use this type of header compression in conjunction with some type of data compression.
最後に、それは可能であり、何回も望ましいです、いくつかに関連したヘッダー圧縮のこのタイプがタイプするデータ圧縮の使用に。
Data compression technology takes many forms. Link bit stream compression is a common approach over very low speed asynchronous links, normally performed by modems transparently. Transparent bit stream compression is also offered in some DSUs, routers and bridges. Data compression can be provided using protocols such as CCITT V.42bis[3], MNP 5, Lempel-Ziv, or LAPB[4].
データ圧縮技術は多くの形を取ります。Linkビットストリーム圧縮は通常、モデムによって透過的に実行された低速非常に非同期なリンクの上の一般的なアプローチです。 また、いくつかのDSUs、ルータ、およびブリッジでわかりやすいビットストリーム圧縮を提供します。 CCITT V.42bis[3]、MNP5、Lempel-Ziv、またはLAPB[4]などのプロトコルを使用することでデータ圧縮を提供できます。
When using both header and data compression, the sequence of compression is important. When sending packets, data compression MUST be done after header compression. Conversely when receiving packets, data decompression MUST be done before header decompression.
ヘッダーとデータ圧縮の両方を使用するとき、圧縮の系列は重要です。 パケットを送るとき、ヘッダー圧縮の後にデータ圧縮をしなければなりません。 パケットを受けるとき、逆に、ヘッダー減圧の前にデータ伸長をしなければなりません。
IPX Compression Algorithm
IPX圧縮アルゴリズム
The normal IPX header consists of the following fields: checksum, packet length, transport control (hop count), packet type, destination and source address fields.
普通のIPXヘッダーは以下の分野から成ります: チェックサム、パケット長、輸送コントロール(ホップカウント)、パケットタイプ、目的地、およびソースは分野を扱います。
+-----------------------+
| Checksum |
+-----------------------+
| Packet Length |
+-----------+-----------+
| Hops |Packet Type|
+-----------+-----------+
| Destination |
| Address |
| (12 Octets) |
+-----------------------+
| Source |
| Address |
| (12 Octets) |
+-----------------------+
+-----------------------+ | チェックサム| +-----------------------+ | パケット長| +-----------+-----------+ | ホップス|パケットタイプ| +-----------+-----------+ | 目的地| | アドレス| | (12の八重奏) | +-----------------------+ | ソース| | アドレス| | (12の八重奏) | +-----------------------+
IPX PACKET HEADER
IPXパケットのヘッダー
The IPX header diagram above is shown without the field alignment details. Consider each field of the IPX header separately, and how it typically changes.
上のIPXヘッダーダイヤグラムは分野整列の詳細なしで見せられます。 ヘッダーは、IPXの各分野であると別々に考えます、そして、それは通常変化します。
Historically, Novell has not used the Checksum field in the IPX
歴史的に、ノベルはIPXのChecksum分野を使用していません。
Mathur & Lewis [Page 3] RFC 1553 CIPX December 1993
マートゥルとルイス[3ページ]RFC1553CIPX1993年12月
header, and has required that this field be set to 0xFFFF. Since the Checksum field remains constant, it is clear that the value can be compressed.
ヘッダー、この分野が0xFFFFに設定されるのが必要でした。 Checksum分野が一定のままで残っているので、値を圧縮できるのは明確です。
Where Checksums are implemented (not 0xFFFF), the Checksum MUST be included in the compressed packet. Recalculating the checksum would destroy the end-to-end reliability of the connection. Note that Checksums are now implemented in the Fault Tolerant Servers.
Checksumsが(0xFFFFでない)であると実装されるところでは、圧縮されたパケットにChecksumを含まなければなりません。 チェックサムをRecalculatingすると、終わりから終わりへの接続の信頼性は煙滅するでしょう。 Checksumsが現在Fault Tolerant Serversで実装されることに注意してください。
For most links, the Packet Length can be determined from the MAC layer. There are cases in which the length cannot be determined from the MAC layer. For example, some hardware devices pad packets to a required minimum length. For links where it is not possible to determine the IPX packet length from the MAC layer, packet length needs to be included in the compressed packet.
ほとんどのリンクに関しては、Packet LengthはMAC層から決定できます。 MAC層から長さを測定できない場合があります。 例えば、いくつかのハードウェアデバイスが必要な最小の長さにパケットを水増しします。 MAC層からIPXパケット長を測定するのが可能でないリンクに、パケット長は、圧縮されたパケットに含まれる必要があります。
The Transport Control (Hops) field usually does not change between two end-points. For the purposes of compression, we will assume that it never changes, and will not examine this field when determining a connection.
通常、Transport Control(ホップス)分野は2つのエンドポイントの間で変化しません。 圧縮の目的のために、私たちは、それが決して変化しないと思うつもりです、そして、接続を決定するとき、この分野を調べないでしょう。
The Packet Type field is constant for any connection.
どんな接続にも、Packet Type分野は一定です。
The Destination and Source Address fields are each made up of 12 octets: Network (4 octets), Node (6 octets), and Socket (2 octets) fields. An IPX connection is the logical association between two endpoints known by a given source and destination address pair. For any specific IPX connection, the Destination and Source Address fields are constant.
DestinationとSource Address分野は12の八重奏でそれぞれ作られます: (4つの八重奏)、Node(6つの八重奏)、およびSocket(2つの八重奏)分野をネットワークでつないでください。 IPX接続は与えられた情報筋と目的地アドレス組によって知られていた2つの終点の間の論理的な協会です。 どんな特定のIPX接続においても、DestinationとSource Address分野は一定です。
Hence, the fields that may need to be included in the compressed IPX header are the Checksum and the Packet Length.
したがって、圧縮されたIPXヘッダーに含まれる必要があるかもしれない分野は、ChecksumとPacket Lengthです。
While using this IPX header compression algorithm, packets can be lost. The loss of an Initial packet presents a problem. In this case, if the sender later tries to send a compressed packet, the receiving end cannot decompress the packet correctly.
このIPXヘッダー圧縮アルゴリズムを使用している間、パケットは失われる場合があります。 Initialパケットの損失は問題を提示します。 この場合、送付者が後で圧縮されたパケットを送ろうとするなら、犠牲者は正しくパケットを減圧できません。
Sufficient information is not available in the IPX header to determine when a re-transmission has occured. For this reason, it is necessary that the sender of an Initial packet be guaranteed that the packet has been received. Therefore, we provide a mechanism for Confirmation of an Initial packet.
再トランスミッションがいつoccuredされたかという十分な情報は決定するIPXヘッダーで利用可能ではありません。 この理由に、Initialパケットの送付者がパケットが受け取られたのが保証されるのが必要です。 したがって、私たちはInitialパケットのConfirmationにメカニズムを供給します。
NCP/IPX Header Compression
NCP/IPXヘッダー圧縮
Since most IPX packets are Netware Core Protocol packets (packet type 17), compressing the NCP header will give us added performance. A
ほとんどのIPXパケットがNetware Coreプロトコルパケット(パケットタイプ17)であるので、NCPヘッダーを圧縮すると、加えられた性能は私たちに与えられるでしょう。 A
Mathur & Lewis [Page 4] RFC 1553 CIPX December 1993
マートゥルとルイス[4ページ]RFC1553CIPX1993年12月
minimal CIPX implementation MUST also implement NCP/IPX compression.
また、最小量のCIPX実装は、NCP/IPXが圧縮であると実装しなければなりません。
+------------+
| NCP |
| Type |
+------------+
| Sequence |
| Number |
+------------+
| Connection |
|(low octet) |
+------------+
| Task |
| Number |
+------------+
| Connection |
|(high octet)|
+------------+
+------------+ | NCP| | タイプ| +------------+ | 系列| | 数| +------------+ | 接続| |(低い八重奏) | +------------+ | タスク| | 数| +------------+ | 接続| |(高い八重奏)| +------------+
NCP HEADER
NCPヘッダー
The NCP header is 6 octets in length consisting of the following fields: NCP type, sequence number, connection number and task number.
NCPヘッダーは以下の分野から成る長さが6つの八重奏です: NCPタイプ、一連番号、接続番号、およびタスク番号。
The NCP type field values that are currently defined are:
現在定義されるNCPタイプ分野値は以下の通りです。
1111 Create Connection
2222 NCP request from workstation
3333 NCP reply from file server
5555 Destroy Connection
7777 Burst Mode Packet
9999 Server Busy Packet
1111はワークステーション3333NCP回答からファイルサーバー5555Destroy Connection7777Burst Mode Packet9999Server Busy PacketからConnection2222NCP要求を作成します。
This NCP header compression algorithm only compresses packets that have a type field value of 0x2222 or 0x3333. If the NCP type is 0x2222, this packet is a request from the client to the server. Conversely if the NCP type is 0x3333, this is a response from the server to the client. All other types of NCP packets are not compressed at the NCP level, but are compressed at the IPX level. The Create Connection (0x111), Destroy Connection (0x5555) and Server Busy (0x9999) packets are not exchanged frequently enough to justify special NCP compression. The Burst Mode (0x7777) packet is discussed below.
このNCPヘッダー圧縮アルゴリズムは0×2222か0×3333のタイプ分野価値を持っているパケットを圧縮するだけです。 NCPタイプが0×2222であるなら、クライアントからサーバまでこのパケットは要求です。逆に、NCPタイプが0×3333であるなら、サーバからクライアントまでこれは応答です。 他のすべてのタイプのNCPパケットは、NCPレベルでは圧縮されませんが、IPXレベルで圧縮されます。 Create Connection(0×111)、Destroy Connection(0×5555)、およびServer Busy(0×9999)パケットは特別なNCP圧縮を正当化できるくらいの頻繁に交換されません。 以下でBurst Mode(0×7777)パケットについて議論します。
The connection number is a constant for a given connection.
接続番号は与えられた接続のための定数です。
The sequence number is increased by one for each new request. Hence the sequence number can be determined implicitly. The decompressor
一連番号はそれぞれの新しい要求あたり1つ増強されます。 したがって、それとなく一連番号を測定できます。 減圧装置
Mathur & Lewis [Page 5] RFC 1553 CIPX December 1993
マートゥルとルイス[5ページ]RFC1553CIPX1993年12月
increments the sequence number for each compressed packet it receives for a connection.
それが接続のために受けるそれぞれの圧縮されたパケットのために一連番号を増加します。
The task number can change unpredictably, although it might remain constant for several packets. If the NCP task number is different from the last one for this connection, the NCP task number must be included.
いくつかのパケットに一定のままで残るかもしれませんが、タスク番号は予想外に変化できます。 この接続において、NCPタスク番号が最後のものと異なるなら、NCPタスク番号を含まなければなりません。
If the NCP packet is lost, it will be retransmitted through the normal transport layer mechanisms. The Initial NCP packet does not require confirmation, as a re-transmitted packet can be easily identified. This is accomplished by comparing the sequence number of the packet to the sequence number of the previous packet. If the sequence number is not exactly one greater than the previous packet, a new Initial packet must be sent, although the same connection slot may be used.
NCPパケットが無くなると、それは正常なトランスポート層メカニズムを通して再送されるでしょう。Initial NCPパケットは確認を必要としません、容易に再送されたパケットを特定できるとき。 これは、前のパケットの一連番号にパケットの一連番号をたとえることによって、達成されます。 一連番号がまさに前のパケットよりすばらしい1つでないなら、新しいInitialパケットを送らなければなりません、同じ接続スロットは使用されるかもしれませんが。
In the event of compressed packet loss, the sequence number will be too small. When the IPX Checksum is present, the loss can be determined at the destination system by an incorrect checksum. When there is no checksum present, the loss is more likely to be detected upon receiving a later retransmission.
圧縮されたパケット損失の場合、一連番号はわずかになり過ぎるでしょう。 IPX Checksumが存在しているとき、損失は目的地システムで不正確なチェックサムで決定できます。 後の「再-トランスミッション」を受けるとき、どんな存在しているチェックサムもないとき、損失は、より検出されそうです。
NCP Burst Mode Packets
NCPバーストモードパケット
The burst mode protocol uses the NCP type value of 0x7777. This type of packet does not have the normal NCP header described above. Instead, it has a 36 octet burst header. The above NCP header compression algorithm should not be used to compress this packet. The IPX header in this packet is still compressible with the IPX header compression algorithm described.
バーストモードプロトコルは0×7777のNCPタイプ価値を使用します。 このタイプのパケットで、上で普通のNCPヘッダーについて説明しません。 代わりに、それには、36八重奏炸裂ヘッダーがあります。 このパケットを圧縮するのに上のNCPヘッダー圧縮アルゴリズムを使用するべきではありません。 IPXヘッダー圧縮アルゴリズムが説明されている状態で、このパケットのIPXヘッダーはまだ圧縮性です。
SPX Packets
SPXパケット
SPX packets are typically used by applications which require
reliable service such as print servers. It is possible to apply a
similar NCP/IPX technique to SPX/IPX packets. At this time, we
have not described such a mechanism. The IPX header in this
packet is still compressible with the IPX header compression
algorithm described.
SPXパケットはプリント・サーバなどの信頼できるサービスを必要とするアプリケーションで通常使用されます。 SPX/IPXパケットへの同様のNCP/IPXのテクニックを適用するのは可能です。 このとき、私たちはそのようなメカニズムについて説明していません。 IPXヘッダー圧縮アルゴリズムが説明されている状態で、このパケットのIPXヘッダーはまだ圧縮性です。
Compression Header
圧縮ヘッダー
IPX compression should be negotiated by some means (eg. IPXCP or
IPXWAN). Each end must negotiate the desired options, such as the
maximum number of concurrent connections which will be maintained
in each direction. Once IPX compression is negotiated, all IPX
packets sent over that link have a CIPX header added to the
IPX圧縮はどうでも(例えば、IPXCPかIPXWAN)交渉されるべきです。 各端は希望のオプションを交渉しなければなりません、各方向に維持される同時接続の最大数などのように。 IPX圧縮がいったん交渉されると、リンクされる移動されたすべてのIPXパケットで、CIPXヘッダーを加えます。
Mathur & Lewis [Page 6] RFC 1553 CIPX December 1993
マートゥルとルイス[6ページ]RFC1553CIPX1993年12月
beginning of the packet. The CIPX header is variable in length.
パケットの始まり。 CIPXヘッダーは長さで可変です。
The one octet CIPX header is added even when a regular IPX packet
is sent over the link. By including the CIPX header on every
packet, we support the ability to run CIPX over various WAN links
as if it were a normal IPX packet. It does not rely on any new
link specific packet demultiplexing.
レギュラーのIPXパケットをリンクの上に送るときさえ、1個の八重奏CIPXヘッダーを加えます。 あらゆるパケットの上のCIPXヘッダーを含んでいることによって、私たちはまるでそれが正常なIPXパケットであるかのように様々なWANリンクの上にCIPXを実行する能力をサポートします。 それはどんな新しいリンク特定のパケット逆多重化も当てにしません。
Implementations of this compression protocol must maintain send
and receive tables indicating the state of each connection. The
original header for each connection is stored in a "slot".
Typically, each client-server connection will use a separate slot.
Both sides keep a copy of the full IPX header corresponding to
each slot. The sending side (compressor) uses this information to
determine the fields that have changed. The receiving side
(decompressor) uses this information to reconstruct the original
packet header.
この圧縮プロトコルの実現はそれぞれの接続の状態を示すテーブルを送って、受けるように主張しなければなりません。 各接続のためのオリジナルのヘッダーは「スロット」に格納されます。 通常、それぞれのクライアント/サーバ接続は別々のスロットを使用するでしょう。 両側は完全なIPXヘッダーの写しを各スロットに対応していることへ取っておきます。 送付側(コンプレッサー)は、変化した分野を決定するのにこの情報を使用します。 受信サイド(減圧装置)は、オリジナルのパケットのヘッダーを再建するのにこの情報を使用します。
The CIPX packet header specifies the type of the packet and any
options for that packet. The minimum CIPX header is one octet in
length.
CIPXパケットのヘッダーはパケットのタイプとそのパケットのためのどんなオプションも指定します。 最小のCIPXヘッダーは長さが1つの八重奏です。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| | | | | | | | |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 0 Compressed
| | | | 1 Regular
| | | | 3 Confirmed Initial
| | | | 5 Confirm
| | | | 7 Unconfirmed Initial
| | | | 9 Reject
| | | | 11-15 Reserved
| | | |
|__ |__ |__ |___________________ Packet Type Dependent Flags
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | | | | | | | | | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | |___|___|___|___ パケットタイプ| | | | 圧縮された0| | | | 1人のレギュラー| | | | 3 初期で、確認されました。| | | | 5は確認します。| | | | 7の未確認のイニシャル| | | | 9廃棄物| | | | 11-15 予約されています。| | | | |__ |__ |__ |___________________ パケットのタイプの依存する旗
FLAGS OCTET
八重奏に旗を揚げさせます。
As can be seen above, the low order bits specify the packet type.
All Compressed packets have a lowest bit of zero. The other
packet types are odd numbers.
上を見ることができるように、下位のビットはパケットタイプを指定します。 すべてのCompressedパケットには、ゼロの最も低いビットがあります。 他のパケットタイプは奇数です。
Note that the Flags octet MUST NOT contain the value 0xFF. This
is necessary to distinguish the CIPX flags octet from a normal IPX
header with a 0xFFFF checksum field. It is important to be able
Flags八重奏が値の0xFFを含んではいけないことに注意してください。 これがCIPXを区別するのが0xFFFFチェックサム分野がある普通のIPXヘッダーから八重奏に旗を揚げさせるのが必要です。 できるのは重要です。
Mathur & Lewis [Page 7] RFC 1553 CIPX December 1993
マートゥルとルイス[7ページ]RFC1553CIPX1993年12月
to recognize a normal IPX header regardless of the state of
compression. It is possible with some link layer protocols such
as X.25 Permanent Virtual Circuits that one end of the link may
fail and start sending regular IPX packets without the CIPX
header. CIPX implementations MUST recognize this situation and
renegotiate the use of CIPX.
圧縮の状態にかかわらず普通のIPXヘッダーを見分けるために。 X.25 Permanent Virtual Circuitsなどのいくつかのリンクレイヤプロトコルでは、リンクのその片端が失敗して、CIPXヘッダーなしでレギュラーのIPXパケットを送り始めるのは、可能です。 CIPX実現は、この状況を認識して、CIPXの使用を再交渉しなければなりません。
Each packet type has associated flag bits, which are called Packet
Type Dependent Flags. Different packet types have different
Packet Type Dependent Flags. All bits that are reserved or are
not specified must be set to zero.
それぞれのパケットタイプには、関連フラグビットがあります。(フラグビットはPacket Type Dependent Flagsと呼ばれます)。 異なったパケットタイプは異なったPacket Type Dependent Flagsを持っています。 予約されているか、または指定されないすべてのビットをゼロに設定しなければなりません。
Since none of the packet types other than Compressed currently
uses any of the flag bits, the packet type field could easily be
expanded. Any future expansion must ensure that at least one of
the bits in the Flags octet remains zero so the value cannot be
0xFF.
Compressed以外のパケットタイプのだれも現在フラグビットのいずれも使用しないので、容易にパケットタイプ分野を広げることができました。 どんな今後の拡大も、少なくともFlags八重奏におけるビットの1つが値が0xFFであるはずがないためにゼロのままで残っているのを確実にしなければなりません。
Compressed Packet
圧縮されたパケット
This type of packet does not contain a packet header (either 30 byte IPX, or 36 byte NCP). A slot number indicates to the receiver which saved header to use to formulate the original packet header before passing the packet up to IPX.
このタイプのパケットはパケットのヘッダー(30バイトのIPXか36バイトのNCPのどちらか)を含みません。 スロット番号は、どれがパケットをIPXまで通過する前にオリジナルのパケットのヘッダーを定式化するのに使用するヘッダーを救ったかを受信機に示します。
Mathur & Lewis [Page 8] RFC 1553 CIPX December 1993
マートゥルとルイス[8ページ]RFC1553CIPX1993年12月
________________________________ Slot Number
| 0 Assume same as last packet
| 1 Included in packet
|
| ____________________________ Checksum
| | 0 Assume 0xFFFF
| | 1 Included in packet
| |
| | ________________________ Length
| | | 0 Determine from MAC length
| | | 1 Included in packet
| | |
| | | ____________________ Task Number (NCP only)
| | | | 0 Assume same as last packet
| | | | 1 Included in packet
| | | |
| | | | ________________ Reserved (Must be zero)
| | | | | | |
| | | | | | | ____ Packet Type
| | | | | | | | 0 Compressed Packet
v v v v v v v v
+---+---+---+---+---+---+---+---+
| | | | | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
7 6 5 4 3 2 1 0
________________________________ スロット番号| 0は、前回同様がパケットであると仮定します。| パケットに1を含んでいること。| | ____________________________ チェックサム| | 0は0xFFFFを仮定します。| | パケットに1を含んでいること。| | | | ________________________ 長さ| | | 0はMACから長さを測定します。| | | パケットに1を含んでいること。| | | | | | ____________________ タスクNumber(NCP専用)| | | | 0は、前回同様がパケットであると仮定します。| | | | パケットに1を含んでいること。| | | | | | | | ________________ 予約されます(ゼロでなければなりません)。| | | | | | | | | | | | | | ____ パケットタイプ| | | | | | | | 0 圧縮されたPacketのv v v v v v v対+---+---+---+---+---+---+---+---+ | | | | | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ 7 6 5 4 3 2 1 0
Consider each flag in the flags octet, looking at the high order bits working toward the lower order bits. Each of the fields is optional, but if present will be found in the same order in the compressed packet header.
下層階級ビットに向かって動く高位のビットで旗によるそれぞれの旗が八重奏であって、見ていると考えてください。 それぞれの分野は任意ですが、プレゼントが同じくらいで見つけられるなら、圧縮されたパケットのヘッダーを入るように命じてください。
Slot Number
スロット番号
The slot number flag indicates the slot number field is included in the compressed packet. The slot number field is one octet in length and specifies the number of the slot which corresponds to the Initial packet header. Slots are numbered starting at zero and continue to the maximum number of slots minus one.
スロット番号旗は、スロット番号分野が圧縮されたパケットに含まれているのを示します。 スロット番号分野は、長さにおける1つの八重奏であり、Initialパケットのヘッダーに文通されるスロットの数を指定します。 スロットは、ゼロから出発して、番号付であり、1を引いてスロットの最大数に続きます。
By default, slot compression is disabled. If negotiated, slot compression can be enabled for those slots which were created by the Unconfirmed Initial packet. When set to one (1), the slot number flag indicates the inclusion of the the slot number in the compressed packet. When set to zero (0), the slot number flag indicates the omission of the the slot number and specifies the use of the same slot number as for the last packet.
デフォルトで、スロット圧縮は障害があります。 交渉されるなら、Unconfirmed Initialパケットによって作成されたそれらのスロットにスロット圧縮を可能にすることができます。 1つ(1)に設定されると、スロット番号旗は圧縮されたパケットでのスロット番号の包含を示します。 (0)のゼロを合わせるように設定されるとき、スロット番号旗は、スロット番号の省略を示して、最後のパケットのように同じスロット番号の使用を指定します。
Mathur & Lewis [Page 9] RFC 1553 CIPX December 1993
マートゥルとルイス[9ページ]RFC1553CIPX1993年12月
Implementation Note:
実現注意:
Slot compression MUST only be enabled in a receiver which can
account for all erroneous and discarded packets. When a packet
has been discarded, the slot number is indeterminate for future
packets. The decompressor MUST discard all further packets
until a slot number is received.
すべての誤って捨てられたパケットの原因になることができる受信機でスロット圧縮を可能にするだけでよいです。 パケットが捨てられたとき、将来のパケットにおいて、スロット番号は不確定です。 スロット番号が受け取られているまで、減圧装置は一層のすべてのパケットを捨てなければなりません。
Checksum
チェックサム
When set to one (1), the checksum flag indicates the compressed packet will include the 2 octet checksum. When set to zero (0), this flag indicates the omission of the checksum and the decompressor is to assume the checksum is 0xFFFF. Note that meaningful checksums must be included in the packet with the checksum flag set to one (1).
1つ(1)に設定されると、チェックサム旗は、圧縮されたパケットが2八重奏チェックサムを含むのを示します。 (0)のゼロを合わせるように設定されるとき、この旗は、チェックサムと減圧装置の省略がチェックサムが0xFFFFであると仮定することであることを示します。 パケットでチェックサム旗のセットで1つ(1)に重要なチェックサムを含めなければならないことに注意してください。
Length
長さ
When set to one (1), the length flag indicates the inclusion of the IPX data length field in the compressed packet. When set to zero (0), the length flag indicates the omission of the IPX data length field in the compressed packet.
1つ(1)に設定されると、長さの旗は圧縮されたパケットでのIPXデータ長さの分野の包含を示します。 (0)のゼロを合わせるように設定されるとき、長さの旗は圧縮されたパケットでのIPXデータ長さの分野の省略を示します。
This is the Length field from the original IPX packet header. It specifies the length of IPX header and data in the packet prior to compression. It does not include the CIPX compression field such as flags, slot number, checksum, length field, or the NCP task number. Note that it is preferable to determine the length field from the MAC layer whenever possible, by subtracting the length of the compression header fields and adding the length of the saved packet header.
これはオリジナルのIPXパケットのヘッダーからのLength分野です。 それは圧縮の前にパケットでIPXヘッダーとデータの長さを指定します。 それは旗、スロット番号、チェックサム、長さの分野、またはNCPタスク番号などのCIPX圧縮分野を含んでいません。 圧縮ヘッダーフィールドの長さを引き算して、救われたパケットのヘッダーの長さを加えることによって可能であるときはいつも、MAC層から長さの分野を決定するのが望ましいことに注意してください。
Since every octet is significant over lower speed WAN links, an optimization is used in the specification of the length. It can be specified as a one, two or three octet field. If the length is in the range 0 to 127, then it is specified as a one octet field. If the length is in the range 128 to 16383, it is specified as a two octet field in high to low order, with the first octet in the range 128 to 191. Otherwise, if the length is greater than 16383, the first octet contains 192, and the second and third octets contain the full length. (This scheme is extensible to 8 octets, but currently is not required in the IPX protocol suite.)
あらゆる八重奏が下側の速度WANリンクの上に重要であるので、最適化は長さの仕様で使用されます。 1、2または3八重奏分野としてそれを指定できます。 長さが範囲に0〜127にあるなら、それは1つの八重奏分野として指定されます。 長さが範囲に128〜16383にあるなら、それは高値における2八重奏分野として範囲における最初の八重奏で128〜191に下位に指定されます。 さもなければ、最初の八重奏は長さが16383以上であるなら、192を含んでいます、そして、2番目と3番目の八重奏は完全な長さを含んでいます。 (この計画は、8つの八重奏に広げることができますが、現在、IPXプロトコル群で必要ではありません。)
Mathur & Lewis [Page 10] RFC 1553 CIPX December 1993
マートゥルとルイス[10ページ]RFC1553CIPX1993年12月
+-+-+-+-+-+-+-+-+ |0| length | length < 128 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |0| 長さ| 長さの<128+++++++++
ONE OCTET LENGTH FIELD
1つの八重奏長さの分野
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| length | length < 16384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| 長さ| 長さの<16384+++++++++++++++++
TWO OCTET LENGTH FIELD
2八重奏長さの分野
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0 0 0 0| length | length < 65535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0 0 0 0| 長さ| 長さの<65535+++++++++++++++++++++++++
THREE OCTET LENGTH FIELD
3八重奏長さの分野
Task Number
タスク番号
When set to one (1), the NCP task number flag indicates the NCP task number is included in the compressed packet (see NCP/IPX compression above). When set to zero (0), the NCP task number flag indicates the omission of the NCP task number in the compressed packet. When the NCP task number is not included in the compressed packet, we use the same NCP task number as that of last packet.
1つ(1)に設定されると、NCPタスク番号旗は、NCPタスク番号が圧縮されたパケットに含まれているのを(NCP/IPX圧縮が上であることを見てください)示します。 (0)のゼロを合わせるように設定されるとき、NCPタスク番号旗は圧縮されたパケットでのNCPタスク番号の省略を示します。 NCPタスク番号が圧縮されたパケットに含まれていないとき、私たちは最後のパケットのものと同じNCPタスク番号を使用します。
Based upon the bits set in the flags octet, optional portions are included in the compressed IPX header. The minimum compressed IPX header contains only the Flags octet. All fields in the original IPX header have been compressed out of the header. The maximum compressed IPX header can include up to 7 octets, the Flags, Slot, Checksum (2 octets), and Length (3 octets) fields, or 8 octets if the NCP Task Number is included. The minimum and maximum compressed IPX packets are shown below. Header fields are one octet in length except where noted.
基づいて、ビットでは、八重奏は旗でセットしていて、任意の部分は圧縮されたIPXヘッダーに含まれています。 最小の圧縮されたIPXヘッダーはFlags八重奏だけを含んでいます。 ヘッダーでオリジナルのIPXヘッダーのすべての分野を圧縮してあります。 NCP Task Numberが含まれているなら、最大の圧縮されたIPXヘッダーは最大7つの八重奏、Flags、Slot、Checksum(2つの八重奏)、およびLength(3つの八重奏)分野、または8つの八重奏を入れることができます。 最小の、そして、最大の圧縮されたIPXパケットは以下で見せられます。 ヘッダーフィールドは有名であるところ以外の長さが1つの八重奏です。
Mathur & Lewis [Page 11] RFC 1553 CIPX December 1993
マートゥルとルイス[11ページ]RFC1553CIPX1993年12月
+--------+---------
| Flags | DATA ...
| 0x00 |
+--------+---------
+--------+--------- | 旗| データ… | 0×00| +--------+---------
MINIMUM COMPRESSED IPX PACKET
最小の圧縮されたIPXパケット
+--------+--------+---------+---------+---------
| Flags | Slot |Checksum | Length | DATA ...
| 0xE0 | Number |2 octets |3 octets |
+--------+--------+---------+---------+---------
+--------+--------+---------+---------+--------- | 旗| スロット|チェックサム| 長さ| データ… | 0xE0| 数|2つの八重奏|3つの八重奏| +--------+--------+---------+---------+---------
MAXIMUM COMPRESSED IPX PACKET
最大の圧縮されたIPXパケット
+--------+--------+---------+---------+--------+---------
| Flags | Slot |Checksum | Length |NCP Task| DATA ...
| 0xF0 | Number |2 octets |3 octets | Number |
+--------+--------+---------+---------+--------+---------
+--------+--------+---------+---------+--------+--------- | 旗| スロット|チェックサム| 長さ|NCPタスク| データ… | 0xF0| 数|2つの八重奏|3つの八重奏| 数| +--------+--------+---------+---------+--------+---------
MAXIMUM COMPRESSED NCP/IPX PACKET
最大の圧縮されたNCP/IPXパケット
Regular Packet
レギュラーのパケット
The Regular packet type designates an IPX packet for which no compression is desired. This type of packet is sent when a packet cannot be compressed, or a decision is made not to compress it.
Regularパケットタイプは圧縮が全く望まれていないIPXパケットを指定します。 パケットを圧縮できないとき、このタイプのパケットを送るか、またはそれを圧縮しないのを決定をします。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 1 Regular
| | | |
|__ |__ |__ |___________________ Reserved (must be zero)
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | |___|___|___|___ パケットタイプ| | | | 1人のレギュラー| | | | |__ |__ |__ |___________________ 予約されます。(ゼロでなければなりません)
The Regular packet is rarely sent. Usually, the Regular packet is sent when there is not enough memory for the overhead of a new compression slot. Also, this type is included for future unforeseen changes to the IPX protocol which defeat the effectiveness of compression.
Regularパケットはめったに送られません。 新しい圧縮スロットのオーバーヘッドのための十分なメモリがないとき、通常、Regularパケットを送ります。 また、このタイプはIPXプロトコルへの圧縮の有効性を破る将来の予期しない変化のために含まれています。
Implementation Note:
実現注意:
The Regular Packet can be used for packets that are sporadic,
which are not worth setting-up a compression slot. This may be
過疎である、圧縮スロットをセットアップする価値がないパケットにRegular Packetを使用できます。 これはそうです。
Mathur & Lewis [Page 12] RFC 1553 CIPX December 1993
マートゥルとルイス[12ページ]RFC1553CIPX1993年12月
hard to determine for specific protocols. Various methods such
as hold-down and least-recently-used timers are currently being
used.
特定のプロトコルのために決定しにくいです。 下に成立などなどの様々な方法と最も最近でない中古のタイマは現在、使用されています。
On receipt, the 1 octet header is simply removed and the packet
passed up to IPX.
領収書で、単に1個の八重奏ヘッダーを取り除きました、そして、パケットはIPXまで通りました。
The entire IPX packet follows the single Flags octet. Note for a
Regular Packet (not compressed or uncompressed), the slot number
field is not included.
全体のIPXパケットはただ一つのFlags八重奏に続きます。 Regular Packet(圧縮されないか、または解凍されない)、スロット番号によって、分野が含まれていないことに注意してください。
Confirmed Initial Packet
確認された初期のパケット
The Confirmed Initial packet type is used by the compressor to inform the decompressor of the original packet header which will be used for subsequent compression, and to request Confirmation. The high order 4 bits are reserved for expansion to support additional protocols.
Confirmed Initialパケットタイプはコンプレッサーによって使用されて、どれがその後の圧縮に使用されるかをオリジナルのパケットのヘッダーの減圧装置に知らせて、Confirmationを要求します。 拡大が追加議定書を支持するように、高位4ビットは予約されます。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 3 Confirmed Initial
| | | |
|__ |__ |__ |___________________ 0 IPX Protocol
1-15 Reserved
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | |___|___|___|___ パケットタイプ| | | | 3 初期で、確認されました。| | | | |__ |__ |__ |___________________ 0 1-15が予約したIPXプロトコル
This type of packet is sent to inform the receiver to associate the IPX packet header with a slot number. This packet is sent each time a different header format is sent for a given slot, or when the sender has not received a Confirmation Packet from the receiver.
IPXパケットのヘッダーをスロット番号に関連づけるために受信機を知らせるためにこのタイプのパケットを送ります。 異なったヘッダー形式を与えられたスロットに送る各回、または送付者が受信機からConfirmation Packetを受け取っていないとき、このパケットを送ります。
The Flags octet lower 4 bits indicate the Confirmed Initial CIPX packet type. The high order 4 bits are reserved for expansion to support additional protocols. The Flags octet is always followed by the Slot Number and an ID field. The ID field is one octet in length.
Flags八重奏低級4ビットはConfirmed Initial CIPXパケットタイプを示します。 拡大が追加議定書を支持するように、高位4ビットは予約されます。 Slot NumberとID分野はいつもFlags八重奏を支えています。 ID分野は長さが1つの八重奏です。
For each slot, the ID will increment with every new header sent. Different slots may have the same ID. The combination of slot and ID uniquely identify a header. In practice, the ID octet can be any number which is unique for a "reasonably long period" of time. A reasonably long period is a function of transmission speed, round trip delays, and network load. There must be very little chance of duplicate slot and ID combinations within this period. Otherwise,
各スロットに関しては、IDはすべての新しいヘッダーを送って増加するでしょう。 異なったスロットには、同じIDがあるかもしれません。 スロットの組み合わせとIDは唯一ヘッダーを特定します。 実際には、ID八重奏はどんな時間の「適度に長い期間」の間ユニークな数であるかもしれません。 適度に長い期間は、伝送速度の関数と、周遊旅行遅れと、ネットワーク負荷です。 この期間中に、写しスロットとID組み合わせの非常に小さい見込みがあるに違いありません。 そうでなければ
Mathur & Lewis [Page 13] RFC 1553 CIPX December 1993
マートゥルとルイス[13ページ]RFC1553CIPX1993年12月
there is ambiguity as to which header is being identified.
ヘッダーが特定されているあいまいさがあります。
Implementation Note:
実現注意:
There is no requirement to hold or resend the Confirmed Initial
packet until confirmation. When a new packet with the same IPX
header is to be sent, another Confirmed Initial packet should
be sent using the same slot, the same ID, and the new packet
data.
確認までConfirmed Initialパケットを保持するか、または再送するという要件が全くありません。 同じIPXヘッダーがある新しいパケットを送ることになっているとき、別のConfirmed Initialパケットに同じスロット、同じID、および新しいパケットデータを使用させるべきです。
When a new packet with a different IPX header is to be sent, it
may be sent using a slot which has not received confirmation.
A Confirmed Initial packet is sent with the same slot, an
incremented ID, and the new packet data. Assuming a least-
recently-used policy for selecting a slot for a new IPX header,
this provides the ability to reuse slots when a Confirmed
Initial packet has been sent but not confirmed.
異なったIPXヘッダーがある新しいパケットを送ることになっているとき、それに確認を受け取っていないスロットを使用させるかもしれません。 同じスロット、増加しているID、および新しいパケットデータと共にConfirmed Initialパケットを送ります。 最少が最近新しいIPXヘッダーのためにスロットを選択するための方針を使用したと仮定して、これはConfirmed Initialパケットを送りますが、確認していないときスロットを再利用する能力を提供します。
+---------+---------+---------+-/ /-+----------
| Flags | Slot | ID | IPX | DATA ...
| 0x03 | Number | | Header |
+---------+---------+---------+-/ /-+----------
+---------+---------+---------+-/ /-+---------- | 旗| スロット| ID| IPX| データ… | 0×03| 数| | ヘッダー| +---------+---------+---------+-/ /-+----------
CONFIRMED INITIAL PACKET
確認された初期のパケット
Note that a Confirmed Initial header is followed by a complete IPX packet.
完全なIPXパケットがConfirmed Initialヘッダーのあとに続くことに注意してください。
Confirm Packet
パケットを確認してください。
The Confirm packet type is used by the decompressor to tell the compressor that it has received the Confirmed Initial packet.
Confirmパケットタイプは減圧装置によって使用されて、Confirmed Initialパケットを受けたとコンプレッサーに言います。
When the compressor receives this, it can start sending Compressed frames.
コンプレッサーがこれを受けるとき、それは、フレームをCompressedに送り始めることができます。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 5 Confirm
| | | |
|__ |__ |__ |___________________ Reserved (must be zero)
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | |___|___|___|___ パケットタイプ| | | | 5は確認します。| | | | |__ |__ |__ |___________________ 予約されます。(ゼロでなければなりません)
A Confirm Packet is exactly 3 octets in length. It consists of the
Confirm Packetはまさに長さが3つの八重奏です。 それは成ります。
Mathur & Lewis [Page 14] RFC 1553 CIPX December 1993
マートゥルとルイス[14ページ]RFC1553CIPX1993年12月
Flags, Slot Number and ID fields. The Slot Number field contains the number of the slot which is being acknowledged. The ID field contains the ID of the Confirmed Initial Packet which is being acknowledged.
旗、Slot Number、およびID分野。 Slot Number分野は承認されているスロットの数を含んでいます。 ID分野は承認されているConfirmed Initial PacketのIDを含んでいます。
+---------+---------+----------+
| Flags | Slot | ID |
| 0x05 | Number | |
+---------+---------+----------+
+---------+---------+----------+ | 旗| スロット| ID| | 0×05| 数| | +---------+---------+----------+
CONFIRM PACKET
パケットを確認してください。
Unconfirmed Initial Packet
未確認の初期のパケット
The Unconfirmed Initial packet type is used by the compressor to inform the decompressor of the original packet header which will be used for subsequent compression while not requesting confirmation.
Unconfirmed Initialパケットタイプはコンプレッサーによって使用されて、どれがその後の圧縮に確認を要求していない間、使用されるかをオリジナルのパケットのヘッダーの減圧装置に知らせます。
After sending an Unconfirmed Initial packet, the compressor may immediately send Compressed packets without confirmation.
Unconfirmed Initialパケットを送った後に、コンプレッサーはすぐに、確認なしでパケットをCompressedに送るかもしれません。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 7 Unconfirmed Initial
| | | |
|__ |__ |__ |___________________ 0 NCP Protocol
1-15 Reserved
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | |___|___|___|___ パケットタイプ| | | | 7の未確認のイニシャル| | | | |__ |__ |__ |___________________ 0 1-15が予約したNCPプロトコル
This type of packet is sent to inform the receiver to associate the IPX packet header with a slot number. This packet is sent each time a different header format is sent for a given slot.
IPXパケットのヘッダーをスロット番号に関連づけるために受信機を知らせるためにこのタイプのパケットを送ります。 異なったヘッダー形式を与えられたスロットに送るたびにこのパケットを送ります。
The Flags octet lower 4 bits indicate the Unconfirmed Initial CIPX packet type. The high order 4 bits are reserved for expansion to support additional protocols. The Flags octet is always followed by the Slot Number.
Flags八重奏低級4ビットはUnconfirmed Initial CIPXパケットタイプを示します。 拡大が追加議定書を支持するように、高位4ビットは予約されます。 Flags八重奏はいつもSlot Numberによって続かれています。
+---------+---------+-/ /-+-/ /-+---------
| Flags | Slot | IPX | NCP | NCP
| 0x07 | Number | Header | Header | DATA ...
+---------+---------+-/ /-+-/ /-+---------
+---------+---------+-/ /-+-/ /-+--------- | 旗| スロット| IPX| NCP| NCP| 0×07| 数| ヘッダー| ヘッダー| データ… +---------+---------+-/ /-+-/ /-+---------
Mathur & Lewis [Page 15] RFC 1553 CIPX December 1993
マートゥルとルイス[15ページ]RFC1553CIPX1993年12月
UNCONFIRMED INITIAL PACKET
未確認の初期のパケット
Note that an Unconfirmed Initial header is followed by a complete IPX packet.
完全なIPXパケットがUnconfirmed Initialヘッダーのあとに続くことに注意してください。
Reject Packet
パケットを拒絶してください。
The Reject packet type is used by the decompressor to tell the compressor that it has received a CIPX packet with a header which it does not support. This is provided to regulate future extensions to CIPX.
Rejectパケットタイプは支えないヘッダーと共にCIPXパケットを受けたとコンプレッサーに言う減圧装置によって使用されます。 今後の拡大をCIPXに規制するためにこれを提供します。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 9 Reject
| | | |
|__ |__ |__ |___________________ Reserved (must be zero)
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | |___|___|___|___ パケットタイプ| | | | 9廃棄物| | | | |__ |__ |__ |___________________ 予約されます。(ゼロでなければなりません)
A Reject Packet is exactly 3 octets in length. It consists of the Flags, Slot Number and Rejected Flags fields.
Reject Packetはまさに長さが3つの八重奏です。 それはFlags、Slot Number、およびRejected Flags分野から成ります。
The Slot Number field contains the number of the slot of the packet which is being rejected. Since the actual packet type may be unknown or misunderstood, this field actually contains the second octet of the rejected packet. In the normal case of a known CIPX packet type, this will be the slot number of an initial packet.
Slot Number分野は拒絶されているパケットのスロットの数を含んでいます。 実際のパケットタイプが未知か誤解されているかもしれないので、この分野は実際に拒絶されたパケットの2番目の八重奏を含んでいます。 知られているCIPXパケットタイプの正常な場合では、これは初期のパケットのスロット番号になるでしょう。
The Rejected Flags field contains the first octet of the packet being rejected. The packet type field is left untouched. Any flags which are correctly recognized should be cleared. The remaining flags indicate specific features that are being rejected. This information should be sufficient for implementations to adjust the use of certain packet types or dependent flags.
Rejected Flags分野は拒絶されるパケットの最初の八重奏を含んでいます。 パケットタイプ野原は触れない状態でおかれます。 正しく認識されるどんな旗もきれいにされるべきです。 残っている旗は拒絶されている特定の特徴を示します。 実現が、あるパケットタイプか依存する旗の使用を調整するように、この情報は十分であるべきです。
Implementation Note:
実現注意:
The Flags value of 0xFF is not a valid CIPX packet type.
Hence, such a packet type should be recognized as a standard
IPX header and forwarded without CIPX processing to the
appropriate routines. Under no circumstances should a Flags
value of 0xFF be rejected in a Reject Packet.
0xFFのFlags値は有効なCIPXパケットタイプではありません。 したがって、そのようなパケットタイプを標準のIPXヘッダーとして見分けて、CIPX処理なしで適切なルーチンに送るべきです。 Reject Packetで0xFFのFlags値を決して、拒絶するべきではありません。
Mathur & Lewis [Page 16] RFC 1553 CIPX December 1993
マートゥルとルイス[16ページ]RFC1553CIPX1993年12月
+---------+---------+----------+
| Flags | Slot | Rejected |
| 0x09 | Number | Flags |
+---------+---------+----------+
+---------+---------+----------+ | 旗| スロット| 拒絶されます。| | 0×09| 数| 旗| +---------+---------+----------+
REJECT PACKET
パケットを拒絶してください。
Compression Negotiation over PPP Links
pppリンクの上の圧縮交渉
For PPP links [5], the use of header compression can be negotiated by IPXCP [6]. By default, no compression is enabled.
PPPリンク[5]に関しては、IPXCP[6]はヘッダー圧縮の使用を交渉できます。 デフォルトで、圧縮は全く可能にされません。
The IPX-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired.
IPX圧縮プロトコルConfiguration Optionは、圧縮されたパケットを受ける能力を示すのに使用されます。 双方向の圧縮が望まれているなら、リンクの各端は別々にこのオプションを要求しなければなりません。
The PPP Protocol field is set to the same value as the usual IPX packets, and all IPX packets sent over the link MUST conform to the compressed format.
PPPプロトコル分野は普通のIPXパケットと同じ値に設定されます、そして、リンクの上に送られたすべてのIPXパケットが圧縮形式に従わなければなりません。
A summary of the IPX-Compression-Protocol Configuration Option format to negotiate Telebit IPX header compression (CIPX) is shown below. The fields are transmitted from left to right.
Configuration OptionがテレビットIPXヘッダー圧縮(CIPX)を交渉するためにフォーマットするIPX圧縮プロトコルの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | IPX-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Slot-Id | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| IPX圧縮プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マックススロットイド| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
6
6
IPX-Compression-Protocol
IPX圧縮プロトコル
0002 (hex) for Telebit Compressed IPX headers (CIPX).
テレビットCompressed IPXヘッダー(CIPX)のための0002(魔法をかけます)。
Max-Slot-Id
マックススロットイド
The Max-Slot-Id field is one octet and indicates the maximum
マックススロットイド分野は、1つの八重奏であり、最大を示します。
Mathur & Lewis [Page 17] RFC 1553 CIPX December 1993
マートゥルとルイス[17ページ]RFC1553CIPX1993年12月
slot identifier. This is one less than the actual number of
slots; the slot identifier has values from zero to Max-Slot-
Id.
識別子に溝をつけてください。 これはスロットの実数よりそれほど1です。 スロット識別子には、ゼロ〜マックス-Slotアイダホ州まで値があります。
Options
オプション
The Options field is one octet, and is comprised of the "logical or" of the following values:
または、Options分野が1つの八重奏であり、包括される、「論理的である、」 以下の値について:
0 No options.
0 オプションがありません。
1 The slot identifer may be compressed.
1 スロットidentiferは圧縮されるかもしれません。
The slot identifier must not be compressed if there is no
ability for the PPP link level to indicate an error in
reception to the decompression module. Synchronization after
errors depends on receiving a packet with the slot identifier.
PPPリンク・レベルが減圧モジュールへのレセプションで誤りを示す能力が全くなければ、スロット識別子を圧縮してはいけません。 誤りの後の同期はスロット識別子でパケットを受けるのによります。
2 Redefine Compressed Packet type bits 1-3.
2はCompressed Packetタイプビット1-3を再定義します。
It was noted earlier that packet types have been chosen such
that only the Compressed Packet type is an even number value
with the lowest order bit of zero. All other packet types are
odd values with a lowest order bit of one. The reason for this
assignment was to make it possible to determine the Compressed
Packet type by examining only one bit. This make it possible
to use all the other 7 bits to indicate status in the
Compressed Packet. The 7 bits are composed of the upper 4 bits
which are permanently defined to indicate packet dependent
flags, plus bits 1-3 which are otherwise part of the Packet
Type. The upper 4 bits are defined above. The redefinition of
bits 1-3 of the Compressed Packet type is left for future
expansion.
より早くパケットタイプが選ばれたことに注意されたので、唯一のCompressed Packetタイプはゼロの最も低いオーダービットがある偶数値です。 他のすべてのパケットタイプが1の最も低いオーダービットがある変な値です。 この課題の理由はCompressed Packetが1ビットだけを調べることによってタイプすることを決定するのを可能にすることでした。 これで、Compressed Packetの状態を示すのに他のすべての7ビットを使用するのは可能になります。 7ビットは永久にパケットに依存する旗を示すために定義される上側の4ビット、およびそうでなければPacket Typeの一部であるビット1-3で構成されます。 上側の4ビットは上で定義されます。 Compressed Packetタイプのビット1-3の再定義は今後の拡大に残されます。
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| | | | | | | | 0 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |___ Packet Type
| | | | | | | 0 Compressed Packet
| | | | | | |
| | | | |___|___|_______ Redefined bits
| | | |
|___|___|___|___________________ Compressed Packet flags
7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | | | | | | | | 0 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | |___ パケットタイプ| | | | | | | 0の圧縮されたパケット| | | | | | | | | | | |___|___|_______ 再定義されたビット| | | | |___|___|___|___________________ 圧縮されたPacket旗
By default, this feature in not enabled and this flag is
set to zero. When this flag is set to one, it indicates
デフォルトで、可能にされないところのこの特徴とこの旗はゼロに設定されます。 この旗が1つに設定されるのを示すとき
Mathur & Lewis [Page 18] RFC 1553 CIPX December 1993
マートゥルとルイス[18ページ]RFC1553CIPX1993年12月
the desire to use this feature.
この特徴を使用する願望。
Compression Negotiation over IPXWAN Links
IPXWANリンクの上の圧縮交渉
"IPXWAN" is the protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks [7]. To negotiate the Telebit compression option, we use Novell's allocated option number for CIPX (00) in the IPXWAN timer request/response packet.
"IPXWAN"はノベルが標準のIPXルーティング情報と交通をWANデータリンク[7]の上と交換する前に必要なルータをルータ情報と交換するのに使用するプロトコルです。 テレビット圧縮オプションを交渉するために、私たちはIPXWANタイマ要求/応答パケットでノベルのCIPX(00)の割り当てられたオプション番号を使用します。
The Timer Request packet contains the following Telebit compression option:
Timer Requestパケットは以下のテレビット圧縮オプションを含んでいます:
WOption Number 80 - Define compression type
WAccept Option 01 - 0=No, 1=Yes, 3=N/A
WOption Data Len 00 03 - Length of option
WOption Data 00 - Telebit's compression (CIPX)
WOption Data XX - Compression options
WOption Data NN - Compression slots
WOption Number80--圧縮タイプWAccept Option01--0=ノー、を定義してください、1つの=はい、WOption Dataレン00 03--WOption Data00--テレビットの圧縮(CIPX)WOption Data XX--オプション圧縮オプションWOption Data NNの長さ--圧縮が溝をつける3=N/
Where the WOption Data fields are:
WOption Data分野があるところ:
00 Telebit's compression option described in this
document (CIPX).
00 テレビットの圧縮オプションは本書では(CIPX)について説明しました。
XX Compression options as defined below:
以下で定義されるXX Compressionオプション:
0x01 Compress slot ID when possible
0x02 Redefine Compressed Packet type bits 1-3.
可能な0×02Redefine Compressed Packetがビット1-3をタイプするとき、0×01はスロットIDを圧縮します。
NN The requested # of compression slots.
NN、圧縮の#、が溝をつける要求。
Accept Option (for compression type) must be set to YES if the
option is supported and NO if the option is not supported. A Timer
Response must respond with only one header compression type set to
YES.
オプションがサポートされないなら、オプションがサポートされるならOption(圧縮タイプのための)がはいに用意ができなければならなくて、いいえと受け入れてください。 Timer Responseは圧縮タイプがはいに設定する1個のヘッダーだけと共に応じなければなりません。
The Timer Response packet that accepts the option will look like
this:
オプションを受け入れるTimer Responseパケットはこれに似るでしょう:
WOption Number 80 - Define compression type
WAccept Option 01 - 0=No, 1=Yes, 3=N/A
WOption Data Len 00 03 - Length of option
WOption Data 00 - Telebit's compression (CIPX)
WOption Data XX - Compression options
WOption Data NN - Compression slots
WOption Number80--圧縮タイプWAccept Option01--0=ノー、を定義してください、1つの=はい、WOption Dataレン00 03--WOption Data00--テレビットの圧縮(CIPX)WOption Data XX--オプション圧縮オプションWOption Data NNの長さ--圧縮が溝をつける3=N/
Mathur & Lewis [Page 19] RFC 1553 CIPX December 1993
マートゥルとルイス[19ページ]RFC1553CIPX1993年12月
Where the WOption Data fields are:
WOption Data分野があるところ:
00 Telebit's compression option described in this
document (CIPX).
00 テレビットの圧縮オプションは本書では(CIPX)について説明しました。
XX Compression options as defined below:
以下で定義されるXX Compressionオプション:
0x01 Compress slot ID when possible
0x02 Redefine Compressed Packet type bits 1-3.
可能な0×02Redefine Compressed Packetがビット1-3をタイプするとき、0×01はスロットIDを圧縮します。
NN The negotiated # of slots (The lower of each side's
requested number of slots)
NN、スロットの#、を交渉します。(それぞれの側の要求された番号のスロットについて、より低い)
IPX packets (except of course IPXWAN packets) are not sent over the link until the IPXWAN negotiations are completed. Once IPXWAN negotiations are completed, regular IPX packets can be sent over the link.
IPXWAN交渉が終了するまで、IPXパケット(もちろんIPXWANパケットを除いた)はリンクの上に送られません。 いったんIPXWAN交渉を終了すると、レギュラーのIPXパケットをリンクの上に送ることができます。
If both ends of the link agree on the compression options, then the IPX packets are sent using the specified options. If either end of the link does not accept a compression option, then this compression option will not be used. Compression will be done using any remaining options. Options, by definition, are not required. Implementations MUST support CIPX without any options.
リンクの両端が圧縮オプションに同意するなら、IPXパケットに指定されたオプションを使用させます。 リンクのどちらの端も圧縮オプションを受け入れないと、この圧縮オプションは使用されないでしょう。 圧縮はどんな残っているオプションも使用し終わるでしょう。 オプションは定義上必要ではありません。 実現は少しもオプションなしでCIPXを支持しなければなりません。
It is the responsibility of the router sending the IPXWAN Timer Response to inform the other router of the options that will be used. The Timer Response MUST contain a subset of the options received in a Timer Request.
使用されるオプションのもう片方のルータを知らせるのは、ルータがIPXWAN Timer Responseを送る責任です。 Timer ResponseはTimer Requestに受け取られたオプションの部分集合を含まなければなりません。
To be clear, IPXWAN is used to set up a symmetrical compression link. Compression is configured identically in both directions. Each end will use the same number of slots and same compression options. It is illegal for link ends to use different number of slots or different options.
明確であるなら、IPXWANは、対称の圧縮リンクをセットアップするのに使用されます。 圧縮は同様に両方の方向に構成されます。 各端は同じ数のスロットと同じ圧縮オプションを使用するでしょう。 リンクエンドが異なった数のスロットか異なったオプションを使用するのは、不法です。
IPX Compression Performance
IPX圧縮パフォーマンス
The performance of this algorithm will depend on the number of active connections and the number of slots negotiated. If the number of slots is greater than the number of connections, the hit rate should be very high giving a very high compression ratio. The performance also depends on the average size of the IPX packets. If the average size of packets is small, then compression will result in a more noticeable performance improvement.
このアルゴリズムの性能は活発な接続の数と交渉されたスロットの数に依存するでしょう。 スロットの数がポートの数より大きいなら、ヒット率は、非常に高い圧縮比を与えながら、非常に高いはずです。 また、性能はIPXパケットの平均のサイズに依存します。 パケットの平均のサイズがわずかであるなら、圧縮は、よりめぼしい性能改良をもたらすでしょう。
Mathur & Lewis [Page 20] RFC 1553 CIPX December 1993
マートゥルとルイス[20ページ]RFC1553CIPX1993年12月
avg_data_len + uncomp_header_len
Compression ratio = ----------------------------------
avg_data_len + avg_comp_header_len
avg_データ_len+「非-コンピュータ」_ヘッダー_len Compression比=---------------------------------- _avg_データ_len+avg_コンピュータヘッダー_len
Where 'avg_data_len' is the average length of data in the IPX packet, and 'uncomp_head_len' is the uncompressed header length which is fixed at 30 octets. Where 'avg_comp_header_len' is the average length of the compressed IPX header. The length of the minimum compressed IPX header is 1 octet. The length of the maximum compressed NCP/IPX header is 8 octets (including the NCP task number), but since no implementation yet sends packets with a length greater than 16K, 7 octets is the commonly encountered maximum. Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the inclusion of the flag and slot number octets.
'avg_データ_len'がIPXパケットの平均した長さに関するデータであり、'「非-コンピュータ」_ヘッド_len'が30の八重奏のときに修理されている解凍されたヘッダ長であるところ。 'avg_コンピュータ_ヘッダー_lenである'ところに、圧縮されたIPXヘッダーには平均した長さがありますか? 最小の圧縮されたIPXヘッダーの長さは1つの八重奏です。 最大の圧縮されたNCP/IPXヘッダーの長さは8つの八重奏(NCPタスク番号を含んでいて)ですが、どんな実現もまだパケットを送らないので、長さより多くの16のK、7つの八重奏と共に、一般的に遭遇した最大があります。 恐らく、旗とスロット番号八重奏の包含を仮定して、妥当な'avg_コンピュータ_ヘッダー_len'は2です。
The maximum length of the data in an IPX packet is 546 octets (576 octets - 30 octet IPX header), although newer implementations may send packets of up to 4096 octets. The minimum length of the data in an IPX packet is 1 octet. Within the normal distribution of small NCP packets, perhaps a reasonable 'avg_data_len' is 26 octets.
IPXパケットのデータの最大の長さは546の八重奏(576の八重奏--30八重奏IPXヘッダー)です、より新しい実現が最大4096の八重奏のパケットを送るかもしれませんが。 IPXパケットのデータの最小の長さは1つの八重奏です。 小さいNCPパケットの正規分布の中では、恐らく、妥当な'avg_データ_len'は26の八重奏です。
546 + 30
Minimal Compression = -------- = 1.04
546 + 6
546+30の最小量の圧縮=-------- = 1.04 546 + 6
1 + 30
Maximal Compression = ------ = 15.50
1 + 1
1+30の最大限度の圧縮=------ = 15.50 1 + 1
26 + 30
Likely Compression = ------- = 2.00
26 + 2
26+30のありそうな圧縮=------- = 2.00 26 + 2
Security Considerations
セキュリティ問題
IPX provides some security features, which are fully applicable to CIPX. CIPX does not significantly alter the basic security of IPX.
IPXはいくつかのセキュリティ機能を提供します。(機能はCIPXに完全に適切です)。 CIPXはIPXの基本的なセキュリティをかなり変更しません。
Mathur & Lewis [Page 21] RFC 1553 CIPX December 1993
マートゥルとルイス[21ページ]RFC1553CIPX1993年12月
References
参照
[1] Novell Inc., "IPX Router Specification", September 1992, Part
Number: 107-000029-001
[1] ノベル株式会社、「IPXルータ仕様」、1992年9月は数を分けます: 107-000029-001
[2] Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990
[2] ジェーコブソン、ヴァン、「低速連続のリンクへのTCP/IPヘッダーを圧縮します」、RFC1144、1990年2月
[3] CCITT Recommendation V.42bis Error Correcting Procedures for DCEs
using Error Correction Procedures
[3] DCEsのためにエラー修正手順を用いることで手順を修正するCCITT推薦V.42bis誤り
[4] ISO 7776, Information Processing Systems - Data Communication -
High Level Data Link Control Procedures - Description of the X.25
LAPB-Compatible DTE Data Link Procedures
[4] ISO7776、情報処理システム--データ通信--ハイレベル・データ・リンク制御手順--X.25 LAPBコンパチブルDTEデータ・リンク手順の記述
[5] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1548,
December 1993
[5] シンプソン、W.A.、「二地点間プロトコル(ppp)」、RFC1548、1993年12月
[6] Simpson, W. A., "The PPP Internet Packet Exchange Control
Protocol (IPXCP)", RFC 1552, December 1993
[6] シンプソン、W.A.、「pppインターネットパケット交換制御プロトコル(IPXCP)」、RFC1552、1993年12月
[7] Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]",
RFC 1551, December 1993
[7] アレン、マイケル、「様々な青白いメディア[IPXWAN]の上のノベルIPX」、RFC1551、1993年12月
Acknowledgements
承認
This compression algorithm incorporates many ideas from the Van Jacobson TCP/IP header compression algorithm.
この圧縮アルゴリズムはヴァンジェーコブソンTCP/IPヘッダー圧縮アルゴリズムから多くの考えを取り入れます。
Michael Allen from Novell provided a lot of valuable feedback in the design of this algorithm. David Piscitello from Bellcore and Marty Del Vecchio at Shiva Corp. made several good suggestions. Bill Simpson was very helpful in driving PPP, and specifically IPXCP, on the standards course.
ノベルからのマイケル・アレンは多くの有益なフィードバックをこのアルゴリズムのデザインに提供しました。 BellcoreからのデヴィッドPiscitelloとシバ神社のマーティ・デル・ヴェッキョはいくつかの良い提案をしました。 ビル・シンプソンは規格コースの駆動PPP、および明確にIPXCPで非常に助けになりました。
Chair's Address
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
議長のAddressフレッド・ベイカー・高度なコンピュータコミュニケーション315Bollay Driveサンタバーバラ、カリフォルニア 93117
EMail: fbaker@acc.com
メール: fbaker@acc.com
Mathur & Lewis [Page 22] RFC 1553 CIPX December 1993
マートゥルとルイス[22ページ]RFC1553CIPX1993年12月
Authors' Addresses
作者のアドレス
Saroop Mathur
Telebit Corp.
1315 Chesapeake Terrace
Sunnyvale, CA 94089-1100
チェサピークTerraceサニーベル、Saroopマートゥルテレビット社1315のカリフォルニア94089-1100
EMail: mathur@telebit.com
メール: mathur@telebit.com
Mark S. Lewis
Telebit Corp.
1315 Chesapeake Terrace
Sunnyvale, CA 94089-1100
チェサピークTerraceサニーベル、マークS.ルイステレビット社1315のカリフォルニア94089-1100
EMail: Mark.S.Lewis@telebit.com
メール: Mark.S.Lewis@telebit.com
Mathur & Lewis [Page 23]
マートゥルとルイス[23ページ]
一覧
スポンサーリンク
