RFC1993 日本語訳

1993 PPP Gandalf FZA Compression Protocol. A. Barbir, D. Carr, W.Simpson. August 1996. (Format: TXT=9811 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          A. Barbir
Request for Comments: 1993                                       Gandalf
Category: Informational                                          D. Carr
                                                               Newbridge
                                                              W. Simpson
                                                              DayDreamer
                                                             August 1996

Barbirがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1993年のガンダルフカテゴリ: 情報のD.のカーNewbridge W.シンプソン空想家1996年8月

                  PPP Gandalf FZA Compression Protocol

pppガンダルフFZA圧縮プロトコル

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。

   The PPP Compression Control Protocol [2] provides a method to
   negotiate and utilize compression protocols over PPP encapsulated
   links.

プロトコル[2]がPPPの上で圧縮プロトコルを交渉して、利用する方法を供給するPPP Compression Controlはリンクを要約しました。

   This document describes the use of the Gandalf FZA data compression
   algorithm [3] for compressing PPP encapsulated packets.

[3] PPPを圧縮するとパケットがカプセルに入れられたので、このドキュメントはガンダルフFZAデータ圧縮アルゴリズムの使用について説明します。

Table of Contents

目次

     1.     Introduction ..........................................    1
        1.1       Licensing .......................................    1
     2.     FZA Packets ...........................................    2
        2.1       Packet Format ...................................    3
     3.     Configuration Option Format ...........................    4
     SECURITY CONSIDERATIONS ......................................    4
     ACKNOWLEDGEMENTS .............................................    5
     REFERENCES ...................................................    5
     CONTACTS .....................................................    5

1. 序論… 1 1.1 認可します。 1 2. FZAパケット… 2 2.1 パケット形式… 3 3. 設定オプション形式… 4 セキュリティ問題… 4つの承認… 5つの参照箇所… 5 連絡します。 5

Barbir, Carr & Simpson                                          [Page i]

RFC 1993                      Gandalf FZA                    August 1996

Barbir、カー、およびシンプソン[ページi]RFC1993ガンダルフFZA1996年8月

1.  Introduction

1. 序論

   FZA is a high performance LZ [4] derivative that maximizes
   compression at the expense of memory and CPU.  Compression
   performance can be adjusted based on CPU and memory available.

FZAはメモリとCPUを犠牲にして圧縮を最大にする高性能LZ[4]派生物です。 CPUと利用可能なメモリに基づいて圧縮性能を調整できます。

   Multiple PPP packets can be combined in a single compressed frame, or
   a single PPP packet can be spread across multiple frames.

単一の圧縮されたフレームで複数のPPPパケットを結合できますか、または複数のフレームの向こう側に単一のPPPパケットを広げることができます。

1.1.  Licensing

1.1. 認可

   Source and object licenses are available on a non-discriminatory
   basis for either a royalty or fixed price arrangement.  Patent
   indemnity is included with the license.

ソースと物のライセンスはロイヤリティか定価アレンジメントのどちらか非差別しているベースで手があいています。 特許保障はライセンスで含まれています。

Barbir, Carr & Simpson                                          [Page 1]

RFC 1993                      Gandalf FZA                    August 1996

Barbir、カー、およびシンプソン[1ページ]RFC1993ガンダルフFZA1996年8月

2.  FZA Packets

2. FZAパケット

   Before any FZA packets may be communicated, PPP must reach the
   Network-Layer Protocol phase.

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

   When the Compression Control Protocol (CCP) has reached the Opened
   state, and FZA is negotiated as the primary compression algorithm,
   the PPP Protocol field indicates type hex 00FB (link compressed
   datagram), or type hex 00FD (compressed datagram).

Compression Controlであるときに、プロトコル(CCP)はOpened状態に達して、一次圧密アルゴリズム、PPPプロトコル分野がタイプ十六進法00FBを示すか(圧縮されたデータグラムをリンクしてください)、またはタイプが00FDに魔法をかけるとき(データグラムを圧縮します)、FZAは交渉されます。

   The maximum length of the FZA datagram transmitted over a PPP link is
   the same as the maximum length of the Information field of a PPP
   encapsulated packet.

PPPリンクの上に送られたFZAデータグラムの最大の長さはPPPの情報分野の最大の長さがパケットをカプセルに入れったのと同じです。

   Padding

詰め物

      The FZA packets require the negotiation of the Self-Describing-
      Padding Configuration Option [5] at LCP Link Establishment.

FZAパケットはLCP Link特権階級でSelfについて説明している詰め物Configuration Option[5]の交渉を必要とします。

   Reliability and Sequencing

信頼性と配列

      The FZA algorithm expects a reliable link, as described in "PPP
      Reliable Transmission" [6].

FZAアルゴリズムは「pppの信頼できる送信」[6]で説明されるように信頼できるリンクを予想します。

      FZA expects the packets to be delivered in sequence.

FZAは、パケットが連続して届けられると予想します。

   Data Expansion

データ展開

      The maximum expansion of Gandalf FZA is 2:1.  However, typical
      expansion on pre-compressed data is 1.01:1.  Expanded data is sent
      to maintain the integrity of the compression history.

ガンダルフFZAの最大の拡大は2:1です。 しかしながら、あらかじめ圧縮されたデータにおける典型的な拡大は1.01です: 1。 圧縮歴史の保全を維持するために拡張データを送ります。

      When the expansion exceeds the size of the peer's Maximum Receive
      Unit for the link, the expanded packet is sent in multiple PPP
      frames.  The compressed data contains an indication of the end of
      the original packet.

拡大が同輩のMaximum Receive Unitのサイズをリンクに超えているとき、複数のPPPフレームで拡張パケットを送ります。 圧縮されたデータはオリジナルのパケットの端のしるしを含んでいます。

Barbir, Carr & Simpson                                          [Page 2]

RFC 1993                      Gandalf FZA                    August 1996

Barbir、カー、およびシンプソン[2ページ]RFC1993ガンダルフFZA1996年8月

2.1.  Packet Format

2.1. パケット・フォーマット

   A summary of the Gandalf FZA packet format is shown below.  The
   fields are transmitted from left to right.

ガンダルフFZAパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |     Compressed Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル| データを圧縮します… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPP Protocol

pppプロトコル

      One or two octets.  The PPP Protocol field is described in the
      Point-to-Point Protocol Encapsulation [1].

1か2つの八重奏。 PPPプロトコル分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。

      Type 00FD is used when the PPP multilink protocol is not used,
      and/or "inside" a multilink bundle.  Type 00FB is used "outside"
      multilink, to compress independently on individual links of a
      multilink bundle.  This value MAY be compressed when LCP
      Protocol-Field-Compression is negotiated.

PPPマルチリンクプロトコルが使用されていないとき、タイプ00FDは使用されています、そして、“inside"はマルチリンクバンドルを使用します。 タイプ00FBはマルチリンクバンドルのマルチリンクの、そして、独自に湿布にオンな「外部」中古の個々のリンクです。 LCPプロトコル分野圧縮が交渉されるとき、この値は圧縮されるかもしれません。

   Compressed Data

圧縮されたデータ

      One or more octets.  The compressed PPP encapsulated packet(s).

1つ以上の八重奏。 圧縮されたPPPはパケットをカプセルに入れりました。

      Prior to compression, the uncompressed data begins with the
      original PPP Protocol number.  This value MAY be compressed when
      LCP Protocol-Field-Compression is negotiated.

圧縮の前に、解凍されたデータは元のPPPプロトコル番号で始まります。 LCPプロトコル分野圧縮が交渉されるとき、この値は圧縮されるかもしれません。

      The original Protocol number is followed by the original
      Information field.  The length of the original Information field
      before compression MUST NOT exceed the link Maximum Receive Unit
      (MRU).

元の情報分野は元のプロトコル番号のあとに続いています。 圧縮の前の元の情報分野の長さはリンクMaximum Receive Unit(MRU)を超えてはいけません。

      PPP Link Control Protocol packets MUST NOT be sent within
      compressed data.

圧縮されたデータの中でPPP Link Controlプロトコルパケットを送ってはいけません。

Barbir, Carr & Simpson                                          [Page 3]

RFC 1993                      Gandalf FZA                    August 1996

Barbir、カー、およびシンプソン[3ページ]RFC1993ガンダルフFZA1996年8月

3.  Configuration Option Format

3. 設定オプション形式

   Description

記述

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

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

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

ガンダルフ-FZA Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   History   |    Version ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 歴史| バージョン… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

タイプ

      19

19

   Length

長さ

      >= 3

>= 3

   History

歴史

      One octet.  The History field specifies the maximum size of the
      compression history in powers of 2.  Valid values range from 12 to
      15.

1つの八重奏。 歴史分野は2人の強国の圧縮歴史の最大サイズを指定します。 有効値は12〜15まで及びます。

      The peer is not required to send as many histories as the
      implementation indicates that it can accept.

実現が、それが受け入れることができるのを示すとき、同輩は同じくらい多くの歴史を送る必要はありません。

   Version

バージョン

      Zero or more octets of additional configuration information.  Any
      implementation that does not implement this information MUST send
      a Configure-Nak without this field.

追加設定情報のゼロか、より多くの八重奏。 この情報を実行しないどんな実現もこの分野なしでConfigure-Nakを送らなければなりません。

      The Version field is not present for FZA.

バージョン分野はFZAのために存在していません。

      The Version field is a single octet containing the value 1 for
      FZA+.

バージョン分野はFZA+のための値1を含むただ一つの八重奏です。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

Barbir, Carr & Simpson                                          [Page 4]

RFC 1993                      Gandalf FZA                    August 1996

Barbir、カー、およびシンプソン[4ページ]RFC1993ガンダルフFZA1996年8月

Acknowledgements

承認

   FZA was developed by David Carr while at Gandalf Data Limited.

ガンダルフData株式会社にある間、FZAはデビット・カーによって開発されました。

   FZA+ was an improvement by Abbie Barbir.

FZA+はアビーBarbirによる改良でした。

   Editting and formatting by William Simpson.

ウィリアムはシンプソンをEdittingして、フォーマットします。

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]   Barbir, A., "A New Fast Approximate Arithmetic Coder",
         Proceedings of IEEE 28th SouthEastern Symposium on Systems
         Theory (SSST), Baton Rouge, Louisiana, pages 482-486, April
         1996.

[3]Barbir、A.、「新しい速い概算的な計算符号化器」、Systems Theory(SSST)、バトンルージュ(ルイジアナ)482-486ページ(1996年4月)のIEEE第28SouthEastern SymposiumのProceedings。

   [4]   Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
         Data Compression", IEEE Transactions On Information Theory,
         Vol. IT-23, No. 3, May 1977.

[4] LempelとA.とZiv、J.、「連続したデータ圧縮のための普遍的なアルゴリズム」、情報理論におけるIEEE取引、Vol.IT-23(No.3)は1977がそうするかもしれません。

   [5]   Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
         DayDreamer, January 1994.

[5] シンプソン、W.、エディタ、「ppp LCP拡張子」、RFC1570、空想家、1994年1月。

   [6]   Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
         1994.

[6] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、ノベル、1994年7月。

Contacts

接触

   Licensing queries should be directed to:

質問を認可するのによる以下のことよう指示されるべきです。

   Michael Williams
   Director of Business Development
   Gandalf Data Limited
   130 Colonnade Road South
   Napean, Ontario, Canada  K2E 7M4
   (613) 274-6500 ext 6575

マイケルウィリアムズ営業担当取締役ガンダルフData株式会社130Colonnade Road Napean、南部オンタリオ、カナダK2E 7M4(613)274-6500ext6575

Barbir, Carr & Simpson                                          [Page 5]

RFC 1993                      Gandalf FZA                    August 1996

Barbir、カー、およびシンプソン[5ページ]RFC1993ガンダルフFZA1996年8月

   Comments should be submitted to the ietf-ppp@merit.edu mailing list.

ietf-ppp@merit.edu メーリングリストにコメントを提出するべきです。

   This document was reviewed by the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).

このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって再検討されました。

   The working group can be contacted via the current chair:

現在のいすを通してワーキンググループに連絡できます:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio  43221

カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。

          karl@MorningStar.com
          karl@Ascend.com

karl@MorningStar.com karl@Ascend.com

   Questions about this memo can also be directed to:

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

      Abdulkader Barbir
      Gandalf Data Limited
      130 Colonnade Road South
      Napean, Ontario, Canada  K2E 7M4
      (613) 274-6500 ext 8550

Abdulkader BarbirガンダルフData株式会社130Colonnade Road Napean、南部オンタリオ、カナダK2E 7M4(613)274-6500ext8550

          abarbir@gandalf.ca

abarbir@gandalf.ca

   Questions about this memo should not be directed to:

以下のことようこのメモに関する質問を指示するべきではありません。

      Dave Carr
      Newbridge Networks Corporation
      600 March Road
      P.O. Box 13600
      Kanata, Ontario, Canada, K2K 2E6

Kanata、デーヴカーニューブリッジネットワークス社600の3月の道路P.O. Box13600オンタリオ(カナダ)K2K2E6

          dcarr@newbridge.com

dcarr@newbridge.com

      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)

wsimpson@UMich.edu wsimpson@GreenDragon.com(都合のよい)です。

Barbir, Carr & Simpson                                          [Page 6]

Barbir、カー、およびシンプソン[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

複数のデータベースを切り替える方法(別データベースを使用する)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る