RFC2118 日本語訳

Network Working Group                                            G. Pall
Request for Comments: 2118                         Microsoft Corporation
Category: Informational                                       March 1997

コメントを求めるワーキンググループG.祭服要求をネットワークでつないでください: 2118年のマイクロソフト社カテゴリ: 情報の1997年3月

          Microsoft Point-To-Point Compression (MPPC) Protocol

マイクロソフトの二地点間圧縮(MPPC)プロトコル

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.

PPP Compression Controlプロトコル[2]はリンクであるとカプセル化されたPPPの上で圧縮プロトコルを交渉して、利用するメソッドを提供します。

   This document describes the use of the Microsoft Point to Point
   Compression protocol (also referred to as MPPC in this document) for
   compressing PPP encapsulated packets.

このドキュメントは、パケットであるとカプセル化されたPPPを圧縮するためにPoint Compressionプロトコル(また、本書ではMPPCと呼ばれる)にマイクロソフトPointの使用について説明します。

Table of Contents

目次

   1.     Introduction ..........................................    2
      1.1       Licensing .......................................    2
      1.2.      Specification of Requirements ...................    2
   2.     Configuration Option Format ...........................    3
   3.     MPPC Packets ..........................................    4
      3.1       Packet Format....................................    5
   4. Description of Compressor and Encoding ....................    6
      4.1       Literal Encoding ................................    7
      4.2       Copy Tuple Encoding .............................    7
          4.2.1     Offset Encoding .............................    7
          4.2.2     Length-of-Match Encoding ....................    7
      4.3       Synchronization .................................    8
   SECURITY CONSIDERATIONS ......................................    8
   REFERENCES ...................................................    9
   ACKNOWLEDGEMENTS .............................................    9
   CHAIR'S ADDRESS    ...........................................    9
   AUTHORS' ADDRESS .............................................    9

1. 序論… 2 1.1 認可します。 2 1.2. 要件の仕様… 2 2. 設定オプション形式… 3 3. MPPCパケット… 4 3.1 パケット形式… 5 4. コンプレッサーとコード化の記述… 6 4.1 リテラルコード化… 7 4.2 Tupleコード化をコピーしてください… 7 4.2 .1 コード化を相殺してください… 7 4.2 .2 マッチの長さのコード化… 7 4.3同期… 8 セキュリティ問題… 8つの参照箇所… 9つの承認… 9 議長のアドレス… 9人の作者のアドレス… 9

Pall                         Informational                      [Page 1]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[1ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

1.  Introduction

1. 序論

   The Microsoft Point to Point Compression scheme is a means of
   representing arbitrary Point to Point Protocol (PPP) packets in a
   compressed form. The MPPC algorithm is designed to optimize processor
   utilization and bandwidth utilization in order to support large
   number of simultaneous connections. The MPPC algorithm is also
   optimized to work efficiently in typical PPP scenarios
   (1500 byte MTU, etc.).

Point Compression体系へのマイクロソフトPointは圧縮形にPointプロトコル(PPP)パケットに任意のPointを表す手段です。 MPPCアルゴリズムは、多くの同時接続をサポートするためにプロセッサ利用と帯域幅利用を最適化するように設計されています。 また、MPPCアルゴリズムは、典型的なPPPシナリオ(1500年のバイトのMTUなど)で効率的に働くために最適化されます。

   The MPPC algorithm uses an LZ [3] based algorithm with a sliding
   window history buffer.

MPPCアルゴリズムは引窓歴史バッファと共に[3]のベースのLZアルゴリズムを使用します。

   The MPPC algorithm keeps a continous history so that after 8192 bytes
   of data has been transmitted compressed there is always 8192 bytes of
   history to use for compressing, except when the history is flushed.

MPPCアルゴリズムが連続の歴史を保管するので、8192バイトのデータをそこに圧縮されていた状態で送ってある後に、いつもそれは圧縮のために費やす8192バイトの歴史です、歴史が紅潮している時を除いて。

1.1.  Licensing

1.1. 認可

   MPPC can only be used in products that implement the Point to Point
   Protocol AND for the sole purpose of interoperating with other MPPC
   and Point to Point Protocol implementations.

PointプロトコルにPointを実装する製品と他のMPPCとPointと共にPointプロトコル実装に共同利用する唯一の目的にMPPCを使用できるだけです。

   Source and object licenses are available on a non-discriminatory
   basis from Stac Electronics. Please contact:

ソースとオブジェクトライセンスはStac Electronicsから非差別しているベースで手があいています。 連絡してください:

         Cheryl Poland
         Stac Electronics
         12636 High Bluff Drive,
         San Deigo, CA 92130
         Phone: (619)794-4534
         Email: cherylp@stac.com

サンDeigo、カリフォルニア シェリルポーランドStac Electronics12636の高い切り立っているドライブ、92130は以下に電話をします。 (619)794-4534 メールしてください: cherylp@stac.com

1.2.  Specification of Requirements

1.2. 要件の仕様

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the specification.

「必要である」というThis単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

Thisは定義がある手段を言葉で表してはいけません。仕様の絶対禁止。

Pall                         Informational                      [Page 2]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[2ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

   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.  Configuration Option Format

2. 設定オプション形式

   Description

記述

      The CCP Configuration Option negotiates the use of MPPC on the
      link.  By default or ultimate disagreement, no compression is
      used.

CCP Configuration OptionはリンクにおけるMPPCの使用を交渉します。 または、デフォルトで、究極の不一致、どんな圧縮も使用されていません。

   A summary of the CCP Configuration Option format is shown below.
   The fields are transmitted from left to right.

CCP 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     |        Supported Bits         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Supported Bits          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

タイプ

      18

18

   Length

長さ

      6

6

   Supported Bits

ビットであるとサポートされます。

      This field is 4 octets, most significant octet first. The least
      significant bit in the least significant octet set to 1 indicates
      desire to negotiate MPPC.

最初に、この分野は4つの八重奏、最も重要な八重奏です。 1に設定される中で最も重要でない八重奏における最下位ビットはMPPCを交渉する願望を示します。

      All other bits MUST be set to 0.

他のすべてのビットを0に設定しなければなりません。

Pall                         Informational                      [Page 3]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[3ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

3.  MPPC Packets

3. MPPCパケット

   Before any MPPC packets may be communicated, PPP must reach the
   Network-Layer Protocol phase, and the CCP Control Protocol must reach
   the Opened state.

どんなMPPCパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、CCP ControlプロトコルはOpened状態に達しなければなりません。

   Exactly one MPPC datagram is encapsulated in the PPP Information
   field. The PPP Protocol field indicates type hex 00FD for all
   compressed datagrams.

ちょうど1個のMPPCデータグラムがPPP情報分野でカプセル化されます。 PPPプロトコル分野はすべての圧縮されたデータグラムのためにタイプ十六進法00FDを示します。

   The maximum length of the MPPC datagram transmitted over a PPP link
   is the same as the maximum length of the Information field of a PPP
   encapsulated packet. Since the history buffer is limited to 8192
   bytes, this length cannot be greater than 8192 bytes.

PPPリンクの上に送られたMPPCデータグラムの最大の長さはPPPの情報分野の最大の長さがパケットをカプセルに入れったのと同じです。 歴史バッファが8192バイトに制限されるので、この長さは8192バイト以上であるはずがありません。

   Only packets with PPP Protocol numbers in the range hex 0021 to hex
   00FA are compressed.  Other packets are not passed thru the MPPC
   processor and are sent with their original PPP Protocol numbers.

十六進法00FAへの範囲十六進法0021におけるPPPプロトコル番号があるパケットだけが圧縮されます。 他のパケットをMPPCプロセッサを通して通過しないで、それらの元のPPPプロトコル番号と共に送ります。

   Padding

詰め物

      It is recommended that padding not be used with MPPC since it
      defeats the purpose of compression. If the sender must use padding
      it MUST negotiate the Self-Describing-Padding Configuration option
      during LCP phase and use self-describing pads.

圧縮の目的をくつがえすので詰め物がMPPCと共に使用されないのは、お勧めです。 送付者が詰め物を使用しなければならないなら、それは、LCP段階の間、そっと歩くと説明するSelf Configurationオプションを交渉して、自己について説明するパッドを使用しなければなりません。

   Reliability and Sequencing

信頼性と配列

      The MPPC scheme does not require a reliable link.  Instead, it
      relies on a 12 bit coherency count in each packet to keep the
      history buffers synchronized.  If the receiver recognizes that the
      coherency count received in the packet does not match the count it
      is expecting, it sends a CCP Reset-Request packet to resynchronize
      its history buffer with the sender's history buffer.

MPPC体系は信頼できるリンクを必要としません。 代わりに、それは、歴史バッファを同期させ続けるために各パケットで12ビットの一貫性カウントに依存します。 受信機が、パケットで受けられた一貫性カウントがそれが予想しているカウントに合っていないと認めるなら、それは、送付者の歴史バッファで歴史バッファを再連動させるようにCCP Reset-リクエスト・パケットを送ります。

      MPPC expects the packets to be delivered in sequence, otherwise
      history buffer re-synchronization will not occur.

MPPCは、パケットが連続して提供されると予想します。さもなければ、歴史バッファ再同期は起こらないでしょう。

      MPPC MAY be used over a reliable link, as described in "PPP
      Reliable Transmision" [5], but this typically just adds
      unnecessary overhead since only the coherency count is required.

MPPC MAYが「pppの信頼できるTransmision」[5]で説明されるように信頼できるリンクの上に使用されて、一貫性カウントだけが必要であるので、これだけがただ不要なオーバーヘッドを通常加えます。

   Data Expansion

データ展開

      If compressing the data results in data expansion, the original
      data is sent as an uncompressed MPPC packet. The sender must flush
      the history before compressing any more data and set the FLUSHED
      bit on the next outgoing packet.

データ展開でデータ結果を圧縮するなら、解凍されたMPPCパケットとしてオリジナルのデータを送ります。 送付者は、それ以上のデータを圧縮する前に、歴史を洗い流して、次の出発しているパケットの上にFLUSHEDビットを設定しなければなりません。

Pall                         Informational                      [Page 4]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[4ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

3.1.  Packet Format

3.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 the MPPC compression protocol is successfully negotiated by
      the PPP Compression Control Protocol, the value is hex 00FD. This
      value MAY be compressed when Protocol-Field-Compression is
      negotiated.

MPPC圧縮プロトコルがPPP Compression Controlプロトコルによって首尾よく交渉されるとき、値は十六進法00FDです。 プロトコル分野圧縮が交渉されるとき、この値は圧縮されるかもしれません。

   Bit A

ビットA

      This bit indicates that the history buffer has just been
      initialized before this packet was generated.  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 the
      sender has initialized its history buffer before compressing the
      packet and that the receiving peer must initialize its history
      buffer before decompressing the packet. This bit is referred to as
      FLUSHED bit in this document.

このビットは、このパケットが生成される前に歴史バッファがちょうど初期化されたところであるのを示します。 このパケット、何か既往歴に基づいていないので、ALWAYSを減圧できますか? パケットを圧縮する前に、送付者が歴史バッファを初期化して、パケットを減圧する前に受信同輩が歴史バッファを初期化しなければならないことを同輩に知らせるためにこのビットを通常送ります。 このビットは本書では噛み付かれたFLUSHEDと呼ばれます。

      Implementation Note: Compression and decompression histories are
      always initialized with all zeroes.

実装注意: 圧縮と減圧歴史はいつもすべてのゼロで初期化されます。

   Bit B

ビットB

      This bit indicates that the packet was moved to the front of the
      history buffer typically because there was no room at the end of
      the history buffer.  This bit is used to tell the decompressor to
      set its history pointer to the beginning of the history buffer.

このビットは、余地が全く歴史バッファの端に通常なかったのでパケットが歴史バッファの前部に動かされたのを示します。 このビットは、歴史バッファの始まりに歴史指針を設定するように減圧装置に言うのに使用されます。

      Implementation Notes:
      1. It is implied that this bit must be set at least once for every
         8192 bytes of data that is sent compressed.
      2. It is also implied that this bit can be set even if the
         sender's history buffer is not full. Initialized history that
         has not been used for compressing data must not be referred to
         in the compressed packets.

実装注意: 1. このビットが送られる8192バイト毎のデータのための少なくとも一度圧縮されたセットであるに違いないことが含意されます。 2. また、送付者の歴史バッファが完全でなくてもこのビットを設定できるのが含意されます。 圧縮されたパケットでデータを圧縮するために費やされていない初期化している歴史を参照してはいけません。

Pall                         Informational                      [Page 5]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[5ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

   Bit C

ビットC

      This bit (if set) is used to indicate that the packet is
      compressed.

このビット(設定されるなら)は、パケットが圧縮されるのを示すのに使用されます。

   Bit D

ビットD

      This bit must be set to 0.

このビットを0に設定しなければなりません。

   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
      starts at 0 and is always increased by 1 and NEVER decreases or
      goes back. When all bits are 1, the count returns to 0.

一貫性カウントは、適切なオーダーでパケットを送って、パケットを全く下げていないことを保証するのに使用されます。 このカウントは、0時に始まって、1ついつも増強されて、減少するか、または決して戻りません。 すべてのビットが1であるときに、カウントは0に戻ります。

   Compressed Data

圧縮されたデータ

      The compressed data begins with the protocol field.  For example,
      in case of an IP packet (0021 followed by an IP header), the
      compressor will first try to compress the 0021 protocol field and
      then compress the IP header.

圧縮されたデータはプロトコル分野で始まります。 例えば、IPパケット(0021はIPヘッダーで続いた)の場合に、コンプレッサーは、0021年のプロトコル分野を圧縮して、最初に、次に、IPヘッダーを圧縮しようとするでしょう。

      If the packet contains header compression, the MPPC compressor is
      applied AFTER header compression is preformed and MUST be applied
      to the compressed header as well.  For example, if a packet
      contained the protocol 002d for a compressed TCP/IP header, the
      compressor would first attempt to compress 002d and then it
      would attempt to compress the compressed Van-Jacobsen TCP/IP
      header.

パケットがヘッダー圧縮を含んでいるなら、MPPCコンプレッサーを適用されたAFTERヘッダー圧縮が前形成されるということであり、また、圧縮されたヘッダーに適用しなければなりません。 例えば、パケットが圧縮されたTCP/IPヘッダーのためのプロトコル002dを含んでいるなら、コンプレッサーは、最初に002dを圧縮するのを試みるでしょうに、そして、次に、それは圧縮されたヴァン-ジェイコブセンTCP/IPヘッダーを圧縮するのを試みるでしょう。

4. Description of Compressor and Encoding

4. コンプレッサーとコード化の記述

   The compressor runs through the length of the frame producing as
   output a Literal (byte to be sent uncompressed) or a <Offset,
   Length-of-Match> Copy tuple, where Offset is the number of bytes
   before in the history where the match lies and Length-of-Match is the
   number of bytes to copy from the location indicated by Offset.

コンプレッサーは出力としてLiteral(送られるバイトは解凍した)か<Offsetを生産するフレームの長さを貫きます、Length。-マッチ>Copy tupleでは、以前Offsetがマッチがある歴史とマッチのLengthのどこのバイト数であるかはOffsetによって示された位置からコピーするバイト数です。

   For example, comsider the following string:

例えば、より多くのcomsiderに、以下は以下を結びます。

   0         1         2         3         4
   012345678901234567890123456789012345678901234567890
   for whom the bell tolls, the bell tolls for thee.

0 1 2 3 4、012345678901234567890123456789012345678901234567890 ベルがだれを鳴らせるように、ベルはあなたに死を知らせる鐘が鳴らせるか。

   The compressor would produce:

コンプレッサーは生産されるでしょう:

   for whom the bell tolls,<16,15> <40,4><19,3>e.

だれ、ベルは突かれて、<16、15><40、4><19、3は>eであるか。

Pall                         Informational                      [Page 6]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[6ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

   The Literal and Copy tuple tokens are then encoded according to the
   MPPC encoding scheme.

そして、体系をコード化するMPPCによると、LiteralとCopy tupleトークンはコード化されます。

4.1 Literal Encoding

4.1 文字通りのコード化

   Literals are bytes sent uncompressed. If the value of the Literal is
   below hex 80, it is encoded with its value itself. If the Literal has
   value greater than hex 7F it is sent as bits 10 followed by the lower
   7 bits of the Literal.

リテラルは解凍されていた状態で送られたバイトです。 Literalの値が十六進法80の下にあるなら、それは値自体でコード化されます。 Literalが値を十六進法よりすばらしくするなら、Literalの低級7ビットに従ってビット10が続いたので、7F、それを送ります。

   Example: Literal hex 56 is transmitted as  01010110
            Literal hex E7 is transmitted as 101100111

例: 01010110Literal十六進法E7が101100111として伝えられるのに従って、文字通りの十六進法56は伝えられます。

4.2 Copy Tuple Encoding

4.2 コピーTupleコード化

   Copy tuples represent compressed data. A tuple has two elements: the
   Offset and Length-of-Match. The Offset is encoded before the Length-
   of-Match.

コピーtuplesは圧縮されたデータを表します。 tupleには、2つの要素があります: オフセットとマッチの長さ。 OffsetはマッチのLengthの前でコード化されます。

4.2.1 Offset Encoding

4.2.1 コード化を相殺してください。

   Offset values less than 64 are encoded as bits 1111 followed by the
   lower 6 bits of the value.

64が価値の低級6ビットに従って1111が続いたビットとしてコード化されるほど値を相殺しないでください。

   Offset values between 64 and 320 are encoded as bits 1110 followed by
   the lower 8 bits of the computation (value - 64).

64と320の間のオフセット値は計算(値--64)の低級8ビットに従って1110が続いたビットとしてコード化されます。

   Offset values between 320 and 8191 are encoded as bits 110 followed
   by the lower 13 bits of the computation (value - 320).

計算(値--320)の低級13ビットに従ってビット110が続いて、320と8191の間のオフセット値はコード化されます。

   Examples: Offset value of 3 is encoded as:     1111 000011
             Offset value of 128 is encoded as:   1110 01000000
             Offset value of 1024 is encoded as:   110 0001011000000

例: 3のオフセット値は以下としてコード化されます。 128の1111 000011のオフセット値は以下としてコード化されます。 1024年の1110 01000000のオフセット値は以下としてコード化されます。 110 0001011000000

4.2.2 Length-of-Match Encoding

4.2.2 マッチの長さのコード化

   Length of 3 is encoded with bit 0.

3の長さはビット0でコード化されます。

   Length values from 4 to 7 are encoded as 10 followed by lower 2 bits
   of the value.

価値の低級2ビットに従って10が続いて、4〜7までの長さの値はコード化されます。

   Length values from 8 to 15 are encoded as 110 followed by lower 3
   bits of the value.

価値の低級3ビットに従って110が続いて、8〜15までの長さの値はコード化されます。

   Length values from 16 to 31 are encoded as 1110 followed by lower 4
   bits of the value.

価値の低級4ビットが支えていて、16〜31までの長さの値は1110としてコード化されます。

Pall                         Informational                      [Page 7]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[7ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

   Length values from 32 to 63 are encoded as 11110 followed by lower 5
   bits of the value.

価値の低級5ビットに従って11110が続いて、32〜63までの長さの値はコード化されます。

   Length values from 64 to 127 are encoded as 111110 followed by lower
   6 bits of the value.

価値の低級6ビットに従って111110が続いて、64〜127までの長さの値はコード化されます。

   Length values from 128 to 255 are encoded as 1111110 followed by
   lower 7 bits of the value.

価値の低級7ビットに従って1111110が続いて、128〜255までの長さの値はコード化されます。

   Length values from 256 to 511 are encoded as 11111110 followed by
   lower 8 bits of the value.

価値の低級8ビットに従って11111110が続いて、256〜511までの長さの値はコード化されます。

   Length values from 512 to 1023 are encoded as 111111110 followed by
   lower 9 bits of the value.

価値の低級9ビットに従って111111110が続いて、512〜1023年までの長さの値はコード化されます。

   Length values from 1024 to 2047 are encoded as 1111111110 followed by
   lower 10 bits of the value.

価値の低級10ビットに従って1111111110が続いて、1024年から2047年までの長さの値はコード化されます。

   Length values from 2048 to 4095 are encoded as 11111111110 followed
   by lower 11 bits of the value.

価値の低級11ビットに従って11111111110が続いて、2048年から4095年までの長さの値はコード化されます。

   Length values from 4096 to 8191 are encoded as 111111111110 followed
   by lower 12 bits of the value.

価値の低級12ビットに従って111111111110が続いて、4096年から8191年までの長さの値はコード化されます。

   Examples: Length of 15 is encoded as:           110 111
             Length of 120 is encoded as:       111110 111000
             Length of 4097 is encoded as:111111111110 000000000001

例: 15の長さは以下としてコード化されます。 120の110 111の長さは以下としてコード化されます。 4097年の長さがコード化される111110 111000: 111111111110 000000000001

   The largest Length value that can be encoded is 8191.

コード化できる中で最も大きいLength値は8191です。

4.3  Synchronization

4.3 同期

   Packets may be lost during transfer. If the decompressor maintained
   coherency count does not match the coherency count received in the
   compressed packet, the decompressor drops the packet and sends a CCP
   Reset-Request packet. The compressor on receiving this packet flushes
   the history buffer and sets the FLUSHED bit in the next packet it
   sends. The decompressor on receiving a packet with its FLUSHED bit
   set flushes its history buffer and sets its coherency count to the
   one transmitted by the compressor in that packet. Thus
   synchronization is achieved without a CCP Reset-Ack packet.

パケットは転送の間、失われるかもしれません。 減圧装置の維持された一貫性カウントが圧縮されたパケットで受けられた一貫性カウントに合っていないなら、減圧装置は、パケットを下げて、CCP Reset-リクエスト・パケットを送ります。 このパケットを受けるときのコンプレッサーは、歴史バッファを洗い流して、それが送る次のパケットにFLUSHEDビットをはめ込みます。 FLUSHEDビットがセットした状態でパケットを受けるときの減圧装置は、そのパケットでコンプレッサーによって伝えられたものに、歴史バッファを洗い流して、一貫性カウントを設定します。 したがって、同期はCCP Reset-Ackパケットなしで達成されます。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Pall                         Informational                      [Page 8]

RFC 2118                     MPPC Protocol                    March 1997

1997年の[8ページ]情報のRFC2118MPPCプロトコル行進のときに、気がぬけてください。

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, Novell, June 1996.

[2] 底ならし革、D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962、ノベル、1996年6月。

   [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月。

Acknowledgments

承認

   Thomas Dimitri made significant contributions towards the design and
   development of Microsoft Point-To-Point Compression Protocol. Robert
   Friend of Stac Technology provided editoral input.

トーマスディミトリはマイクロソフトのPointからポイントのデザインと開発に向かった重要な貢献をCompressionプロトコルにしました。 Stac TechnologyのロバートFriendはeditoral入力を提供しました。

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

Author's Address

作者のアドレス

   Questions about this memo can also be directed to:

また、このメモに関する質問による以下のことよう指示できます。

         Gurdeep Singh Pall
         1, Microsoft Way,
         Redmond, WA 98052

レッドモンド、ワシントン GurdeepシンPall1、マイクロソフト道、98052

         (206) 882-8080

(206) 882-8080

         Email: gurdeep@microsoft.com

メール: gurdeep@microsoft.com

Pall                         Informational                      [Page 9]

祭服情報です。[9ページ]