RFC1976 日本語訳

Network Working Group                                       K. Schneider
Request for Comments: 1976                                    S. Venters
Category: Informational                                     ADTRAN, Inc.
                                                             August 1996

コメントを求めるワーキンググループK.シュナイダーの要求をネットワークでつないでください: 1976秒間母カテゴリ: 情報のADTRAN Inc.1996年8月

  PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)

回路を終えるデータ設備のデータ圧縮のためのppp(DCE)

Status of This 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.  PPP
   defines an extensible Link Control Protocol, and proposes a family of
   Network Control Protocols for establishing and configuring different
   network-layer protocols.

Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するために広げることができるLink Controlプロトコルを定義して、Network Controlプロトコルのファミリーを提案します。

   The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a
   standard method for encapsulating and transporting serial data over a
   PPP link.  The PPP Compression Control Protocol [3] provides a
   standard method for selecting and using a compression protocol to
   provide for data compression on a PPP link.

PPP Serial Data Transportプロトコル(PPP-SDTP)[2]はPPPリンクの上にシリアルデータをカプセル化して、輸送するための標準方法を提供します。 PPP Compression Controlプロトコル[3]はPPPリンクの上にデータ圧縮に備えるのに圧縮プロトコルを選択して、使用するための標準方法を提供します。

   This document defines a specific set of parameters for these
   protocols and an LCP extension to define a standard way of using PPP
   for data compression of serial data in Data Circuit-Terminating
   Equipment (DCE).

このドキュメントはData Circuit-終わりEquipmentのシリアルデータのデータ圧縮にPPPを使用する標準の方法(DCE)でこれらのプロトコルとLCP拡張子が定義する特定のセットのパラメタを定義します。

Table of Contents

目次

     1.     Introduction ..........................................    2
        1.1       Specification of Requirements ...................    2
        1.2       Terminology .....................................    3
     2.     Modes of Operation ....................................    3
     3.     PPP Link Control Protocol Extension ...................    4
     4.     Required PPP Elements .................................    4
        4.1       Required Configuration Options and Parameters ...    5
     5.     Mode-1 Requirements ...................................    6
        5.1       Detailed Mode-1 Example .........................    7
     6.     Initial Handshake Operation ...........................    8
     7.     Security ..............................................    9
     8.     References ............................................    9
     CHAIR'S ADDRESS ..............................................    9

1. 序論… 2 1.1 要件の仕様… 2 1.2用語… 3 2. 操作のモード… 3 3. pppは制御プロトコル拡大をリンクします… 4 4. PPP Elementsが必要でした… 4 4.1 設定オプションとパラメタを必要とします… 5 5. モード-1要件… 6 5.1はモード-1の例を詳しく述べました… 7 6. 握手操作に頭文字をつけてください… 8 7. セキュリティ… 9 8. 参照… 9 議長のアドレス… 9

Schneider & Venters          Informational                      [Page 1]

RFC 1976                        PPP DCE                      August 1996

[1ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

     AUTHORS' ADDRESSES ...........................................   10

作者のアドレス… 10

1.  Introduction

1. 序論

   This document is a product of the TR30.1 ad hoc committee on
   compression of synchronous data.  It represents a component of a
   proposal to use PPP to provide compression of synchronous serial data
   in DSU/CSUs.

このドキュメントは同期データの要約のTR30.1専門委員会の製品です。 それはDSU/CSUsでの同期シリアルデータの要約を提供するのにPPPを使用するという提案の成分を表します。

   PPP [1] has three main components:

PPP[1]には、3つの主なコンポーネントがあります:

      1. A method for encapsulating multi-protocol datagrams.

1. マルチプロトコルデータグラムをカプセル化するためのメソッド。

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。

      3. A family of Network Control Protocols for establishing and
         configuring different network-layer protocols.

3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコルのファミリー。

   In addition to providing support for multi-protocol datagrams, the
   Point-to-Point Protocol (PPP) [1] has defined an effective and robust
   negotiating mechanism that can be used on point to point links.  When
   used in conjunction with the PPP Compression Control Protocol [3] and
   one of the PPP Compression Protocols [4], PPP provides an
   interoperable method of employing data compression on a point-to-
   point link.

マルチプロトコルデータグラムのサポートを提供することに加えて、Pointからポイントへのプロトコル(PPP)[1]はリンクを指すのにポイントの上で使用できる有効で強健な交渉メカニズムを定義しました。 PPP Compression Controlプロトコル[3]とPPP Compressionプロトコル[4]の1つに関連して使用されると、PPPはポイントからポイントへのリンクの上にデータ圧縮を使う共同利用できるメソッドを提供します。

   The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial
   Data Control Protocol (PPP-SDCP) [2] have been developed to allow
   serial data to be carried within a PPP packet.  PPP-SDTP uses a
   terminal adaption header based on that of ITU-T Recommendation V.120
   [5].

PPP Serial Data Transportプロトコル(PPP-SDTP)とPPP Serial Data Controlプロトコル(PPP-SDCP)[2]は、シリアルデータがPPPパケットの中で運ばれるのを許容するために開発されました。 PPP-SDTPはITU-T Recommendation V.120[5]のものに基づく端末の適応ヘッダーを使用します。

1.1.  Specification of Requirements

1.1. 要件の仕様

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

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

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

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

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

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

   SHOULD    This word, or the adjective "recommended", means that there
             may exist valid reasons in particular circumstances to
             ignore this item, but the full implications must be
             understood and carefully weighed before choosing a

「推薦される」というSHOULD This単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、aを選ぶ前に、慎重に熟慮しなければなりません。

Schneider & Venters          Informational                      [Page 2]

RFC 1976                        PPP DCE                      August 1996

[2ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

             different course.

異なったコース。

   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つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。

1.2.  Terminology

1.2. 用語

   This document frequently uses the following terms:

このドキュメントは頻繁に次の用語を使用します:

   datagram  The unit of transmission in the network layer (such as IP).
             A datagram may be encapsulated in one or more packets
             passed to the data link layer.

データグラム、ネットワーク層(IPなどの)における、トランスミッションのユニット。 データグラムはデータ・リンク層に通過された1つ以上のパケットでカプセル化されるかもしれません。

   frame     The unit of transmission at the data link layer.  A frame
             may include a header and/or a trailer, along with some
             number of units of data.

データ・リンク層でトランスミッションのユニットを縁どってください。 フレームは何らかの数のユニットのデータに伴うヘッダー、そして/または、トレーラを含むかもしれません。

   packet    The basic unit of encapsulation, which is passed across the
             interface between the network layer and the data link
             layer.  A packet is usually mapped to a frame; the
             exceptions are when data link layer fragmentation is being
             performed, or when multiple packets are incorporated into a
             single frame.

パケットはカプセル化(ネットワーク層とデータ・リンク層とのインタフェースの向こう側に通過されるもの)の原単位です。 通常、パケットはフレームに写像されます。 例外はデータ・リンク層断片化がいつ実行されているか、そして、または複数のパケットがいつシングルフレームに法人組織であるかということです。

   peer      The other end of the point-to-point link.

他が終わらせるポイントツーポイント接続の同輩。

   silently discard
             This means the implementation discards the packet without
             further processing.  The implementation SHOULD provide the
             capability of logging the error, including the contents of
             the silently discarded packet, and SHOULD record the event
             in a statistics counter.

さらに処理しながら、静かにThis手段を実装がパケットを捨てる捨ててください。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。

2.  Modes of Operation

2. 運転モード

   This document provides for three modes of operation for DCE devices:
   Mode-0 represents transparent operation; Mode-1 a simplified,
   predefined compression format; and Mode-2, a full PPP implementation
   providing compression of serial data.

このドキュメントはDCEデバイスのために3つの運転モードに備えます: モード-0はわかりやすい操作を表します。 簡易型の、そして、事前に定義された圧縮あたりモード-1形式。 Mode-2、シリアルデータの要約を提供する完全なPPP実装。

   Mode-0 represents the operating mode of currently deployed DCEs that
   operate in transparent mode, without any DCE-to-DCE protocols.
   Mode-1 devices implement data compression upon detecting an initial
   handshake, which is implemented via an newly defined LCP
   Configuration Option called the DCE-Identifier.  The DCE-Identifier

モード-0はDCEからDCEへの少しもプロトコルなしで透過モードで作動するDCEsであると配布された現在のオペレーティング・モードを表します。 初期の握手を検出するとき、モード-1デバイスはデータ圧縮を実装します。(握手はDCE-識別子と呼ばれる新たに定義されたLCP Configuration Optionを通して実装されます)。 DCE-識別子

Schneider & Venters          Informational                      [Page 3]

RFC 1976                        PPP DCE                      August 1996

[3ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

   is used both to distinguish DCE devices from PPP bridges and routers,
   and to all Mode-1 and Mode-2 DCE devices to interoperate, via its
   Mode parameter.  In Mode-1, the parameters of operation are not
   negotiable.  Mode-2 devices implement the full LCP state machine and
   are therefore capable of negotiating alternatives to the default set
   of paramaters and options.  Mode-2 devices must also support Mode-1
   operation, and fall-back to such operation when connected to a Mode-1
   device.  The mechanism of the Mode-1/Mode-2 handshake is given in
   Section 7.

ともに共同利用するためにModeパラメタでPPPブリッジとルータと、すべてのMode-1とMode-2 DCEデバイスに区別するために、DCEデバイスを使用されます。 Mode-1では、操作のパラメタは交渉可能ではありません。 モード-2台のデバイスが、完全なLCP州のマシンを実装して、したがって、paramatersとオプションについてデフォルトへの代替手段が設定する交渉できます。 また、Mode-1デバイスに接続されると、モード-2台のデバイスが、Mode-1が操作と、後退であるとそのような操作にサポートしなければなりません。 セクション7でMode-1/モード-2握手のメカニズムを与えます。

3.  PPP Link Control Protocol Extension

3. pppリンク制御プロトコル拡大

   The use of PPP in Compression DCE requires the use of an additional
   LCP Configuration Option:

Compression DCEにおけるPPPの使用は追加LCP Configuration Optionの使用を必要とします:

      25  DCE-Identifier

25DCE-識別子

   DCE-Identifier

DCE-識別子

      The presence of this option indicates that the system sending it
      is Data Circuit-Terminating Equipment (DCE) that desires to
      establish a serial data compression link.

このオプションの存在は、それを送るシステムがシリアルデータ圧縮リンクを設立することを望んでいるData Circuit-終わりEquipment(DCE)であることを示します。

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |      Mode     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| モード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

タイプ

         25

25

      Length

長さ

         3

3

      Mode

モード

         1   Mode-1 (No Additional Negotiation)
         2   Mode-2 (Full PPP Negotiation and State Machine)

1 モード-1(追加交渉がない)2モード-2(交渉と州が機械加工する完全なppp)

4.  Required PPP Elements

4. 必要なPPP Elements

   Unlike PPP's native bridge/router environment, the minimum
   requirement for use of PPP in DCE equipment is not simply
   interoperability, but rather interoperability with effective data

PPPのネイティブのブリッジ/ルータ環境と異なって、DCE設備におけるPPPの使用のための必要最小限は単に相互運用性ではなく、むしろ有効なデータがある相互運用性です。

Schneider & Venters          Informational                      [Page 4]

RFC 1976                        PPP DCE                      August 1996

[4ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

   compression.  With this in mind, it is desirable to specify a minimum
   PPP feature set, that is somewhat different than that of a normal PPP
   bridge/router requirement.

圧縮。 これが念頭にある状態で、それは、最小のPPP特徴セットを指定するのにおいて望ましくて、すなわち、正常なPPPブリッジ/ルータ要件のものといくらか異なっています。

   This different feature set includes: support for compression, support
   of a single default compression algorithm, support of Protocol-Field
   compression, support of Address-and-Control-Field-Compression,
   support of PPP-SDTP, etc.

この異なった特徴セットは: 圧縮のサポート、ただ一つのデフォルト圧縮アルゴリズムのサポート、プロトコル分野圧縮のサポート、Addressとコントロール分野圧縮のサポート、PPP-SDTPのサポートなど

   The minimum feature set includes the following protocols:

最小の特徴セットは以下のプロトコルを含んでいます:

      PPP Link Control Protocol (Mode-1 must include a subset) [1]
      PPP in HDLC-like Framing [6]
      PPP Compression Control Protocol (Mode-2 only) [3]
      PPP LZS-DCP Compression Protocol [4]
      PPP Serial Data Transport Protocol [2]
      PPP Serial Data Control Protocol (Mode-2 only) [2]

[1] HDLCのようなFraming[6]PPP Compression Controlプロトコル(モード-2専用)[3]PPP LZS-DCP Compressionプロトコル[4]PPP Serial Data Transportプロトコル[2]PPP Serial Data Controlプロトコル(モード-2専用)のPPP Link Controlプロトコル(モード-1は部分集合を含まなければならない)PPP[2]

   The Stacker-LZS algorithm from Stac Electronics was chosen as the
   default compression algorithm for DCE devices.  This decision was
   made by the TR30.1 ad hoc based on licensing issues (agreeing to
   non-discriminatory and reasonable terms), compression ratios, its
   efficient use of processor and memory resources, and speed
   scalability.  A compression protocol incorporating in-band
   synchronization signaling was defined for the Stacker algorithm and
   selected for the default compression protocol.  This protocol is
   known as the PPP LZS-DCP Compression Protocol [4].  Although the PPP
   LZS-DCP Compression Protocol specifies a number of formats and
   history management options, only the default format with a single
   history must be implemented.

Stac ElectronicsからのStacker-LZSアルゴリズムはDCEデバイスのためのデフォルト圧縮アルゴリズムとして選ばれました。 この決定はライセンシング問題(非差別していて妥当な用語に同意した)、圧縮比、プロセッサの効率的な使用、メモリリソース、および速度スケーラビリティに基づいてTR30.1によって臨時にされました。 バンドにおける同期シグナリングを取り入れる圧縮プロトコルは、Stackerアルゴリズムのために定義されて、デフォルト圧縮プロトコルのために選択されました。 このプロトコルはPPP LZS-DCP Compressionプロトコル[4]として知られています。 PPP LZS-DCP Compressionプロトコルは多くの形式と歴史管理オプションを指定しますが、ただ一つの歴史に伴う省略時書式だけを実装しなければなりません。

4.1.  Required Configuration Options and Parameters

4.1. 必要な設定オプションとパラメタ

   To ensure that implementations are able to interoperate with
   effective data compression, a required set of Configuration Options
   are specified.  These Options are assumed in Mode-1, and are
   negotiated in Mode-2, using the standard PPP negotiation state
   machine.  (Mode-1 uses a fixed packet format with a predetermined set
   of values for LCP, LZS-DCP, and SDTP Configuration
   Options/parameters.  The required values listed in this section are
   the predefined values.)

実装が効果的なデータ圧縮、Configuration Optionsの必要なセットで共同利用できるのを保証するのは指定されています。 標準のPPP交渉州のマシンを使用して、これらのOptionsはMode-1で想定されて、Mode-2で交渉されます。 (モード-1はLCP、LZS-DCP、およびSDTP Configuration Options/パラメタに予定されたセットの値がある固定パケット・フォーマットを使用します。 このセクションで記載された必要な値は事前に定義された値です。)

   The following LCP Configuration Options [7] MUST be supported:

以下のLCP Configuration Options[7]をサポートしなければなりません:

      Maximum-Receive-Unit                 1550
      Address/Control-Field-Compression    Yes
      Protocol-Field-Compression           Yes

1550年の最大がユニットを受けているコントロール分野アドレス/圧縮はいプロトコル分野圧縮はい

Schneider & Venters          Informational                      [Page 5]

RFC 1976                        PPP DCE                      August 1996

[5ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

   The following CCP Configuration Option MUST be supported:

以下のCCP Configuration Optionをサポートしなければなりません:

      Compression-Type                      23 (LZS-DCP)

圧縮タイプ23(LZS-DCP)

   The following default LZS-DCP Configuration Options MUST be
   supported:

以下のデフォルトLZS-DCP Configuration Optionsをサポートしなければなりません:

      Check-Mode                    3 (sequence + LCB)
      History-Count                 1 (single history)
      Process-Mode                  0 (None)

チェックモード3(系列+LCB)歴史カウント1(ただ一つの歴史)プロセスモード0(なにも)

   The default SDTP/SDCP Configuration Options MUST be supported.  They
   are:

デフォルトSDTP/SDCP Configuration Optionsをサポートしなければなりません。 それらは以下の通りです。

      Packet-Format:                Header-Last
      Header-Type:                  H-Only
      Multiple-Packets:             Off
      Multi-Port:                   Off
      Transport-Mode:               HDLC-Synchronous
      Maximum-Frame-Size:           10,000 bytes
      Allow-Odd-Frames:             Off
      FCS-Type:                     Transparent-Transport
      Flow-Expiration-Time:         100

パケット・フォーマット: ヘッダー最後のヘッダータイプ: Hだけ複数のパケット: オフマルチポート: オフ交通機関: HDLC同期の最大のフレーム・サイズ: 1万バイトのAllowの変なフレーム: オフFCS-タイプ: わかりやすい輸送流れ満了時間: 100

5.  Mode-1 Requirements

5. モード-1要件

   DSUs that use only Mode-1 (non-negotiate mode) use only a
   predetermined set of PPP packets.  In addition to a fixed data packet
   format, two fixed formats are used to differentiate between Mode-1
   devices and Mode-0 (transparent) devices.  Mode-1 devices are
   designed to operate using compression if a peer has the same
   capability, or revert to transparent operation (Mode-0) if the peer
   does not support standard compression.

Mode-1だけを使用するDSUs、(非、交渉、モード) 予定されたセットのPPPパケットだけを使用してください。 固定データパケット・フォーマットに加えて、2つの固定フォーマットが、Mode-1デバイスとMode-0の(透明)のデバイスを区別するのに使用されます。 モード-1デバイスが同輩に同じ能力があるなら圧縮を使用することで作動するように設計されているか、または同輩が標準の圧縮をサポートしないなら、わかりやすい操作(モード-0)に戻ってください。

   Mode-1 devices use LZS-DCP Compression Packets as specified in [4].
   These packets include the capabilities of DCP:  Reset-Request and
   Acknowledge, Compressed/Transparent, etc.  Since the packets include
   signalling, these packets can be sent with an empty data field to
   signal a reset request if no data packets are ready for piggy-backed
   signalling.

モード-1デバイスは[4]の指定されるとしてのLZS-DCP Compression Packetsを使用します。 これらのパケットはDCPの能力を含んでいます: /透明な状態で圧縮されて、などをリセットして要求して、承認してください。 パケットが、合図するのを含んでいるので、どんなデータ・パケットも便乗している合図の準備ができていないなら、リセット要求に合図するために人影のないデータ・フィールドと共にこれらのパケットを送ることができます。

   Exactly one LZS-DCP packet is encapsulated in the PPP Information
   field, where the PPP Protocol field indicates type 00FD (Compression
   Protocol).  Exactly one SDTP packet is transported by each LZS-DCP
   data packet.

ちょうど1つのLZS-DCPパケットがPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野はタイプ00FD(圧縮プロトコル)を示します。 ちょうど1つのSDTPパケットがそれぞれのLZS-DCPデータ・パケットによって輸送されます。

Schneider & Venters          Informational                      [Page 6]

RFC 1976                        PPP DCE                      August 1996

[6ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

   Operation in Mode-1 implies a set of predetermined values for LCP,
   LZS-DCP, and SDTP configuration options and parameters, using the
   values listed in the preceding section.

Mode-1での操作はLCP、LZS-DCP、SDTP設定オプション、およびパラメタのために1セットの予定された値を含意します、先行するセクションで記載された値を使用して。

   The following PPP packets are permitted and recognized:

以下のPPPパケットは、受入れられて、認識されます:

      LCP Configure-Request with DCE Mode-1 Configuration Option
      LCP Configure-Ack with DCE Mode-1 Configuration Option
      LZS-DCP Packet with the data field containing an SDTP packet
      LZS-DCP Packet with an empty data field

人影のないデータ・フィールドがあるデータ・フィールドがSDTPパケットを含んでいるDCE Mode-1 Configuration Option LZS-DCP PacketとDCE Mode-1 Configuration Option LCP Configure-AckとのLCP Configure-要求LZS-DCP Packet

   Protocol-Field-Compression and Address-and-Control-Field-Compression
   is used on all packets except the handshake packets (LCP packets).

プロトコル分野圧縮、Address、およびコントロール分野圧縮は握手パケット(LCPパケット)以外のすべてのパケットの上で使用されます。

   Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST
   Acknowledge the request.

Mode-1要求を受け取るどんなMode-1やMode-2 DCEもそうしなければならない、Acknowledge、要求。

5.1.  Detailed Mode-1 Example

5.1. 詳細なモード-1の例

   Detailed Example when using Mode-1 on a point-to-point leased or
   circuit switched link (using PPP in HDLC-like Framing [6]) (data
   shown is after flags and inserted 0s are removed; lower case letters
   and numbers represent actual values, uppercase represent data fields
   whose values may vary from packet to packet; parentheses surrounding
   a field indicate that the field may not be present in all packets of
   that type):

ポイントツーポイントのMode-1が賃貸した使用か回路が切り替わったとき、詳細なExampleがリンクする、(HDLCのようなFraming[6])(挿入されて、0を取り除きます; 大文字はパケットによって値が異なるかもしれないデータ・フィールドを表します; 示されたデータは後旗です、そして、小文字と数は実価を表します、そして、分野を囲む括弧は分野がそのタイプのすべてのパケットに存在していないかもしれないのを示します)でPPPを使用します:

      LCP Configure-Request:
                                               Config. Opt.
      Addr. Ctl.  PID    Code ID   Length Type Lngth Mode
      +----+----+-------+----+----+-------+----+----+----+-----+
      | ff | 03 | c0 21 | 01 | 00 | 00 07 | 21 | 03 | 01 | FCS |
      +----+----+-------+----+----+-------+----+----+----+-----+

LCP、要求を構成します: コンフィグ選んでください。 Addr。 Ctl。 PIDコードID長さのタイプLngthモード+----+----+-------+----+----+-------+----+----+----+-----+ | ff| 03 | c0 21| 01 | 00 | 00 07 | 21 | 03 | 01 | FCS| +----+----+-------+----+----+-------+----+----+----+-----+

      LCP Configure-Ack:

LCP、Ackを構成します:

                                               Config. Opt.
      Addr. Ctl.  PID    Code ID   Length Type Lngth Mode
      +----+----+-------+----+----+-------+----+----+----+-----+
      | ff | 03 | c0 21 | 02 | 00 | 00 07 | 21 | 03 | 01 | FCS |
      +----+----+-------+----+----+-------+----+----+----+-----+

コンフィグ選んでください。 Addr。 Ctl。 PIDコードID長さのタイプLngthモード+----+----+-------+----+----+-------+----+----+----+-----+ | ff| 03 | c0 21| 02 | 00 | 00 07 | 21 | 03 | 01 | FCS| +----+----+-------+----+----+-------+----+----+----+-----+

      LZS-DCP Packet:

LZS-DCPパケット:

       PID  DCP
      +----+----+------+------ -+-------+-----+
      | fd | HD | (SQ) | (DATA) | (LCB) | FCS |
      +----+----+------+--------+-------+-----+

PID DCP+----+----+------+------ -+-------+-----+ | fd| HD| (シンガポール航空の便名) | (データ) | (LCB) | FCS| +----+----+------+--------+-------+-----+

Schneider & Venters          Informational                      [Page 7]

RFC 1976                        PPP DCE                      August 1996

[7ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

      The DATA field contains a compressed or uncompressed SDTP-PDU.
      The LCB field is only present on a packet containing compressed
      data.  The Sequence Number and Data fields are only present on
      packets that contain data.

DATA分野は圧縮されたか解凍されたSDTP-PDUを含んでいます。 圧縮されたデータを含んでいて、LCB分野は単にパケットに存在しています。 Sequence NumberとData分野は単にデータを含むパケットに存在しています。

                        +----+------+----+
            SDTP-PDU:   | 49 | DATA | HD |
                        +----+------+----+

+----+------+----+ SDTP-PDU: | 49 | データ| HD| +----+------+----+

6.  Initial Handshake Operation

6. 初期の握手操作

   When a unit is powered up, or when the lower layer signals that the
   peer has gone out of service and returned, the handshake procedure is
   initiated.  The handshake procedure for Mode-1 and Mode-2 devices is
   described below.

いつ、ユニットがあるかがエネルギー消費量を上げたか、または下層が、同輩が使われなくなるようになって、戻ったのを示すと、握手手順は着手されます。 Mode-1とMode-2デバイスのための握手手順は以下で説明されます。

   Mode-1:

モード-1:

      When starting Mode-1, each DCE sends out an LCP Configure-Request
      packet containing only the DCE-Identifier LCP Configuration Option
      described in Section 3, with the with the Mode Field set to a
      value of 1.  When a DCE device receives such a packet, it must
      answer with an LCP Configure-Ack packet.  In each of these
      packets, the identifier field is set to 0.  If the originator of
      the Configure-Request packet does not receive a Configure-Ack
      response within a user configurable time T1, the unit MUST revert
      to transparent (Mode-0) operation.

いつ、Mode-1、DCEがLCP Configuration Optionがセクション3で説明したDCE-識別子だけを含むLCP Configure-リクエスト・パケットから送るそれぞれを始めるか、1の値に用意ができているMode Field DCEデバイスがそのようなパケットを受けるとき、それにLCP Configure-Ackパケットで答えなければなりません。 それぞれのこれらのパケットでは、識別子分野は0に設定されます。 Configure-リクエスト・パケットの創始者が構成可能な時間T1、ユニットがそうしなければならないユーザの中でConfigure-Ack応答を受けないなら、わかりやすい(モード-0)操作に戻ってください。

   Mode-2:

モード-2:

      A Mode-2 device will first try to operate in Mode-2 by starting
      PPP normally, following the state machine described in [1].  The
      LCP Configure-Request MUST include the DCE-Identifier
      Configuration Option with the Mode Field set to 2.  If the unit
      receives a Configure-Reject Packet Containing the DCE-Identifier,
      the unit MUST revert immediately to transparent (Mode-0)
      operation.  If the LCP state machine times out because a response
      was not received in user configurable time T2, or if a Mode-1
      Configuration-Request packet is received, the unit attempts to
      operate in Mode-1 by following the procedure listed above,
      ultimately reverting to Mode-0 operation if the Mode-1 procedure
      times out.

Mode-2デバイスは最初にMode-2で通常、PPPを始動することによって、作動しようとするでしょう、[1]で説明された州のマシンに続いて。 LCP Configure-要求はMode FieldセットがあるDCE-識別子Configuration Optionを2に含まなければなりません。 ユニットがConfigure-廃棄物Packet Containing DCE-識別子を受け取るなら、ユニットはすぐわかりやすい(モード-0)操作に戻らなければなりません。 応答がユーザの構成可能な時間T2で受けられなかったのでLCPがマシン回を述べるか、またはMode-1 Configuration-リクエスト・パケットが受け取られているなら、ユニットは、Mode-1でMode-1手順回数であるなら結局Mode-0操作に戻って、上に記載された手順に外に従うことで作動するのを試みます。

   In either case, the unit is not prohibited from sending multiple
   Configuration-Request packets before the applicable timer (T1, T2)
   expires.  A unit may also initiate the handshake procedure at any
   time.

どちらの場合ではも、ユニットは適切なタイマ(T1、T2)が期限が切れる前に複数のConfiguration-リクエスト・パケットを送るのが禁止されていません。 また、ユニットはいつでも、握手手順に着手するかもしれません。

Schneider & Venters          Informational                      [Page 8]

RFC 1976                        PPP DCE                      August 1996

[8ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

7.  Security Considerations

7. セキュリティ問題

   Security issues are not discussed in this memo.

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

8.  References

8. 参照

   [1]    Simpson, W., ed., "The Point-to-Point Protocol (PPP)", STD
          51, RFC 1661, July 1994.

[1] シンプソン、W.、教育、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月1994日

   [2]    Schneider, K., and S. Venters, "PPP Serial Data Transport
          Protocol (PPP-SDTP)", RFC 1963, August 1996.

[2]シュナイダー、K.、およびS.母、「pppシリアルデータトランスポート・プロトコル(ppp-SDTP)」、RFC1963、1996年8月。

   [3]    Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
          1962, June 1996.

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

   [4]    Lutz, R., "PPP LZS-DCP Compression Protocol", RFC 1967
          August 1996.

[4] ルッツ、R.、「ppp LZS-DCP圧縮プロトコル」、RFC1967 1996年8月。

   [5]    CCITT Recommendation V.120, "Support by an ISDN of Data
          Terminal Equipment with V-Series Type Interfaces with
          Provision for Statistical Multiplexing (revised 1992)", ITU-T,
          1993.

[5] CCITT推薦V.120、「支給とのV-シリーズタイプインタフェースがあるデータ端末装置のISDNによる統計的多重化(1992を改訂する)のサポート」、ITU-T、1993。

   [6]    Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
          January 1994.

[6] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年1月。

   [7]    Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.

[7] シンプソン、W.、「ppp LCP拡張子」、RFC1570、1994年1月。

Chair's Address

議長のアドレス

   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を昇ります。

   EMail: karl@ascend.com

メール: karl@ascend.com

Schneider & Venters          Informational                      [Page 9]

RFC 1976                        PPP DCE                      August 1996

[9ページ]RFC1976ppp DCE1996年8月の情報のシュナイダーと母

Authors' Addresses

作者のアドレス

   Questions about this memo can also be directed to:

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

   Kevin Schneider
   Adtran, Inc.
   901 Explorer Blvd.
   Huntsville, AL 35806-2807

ケビンシュナイダーAdtran Inc.901エクスプローラーBlvd. ハンツビル、AL35806-2807

   Phone: (205) 971-8000
   EMail:  kevin@adtran.com

以下に電話をしてください。 (205) 971-8000 メールしてください: kevin@adtran.com

   Stuart Venters
   Adtran, Inc.
   901 Explorer Blvd.
   Huntsville, AL 35806-2807

スチュアート母、Adtran Inc.901エクスプローラーBlvd. ハンツビル、AL35806-2807

   Phone: (205) 971-8000
   EMail: sventers@adtran.com

以下に電話をしてください。 (205) 971-8000 メールしてください: sventers@adtran.com

Schneider & Venters          Informational                     [Page 10]

シュナイダーと母、情報[10ページ]