RFC1548 日本語訳
1548 The Point-to-Point Protocol (PPP). W. Simpson. December 1993. (Format: TXT=111638 bytes) (Obsoletes RFC1331) (Obsoleted by RFC1661) (Updated by RFC1570) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson Request for Comments: 1548 Daydreamer Obsoletes: RFC 1331 December 1993 Category: Standards Track
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1548年の空想家は以下を時代遅れにします。 RFC1331 1993年12月のカテゴリ: 標準化過程
The Point-to-Point Protocol (PPP)
二地点間プロトコル(ppp)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
Pointからポイントへのプロトコル(PPP)はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは3つの主なコンポーネントから成ります:
1. A method for encapsulating multi-protocol datagrams.
1. マルチプロトコルデータグラムをカプセル化するためのメソッド。
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.
このドキュメントはPPP組織、方法論、およびPPPカプセル化を定義します、設定パラメータの豊かな分類を交渉できて、追加管理機能を提供する広げることができるオプション交渉メカニズムと共に。 PPP Link Controlプロトコル(LCP)はこのメカニズムで説明されます。
This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 ietf-ppp@ucdavis.edu メーリングリストにコメントを提出するべきです。
Simpson [Page 1] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[1ページ]RFC1548のプロトコル1993年12月
Table of Contents
目次
1. Introduction ................................................3 1.1 Specification of Requirements ...............................4 1.2 Terminology .................................................5 2. PPP Encapsulation ...........................................5 3. PPP Link Operation ..........................................8 3.1 Overview ....................................................8 3.2 Phase Diagram ...............................................8 3.3 Link Dead (physical-layer not ready) ........................9 3.4 Link Establishment Phase ....................................9 3.5 Authentication Phase ........................................9 3.6 Network-Layer Protocol Phase ................................10 3.7 Link Termination Phase ......................................10 4. The Option Negotiation Automaton ............................11 4.1 State Diagram ...............................................12 4.2 State Transition Table ......................................14 4.3 A Day in the Life ...........................................15 4.4 States ......................................................16 4.5 Events ......................................................19 4.6 Actions .....................................................23 4.7 Loop Avoidance ..............................................26 4.8 Counters and Timers .........................................26 5. LCP Packet Formats ..........................................27 5.1 Configure-Request ...........................................29 5.2 Configure-Ack ...............................................30 5.3 Configure-Nak ...............................................31 5.4 Configure-Reject ............................................33 5.5 Terminate-Request and Terminate-Ack .........................34 5.6 Code-Reject .................................................35 5.7 Protocol-Reject .............................................36 5.8 Echo-Request and Echo-Reply .................................37 5.9 Discard-Request .............................................39 6. LCP Configuration Options ...................................40 6.1 Maximum-Receive-Unit ........................................41 6.2 Async-Control-Character-Map .................................42 6.3 Authentication-Protocol .....................................43 6.4 Quality-Protocol ............................................45 6.5 Magic-Number ................................................46 6.6 Protocol-Field-Compression ..................................49 6.7 Address-and-Control-Field-Compression .......................50 APPENDIX A. LCP Recommended Options ..............................51 SECURITY CONSIDERATIONS ..........................................51 REFERENCES .......................................................52 ACKNOWLEDGEMENTS .................................................52 CHAIR'S ADDRESS ..................................................52 EDITOR'S ADDRESS .................................................53
1. 序論…3 1.1 要件の仕様…4 1.2用語…5 2. pppカプセル化…5 3. pppは操作をリンクします…8 3.1概要…8 3.2 ダイヤグラムの位相を合わせてください…8 3.3 Dead(準備ができていなく身体検査で層にする)をリンクしてください…9 3.4 確立段階をリンクしてください…9 3.5認証フェーズ…9 3.6ネットワーク層プロトコルフェーズ…10 3.7 終了段階をリンクしてください…10 4. オプション交渉オートマトン…11 4.1 ダイヤグラムを述べてください…12 4.2 変遷テーブルを述べてください…14 4.3 寿命における1日…15 4.4 述べます。16 4.5のイベント…19 4.6の動作…23 4.7 回避を輪にしてください…26 4.8個のカウンタとタイマ…26 5. LCPパケット・フォーマット…27 5.1 要求を構成します…29 5.2 Ackを構成します…30 5.3 Nakを構成します…31 5.4 廃棄物を構成します…33 5.5 要求を終えてAckを終えます…34 5.6コード廃棄物…35 5.7プロトコル廃棄物…36 5.8のエコー要求とエコー・リプライ…37 5.9 …を破棄して要求してください…39 6. LCP設定オプション…40 6.1 最大はユニットを受けます…41 6.2 Asyncはキャラクター地図を制御します…42 6.3 認証プロトコル…43 6.4 品質で議定書を作ってください…45 6.5マジックナンバー…46 6.6 プロトコル分野圧縮…49 6.7 アドレスとコントロールは圧縮をさばきます…50 付録A.LCPはオプションを推薦しました…51 セキュリティ問題…51の参照箇所…52の承認…52 議長のアドレス…52エディタのアドレス…53
Simpson [Page 2] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[2ページ]RFC1548のプロトコル1993年12月
1. Introduction
1. 序論
Encapsulation
カプセル化
The PPP encapsulation 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 [1].
PPPカプセル化は同時に、同じリンクの上に異なったネットワーク層プロトコルのマルチプレクシングに備えます。 PPPがさまざまなホスト、ブリッジ、およびルータ[1]の簡単な接続に一般的な解決法を提供することを意図します。
The PPP encapsulation has been carefully designed to retain
compatibility with most commonly used supporting hardware.
PPPカプセル化は、ハードウェアを支えながら一般的に使用される大部分との互換性を保有するように入念に設計されています。
Only 8 additional octets are necessary to form the encapsulation
when used with the default HDLC framing. In environments where
bandwidth is at a premium, the encapsulation and framing may be
shortened to 2 or 4 octets.
デフォルトHDLC縁どりと共に使用されると、8つの追加八重奏だけが、カプセル化を形成するのに必要です。 プレミアムには帯域幅がある環境で、カプセル化と縁どりは2か4つの八重奏に短くされるかもしれません。
To support high speed implementations, the default encapsulation
uses only simple fields, only one of which needs to be examined
for demultiplexing. The default header and information fields
fall on 32-bit boundaries, and the trailer may be padded to an
arbitrary boundary.
高速が実装であるとサポートするのに、デフォルトカプセル化は簡単な分野だけを使用します。そのひとりだけが逆多重化がないかどうか調べられる必要があります。 デフォルトヘッダーと情報フィールドは32ビットの境界の責任となります、そして、トレーラは任意の境界に水増しされるかもしれません。
Link Control Protocol
リンク制御プロトコル
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.
さまざまな環境に携帯用であることができるくらい多能になるように、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
companion documents.
指すポイントリンクは、ネットワーク・プロトコルの現在のファミリーに関する多くの問題を悪化させる傾向があります。 例えば、IPアドレスの課題と管理(LAN環境においてさえ問題である)は回路で切り換えられたポイントツーポイント接続(ダイヤルアップモデムサーバなどの)の上で特に難しいです。 これらの問題はNetwork Controlプロトコル(NCP)のファミリーによって扱われます。(それぞれ、プロトコルはそれらのそれぞれのネットワーク層プロトコルによって必要とされた特定の必要性を管理します)。 これらのNCPは仲間ドキュメントで定義されます。
Simpson [Page 3] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[3ページ]RFC1548のプロトコル1993年12月
Configuration
構成
It is intended that PPP links be easy to configure. By design,
the standard defaults handle all common configurations. The
implementor can 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
document is specified in terms of the Link Control Protocol (LCP),
the same facilities are designed to be used by other control
protocols, especially the family of NCPs.
この自己構成は広げることができるオプション交渉メカニズムを通して実装されます。リンクの各端はメカニズムでその能力と要件についてもう片方に説明します。 Link Controlプロトコル(LCP)で本書では説明されたオプション交渉メカニズムは指定されますが、同じ施設は、他の制御プロトコル(特にNCPのファミリー)によって使用されるように設計されています。
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 must 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つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
Simpson [Page 4] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[4ページ]RFC1548のプロトコル1993年12月
1.2 Terminology
1.2 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
datagram
データグラム
The unit of transmission in the network layer (such as IP). A
datagram may be encapsulated in one or more packets passed to the
data link layer.
ネットワーク層(IPなどの)における、トランスミッションのユニット。 データグラムはデータ・リンク層に通過された1つ以上のパケットでカプセル化されるかもしれません。
frame
フレーム
The unit of transmission at the data link layer. A frame may
include a header and/or a trailer, along with some number of units
of data.
データ・リンク層におけるトランスミッションのユニット。 フレームは何らかの数のユニットのデータに伴うヘッダー、そして/または、トレーラを含むかもしれません。
packet
パケット
The basic unit of encapsulation, which is passed across the
interface between the network layer and the data link layer. A
packet is usually mapped to a frame; the exceptions are when data
link layer fragmentation is being performed, or when multiple
packets are incorporated into a single frame.
カプセル化の原単位。(それは、ネットワーク層とデータ・リンク層とのインタフェースの向こう側に通過されます)。 通常、パケットはフレームに写像されます。 例外はデータ・リンク層断片化がいつ実行されているか、そして、または複数のパケットがいつシングルフレームに法人組織であるかということです。
peer
同輩
The other end of the point-to-point link.
ポイントツーポイント接続のもう一方の端。
silently discard
静かに捨ててください。
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the error, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
これは、実装がさらなる処理なしでパケットを捨てることを意味します。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. PPP Encapsulation
2. pppカプセル化
The PPP encapsulation is used to disambiguate multiprotocol datagrams. This encapsulation requires framing to indicate the beginning and end of the encapsulation. Methods of providing framing are specified in companion documents.
PPPカプセル化は、「マルチ-プロトコル」データグラムのあいまいさを除くのに使用されます。このカプセル化は、カプセル化の首尾を示すために縁どるのを必要とします。 縁どりを提供するメソッドは仲間ドキュメントで指定されます。
Simpson [Page 5] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[5ページ]RFC1548のプロトコル1993年12月
A summary of the PPP encapsulation is shown below. The fields are transmitted from left to right.
PPPカプセル化の概要は以下に示されます。 野原は左から右まで伝えられます。
+----------+-------------+---------+
| Protocol | Information | Padding |
| 16 bits | * | * |
+----------+-------------+---------+
+----------+-------------+---------+ | プロトコル| 情報| 詰め物| | 16ビット| * | * | +----------+-------------+---------+
Protocol Field
プロトコル分野
The Protocol field is two octets and its value identifies the
datagram encapsulated in the Information field of the packet. The
field is transmitted and received most significant octet first.
プロトコル分野は2つの八重奏です、そして、値はパケットの情報分野でカプセル化されたデータグラムを特定します。 最初に、分野は伝えられて容認された最も重要な八重奏です。
The structure of this 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
treated as having an unrecognized Protocol.
アドレス・フィールドにおいて、この分野の構造はISO3309拡張機能と一致しています。 すべてのプロトコルが変であるに違いありません。 最も重要でない八重奏の最下位ビットは「1インチ」と等しくなければなりません。 また、最も重要な八重奏の最下位ビットが「0インチ」と等しいように、すべてのプロトコルを割り当てなければなりません。 これらの規則に従わない受け取られたフレームを認識されていないプロトコルを持っているとして扱わなければなりません。
Protocol field values in the "0***" to "3***" range identify the
network-layer protocol of specific packets, and values in the
"8***" to "b***" range identify packets belonging to the
associated Network Control Protocols (NCPs), if any.
「3***」範囲への「0***」のプロトコル分野値は特定のパケットのネットワーク層プロトコルを特定します、そして、「b***」範囲への「8***」の値はもしあれば関連ネットワーク制御プロトコル(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
packets as link-layer Control Protocols (such as LCP).
「7***」範囲への「4***」のプロトコル分野値はプロトコルにどんな関連NCPも持っていない低いボリュームトラフィックで使用されます。 「f***」範囲への「c***」のプロトコル分野値は、パケットがリンクレイヤControlプロトコル(LCPなどの)であると認識します。
Up-to-date values of the Protocol field are specified in the most
recent "Assigned Numbers" RFC [2]. Current values are assigned as
follows:
プロトコル分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
Value (in hex) Protocol Name
値(十六進法における)のプロトコルName
0001 Padding Protocol
0003 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
0001年の001fへの詰め物プロトコル0003は0021年の(透明効率の悪い)のインターネットプロトコル0023OSI Network Layer0025ゼロックスNS IDP0027DECnet Phase IV0029Appletalk 002bノベルIPX 002dヴァンジェーコブソンCompressed TCP/IP002fヴァンジェーコブソンUncompressed TCP/IPを予約しました。
Simpson [Page 6] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[6ページ]RFC1548のプロトコル1993年12月
0031 Bridging PDU
0033 Stream Protocol (ST-II)
0035 Banyan Vines
0037 unused
0039 AppleTalk EDDP
003b AppleTalk SmartBuffered
003d Multi-Link
005d reserved (compression inefficient)
00cf reserved (PPP NLPID)
00fd 1st choice compression
00ff reserved (compression inefficient)
0031 PDU0033Streamプロトコル(ST-II)0035Banyanが0039年のバインズ0037の未使用のAppleTalk EDDP 003b AppleTalk SmartBuffered 003d Multi-リンクの005dの予約された(圧縮効率の悪い)00cfであるとブリッジするのが00ffが控えた(PPP NLPID)00fdの第一希望の圧縮を控えました。(圧縮効率の悪い)です。
0201 802.1d Hello Packets
0203 IBM Source Routing BPDU
0231 Luxcom
0233 Sigma Network Systems
BPDU0231Luxcom0233σネットワーク・システムを発送するこんにちは、パケット0203IBMが出典を明示する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
8037 unused
8039 Reserved
803b Reserved
803d Multi-Link Control Protocol
80fd Compression Control Protocol
80ff Reserved
未使用の8021年のインターネットプロトコルControlプロトコル8023OSI Network Layer Controlプロトコル8025ゼロックスNS IDP Controlプロトコル8027DECnet Phase IV Controlプロトコル8029Appletalk Controlプロトコル802bノベルIPX Controlプロトコル802d Reserved 802f Reserved8031Bridging NCP8033StreamプロトコルControlプロトコル8035BanyanバインズControlプロトコル8037のReserved 803b Reserved 803d Multi-リンクControlプロトコル80fd Compression Controlプロトコル8039 80ff Reserved
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)から数を得なければなりません。
Information Field
情報フィールド
The Information field is zero or more octets. The Information
field contains the datagram for the protocol specified in the
Protocol field.
情報分野はゼロであるか以上が八重奏です。 情報分野はプロトコル分野で指定されたプロトコルのためのデータグラムを含んでいます。
Simpson [Page 7] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[7ページ]RFC1548のプロトコル1993年12月
The maximum length for the Information field, including Padding,
is termed the Maximum Receive Unit (MRU), which defaults to 1500
octets. By negotiation, consenting PPP implementations may use
other values for the MRU.
Paddingを含む情報分野への最大の長さはMaximum Receive Unit(MRU)と呼ばれます。(Maximum Receive Unitは1500の八重奏をデフォルトとします)。 交渉で、同意して、PPP実現はMRUに他の値を使用するかもしれません。
Padding
詰め物
On transmission, the Information field MAY be padded with an
arbitrary number of octets up to the MRU. It is the
responsibility of each protocol to distinguish padding octets from
real information.
トランスミッションのときに、情報分野は八重奏の特殊活字の数字でMRUまで水増しされるかもしれません。 本当の情報と八重奏を水増しするのを区別するのは、それぞれのプロトコルの責任です。
3. PPP Link Operation
3. pppリンク操作
3.1 Overview
3.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 MUSTは、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パケットがリンクを閉鎖するか、またはいくつかの外部の出来事が起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
3.2 Phase Diagram
3.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 |<-+
| | | |
+-----------+ +---------+
+------+ +-----------+ +--------------+ | | 上がる| | 開かれます。| | 成功/、なし| 死者|、-、-、-、-、-、--、>| 設立します。|、-、-、-、-、-、-、-、-、--、>| 認証します。|--+ | | | | | | | +------+ +-----------+ +--------------+ | ^失敗してください。| 失敗してください。| | + <。--------------+ +----------+ | | | | | +-----------+ | +---------+ | | 下に| | | 閉じます。| | | +------------| 終わってください。| <、-、--+ <。----------| ネットワーク| <、-+ | | | | +-----------+ +---------+
Simpson [Page 8] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[8ページ]RFC1548のプロトコル1993年12月
3.3 Link Dead (physical-layer not ready)
3.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出来事を示すでしょう。
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.
通常、リンクはモデムの断線の後に自動的にこのフェーズに戻るでしょう。 このフェーズはハード・ワイヤード線の場合は非常に不足するかもしれません--単に装置の存在を検出できるくらい長いです。
3.4 Link Establishment Phase
3.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.
Link Controlプロトコル(LCP)は、Configureパケットの交換を通して接続を証明するのに使用されます。 この交換は完全です、そして、LCP Opened状態に入りました、いったん、Configure-Ackパケット(以下で、説明される)を送って、受け取ると。
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-層のプロトコル段階の間、扱われます。
Any non-LCP packets received during this phase MUST be silently discarded.
静かにこの段階の間に受け取られたどんな非LCPパケットも捨てなければなりません。
3.5 Authentication Phase
3.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 mandatory. If an implementation desires that the peer authenticate with some specific authentication protocol, then it MUST negotiate the use of that authentication protocol during Link Establishment phase.
デフォルトで、認証は義務的ではありません。 実現であるなら、何かが特定の状態で同輩が認証を認証するという願望は議定書を作って、次に、それはLink特権階級段階の間、その認証プロトコルの使用を交渉しなければなりません。
Simpson [Page 9] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[9ページ]RFC1548のプロトコル1993年12月
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 authentication has completed, using the negotiated authentication protocol. If authentication fails, PPP SHOULD proceed instead to the Link Termination phase.
完成して、交渉された認証プロトコルを使用して、AuthenticationフェーズからNetwork-層のプロトコルフェーズまでの前進は認証が起こるまで起こってはいけません。 認証が失敗するなら、PPP SHOULDは代わりにLink Terminationフェーズに続きます。
Any Network Control Protocol or network-layer protocol packets received during this phase MUST be silently discarded.
静かにパケットがこの段階の間に受け取ったどんなNetwork Controlプロトコルやネットワーク層プロトコルも捨てなければなりません。
3.6 Network-Layer Protocol Phase
3.6 ネットワーク層プロトコルフェーズ
Once PPP has finished the previous phases, each network-layer protocol (such as IP, IPX, or AppleTalk) MUST be separately configured by the appropriate Network Control Protocol (NCP).
PPPがいったん前のフェーズを終えると、別々に、適切なNetwork Controlプロトコル(NCP)で各ネットワーク層プロトコル(IP、IPX、またはAppleTalkなどの)を構成しなければなりません。
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 MUST be silently discarded.
NCPがOpened状態に達した後に、PPPは対応するネットワーク層プロトコルパケットを運ぶでしょう。 静かに対応するNCPがOpened状態にないとき受け取られたどんなネットワーク層プロトコルパケットも捨てなければなりません。
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 protocols which are supported are silently
discarded.
先行のパラグラフへの例外がLCPプロトコル廃棄物(以下で、説明される)の有用性のためにあります。 LCPがOpened状態にある間、プロトコル廃棄物でどんな実現でサポートされないプロトコルパケットも返さなければなりません。 サポートされるプロトコルだけが静かに捨てられます。
During this phase, link traffic consists of any possible
combination of LCP, NCP, and network-layer protocol packets.
この段階の間、リンク交通はLCP、NCP、およびネットワーク層プロトコルパケットのどんな可能な組み合わせからも成ります。
3.7 Link Termination Phase
3.7 リンク終了段階
PPP can terminate the link at any time. This might happen because of
PPPはいつでも、リンクを終えることができます。 これは起こるかもしれません。
Simpson [Page 10] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[10ページ]RFC1548のプロトコル1993年12月
the loss of carrier, authentication failure, link quality failure, the expiration of an idle-period timer, or the administrative closing of the link. 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 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パケットの交換の後に、実現SHOULDは、リンクの終了を実施するために連絡を断つように物理的な層に合図します、特に認証失敗の場合で。 Terminate-Ackを受けるか、またはRestartが反対した後にSHOULDが外すTerminate-要求の送付者は呼吸が絶えます。 Terminate-Ackを送った後に、SHOULDが同輩が外すのを待っていて、少なくとも1Restart回まで外してはいけないTerminate-要求の受信機は通過しました。 PPP SHOULDはLink Deadフェーズに続きます。
Any non-LCP packets received during this phase MUST be silently discarded.
静かにこの段階の間に受け取られたどんな非LCPパケットも捨てなければなりません。
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 one NCP has Closed is not sufficient reason to cause
the termination of the PPP link, even if that NCP was the only NCP
currently in the Opened state.
LCPによるリンクの閉鎖は十分です。 各NCPがTerminateパケットの突風を送る必要は全くありません。 逆に、1つのNCPにはClosedがあるという事実はPPPリンクの終了を引き起こすことができるくらいの理由ではありません、そのNCPが現在Opened状態において唯一のNCPであったとしても。
4. The Option Negotiation Automaton
4. オプション交渉オートマトン
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-Started Close= administrative Close tlf = This-Layer-Finished
=に、下層はこの層が上昇しているUp tlu=Down=下層が終わっているこの管理この層が始動している管理下にこの層のDown tld=オープン=オープンtls=Close=Close tlf=層であるということです。
Simpson [Page 11] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[11ページ]RFC1548のプロトコル1993年12月
TO+ = Timeout with counter > 0 irc = Initialize-Restart-Counter TO- = Timeout with counter expired zrc = Zero-Restart-Counter
カウンタがある再開カウンタを初期化しているカウンタ>0irc=TO=タイムアウトを伴うTO+=タイムアウトは無Restartの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
コード廃棄物を受けているか(受入れられます)、またはReceiveが廃棄物について議定書の中で述べている未知のコードを受け取っている==コード廃棄物を送っているRUC scj RXJ+=RXJ=Receiveプロトコル廃棄物RXRがエコー要求を受け取っているser=とエコー回答を送った状態で等しいです、コード廃棄物を受けるか(壊滅的な)、Receiveが回答をまねます、Receiveは要求を捨てます。
4.1 State Diagram
4.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パケットを受けました。
Simpson [Page 12] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[12ページ]RFC1548のプロトコル1993年12月
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 13] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[13ページ]RFC1548のプロトコル1993年12月
4.2 State Transition Table
4.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; multiple actions may be implemented in any
convenient order. The state may be followed by a letter, which
indicates an explanatory footnote. The dash ('-') indicates an
illegal transition.
完全な状態遷移テーブルは続きます。 州は水平に示されます、そして、出来事は垂直に読まれます。 状態遷移と動作はフォームに新しい動作/状態で表されます。 複数の動作が、コンマによって切り離されて、スペースが必要であるように続く線の上で続くかもしれません。 複数の動作がどんな便利なオーダーでも実行されるかもしれません。 手紙は状態を支えるかもしれません。(それは、脚注を示します)。 ダッシュ('--')は不法な変遷を示します。
| 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 14] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[14ページ]RFC1548のプロトコル1993年12月
| 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 scj/9
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/8scj/9RXJ+| 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 is 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タイマは止められます。
[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イベント議論を見てください。
4.3 A Day in the Life
人生における1日あたり4.3
Here is an example of how a typical implementation might use the automaton to implement LCP in a dial-up environment:
ここに、典型的な実現がダイヤルアップ環境でLCPを実行するのにどうオートマトンを使用するかもしれないかに関する例があります:
- The Network Access Server is powered on (Initial state, Link Dead
phase).
- Network Access Serverは電源を入れられています(初期状態、Link Deadフェーズ)。
- A configuration file indicates that a particular link is to be
- 構成ファイルは、そのa特定のリンクがあるのを示します。
Simpson [Page 15] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[15ページ]RFC1548のプロトコル1993年12月
used for PPP access (Open: tls/Starting). The This-Layer-Started
event turns on DTR to a modem, readying it for accepting calls.
PPPアクセスに使用されて、(開いてください: tls/始め。)です。 呼び出しを受け入れるためにそれを準備して、This層が始動している出来事はDTRをモデムにつけます。
- An incoming call is answered. The modem CD triggers configuration
negotiation (Up: irc,scr/Req-Sent, Link Establishment phase).
- かかってきた電話は答えられます。 モデムCDは構成交渉(: ircへのscr/Reqによって送られたLink特権階級フェーズ)の引き金となります。
- A Configure-Request is received, which is acknowleged (RCR+:
sca/Ack-Sent).
- Configure-要求が受信されている、(acknowlegedされます)(RCR+:、sca/Ackによって送られる、)
- The Request is acknowleged (RCA: irc,tlu/Opened). The This-
Layer-Up event starts authentication and quality monitoring
protocols (Authentication phase).
- Requestはacknowlegedされます(RCA: ircの、そして、tlu/開かれた)。 認証と品質はThis上に層の出来事がプロトコル(認証フェーズ)をモニターし始めます。
- When authentication and quality monitoring are satisfied, they
send an Up event to start the available NCPs (Network-Layer
Protocol phase).
- 認証と上質のモニターが満足していて、彼らが利用可能なNCPを始めるためにUp出来事を送るということ(ネットワーク層のプロトコルフェーズ)であるときに。
- Later, the peer is finished, and closes the link. A Terminate-
Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase).
The This-Layer-Down action sends the Down event to any NCPs, while
the Terminate-Ack is sent. The Zero-Restart-Counter action causes
the link to wait for the peer to process the Terminate-Ack, with
no retries.
- その後、同輩は、終わって、リンクを閉じます。 Terminate要求は到着します(RTR: tld、zrc、Terminationが位相を合わせるsta/停止)。 This層がダウンしている動作はDown出来事をどんなNCPにも送りますが、Terminate-Ackを送ります。 Zero再開カウンタ動作で、リンクは、同輩が再試行なしでTerminate-Ackを処理するのを待ちます。
- When the Restart Timer times out (TO-: tlf/Stopped), the This-
Layer-Finished action signals the modem to hang up by dropping
DTR.
- (tlfであるか止まっているTO)からのRestart Timer回であるときに、Thisの層で終わっている動きは、DTRを落とすことによっての電話を切るようにモデムに示します。
- When the CD from the modem drops (Down: tls/Starting), the This-
Layer-Started action raises DTR again, readying it for the next
call (returning to the Link Dead phase).
- モデムからのCDが(下に: tls/始め)を落とすと、Thisの層で始められた動作は再びDTRを上げます、次の呼び出しのためにそれを準備して(Link Deadフェーズに戻って)。
4.4 States
4.4 州
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状態に遺伝していません。
Simpson [Page 16] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[16ページ]RFC1548のプロトコル1993年12月
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
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.
Downイベント応答(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を持っている専用回線、またはサーキットの役に立ちます。交換回線網には、使用されてください。
Simpson [Page 17] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[17ページ]RFC1548のプロトコル1993年12月
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
nor has one been sent.
Requestによって送られた状態では、接続を構成するのを試みをします。 Configure-要求を送りました、そして、まだConfigure-Ackを受け取っていません、そして、Restartタイマは動いていますが、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状態に遺伝していません。
Simpson [Page 18] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[18ページ]RFC1548のプロトコル1993年12月
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であると上側の層に合図します。
4.5 Events
4.5 出来事
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.
下層が、それがパケットを運ぶ準備ができているのを示すとき、Up出来事は起こります。
Typically, this event is used by a modem handling or calling
process, or by some other coupling of the PPP link to the physical
media, to signal LCP that the link is entering Link Establishment
phase.
通常、この出来事はモデム取り扱いか呼び出しプロセス、または物理的なメディアへのPPPリンクのある他のカップリングによって使用されて、リンクがLink特権階級フェーズに入っているとLCPに合図します。
It also can be used by LCP to signal each NCP that the link is
entering Network-Layer Protocol phase. That is, the This-Layer-Up
action from LCP triggers the Up event in the NCP.
また、LCPは、リンクがNetwork-層のプロトコルフェーズに入っていると各NCPに合図するのにそれを使用できます。 すなわち、LCPからのThisが上に層にしている動作はNCPにおけるUp出来事の引き金となります。
Down
下に
The Down event occurs when a lower layer indicates that it is no
longer ready to carry packets.
下層が、それがもうパケットを運ぶ準備ができていないのを示すとき、Down出来事は起こります。
Typically, this event is used by a modem handling or calling
process, or by some other coupling of the PPP link to the physical
media, to signal LCP that the link is entering Link Dead phase.
通常、この出来事はモデム取り扱いか呼び出しプロセス、または物理的なメディアへのPPPリンクのある他のカップリングによって使用されて、リンクがLink Deadフェーズに入っているとLCPに合図します。
It also can be used by LCP to signal each NCP that the link is
leaving Network-Layer Protocol phase. That is, the This-Layer-
Down action from LCP triggers the Down event in the NCP.
また、LCPは、リンクがNetwork-層のプロトコルをフェーズに残していると各NCPに合図するのにそれを使用できます。 すなわち、LCPからのThis下にを層にしている動作はNCPにおけるDown出来事の引き金となります。
Open
開いてください。
The Open event indicates that the link is administratively
available for traffic; that is, the network administrator (human
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出来事が完成していない、)、リンクの設立は自動的に遅れます。
Simpson [Page 19] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[19ページ]RFC1548のプロトコル1993年12月
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 is necessary.
Terminate-要求が受信されているか、またはリンクが入手できなくなる他の出来事が起こると、オートマトンはリンクが再開する準備ができている状態に進むでしょう。 どんな追加管理介入も必要ではありません。
Implementation Option:
実現オプション:
Experience has shown that users will execute an additional Open
command when they want to renegotiate the link. This might
indicate that new values are to be negotiated.
経験は、彼らがリンクを再交渉したがっているとき、ユーザが追加オープン命令を実行するのを示しました。 これは、新しい値が交渉されることであることを示すかもしれません。
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試みは否定されます。
Implementation Note:
実現注意:
When authentication fails, the link SHOULD be terminated, to
prevent attack by repetition and denial of service to other users.
Since the link is administratively available (by definition), this
can be accomplished by simulating a Close event to the LCP,
immediately followed by an Open event.
認証は失敗して、リンクはSHOULDです。いつ、終えられるか、そして、他のユーザに対するサービスの反復と否定で攻撃を防いでください。 リンクが行政上利用可能であるので(定義上)、オープン出来事がすぐにあとに続いたLCPへのClose出来事をシミュレートすることによって、これを達成できます。
The Close followed by an Open will cause an orderly termination of
the link, by progressing from the Closing to the Stopping state,
and the This-Layer-Finished action can disconnect the link. The
automaton waits in the Stopped or Starting states for the next
connection attempt.
オープンがあとに続いたCloseはClosingからStopping状態まで進歩をすることによって、リンクの規則的な終了を引き起こすでしょう、そして、This層が終わっている動作はリンクを外すことができます。 オートマトンはStoppedかStarting州で次の接続試みを待っています。
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-
TO+出来事は、Restartカウンタがずっとゼロ以上であることを示します。(それは、対応するConfigureの引き金となります)。
Simpson [Page 20] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[20ページ]RFC1548のプロトコル1993年12月
Request or Terminate-Request packet to be retransmitted.
要求か再送されるべき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
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-リクエスト・パケットを受け取るとき、この出来事は起こります。 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 SHOULD、登録されてください。
Simpson [Page 21] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[21ページ]RFC1548のプロトコル1993年12月
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リクエスト・パケットへの否定応答です。 順序が狂ってかそうでなさ、無効のパケットは静かに捨てられます。
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
拒絶された値が許容できるとき、RXJ+出来事が起こる、そのようなもの
Simpson [Page 22] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[22ページ]RFC1548のプロトコル1993年12月
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.
拡張コードの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
terminates the connection.
拒絶された値が壊滅的であるときに、RXJ出来事は起こります、Configure-要求のCode-廃棄物、またはLCPのプロトコル廃棄物などのように! この出来事は接続を終える回復不能エラーを伝えます。
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-リクエスト・パケットに関する回答が全くありません。
4.6 Actions
4.6 動作
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 cannot occur in a properly
implemented automaton. The implementation has an internal error,
which should be reported and logged. No transition is taken, and
the implementation SHOULD NOT reset or freeze.
これは適切に実行されたオートマトンに起こることができない出来事を示します。 実現には、内部エラーがあります。(それは、報告されて、登録されるべきです)。 どんな変遷も、取って実現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 is 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 network layer 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 is 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
この動作は通常、NCP、Authenticationプロトコル、またはLink QualityプロトコルへのDown出来事に合図するのにLCPによって使用されるか、またはNCPによって使用されて、リンクがもうそうであることを示すかもしれません。
Simpson [Page 23] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[23ページ]RFC1548のプロトコル1993年12月
available for its network layer traffic.
ネットワーク層交通に、利用可能です。
This-Layer-Started (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出来事で応じます。
Implementation Note:
実現注意:
This results of this action are highly implementation dependent.
この動作のこの結果は実現に非常に依存しています。
The transitions where this event is indicated are defined
according to a message passing architecture, rather than a
signalling architecture. If the action is desired to control
specific signals (such as DTR), other transitions for the action
are likely to be required (Open in Closed, RCR in Stopped).
合図構造よりむしろメッセージ・パッシング構造に従って、この出来事が示されるところで変遷は定義されます。 動作が特定の信号(DTRなどの)を制御することを望まれているなら、動作のための他の変遷が必要でありそうです(Closedで開いてください、StoppedのRCR)。
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に示すかもしれません。
Implementation Note:
実現注意:
This results of this action are highly implementation dependent.
この動作のこの結果は実現に非常に依存しています。
The transitions where this event is indicated are defined
according to a message passing architecture, rather than a
signalling architecture. If the action is desired to control
specific signals (such as DTR), other transitions for the action
are likely to be required (Close in Starting, Down in Closing).
合図構造よりむしろメッセージ・パッシング構造に従って、この出来事が示されるところで変遷は定義されます。 動作が特定の信号(DTRなどの)を制御することを望まれているなら、動作のための他の変遷が必要でありそうです(Starting、ClosingのDownで近い)。
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番目を含む各トランスミッション単位で減少します。
Simpson [Page 24] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[24ページ]RFC1548のプロトコル1993年12月
Implementation Note:
実現注意:
In addition to setting the Restart counter, the implementation
MUST set the timeout period to the initial value when Restart
timer backoff is used.
Restartカウンタを設定することに加えて、実現は初期の値へのRestartタイマbackoffが使用されているタイムアウト時間を決めなければなりません。
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, allowing traffic to be processed by the peer.
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-リクエスト・パケットのレセプションを承認します。
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
Sendが要求を終えている動作はTerminate-要求を伝えます。
Simpson [Page 25] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[25ページ]RFC1548のプロトコル1993年12月
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.
パケット。 これは接続を終える願望を示します。 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-リクエスト・パケットのレセプションを承認します。
4.7 Loop Avoidance
4.7 輪の回避
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実現を構成するのは可能です。 また、一点に集まりますが、そうするには重要な時間がかかる方針を構成するのも可能です。 作成者は念頭にこれを保つべきです、そして、SHOULDは輪の検出メカニズムか、より高い平らなタイムアウトを実行します。
4.8 Counters and Timers
4.8 カウンタとタイマ
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 SHOULD default to three (3) seconds.
オートマトンによって使用される1個の特別なタイマがあります。 RestartタイマはConfigure-要求とTerminateリクエスト・パケットの時間送信に使用されます。 Restartタイマの満了はTimeout出来事、および対応するConfigure-要求かTerminate-リクエスト・パケットの「再-トランスミッション」を引き起こします。 Restartタイマは構成可能であるに違いありませんが、SHOULDは3(3)秒をデフォルトとします。
Implementation Note:
実現注意:
The Restart timer SHOULD be based on the speed of the link. The
default value is designed for low speed (2,400 to 9,600 bps), high
RestartタイマSHOULDはリンクの速度に基づいたそうです。 デフォルト値は低速(2,400〜9,600ビーピーエス)のために高く設計されています。
Simpson [Page 26] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[26ページ]RFC1548のプロトコル1993年12月
switching latency links (typical telephone lines). Higher speed
links, or links with low switching latency, SHOULD have
correspondingly faster retransmission times.
切り換え潜在は(典型的な電話回線)をリンクします。 より高い速度リンク、または低い切り換え潜在とのリンク、SHOULDが対応するより速い「再-トランスミッション」時を過します。
Instead of a constant value, the Restart timer MAY begin at an
initial small value and increase to the configured final value.
Each successive value less than the final value SHOULD be at least
twice the previous value. The initial value SHOULD be large
enough to account for the size of the packets, twice the round
trip time for transmission at the link speed, and at least an
additional 100 milliseconds to allow the peer to process the
packets before responding. Some circuits add another 200
milliseconds of satellite delay. Round trip times for modems
operating at 14,400 bps have been measured in the range of 160 to
more than 600 milliseconds.
恒常価値の代わりに、Restartタイマは構成された検査値への初期の小さい値と増加で始まるかもしれません。 決勝より少ないそれぞれの連続した値は少なくとも前の2倍が値であったならSHOULDを評価します。 多大がトランスミッションのためのリンク速度における、少なくとも応じるパケットを処理するのを同輩を許容する追加100人のミリセカンドと同じくらいの前の時にパケットのサイズ、周遊旅行の2倍を説明するために十分であったなら、イニシャルはSHOULDを評価します。 いくつかのサーキットがもう200ミリセカンドの衛星遅れを加えます。 1万4400ビーピーエスで作動するモデムのための周遊旅行時間は160の範囲で600ミリセカンド以上まで測定されました。
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)への構成可能であるのにもかかわらずの、SHOULDデフォルトがトランスミッションであったに違いないならマックスと同じくらい終わってください。
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)への構成可能であるのにもかかわらずの、SHOULDデフォルトがトランスミッションであったに違いないなら、構成します。
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-廃棄物パケットに変換されます。 マックス-失敗は構成可能であるに違いありませんが、SHOULDは10(10)トランスミッションをデフォルトとします。
5. LCP Packet Formats
5. 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
1. そしてリンクConfigurationパケットがリンクを設立して、以前はよく構成していた、(要求を構成する、Configure-Ack、Configure-Nak。
Simpson [Page 27] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[27ページ]RFC1548のプロトコル1993年12月
Configure-Reject).
廃棄物を構成する、)
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 PPP 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の新しいバージョンが将来必要であるなら、意志は新しいPPPプロトコル分野価値が他のすべてのバージョンとバージョン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 as if no Configuration Options were enabled. This ensures that such LCP packets are always recognizable even when one end of the link mistakenly believes the link to be open.
どのConfiguration Optionsが有効にされるかにかかわらず、まるでConfiguration Optionsが全く有効にされないかのようにいつもすべてのLCP Link Configuration、Link Termination、およびCode-廃棄物パケット(1〜7に、コード化する)を送ります。 これはそのようなLCPパケットが確実にリンクの片端が、リンクが開いていると誤って信じるときさえ、いつも認識可能になるようにします。
Implementation Note:
実装注意:
In particular, the Async-Control-Character-Map (ACCM) default for
the type of link is used, and no address, control, or protocol
field compression is allowed.
リンクのタイプのためのAsync規制キャラクター地図(ACCM)デフォルトは特に、使用されています、そして、どんなアドレス、コントロールも、またはプロトコル分野圧縮も許されていません。
Exactly one LCP packet is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type hex c021 (Link
Control Protocol).
ちょうど1つのLCPパケットがPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野はタイプ十六進法c021を示します(Controlプロトコルをリンクしてください)。
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 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[28ページ]RFC1548のプロトコル1993年12月
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廃棄物パケットを伝えます。
Up-to-date values of the LCP Code field are specified in the most
recent "Assigned Numbers" RFC [2]. This specification concerns
the following values:
LCP Code分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 この仕様は以下の値に関係があります:
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
1 エコー・リプライ11が破棄して要求する要求を終えている要求を構成している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 are treated as
padding and are 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パケットの長さを示します。 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分野のそばで決定しています。
5.1 Configure-Request
5.1、要求を構成します。
Description
記述
An implementation wishing to open a connection MUST transmit a LCP
packet with the Code field set to 1 (Configure-Request), and the
そして接続を開く実装願望がCode分野セットで1(要求を構成している)にLCPパケットを伝えなければならない。
Simpson [Page 29] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[29ページ]RFC1548のプロトコル1993年12月
Options field filled with any desired changes to the link
defaults. Configuration Options SHOULD NOT be included with
default values.
リンクへのどんな必要な変化でも満たされたオプション分野はデフォルトとします。 構成Options SHOULD、デフォルト値で、含められないでください。
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 MUST be changed whenever the content of the
Options field changes, and whenever a valid reply has been
received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
Options分野の内容が変化するときはいつも、Identifier分野を変えなければなりません、そして、a有効であるときはいつも、前の要求のために回答を受け取りました。 「再-トランスミッション」に関しては、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の形式は後のセクションでさらに説明されます。
5.2 Configure-Ack
5.2、Ackを構成します。
Description
記述
If every Configuration Option received in a Configure-Request is
recognizable and all values are acceptable, then the
implementation MUST 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が認識可能であり、すべての値が許容できるなら、実装はCode分野セットで2(Ackを構成している)にLCPパケットを伝えなければなりません、そして、Identifier分野は受信されたConfigure-要求からコピーされました、そして、Options分野は受信されたConfigure-要求からコピーされました。 何らかの方法で承認されたConfiguration Optionsを再命令されてはいけないか、変更してはいけません。
Simpson [Page 30] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[30ページ]RFC1548のプロトコル1993年12月
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が同時に、いつも承認されます。
5.3 Configure-Nak
5.3、Nakを構成します。
Description
記述
If every element of the received Configuration Options is
recognizable but some values are not acceptable, then the
implementation MUST 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のあらゆる要素が認識可能ですが、いくつかの値が許容できないなら、実装はCode分野セットで3(Nakを構成している)にLCPパケットを伝えなければなりません、そして、Identifier分野は受信されたConfigure-要求からコピーされました、そして、Options分野はConfigure-要求から容認できないConfiguration Optionsだけで満ちました。 すべての許容できるConfiguration OptionsがConfigure-Nakからフィルターにかけられますが、さもなければ、Configure-要求からのConfiguration Optionsを再命令してはいけません。
Options which have no value fields (boolean options) MUST use the
分野(論理演算子オプション)が使用してはいけない値を全く持っているオプション
Simpson [Page 31] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[31ページ]RFC1548のプロトコル1993年12月
Configure-Reject reply instead.
代わりに廃棄物を構成している回答。
Each Configuration Option which is allowed only a single instance
MUST be modified to a value acceptable to the Configure-Nak
sender. The default value MAY be used, when this differs from the
requested value.
ただ一つのインスタンスだけが許容されている各Configuration OptionをConfigure-Nak送付者にとって、許容できる値に変更しなければなりません。 これが要求された値と異なっているとき、デフォルト値は使用されるかもしれません。
When a particular type of Configuration Option can be listed more
than once with different values, the Configure-Nak MUST include a
list of all values for that option which are acceptable to the
Configure-Nak sender. This includes acceptable values that were
present in the Configure-Request.
異価による一度よりConfiguration Optionの特定のタイプをもう少し記載できるとき、Configure-NakはそのオプションのためのすべてのConfigure-Nak送付者にとって、許容できる値のリストを含まなければなりません。 これはConfigure-要求に存在している許容値を含んでいます。
Finally, an implementation may be configured to request the
negotiation of a specific Configuration Option. If that option is
not listed, then that option MAY be appended to the list of Nak'd
Configuration Options in order to prompt the peer to include that
option in its next Configure-Request packet. Any value fields for
the option MUST indicate values acceptable to the Configure-Nak
sender.
最終的に、実装は、特定のConfiguration Optionの交渉を要求するために構成されるかもしれません。 そのオプションが記載されていないなら、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. When multiple
instances of a Configuration Option are present, the peer SHOULD
select a single value to include in its next Configure-Request
packet.
有効なConfigure-Nakのレセプションは、Configure-Nakで指定されるようにConfiguration Optionsが変更されている状態で新しいConfigure-要求が送られるかもしれないのを示します。 Configuration Optionの複数のインスタンスが存在しているとき、SHOULDが、ただ一つの値が次の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の長さを扱うことができなければなりません。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Simpson [Page 32] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[32ページ]RFC1548のプロトコル1993年12月
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は同時に、そうするでしょう。
5.4 Configure-Reject
5.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 the implementation
MUST 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が認識可能でないか、または交渉において、許容できないなら(ネットワーク管理者によって構成されるように)、実装は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要求におけるそれらの真部分集合であるに違いありません。 無効のパケットは静かに捨てられます。
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-廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
Simpson [Page 33] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[33ページ]RFC1548のプロトコル1993年12月
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が同時に、いつも拒絶されます。
5.5 Terminate-Request and Terminate-Ack
5.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.
接続SHOULDを閉じるLCP実装願望はCode分野セットで5(要求を終えている)にLCPパケットを伝えます、そして、Data分野はどんな必要なデータでも満ちました。 リクエスト・パケットを終えているSHOULDは、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
Terminate-要求とTerminate-Ackパケット・フォーマットの概要
Simpson [Page 34] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[34ページ]RFC1548のプロトコル1993年12月
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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
識別子
On transmission, the Identifier field MUST be changed whenever the
content of the Data field changes, and whenever a valid reply has
been received for a previous request. For retransmissions, the
Identifier MAY remain unchanged. On reception, the Identifier
field of the Terminate-Request is copied into the Identifier field
of the Terminate-Ack packet.
トランスミッションのときに、Data分野の内容が変化するときはいつも、Identifier分野を変えなければならなくて、a有効であるときはいつも、前の要求のために回答を受け取りました。 「再-トランスミッション」に関しては、Identifierは変わりがないかもしれません。 レセプションでは、Terminate-要求のIdentifier分野はTerminate-AckパケットのIdentifier分野にコピーされます。
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
MRU minus four.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した同輩のMRUまで4を引いたどんな長さのものであるかもしれません。
5.6 Code-Reject
5.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は誤りを報告します、自動的に事態を収拾できるのがありそうもないので。
Simpson [Page 35] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[35ページ]RFC1548のプロトコル1993年12月
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 MUST be changed for each Code-Reject sent.
送られた各Code-廃棄物のためにIdentifier分野を変えなければなりません。
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 Data Link Layer headers nor an FCS. The
Rejected-Information MUST be truncated to comply with the peer's
established MRU.
Rejected-情報フィールドは拒絶されているLCPパケットのコピーを含んでいます。 それは、情報分野で始まって、どんなData Link Layerヘッダーも含んでいません。または、FCS。 同輩の確立したMRUに従うためにRejected-情報に先端を切らせなければなりません。
5.7 Protocol-Reject
5.7 プロトコル廃棄物
Description
記述
Reception of a PPP packet with an unknown Protocol field 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.
未知のプロトコル分野があるPPPパケットのレセプションは、同輩が、サポートされないプロトコルを使用するのを試みているのを示します。 同輩が、新しいプロトコルを構成するのを試みるとき、通常、これは起こります。 LCP州のマシンがOpened状態にあるなら、この誤りは同輩へのCode分野セットで8(プロトコル廃棄物)にLCPパケットを伝えるのによる報告された後部、容認されたプロトコルに設定されたRejected-プロトコル分野、および誘発がRejected-情報フィールドにコピーされたパケットであったならそうしなければなりません。
Upon reception of a Protocol-Reject, the implementation MUST stop
sending packets of the indicated protocol at the earliest
opportunity.
プロトコル廃棄物のレセプションでは、実装は、できるだけ早い機会に示されたプロトコルのパケットを送るのを止めなければなりません。
Protocol-Reject packets can 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を除いて、いずれにも受け取られたプロトコル廃棄物パケットは、静かに捨てられるように述べます。
Simpson [Page 36] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[36ページ]RFC1548のプロトコル1993年12月
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 MUST be changed for each Protocol-Reject
sent.
送られたそれぞれのプロトコル廃棄物のためにIdentifier分野を変えなければなりません。
Rejected-Protocol
拒絶されたプロトコル
The Rejected-Protocol field is two octets and contains the PPP
Protocol field of the packet which is being rejected.
Rejected-プロトコル分野は、2つの八重奏であり、拒絶されているパケットのPPPプロトコル分野を含んでいます。
Rejected-Information
拒絶された情報
The Rejected-Information field contains a copy of the packet which
is being rejected. It begins with the Information field, and does
not include any Data Link Layer headers nor an FCS. The
Rejected-Information MUST be truncated to comply with the peer's
established MRU.
Rejected-情報フィールドは拒絶されているパケットのコピーを含んでいます。 それは、情報分野で始まって、どんなData Link Layerヘッダーも含んでいません。または、FCS。 同輩の確立したMRUに従うためにRejected-情報に先端を切らせなければなりません。
5.8 Echo-Request and Echo-Reply
5.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 (if any) inserted, and the Data field filled with any
desired data, but not exceeding the peer's established MRU minus
eight.
Echo-要求送付者は9(エコー要求)に設定されたCode分野、地方のマジック数(もしあれば)が指し込んだIdentifier分野セットでLCPパケットを伝えます、そして、Data分野はどんな必要なデータでも満ちましたが、同輩を超えていないと、MRUは8を引いて創業しました。
Simpson [Page 37] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[37ページ]RFC1548のプロトコル1993年12月
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 (if any) inserted, and the Data field copied from the
Echo-Request, truncating as necessary to avoid exceeding the
peer's established MRU.
Echo-要求のレセプションでは、10(エコー回答)に設定されたCode分野、受信されたEcho-要求からコピーされたIdentifier分野、挿入された地方のマジック数(もしあれば)、および同輩の確立したMRUを超えているのを避けるために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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
9 for Echo-Request;
9 エコー要求のために。
10 for Echo-Reply.
10 エコー・リプライのために。
Identifier
識別子
On transmission, the Identifier field MUST be changed whenever the
content of the Data field changes, and whenever a valid reply has
been received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
トランスミッションのときに、Data分野の内容が変化するときはいつも、Identifier分野を変えなければならなくて、a有効であるときはいつも、前の要求のために回答を受け取りました。 「再-トランスミッション」に関しては、Identifierは変わりがないかもしれません。
On reception, the Identifier field of the Echo-Request is copied
into the Identifier field of the Echo-Reply packet.
レセプションでは、Echo-要求のIdentifier分野はEcho-回答パケットのIdentifier分野にコピーされます。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number
Configuration Option for further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 マジック数のConfiguration Optionが首尾よく交渉されるまで、ゼロとしてマジック数を伝えなければなりません。 詳細な説明のマジック数のConfiguration Optionを見てください。
Simpson [Page 38] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[38ページ]RFC1548のプロトコル1993年12月
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
MRU minus eight.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した同輩のMRUまで8を引いたどんな長さのものであるかもしれません。
5.9 Discard-Request
5.9は破棄して要求します。
Description
記述
LCP includes a Discard-Request Code in order to provide a Data
Link Layer 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を含んでいます。 これはデバッグにおける援助、機能をテストして他の多数の機能のための性能として役に立ちます。
The sender transmits a LCP packet with the Code field set to 11
(Discard-Request), the Identifier field set, the local Magic-
Number (if any) inserted, and the Data field filled with any
desired data, but not exceeding the peer's established MRU minus
eight.
送付者は11(破棄して要求する)に設定されたCode分野、地方のマジック数(もしあれば)が指し込んだIdentifier分野セットでLCPパケットを伝えます、そして、Data分野はどんな必要なデータでも満ちましたが、同輩を超えていないと、MRUは8を引いて創業しました。
Discard-Request packets may only be sent in the LCP Opened state.
On reception, the receiver MUST simply throw away any Discard-
Request that it receives.
LCP Opened状態でRequestを捨てているパケットを送るだけであるかもしれません。 レセプションでは、受信機は単に、受信するというどんなDiscard要求も無駄にしなければなりません。
A summary of the Discard-Request packet format 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 MUST be changed for each Discard-Request
sent.
送られた各Discard-要求単位でIdentifier分野を変えなければなりません。
Simpson [Page 39] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[39ページ]RFC1548のプロトコル1993年12月
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. 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
MRU minus four.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した同輩のMRUまで4を引いたどんな長さのものであるかもしれません。
6. LCP Configuration Options
6. LCP設定オプション
LCP Configuration Options allow negotiation of modifications to the default characteristics of a point-to-point link. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
LCP Configuration Optionsはポイントツーポイント接続のデフォルトの特性への変更の交渉を許します。 Configuration OptionがConfigure-リクエスト・パケットに含まれていないなら、そのConfiguration Optionのためのデフォルト値は想定されます。
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 description. (None of the Configuration Options in this specification can be listed more than once.)
いくつかのConfiguration Optionsが一度よりもう少し記載されているかもしれません。 この効果は、Configuration Option特有であり、そのようなそれぞれのConfiguration Option記述で指定されます。 (一度よりこの仕様によるConfiguration Optionsのどれかをもう少し記載できません。)
The end of the list of Configuration Options is indicated by the length of the LCP packet.
Configuration Optionsのリストの終わりはLCPパケットの長さによって示されます。
Unless otherwise specified, all Configuration Options apply in a half-duplex fashion; typically, in the receive direction of the link from the point of view of the Configure-Request sender.
別の方法で指定されない場合、すべてのConfiguration Optionsが半二重ファッションで適用します。 通常と中、Configure-要求送付者の観点からリンクの方向を受けてください。
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. Up-to-date values of the LCP Option Type
field are specified in the most recent "Assigned Numbers" RFC [2].
Type分野は、1つの八重奏であり、Configuration Optionのタイプを示します。 LCP Option Type分野の最新の値は最新の「規定番号」RFC[2]で指定されます。
Simpson [Page 40] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[40ページ]RFC1548のプロトコル1993年12月
This specification concerns the following values:
この仕様は以下の値に関係があります:
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 information specific to
the Configuration Option. The format and length of the Data field
is determined by the Type and Length fields.
Data分野がゼロであるか以上は、Configuration Optionに特定の八重奏と情報です。 Data分野の形式と長さはTypeとLength分野のそばで決定しています。
6.1 Maximum-Receive-Unit
6.1 最大はユニットを受けます。
Description
記述
This Configuration Option may be sent to inform the peer that the
implementation can receive larger packets, or to request that the
peer send smaller packets.
実装が、より大きいパケットを受けることができることを同輩に知らせるか、または同輩が、より小さいパケットを送るよう要求するためにこのConfiguration Optionを送るかもしれません。
The default value is 1500 octets. If smaller packets are
requested, an implementation MUST still be able to receive the
full 1500 octet information field in case link synchronization is
lost.
デフォルト値は1500の八重奏です。 より小さいパケットが要求されるなら、リンク同期が無くなるといけないので、実装はまだ完全な1500八重奏情報フィールドを受けることができなければなりません。
Implementation Note:
実装注意:
This option is used to indicate an implementation capability. The
peer is not required to maximize the use of the capacity. For
example, when a MRU is indicated which is 2048 octets, the peer is
not required to send any packet with 2048 octets. The peer need
not Configure-Nak to indicate that it will only send smaller
packets, since the implementation will always require support for
at least 1500 octets.
このオプションは、実装能力を示すのに使用されます。 同輩は容量の使用を最大にする必要はありません。 MRUが示されるとき、(2048の八重奏です)例えば、同輩は2048の八重奏と共にどんなパケットも送る必要はありません。 実装以来、より小さいパケットを送るだけであるのを示すどんな同輩の必要性Configure-Nakも少なくとも1500の八重奏にいつも支持を要するというわけではないでしょう。
Simpson [Page 41] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[41ページ]RFC1548のプロトコル1993年12月
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 specifies the
maximum number of octets in the Information and Padding fields.
It does not include the framing, Protocol field, FCS, nor any
transparency bits or bytes.
Maximumがユニットを受けている分野は、2つの八重奏であり、情報とPadding分野の八重奏の最大数を指定します。 それはどんな縁どりや、プロトコル分野や、FCSと、透明ビットやバイトも含んでいません。
6.2 Async-Control-Character-Map
6.2 Async規制キャラクター地図
Description
記述
This Configuration Option provides a method to negotiate the use
of control character transparency on asynchronous links.
このConfiguration Optionは非同期なリンクにおける制御文字透明の使用を交渉するメソッドを提供します。
For asynchronous links, the default value is 0xffffffff, which
causes all octets less than 0x20 to be mapped into an appropriate
two octet sequence. For most other links, the default value is 0,
since there is no need for mapping.
非同期なリンクに関しては、デフォルト値は0xffffffffです。(その0xffffffffは適切な2八重奏系列に写像するべき0×20をすべての八重奏に引き起こします)。 他のほとんどのリンクに関しては、マッピングの必要は全くないので、デフォルト値は0です。
However, it is rarely necessary to map all control characters, and
often it is unnecessary to map any control characters. The
Configuration Option is used to inform the peer which control
characters MUST remain mapped when the peer sends them.
しかしながら、すべての制御文字を写像するのはめったに必要でなく、しばしば、どんな制御文字も写像するのは不要です。 Configuration Optionは、どの制御文字が同輩がそれらを送るとき、写像されたままで残らなければならないかを同輩に知らせるのに使用されます。
The peer MAY still send any other octets in mapped format, if it
is necessary because of constraints known to the peer. The peer
SHOULD Configure-Nak with the logical union of the sets of mapped
octets, so that when such octets are spuriously introduced they
can be ignored on receipt.
同輩は写像している形式でまだいかなる他の八重奏も送るかもしれません、それが同輩にとって知られている規制のために必要であるなら。 写像している八重奏のセットの論理的な組合がある同輩SHOULD Configure-Nakによって、そのような八重奏が偽って導入されたそれらであるときに、領収書の上でそれを無視できます。
Simpson [Page 42] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[42ページ]RFC1548のプロトコル1993年12月
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
Length
長さ
6
6
Async-Control-Character-Map
Async規制キャラクター地図
The Async-Control-Character-Map field is four octets and indicates
the set of control characters to be mapped. The map is sent most
significant octet first.
Async規制キャラクター地図分野は、写像されるために4つの八重奏であり、制御文字のセットを示します。 最初に、最も重要な八重奏を地図に送ります。
Each numbered bit corresponds to the octet of the same value. If
the bit is cleared to zero, then that octet need not be mapped.
If the bit is set to one, then that octet MUST remain mapped. For
example, if bit 19 is set to zero, then the ASCII control
character 19 (DC3, Control-S) MAY be sent in the clear.
それぞれの番号付のビットは同じ価値の八重奏に対応しています。 ビットがゼロまできれいにされるなら、その八重奏は写像される必要はありません。 ビットが1つに設定されるなら、その八重奏は写像されたままで残らなければなりません。 例えば、ビット19をゼロに設定するなら、明確でASCII制御文字19(DC3、Control-S)を送るかもしれません。
Note: 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.
以下に注意してください。 最も重要でない八重奏(最終的な八重奏は伝わった)の最下位ビットは、番号付のビット0であり、NULをASCII制御文字に写像するでしょう。
6.3 Authentication-Protocol
6.3 認証プロトコル
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 method to negotiate the use
of a specific authentication protocol. By default, authentication
is not required.
このConfiguration Optionは特定の認証プロトコルの使用を交渉するメソッドを提供します。 デフォルトで、認証は必要ではありません。
Simpson [Page 43] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[43ページ]RFC1548のプロトコル1993年12月
An implementation MUST 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 Configure-Nak'd, then the
implementation SHOULD attempt the next most desirable protocol in
the next Configure-Request.
実装はConfigure-リクエスト・パケットに複数のAuthenticationプロトコルConfiguration Optionsを含んではいけません。 代わりにそれ、SHOULDは、最初に最も望ましいプロトコルを構成するのを試みます。 そのプロトコルがそうなら、Configure-Nakは試みて、次に、実装SHOULDは次の次の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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
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 Protocol field values for that same
authentication protocol.
Authentication-プロトコル分野は、2つの八重奏であり、認証プロトコルが望んでいたのを示します。 この分野への値はその同じ認証のためのPPPプロトコル分野値が議定書を作るのといつも同じです。
Up-to-date values of the Authentication-Protocol field are
specified in the most recent "Assigned Numbers" RFC [2]. Current
values are assigned as follows:
Authentication-プロトコル分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
Simpson [Page 44] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[44ページ]RFC1548のプロトコル1993年12月
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分野は、ゼロか、より多くの八重奏であり、特定のプロトコルで決定するように追加データを含んでいます。
6.4 Quality-Protocol
6.4 上質のプロトコル
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 method 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
Simpson [Page 45] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[45ページ]RFC1548のプロトコル1993年12月
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 Protocol field values for that same
monitoring protocol.
Quality-プロトコル分野は、2つの八重奏であり、上質のモニターしているプロトコルが望んでいたリンクを示します。 この分野への値はPPPプロトコル分野がその同じモニターしているプロトコルのために評価するのといつも同じです。
Up-to-date values of the Quality-Protocol field are specified in
the most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows:
Quality-プロトコル分野の最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
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分野は、ゼロか、より多くの八重奏であり、特定のプロトコルで決定するように追加データを含んでいます。
6.5 Magic-Number
6.5 マジックナンバー
Description
記述
This Configuration Option provides a method 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 Quality-Protocol Configuration Option. By default, the
Magic-Number is not negotiated, and zero is inserted where a
Magic-Number might otherwise be used.
このConfiguration Optionは輪にされて逆リンクと他のData Link Layer例外を検出するメソッドを提供します。 このConfiguration OptionはQuality-プロトコル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.
マジック数のConfiguration Optionと共にConfigure-要求を受け取るとき、同輩に送る最後のConfigure-要求のマジック数に容認されたマジック数をたとえます。
Simpson [Page 46] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[46ページ]RFC1548のプロトコル1993年12月
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
MUST 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 (that is, until a Configure-
Nak is received or the Restart timer runs out).
2つのマジック番号が異なるなら、リンクは、輪にされた後部と、またはマジック数のSHOULDではありません。承認されます。 2つのマジック番号が等しいなら、可能ですが、確かでない、リンクが-逆で輪にされて、このConfigure-要求が最後に実際にものであることは発信しました。 これを決定するために、Configure-Nakに異なったマジック数の値を指定させなければなりません。 A新しい、SHOULD NOTが正常処理でそれを送るだろうまで(すなわち、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 MUST be chosen. In either case, a new Configure-
Request SHOULD be sent with the new Magic-Number.
同輩に送られた最後のConfigure-Nakのものと異なったマジック数があるConfigure-Nakのレセプションは、リンクが-逆で輪にされないと立証して、ユニークなマジック数を示します。 マジック数が最後のConfigure-Nakで送られたものと等しいなら、輪にされて逆リンクの可能性は増強されます、そして、新しいマジック数を選ばなければなりません。 どちらかでは、ケース、新しいConfigureは、SHOULDが新しいマジック数と共に送られるよう要求します。
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
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:
リンクが本当に-逆で輪にされると、この系列(Configure-要求を送信してください、そして、Configure-要求を受け取ってください、そして、Configure- Nakを送信してください、そして、Configure-Nakを受ける)は再三再び繰り返すでしょう。 リンクが-逆で輪にされないなら、この系列は数回起こるかもしれませんが、それは繰り返して非常に起こりそうにはありません。 おそらく、系列を終えると、どちらの終わりにも選ばれたマジック数は急速に分岐するでしょう。 以下のテーブルは衝突が、リンクの両端が完全に一定の分配があるマジック数を選択すると仮定するという確率を示しています:
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 it receives 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
実装がマジック数のConfiguration OptionとのConfigure-要求を伝えるなら、マジック数のConfiguration OptionとのConfigure-要求を受け取るなら、それはConfigure-廃棄物で応じてはいけません。 マジック民数記を使用する実装願望であるなら、それはまたそれが同輩を許容しなければならないその時です。
Simpson [Page 47] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[47ページ]RFC1548のプロトコル1993年12月
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).
そうしてください。 実装がConfigure-要求に対応してConfigure-廃棄物を受けるなら、それは、リンクが-逆で輪にされないで、また同輩がマジック数を使用しないことを意味できるだけです。 この場合まるで交渉がうまくいったかのように(まるで代わりにConfigure-Ackを受けたかのように)SHOULDが活動させる実装。
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. 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 a Magic-Number. Reception of a
Magic-Number field equal to the negotiated local 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.
これらのマジックナンバーフィールドパケットSHOULD、レセプションで点検されてください。 すべての容認されたマジックナンバーフィールドがゼロか同輩のユニークなマジック番号のどちらかと等しいに違いありません、同輩がマジック数を交渉したかどうかによって。 交渉された地方のマジック数と等しいマジックナンバーフィールドのレセプションは輪にされて逆リンクを示します。 同輩が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)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Simpson [Page 48] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[48ページ]RFC1548のプロトコル1993年12月
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はそうするでしょう。
6.6 Protocol-Field-Compression
6.6 プロトコル分野圧縮
Description
記述
This Configuration Option provides a method to negotiate the
compression of the PPP Protocol field. By default, all
implementations MUST transmit packets with two octet PPP Protocol
fields.
このConfiguration OptionはPPPプロトコル分野の圧縮を交渉するメソッドを提供します。 デフォルトで、すべての実装が2つの八重奏PPPプロトコル分野でパケットを伝えなければなりません。
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.
PPPプロトコル分野番号は、2八重奏フォームから明確に区別可能なただ一つの八重奏フォームにいくつかの値を圧縮できるように選ばれています。 実装がそのようなただ一つの八重奏プロトコル野原を受けることができることを同輩に知らせるためにこの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 binary 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つの2進法表示を(考えてください)」通知。
When using low speed links, it is desirable to conserve bandwidth
by sending as little redundant data as possible. The Protocol-
Field-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 packets are compressible since data
低速リンクを使用するとき、できるだけ少ししか冗長データを送らないことによって帯域幅を保存するのは望ましいです。 プロトコル分野圧縮Configuration Optionは実装の簡単さと帯域幅効率の間のトレードオフを許容します。 首尾よく交渉されるなら、3309年のISO拡張機能は、2の代わりに1つの八重奏にプロトコル分野を圧縮するのに使用されるかもしれません。 データ以来パケットの大多数は圧縮性です。
Simpson [Page 49] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[49ページ]RFC1548のプロトコル1993年12月
protocols are typically assigned with Protocol field values less
than 256.
プロトコルはプロトコル分野値256で通常割り当てられます。
Compressed Protocol fields MUST NOT be transmitted unless this
Configuration Option has been negotiated. When negotiated, PPP
implementations MUST accept PPP packets with either double-octet
or single-octet Protocol fields, and MUST NOT distinguish between
them.
このConfiguration Optionが交渉されていない場合、圧縮されたプロトコル野原を伝えてはいけません。 交渉されると、PPP実装は、二重八重奏の、または、ただ一つの八重奏のプロトコル分野でPPPパケットを受け入れなければならなくて、それらを見分けてはいけません。
The Protocol field is never compressed when sending any LCP
packet. This rule guarantees unambiguous recognition of LCP
packets.
どんなLCPパケットも送るとき、プロトコル分野は決して圧縮されません。 この規則はLCPパケットの明白な認識を保証します。
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
6.7 Address-and-Control-Field-Compression
6.7 アドレスとコントロール分野圧縮
Description
記述
This Configuration Option provides a method 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 appropriate to the link framing.
このConfiguration OptionはData Link Layer AddressとControl分野の圧縮を交渉するメソッドを提供します。 デフォルトで、すべての実装がリンク縁どりに適切なAddressとControl分野があるフレームを伝えなければなりません。
Since these fields usually have constant values for point-to-point
links, they are easily compressed. This Configuration Option is
sent to inform the peer that the implementation can receive
compressed Address and Control fields.
これらの分野にはポイントツーポイント接続への恒常価値が通常あるので、それらが容易に圧縮されます。 実装が圧縮されたAddressとControl野原を受けることができることを同輩に知らせるためにこのConfiguration Optionを送ります。
Simpson [Page 50] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[50ページ]RFC1548のプロトコル1993年12月
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8
8
Length
長さ
2
2
A. LCP Recommended Options
A。 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制御文字地図マジックナンバーアドレスと制御フィールド圧縮プロトコル分野圧縮
Security Considerations
セキュリティ問題
Security issues are briefly discussed in sections concerning the Authentication Phase, the Close event, and the Authentication-
安全保障問題は、Authentication Phase、Closeイベントに関してセクションで簡潔に議論していてAuthenticationです。
Simpson [Page 51] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[51ページ]RFC1548のプロトコル1993年12月
Protocol Configuration Option. Further discussion is in a companion document entitled PPP Authentication Protocols.
設定オプションについて議定書の中で述べてください。 さらなる議論がPPP Authenticationプロトコルと題する仲間ドキュメントにあります。
References
参照
[1] Perkins, D., "Requirements for an Internet Standard
Point-to-Point Protocol", RFC 1547, December 1993.
[1] パーキンス、D.、「インターネットの標準の二地点間プロトコルのための要件」、RFC1547、1993年12月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
Acknowledgments
承認
Much of the text in this document is taken from the WG Requirements, 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 (Network Systems), Karl Fox (Morning Star Technologies), Phill Gross (AN&S), former WG chair Russ Hobby (UC Davis), David Kaufman (Proteon), former WG chair Steve Knowles (FTP Software), former WG chair Brian Lloyd (L&A), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), former WG chair Drew Perkins (Fore), Greg Satz (cisco systems), John Shriver (Proteon), Vernon Schryver (Silicon Graphics), and Asher Waldfogel (Wellfleet).
Pointからポイントへのプロトコルを開発するのを助けるのに多くの人々が重要な時間を費やしました。 人々の全リストは記載できないくらい非常に多いのですが、以下の人々は特別な感謝に値します: リック・アダムス(UUNET)、ケン・エーデルマン(TGV)、フレッドベイカー(ACC)、マイク・バラード(テレビット)クレイグフォックス(ネットワークSystems)、カールフォックス(朝のStar Technologies)、フィルGross(AN&S)、元WGはラスHobby(UCデイヴィス)をまとめます、デヴィッド・コーフマン(Proteon)、WG元スティーブ・ノウルズ議長(FTP Software); 元WGいすブライアンロイド(L&A)(ジョンLoVerso(Xylogics))ビルMelohn(サン・マイクロシステムズ)、マイク・パットン(MIT)、元WGはドリュー・パーキンス(前面)、グレッグSatz(コクチマスシステム)、ジョン・シュライバー(Proteon)、ヴァーノンSchryver(シリコングラフィックス)、およびアシャーWaldfogel(Wellfleet)をまとめます。
The "Day in the Life" example was instigated by Kory Hamzeh (Avatar). In this version, improvements in wording were also provided by Scott Ginsburg, Mark Moraes, and Timon Sloan, as they worked on implementations.
「寿命における日」例はコーリーHamzeh(アバター)によって扇動されました。 また、このバージョンに、言葉遣いにおける改良はスコット・ギンズバーグ、マーク・モラエス、およびタイモン・スローンによって提供されました、実装に取り組んだので。
Special thanks to Morning Star Technologies for providing computing resources and network access support for writing this specification.
コンピューティング資源とネットワークアクセスを提供するためのMorning Star Technologiesへの特別な感謝は書くことのためにこの仕様をサポートします。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California, 93111
Driveサンタバーバラ、フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollayカリフォルニア 93111
EMail: fbaker@acc.com
メール: fbaker@acc.com
Simpson [Page 52] RFC 1548 The Point-to-Point Protocol December 1993
二地点間シンプソン[52ページ]RFC1548のプロトコル1993年12月
Editor's Address
エディタのアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
EMail: Bill.Simpson@um.cc.umich.edu
メール: Bill.Simpson@um.cc.umich.edu
Simpson [Page 53]
シンプソン[53ページ]
一覧
スポンサーリンク
