RFC1331 日本語訳
1331 The Point-to-Point Protocol (PPP) for the Transmission ofMulti-protocol Datagrams over Point-to-Point Links. W. Simpson. May 1992. (Format: TXT=129892 bytes) (Obsoletes RFC1171, RFC1172) (Obsoleted by RFC1548) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson Request for Comments: 1331 Daydreamer Obsoletes: RFCs 1171, 1172 May 1992
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1331年の空想家は以下を時代遅れにします。 RFCs1171、1172 1992年5月
The Point-to-Point Protocol (PPP)
for the
Transmission of Multi-protocol Datagrams
over Point-to-Point Links
ポイントツーポイント接続の上のマルチプロトコルデータグラムの送信のための二地点間プロトコル(ppp)
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components:
Pointからポイントへのプロトコル(PPP)は連続のポイントツーポイント接続の上にデータグラムを送るためのメソッドを提供します。 PPPは3つの主なコンポーネントから成ります:
1. A method for encapsulating datagrams over serial links.
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 (NCPs) for establishing
and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.
このドキュメントはPPPカプセル化体系を定義します、PPP Link Controlプロトコル(LCP)と共に、設定パラメータの豊かな分類を交渉できて、追加管理機能を提供する広げることができるオプション交渉プロトコル。
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このRFCはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 このメモのコメントを ietf-ppp@ucdavis.edu メーリングリストに提出するべきです。
Simpson [Page i] RFC 1331 Point-to-Point Protocol May 1992
1331年のPointからポイントのシンプソン[ページi]RFCプロトコル1992年5月
Table of Contents
目次
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
1. 序論… 1 1.1 要件の仕様… 3 1.2用語… 3
2. Physical Layer Requirements ........................... 4
2. 物理的な層の要件… 4
3. The Data Link Layer ................................... 5
3.1 Frame Format .................................... 6
3. データ・リンク層… 5 3.1 形式を縁どってください… 6
4. PPP Link Operation .................................... 10
4.1 Overview ........................................ 10
4.2 Phase Diagram ................................... 10
4.3 Link Dead (physical-layer not ready) ............ 10
4.4 Link Establishment Phase ........................ 11
4.5 Authentication Phase ............................ 11
4.6 Network-Layer Protocol Phase .................... 12
4.7 Link Termination Phase .......................... 12
4. pppは操作をリンクします… 10 4.1概要… 10 4.2 ダイヤグラムの位相を合わせてください… 10 4.3 Dead(準備ができていなく身体検査で層にする)をリンクしてください… 10 4.4 確立段階をリンクしてください… 11 4.5認証フェーズ… 11 4.6ネットワーク層プロトコルフェーズ… 12 4.7 終了段階をリンクしてください… 12
5. The Option Negotiation Automaton ...................... 14
5.1 State Diagram ................................... 15
5.2 State Transition Table .......................... 16
5.3 States .......................................... 18
5.4 Events .......................................... 20
5.5 Actions ......................................... 24
5.6 Loop Avoidance .................................. 26
5.7 Counters and Timers ............................. 27
5. オプション交渉オートマトン… 14 5.1 ダイヤグラムを述べてください… 15 5.2 変遷テーブルを述べてください… 16 5.3 述べます。 18 5.4のイベント… 20 5.5の動作… 24 5.6 回避を輪にしてください… 26 5.7個のカウンタとタイマ… 27
6. LCP Packet Formats .................................... 28
6.1 Configure-Request ............................... 30
6.2 Configure-Ack ................................... 31
6.3 Configure-Nak ................................... 32
6.4 Configure-Reject ................................ 33
6.5 Terminate-Request and Terminate-Ack ............. 35
6.6 Code-Reject ..................................... 36
6.7 Protocol-Reject ................................. 38
6.8 Echo-Request and Echo-Reply ..................... 39
6.9 Discard-Request ................................. 40
6. LCPパケット・フォーマット… 28 6.1 要求を構成します… 30 6.2 Ackを構成します… 31 6.3 Nakを構成します… 32 6.4 廃棄物を構成します… 33 6.5 要求を終えてAckを終えます… 35 6.6コード廃棄物… 36 6.7プロトコル廃棄物… 38 6.8のエコー要求とエコー・リプライ… 39 6.9 …を破棄して要求してください… 40
7. LCP Configuration Options ............................. 42
7.1 Format .......................................... 43
7.2 Maximum-Receive-Unit ............................ 44
7.3 Async-Control-Character-Map ..................... 45
7.4 Authentication-Protocol ......................... 47
7.5 Quality-Protocol ................................ 49
7.6 Magic-Number .................................... 51
7. LCP設定オプション… 42 7.1 形式… 43 7.2 最大はユニットを受けます… 44 7.3 Asyncはキャラクター地図を制御します… 45 7.4 認証プロトコル… 47 7.5 品質で議定書を作ってください… 49 7.6マジックナンバー… 51
Simpson [Page ii] RFC 1331 Point-to-Point Protocol May 1992
1331年のPointからポイントのシンプソン[ページii]RFCプロトコル1992年5月
7.7 Protocol-Field-Compression ...................... 54
7.8 Address-and-Control-Field-Compression ........... 56
7.7 プロトコル分野圧縮… 54 7.8 アドレスとコントロールは圧縮をさばきます… 56
APPENDICES ................................................... 58
付録… 58
A. Asynchronous HDLC ..................................... 58
A.の非同期なHDLC… 58
B. Fast Frame Check Sequence (FCS) Implementation ........ 61
B.1 FCS Computation Method .......................... 61
B.2 Fast FCS table generator ........................ 63
B.の速いフレームチェックシーケンス(FCS)実装… 61B.1 FCS計算メソッド… 61 B.2の速いFCSはジェネレータをテーブルの上に置きます… 63
C. LCP Recommended Options ............................... 64
C.LCPはオプションを推薦しました… 64
SECURITY CONSIDERATIONS ...................................... 65
セキュリティ問題… 65
REFERENCES ................................................... 65
参照… 65
ACKNOWLEDGEMENTS ............................................. 66
承認… 66
CHAIR'S ADDRESS .............................................. 66
議長のアドレス… 66
AUTHOR'S ADDRESS ............................................. 66
作者のアドレス… 66
Simpson [Page iii] RFC 1331 Point-to-Point Protocol May 1992
1331年のPointからポイントのシンプソン[ページiii]RFCプロトコル1992年5月
1. Introduction
1. 序論
Motivation
動機
In the last few years, the Internet has seen explosive growth in
the number of hosts supporting TCP/IP. The vast majority of these
hosts are connected to Local Area Networks (LANs) of various
types, Ethernet being the most common. Most of the other hosts
are connected through Wide Area Networks (WANs) such as X.25 style
Public Data Networks (PDNs). Relatively few of these hosts are
connected with simple point-to-point (i.e., serial) links. Yet,
point-to-point links are among the oldest methods of data
communications and almost every host supports point-to-point
connections. For example, asynchronous RS-232-C [1] interfaces
are essentially ubiquitous.
ここ数年間で、インターネットは、ホストの数における爆発的成長がTCP/IPをサポートしているのを見ました。 これらのホストのかなりの大部分が様々なタイプ(最も一般的なイーサネット)のローカル・エリア・ネットワーク(LAN)に接続されます。 他のホストの大部分はX.25スタイルPublic Data Networks(PDNs)などのワイドエリアネットワーク(WAN)を通して接されます。 比較的、これらのホストのわずかしか簡単な二地点間(すなわち、連続の)のリンクに接続されません。 しかし、データ通信の最も古いメソッドの中にポイントツーポイント接続があります、そして、ほとんどすべてのホストが二地点間接続をサポートします。 例えば、非同期なRS232C[1]インタフェースは本質的には遍在しています。
Encapsulation
カプセル化
One reason for the small number of point-to-point IP links is the
lack of a standard encapsulation protocol. There are plenty of
non-standard (and at least one de facto standard) encapsulation
protocols available, but there is not one which has been agreed
upon as an Internet Standard. By contrast, standard encapsulation
schemes do exist for the transmission of datagrams over most
popular LANs.
二地点間IPリンクの少ない数の1つの理由が標準のカプセル化プロトコルの不足です。 利用可能な多くの標準的でない(そして、少なくとも1つのデファクトスタンダード)カプセル化プロトコルがありますが、インターネットStandardとして同意されたのはありません。 対照的に、標準のカプセル化体系はデータグラムのトランスミッションのためにほとんどのポピュラーなLANの上に存在しています。
PPP provides an encapsulation protocol over both bit-oriented
synchronous links and asynchronous links with 8 bits of data and
no parity. These links MUST be full-duplex, but MAY be either
dedicated or circuit-switched. PPP uses HDLC as a basis for the
encapsulation.
PPPはビット指向の同期リンクと8ビットのデータとの非同期なリンクの両方にもかかわらず、どんな同等の上にもカプセル化プロトコルを提供しません。 これらのリンクは全二重であるに違いありませんが、5月は、捧げられるか、または回路によって切り換えられます。 PPPはカプセル化の基礎としてHDLCを使用します。
PPP has been carefully designed to retain compatibility with most
commonly used supporting hardware. In addition, an escape
mechanism is specified to allow control data such as XON/XOFF to
be transmitted transparently over the link, and to remove spurious
control data which may be injected into the link by intervening
hardware and software.
PPPは、ハードウェアを支えながら一般的に使用される大部分との互換性を保有するように入念に設計されています。 さらに、逃避機制は、XON/XOFFなどの制御データが透過的にリンクの上に伝えられて、介入しているハードウェアとソフトウェアでリンクに注がれるかもしれない偽りの制御データを移すのを許容するために指定されます。
The PPP encapsulation also provides for multiplexing of different
network-layer protocols simultaneously over the same link. It is
intended that PPP provide a common solution for easy connection of
a wide variety of hosts, bridges and routers.
また、PPPカプセル化は同時に、同じリンクの上に異なったネットワーク層プロトコルのマルチプレクシングに備えます。 PPPがさまざまなホスト、ブリッジ、およびルータの簡単な接続に一般的な解決法を提供することを意図します。
Some protocols expect error free transmission, and either provide
error detection only on a conditional basis, or do not provide it
at all. PPP uses the HDLC Frame Check Sequence for error
detection. This is commonly available in hardware
いくつかのプロトコルは、エラーのないトランスミッションを予想して、条件付きベースだけで誤り検出を提供するか、またはそれを全く提供しません。 PPPは誤り検出にHDLC Frame Check Sequenceを使用します。 これはハードウェアで一般的に利用可能です。
Simpson [Page 1] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[1ページ]RFC1331 1992年5月
implementations, and a software implementation is provided.
実装が提供される実装、およびソフトウェア。
By default, only 8 additional octets are necessary to form the
encapsulation. In environments where bandwidth is at a premium,
the encapsulation may be shortened to as few as 2 octets. To
support high speed hardware implementations, PPP provides that the
default encapsulation header and information fields fall on 32-bit
boundaries, and allows the trailer to be padded to an arbitrary
boundary.
デフォルトで、8つの追加八重奏だけが、カプセル化を形成するのに必要です。 プレミアムには帯域幅がある環境で、カプセル化は最小2つの八重奏に短くされるかもしれません。 PPPは、高速がハードウェア実装であるとサポートするために、デフォルトカプセル化ヘッダーと情報フィールドが32ビットの境界の責任となるのを前提として、トレーラが任意の境界に水増しされるのを許容します。
Link Control Protocol
リンク制御プロトコル
More importantly, the Point-to-Point Protocol defines more than
just an encapsulation scheme. In order to be sufficiently
versatile to be portable to a wide variety of environments, PPP
provides a Link Control Protocol (LCP). The LCP is used to
automatically agree upon the encapsulation format options, handle
varying limits on sizes of packets, authenticate the identity of
its peer on the link, determine when a link is functioning
properly and when it is defunct, detect a looped-back link and
other common misconfiguration errors, and terminate the link.
より重要に、Pointからポイントへのプロトコルはまさしくカプセル化体系以上を定義します。 さまざまな環境に携帯用であることができるくらい多能になるように、PPPはLink Controlプロトコル(LCP)を提供します。 LCPは、自動的にカプセル化形式オプションに同意して、パケットのサイズで異なった限界を扱って、リンクの上に同輩のアイデンティティを認証して、リンクがいつ適切に機能しているか、そして、それがいつ死んでいるかを決定して、輪にされて逆リンクと他の一般的なmisconfiguration誤りを検出して、リンクを終えるのに使用されます。
Network Control Protocols
ネットワーク制御プロトコル
Point-to-Point links tend to exacerbate many problems with the
current family of network protocols. For instance, assignment and
management of IP addresses, which is a problem even in LAN
environments, is especially difficult over circuit-switched
point-to-point links (such as dial-up modem servers). These
problems are handled by a family of Network Control Protocols
(NCPs), which each manage the specific needs required by their
respective network-layer protocols. These NCPs are defined in
other documents.
指すポイントリンクは、ネットワーク・プロトコルの現在のファミリーに関する多くの問題を悪化させる傾向があります。 例えば、IPアドレスの課題と管理(LAN環境においてさえ問題である)は回路で切り換えられたポイントツーポイント接続(ダイヤルアップモデムサーバなどの)の上で特に難しいです。 これらの問題はNetwork Controlプロトコル(NCP)のファミリーによって扱われます。(それぞれ、プロトコルはそれらのそれぞれのネットワーク層プロトコルによって必要とされた特定の必要性を管理します)。 これらのNCPは他のドキュメントで定義されます。
Configuration
構成
It is intended that PPP be easy to configure. By design, the
standard defaults should handle all common configurations. The
implementor may specify improvements to the default configuration,
which are automatically communicated to the peer without operator
intervention. Finally, the operator may explicitly configure
options for the link which enable the link to operate in
environments where it would otherwise be impossible.
PPPは構成しやすいことを意図します。 故意に、標準省略時解釈はすべての一般的な構成を扱うべきです。 作成者はデフォルト設定への改良を指定するかもしれません。(改良はオペレータ介入なしで同輩に自動的に伝えられます)。 最終的に、オペレータは明らかにリンクのためのそうでなければそれが不可能であるところでリンクが環境で作動するのを可能にするオプションを構成するかもしれません。
This self-configuration is implemented through an extensible
option negotiation mechanism, wherein each end of the link
describes to the other its capabilities and requirements.
Although the option negotiation mechanism described in this
この自己構成は広げることができるオプション交渉メカニズムを通して実装されます。リンクの各端はメカニズムでその能力と要件についてもう片方に説明します。 オプション交渉メカニズムは中でこれについて説明しましたが
Simpson [Page 2] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[2ページ]RFC1331 1992年5月
document is specified in terms of the Link Control Protocol (LCP),
the same facilities may be used by the Internet Protocol Control
Protocol (IPCP) and others in the family of NCPs.
Link Controlプロトコル(LCP)でドキュメントは指定されて、同じ施設はNCPのファミリーのインターネットプロトコルControlプロトコル(IPCP)と他のものによって使用されるかもしれません。
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.
「必要である」というこの単語、または形容詞が、定義が仕様に関する絶対条件であることを意味します。
MUST NOT
必須NOT
This phrase means that the definition is an absolute prohibition
of the specification.
この句は、定義が仕様の絶対禁止であることを意味します。
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つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
1.2. Terminology
1.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
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.
これは、実装がさらなる処理なしでパケットを捨てることを意味します。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
Simpson [Page 3] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[3ページ]RFC1331 1992年5月
2. Physical Layer Requirements
2. 物理的な層の要件
The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the provision of a full-duplex circuit, either dedicated or circuit- switched, which can operate in either an asynchronous (start/stop) or synchronous bit-serial mode, transparent to PPP Data Link Layer frames. PPP does not impose any restrictions regarding transmission rate, other than those imposed by the particular DTE/DCE interface in use.
PointからポイントへのプロトコルはどんなDTE/DCEインタフェース(例えば、EIA RS232C、EIA RS-422、EIA RS-423、およびCCITT V.35)の向こう側にも作動できます。 PPPによって課された唯一の絶対条件が捧げられた全二重回路の設備であるか回路(非同期な(始め/停止)かシンクロナスビット連続のモードのどちらかで作動できる)は切り替わりました、PPP Data Link Layerフレームに、透明です。 PPPは特定のDTE/DCEインタフェースによって使用中に課されたもの以外の通信速度に関する少しの制限も課しません。
PPP does not require any particular synchronous encoding, such as FM, NRZ, or NRZI.
PPPはFM、NRZ、またはNRZIなどのようなどんな特定の同期コード化も必要としません。
Implementation Note:
実装注意:
NRZ is currently most widely available, and on that basis is
recommended as a default. When configuration of the encoding is
allowed, NRZI is recommended as an alternative, because of its
relative immunity to signal inversion configuration errors.
NRZは現在、最も広く利用可能であり、デフォルトとしてそのような方式でお勧めです。 コード化の構成が許されているとき、部分的免疫による代替手段として、NRZIが逆構成誤りに合図することが勧められます。
PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and Data Terminal Ready (DTR).
PPPはモデム制御信号の使用を必要としません、Request To Send(RTS)や、Clear To Send(CTS)や、Data Carrier Detect(DCD)や、Data Terminal Ready(DTR)などのように。
Implementation Note:
実装注意:
When available, using such signals can allow greater functionality
and performance. In particular, such signals SHOULD be used to
signal the Up and Down events in the Option Negotiation Automaton
(described below).
利用可能であるときに、そのような信号を使用すると、より大きい機能性と性能を許容できます。 特定の、そして、そのような信号SHOULDでは、使用されて、Option Negotiation Automaton(以下で、説明される)でUpとDownイベントに合図してください。
Simpson [Page 4] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[4ページ]RFC1331 1992年5月
3. The Data Link Layer
3. データ・リンク層
The Point-to-Point Protocol uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) High-level Data Link Control (HDLC) procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/stop transmission" [5]. ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments.
Pointからポイントへのプロトコルが国際標準化機構(ISO)のハイレベルのData Link Control(HDLC)手順の原則、用語、および枠組構造を使用する、(ISO3309によって変更されるようなISO3309-1979[2])、1984/PDAD1、「付加物1:」 「始め/停止送信」[5]。 ISO3309-1979は同期環境における使用にHDLC枠組構造を指定します。 ISO3309: 1984/PDAD1は、非同期な環境における使用を許すためにISO3309-1979への提案された変更を指定します。
The PPP control procedures use the definitions and Control field encodings standardized in ISO 4335-1979 [3] and ISO 4335- 1979/Addendum 1-1979 [4]. The PPP frame structure is also consistent with CCITT Recommendation X.25 LAPB [6], since that too is based on HDLC.
PPPコントロール手順はISO4335-1979[3]とISO4335- 1979/付加物1-1979[4]で標準化された定義とControl分野encodingsを使用します。 また、それもHDLCに基づいているので、PPP枠組構造もCCITT Recommendation X.25 LAPB[6]と一致しています。
The purpose of this memo is not to document what is already standardized in ISO 3309. We assume that the reader is already familiar with HDLC, or has access to a copy of [2] or [6]. Instead, this paper attempts to give a concise summary and point out specific options and features used by PPP. Since "Addendum 1: Start/stop transmission", is not yet standardized and widely available, it is summarized in Appendix A.
このメモの目的はISO3309で既に標準化されることを記録しないことです。 私たちは、読者が既にHDLCになじみ深いか、または[2]か[6]のコピーに近づく手段を持っていると思います。 代わりに、この紙は、簡潔な概要をして、特定のオプションとPPPによって使用された特徴を指摘するのを試みます。 以来、「付加物1:」 「始め/停止送信」がまだ標準化されていなくて広く利用可能である、それはAppendix Aにまとめられます。
To remain consistent with standard Internet practice, and avoid confusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Significant Bit order, reading from left to right, unless otherwise indicated. Note that this is contrary to standard ISO and CCITT practice which orders bits as transmitted (i.e., network bit order). Keep this in mind when comparing this document with the international standards documents.
一般的なインターネット習慣と一致していたままで残って、読書RFCsに慣れている人々のために混乱を避けるために、Least Significant Bitオーダーには以下の記述におけるすべての2進の数がMost Significant Bitにあります、左から右まで読んで、別の方法で示されない場合。 これが標準のISOとCCITT習慣に合わないことに注意してください(伝えられるようにビットを配置します)(すなわち、ネットワークはオーダーに噛み付きました)。 世界規格ドキュメントとこのドキュメントを比べるときにはこれを覚えておいてください。
Simpson [Page 5] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[5ページ]RFC1331 1992年5月
3.1. Frame Format
3.1. フレーム形式
A summary of the standard PPP frame structure is shown below. This figure does not include start/stop bits (for asynchronous links), nor any bits or octets inserted for transparency. The fields are transmitted from left to right.
標準のPPP枠組構造の概要は以下に示されます。 この図は透明ために挿入されたどんなスタート/ストップ・ビット(非同期なリンクへの)と、ビットや八重奏も入れません。 野原は左から右まで伝えられます。
+----------+----------+----------+----------+------------
| Flag | Address | Control | Protocol | Information
| 01111110 | 11111111 | 00000011 | 16 bits | *
+----------+----------+----------+----------+------------
---+----------+----------+-----------------
| FCS | Flag | Inter-frame Fill
| 16 bits | 01111110 | or next Address
---+----------+----------+-----------------
+----------+----------+----------+----------+------------ | 旗| アドレス| コントロール| プロトコル| 情報| 01111110 | 11111111 | 00000011 | 16ビット| * +----------+----------+----------+----------+------------ ---+----------+----------+----------------- | FCS| 旗| インターフレーム中詰め| 16ビット| 01111110 | または、次のAddress---+----------+----------+-----------------
Inter-frame Time Fill
インターフレームタイム・フィル
For asynchronous links, inter-frame time fill SHOULD be accomplished in the same manner as inter-octet time fill, by transmitting continuous "1" bits (mark-hold state).
非同期なリンクに関しては、インターフレーム時間は優れたコネが相互八重奏タイム・フィル、伝わっている連続した「1インチのビット(マークホールド状態)」と同じ方法であったならSHOULDをいっぱいにしています。
For synchronous links, the Flag Sequence SHOULD be transmitted during inter-frame time fill. There is no provision for inter-octet time fill.
同期リンク、Flag Sequence SHOULD、インターフレームタイム・フィルの間、伝えられてください。 相互八重奏タイム・フィルへの支給が全くありません。
Implementation Note:
実装注意:
Mark idle (continuous ones) SHOULD NOT be used for idle
synchronous inter-frame time fill. However, certain types of
circuit-switched links require the use of mark idle, particularly
those that calculate accounting based on bit activity. When mark
idle is used on a synchronous link, the implementation MUST ensure
at least 15 consecutive "1" bits between Flags, and that the Flag
Sequence is generated at the beginning and end of a frame.
(連続したもの)使用されていないSHOULD NOTをマークしてください。無駄な同期インターフレームタイム・フィルには、使用されてください。 しかしながら、あるタイプの回路で切り換えられたリンクは活動していない状態でマークの使用を必要とします、特に噛み付いている活動に基づく会計について計算するもの。 マークがいつ怠けるかは同期リンクの上に使用されて、実装は少なくとも15を確実にしなければなりません。連続した「間のビットが旗を揚げて、フラグ・シーケンスがフレームの首尾で生成される1インチ。」
Flag Sequence
フラグ・シーケンス
The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e).
Flag Sequenceはただ一つの八重奏であり、フレームの始めか端を示します。 Flag Sequenceは2進の系列01111110(16進0x7e)から成ります。
The Flag is a frame separator. Only one Flag is required between two frames. Two consecutive Flags constitute an empty frame, which is ignored.
Flagはフレーム分離符です。 1Flagだけが2個のフレームの間で必要です。 2連続したFlagsが空のフレームを設立します。(それは、無視されます)。
Simpson [Page 6] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[6ページ]RFC1331 1992年5月
Implementation Note:
実装注意:
The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
be used. When not avoidable, such an implementation MUST ensure
that the first Flag Sequence detected (the end of the frame) is
promptly communicated to the link layer.
「共有されて、モードのゼロを合わせてください」というFlag Sequence「011111101111110」を使用するべきではありません。 回避可能でないときに、そのような実装は、Flag Sequenceが検出した1(フレームの端)番目が即座にリンクレイヤに伝えられるのを確実にしなければなりません。
Address Field
アドレス・フィールド
The Address field is a single octet and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not assign individual station addresses. The All-Stations address MUST always be recognized and received. The use of other address lengths and values may be defined at a later time, or by prior agreement. Frames with unrecognized Addresses SHOULD be silently discarded, and reported through the normal network management facility.
Address分野は、ただ一つの八重奏であり、2進の系列11111111(16進0xff)、All-駅のアドレスを含んでいます。 PPPは個々のステーションアドレスを割り当てません。 いつもAll-駅のアドレスを認識して、受け取らなければなりません。 他のアドレスの長さと値の使用は後で、またはあらかじめ取り決めて定義されるかもしれません。 正常なネットワークマネージメント施設で認識されていないAddresses SHOULDが静かに捨てられている状態で縁どって、報告しました。
Control Field
制御フィールド
The Control field is a single octet and contains the binary sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the P/F bit set to zero. Frames with other Control field values SHOULD be silently discarded.
Control分野は、ただ一つの八重奏であり、2進の系列00000011(16進0x03)を含んでいます、ゼロに設定されたP/FビットによるUnnumbered情報(UI)コマンド。 他のControl分野値のSHOULDが静かに捨てられているフレーム。
Protocol Field
プロトコル分野
The Protocol field is two octets and its value identifies the protocol encapsulated in the Information field of the frame.
プロトコル分野は2つの八重奏です、そして、値はフレームの情報分野でカプセル化されたプロトコルを特定します。
This Protocol field is defined by PPP and is not a field defined by HDLC. However, the Protocol field is consistent with the ISO 3309 extension mechanism for Address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules MUST be considered as having an unrecognized Protocol, and handled as specified by the LCP. The Protocol field is transmitted and received most significant octet first.
このプロトコル分野は、PPPによって定義されて、HDLCによって定義された分野ではありません。 しかしながら、Address分野において、プロトコル分野はISO3309拡張機能と一致しています。 すべてのプロトコルが変であるに違いありません。 最も重要でない八重奏の最下位ビットは「1インチ」と等しくなければなりません。 また、最も重要な八重奏の最下位ビットが「0インチ」と等しいように、すべてのプロトコルを割り当てなければなりません。 認識されていないプロトコルを持って、LCPによって指定されるように扱われるように考えられて、これらの規則に従わない受け取られたフレームはそうしなければなりません。 最初に、プロトコル分野は伝えられて容認された最も重要な八重奏です。
Protocol field values in the "0---" to "3---" range identify the network-layer protocol of specific datagrams, and values in the "8-- -" to "b---" range identify datagrams belonging to the associated Network Control Protocols (NCPs), if any.
「0」におけるプロトコル分野値---「「3」---「範囲が中で特定のデータグラム、および値のネットワーク層プロトコルを特定する、「8--、--、」、「b」---「範囲はもしあれば関連Network Controlプロトコル(NCP)に属すデータグラムを特定します」
Protocol field values in the "4---" to "7---" range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the "c---" to "f---" range identify
「4」におけるプロトコル分野値---「「7」---「範囲はプロトコルにどんな関連NCPも持っていない低いボリュームトラフィックで使用されます。」 「c」のプロトコル分野値---「「f」---「範囲は特定します」
Simpson [Page 7] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[7ページ]RFC1331 1992年5月
datagrams as link-layer Control Protocols (such as LCP).
リンクレイヤControlプロトコル(LCPなどの)としてのデータグラム。
The most up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC [11]. Current values are assigned as follows:
プロトコル分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。 現行価値は以下の通り割り当てられます:
Value (in hex) Protocol Name
値(十六進法における)のプロトコルName
0001 to 001f reserved (transparency inefficient)
0021 Internet Protocol
0023 OSI Network Layer
0025 Xerox NS IDP
0027 DECnet Phase IV
0029 Appletalk
002b Novell IPX
002d Van Jacobson Compressed TCP/IP
002f Van Jacobson Uncompressed TCP/IP
0031 Bridging PDU
0033 Stream Protocol (ST-II)
0035 Banyan Vines
0037 reserved (until 1993)
00ff reserved (compression inefficient)
Banyanバインズ0037の予約された(1993年までの)00ffが予約した0021年の001fの予約された(透明効率の悪い)インターネットプロトコル0023OSI Network Layer0025ゼロックスNS IDP0027DECnet Phase IV0029Appletalk 002bノベルIPX 002dヴァンジェーコブソンCompressed TCP/IP002fヴァンジェーコブソンUncompressed TCP/IP0031Bridging PDU0033Streamプロトコル(ST-II)0001年の対0035(圧縮効率の悪い)です。
0201 802.1d Hello Packets
0231 Luxcom
0233 Sigma Network Systems
こんにちは、パケット0231Luxcom0233σがネットワークでつなぐ0201 802.1d、システム
8021 Internet Protocol Control Protocol
8023 OSI Network Layer Control Protocol
8025 Xerox NS IDP Control Protocol
8027 DECnet Phase IV Control Protocol
8029 Appletalk Control Protocol
802b Novell IPX Control Protocol
802d Reserved
802f Reserved
8031 Bridging NCP
8033 Stream Protocol Control Protocol
8035 Banyan Vines Control Protocol
制御プロトコル8027DECnetフェーズIV制御プロトコル8029Appletalk制御プロトコル802bノベルIPXが制御する8021年のインターネットプロトコル制御プロトコル8023OSIネットワーク層制御プロトコル8025ゼロックスナノ秒IDPはNCP8033ストリームプロトコル制御プロトコル8035バニヤンつる植物に制御プロトコルをブリッジする802dの予約された802f予約された8031について議定書の中で述べます。
c021 Link Control Protocol
c023 Password Authentication Protocol
c025 Link Quality Report
c223 Challenge Handshake Authentication Protocol
c021リンクControlプロトコルc023パスワード認証プロトコルc025 Link Quality Report c223チャレンジハンドシェイク式認証プロトコル
Developers of new protocols MUST obtain a number from the Internet Assigned Numbers Authority (IANA), at IANA@isi.edu.
新しいプロトコルの開発者は IANA@isi.edu のインターネットAssigned民数記Authority(IANA)から数を得なければなりません。
Simpson [Page 8] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[8ページ]RFC1331 1992年5月
Information Field
情報フィールド
The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The end of the Information field is found by locating the closing Flag Sequence and allowing two octets for the Frame Check Sequence field. The default maximum length of the Information field is 1500 octets. By negotiation, consenting PPP implementations may use other values for the maximum Information field length.
情報分野はゼロであるか以上が八重奏です。 情報分野はプロトコル分野で指定されたプロトコルのためのデータグラムを含んでいます。 情報分野の端は、終わりのFlag Sequenceの場所を見つけて、2つの八重奏を許容することによって、Frame Check Sequence分野に見つけられます。 情報分野のデフォルトの最大の長さは1500の八重奏です。 交渉で、同意しているPPP実装は最大の情報フィールド長に他の値を使用するかもしれません。
On transmission, the Information field may be padded with an arbitrary number of octets up to the maximum length. It is the responsibility of each protocol to disambiguate padding octets from real information.
トランスミッションのときに、情報分野は八重奏の特殊活字の数字で最大の長さまで水増しされるかもしれません。 それは本当の情報から八重奏を水増しするあいまいさを除くそれぞれのプロトコルの責任です。
Frame Check Sequence (FCS) Field
フレームチェックシーケンス(FCS)分野
The Frame Check Sequence field is normally 16 bits (two octets). The use of other FCS lengths may be defined at a later time, or by prior agreement.
通常、Frame Check Sequence分野は16ビット(2つの八重奏)です。 他のFCSの長さの使用は後で、またはあらかじめ取り決めて定義されるかもしれません。
The FCS field is calculated over all bits of the Address, Control, Protocol and Information fields not including any start and stop bits (asynchronous) and any bits (synchronous) or octets (asynchronous) inserted for transparency. This does not include the Flag Sequences or the FCS field itself. The FCS is transmitted with the coefficient of the highest term first.
FCS分野は透明ために挿入されたどんなどんな始めとストップビット(非同期な)とビット(同期)や八重奏(非同期な)も含まないAddress、Control、プロトコル、および情報分野のすべてのビットの上計算されます。 これはFlag SequencesかFCS分野自体を含んでいません。 FCSは最初に、最も高い用語の係数で伝えられます。
Note: When octets are received which are flagged in the Async-
Control-Character-Map, they are discarded before calculating the
FCS. See the description in Appendix A.
以下に注意してください。 八重奏が受け取られているとき、(Async規制キャラクター地図で旗を揚げられます)FCSについて計算する前に、それらは捨てられます。 Appendix Aの記述を見てください。
For more information on the specification of the FCS, see ISO 3309 [2] or CCITT X.25 [6].
FCSの仕様の詳しい情報に関しては、ISO3309[2]かCCITT X.25[6]を見てください。
Note: A fast, table-driven implementation of the 16-bit FCS
algorithm is shown in Appendix B. This implementation is based on
[7], [8], and [9].
以下に注意してください。 16ビットのFCSアルゴリズムの速くて、テーブル駆動の実装はAppendixにB.This実装が[7]、[8]、および[9]に基づいているのが示されます。
Modifications to the Basic Frame Format
基本枠形式への変更
The Link Control Protocol can negotiate modifications to the standard PPP frame structure. However, modified frames will always be clearly distinguishable from standard frames.
Link Controlプロトコルは標準のPPP枠組構造への変更を交渉できます。 しかしながら、変更されたフレームは標準のフレームから区別可能にいつも明確になるでしょう。
Simpson [Page 9] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[9ページ]RFC1331 1992年5月
4. PPP Link Operation
4. pppリンク操作
4.1. Overview
4.1. 概要
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established, the peer may be authenticated. Then, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link.
ポイントツーポイント接続の上でコミュニケーションを確立するために、PPPリンクの各端は、最初に、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立された後に、同輩は認証されるかもしれません。 そして、PPPは、1つ以上のネットワーク層プロトコルを選んで、構成するためにNCPパケットを送らなければなりません。 いったんそれぞれの選ばれたネットワーク層プロトコルを構成すると、各ネットワーク層プロトコルからのデータグラムをリンクの上に送ることができます。
The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention).
リンクは明白なLCPかNCPパケットがリンクを閉鎖するか、または何らかの外部のイベントが起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
4.2. Phase Diagram
4.2. フェーズダイヤグラム
In the process of configuring, maintaining and terminating the point-to-point link, the PPP link goes through several distinct phases:
ポイントツーポイント接続を構成して、維持して、終えることの途中に、PPPリンクはいくつかの異なったフェーズに直面しています:
+------+ +-----------+ +--------------+
| | UP | | OPENED | | SUCCESS/NONE
| Dead |------->| Establish |---------->| Authenticate |--+
| | | | | | |
+------+ +-----------+ +--------------+ |
^ FAIL | FAIL | |
+<--------------+ +----------+ |
| | |
| +-----------+ | +---------+ |
| DOWN | | | CLOSING | | |
+------------| Terminate |<---+<----------| Network |<-+
| | | |
+-----------+ +---------+
+------+ +-----------+ +--------------+ | | 上がる| | 開かれます。| | 成功/、なし| 死者|、-、-、-、-、-、--、>| 設立します。|、-、-、-、-、-、-、-、-、--、>| 認証します。|--+ | | | | | | | +------+ +-----------+ +--------------+ | ^失敗してください。| 失敗してください。| | + <。--------------+ +----------+ | | | | | +-----------+ | +---------+ | | 下に| | | 閉じます。| | | +------------| 終わってください。| <、-、--+ <。----------| ネットワーク| <、-+ | | | | +-----------+ +---------+
4.3. Link Dead (physical-layer not ready)
4.3. リンク死者(準備ができていなく身体検査で層にします)
The link necessarily begins and ends with this phase. When an external event (such as carrier detection or network administrator configuration) indicates that the physical-layer is ready to be used, PPP will proceed to the Link Establishment phase.
リンクは、必ず始まって、このフェーズで終わります。 外部のイベント(キャリヤー検出かネットワーク管理者構成などの)が、物理的な層が使用される準備ができているのを示すとき、PPPはLink特権階級フェーズに続くでしょう。
During this phase, the LCP automaton (described below) will be in the Initial or Starting states. The transition to the Link Establishment phase will signal an Up event to the automaton.
この段階の間、LCPオートマトン(以下で、説明される)がInitialかStarting州にあるでしょう。 Link特権階級フェーズへの変遷はUpイベントをオートマトンに示すでしょう。
Simpson [Page 10] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[10ページ]RFC1331 1992年5月
Implementation Note:
実装注意:
Typically, a link will return to this phase automatically after
the disconnection of a modem. In the case of a hard-wired line,
this phase may be extremely short -- merely long enough to detect
the presence of the device.
通常、リンクはモデムの断線の後に自動的にこのフェーズに戻るでしょう。 このフェーズはハード・ワイヤード系列の場合は非常に不足するかもしれません--単にデバイスの存在を検出できるくらい長いです。
4.4. Link Establishment Phase
4.4. リンク確立段階
The Link Control Protocol (LCP) is used to establish the connection through an exchange of Configure packets. This exchange is complete, and the LCP Opened state entered, once a Configure-Ack packet (described below) has been both sent and received. Any non-LCP packets received during this phase MUST be silently discarded.
Link Controlプロトコル(LCP)は、Configureパケットの交換を通して接続を証明するのに使用されます。 この交換は完全です、そして、LCP Opened状態に入りました、いったん、Configure-Ackパケット(以下で、説明される)を送って、受け取ると。 静かにこの段階の間に受け取られたどんな非LCPパケットも捨てなければなりません。
All Configuration Options are assumed to be at default values unless altered by the configuration exchange. See the section on LCP Configuration Options for further discussion.
構成交換で変更されない場合、デフォルト値にはすべてのConfiguration Optionsがいると思われます。 さらなる議論に関してLCP Configuration Optionsの上のセクションを見てください。
It is important to note that only Configuration Options which are independent of particular network-layer protocols are configured by LCP. Configuration of individual network-layer protocols is handled by separate Network Control Protocols (NCPs) during the Network-Layer Protocol phase.
特定のネットワーク層プロトコルから独立しているConfiguration OptionsだけがLCPによって構成されることに注意するのは重要です。 別々のNetwork Controlプロトコル(NCP)によって個々のネットワーク層プロトコルの構成はNetwork-層のプロトコル段階の間、扱われます。
4.5. Authentication Phase
4.5. 認証フェーズ
On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged.
いくつかのリンクでは、同輩がネットワーク層プロトコルパケットが交換されるのを許容する前にそれ自体を認証するのが必要であるのは望ましいかもしれません。
By default, authentication is not necessary. If an implementation requires that the peer authenticate with some specific authentication protocol, then it MUST negotiate the use of that authentication protocol during Link Establishment phase.
デフォルトで、認証は必要ではありません。 実装が、何かが特定の状態で同輩が認証プロトコルを認証するのを必要とするなら、それはLink特権階級段階の間、その認証プロトコルの使用を交渉しなければなりません。
Authentication SHOULD take place as soon as possible after link establishment. However, link quality determination MAY occur concurrently. An implementation MUST NOT allow the exchange of link quality determination packets to delay authentication indefinitely.
認証SHOULDはリンク設立の後にできるだけ早く、行われます。 しかしながら、リンク品質決定は同時に起こるかもしれません。 リンク品質決定パケットの交換は実現で認証を無期限に遅らせることができてはいけません。
Advancement from the Authentication phase to the Network-Layer Protocol phase MUST NOT occur until the peer is successfully authenticated using the negotiated authentication protocol. In the event of failure to authenticate, PPP SHOULD proceed instead to the Link Termination phase.
同輩が交渉された認証プロトコルを使用することで首尾よく認証されるまで、AuthenticationフェーズからNetwork-層のプロトコルフェーズまでの前進は起こってはいけません。 認証する失敗の場合、PPP SHOULDは代わりにLink Terminationフェーズに続きます。
Simpson [Page 11] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[11ページ]RFC1331 1992年5月
4.6. Network-Layer Protocol Phase
4.6. ネットワーク層プロトコルフェーズ
Once PPP has finished the previous phases, each network-layer protocol (such as IP) MUST be separately configured by the appropriate Network Control Protocol (NCP).
PPPがいったん前のフェーズを終えると、別々に、適切なNetwork Controlプロトコル(NCP)で各ネットワーク層プロトコル(IPなどの)を構成しなければなりません。
Each NCP may be Opened and Closed at any time.
いつでも、各NCPは、OpenedとClosedであるかもしれません。
Implementation Note:
実現注意:
Because an implementation may initially use a significant amount
of time for link quality determination, implementations SHOULD
avoid fixed timeouts when waiting for their peers to configure a
NCP.
実現が初めはリンク品質決定のために重要な時間を費やすかもしれないので、彼らの同輩がNCPを構成するのを待つとき、実現SHOULDは固定タイムアウトを避けます。
After a NCP has reached the Opened state, PPP will carry the corresponding network-layer protocol packets. Any network-layer protocol packets received when the corresponding NCP is not in the Opened state SHOULD be silently discarded.
NCPがOpened状態に達した後に、PPPは対応するネットワーク層プロトコルパケットを運ぶでしょう。 対応するNCPがOpenedにないとき受け取られたどんなネットワーク層プロトコルパケットも、SHOULDが静かに捨てられると述べます。
During this phase, link traffic consists of any possible combinations of LCP, NCP, and network-layer protocol packets. Any NCP or network-layer protocol packets received during any other phase SHOULD be silently discarded.
この段階の間、リンク交通はLCP、NCP、およびネットワーク層プロトコルパケットのどんな可能な組み合わせからも成ります。 捨てられて、いかなる他のフェーズSHOULDの間にも受け取られたどんなNCPやネットワーク層プロトコルパケットも静かにそうです。
Implementation Note:
実現注意:
There is an exception to the preceding paragraphs, due to the
availability of the LCP Protocol-Reject (described below). While
LCP is in the Opened state, any protocol packet which is
unsupported by the implementation MUST be returned in a Protocol-
Reject. Only supported protocols are silently discarded.
先行のパラグラフへの例外がLCPプロトコル廃棄物(以下で、説明される)の有用性のためにあります。 LCPがOpened状態にある間、プロトコル廃棄物でどんな実現でサポートされないプロトコルパケットも返さなければなりません。 支持されたプロトコルだけが静かに捨てられます。
4.7. Link Termination Phase
4.7. リンク終了段階
PPP may terminate the link at any time. This will usually be done at the request of a human user, but might happen because of a physical event such as the loss of carrier, authentication failure, link quality failure, or the expiration of an idle-period timer.
PPPはいつでも、リンクを終えるかもしれません。 通常、活動していない期間のタイマのキャリヤーの損失、認証失敗、リンク品質の欠陥、または満了などの物理的な出来事のために起こるかもしれないのを除いて、人間のユーザの依頼でこれをするでしょう。
LCP is used to close the link through an exchange of Terminate packets. When the link is closing, PPP informs the network-layer protocols so that they may take appropriate action.
LCPは、Terminateパケットの交換を通してリンクを閉じるのに使用されます。 リンクが閉じているとき、PPPは、適切な行動を取ることができるようにネットワーク層プロトコルを知らせます。
After the exchange of Terminate packets, the implementation SHOULD signal the physical-layer to disconnect in order to enforce the termination of the link, particularly in the case of an authentication failure. The sender of the Terminate-Request SHOULD
Terminateパケットの交換の後に、実現SHOULDは、リンクの終了を実施するために連絡を断つように物理的な層に合図します、特に認証失敗の場合で。 Terminate-要求SHOULDの送付者
Simpson [Page 12] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[12ページ]RFC1331 1992年5月
disconnect after receiving a Terminate-Ack, or after the Restart counter expires. The receiver of a Terminate-Request SHOULD wait for the peer to disconnect, and MUST NOT disconnect until at least one Restart time has passed after sending a Terminate-Ack. PPP SHOULD proceed to the Link Dead phase.
Terminate-Ackを受けるか、またはRestartカウンタが期限が切れた後に連絡を断ってください。 Terminate-Ackを送った後に、SHOULDが同輩が外すのを待っていて、少なくとも1Restart回まで外してはいけないTerminate-要求の受信機は通過しました。 PPP SHOULDはLink Deadフェーズに続きます。
Implementation Note:
実現注意:
The closing of the link by LCP is sufficient. There is no need
for each NCP to send a flurry of Terminate packets. Conversely,
the fact that a NCP has Closed is not sufficient reason to cause
the termination of the PPP link, even if that NCP was the only
currently NCP in the Opened state.
LCPによるリンクの閉鎖は十分です。 各NCPがTerminateパケットの突風を送る必要は全くありません。 逆に、NCPにはClosedがあるという事実はPPPリンクの終了を引き起こすことができるくらいの理由ではありません、現在そのNCPが唯一であったとしても。Opened状態のNCP。
Simpson [Page 13] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[13ページ]RFC1331 1992年5月
5. The Option Negotiation Automaton
5. オプション交渉オートマトン
The finite-state automaton is defined by events, actions and state transitions. Events include reception of external commands such as Open and Close, expiration of the Restart timer, and reception of packets from a peer. Actions include the starting of the Restart timer and transmission of packets to the peer.
有限状態オートマトンは出来事、動作、および状態遷移で定義されます。 出来事はオープンやCloseなどの外部のコマンドのレセプション、Restartタイマの満了、および同輩からのパケットのレセプションを含んでいます。 動作はRestartタイマの始めとパケットのトランスミッションを同輩に含んでいます。
Some types of packets -- Configure-Naks and Configure-Rejects, or Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and Discard-Requests -- are not differentiated in the automaton descriptions. As will be described later, these packets do indeed serve different functions. However, they always cause the same transitions.
何人かのタイプのパケット--、Naksを構成する、Configure-廃棄物かCode-廃棄物とプロトコル廃棄物か、Echo-要求と、Echo-回答とDiscard-要求--そして、オートマトン記述で微分されません。 本当に、後で説明されるように、これらのパケットは異なった機能を果たします。 しかしながら、彼らはいつも同じ変遷を引き起こします。
Events Actions
イベント動作
Up = lower layer is Up tlu = This-Layer-Up Down = lower layer is Down tld = This-Layer-Down Open = administrative Open tls = This-Layer-Start Close= administrative Close tlf = This-Layer-Finished
=に、下層はこの層が上昇しているUp tlu=Down=下層が終わっているこの管理管理オープンtls=この層のスタート下にこの層のDown tld=オープン=Close=Close tlf=層であるということです。
TO+ = Timeout with counter > 0 irc = initialize restart
counter
TO- = Timeout with counter expired zrc = zero restart counter
=が反対に再開カウンタTO=タイムアウトを初期化する反対の>0ircがあるTO+=タイムアウトは再開zrc=カウンタを全く吐き出しませんでした。
RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack sca = Send-Configure-Ack RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej
RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack sca = Send-Configure-Ack RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej
RTR = Receive-Terminate-Request str = Send-Terminate-Request RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack
RTRが等しい、受信、要求を終えてください、strが等しい、発信、要求を終えてください、RTAが等しい、受信、Ack staを終えてください、等しさ、発信、Ackを終えてください。
RUC = Receive-Unknown-Code scj = Send-Code-Reject
RXJ+ = Receive-Code-Reject (permitted)
or Receive-Protocol-Reject
RXJ- = Receive-Code-Reject (catastrophic)
or Receive-Protocol-Reject
RXR = Receive-Echo-Request ser = Send-Echo-Reply
or Receive-Echo-Reply
or Receive-Discard-Request
- = illegal action
Receiveは要求を捨てます--コード廃棄物を受けているか(壊滅的な)、またはReceiveが廃棄物について議定書の中で述べている未知のコードを受け取っているscj RUC==コード廃棄物を送っているRXJ+=コード廃棄物を受けているか(受入れられます)、またはReceiveが廃棄物について議定書の中で述べているRXJ=RXRがエコー要求を受け取っているser=とエコー回答を送った状態で等しいです、Receiveが回答をまねるか、または不法な動きと等しいです。
Simpson [Page 14] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[14ページ]RFC1331 1992年5月
5.1. State Diagram
5.1. 州のダイヤグラム
The simplified state diagram which follows describes the sequence of events for reaching agreement on Configuration Options (opening the PPP link) and for later termination of the link.
従う簡易型の州のダイヤグラムはConfiguration Options(PPPリンクを開ける)で合意に達して、リンクの後の終了のために出来事の系列について説明します。
This diagram is not a complete representation of the automaton.
Implementation MUST be done by consulting the actual state
transition table.
このダイヤグラムはオートマトンの完全表記ではありません。 実際の状態遷移テーブルに相談することによって、実現しなければなりません。
Events are in upper case. Actions are in lower case. For these purposes, the state machine is initially in the Closed state. Once the Opened state has been reached, both ends of the link have met the requirement of having both sent and received a Configure-Ack packet.
大文字の中に出来事があります。 小文字には動作があります。 これらの目的のために、州のマシンは初めはClosed状態にあります。 Opened状態にいったん達すると、リンクの両端は、両方を送らせる必要条件を満たして、Configure-Ackパケットを受けました。
RCR TO+
+--sta-->+ +------->+
| | | |
+-------+ | RTA +-------+ | Close +-------+
| |<-----+<------| |<-str-+<------| |
|Closed | |Closing| |Opened |
| | Open | | | |
| |------+ | | | |
+-------+ | +-------+ +-------+
| ^
| |
| +-sca----------------->+
| | ^
RCN,TO+ V RCR+ | RCR- RCA | RCN,TO+
+------->+ | +------->+ | +--scr-->+
| | | | | | | |
+-------+ | TO+ +-------+ | +-------+ |
| |<-scr-+<------| |<-scn-+ | |<-----+
| Req- | | Ack- | | Ack- |
| Sent | RCA | Rcvd | | Sent |
+-scn->| |------------->| | +-sca->| |
| +-------+ +-------+ | +-------+
| RCR- | | RCR+ | RCR+ | | RCR-
| | +------------------------------->+<-------+ |
| | |
+<-------+<------------------------------------------------+
+ +へのRCR--sta-->++------->+| | | | +-------+ | RTA+-------+ | 閉鎖+-------+ | | <、-、-、-、--+ <。------| | <、-str-+<。------| | |閉じられます。| |閉じます。| |開かれます。| | | 開いてください。| | | | | |------+ | | | | +-------+ | +-------+ +-------+ | ^ | | | +-sca----------------->+| | ^+ V RCR+へのRCN| RCR- RCA| + +へのRCN------->+| +------->+| +--scr-->+| | | | | | | | +-------+ | + +に-------+ | +-------+ | | | <、-scr-+<。------| | <、-scn-+| | <、-、-、-、--+ | Req| | Ack| | Ack| | 発信します。| RCA| Rcvd| | 発信します。| +-scn、->| |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +-sca、->|、|、| +-------+ +-------+ | +-------+ | RCR| | RCR+| RCR+| | RCR| | +------------------------------->+<。-------+ | | | | + <。-------+ <。------------------------------------------------+
Simpson [Page 15] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[15ページ]RFC1331 1992年5月
5.2. State Transition Table
5.2. 状態遷移テーブル
The complete state transition table follows. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. The state may be followed by a letter, which indicates an explanatory footnote.
完全な状態遷移テーブルは続きます。 州は水平に示されます、そして、出来事は垂直に読まれます。 状態遷移と動作はフォームに新しい動作/状態で表されます。 複数の動作が、コンマによって切り離されて、スペースが必要であるように続く線の上で続くかもしれません。 手紙は状態を支えるかもしれません。(それは、脚注を示します)。
Rationale:
原理:
In previous versions of this table, a simplified non-deterministic
finite-state automaton was used, with considerable detailed
information specified in the semantics. This lead to
interoperability problems from differing interpretations.
このテーブルの旧バージョンでは、簡易型の非決定論的な有限状態オートマトンは使用されました、かなりの詳細な情報が意味論で指定されている状態で。 異なった解釈からの相互運用性問題へのこのリード。
This table functions similarly to the previous versions, with the
up/down flags expanded to explicit states, and the active/passive
paradigm eliminated. It is believed that this table interoperates
with previous versions better than those versions themselves.
このテーブルは同様に上がるか下がるのによる旧バージョン、明白な州に広げられた旗、および除去されたアクティブであるか受け身のパラダイムに機能します。 旧バージョンがそれらのバージョン自体より良い状態でこのテーブルが共同利用すると信じられています。
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
|
RCR+ | - - sta/2 irc,scr,sca/8 4 5
RCR- | - - sta/2 irc,scr,scn/6 4 5
RCA | - - sta/2 sta/3 4 5
RCN | - - sta/2 sta/3 4 5
|
RTR | - - sta/2 sta/3 sta/4 sta/5
RTA | - - 2 3 tlf/2 tlf/3
|
RUC | - - scj/2 scj/3 scj/4 scj/5
RXJ+ | - - 2 3 4 5
RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3
|
RXR | - - 2 3 4 5
| 状態| 0 1 2 3 4 5回の出来事| 閉じられた初期の始めは、停止を閉じるのを止めました。------+----------------------------------------------------------- 上がる| 2irc、scr/6--、--、--、--下になってください| - - 0 tls/1 0 1オープン| tls/1 1irc、scr/6 3r 5r 5r Close| 0 0 2 2 4 4 | +に| - - - - str/4str/5TO| - - - - tlf/2tlf/3| RCR+| - - sta/2irc、scr、sca/8 4 5RCR| - - sta/2irc、scr、scn/6 4 5RCA| - - sta/2sta/3 4 5RCN| - - sta/2sta/3 4 5| RTR| - - sta/2sta/3sta/4sta/5RTA| - - 2 3tlf/2tlf/3| RUC| - - scj/2scj/3scj/4scj/5RXJ+| - - 2 3 4 5RXJ| - - tlf/2tlf/3tlf/2tlf/3| RXR| - - 2 3 4 5
Simpson [Page 16] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[16ページ]RFC1331 1992年5月
| State
| 6 7 8 9
Events| Req-Sent Ack-Rcvd Ack-Sent Opened
------+-----------------------------------------
Up | - - - -
Down | 1 1 1 tld/1
Open | 6 7 8 9r
Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
|
TO+ | scr/6 scr/6 scr/8 -
TO- | tlf/3p tlf/3p tlf/3p -
|
RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8
RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6
RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x
RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x
|
RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5
RTA | 6 6 8 tld,scr/6
|
RUC | scj/6 scj/7 scj/8 tld,scj,scr/6
RXJ+ | 6 6 8 9
RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5
|
RXR | 6 7 8 ser/9
| 状態| 6 7 8 9回の出来事| 開かれて、Ack-Rcvd Ackによって送られた状態で、Req発信します。------+----------------------------------------- 上がる| - - - - 下に| 1 1 1tld/1オープン| 6 7 8 9r閉鎖|irc、str/4irc、str/4irc、str/4tld、irc、str/4| +に| scr/6scr/6scr/8--TO| tlf/3p tlf/3p tlf/3p、-| RCR+| sca/8sca、tlu/9sca/8tld、scr、sca/8RCR| scn/6scn/7scn/6tld、scr、scn/6RCA| irc/7scr/6x irc、tlu/9tld、scr/6x RCN|irc、scr/6scr/6x irc、scr/8tld、scr/6x| RTR| sta/6sta/6sta/6tld、zrc、sta/5RTA| 6 6 8tld、scr/6| RUC| scj/6scj/7scj/8tld、scj、scr/6RXJ+| 6 6 8 9RXJ| tlf/3tlf/3tlf/3tld、irc、str/5| RXR| 6 7 8ser/9
The states in which the Restart timer is running are identifiable by the presence of TO events. Only the Send-Configure-Request, Send- Terminate-Request and Zero-Restart-Counter actions start or re-start the Restart timer. The Restart timer SHOULD be stopped when transitioning from any state where the timer is running to a state where the timer is not running.
Restartタイマが動いている州はTO出来事の存在が身元保証可能です。 Sendが要求を構成していて、要求を終えていてZeroがカウンタを再開しているSend動作は、始まるか、またはRestartタイマを再開するだけです。 RestartタイマSHOULD、タイマがタイマが動いていない状態を頼っているどんな状態からも移行するときには、止められてください。
[p] Passive option; see Stopped state discussion.
[p] 受け身のオプション。 Stopped州の議論を見てください。
[r] Restart option; see Open event discussion.
[r] オプションを再開してください。 オープンイベント議論を見てください。
[x] Crossed connection; see RCA event discussion.
[x] 交差している接続。 RCAイベント議論を見てください。
Simpson [Page 17] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[17ページ]RFC1331 1992年5月
5.3. States
5.3. 状態
Following is a more detailed description of each automaton state.
以下に、それぞれのオートマトン状態の、より詳細な記述があります。
Initial
初期
In the Initial state, the lower layer is unavailable (Down), and
no Open has occurred. The Restart timer is not running in the
Initial state.
Initial状態では、下層は入手できない(Down)です、そして、オープンは全く起こっていません。 RestartタイマはInitial状態に遺伝していません。
Starting
始まります。
The Starting state is the Open counterpart to the Initial state.
An administrative Open has been initiated, but the lower layer is
still unavailable (Down). The Restart timer is not running in the
Starting state.
Starting状態はInitial状態へのオープン対応者です。 管理オープンは起こされましたが、下層はまだ入手できない(Down)です。 RestartタイマはStarting状態に遺伝していません。
When the lower layer becomes available (Up), a Configure-Request
is sent.
下層が利用可能な(Up)になるとき、Configure-要求を送ります。
Closed
閉じられます。
In the Closed state, the link is available (Up), but no Open has
occurred. The Restart timer is not running in the Closed state.
Closed状態では、リンクは利用可能な(Up)ですが、オープンは全く起こっていません。 RestartタイマはClosed状態に遺伝していません。
Upon reception of Configure-Request packets, a Terminate-Ack is
sent. Terminate-Acks are silently discarded to avoid creating a
loop.
Configure-リクエスト・パケットのレセプションに、Terminate-Ackを送ります。 輪を作成するのを避けるために捨てられて、Acksを終えるのは、静かにそうです。
Stopped
止められます。
The Stopped state is the Open counterpart to the Closed state. It
is entered when the automaton is waiting for a Down event after
the This-Layer-Finished action, or after sending a Terminate-Ack.
The Restart timer is not running in the Stopped state.
Stopped状態はClosed状態へのオープン対応者です。 This層が終わっている動作の後、またはTerminate-Ackを送った後にオートマトンがDown出来事を待っているとき、それは入られます。 RestartタイマはStopped状態に遺伝していません。
Upon reception of Configure-Request packets, an appropriate
response is sent. Upon reception of other packets, a Terminate-
Ack is sent. Terminate-Acks are silently discarded to avoid
creating a loop.
Configure-リクエスト・パケットのレセプションに、適切な応答を送ります。 他のパケットのレセプションに、Terminate- Ackを送ります。 輪を作成するのを避けるために捨てられて、Acksを終えるのは、静かにそうです。
Rationale:
原理:
The Stopped state is a junction state for link termination,
link configuration failure, and other automaton failure modes.
These potentially separate states have been combined.
Stopped状態はリンク終了、リンク構成の故障、および他のオートマトン故障モードのための合流点状態です。 これらの潜在的に別々の州は合併されました。
There is a race condition between the Down event response (from
Downイベント応答の間には、競合条件がある、(
Simpson [Page 18] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[18ページ]RFC1331 1992年5月
the This-Layer-Finished action) and the Receive-Configure-
Request event. When a Configure-Request arrives before the
Down event, the Down event will supercede by returning the
automaton to the Starting state. This prevents attack by
repetition.
This層が終わっている動作) そして、Receive要求を構成している出来事。 Configure-要求がDown出来事の前に到着すると、Down出来事はStarting状態にオートマトンを返すのによるsupercedeが到着するでしょう。 これは復唱して攻撃を防ぎます。
Implementation Option:
実現オプション:
After the peer fails to respond to Configure-Requests, an
implementation MAY wait passively for the peer to send
Configure-Requests. In this case, the This-Layer-Finished
action is not used for the TO- event in states Req-Sent, Ack-
Rcvd and Ack-Sent.
同輩がConfigure-要求に応じなかった後に、実現は、同輩がConfigure-要求を送るのを受け身に待つかもしれません。 この場合、This層が終わっている動作は、Reqによって送られた状態で州のTO出来事に使用されないで、Ack- RcvdであってAckによって送られます。
This option is useful for dedicated circuits, or circuits which
have no status signals available, but SHOULD NOT be used for
switched circuits.
このオプションは利用可能などんなステータス信号も持っていなくて、SHOULD NOTを持っている専用回線、またはサーキットの役に立ちます。交換回線網には、使用されてください。
Closing
閉じます。
In the Closing state, an attempt is made to terminate the
connection. A Terminate-Request has been sent and the Restart
timer is running, but a Terminate-Ack has not yet been received.
Closing状態では、接続を終えるのを試みをします。 Terminate-要求を送りました、そして、Restartタイマは動いていますが、まだTerminate-Ackを受け取っていません。
Upon reception of a Terminate-Ack, the Closed state is entered.
Upon the expiration of the Restart timer, a new Terminate-Request
is transmitted and the Restart timer is restarted. After the
Restart timer has expired Max-Terminate times, this action may be
skipped, and the Closed state may be entered.
Terminate-Ackのレセプションに、Closed状態は入れられます。 Restartタイマの満了のときに、新しいTerminate-要求は伝えられます、そして、Restartタイマは再開されます。 この動作はサボられるかもしれません、そして、Restartタイマが期限が切れた後に、回をマックスと同じくらい終えてください、そして、Closed状態は入られてもよいです。
Stopping
停止
The Stopping state is the Open counterpart to the Closing state.
A Terminate-Request has been sent and the Restart timer is
running, but a Terminate-Ack has not yet been received.
Stopping状態はClosing状態へのオープン対応者です。 Terminate-要求を送りました、そして、Restartタイマは動いていますが、まだTerminate-Ackを受け取っていません。
Rationale:
原理:
The Stopping state provides a well defined opportunity to
terminate a link before allowing new traffic. After the link
has terminated, a new configuration may occur via the Stopped
or Starting states.
Stopping州は新しい交通を許容する前にリンクを終えるよく定義された機会を提供します。 リンクが終わった後に、新しい構成はStoppedかStarting州を通って起こるかもしれません。
Request-Sent
要求で、送ります。
In the Request-Sent state an attempt is made to configure the
connection. A Configure-Request has been sent and the Restart
timer is running, but a Configure-Ack has not yet been received
Requestによって送られた状態では、接続を構成するのを試みをします。 Configure-要求を送りました、そして、Restartタイマは動いていますが、まだConfigure-Ackを受け取っていません。
Simpson [Page 19] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[19ページ]RFC1331 1992年5月
nor has one been sent.
また、1つは送られません。
Ack-Received
Ackを受け取られていさせます。
In the Ack-Received state, a Configure-Request has been sent and a
Configure-Ack has been received. The Restart timer is still
running since a Configure-Ack has not yet been sent.
Ackによって容認された状態では、Configure-要求を送りました、そして、Configure-Ackを受け取りました。 Configure-Ackがまだ送られないので、Restartタイマはまだ動いています。
Ack-Sent
Ackによって送られます。
In the Ack-Sent state, a Configure-Request and a Configure-Ack
have both been sent but a Configure-Ack has not yet been received.
The Restart timer is always running in the Ack-Sent state.
Ackによって送られた状態では、ともにConfigure-要求とConfigure-Ackを送りましたが、まだConfigure-Ackを受け取っていません。 RestartタイマはいつもAckによって送られた状態に遺伝しています。
Opened
開かれます。
In the Opened state, a Configure-Ack has been both sent and
received. The Restart timer is not running in the Opened state.
Opened状態では、Configure-Ackを送って、受け取りました。 RestartタイマはOpened状態に遺伝していません。
When entering the Opened state, the implementation SHOULD signal
the upper layers that it is now Up. Conversely, when leaving the
Opened state, the implementation SHOULD signal the upper layers
that it is now Down.
Opened状態に入るとき、実現SHOULDは、それが現在Upであると上側の層に合図します。 Opened状態を出るとき、逆に、実現SHOULDは、それが現在Downであると上側の層に合図します。
5.4. Events
5.4. 出来事
Transitions and actions in the automaton are caused by events.
オートマトンでの変遷と動作は出来事によって引き起こされます。
Up
上がる
The Up event occurs when a lower layer indicates that it is ready
to carry packets. Typically, this event is used to signal LCP
that the link is entering Link Establishment phase, or used to
signal a NCP that the link is entering Network-Layer Protocol
phase.
下層が、それがパケットを運ぶ準備ができているのを示すとき、Up出来事は起こります。 この出来事は、通常、リンクがLink特権階級フェーズに入っているとLCPに合図するのに使用されるか、またはリンクがNetwork-層のプロトコルフェーズに入っているとNCPに合図するのに使用されます。
Down
下に
The Down event occurs when a lower layer indicates that it is no
longer ready to carry packets. Typically, this event is used to
signal LCP that the link is entering Link Dead phase, or used to
signal a NCP that the link is leaving Network-Layer Protocol
phase.
下層が、それがもうパケットを運ぶ準備ができていないのを示すとき、Down出来事は起こります。 この出来事は、通常、リンクがLink Deadフェーズに入っているとLCPに合図するのに使用されるか、またはリンクがNetwork-層のプロトコルをフェーズに残しているとNCPに合図するのに使用されます。
Open
開いてください。
The Open event indicates that the link is administratively
available for traffic; that is, the network administrator (human
オープン出来事は、リンクが行政上交通に利用可能であることを示します。 すなわち、ネットワーク管理者、(人間
Simpson [Page 20] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[20ページ]RFC1331 1992年5月
or program) has indicated that the link is allowed to be Opened.
When this event occurs, and the link is not in the Opened state,
the automaton attempts to send configuration packets to the peer.
または、プログラム) リンクがOpenedであることが許容されているのを示しました。 この出来事が起こって、リンクがOpened状態にないとき、オートマトンは、構成パケットを同輩に送るのを試みます。
If the automaton is not able to begin configuration (the lower
layer is Down, or a previous Close event has not completed), the
establishment of the link is automatically delayed.
オートマトンは構成を始めることができません。または、(下層がDownである、前のClose出来事が完成していない、)、リンクの設立は自動的に遅れます。
When a Terminate-Request is received, or other events occur which
cause the link to become unavailable, the automaton will progress
to a state where the link is ready to re-open. No additional
administrative intervention should be necessary.
Terminate-要求が受信されているか、またはリンクが入手できなくなる他の出来事が起こると、オートマトンはリンクが再開する準備ができている状態に進むでしょう。 どんな追加管理介入も必要であるべきではありません。
Implementation Note:
実現注意:
Experience has shown that users will execute an additional Open
command when they want to renegotiate the link. Since this is
not the meaning of the Open event, it is suggested that when an
Open user command is executed in the Opened, Closing, Stopping,
or Stopped states, the implementation issue a Down event,
immediately followed by an Up event. This will cause the
renegotiation of the link, without any harmful side effects.
経験は、彼らがリンクを再交渉したがっているとき、ユーザが追加オープン命令を実行するのを示しました。 これがオープン出来事の意味でないので、Up出来事はオープンユーザ命令がOpenedで実行されるとき、Closing、Stopping、またはStopped州、実現がDown出来事を発行して、すぐに続いて発行することが提案されます。 これは少しも有害な副作用なしでリンクの再交渉を引き起こすでしょう。
Close
閉鎖
The Close event indicates that the link is not available for
traffic; that is, the network administrator (human or program) has
indicated that the link is not allowed to be Opened. When this
event occurs, and the link is not in the Closed state, the
automaton attempts to terminate the connection. Futher attempts
to re-configure the link are denied until a new Open event occurs.
Close出来事は、リンクが交通に利用可能でないことを示します。 すなわち、ネットワーク管理者(人間かプログラム)は、リンクがOpenedであることが許容されていないのを示しました。 この出来事が起こって、リンクがClosed状態にないとき、オートマトンは、接続を終えるのを試みます。 新しいオープン出来事が起こるまで、リンクを再構成するFuther試みは否定されます。
Timeout (TO+,TO-)
タイムアウト(+に-、)
This event indicates the expiration of the Restart timer. The
Restart timer is used to time responses to Configure-Request and
Terminate-Request packets.
この出来事はRestartタイマの満了を示します。 RestartタイマはConfigure-要求とTerminate-リクエスト・パケットへの時間応答に使用されます。
The TO+ event indicates that the Restart counter continues to be
greater than zero, which triggers the corresponding Configure-
Request or Terminate-Request packet to be retransmitted.
TO+出来事は、再送されるためにRestartカウンタがずっとゼロ以上であることを示します。(それは、対応するConfigure要求かTerminate-リクエスト・パケットの引き金となります)。
The TO- event indicates that the Restart counter is not greater
than zero, and no more packets need to be retransmitted.
TO出来事は、Restartカウンタがゼロ以上でなく、またそれ以上のパケットが、再送される必要でないのを示します。
Receive-Configure-Request (RCR+,RCR-)
受信、要求を構成してください。(RCR+、RCR)
This event occurs when a Configure-Request packet is received from
Configure-リクエスト・パケットから受け取るとき、この出来事は起こります。
Simpson [Page 21] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[21ページ]RFC1331 1992年5月
the peer. The Configure-Request packet indicates the desire to
open a connection and may specify Configuration Options. The
Configure-Request packet is more fully described in a later
section.
同輩。 Configure-リクエスト・パケットは、接続を開く願望を示して、Configuration Optionsを指定するかもしれません。 Configure-リクエスト・パケットは後のセクションで、より完全に説明されます。
The RCR+ event indicates that the Configure-Request was
acceptable, and triggers the transmission of a corresponding
Configure-Ack.
RCR+出来事は、Configure-要求が許容できたのを示して、対応するConfigure-Ackのトランスミッションの引き金となります。
The RCR- event indicates that the Configure-Request was
unacceptable, and triggers the transmission of a corresponding
Configure-Nak or Configure-Reject.
RCR出来事は、Configure-要求が容認できなかったのを示して、対応するConfigure-NakかConfigure-廃棄物のトランスミッションの引き金となります。
Implementation Note:
実現注意:
These events may occur on a connection which is already in the
Opened state. The implementation MUST be prepared to
immediately renegotiate the Configuration Options.
これらの出来事はOpened状態に既にある接続のときに起こるかもしれません。 至急Configuration Optionsを再交渉するように実現を準備しなければなりません。
Receive-Configure-Ack (RCA)
受信、Ackを構成してください。(RCA)
The Receive-Configure-Ack event occurs when a valid Configure-Ack
packet is received from the peer. The Configure-Ack packet is a
positive response to a Configure-Request packet. An out of
sequence or otherwise invalid packet is silently discarded.
同輩から有効なConfigure-Ackパケットを受け取るとき、ReceiveがAckを構成している出来事は起こります。 Configure-AckパケットはConfigure-リクエスト・パケットへの積極的な応答です。 順序が狂ってかそうでなさ、無効のパケットは静かに捨てられます。
Implementation Note:
実現注意:
Since the correct packet has already been received before
reaching the Ack-Rcvd or Opened states, it is extremely
unlikely that another such packet will arrive. As specified,
all invalid Ack/Nak/Rej packets are silently discarded, and do
not affect the transitions of the automaton.
Ack-RcvdかOpened州に達する前に既に正しいパケットを受け取ったので、別のそのようなパケットが到着するのは、非常にありそうもないです。 指定されるように、すべての無効のAck/Nak/レイパケットは、静かに捨てられて、オートマトンの変遷に影響しません。
However, it is not impossible that a correctly formed packet
will arrive through a coincidentally-timed cross-connection.
It is more likely to be the result of an implementation error.
At the very least, this occurance should be logged.
しかしながら、正しく形成されたパケットが一致して調節された交差接続で到着するのは、不可能ではありません。 それは実現誤りの結果であるより傾向があります。 少なくとも、このoccuranceは登録されるべきです。
Receive-Configure-Nak/Rej (RCN)
受信、Nakを構成してください、/レイ(RCN)
This event occurs when a valid Configure-Nak or Configure-Reject
packet is received from the peer. The Configure-Nak and
Configure-Reject packets are negative responses to a Configure-
Request packet. An out of sequence or otherwise invalid packet is
silently discarded.
同輩から有効なConfigure-NakかConfigure-廃棄物パケットを受け取るとき、この出来事は起こります。 Configure-NakとConfigure-廃棄物パケットはConfigureリクエスト・パケットへの否定応答です。 順序が狂ってかそうでなさ、無効のパケットは静かに捨てられます。
Simpson [Page 22] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[22ページ]RFC1331 1992年5月
Implementation Note:
実現注意:
Although the Configure-Nak and Configure-Reject cause the same
state transition in the automaton, these packets have
significantly different effects on the Configuration Options
sent in the resulting Configure-Request packet.
Configure-NakとConfigure-廃棄物はオートマトンで同じ状態遷移を引き起こしますが、これらのパケットは結果として起こるConfigure-リクエスト・パケットで送られたConfiguration Optionsにかなり異なった影響を与えます。
Receive-Terminate-Request (RTR)
受信、要求を終えてください。(RTR)
The Receive-Terminate-Request event occurs when a Terminate-
Request packet is received. The Terminate-Request packet
indicates the desire of the peer to close the connection.
Terminateリクエスト・パケットが受け取られているとき、Receiveが要求を終えている出来事は起こります。 Terminate-リクエスト・パケットは同輩が接続を終える願望を示します。
Implementation Note:
実現注意:
This event is not identical to the Close event (see above), and
does not override the Open commands of the local network
administrator. The implementation MUST be prepared to receive
a new Configure-Request without network administrator
intervention.
この出来事は、Close出来事(上を見る)と同じでなく、また企業内情報通信網の管理者のオープン命令に優越しません。 ネットワーク管理者介入なしで新しいConfigure-要求を受け取るように実現を準備しなければなりません。
Receive-Terminate-Ack (RTA)
受信、Ackを終えてください。(RTA)
The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
is received from the peer. The Terminate-Ack packet is usually a
response to a Terminate-Request packet. The Terminate-Ack packet
may also indicate that the peer is in Closed or Stopped states,
and serves to re-synchronize the link configuration.
同輩からTerminate-Ackパケットを受け取るとき、ReceiveがAckを終えている出来事は起こります。 通常、Terminate-AckパケットはTerminate-リクエスト・パケットへの応答です。 また、Terminate-Ackパケットが、同輩がClosedにいるのを示すかもしれないか、Stoppedは、リンク構成を再同期させるのに述べて、役立ちます。
Receive-Unknown-Code (RUC)
未知のコードを受け取ってください。(RUC)
The Receive-Unknown-Code event occurs when an un-interpretable
packet is received from the peer. A Code-Reject packet is sent in
response.
同輩から不-解明できるパケットを受け取るとき、Receiveの未知のコードイベントは起こります。 応答でCode-廃棄物パケットを送ります。
Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)
コード廃棄物を受けてください、そして、プロトコル廃棄物を受けてください。(RXJ+、RXJ)
This event occurs when a Code-Reject or a Protocol-Reject packet
is received from the peer.
同輩からCode-廃棄物かプロトコル廃棄物パケットを受け取るとき、この出来事は起こります。
The RXJ+ event arises when the rejected value is acceptable, such
as a Code-Reject of an extended code, or a Protocol-Reject of a
NCP. These are within the scope of normal operation. The
implementation MUST stop sending the offending packet type.
拒絶された値が許容できるとき、RXJ+出来事は起こります、拡張コードのCode-廃棄物、またはNCPのプロトコル廃棄物などのように。 通常の操作の範囲の中にこれらはあります。 実現は、怒っているパケットタイプを送るのを止めなければなりません。
The RXJ- event arises when the rejected value is catastrophic,
such as a Code-Reject of Configure-Request, or a Protocol-Reject
of LCP! This event communicates an unrecoverable error that
拒絶された値が壊滅的であるときに、RXJ出来事は起こります、Configure-要求のCode-廃棄物、またはLCPのプロトコル廃棄物などのように! この出来事が回復不能エラーを伝える、それ
Simpson [Page 23] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[23ページ]RFC1331 1992年5月
terminates the connection.
接続を終えます。
Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request (RXR)
エコー要求を受け取って、エコー・リプライを受ける、受信、要求を捨ててください。(RXR)
This event occurs when an Echo-Request, Echo-Reply or Discard-
Request packet is received from the peer. The Echo-Reply packet
is a response to a Echo-Request packet. There is no reply to an
Echo-Reply or Discard-Request packet.
同輩からEcho-要求、Echo-回答またはDiscardリクエスト・パケットを受け取るとき、この出来事は起こります。 Echo-回答パケットはEcho-リクエスト・パケットへの応答です。 Echo-回答かDiscard-リクエスト・パケットに関する回答が全くありません。
5.5. Actions
5.5. 動作
Actions in the automaton are caused by events and typically indicate the transmission of packets and/or the starting or stopping of the Restart timer.
オートマトンでの動作は、出来事によって引き起こされて、Restartタイマのパケットのトランスミッション、そして/または、始めか停止を通常示します。
Illegal-Event (-)
不法な出来事(-)
This indicates an event that SHOULD NOT occur. The implementation
probably has an internal error.
これは出来事を示します。SHOULD NOTは起こります。 実現には、内部エラーがたぶんあります。
This-Layer-Up (tlu)
この層の上(tlu)
This action indicates to the upper layers that the automaton is
entering the Opened state.
この動作は、オートマトンがOpened状態に入っているのを上側の層に示します。
Typically, this action MAY be used by the LCP to signal the Up
event to a NCP, Authentication Protocol, or Link Quality Protocol,
or MAY be used by a NCP to indicate that the link is available for
its traffic.
この動作は通常、NCP、Authenticationプロトコル、またはLink QualityプロトコルへのUp出来事に合図するのにLCPによって使用されるか、またはNCPによって使用されて、リンクが交通に利用可能であることを示すかもしれません。
This-Layer-Down (tld)
この層の下(tld)
This action indicates to the upper layers that the automaton is
leaving the Opened state.
この動作は、オートマトンがOpenedを状態に出発しているのを上側の層に示します。
Typically, this action MAY be used by the LCP to signal the Down
event to a NCP, Authentication Protocol, or Link Quality Protocol,
or MAY be used by a NCP to indicate that the link is no longer
available for its traffic.
この動作は通常、NCP、Authenticationプロトコル、またはLink QualityプロトコルへのDown出来事に合図するのにLCPによって使用されるか、またはNCPによって使用されて、リンクがもう交通に利用可能でないことを示すかもしれません。
This-Layer-Start (tls)
この層の始め(tls)
This action indicates to the lower layers that the automaton is
entering the Starting state, and the lower layer is needed for the
link. The lower layer SHOULD respond with an Up event when the
lower layer is available.
この動作は、オートマトンがStarting状態に入っているのを下層に示します、そして、下層がリンクに必要です。 下層が利用可能であるときに、下層SHOULDはUp出来事で応じます。
Simpson [Page 24] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[24ページ]RFC1331 1992年5月
This action is highly implementation dependent.
この動作は実現に非常に依存しています。
This-Layer-Finished (tlf)
この層は終わりました。(tlf)
This action indicates to the lower layers that the automaton is
entering the Stopped or Closed states, and the lower layer is no
longer needed for the link. The lower layer SHOULD respond with a
Down event when the lower layer has terminated.
この動作は、オートマトンがStoppedかClosed州に入っているのを下層に示します、そして、下層はもうリンクに必要ではありません。 下層が終わったとき、下層SHOULDはDown出来事で応じます。
Typically, this action MAY be used by the LCP to advance to the
Link Dead phase, or MAY be used by a NCP to indicate to the LCP
that the link may terminate when there are no other NCPs open.
この動作は通常、Link Deadフェーズに達するのにLCPによって使用されるか、またはNCPによって使用されて、いつ、他のNCP戸外が全くないかをリンクが終えるかもしれないLCPに示すかもしれません。
This action is highly implementation dependent.
この動作は実現に非常に依存しています。
Initialize-Restart-Counter (irc)
再開カウンタを初期化してください。(irc)
This action sets the Restart counter to the appropriate value
(Max-Terminate or Max-Configure). The counter is decremented for
each transmission, including the first.
この動作は適切な値(マックスと同じくらい終えるか、またはマックスと同じくらい構成する)にRestartカウンタを設定します。 カウンタは1番目を含む各トランスミッション単位で減少します。
Zero-Restart-Counter (zrc)
再開の無カウンタ(zrc)
This action sets the Restart counter to zero.
この動作はRestartカウンタをゼロに設定します。
Implementation Note:
実現注意:
This action enables the FSA to pause before proceeding to the
desired final state. In addition to zeroing the Restart
counter, the implementation MUST set the timeout period to an
appropriate value.
この動作は、FSAが必要な最終的な状態に進む前に止まるのを可能にします。 Restartカウンタのゼロを合わせることに加えて、実現は適切な値にタイムアウト時間を決めなければなりません。
Send-Configure-Request (scr)
発信、要求を構成してください。(scr)
The Send-Configure-Request action transmits a Configure-Request
packet. This indicates the desire to open a connection with a
specified set of Configuration Options. The Restart timer is
started when the Configure-Request packet is transmitted, to guard
against packet loss. The Restart counter is decremented each time
a Configure-Request is sent.
Sendが要求を構成している動作はConfigure-リクエスト・パケットを伝えます。 これはConfiguration Optionsの指定されたセットとの接続を開く願望を示します。 Configure-リクエスト・パケットがパケット損失に用心するために伝えられるとき、Restartタイマは始動されます。 RestartカウンタはConfigure-要求を送るたびに減少します。
Send-Configure-Ack (sca)
発信、Ackを構成してください。(sca)
The Send-Configure-Ack action transmits a Configure-Ack packet.
This acknowledges the reception of a Configure-Request packet with
an acceptable set of Configuration Options.
SendがAckを構成している動作はConfigure-Ackパケットを伝えます。 これはConfiguration Optionsの許容できるセットがあるConfigure-リクエスト・パケットのレセプションを承認します。
Simpson [Page 25] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[25ページ]RFC1331 1992年5月
Send-Configure-Nak (scn)
発信、Nakを構成してください。(scn)
The Send-Configure-Nak action transmits a Configure-Nak or
Configure-Reject packet, as appropriate. This negative response
reports the reception of a Configure-Request packet with an
unacceptable set of Configuration Options. Configure-Nak packets
are used to refuse a Configuration Option value, and to suggest a
new, acceptable value. Configure-Reject packets are used to
refuse all negotiation about a Configuration Option, typically
because it is not recognized or implemented. The use of
Configure-Nak versus Configure-Reject is more fully described in
the section on LCP Packet Formats.
SendがNakを構成している動作は適宜Configure-NakかConfigure-廃棄物パケットを伝えます。 この否定応答はConfiguration Optionsの容認できないセットでConfigure-リクエスト・パケットのレセプションを報告します。 Nakを構成しているパケットは、Configuration Option値を拒否して、新しくて、許容できる値を示すのに使用されます。 それが通常認識もされませんし、実装もされないので、廃棄物を構成しているパケットはConfiguration Optionに関してすべての交渉を拒否するのに使用されます。 Configure-Nak対Configure-廃棄物の使用はLCP Packet Formatsの上のセクションで、より完全に説明されます。
Send-Terminate-Request (str)
発信、要求を終えてください。(str)
The Send-Terminate-Request action transmits a Terminate-Request
packet. This indicates the desire to close a connection. The
Restart timer is started when the Terminate-Request packet is
transmitted, to guard against packet loss. The Restart counter is
decremented each time a Terminate-Request is sent.
Sendが要求を終えている動作はTerminate-リクエスト・パケットを伝えます。 これは接続を終える願望を示します。 Terminate-リクエスト・パケットがパケット損失に用心するために伝えられるとき、Restartタイマは始動されます。 RestartカウンタはTerminate-要求を送るたびに減少します。
Send-Terminate-Ack (sta)
発信、Ackを終えてください。(sta)
The Send-Terminate-Ack action transmits a Terminate-Ack packet.
This acknowledges the reception of a Terminate-Request packet or
otherwise serves to synchronize the state machines.
SendがAckを終えている動作はTerminate-Ackパケットを伝えます。 これは、Terminate-リクエスト・パケットのレセプションを認めるか、またはそうでなければ、州のマシンを連動させるのに役立ちます。
Send-Code-Reject (scj)
コード廃棄物を送ってください。(scj)
The Send-Code-Reject action transmits a Code-Reject packet. This
indicates the reception of an unknown type of packet.
Sendコード廃棄物動作はCode-廃棄物パケットを伝えます。 これは未知のタイプのパケットのレセプションを示します。
Send-Echo-Reply (ser)
エコー・リプライを発信させます。(ser)
The Send-Echo-Reply action transmits an Echo-Reply packet. This
acknowledges the reception of an Echo-Request packet.
Sendエコー回答動作はEcho-回答パケットを伝えます。 これはEcho-リクエスト・パケットのレセプションを承認します。
5.6. Loop Avoidance
5.6. 輪の回避
The protocol makes a reasonable attempt at avoiding Configuration Option negotiation loops. However, the protocol does NOT guarantee that loops will not happen. As with any negotiation, it is possible to configure two PPP implementations with conflicting policies that will never converge. It is also possible to configure policies which do converge, but which take significant time to do so. Implementors should keep this in mind and should implement loop detection mechanisms or higher level timeouts.
プロトコルはConfiguration Optionネゴシエーション・ループを避けることへの合理的な試みをします。 しかしながら、プロトコルは、輪が起こらないのを保証しません。 どんな交渉のようにも、決して一点に集まらない闘争方針で2つのPPP実装を構成するのは可能です。 また、一点に集まりますが、そうするには重要な時間がかかる方針を構成するのも可能です。 作成者は、これを覚えておくべきであり、輪の検出がメカニズムか、より高い平らなタイムアウトであると実装するべきです。
Simpson [Page 26] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[26ページ]RFC1331 1992年5月
5.7. Counters and Timers
5.7. カウンタとタイマ
Restart Timer
再開タイマ
There is one special timer used by the automaton. The Restart timer is used to time transmissions of Configure-Request and Terminate- Request packets. Expiration of the Restart timer causes a Timeout event, and retransmission of the corresponding Configure-Request or Terminate-Request packet. The Restart timer MUST be configurable, but MAY default to three (3) seconds.
オートマトンによって使用される1個の特別なタイマがあります。 RestartタイマはConfigure-要求とTerminateリクエスト・パケットの時間送信に使用されます。 Restartタイマの満了はTimeoutイベント、および対応するConfigure-要求かTerminate-リクエスト・パケットの「再-トランスミッション」を引き起こします。 Restartタイマは、構成可能でなければなりませんが、3(3)秒をデフォルトとするかもしれません。
Implementation Note:
実装注意:
The Restart timer SHOULD be based on the speed of the link. The
default value is designed for low speed (19,200 bps or less), high
switching latency links (typical telephone lines). Higher speed
links, or links with low switching latency, SHOULD have
correspondingly faster retransmission times.
RestartタイマSHOULDはリンクの速度に基づいたそうです。 デフォルト値は低速(1万9200よりビーピーエス)、高い切り換え潜在リンク(典型的な電話回線)に設計されています。 より高い速度リンク、または低い切り換え潜在とのリンク、SHOULDが対応するより速い「再-トランスミッション」時を過します。
Max-Terminate
マックスと同じくらい終わってください。
There is one required restart counter for Terminate-Requests. Max- Terminate indicates the number of Terminate-Request packets sent without receiving a Terminate-Ack before assuming that the peer is unable to respond. Max-Terminate MUST be configurable, but should default to two (2) transmissions.
Terminate-要求のための1台の必要な再開カウンタがあります。 マックスは終わります。Terminate-リクエスト・パケットの数が同輩が応じることができないと仮定する前にTerminate-Ackを受けないで発信したのを示します。 マックスと同じくらい終わってください。構成可能でなければなりませんが、(2)2個のトランスミッションをデフォルトとするべきです。
Max-Configure
マックスと同じくらい構成します。
A similar counter is recommended for Configure-Requests. Max- Configure indicates the number of Configure-Request packets sent without receiving a valid Configure-Ack, Configure-Nak or Configure- Reject before assuming that the peer is unable to respond. Max- Configure MUST be configurable, but should default to ten (10) transmissions.
同様のカウンタはConfigure-要求のために推薦されます。 マックスが、有効なConfigure-Ackを受けないで送られたConfigure-リクエスト・パケットの数、Configure-Nakが示すのを構成するか、またはConfigureは以前、同輩が反応させることができない仮定を拒絶します。 マックスが構成する、構成可能でなければなりませんが、10(10)トランスミッションをデフォルトとするべきです。
Max-Failure
マックス-失敗
A related counter is recommended for Configure-Nak. Max-Failure indicates the number of Configure-Nak packets sent without sending a Configure-Ack before assuming that configuration is not converging. Any further Configure-Nak packets are converted to Configure-Reject packets. Max-Failure MUST be configurable, but should default to ten (10) transmissions.
関連するカウンタはConfigure-Nakのために推薦されます。 マックス-失敗は、その構成を仮定する前にConfigure-Ackを送らないで送られたConfigure-Nakパケットの数が一点に集まっていないのを示します。 どんな一層のConfigure-NakパケットもConfigure-廃棄物パケットに変換されます。 マックス-失敗は、構成可能でなければなりませんが、10(10)トランスミッションをデフォルトとするべきです。
Simpson [Page 27] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[27ページ]RFC1331 1992年5月
6. LCP Packet Formats
6. LCPパケット・フォーマット
There are three classes of LCP packets:
3つのクラスのLCPパケットがあります:
1. Link Configuration packets used to establish and configure a
link (Configure-Request, Configure-Ack, Configure-Nak and
Configure-Reject).
1. リンクConfigurationパケットがリンクを設立して、以前はよく構成していた、(要求を構成する、Configure-Ack、Configure-Nak、およびConfigure-廃棄物)
2. Link Termination packets used to terminate a link (Terminate-
Request and Terminate-Ack).
2. リンクTerminationパケットは以前はよくリンクを終えていました(要求とTerminate-Ackを終えてください)。
3. Link Maintenance packets used to manage and debug a link
(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and
Discard-Request).
3. リンクMaintenanceパケットは、リンク(コード廃棄物、プロトコル廃棄物、Echo-要求、Echo-回答、およびDiscard-要求)を管理して、以前は、よくデバッグしていました。
This document describes Version 1 of the Link Control Protocol. In the interest of simplicity, there is no version field in the LCP packet. If a new version of LCP is necessary in the future, the intention is that a new Data Link Layer Protocol field value will be used to differentiate Version 1 LCP from all other versions. A correctly functioning Version 1 LCP implementation will always respond to unknown Protocols (including other versions) with an easily recognizable Version 1 packet, thus providing a deterministic fallback mechanism for implementations of other versions.
このドキュメントはLink Controlプロトコルのバージョン1について説明します。 簡単さのために、バージョン分野は全くLCPパケットにありません。 LCPの新しいバージョンが将来必要であるなら、意志は新しいData Link Layerプロトコル分野価値が他のすべてのバージョンとバージョン1LCPを区別するのに使用されるということです。 正しく機能しているバージョン1LCP実装はいつも容易に認識可能なバージョン1パケットで未知のプロトコル(他のバージョンを含んでいる)に応じるでしょう、その結果、決定論的な後退メカニズムを他のバージョンの実装に提供します。
Regardless of which Configuration Options are enabled, all LCP Link Configuration, Link Termination, and Code-Reject packets (codes 1 through 7) are always sent in the full, standard form, as if no Configuration Options were enabled. This ensures that LCP Configure-Request packets are always recognizable even when one end of the link mistakenly believes the link to be open.
どのConfiguration Optionsが有効にされるかにかかわらず、完全で、標準のフォームでいつもすべてのLCP Link Configuration、Link Termination、およびCode-廃棄物パケット(1〜7に、コード化する)を送ります、まるでConfiguration Optionsが全く有効にされないかのように。 これはLCP Configure-リクエスト・パケットが確実にリンクの片端が、リンクが開いていると誤って信じるときさえ、いつも認識可能になるようにします。
Exactly one Link Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex c021 (Link Control Protocol).
ちょうど1つのLink Controlプロトコルパケットがプロトコル分野がタイプ十六進法c021を示す(Controlプロトコルをリンクしてください)PPP Data Link Layerフレームの情報分野でカプセルに入れられます。
A summary of the Link Control Protocol packet format is shown below. The fields are transmitted from left to right.
Link Controlプロトコルパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Simpson [Page 28] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[28ページ]RFC1331 1992年5月
Code
コード
The Code field is one octet and identifies the kind of LCP packet.
When a packet is received with an invalid Code field, a Code-
Reject packet is transmitted.
Code分野は、1つの八重奏であり、LCPパケットの種類を特定します。 無効のCode分野でパケットを受け取るとき、Code廃棄物パケットを伝えます。
The most up-to-date values of the LCP Code field are specified in
the most recent "Assigned Numbers" RFC [11]. Current values are
assigned as follows:
LCP Code分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。 現行価値は以下の通り割り当てられます:
1 Configure-Request
2 Configure-Ack
3 Configure-Nak
4 Configure-Reject
5 Terminate-Request
6 Terminate-Ack
7 Code-Reject
8 Protocol-Reject
9 Echo-Request
10 Echo-Reply
11 Discard-Request
12 RESERVED
1 エコー・リプライ11が、12が控えたよう破棄して要求する要求を終えている要求を構成しているAckを構成しているNakを構成している廃棄物を構成しているAckを終えている2の7コード廃棄物8プロトコル廃棄物9 3 4 5 6エコー要求10
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies. When a packet is received with an invalid Identifier
field, the packet is silently discarded.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 無効のIdentifier分野でパケットを受け取るとき、静かにパケットを捨てます。
Length
長さ
The Length field is two octets and indicates the length of the LCP
packet including the Code, Identifier, Length and Data fields.
Octets outside the range of the Length field should be treated as
Data Link Layer padding and should be ignored on reception. When
a packet is received with an invalid Length field, the packet is
silently discarded.
Length分野は、2つの八重奏であり、Code、Identifier、Length、およびData分野を含むLCPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。 無効のLength分野でパケットを受け取るとき、静かにパケットを捨てます。
Data
データ
The Data field is zero or more octets as indicated by the Length
field. The format of the Data field is determined by the Code
field.
Data分野はゼロであるか以上がLength分野によって示される八重奏です。 Data分野の形式はCode分野のそばで決定しています。
Simpson [Page 29] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[29ページ]RFC1331 1992年5月
6.1. Configure-Request
6.1. 要求を構成します。
Description
記述
A LCP implementation wishing to open a connection MUST transmit a
LCP packet with the Code field set to 1 (Configure-Request) and
the Options field filled with any desired changes to the default
link Configuration Options.
接続を開くLCP実装願望は1(要求を構成している)に設定されたCode分野とデフォルトリンクConfiguration Optionsへのどんな必要な変化でも満たされたOptions分野でLCPパケットを伝えなければなりません。
Upon reception of a Configure-Request, an appropriate reply MUST
be transmitted.
Configure-要求のレセプションでは、適切な回答を伝えなければなりません。
A summary of the Configure-Request packet format is shown below. The fields are transmitted from left to right.
Configure-リクエスト・パケット形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
1 for Configure-Request.
1、要求を構成します。
Identifier
識別子
The Identifier field SHOULD be changed on each transmission. On
reception, the Identifier field should be copied into the
Identifier field of the appropriate reply packet.
IdentifierはSHOULDをさばきます。各トランスミッションのときに、変えます。 レセプションでは、Identifier分野は適切な回答パケットのIdentifier分野にコピーされるべきです。
Options
オプション
The options field is variable in length and contains the list of
zero or more Configuration Options that the sender desires to
negotiate. All Configuration Options are always negotiated
simultaneously. The format of Configuration Options is further
described in a later section.
オプション分野は、長さで可変であり、ゼロのリストか送付者が交渉することを望んでいるより多くのConfiguration Optionsを含んでいます。 すべてのConfiguration Optionsが同時に、いつも交渉されます。 Configuration Optionsの形式は後のセクションでさらに説明されます。
Simpson [Page 30] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[30ページ]RFC1331 1992年5月
6.2. Configure-Ack
6.2. Ackを構成します。
Description
記述
If every Configuration Option received in a Configure-Request is
both recognizable and acceptable, then a LCP implementation should
transmit a LCP packet with the Code field set to 2 (Configure-
Ack), the Identifier field copied from the received Configure-
Request, and the Options field copied from the received
Configure-Request. The acknowledged Configuration Options MUST
NOT be reordered or modified in any way.
Configure-要求に受け取られたあらゆるConfiguration Optionが認識可能であって、かつ許容できるなら、LCP実装はCode分野セットでLCPパケットを2に伝えるべきです、そして、(Ackを構成してください)Identifier分野は受信されたConfigure要求からコピーされました、そして、Options分野は受信されたConfigure-要求からコピーされました。 何らかの方法で承認されたConfiguration Optionsを再命令されてはいけないか、変更してはいけません。
On reception of a Configure-Ack, the Identifier field must match
that of the last transmitted Configure-Request. Additionally, the
Configuration Options in a Configure-Ack must exactly match those
of the last transmitted Configure-Request. Invalid packets are
silently discarded.
Configure-Ackのレセプションと、Identifier分野は最後に伝えられたConfigure-要求のものを合わせなければなりません。 さらに、Configure-AckのConfiguration Optionsはまさに最後に伝えられたConfigure-要求のものに合わなければなりません。 無効のパケットは静かに捨てられます。
A summary of the Configure-Ack packet format is shown below. The fields are transmitted from left to right.
Configure-Ackパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
2 for Configure-Ack.
2、Ackを構成します。
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Configure-Request which caused this Configure-Ack.
Identifier分野はこのConfigure-Ackを引き起こしたConfigure-要求のIdentifier分野のコピーです。
Options
オプション
The Options field is variable in length and contains the list of
zero or more Configuration Options that the sender is
acknowledging. All Configuration Options are always acknowledged
simultaneously.
Options分野は、長さで可変であり、ゼロのリストか送付者が承認しているより多くのConfiguration Optionsを含んでいます。 すべてのConfiguration Optionsが同時に、いつも承認されます。
Simpson [Page 31] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[31ページ]RFC1331 1992年5月
6.3. Configure-Nak
6.3. Nakを構成します。
Description
記述
If every element of the received Configuration Options is
recognizable but some are not acceptable, then a LCP
implementation should transmit a LCP packet with the Code field
set to 3 (Configure-Nak), the Identifier field copied from the
received Configure-Request, and the Options field filled with only
the unacceptable Configuration Options from the Configure-Request.
All acceptable Configuration Options are filtered out of the
Configure-Nak, but otherwise the Configuration Options from the
Configure-Request MUST NOT be reordered.
容認されたConfiguration Optionsのあらゆる要素が認識可能ですが、或るものが許容できないなら、LCP実装はCode分野セットで3(Nakを構成している)にLCPパケットを伝えるべきです、そして、Identifier分野は受信されたConfigure-要求からコピーされました、そして、Options分野はConfigure-要求から容認できないConfiguration Optionsだけで満ちました。 すべての許容できるConfiguration OptionsがConfigure-Nakからフィルターにかけられますが、さもなければ、Configure-要求からのConfiguration Optionsを再命令してはいけません。
Each of the Nak'd Configuration Options MUST be modified to a
value acceptable to the Configure-Nak sender. Options which have
no value fields (boolean options) use the Configure-Reject reply
instead.
それぞれ、Nakについて、Configure-Nak送付者にとって、許容できる値にConfiguration Optionsを変更しなければならないでしょうか? 値の分野(論理演算子オプション)を全く持っていないオプションが代わりにConfigure-廃棄物回答を使用します。
Finally, an implementation may be configured to request the
negotiation of a specific option. If that option is not listed,
then that option may be appended to the list of Nak'd
Configuration Options in order to request the peer to list that
option in its next Configure-Request packet. Any value fields for
the option MUST indicate values acceptable to the Configure-Nak
sender.
最終的に、実装は、特定のオプションの交渉を要求するために構成されるかもしれません。 そのオプションが記載されていないなら、Nakのリストにオプションを追加するかもしれないその時が記載するだろう、Configuration Options、それを記載するよう同輩に要求するには、次のConfigure-リクエスト・パケットを中にゆだねてください。 オプションのためのどんな値の分野もConfigure-Nak送付者にとって、許容できる値を示さなければなりません。
On reception of a Configure-Nak, the Identifier field must match
that of the last transmitted Configure-Request. Invalid packets
are silently discarded.
Configure-Nakのレセプションと、Identifier分野は最後に伝えられたConfigure-要求のものを合わせなければなりません。 無効のパケットは静かに捨てられます。
Reception of a valid Configure-Nak indicates that a new
Configure-Request MAY be sent with the Configuration Options
modified as specified in the Configure-Nak.
有効なConfigure-Nakのレセプションは、Configure-Nakで指定されるようにConfiguration Optionsが変更されている状態で新しいConfigure-要求が送られるかもしれないのを示します。
Some Configuration Options have a variable length. Since the
Nak'd Option has been modified by the peer, the implementation
MUST be able to handle an Option length which is different from
the original Configure-Request.
いくつかのConfiguration Optionsには、可変長があります。 Nakはそうするでしょう、したがって、Optionが同輩が変更されて、実装はオリジナルのConfigure-要求と異なったOptionの長さを扱うことができなければなりません。
Simpson [Page 32] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[32ページ]RFC1331 1992年5月
A summary of the Configure-Nak packet format is shown below. The fields are transmitted from left to right.
Configure-Nakパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
3 for Configure-Nak.
3、Nakを構成します。
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Configure-Request which caused this Configure-Nak.
Identifier分野はこのConfigure-Nakを引き起こしたConfigure-要求のIdentifier分野のコピーです。
Options
オプション
The Options field is variable in length and contains the list of
zero or more Configuration Options that the sender is Nak'ing.
All Configuration Options are always Nak'd simultaneously.
Options分野は、長さで可変であり、ゼロのリストか、より多くのConfiguration Optionsを含んでいます。送付者はNak'ingです。 いつもすべてのConfiguration Optionsがそうです。Nakは同時に、そうするでしょう。
6.4. Configure-Reject
6.4. 廃棄物を構成します。
Description
記述
If some Configuration Options received in a Configure-Request are
not recognizable or are not acceptable for negotiation (as
configured by a network administrator), then a LCP implementation
should transmit a LCP packet with the Code field set to 4
(Configure-Reject), the Identifier field copied from the received
Configure-Request, and the Options field filled with only the
unacceptable Configuration Options from the Configure-Request.
All recognizable and negotiable Configuration Options are filtered
out of the Configure-Reject, but otherwise the Configuration
Options MUST NOT be reordered or modified in any way.
Configure-要求に受け取られたいくつかのConfiguration Optionsが認識可能でないか、または交渉において、許容できないなら(ネットワーク管理者によって構成されるように)、LCP実装はCode分野セットで4(廃棄物を構成している)にLCPパケットを伝えるべきです、そして、Identifier分野は受信されたConfigure-要求からコピーされました、そして、Options分野はConfigure-要求から容認できないConfiguration Optionsだけで満ちました。 すべての認識可能で交渉可能なConfiguration OptionsがConfigure-廃棄物からフィルターにかけられますが、さもなければ、何らかの方法でConfiguration Optionsを再命令されてはいけないか、変更してはいけません。
On reception of a Configure-Reject, the Identifier field must
match that of the last transmitted Configure-Request.
Additionally, the Configuration Options in a Configure-Reject must
be a proper subset of those in the last transmitted Configure-
Request. Invalid packets are silently discarded.
Configure-廃棄物のレセプションと、Identifier分野は最後に伝えられたConfigure-要求のものを合わせなければなりません。 さらに、Configure-廃棄物のConfiguration Optionsは最後に伝えられたConfigure要求におけるそれらの真部分集合であるに違いありません。 無効のパケットは静かに捨てられます。
Simpson [Page 33] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[33ページ]RFC1331 1992年5月
Reception of a valid Configure-Reject indicates that a new
Configure-Request SHOULD be sent which does not include any of the
Configuration Options listed in the Configure-Reject.
有効なConfigure-廃棄物のレセプションは、新しいConfigure-要求SHOULDが送られるのを示します(Configure-廃棄物に記載されたConfiguration Optionsのいずれも含んでいません)。
A summary of the Configure-Reject packet format is shown below. The fields are transmitted from left to right.
Configure-廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
4 for Configure-Reject.
4、廃棄物を構成します。
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Configure-Request which caused this Configure-Reject.
Identifier分野はこのConfigure-廃棄物を引き起こしたConfigure-要求のIdentifier分野のコピーです。
Options
オプション
The Options field is variable in length and contains the list of
zero or more Configuration Options that the sender is rejecting.
All Configuration Options are always rejected simultaneously.
Options分野は、長さで可変であり、ゼロのリストか送付者が拒絶しているより多くのConfiguration Optionsを含んでいます。 すべてのConfiguration Optionsが同時に、いつも拒絶されます。
Simpson [Page 34] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[34ページ]RFC1331 1992年5月
6.5. Terminate-Request and Terminate-Ack
6.5. 要求を終えてAckを終えます。
Description
記述
LCP includes Terminate-Request and Terminate-Ack Codes in order to
provide a mechanism for closing a connection.
LCPは、接続を終えるのにメカニズムを提供するためにTerminate-要求とTerminate-Ack Codesを含んでいます。
A LCP implementation wishing to close a connection should transmit
a LCP packet with the Code field set to 5 (Terminate-Request) and
the Data field filled with any desired data. Terminate-Request
packets should continue to be sent until Terminate-Ack is
received, the lower layer indicates that it has gone down, or a
sufficiently large number have been transmitted such that the peer
is down with reasonable certainty.
接続を終えるのがCode分野セットでLCPパケットを5に伝えるべきであることを(要求を終えている)願って、DataがさばくLCP実装はどんな必要なデータでも満ちました。 Requestを終えているパケットは、Terminate-Ackが受け取られているまで送られ続けるはずであり、下層は、落ちたか、または十分大きい数が伝えられたので同輩が妥当な確実性と共にいるのを示します。
Upon reception of a Terminate-Request, a LCP packet MUST be
transmitted with the Code field set to 6 (Terminate-Ack), the
Identifier field copied from the Terminate-Request packet, and the
Data field filled with any desired data.
Terminate-要求のレセプションでは、Code分野セットで6(Ackを終えている)にLCPパケットを伝えなければなりませんでした、そして、Identifier分野はTerminate-リクエスト・パケットからコピーされました、そして、Data分野はどんな必要なデータでも満ちました。
Reception of an unelicited Terminate-Ack indicates that the peer
is in the Closed or Stopped states, or is otherwise in need of
re-negotiation.
unelicited Terminate-Ackのレセプションは、同輩がClosedかStopped州にいるか、またはそうでなければ、再交渉を必要としているのを示します。
A summary of the Terminate-Request and Terminate-Ack packet formats is shown below. The fields are transmitted from left to right.
Terminate-要求とTerminate-Ackパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
5 for Terminate-Request;
5、要求を終えます。
6 for Terminate-Ack.
6、Ackを終えます。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。
Simpson [Page 35] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[35ページ]RFC1331 1992年5月
Data
データ
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the peer's established
maximum Information field length minus four.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した最大の同輩の情報フィールド長まで4を引いたどんな長さのものであるかもしれません。
6.6. Code-Reject
6.6. コード廃棄物
Description
記述
Reception of a LCP packet with an unknown Code indicates that one
of the communicating LCP implementations is faulty or incomplete.
This error MUST be reported back to the sender of the unknown Code
by transmitting a LCP packet with the Code field set to 7 (Code-
Reject), and the inducing packet copied to the Rejected-
Information field.
未知のCodeとのLCPパケットのレセプションは、交信しているLCP実装の1つが不完全であるか、または不完全であることを示します。 Code分野セットで7(コード廃棄物)にLCPパケットを伝えることによって、未知のCodeの送付者にこの誤りの報告を持ちかえらなければなりませんでした、そして、誘発しているパケットはRejected情報フィールドにコピーされました。
Upon reception of a Code-Reject, the implementation SHOULD report
the error, since it is unlikely that the situation can be
rectified automatically.
Code-廃棄物のレセプションに関して、実装SHOULDは誤りを報告します、自動的に事態を収拾できるのがありそうもないので。
A summary of the Code-Reject packet format is shown below. The fields are transmitted from left to right.
Code-廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Packet ...
+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拒絶されたパケット… +-+-+-+-+-+-+-+-+
Code
コード
7 for Code-Reject.
7 コード廃棄物のために。
Identifier
識別子
The Identifier field is one octet and is for use by the
transmitter.
Identifier分野は、1つの八重奏であり、送信機による使用のためのものです。
Rejected-Information
拒絶された情報
The Rejected-Information field contains a copy of the LCP packet
which is being rejected. It begins with the Information field,
and does not include any PPP Data Link Layer headers nor the FCS.
Rejected-情報フィールドは拒絶されているLCPパケットのコピーを含んでいます。 それは、情報分野で始まって、どんなPPP Data Link Layerヘッダーも含んでいません。または、FCS。
Simpson [Page 36] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[36ページ]RFC1331 1992年5月
The Rejected-Information MUST be truncated to comply with the
peer's established maximum Information field length.
同輩の確立した最大の情報フィールド長に従うためにRejected-情報に先端を切らせなければなりません。
Simpson [Page 37] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[37ページ]RFC1331 1992年5月
6.7. Protocol-Reject
6.7. プロトコル廃棄物
Description
記述
Reception of a PPP frame with an unknown Data Link Layer Protocol
indicates that the peer is attempting to use a protocol which is
unsupported. This usually occurs when the peer attempts to
configure a new protocol. If the LCP state machine is in the
Opened state, then this error MUST be reported back to the peer by
transmitting a LCP packet with the Code field set to 8 (Protocol-
Reject), the Rejected-Protocol field set to the received Protocol,
and the inducing packet copied to the Rejected-Information field.
未知のData Link LayerプロトコルがあるPPPフレームのレセプションは、同輩が、サポートされないプロトコルを使用するのを試みているのを示します。 同輩が、新しいプロトコルを構成するのを試みるとき、通常、これは起こります。 LCP州のマシンがOpened状態にあるなら、この誤りは同輩へのCode分野セットで8(プロトコル廃棄物)にLCPパケットを伝えるのによる報告された後部、容認されたプロトコルに設定されたRejected-プロトコル分野、および誘発がRejected-情報フィールドにコピーされたパケットであったならそうしなければなりません。
Upon reception of a Protocol-Reject, a LCP implementation SHOULD
stop transmitting frames of the indicated protocol.
プロトコル廃棄物、示されたプロトコルのフレームを伝えるLCP実装SHOULD停止のレセプションで。
Protocol-Reject packets may only be sent in the LCP Opened state.
Protocol-Reject packets received in any state other than the LCP
Opened state SHOULD be silently discarded.
LCP Opened状態でプロトコル廃棄物パケットを送るだけであるかもしれません。 LCP Opened州のSHOULDを除いて、いずれにも受け取られたプロトコル廃棄物パケットは、静かに捨てられるように述べます。
A summary of the Protocol-Reject packet format is shown below. The fields are transmitted from left to right.
プロトコル廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Protocol | Rejected-Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拒絶されたプロトコル| 拒絶された情報… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
8 for Protocol-Reject.
8 プロトコル廃棄物のために。
Identifier
識別子
The Identifier field is one octet and is for use by the
transmitter.
Identifier分野は、1つの八重奏であり、送信機による使用のためのものです。
Rejected-Protocol
拒絶されたプロトコル
The Rejected-Protocol field is two octets and contains the
Protocol of the Data Link Layer frame which is being rejected.
Rejected-プロトコル分野は、2つの八重奏であり、拒絶されているData Link Layerフレームのプロトコルを含んでいます。
Rejected-Information
拒絶された情報
The Rejected-Information field contains a copy from the frame
Rejected-情報フィールドはフレームからのコピーを含んでいます。
Simpson [Page 38] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[38ページ]RFC1331 1992年5月
which is being rejected. It begins with the Information field,
and does not include any PPP Data Link Layer headers nor the FCS.
The Rejected-Information MUST be truncated to comply with the
peer's established maximum Information field length.
拒絶されています。 それは、情報分野で始まって、どんなPPP Data Link Layerヘッダーも含んでいません。または、FCS。 同輩の確立した最大の情報フィールド長に従うためにRejected-情報に先端を切らせなければなりません。
6.8. Echo-Request and Echo-Reply
6.8. エコー要求とエコー・リプライ
Description
記述
LCP includes Echo-Request and Echo-Reply Codes in order to provide
a Data Link Layer loopback mechanism for use in exercising both
directions of the link. This is useful as an aid in debugging,
link quality determination, performance testing, and for numerous
other functions.
LCPは、リンクの両方の方向を運動させることにおける使用にData Link Layerループバックメカニズムを提供するためにEcho-要求とEcho-回答Codesを含んでいます。 これはデバッグにおける援助、リンク品質決定、機能をテストして他の多数の機能のための性能として役に立ちます。
An Echo-Request sender transmits a LCP packet with the Code field
set to 9 (Echo-Request), the Identifier field set, the local
Magic-Number inserted, and the Data field filled with any desired
data, up to but not exceeding the peer's established maximum
Information field length minus eight.
9(エコー要求)、地方のマジック数が指し込んだIdentifier分野セットに設定されたCode分野、およびData分野にどんな必要なデータでもいっぱいにされて、上がっているLCPパケットを伝えますが、Echo-要求送付者は同輩の確立した最大の情報フィールド長を超えていません8。
Upon reception of an Echo-Request, a LCP packet MUST be
transmitted with the Code field set to 10 (Echo-Reply), the
Identifier field copied from the received Echo-Request, the local
Magic-Number inserted, and the Data field copied from the Echo-
Request, truncating as necessary to avoid exceeding the peer's
established maximum Information field length.
Echo-要求のレセプションでは、10(エコー回答)に設定されたCode分野、受信されたEcho-要求からコピーされたIdentifier分野、挿入された地方のマジック数、およびEcho要求、必要に応じて先端を切るのからコピーされたData分野でLCPパケットを伝えて、同輩の確立した最大の情報フィールド長を超えているのを避けなければなりません。
Echo-Request and Echo-Reply packets may only be sent in the LCP
Opened state. Echo-Request and Echo-Reply packets received in any
state other than the LCP Opened state SHOULD be silently
discarded.
LCP Opened状態でエコー要求とEcho-回答パケットを送るだけであるかもしれません。 LCP Opened州のSHOULDを除いて、いずれにも受け取られたエコー要求とEcho-回答パケットは、静かに捨てられるように述べます。
A summary of the Echo-Request and Echo-Reply packet formats is shown below. The fields are transmitted from left to right.
Echo-要求とEcho-回答パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Simpson [Page 39] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[39ページ]RFC1331 1992年5月
Code
コード
9 for Echo-Request;
9 エコー要求のために。
10 for Echo-Reply.
10 エコー・リプライのために。
Identifier
識別子
The Identifier field is one octet and aids in matching Echo-
Requests and Echo-Replies.
Identifier分野は、合っているEcho要求とEcho-回答で1つの八重奏と援助です。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Unless modified by a
Configuration Option, the Magic-Number MUST be transmitted as zero
and MUST be ignored on reception. See the Magic-Number
Configuration Option for further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 Configuration Optionによって変更されない場合、マジック数をゼロとして伝えなければならなくて、レセプションで無視しなければなりません。 詳細な説明のマジック数のConfiguration Optionを見てください。
Data
データ
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the peer's established
maximum Information field length minus eight.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した最大の同輩の情報フィールド長まで8を引いたどんな長さのものであるかもしれません。
6.9. Discard-Request
6.9. 要求を捨てます。
Description
記述
LCP includes a Discard-Request Code in order to provide a Data
Link Layer data sink mechanism for use in exercising the local to
remote direction of the link. This is useful as an aid in
debugging, performance testing, and for numerous other functions.
LCPは、リンクのリモート方向への地方を運動させることにおける使用にData Link Layerデータ受信端末メカニズムを提供するためにDiscard-要求Codeを含んでいます。 これはデバッグにおける援助、機能をテストして他の多数の機能のための性能として役に立ちます。
A discard sender transmits a LCP packet with the Code field set to
11 (Discard-Request) the Identifier field set, the local Magic-
Number inserted, and the Data field filled with any desired data,
up to but not exceeding the peer's established maximum Information
field length minus eight.
しかし送付者が8を引いて同輩の確立した最大の情報フィールド長を超えないことでCode分野がIdentifier分野が設定した11(破棄して要求する)、挿入された地方のマジック数にセットして、どんな必要なデータでもいっぱいにされて、Data分野が上がっているLCPパケットを伝える破棄。
A discard receiver MUST simply throw away an Discard-Request that
it receives.
受信機が単にそうしなければならない破棄は受信するというDiscard-要求を無駄にします。
Discard-Request packets may only be sent in the LCP Opened state.
LCP Opened状態でRequestを捨てているパケットを送るだけであるかもしれません。
Simpson [Page 40] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[40ページ]RFC1331 1992年5月
A summary of the Discard-Request packet formats is shown below. The fields are transmitted from left to right.
Discard-リクエスト・パケット形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
11 for Discard-Request.
11、破棄して要求します。
Identifier
識別子
The Identifier field is one octet and is for use by the Discard-
Request transmitter.
Identifier分野は、1つの八重奏であり、Discard要求送信機による使用のためのものです。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Unless modified by a
configuration option, the Magic-Number MUST be transmitted as zero
and MUST be ignored on reception. See the Magic-Number
Configuration Option for further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 設定オプションで変更されない場合、マジック数をゼロとして伝えなければならなくて、レセプションで無視しなければなりません。 詳細な説明のマジック数のConfiguration Optionを見てください。
Data
データ
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the peer's established
maximum Information field length minus four.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した最大の同輩の情報フィールド長まで4を引いたどんな長さのものであるかもしれません。
Simpson [Page 41] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[41ページ]RFC1331 1992年5月
7. LCP Configuration Options
7. LCP設定オプション
LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated. Negotiable modifications include such things as the maximum receive unit, async control character mapping, the link authentication method, etc. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
LCP Configuration Optionsは、ポイントツーポイント接続の標準の特性への変更が交渉されるのを許容します。 交渉可能な変更は最大がユニット、async制御文字マッピング、リンク認証方法を受けるようなものなどを含んでいます。 Configuration OptionがConfigure-リクエスト・パケットに含まれていないなら、そのConfiguration Optionのためのデフォルト値は想定されます。
The end of the list of Configuration Options is indicated by the length of the LCP packet.
Configuration Optionsのリストの終わりはLCPパケットの長さによって示されます。
Unless otherwise specified, each Configuration Option is not listed more than once in a Configuration Options list. Some Configuration Options MAY be listed more than once. The effect of this is Configuration Option specific and is specified by each such Configuration Option.
別の方法で指定されない場合、各Configuration OptionはConfiguration Optionsリストの一度よりもう少し記載されません。 いくつかのConfiguration Optionsが一度よりもう少し記載されているかもしれません。 この効果は、Configuration Option特有であり、そのような各Configuration Optionによって指定されます。
Also unless otherwise specified, all Configuration Options apply in a half-duplex fashion. When negotiated, they apply to only one direction of the link, typically in the receive direction when interpreted from the point of view of the Configure-Request sender.
また、別の方法で指定されない場合、すべてのConfiguration Optionsが半二重ファッションで適用します。 交渉されています、彼らがいつリンクの一方向だけに通常適用するか、Configure-要求送付者の観点から解釈されたら、方向を受けてください。
Simpson [Page 42] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[42ページ]RFC1331 1992年5月
7.1. Format
7.1. 形式
A summary of the Configuration Option format is shown below. The fields are transmitted from left to right.
Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
The Type field is one octet and indicates the type of
Configuration Option. The most up-to-date values of the LCP
Option Type field are specified in the most recent "Assigned
Numbers" RFC [11]. Current values are assigned as follows:
Type分野は、1つの八重奏であり、Configuration Optionのタイプを示します。 LCP Option Type分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。 現行価値は以下の通り割り当てられます:
1 Maximum-Receive-Unit
2 Async-Control-Character-Map
3 Authentication-Protocol
4 Quality-Protocol
5 Magic-Number
6 RESERVED
7 Protocol-Field-Compression
8 Address-and-Control-Field-Compression
1 アドレスとコントロールが圧縮をさばいた状態で、最大がユニットを受けている2Async規制キャラクター地図3認証プロトコル4上質のプロトコル5マジックナンバー6は7プロトコル分野圧縮8を予約しました。
Length
長さ
The Length field is one octet and indicates the length of this
Configuration Option including the Type, Length and Data fields.
If a negotiable Configuration Option is received in a Configure-
Request but with an invalid Length, a Configure-Nak SHOULD be
transmitted which includes the desired Configuration Option with
an appropriate Length and Data.
Length分野は、1つの八重奏であり、Type、Length、およびData分野を含むこのConfiguration Optionの長さを示します。 しかし、交渉可能なConfiguration Optionに受け取るなら、Configureは、病人と共にLength、Configure-Nak SHOULDが伝えられるよう要求します(適切なLengthとDataと必要なConfiguration Optionを含んでいます)。
Data
データ
The Data field is zero or more octets and indicates the value or
other information for this Configuration Option. The format and
length of the Data field is determined by the Type and Length
fields.
Data分野は、ゼロか、より多くの八重奏であり、このConfiguration Optionのための値か他の情報を示します。 Data分野の形式と長さはTypeとLength分野のそばで決定しています。
Simpson [Page 43] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[43ページ]RFC1331 1992年5月
7.2. Maximum-Receive-Unit
7.2. 最大はユニットを受けます。
Description
記述
This Configuration Option may be sent to inform the peer that the
implementation can receive larger frames, or to request that the
peer send smaller frames. If smaller frames are requested, an
implementation MUST still be able to receive 1500 octet frames in
case link synchronization is lost.
実装が、より大きいフレームを受けることができることを同輩に知らせるか、または同輩が、より小さいフレームを送るよう要求するためにこのConfiguration Optionを送るかもしれません。 より小さいフレームが要求されるなら、リンク同期が無くなるといけないので、実装はまだ1500個の八重奏フレームを受け取ることができなければなりません。
A summary of the Maximum-Receive-Unit Configuration Option format is shown below. The fields are transmitted from left to right.
Maximumがユニットを受けている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 | Maximum-Receive-Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 最大はユニットを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
4
4
Maximum-Receive-Unit
最大はユニットを受けます。
The Maximum-Receive-Unit field is two octets and indicates the new
maximum receive unit. The Maximum-Receive-Unit covers only the
Data Link Layer Information field. It does not include the
header, padding, FCS, nor any transparency bits or bytes.
Maximumがユニットを受けている分野は、2つの八重奏であり、新しい最大がユニットを受けるのを示します。 Maximumがユニットを受けるのがData Link Layer情報分野だけをカバーしています。 それはどんなヘッダーや、詰め物や、FCSと、透明ビットやバイトも含んでいません。
Default
デフォルト
1500
1500
Simpson [Page 44] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[44ページ]RFC1331 1992年5月
7.3. Async-Control-Character-Map
7.3. Async規制キャラクター地図
Description
記述
This Configuration Option provides a way to negotiate the use of
control character mapping on asynchronous links. By default, PPP
maps all control characters into an appropriate two character
sequence. However, it is rarely necessary to map all control
characters and often it is unnecessary to map any characters. A
PPP implementation may use this Configuration Option to inform the
peer which control characters must remain mapped and which control
characters need not remain mapped when the peer sends them. The
peer may still send these control characters in mapped format if
it is necessary because of constraints at the peer.
このConfiguration Optionは非同期なリンクにおける制御文字マッピングの使用を交渉する方法を提供します。 デフォルトで、PPPは適切な2キャラクタシーケンスにすべての制御文字を写像します。 しかしながら、すべての制御文字としばしばそれを写像するのがどんなキャラクタも写像するために不要であることはめったに必要ではありません。 PPP実装は、どの制御文字が写像されたままで残らなければならないか、そして、どの制御文字は同輩がそれらを送るとき、写像されたままで残る必要はないかを同輩に知らせるのにこのConfiguration Optionを使用するかもしれません。 それが規制のために同輩で必要であるなら、同輩は写像している形式でまだこれらの制御文字を送るかもしれません。
There may be some use of synchronous-to-asynchronous converters
(some built into modems) in Point-to-Point links resulting in a
synchronous PPP implementation on one end of a link and an
asynchronous implementation on the other. It is the
responsibility of the converter to do all mapping conversions
during operation. To enable this functionality, synchronous PPP
implementations MUST always accept a Async-Control-Character-Map
Configuration Option (it MUST always respond to an LCP Configure-
Request specifying this Configuration Option with an LCP
Configure-Ack). However, acceptance of this Configuration Option
does not imply that the synchronous implementation will do any
character mapping, since synchronous PPP uses bit-stuffing rather
than character-stuffing. Instead, all such character mapping will
be performed by the asynchronous-to-synchronous converter.
Pointからポイントへのリンクでの非同期であるのと同期のコンバータ(モデムが組み込まれたいくつか)のもう片方でリンクと非同期な実装の片端で同期PPP実装をもたらす何らかの使用があるかもしれません。 操作の間、すべてのマッピング変換をするのは、コンバータの責任です。 この機能性を可能にするために、同期PPP実装はいつもAsync規制キャラクター地図Configuration Optionを受け入れなければなりません(それはいつもLCP Configure-Ackと共にこのConfiguration Optionを指定するLCP Configure要求に応じなければなりません)。 しかしながら、このConfiguration Optionの承認は、同期実装がどんなキャラクタマッピングもするのを含意しません、同期PPPがキャラクタ詰め物よりむしろビット・スタッフィングを使用するので。 代わりに、そのようなすべてのキャラクタマッピングが同期変流機への非同期によって実行されるでしょう。
A summary of the Async-Control-Character-Map Configuration Option format is shown below. The fields are transmitted from left to right.
Async規制キャラクター地図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 | Async-Control-Character-Map
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACCM (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| Async規制キャラクター地図+++++++++++++++++++++++++++++++++ACCM(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2
2
Simpson [Page 45] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[45ページ]RFC1331 1992年5月
Length
長さ
6
6
Async-Control-Character-Map
Async規制キャラクター地図
The Async-Control-Character-Map field is four octets and indicates
the new async control character map. The map is encoded in big-
endian fashion where each numbered bit corresponds to the ASCII
control character of the same value. If the bit is cleared to
zero, then that ASCII control character need not be mapped. If
the bit is set to one, then that ASCII control character must
remain mapped. E.g., if bit 19 is set to zero, then the ASCII
control character 19 (DC3, Control-S) may be sent in the clear.
Async規制キャラクター地図分野は、4つの八重奏であり、新しいasync制御文字地図を示します。 地図はそれぞれの番号付のビットが同じ価値のASCII制御文字に対応する大きいエンディアンファッションでコード化されます。 ビットがゼロまできれいにされるなら、そのASCII制御文字は写像される必要はありません。 ビットが1つに設定されるなら、そのASCII制御文字は写像されたままで残らなければなりません。 例えば、ビット19をゼロに設定するなら、明確でASCII制御文字19(DC3、Control-S)を送るかもしれません。
Note: The bit ordering of the map is as described in section
3.1, Most Significant Bit to Least Significant Bit. The least
significant bit of the least significant octet (the final octet
transmitted) is numbered bit 0, and would map to the ASCII
control character NUL.
以下に注意してください。 地図を注文するビットがセクション3.1、Least Significant BitへのMost Significant Bitで説明されるようにあります。 最も重要でない八重奏(最終的な八重奏は伝わった)の最下位ビットは、番号付のビット0であり、NULをASCII制御文字に写像するでしょう。
Default
デフォルト
All ones (0xffffffff).
すべてのもの(0xffffffff)。
Simpson [Page 46] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[46ページ]RFC1331 1992年5月
7.4. Authentication-Protocol
7.4. 認証プロトコル
Description
記述
On some links it may be desirable to require a peer to
authenticate itself before allowing network-layer protocol packets
to be exchanged. This Configuration Option provides a way to
negotiate the use of a specific authentication protocol. By
default, authentication is not necessary.
いくつかのリンクでは、同輩がネットワーク層プロトコルパケットが交換されるのを許容する前にそれ自体を認証するのが必要であるのは望ましいかもしれません。 このConfiguration Optionは特定の認証プロトコルの使用を交渉する方法を提供します。 デフォルトで、認証は必要ではありません。
An implementation SHOULD NOT include multiple Authentication-
Protocol Configuration Options in its Configure-Request packets.
Instead, it SHOULD attempt to configure the most desirable
protocol first. If that protocol is Rejected, then the
implementation could attempt the next most desirable protocol in
the next Configure-Request.
実装SHOULD NOTはConfigure-リクエスト・パケットに複数のAuthenticationプロトコルConfiguration Optionsを含んでいます。 代わりにそれ、SHOULDは、最初に最も望ましいプロトコルを構成するのを試みます。 そのプロトコルがRejectedであるなら、実装は次の次のConfigure-要求で最も望ましいプロトコルを試みるかもしれません。
An implementation receiving a Configure-Request specifying
Authentication-Protocols MAY choose at most one of the negotiable
authentication protocols and MUST send a Configure-Reject
including the other specified authentication protocols. The
implementation MAY reject all of the proposed authentication
protocols.
Authentication-プロトコルを指定しながらConfigure-要求を受け取る実装は、交渉可能な認証プロトコルの1つを高々選ぶかもしれなくて、他の指定された認証プロトコルを含むConfigure-廃棄物を送らなければなりません。 実装は提案された認証プロトコルのすべてを拒絶するかもしれません。
If an implementation sends a Configure-Ack with this Configuration
Option, then it is agreeing to authenticate with the specified
protocol. An implementation receiving a Configure-Ack with this
Configuration Option SHOULD expect the peer to authenticate with
the acknowledged protocol.
実装がこのConfiguration OptionとConfigure-Ackを送るなら、それが指定されたプロトコルで認証するのに同意しているその時です。 承認されたプロトコルで認証するこのConfiguration Option SHOULDと共にConfigure-Ackを受けると同輩が予想される実装。
There is no requirement that authentication be full duplex or that
the same protocol be used in both directions. It is perfectly
acceptable for different protocols to be used in each direction.
This will, of course, depend on the specific protocols negotiated.
認証が全二重であるか同じプロトコルが両方の方向に使用されるという要件が全くありません。 異なったプロトコルが各方向に使用されるのは、完全に許容できます。 これはもちろん交渉された特定のプロトコルによるでしょう。
A summary of the Authentication-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.
Authentication-プロトコル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 | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Simpson [Page 47] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[47ページ]RFC1331 1992年5月
Type
タイプ
3
3
Length
長さ
>= 4
>= 4
Authentication-Protocol
認証プロトコル
The Authentication-Protocol field is two octets and indicates the
authentication protocol desired. Values for this field are always
the same as the PPP Data Link Layer Protocol field values for that
same authentication protocol.
Authentication-プロトコル分野は、2つの八重奏であり、認証プロトコルが望んでいたのを示します。 この分野への値はその同じ認証のためのPPP Data Link Layerプロトコル分野値が議定書を作るのといつも同じです。
The most up-to-date values of the Authentication-Protocol field
are specified in the most recent "Assigned Numbers" RFC [11].
Current values are assigned as follows:
Authentication-プロトコル分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。 現行価値は以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
c023 Password Authentication Protocol
c223 Challenge Handshake Authentication
Protocol
c023パスワード認証プロトコルc223チャレンジハンドシェイク式認証プロトコル
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the particular protocol.
Data分野は、ゼロか、より多くの八重奏であり、特定のプロトコルで決定するように追加データを含んでいます。
Default
デフォルト
No authentication protocol necessary.
いいえ認証プロトコル必要です。
Simpson [Page 48] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[48ページ]RFC1331 1992年5月
7.5. Quality-Protocol
7.5. 上質のプロトコル
Description
記述
On some links it may be desirable to determine when, and how
often, the link is dropping data. This process is called link
quality monitoring.
いくつかのリンクでは、しばしば、リンクがいつ、どのようにデータを下げているかを決定するのは望ましいかもしれません。 このプロセスは、モニターしながら、上質でリンクと呼ばれます。
This Configuration Option provides a way to negotiate the use of a
specific protocol for link quality monitoring. By default, link
quality monitoring is disabled.
このConfiguration Optionはモニターしながら上質で特定のプロトコルのリンクの使用を交渉する方法を提供します。 デフォルトで、リンク品質モニターは障害があります。
There is no requirement that quality monitoring be full duplex or
that the same protocol be used in both directions. It is
perfectly acceptable for different protocols to be used in each
direction. This will, of course, depend on the specific protocols
negotiated.
上質のモニターが全二重であるか同じプロトコルが両方の方向に使用されるという要件が全くありません。 異なったプロトコルが各方向に使用されるのは、完全に許容できます。 これはもちろん交渉された特定のプロトコルによるでしょう。
A summary of the Quality-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.
Quality-プロトコル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 | Quality-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 上質のプロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
4
4
Length
長さ
>= 4
>= 4
Quality-Protocol
上質のプロトコル
The Quality-Protocol field is two octets and indicates the link
quality monitoring protocol desired. Values for this field are
always the same as the PPP Data Link Layer Protocol field values
for that same monitoring protocol.
Quality-プロトコル分野は、2つの八重奏であり、上質のモニターしているプロトコルが望んでいたリンクを示します。 この分野への値はPPP Data Link Layerプロトコル分野がその同じモニターしているプロトコルのために評価するのといつも同じです。
The most up-to-date values of the Quality-Protocol field are
specified in the most recent "Assigned Numbers" RFC [11]. Current
values are assigned as follows:
Quality-プロトコル分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。 現行価値は以下の通り割り当てられます:
Simpson [Page 49] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[49ページ]RFC1331 1992年5月
Value (in hex) Protocol
値(十六進法における)のプロトコル
c025 Link Quality Report
c025リンクQuality Report
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the particular protocol.
Data分野は、ゼロか、より多くの八重奏であり、特定のプロトコルで決定するように追加データを含んでいます。
Default
デフォルト
None
なし
Simpson [Page 50] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[50ページ]RFC1331 1992年5月
7.6. Magic-Number
7.6. マジックナンバー
Description
記述
This Configuration Option provides a way to detect looped-back
links and other Data Link Layer anomalies. This Configuration
Option MAY be required by some other Configuration Options such as
the Monitoring-Protocol Configuration Option.
このConfiguration Optionは輪にされて逆リンクと他のData Link Layer例外を検出する方法を提供します。 このConfiguration OptionはMonitoring-プロトコルConfiguration Optionなどのある他のConfiguration Optionsによって必要とされるかもしれません。
Before this Configuration Option is requested, an implementation
must choose its Magic-Number. It is recommended that the Magic-
Number be chosen in the most random manner possible in order to
guarantee with very high probability that an implementation will
arrive at a unique number. A good way to choose a unique random
number is to start with an unique seed. Suggested sources of
uniqueness include machine serial numbers, other network hardware
addresses, time-of-day clocks, etc. Particularly good random
number seeds are precise measurements of the inter-arrival time of
physical events such as packet reception on other connected
networks, server response time, or the typing rate of a human
user. It is also suggested that as many sources as possible be
used simultaneously.
このConfiguration Optionが要求されている前に、実装はマジック番号を選ばなければなりません。 マジック数が実装がそうするという非常に高い確率でユニークな数に達するように保証するために可能な最も無作為の方法で選ばれているのは、お勧めです。 ユニークな乱数を選ぶ早道はユニークな種子から始めることです。 ユニークさの提案された源はマシン通し番号、他のネットワークハードウェアアドレス、時刻時計などを含んでいます。 特に良い乱数種子は物理的なイベントの相互到着時間の人間のユーザの他の接続ネットワーク、サーバ応答時間、またはタイプレートにおけるパケットレセプションなどの正確な寸法です。 また、できるだけ多くのソースが同時に使用されることが提案されます。
When a Configure-Request is received with a Magic-Number
Configuration Option, the received Magic-Number is compared with
the Magic-Number of the last Configure-Request sent to the peer.
If the two Magic-Numbers are different, then the link is not
looped-back, and the Magic-Number should be acknowledged. If the
two Magic-Numbers are equal, then it is possible, but not certain,
that the link is looped-back and that this Configure-Request is
actually the one last sent. To determine this, a Configure-Nak
should be sent specifying a different Magic-Number value. A new
Configure-Request should not be sent to the peer until normal
processing would cause it to be sent (i.e., until a Configure-Nak
is received or the Restart timer runs out).
マジック数のConfiguration Optionと共にConfigure-要求を受け取るとき、同輩に送る最後のConfigure-要求のマジック数に容認されたマジック数をたとえます。 2つのマジック番号が異なるなら、リンクは-逆で輪にされません、そして、マジック数は承認されるべきです。 2つのマジック番号が等しいなら、可能ですが、確かでない、リンクが-逆で輪にされて、このConfigure-要求が最後に実際にものであることは発信しました。 これを決定するために、Configure-Nakに異なったマジック数の値を指定させるべきです。 正常処理でそれを送るだろうまで(すなわち、Configure-Nakが受け取られているか、またはRestartタイマがなくなるまで)新しいConfigure-要求を同輩に送るべきではありません。
Reception of a Configure-Nak with a Magic-Number different from
that of the last Configure-Nak sent to the peer proves that a link
is not looped-back, and indicates a unique Magic-Number. If the
Magic-Number is equal to the one sent in the last Configure-Nak,
the possibility of a looped-back link is increased, and a new
Magic-Number should be chosen. In either case, a new Configure-
Request should be sent with the new Magic-Number.
同輩に送られた最後のConfigure-Nakのものと異なったマジック数があるConfigure-Nakのレセプションは、リンクが-逆で輪にされないと立証して、ユニークなマジック数を示します。 マジック数が最後のConfigure-Nakで送られたものと等しいなら、輪にされて逆リンクの可能性は増加されています、そして、新しいマジック数は選ばれるべきです。 どちらの場合ではも、新しいマジック数と共に新しいConfigure要求を送るべきです。
If the link is indeed looped-back, this sequence (transmit
Configure-Request, receive Configure-Request, transmit Configure-
Nak, receive Configure-Nak) will repeat over and over again. If
the link is not looped-back, this sequence might occur a few
リンクが本当に-逆で輪にされると、この系列(Configure-要求を送信してください、そして、Configure-要求を受け取ってください、そして、Configure- Nakを送信してください、そして、Configure-Nakを受ける)は再三再び繰り返すでしょう。 リンクが-逆で輪にされないなら、この系列が起こるかもしれない、いくつか
Simpson [Page 51] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[51ページ]RFC1331 1992年5月
times, but it is extremely unlikely to occur repeatedly. More
likely, the Magic-Numbers chosen at either end will quickly
diverge, terminating the sequence. The following table shows the
probability of collisions assuming that both ends of the link
select Magic-Numbers with a perfectly uniform distribution:
しかし、回、それは繰り返して非常に起こりそうにはありません。 おそらく、系列を終えると、どちらの終わりにも選ばれたマジック数は急速に分岐するでしょう。 以下のテーブルは衝突が、リンクの両端が完全に一定の分配があるマジック数を選択すると仮定するという確率を示しています:
Number of Collisions Probability
-------------------- ---------------------
1 1/2**32 = 2.3 E-10
2 1/2**32**2 = 5.4 E-20
3 1/2**32**3 = 1.3 E-29
衝突確率の数-------------------- --------------------- 1 1/2**32 = 2.3E-10 2 1/2**32**2 = 5.4E-20 3 1/2**32**3 = 1.3E-29
Good sources of uniqueness or randomness are required for this
divergence to occur. If a good source of uniqueness cannot be
found, it is recommended that this Configuration Option not be
enabled; Configure-Requests with the option SHOULD NOT be
transmitted and any Magic-Number Configuration Options which the
peer sends SHOULD be either acknowledged or rejected. In this
case, loop-backs cannot be reliably detected by the
implementation, although they may still be detectable by the peer.
ユニークさか偶発性の良い源が、この分岐が起こるのに必要です。 ユニークさの良い源を見つけることができないなら、このConfiguration Optionが有効にされないのは、お勧めです。 伝えられるオプションSHOULD NOTと承認されるか、または拒絶される同輩が送るどんなマジック数のConfiguration Options SHOULDも要求を構成します。 この場合、それらは同輩がまだ検出可能であるかもしれませんが、実現でループバックを確かに検出できません。
If an implementation does transmit a Configure-Request with a
Magic-Number Configuration Option, then it MUST NOT respond with a
Configure-Reject if its peer also transmits a Configure-Request
with a Magic-Number Configuration Option. That is, if an
implementation desires to use Magic Numbers, then it MUST also
allow its peer to do so. If an implementation does receive a
Configure-Reject in response to a Configure-Request, it can only
mean that the link is not looped-back, and that its peer will not
be using Magic-Numbers. In this case, an implementation should
act as if the negotiation had been successful (as if it had
instead received a Configure-Ack).
実現がマジック数のConfiguration OptionとのConfigure-要求を伝えるなら、また、同輩がマジック数のConfiguration OptionとのConfigure-要求を伝えるなら、それはConfigure-廃棄物で応じてはいけません。 また、すなわち、実現が、マジック民数記を使用することを望んでいるなら、それで、同輩はそうすることができなければなりません。 実現がConfigure-要求に対応してConfigure-廃棄物を受けるなら、それは、リンクが-逆で輪にされないで、また同輩がマジック数を使用しないことを意味できるだけです。 この場合、まるで交渉がうまくいったかのように(まるで代わりにConfigure-Ackを受けたかのように)実現は行動するべきです。
The Magic-Number also may be used to detect looped-back links
during normal operation as well as during Configuration Option
negotiation. All LCP Echo-Request, Echo-Reply, and Discard-
Request packets have a Magic-Number field which MUST normally be
zero, and MUST normally be ignored on reception. If Magic-Number
has been successfully negotiated, an implementation MUST transmit
these packets with the Magic-Number field set to its negotiated
Magic-Number.
マジック数も、通常の操作とConfiguration Option交渉の間、輪にされて逆リンクを検出するのに使用されるかもしれません。 すべてのLCP Echo-要求、Echo-回答、およびDiscardリクエスト・パケットには、通常ゼロでなければならなく、通常、レセプションで無視しなければならないマジックナンバーフィールドがあります。 マジック数が首尾よく交渉されたなら、実現はマジックナンバーフィールドセットで交渉されたマジック番号にこれらのパケットを伝えなければなりません。
The Magic-Number field of these packets SHOULD be inspected on
reception. All received Magic-Number fields MUST be equal to
either zero or the peer's unique Magic-Number, depending on
whether or not the peer negotiated one.
これらのマジックナンバーフィールドパケットSHOULD、レセプションで点検されてください。 すべての容認されたマジックナンバーフィールドがゼロか同輩のユニークなマジック番号のどちらかと等しいに違いありません、同輩が1つを交渉したかどうかによって。
Reception of a Magic-Number field equal to the negotiated local
交渉への地元のマジックナンバーフィールド同輩のレセプション
Simpson [Page 52] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[52ページ]RFC1331 1992年5月
Magic-Number indicates a looped-back link. Reception of a Magic-
Number other than the negotiated local Magic-Number or the peer's
negotiated Magic-Number, or zero if the peer didn't negotiate one,
indicates a link which has been (mis)configured for communications
with a different peer.
魔法番号は輪にされて逆リンクを示します。 同輩が1つを交渉しないで、そうするリンクを示すなら交渉された地方のマジック数か同輩以外のaマジック番号のレセプションがマジック数、またはゼロを交渉した、(誤、)、異なった同輩とのコミュニケーションのために、構成されています。
Procedures for recovery from either case are unspecified and may
vary from implementation to implementation. A somewhat
pessimistic procedure is to assume a LCP Down event. A further
Open event will begin the process of re-establishing the link,
which can't complete until the loop-back condition is terminated
and Magic-Numbers are successfully negotiated. A more optimistic
procedure (in the case of a loop-back) is to begin transmitting
LCP Echo-Request packets until an appropriate Echo-Reply is
received, indicating a termination of the loop-back condition.
どちらかのケースからの回復のための手順は、不特定であり、実現によって異なるかもしれません。 いくらか悲観的な手順はLCP Down出来事を仮定することです。 一層のオープン出来事はリンクを復職させるプロセスを開始するでしょう、そして、どれがループバックまで状態を完成できないかは、終えられます、そして、マジック数は首尾よく交渉されます。 より楽観的な手順(ループバックの場合における)は適切なEcho-回答が受け取られているまでLCP Echo-リクエスト・パケットを伝え始めることです、ループバック状態の終了を示して。
A summary of the Magic-Number Configuration Option format is shown below. The fields are transmitted from left to right.
マジック数の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 | Magic-Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-Number (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| マジックナンバー+++++++++++++++++++++++++++++++++マジックナンバー(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5
5
Length
長さ
6
6
Magic-Number
マジックナンバー
The Magic-Number field is four octets and indicates a number which
is very likely to be unique to one end of the link. A Magic-
Number of zero is illegal and MUST always be Nak'd, if it is not
Rejected outright.
マジックナンバーフィールドは、4つの八重奏であり、非常にありそうな数がリンクの片端に特有であることを示します。 マジック数のゼロは、不法であり、いつもあるに違いありません。それが完全にRejectedでなくNakはそうするでしょう。
Default
デフォルト
None.
なし。
Simpson [Page 53] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[53ページ]RFC1331 1992年5月
7.7. Protocol-Field-Compression
7.7. プロトコル分野圧縮
Description
記述
This Configuration Option provides a way to negotiate the
compression of the Data Link Layer Protocol field. By default,
all implementations MUST transmit standard PPP frames with two
octet Protocol fields. However, PPP Protocol field numbers are
chosen such that some values may be compressed into a single octet
form which is clearly distinguishable from the two octet form.
This Configuration Option is sent to inform the peer that the
implementation can receive such single octet Protocol fields.
Compressed Protocol fields MUST NOT be transmitted unless this
Configuration Option has been negotiated.
このConfiguration OptionはData Link Layerプロトコル分野の圧縮を交渉する方法を提供します。 デフォルトで、すべての実現が2つの八重奏プロトコル分野がある標準のPPPフレームを伝えなければなりません。 しかしながら、PPPプロトコル分野番号は、2八重奏フォームから明確に区別可能なただ一つの八重奏フォームにいくつかの値を圧縮できるように選ばれています。 実現がそのようなただ一つの八重奏プロトコル野原を受けることができることを同輩に知らせるためにこのConfiguration Optionを送ります。 このConfiguration Optionが交渉されていない場合、圧縮されたプロトコル野原を伝えてはいけません。
As previously mentioned, the Protocol field uses an extension
mechanism consistent with the ISO 3309 extension mechanism for the
Address field; the Least Significant Bit (LSB) of each octet is
used to indicate extension of the Protocol field. A binary "0" as
the LSB indicates that the Protocol field continues with the
following octet. The presence of a binary "1" as the LSB marks
the last octet of the Protocol field. Notice that any number of
"0" octets may be prepended to the field, and will still indicate
the same value (consider the two representations for 3, 00000011
and 00000000 00000011).
以前に言及されるように、プロトコル分野はAddress分野に3309年のISO拡大メカニズムと一致した拡大メカニズムを使用します。 それぞれの八重奏のLeast Significant Bit(LSB)は、プロトコル分野の拡大を示すのに使用されます。 バイナリー「LSBが、プロトコル分野が以下の八重奏を続行するのを示すような0インチ。」 「LSBとしての1インチはプロトコル分野の最後の八重奏であるとマークする」バイナリーの存在。 いずれも付番する「0インチの八重奏は、その分野にprependedされるかもしれなくて、それでも、同じ値を示3、00000011、および00000000 00000011の2つの表現を(考えてください)」通知。
In the interest of simplicity, the standard PPP frame uses this
fact and always sends Protocol fields with a two octet
representation. Protocol field values less than 256 (decimal) are
prepended with a single zero octet even though transmission of
this, the zero and most significant octet, is unnecessary.
簡単さのために、標準のPPPフレームは、この事実を使用して、プロトコル野原は2八重奏表現と共にいつも行きます。 このトランスミッション(ゼロと最も重要な八重奏)は、不要ですが、256(10進)がシングルでprependedされるより少ないプロトコル分野値は八重奏のゼロに合っています。
However, when using low speed links, it is desirable to conserve
bandwidth by sending as little redundant data as possible. The
Protocol Compression Configuration Option allows a trade-off
between implementation simplicity and bandwidth efficiency. If
successfully negotiated, the ISO 3309 extension mechanism may be
used to compress the Protocol field to one octet instead of two.
The large majority of frames are compressible since data protocols
are typically assigned with Protocol field values less than 256.
しかしながら、低速リンクを使用するとき、できるだけ少ししか冗長データを送らないことによって帯域幅を保存するのは望ましいです。 プロトコルCompression Configuration Optionは実現の簡単さと帯域幅効率の間のトレードオフを許容します。 首尾よく交渉されるなら、3309年のISO拡大メカニズムは、2の代わりに1つの八重奏にプロトコル分野を圧縮するのに使用されるかもしれません。 データプロトコルがプロトコル分野値256で通常割り当てられるので、フレームの大多数は圧縮性です。
In addition, PPP implementations must continue to be robust and
MUST accept PPP frames with either double-octet or single-octet
Protocol fields, and MUST NOT distinguish between them.
さらに、PPP実現は、ずっと強健でなければならなく、二重八重奏の、または、ただ一つの八重奏のプロトコル分野があるPPPフレームを受け入れなければならなくて、それらを見分けてはいけません。
The Protocol field is never compressed when sending any LCP
packet. This rule guarantees unambiguous recognition of LCP
packets.
どんなLCPパケットも送るとき、プロトコル分野は決して圧縮されません。 この規則はLCPパケットの明白な認識を保証します。
Simpson [Page 54] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[54ページ]RFC1331 1992年5月
When a Protocol field is compressed, the Data Link Layer FCS field
is calculated on the compressed frame, not the original
uncompressed frame.
プロトコル分野が圧縮されるとき、Data Link Layer FCS分野はオリジナルの解凍されたフレームではなく、圧縮されたフレームの上に計算されます。
A summary of the Protocol-Field-Compression Configuration Option format is shown below. The fields are transmitted from left to right.
プロトコル分野圧縮Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7
7
Length
長さ
2
2
Default
デフォルト
Disabled.
障害がある。
Simpson [Page 55] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[55ページ]RFC1331 1992年5月
7.8. Address-and-Control-Field-Compression
7.8. アドレスとコントロール分野圧縮
Description
記述
This Configuration Option provides a way to negotiate the
compression of the Data Link Layer Address and Control fields. By
default, all implementations MUST transmit frames with Address and
Control fields and MUST use the hexadecimal values 0xff and 0x03
respectively. Since these fields have constant values, they are
easily compressed. This Configuration Option is sent to inform
the peer that the implementation can receive compressed Address
and Control fields.
このConfiguration OptionはData Link Layer AddressとControl分野の圧縮を交渉する方法を提供します。 デフォルトで、すべての実現が、AddressがあるフレームとControl野原を伝えなければならなくて、それぞれ16進値0xffと0x03を使用しなければなりません。 これらの分野には恒常価値があるので、それらが容易に圧縮されます。 実現が圧縮されたAddressとControl野原を受けることができることを同輩に知らせるためにこのConfiguration Optionを送ります。
Compressed Address and Control fields are formed by simply
omitting them. By definition the first octet of a two octet
Protocol field will never be 0xff, and the Protocol field value
0x00ff is not allowed (reserved) to avoid ambiguity.
圧縮されたAddressとControl分野は、単にそれらを省略することによって、形成されます。 定義上、2八重奏プロトコル分野の最初の八重奏は0xffに決してならないでしょう、そして、プロトコル分野値の0x00ffはあいまいさを避けることができません(予約されます)。
On reception, the Address and Control fields are decompressed by
examining the first two octets. If they contain the values 0xff
and 0x03, they are assumed to be the Address and Control fields.
If not, it is assumed that the fields were compressed and were not
transmitted.
レセプションでは、AddressとControl分野は、最初の2つの八重奏を調べることによって、減圧されます。 値0xffと0x03を含んでいるなら、それらはAddressとControl分野であると思われます。 そうでなければ、野原が圧縮されて、伝えられなかったと思われます。
If a compressed frame is received when Address-and-Control-Field-
Compression has not been negotiated, the implementation MAY
silently discard the frame.
そして、Addressであるときに、圧縮されたフレームが受け取られている、-、-コントロール分野圧縮は交渉されていなくて、実現は静かにフレームを捨てるかもしれません。
The Address and Control fields MUST NOT be compressed when sending
any LCP packet. This rule guarantees unambiguous recognition of
LCP packets.
どんなLCPパケットも送るとき、AddressとControl分野を圧縮してはいけません。 この規則はLCPパケットの明白な認識を保証します。
When the Address and Control fields are compressed, the Data Link
Layer FCS field is calculated on the compressed frame, not the
original uncompressed frame.
AddressとControl分野が圧縮されるとき、Data Link Layer FCS分野はオリジナルの解凍されたフレームではなく、圧縮されたフレームの上に計算されます。
A summary of the Address-and-Control-Field-Compression configuration option format is shown below. The fields are transmitted from left to right.
Addressとコントロール分野圧縮設定オプション形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Simpson [Page 56] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[56ページ]RFC1331 1992年5月
Type
タイプ
8
8
Length
長さ
2
2
Default
デフォルト
Not compressed.
圧縮されません。
Simpson [Page 57] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[57ページ]RFC1331 1992年5月
A. Asynchronous HDLC
A。 非同期なHDLC
This appendix summarizes the modifications to ISO 3309-1979 proposed in ISO 3309:1984/PDAD1, as applied in the Point-to-Point Protocol. These modifications allow HDLC to be used with 8-bit asynchronous links.
この付録はPointからポイントへのプロトコルで適用されるようにISO3309: 1984/PDAD1で提案されたISO3309-1979への変更をまとめます。 これらの変更は、HDLCが8ビットの非同期なリンクと共に使用されるのを許容します。
Transmission Considerations
トランスミッション問題
All octets are transmitted with one start bit, eight bits of data,
and one stop bit. There is no provision in either PPP or ISO
3309:1984/PDAD1 for seven bit asynchronous links.
すべての八重奏が1つのスタートビット、8ビットのデータ、および1つのストップビットで伝えられます。 支給が全くPPPかISO3309のどちらかにありません: 7ビットの非同期なリンクへの1984/PDAD1。
Flag Sequence
フラグ・シーケンス
The Flag Sequence is a single octet and indicates the beginning or
end of a frame. The Flag Sequence consists of the binary sequence
01111110 (hexadecimal 0x7e).
Flag Sequenceはただ一つの八重奏であり、フレームの始めか端を示します。 Flag Sequenceは2進の系列01111110(16進0x7e)から成ります。
Transparency
透明
On asynchronous links, a character stuffing procedure is used.
The Control Escape octet is defined as binary 01111101
(hexadecimal 0x7d) where the bit positions are numbered 87654321
(not 76543210, BEWARE).
非同期なリンクでは、キャラクタ詰め物の手順は使用されています。 Control Escape八重奏はビット位置が番号付の87654321(76543210、BEWAREでない)である2進の01111101(16進0x7d)と定義されます。
After FCS computation, the transmitter examines the entire frame
between the two Flag Sequences. Each Flag Sequence, Control
Escape octet and octet with value less than hexadecimal 0x20 which
is flagged in the Remote Async-Control-Character-Map is replaced
by a two octet sequence consisting of the Control Escape octet and
the original octet with bit 6 complemented (i.e., exclusive-or'd
with hexadecimal 0x20).
FCS計算の後に、送信機は2Flag Sequencesの間の全体のフレームを調べます。 各Flag Sequence、Control Escape八重奏、および値がRemote Async規制キャラクター地図で旗を揚げられる16進0x20をビット6によるControl Escape八重奏から成る系列とオリジナルの八重奏が補足となった2八重奏に取り替えるより(すなわち、排他的論理和は16進0x20でそうするでしょう)少ない八重奏。
Prior to FCS computation, the receiver examines the entire frame
between the two Flag Sequences. Each octet with value less than
hexadecimal 0x20 is checked. If it is flagged in the Local
Async-Control-Character-Map, it is simply removed (it may have
been inserted by intervening data communications equipment). For
each Control Escape octet, that octet is also removed, but bit 6
of the following octet is complemented. A Control Escape octet
immediately preceding the closing Flag Sequence indicates an
invalid frame.
FCS計算の前に、受信機は2Flag Sequencesの間の全体のフレームを調べます。 値が16進0x20より少ない各八重奏はチェックされます。 Local Async規制キャラクター地図でそれに旗を揚げさせるなら、単にそれを取り除きます(それはデータ通信装置に介入することによって、挿入されたかもしれません)。 また、それぞれのControl Escape八重奏において、その八重奏を取り除きますが、以下の八重奏のビット6は補足となります。 すぐに終わりのFlag Sequenceに先行するControl Escape八重奏は無効のフレームを示します。
Note: The inclusion of all octets less than hexadecimal 0x20
allows all ASCII control characters [10] excluding DEL (Delete)
to be transparently communicated through almost all known data
communications equipment.
以下に注意してください。 16進0x20より少ないすべての八重奏の包含は、ほとんどすべての知られているデータ通信装置を通って透明にコミュニケートするために、DEL(削除する)を除きながら、すべてのASCII制御文字[10]を許容します。
Simpson [Page 58] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[58ページ]RFC1331 1992年5月
The transmitter may also send octets with value in the range 0x40
through 0xff (except 0x5e) in Control Escape format. Since these
octet values are not negotiable, this does not solve the problem
of receivers which cannot handle all non-control characters.
Also, since the technique does not affect the 8th bit, this does
not solve problems for communications links that can send only 7-
bit characters.
また、値が範囲0x40にある状態で、送信機は0xff(0x5eを除いた)を通してControl Escape形式で八重奏を送るかもしれません。 これらの八重奏値が交渉可能でないので、これはすべての非制御文字を扱うことができるというわけではない受信機の問題を解決しません。 また、テクニックが8番目のビットに影響しないので、これは7の噛み付いているキャラクタしか送ることができないコミュニケーションリンクへの問題を解決しません。
A few examples may make this more clear. Packet data is
transmitted on the link as follows:
いくつかの例がこの以上を明らかにするかもしれません。 パケットデータは以下のリンクの上に送られます:
0x7e is encoded as 0x7d, 0x5e.
0x7d is encoded as 0x7d, 0x5d.
0x01 is encoded as 0x7d, 0x21.
0x7eは0x7d、0x5eとしてコード化されます。 0x7dは0x7d、0x5dとしてコード化されます。 0×01 0x7d、0×21として、コード化されます。
Some modems with software flow control may intercept outgoing DC1
and DC3 ignoring the 8th (parity) bit. This data would be
transmitted on the link as follows:
ソフトウェア・フロー制御があるいくつかのモデムが8(同等)番目のビットを無視する出発しているDC1とDC3を妨害するかもしれません。 このデータは以下のリンクの上に送られるでしょう:
0x11 is encoded as 0x7d, 0x31.
0x13 is encoded as 0x7d, 0x33.
0x91 is encoded as 0x7d, 0xb1.
0x93 is encoded as 0x7d, 0xb3.
0×11 0x7d、0×31として、コード化されます。 0×13 0x7d、0×33として、コード化されます。 0×91 0x7d、0xb1として、コード化されます。 0×93 0x7d、0xb3として、コード化されます。
Aborting a Transmission
トランスミッションを中止します。
On asynchronous links, frames may be aborted by transmitting a "0"
stop bit where a "1" bit is expected (framing error) or by
transmitting a Control Escape octet followed immediately by a
closing Flag Sequence.
非同期なリンクの上では、フレームがaを伝えることによって中止されるかもしれない、「0インチのストップビット、どこ、「1インチのビットが予想されたか(誤りを縁どっていて)、または伝わることによって、コントロールエスケープ八重奏はすぐ終わりのフラグ・シーケンスで続いたか」。
Time Fill
タイム・フィル
On asynchronous links, inter-octet and inter-frame time fill MUST
be accomplished by transmitting continuous "1" bits (mark-hold
state).
非同期なリンクでは、伝える連続した「1インチのビット(マークホールド状態)」で相互八重奏とインターフレームタイム・フィルを実行しなければなりません。
Note: On asynchronous links, inter-frame time fill can be
viewed as extended inter-octet time fill. Doing so can save
one octet for every frame, decreasing delay and increasing
bandwidth. This is possible since a Flag Sequence may serve as
both a frame close and a frame begin. After having received
any frame, an idle receiver will always be in a frame begin
state.
以下に注意してください。 非同期なリンクの上では、拡張相互八重奏タイム・フィルとしてインターフレームタイム・フィルを見なすことができます。 遅れを減少させて、帯域幅を増加させて、そうするのは各フレームあたり1つの八重奏を救うことができます。 フレーム閉鎖とフレームの両方が始まるときFlag Sequenceが役立つかもしれないので、これは可能です。 どんなフレームも受けた後に、使用されていない受信機はフレームで状態を始めるためにいつもことになるでしょう。
Robust transmitters should avoid using this trick over-
zealously since the price for decreased delay is decreased
reliability. Noisy links may cause the receiver to receive
強健な送信機は、減少している遅れの価格が減少している信頼性であるので過剰熱心にこのトリックを使用するのを避けるはずです。 騒がしいリンクで、受信機は受信されるかもしれません。
Simpson [Page 59] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[59ページ]RFC1331 1992年5月
garbage characters and interpret them as part of an incoming
frame. If the transmitter does not transmit a new opening Flag
Sequence before sending the next frame, then that frame will be
appended to the noise characters causing an invalid frame (with
high reliability). Transmitters should avoid this by
transmitting an open Flag Sequence whenever "appreciable time"
has elapsed since the prior closing Flag Sequence. It is
suggested that implementations will achieve the best results by
always sending an opening Flag Sequence if the new frame is not
back-to-back with the last. The maximum value for "appreciable
time" is likely to be no greater than the typing rate of a slow
to average typist, say 1 second.
そして、ゴミキャラクタ、入って来るフレームの一部として彼らを解釈してください。 隣のフレームを送る前に送信機が新しい初めのFlag Sequenceを伝えないと、無効のフレーム(高信頼性がある)を引き起こす雑音キャラクタにそのフレームを追加するでしょう。 送信機は、先の終わりのFlag Sequence以来「かなりの時間」が経過しているときはいつも、開いているFlag Sequenceを伝えることによって、これを避けるはずです。 新しいフレームが獲得しないと実現がいつも初めのFlag Sequenceを送ることによって最も良い結果を獲得することが提案される、背中合わせである、最終で。 「かなりの時間」のための最大値はタイピストを平均するのが遅いaのタイプよりレートである傾向があります、たとえば、1秒。
Simpson [Page 60] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[60ページ]RFC1331 1992年5月
B. Fast Frame Check Sequence (FCS) Implementation
B。 速いフレームチェックシーケンス(FCS)実現
B.1. FCS Computation Method
B.1。 FCS計算方法
The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. This implementation is based on [7], [8], and [9]. The table is created by the code in section B.2.
以下のコードはデータがインタフェースに到着するのでFrame Check Sequenceについて計算するための索表計算を提供します。 この実現は[7]、[8]、および[9]に基づいています。 テーブルはセクションB.2のコードによって作成されます。
/*
* u16 represents an unsigned 16-bit number. Adjust the typedef for
* your hardware.
*/
typedef unsigned short u16;
/**u16は無記名の16ビットの数を表します。 *のためにtypedefを調整してください。あなたのハードウェア。 */typedef無記名の短いu16。
/*
* FCS lookup table as calculated by the table generator in section
* B.2.
*/
static u16 fcstab[256] = {
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
計算されるとしてのセクション*B.2のテーブルジェネレータによる/**FCSルックアップ表。 */静的なu16 fcstab256が等しい、0×0000 0×1189 0×2312 0x329b、0×4624、0x57ad、0×6536、0x74bf、0x8c48、0x9dc1、0xaf5a、0xbed3、0xca6c、0xdbe5、0xe97e、0xf8f7、0×1081、0×0108、0×3393、0x221a、0x56a5、0x472c、0x75b7、0x643e、0x9cc9、0x8d40、0xbfdb、0xae52、0xdaed; 0xcb64、0xf9ff、0xe876、0×2102、0x308b、0×0210、0×1399、0×6726、0x76af、0×4434、0x55bd、0xad4a、0xbcc3、0x8e58、0x9fd1、0xeb6e、0xfae7、0xc87c、0xd9f5、0×3183、0x200a、0×1291、0×0318、0x77a7、0x662e、0x54b5、0x453c、0xbdcb、0xac42、0x9ed9、0x8f50、0xfbef; 0xea66、0xd8fd、0xc974、0×4204、0x538d、0×6116、0x709f、0×0420、0x15a9、0×2732、0x36bb、0xce4c、0xdfc5、0xed5e、0xfcd7、0×8868、0x99e1、0xab7a、0xbaf3、0×5285、0x430c、0×7197、0x601e、0x14a1、0×0528、0x37b3、0x263a、0xdecd、0xcf44、0xfddf、0xec56、0x98e9、0×8960、0xbbfb、0xaa72、0×6306、0x728f、0×4014、0x519d、0×2522、0x34ab、0×0630、0x17b9、0xef4e、0xfec7、0xcc5c、0xddd5、0xa96a、0xb8e3、0x8a78、0x9bf1、0×7387、0x620e、0×5095、0x411c、0x35a3、0x242a、0x16b1、0×0738、0xffcf、0xee46、0xdcdd、0xcd54、0xb9eb、0xa862、0x9af9、0x8b70、0×8408、0×9581、0xa71a、0xb693、0xc22c、0xd3a5、0xe13e、0xf0b7、0×0840、0x19c9、0x2b52、0x3adb、0x4e64、0x5fed、0x6d76、0x7cff、0×9489、0×8500、0xb79b、0xa612、0xd2ad、0xc324、0xf1bf、0xe036、0x18c1、0×0948、0x3bd3、0x2a5a、0x5ee5、0x4f6c、0x7df7、0x6c7e、0xa50a、0xb483、0×8618、0×9791、0xe32e、0xf2a7、0xc03c、0xd1b5、0×2942、0x38cb; 0x0a50、0x1bd9、0x6f66、0x7eef、0x4c74、0x5dfd、0xb58b、0xa402、0×9699、0×8710、0xf3af、0xe226、0xd0bd、0xc134、0x39c3、0x284a、0x1ad1、0x0b58、0x7fe7、0x6e6e、0x5cf5、0x4d7c、0xc60c、0xd785、0xe51e、0xf497、0×8028、0x91a1、0xa33a、0xb2b3、0x4a44、0x5bcd、0×6956、0x78df、0x0c60、0x1de9、0x2f72、0x3efb、0xd68d、0xc704、0xf59f、0xe416、0x90a9、0×8120、0xb3bb、0xa232
Simpson [Page 61] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[61ページ]RFC1331 1992年5月
0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
};
0x5ac5、0x4b4c、0x79d7、0x685e、0x1ce1、0x0d68、0x3ff3、0x2e7a、0xe70e、0xf687、0xc41c、0xd595、0xa12a、0xb0a3、0×8238、0x93b1、0x6b46、0x7acf、0×4854、0x59dd、0x2d62、0x3ceb、0x0e70、0x1ff9、0xf78f、0xe606、0xd49d、0xc514、0xb1ab、0xa022、0x92b9、0×8330、0x7bc7、0x6a4e、0x58d5、0x495c、0x3de3、0x2c6a、0x1ef1、0x0f78、。
#define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */
#定義、PPPINITFCS 0xffff/*初期のFCS値*/#、はPPPGOODFCS 0xf0b8/*良い最終的なFCS値*/を定義します。
/*
* Calculate a new fcs given the current fcs and the new data.
*/
u16 pppfcs(fcs, cp, len)
register u16 fcs;
register unsigned char *cp;
register int len;
{
ASSERT(sizeof (u16) == 2);
ASSERT(((u16) -1) > 0);
while (len--)
fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
現在のfcsと新しいデータを考えて、/**は新しいfcsについて計算します。 */u16 pppfcs(fcs、cp、len)レジスタu16 fcs。 無記名の炭*cpを登録してください。 int lenを登録してください。 ASSERT(sizeof(u16)=2)(ASSERT(((u16)-1)>0))がゆったり過ごす、(len--、)、fcsは^fcstab[(fcs^ *cp++)と0xff]と等しいです(>>8をfcsします)。
return (fcs);
}
戻ってください(fcs)。 }
Simpson [Page 62] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[62ページ]RFC1331 1992年5月
B.2. Fast FCS table generator
B.2。 速いFCSテーブルジェネレータ
The following code creates the lookup table used to calculate the FCS.
以下のコードはFCSについて計算するのに使用されるルックアップ表を作成します。
/*
* Generate a FCS table for the HDLC FCS.
*
* Drew D. Perkins at Carnegie Mellon University.
*
* Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
*/
/**はHDLC FCSのためにFCSテーブルを発生させます。 * * カーネギーメロン大学のドリュー・D.パーキンス。 * * コードはモホセンBananとD.ヒューRedelmeierから気前よく借りました。 */
/*
* The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408).
*/
#define P 0x8408
/**、HDLC多項式: x**0+x**5+x**12+x**16(0×8408)。 */#はP0x8408を定義します。
main()
{
register unsigned int b, v;
register int i;
メイン()、無記名のint b、vを登録してください; int iを登録してください。
printf("typedef unsigned short u16;\n");
printf("static u16 fcstab[256] = {");
for (b = 0; ; ) {
if (b % 8 == 0)
printf("\n");
printf(「typedefの無記名の短いu16; \n」)。 printf、(「静的なu16 fcstab[256]が等しい、「)、(b=0)、(b%8 == 0)printf(「\n」)であるなら;」
v = b;
for (i = 8; i--; )
v = v & 1 ? (v >> 1) ^ P : v >> 1;
v=b。 =vと1? (>>1に対する)^Pに対する(i=8(i))のために: v>>1。
printf("0x%04x", v & 0xFFFF);
if (++b == 256)
break;
printf(",");
}
printf("\n};\n");
}
printf(「0x%04x」、v、および0xFFFF)。 (+ + b=256)が壊れるなら。 printf、(「」、)、。 printf、(「\n、;、\n」)、。 }
Simpson [Page 63] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[63ページ]RFC1331 1992年5月
C. LCP Recommended Options
C。 LCPのお勧めのオプション
The following Configurations Options are recommended:
以下のConfigurations Optionsはお勧めです:
SYNC LINES
同時性線
Magic Number
Link Quality Monitoring
No Address and Control Field Compression
No Protocol Field Compression
アドレスを全くモニターしないマジックナンバーリンク品質と制御フィールド圧縮いいえプロトコル分野圧縮
ASYNC LINES
ASYNC線
Async Control Character Map
Magic Number
Address and Control Field Compression
Protocol Field Compression
Async制御文字地図マジックナンバーアドレスと制御フィールド圧縮プロトコル分野圧縮
Simpson [Page 64] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[64ページ]RFC1331 1992年5月
Security Considerations
セキュリティ問題
Security issues are briefly discussed in sections concerning the Authentication Phase, and the Authentication-Protocol Configuration Option. Further discussion is planned in a separate document entitled PPP Authentication Protocols.
Authentication Phase、およびAuthentication-プロトコルConfiguration Optionに関してセクションで簡潔に安全保障問題について議論します。 さらなる議論はPPP Authenticationプロトコルと題する別々のドキュメントで計画されています。
References
参照
[1] Electronic Industries Association, EIA Standard RS-232-C,
"Interface Between Data Terminal Equipment and Data
Communications Equipment Employing Serial Binary Data
Interchange", August 1969.
[1] 電子工業会、EIAの標準のRS232Cは「連続の2進のデータ置き換えを使って、データ端末装置とデータ通信装置の間で連結します」、1969年8月。
[2] International Organization For Standardization, ISO Standard
3309-1979, "Data communication - High-level data link control
procedures - Frame structure", 1979.
[2]国際標準化機構、ISO Standard3309-1979、「データ通信--ハイレベル・データリンク制御手順--枠組構造」、1979。
[3] International Organization For Standardization, ISO Standard
4335-1979, "Data communication - High-level data link control
procedures - Elements of procedures", 1979.
[3]国際標準化機構、ISO Standard4335-1979、「データ通信--ハイレベル・データリンク制御手順--手順のElements」1979。
[4] International Organization For Standardization, ISO Standard
4335-1979/Addendum 1, "Data communication - High-level data
link control procedures - Elements of procedures - Addendum 1",
1979.
[4]国際標準化機構、ISO Standard4335-1979/付加物1、「データ通信--ハイレベル・データリンク制御手順--手順のElements--付加物1インチ、1979。」
[5] International Organization For Standardization, Proposed Draft
International Standard ISO 3309:1983/PDAD1, "Information
processing systems - Data communication - High-level data link
control procedures - Frame structure - Addendum 1: Start/stop
transmission", 1984.
ISO3309: [5]国際標準化機構、Proposed国際規格案1983/PDAD1、「情報処理システム--データ通信--ハイレベル・データリンク制御手順--枠組構造--付加物1:、」 「始め/停止送信」、1984。
[6] International Telecommunication Union, CCITT Recommendation
X.25, "Interface Between Data Terminal Equipment (DTE) and Data
Circuit Terminating Equipment (DCE) for Terminals Operating in
the Packet Mode on Public Data Networks", CCITT Red Book,
Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984.
[6] 国際電気通信連合、CCITT推薦X.25は「公共のデータ網がパケット形態で作動して、データ端末装置(DTE)とデータ回線終端装置(DCE)の間で端末に連結します」、CCITT職員録、巻VIII、分冊VIII.3、Rec。 X.25、10月1984日
[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983.
[7] ペレス、「バイト的なCRC計算」、IEEEミクロ、1983年6月。
[8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
September 1986.
[8] モース、G.、「ビットとバイトの計算のCRCのもの」、バイト、1986年9月。
[9] LeVan, J., "A Fast CRC", Byte, November 1987.
1987年11月の[9] レバン、J.、「速いCRC」バイト。
[10] American National Standards Institute, ANSI X3.4-1977,
"American National Standard Code for Information Interchange",
[10]American National Standards Institut、ANSI X3.4-1977、「情報交換用米国標準コード」
Simpson [Page 65] RFC 1331 Point-to-Point Protocol May 1992
二地点間プロトコルシンプソン[65ページ]RFC1331 1992年5月
1977.
1977.
[11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[11] USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
Acknowledgments
承認
Much of the text in this document is taken from the WG Requirements (unpublished), and RFCs 1171 & 1172, by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis.
カーネギーメロン大学のドリュー・パーキンス、およびカリフォルニア大学デイビス校のラスHobbyによるWG Requirements(未発表の)、およびRFCs1171と1172からテキストの多くを本書では取ります。
Many people spent significant time helping to develop the Point-to- Point Protocol. The complete list of people is too numerous to list, but the following people deserve special thanks: Rick Adams (UUNET), Ken Adelman (TGV), Fred Baker (ACC), Mike Ballard (Telebit), Craig Fox (NSC), Karl Fox (Morning Star Technologies), Phill Gross (NRI), former WG chair Russ Hobby (UC Davis), David Kaufman (Proteon), former WG chair Steve Knowles (FTP Software), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), former WG chair Drew Perkins (CMU), Greg Satz (cisco systems) and Asher Waldfogel (Wellfleet).
Pointからポイントへのプロトコルを開発するのを助けるのに多くの人々が重要な時間を費やしました。 人々の全リストは記載できないくらい非常に多いのですが、以下の人々は特別な感謝に値します: リック・アダムス(UUNET)、ケン・エーデルマン(TGV)、フレッドベイカー(ACC)、マイク・バラード(テレビット)クレイグフォックス(NSC)、カールフォックス(朝のStar Technologies)、フィルGross(NRI)、元WGはラスHobby(UCデイヴィス)、デヴィッド・コーフマン(Proteon)、元スティーブ・ノウルズWG議長(FTP Software)、ジョンLoVerso(Xylogics)、ビルMelohn(サン・マイクロシステムズ)、マイク・パットン(MIT)、元ドリュー・パーキンスWG議長(米カーネギーメロン大学)、グレッグSatz(コクチマスシステム)、およびアシャーWaldfogel(Wellfleet)をまとめます。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
ブライアン・ロイド・ロイドと3420年のサドベリー道路キャメロン公園、仲間カリフォルニア 95682
Phone: (916) 676-1147
以下に電話をしてください。 (916) 676-1147
EMail: brian@ray.lloyd.com
メール: brian@ray.lloyd.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6025
P O Box6205イーストランシング、Services MI48826-6025に相談するウィリアムアレンシンプソン空想家コンピュータシステムズ
EMail: bsimpson@ray.lloyd.com
メール: bsimpson@ray.lloyd.com
Simpson [Page 66]
シンプソン[66ページ]
一覧
スポンサーリンク
