RFC1134 日本語訳
1134 Point-to-Point Protocol: A proposal for multi-protocoltransmission of datagrams over Point-to-Point links. D. Perkins. November 1989. (Format: TXT=87352 bytes) (Obsoleted by RFC1171) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Perkins
Request for Comments: 1134 CMU
November 1989
コメントを求めるワーキンググループD.パーキンス要求をネットワークでつないでください: 1134 米カーネギーメロン大学1989年11月
The Point-to-Point Protocol: A Proposal for Multi-Protocol
Transmission of Datagrams Over Point-to-Point Links
二地点間プロトコル: ポイントツーポイント接続の上のデータグラムのマルチプロトコル送信のための提案
Table of Contents
目次
Status of this Memo ................................... 2 Abstract .............................................. 2 1. Introduction ....................................... 2 1.1 Motivation ........................................ 2 1.2 Overview of PPP ................................... 3 1.3 Organization of the document ...................... 4 2. Physical Layer Requirements ........................ 4 3. The Data Link Layer ................................ 4 3.1 Frame Format ...................................... 5 4. The PPP Link Control Protocol (LCP) ................ 8 4.1 The LCP Automaton ................................. 9 4.1.1 Overview ........................................ 9 4.1.2 State Diagram ................................... 10 4.1.3 State Transition Table .......................... 12 4.1.4 Events .......................................... 12 4.1.5 Actions ......................................... 14 4.1.6 States .......................................... 16 4.2 Loop Avoidance .................................... 19 4.3 Packet Format ..................................... 19 4.3.1 Configure-Request ............................... 21 4.3.2 Configure-Ack ................................... 21 4.3.3 Configure-Nak ................................... 22 4.3.4 Configure-Reject ................................ 24 4.3.5 Terminate-Request and Terminate-Ack ............. 25 4.3.6 Code-Reject ..................................... 26 4.3.7 Protocol-Reject ................................. 27 4.3.8 Echo-Request and Echo-Reply ..................... 28 4.3.9 Discard-Request ................................. 29 4.4 Configuration Options ............................. 30 4.4.1 Format .......................................... 31 5. A PPP Network Control Protocol (NCP) for IP ........ 32 5.1 Sending IP Datagrams .............................. 33 APPENDICES ............................................ 33 A. Asynchronous HDLC .................................. 33 B. Fast Frame Check Sequence (FCS) Implementation ..... 35 B.1 FCS Computation Method ............................ 35 B.2 Fast FCS table generator .......................... 36
このMemoの状態… 2要約… 2 1. 序論… 2 1.1動機… 2 pppの1.2概要… 3 1.3 ドキュメントの組織… 4 2. 物理的な層の要件… 4 3. データ・リンク層… 4 3.1 形式を縁どってください… 5 4. pppは制御プロトコル(LCP)をリンクします… 8 4.1 LCPオートマトン… 9 4.1 .1概要… 9 4.1 .2 ダイヤグラムを述べてください… 10 4.1 .3 変遷テーブルを述べてください… 12 4.1 .4のイベント… 12 4.1 .5の動作… 14 4.1 .6 述べます。 16 4.2 回避を輪にしてください… 19 4.3 パケット形式… 19 4.3 .1 要求を構成します… 21 4.3 .2 Ackを構成します… 21 4.3 .3 Nakを構成します… 22 4.3 .4 廃棄物を構成します… 24 4.3 .5 要求を終えてAckを終えます… 25 4.3 .6コード廃棄物… 26 4.3 .7プロトコル廃棄物… 27 4.3 .8のエコー要求とエコー・リプライ… 28 4.3 .9 …を破棄して要求してください… 29 4.4 構成オプション… 30 4.4 .1 形式… 31 5. pppネットワークはIPのためにプロトコル(NCP)を制御します… 32 5.1 IPデータグラムを送ります… 33個の付録… 33 A.の非同期なHDLC… 33B.の速いフレームチェックシーケンス(FCS)実装… 35B.1 FCS計算メソッド… 35 B.2の速いFCSはジェネレータをテーブルの上に置きます… 36
Perkins [Page 1] RFC 1134 PPP November 1989
パーキンス[1ページ]RFC1134ppp1989年11月
REFERENCES ............................................ 37 AUTHOR'S ADDRESS ...................................... 38
参照… 37作者のアドレス… 38
Status of this Memo
このMemoの状態
This memo defines a proposed protocol for the Internet community.
このメモはインターネットコミュニティのために提案されたプロトコルを定義します。
This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. Distribution of this memo is unlimited.
この提案はPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 1990年1月15日までにIETF Pointからポイントへのプロトコル作業部会いすにこのメモのコメントを提出するべきです。 コメントは標準の状態を作成するためにPPPを進めるという目標のために1990年2月のIETFミーティングで見直されるでしょう。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
Pointからポイントへのプロトコル(PPP)は連続のポイントツーポイント接続の上にデータグラムを送るためのメソッドを提供します。 PPPは3つの部品で構成されます:
1. A method for encapsulating datagrams over serial links.
1. シリーズの上でデータグラムをカプセル化するためのメソッドはリンクされます。
2. An extensible Link Control Protocol (LCP).
2. 広げることができるLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCP) for establishing
and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
This document defines the encapsulation scheme, the basic LCP, and an NCP for establishing and configuring the Internet Protocol (IP) (called the IP Control Protocol, IPCP).
このドキュメントは、インターネットプロトコル(IP)(IPをControlプロトコル、IPCPと呼ぶ)を設立して、構成するためにカプセル化体系、基本的なLCP、およびNCPを定義します。
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET, OSI) are expected to be developed as needed.
LCPとIPCPによって使用されたオプションと施設は別々のドキュメントで定義されます。 必要に応じてIP(例えば、DECNET、OSI)以外に他のネットワーク層プロトコルを構成して、利用するための制御プロトコルによって開発されると予想されます。
1. Introduction
1. 序論
1.1. Motivation
1.1. 動機
In the last few years, the Internet has seen explosive growth in the number of hosts supporting TCP/IP. The vast majority of these hosts are connected to Local Area Networks (LANs) of various types, Ethernet being the most common. Most of the other hosts are connected through Wide Area Networks (WANs) such as X.25 style Public Data Networks (PDNs). Relatively few of these hosts are connected with simple point-to-point (i.e., serial) links. Yet, point-to-point links are among the oldest methods of data communications and almost
ここ数年間で、インターネットは、ホストの数における爆発的成長がTCP/IPをサポートしているのを見ました。 これらのホストのかなりの大部分が様々なタイプ(最も一般的なイーサネット)のローカル・エリア・ネットワーク(LAN)に接続されます。 他のホストの大部分はX.25スタイルPublic Data Networks(PDNs)などのワイドエリアネットワーク(WAN)を通して接されます。 比較的、これらのホストのわずかしか簡単な二地点間(すなわち、連続の)のリンクに接続されません。 しかし、ポイントツーポイント接続はデータ通信の最も古いメソッドとほとんどそうです。
Perkins [Page 2] RFC 1134 PPP November 1989
パーキンス[2ページ]RFC1134ppp1989年11月
every host supports point-to-point connections. For example, asynchronous RS-232-C [1] interfaces are essentially ubiquitous.
すべてのホストが二地点間接続をサポートします。 例えば、非同期なRS232C[1]インタフェースは本質的には遍在しています。
One reason for the small number of point-to-point IP links is the lack of a standard encapsulation protocol. There are plenty of non- standard (and at least one defacto standard) encapsulation protocols available, but there is not one which has been agreed upon as an Internet Standard. By contrast, standard encapsulation schemes do exist for the transmission of datagrams over most popular LANs.
二地点間IPリンクの少ない数の1つの理由が標準のカプセル化プロトコルの不足です。 利用可能な多くの非標準(そして、少なくとも1つの事実上の規格)のカプセル化プロトコルがありますが、インターネットStandardとして同意されたのはありません。 対照的に、標準のカプセル化体系はデータグラムのトランスミッションのためにほとんどのポピュラーなLANの上に存在しています。
One purpose of this memo is to remedy this problem. But even more importantly, the Point-to-Point Protocol proposes more than just an encapsulation scheme. 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 switched point-to- point circuits (e.g., dialups).
このメモの1つの目的はこの問題を改善することです。 しかし、まさしくカプセル化体系よりさらに重要に、Pointからポイントへのプロトコルは提案します。 指すポイントリンクは、ネットワーク・プロトコルの現在のファミリーに関する多くの問題を悪化させる傾向があります。 例えば、IPアドレスの課題と管理(LAN環境においてさえ問題である)は切り換えられたポイントからポイントの上の特に難しい回路(例えば、ダイアルアップ)です。
Some additional issues addressed by PPP include asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network-layer address negotiation and data compression negotiation.
PPPによって扱われたいくつかの追加設定がネットワーク層アドレス交渉とデータ圧縮交渉のような能力のための非同期な(始め/停止)、ビット指向の同期カプセル化、ネットワーク・プロトコルマルチプレクシング、リンク構成、リンク品質検査、誤り検出、およびオプション交渉を含んでいます。
PPP addresses these issues by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCP) to negotiate optional configuration parameters and facilities.
PPPは、任意の設定パラメータと施設を交渉するために広げることができるLink Controlプロトコル(LCP)とNetwork Controlプロトコル(NCP)のファミリーを提供することによって、これらの問題を扱います。
1.2. Overview of PPP
1.2. pppの概要
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating datagrams over serial links. PPP
uses HDLC as a basis for encapsulating datagrams over point-
to-point links.
1. シリーズの上でデータグラムをカプセル化するためのメソッドはリンクされます。 PPPはデータグラムがある程度ポイントの上のリンクであるとカプセル化する基礎としてHDLCを使用します。
2. An extensible Link Control Protocol (LCP) to establish,
configure, and test the data-link connection.
2. データリンク接続を設立して、構成して、テストする広げることができるLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCP) for establishing
and configuring different network-layer protocols. PPP is
designed to allow the simultaneous use of multiple network-
layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。 PPPは、複数のネットワーク層のプロトコルの同時の使用を許すように設計されています。
In order to establish communications over a point-to-point link, the originating PPP would first send LCP packets to configure and test the data link. After the link has been establish and optional facilities have been negotiated as needed by the LCP, the originating
ポイントツーポイント接続の上でコミュニケーションを確立するために、起因しているPPPは最初に、構成するパケットをLCPに送って、データ・リンクをテストに送るでしょう。 リンクがあった後、設立、任意の施設は必要に応じてLCP、起因することで交渉されました。
Perkins [Page 3] RFC 1134 PPP November 1989
パーキンス[3ページ]RFC1134ppp1989年11月
PPP would 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は、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 (e.g., inactivity timer expires or user intervention).
または、リンクが明白なLCPかNCPパケットがリンクを閉鎖するか、または何らかの外部のイベントが起こるまでコミュニケーションのために構成されたままで残る、(例えば不活発タイマが期限が切れる、ユーザ介入)
1.3. Organization of the document
1.3. ドキュメントの組織
This memo is divided into several sections. Section 2 discusses the physical-layer requirements of PPP. Section 3 describes the Data Link Layer including the PPP frame format and data link encapsulation scheme. Section 4 specifies the LCP including the connection establishment and option negotiation procedures. Section 5 specifies the IP Control Protocol (IPCP), which is the NCP for the Internet Protocol, and describes the encapsulation of IP datagrams within PPP packets. Appendix A summarizes important features of asynchronous HDLC, and Appendix B describes an efficient table-lookup algorithm for fast Frame Check Sequence (FCS) computation.
このメモは数人のセクションに分割されます。 セクション2はPPPの物理的な層の要件について論じます。 セクション3はPPPフレーム形式とデータ・リンクカプセル化体系を含むData Link Layerについて説明します。 セクション4はコネクション確立とオプション交渉手順を含むLCPを指定します。 セクション5は、IP Controlプロトコル(IPCP)を指定して、PPPパケットの中でIPデータグラムのカプセル化について説明します。(プロトコルはインターネットプロトコルのためのNCPです)。 付録Aは非同期なHDLCの重要な特徴をまとめます、そして、Appendix Bは速いFrame Check Sequence(FCS)計算のための効率的な索表アルゴリズムを説明します。
2. Physical Layer Requirements
2. 物理的な層の要件
The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the provision of a duplex circuit, either dedicated or switched, which can operate in either an asynchronous (start/stop) or synchronous bit-serial mode, transparent to PPP Data Link Layer frames. PPP does not impose any restrictions regarding transmission rate, other than those imposed by the particular DTE/DCE interface in use.
PointからポイントへのプロトコルはどんなDTE/DCEインタフェース(例えば、EIA RS232C、EIA RS-422、EIA RS-423、およびCCITT V.35)の向こう側にも作動できます。 PPPによって課された唯一の絶対条件が非同期な(始め/停止)かシンクロナスビット連続のモードのどちらかで作動できる捧げられるか、または切り換えられた複式の回路の設備です、PPP Data Link Layerフレームに、透明です。 PPPは特定のDTE/DCEインタフェースによって使用中に課されたもの以外の通信速度に関する少しの制限も課しません。
PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and Data Terminal Ready (DTR). However, using such signals when available can allow greater functionality and performance.
PPPはモデム制御信号の使用を必要としません、Request To Send(RTS)や、Clear To Send(CTS)や、Data Carrier Detect(DCD)や、Data Terminal Ready(DTR)などのように。 しかしながら、利用可能であるときに、そのような信号を使用すると、より大きい機能性と性能を許容できます。
3. The Data Link Layer
3. データ・リンク層
The Point-to-Point Protocol uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) High-level Data Link Control (HDLC) procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/stop transmission" [5]. ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments.
Pointからポイントへのプロトコルが国際標準化機構(ISO)のハイレベルのData Link Control(HDLC)手順の原則、用語、および枠組構造を使用する、(ISO3309によって変更されるようなISO3309-1979[2])、1984/PDAD1、「付加物1:」 「始め/停止送信」[5]。 ISO3309-1979は同期環境における使用にHDLC枠組構造を指定します。 ISO3309: 1984/PDAD1は、非同期な環境における使用を許すためにISO3309-1979への提案された変更を指定します。
Perkins [Page 4] RFC 1134 PPP November 1989
パーキンス[4ページ]RFC1134ppp1989年11月
The PPP control procedures use the definitions and Control field encodings standardized in ISO 4335-1979 [3] and ISO 4335- 1979/Addendum 1-1979 [4]. The PPP frame structure is also consistent with CCITT Recommendation X.25 LAPB [6], since that too is based on HDLC.
PPPコントロール手順はISO4335-1979[3]とISO4335- 1979/付加物1-1979[4]で標準化された定義とControl分野encodingsを使用します。 また、それもHDLCに基づいているので、PPP枠組構造もCCITT Recommendation X.25 LAPB[6]と一致しています。
Note: ISO 3309:1984/PDAD1 is a Proposed Draft standard. At
present, it seems that ISO 3309:1984/PDAD1 is stable and likely to
become an International Standard. Therefore, we feel comfortable
about using it before it becomes an International Standard. The
progress of this proposal should be tracked and encouraged by the
Internet community.
以下に注意してください。 ISO3309: 1984/PDAD1はProposed Draft規格です。 現在のところ、そのISO3309に見えます: 1984/PDAD1は安定していて国際規格になりそうです。 したがって、私たちは国際規格になる前にそれを使用することに関して快適であると感じます。 この提案の進歩は、インターネットコミュニティによって追跡されて、奨励されるべきです。
The purpose of this memo is not to document what is already standardized in ISO 3309. We assume that the reader is already familiar with HDLC, or has access to a copy of [2] or [6]. Instead, this paper attempts to give a concise summary and point out specific options and features used by PPP. Since "Addendum 1: Start/stop transmission", is not yet standardized and widely available, it is summarized in Appendix A.
このメモの目的はISO3309で既に標準化されることを記録しないことです。 私たちは、読者が既にHDLCになじみ深いか、または[2]か[6]のコピーに近づく手段を持っていると思います。 代わりに、この紙は、簡潔な概要をして、特定のオプションとPPPによって使用された特徴を指摘するのを試みます。 以来、「付加物1:」 「始め/停止送信」がまだ標準化されていなくて広く利用可能である、それはAppendix Aにまとめられます。
3.1. Frame Format
3.1. フレーム形式
A summary of the standard PPP frame structure is shown below. The fields are transmitted from left to right.
標準のPPP枠組構造の概要は以下に示されます。 野原は左から右まで伝えられます。
+----------+---------+---------+----------+------------
| Flag | Address | Control | Protocol | Information
| 01111110 | 1111111 | 0000011 | 16 bits | *
+----------+---------+---------+----------+------------
---+---------+----------+
| FCS | Flag |
| 16 bits | 01111110 |
---+---------+----------+
+----------+---------+---------+----------+------------ | 旗| アドレス| コントロール| プロトコル| 情報| 01111110 | 1111111 | 0000011 | 16ビット| * +----------+---------+---------+----------+------------ ---+---------+----------+ | FCS| 旗| | 16ビット| 01111110 | ---+---------+----------+
This figure does not include start/stop bits (for asynchronous links) or any bits or octets inserted for transparency. When asynchronous links are used, all octets are transmitted with one start bit, eight bits of data, and one stop bit. There is no provision in either PPP or ISO 3309:1984/PDAD1 for seven bit asynchronous links.
この図は透明ために挿入されたどんなスタート/ストップ・ビット(非同期なリンクへの)や、ビットやまたは八重奏も入れません。 非同期なリンクが使用されているとき、すべての八重奏が1つのスタートビット、8ビットのデータ、および1つのストップビットで伝えられます。 支給が全くPPPかISO3309のどちらかにありません: 7ビットの非同期なリンクへの1984/PDAD1。
To remain consistent with standard Internet practice, and avoid confusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Significant Bit order, reading from left to right, unless otherwise indicated. Note that this is contrary to standard ISO and CCITT practice which orders bits as transmitted (i.e., network bit order). Keep this in mind when comparing this document with the international
一般的なインターネット習慣と一致していたままで残って、読書RFCsに慣れている人々のために混乱を避けるために、Least Significant Bitオーダーには以下の記述におけるすべての2進の数がMost Significant Bitにあります、左から右まで読んで、別の方法で示されない場合。 これが標準のISOとCCITT習慣に合わないことに注意してください(伝えられるようにビットを配置します)(すなわち、ネットワークはオーダーに噛み付きました)。 このドキュメントを国際的と比べるときにはこれを覚えておいてください。
Perkins [Page 5] RFC 1134 PPP November 1989
パーキンス[5ページ]RFC1134ppp1989年11月
standards documents.
規格文書。
Flag Sequence
フラグ・シーケンス
The Flag Sequence is a single octet and indicates the beginning or
end of a frame. The Flag Sequence consists of the binary sequence
01111110 (hexadecimal 0x7e).
Flag Sequenceはただ一つの八重奏であり、フレームの始めか端を示します。 Flag Sequenceは2進の系列01111110(16進0x7e)から成ります。
Address Field
アドレス・フィールド
The Address field is a single octet and contains the binary
sequence 11111111 (hexadecimal 0xff), the All-Stations address.
PPP does not assign individual station addresses. The All-
Stations address should always be recognized and received. Frames
with other Addresses should be silently discarded.
Address分野は、ただ一つの八重奏であり、2進の系列11111111(16進0xff)、All-駅のアドレスを含んでいます。 PPPは個々のステーションアドレスを割り当てません。 いつもAll駅のアドレスを認識して、受け取るべきです。 他のAddressesがあるフレームは静かに捨てられるべきです。
Control Field
制御フィールド
The Control field is a single octet and contains the binary
sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
(UI) command with the P/F bit is set to zero. Frames with other
Control field values should be silently discarded.
Control分野は、ただ一つの八重奏であり、2進の系列00000011(16進0x03)を含んでいます、合わせてくださいP/Fビットによる情報(UI)コマンドが設定されるゼロUnnumbered。 他のControl分野値があるフレームは静かに捨てられるべきです。
Protocol Field
プロトコル分野
The Protocol field is two octets and its value identifies the
protocol encapsulated in the Information field of the frame. The
most up-to-date values of the Protocol field are specified in the
most recent "Assigned Numbers" RFC [11]. Initial values are also
listed below.
プロトコル分野は2つの八重奏です、そして、値はフレームの情報分野でカプセル化されたプロトコルを特定します。 プロトコル分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。 また、初期の値は以下に記載されています。
Protocol field values in the "cxxx" range identify datagrams as
belonging to the Link Control Protocol (LCP) or associated
protocols. Values in the "8xxx" range identify datagrams belonging
to the family of Network Control Protocols (NCP). Values in the
"0xxx" range identify the network protocol of specific datagrams.
"cxxx"範囲のプロトコル分野値はLink Controlプロトコル(LCP)か関連プロトコルに属すとしてデータグラムを特定します。 "8xxx"範囲の値はNetwork Controlプロトコル(NCP)のファミリーのものであるデータグラムを特定します。 "0xxx"範囲の値は特定のデータグラムのネットワーク・プロトコルを特定します。
This Protocol field is defined by PPP and is not a field defined
by HDLC. However, the Protocol field is consistent with the ISO
3309 extension mechanism for Address fields. All Protocols MUST be
odd; the least significant bit of the least significant octet MUST
equal "1". Also, all Protocols MUST be assigned such that the
least significant bit of the most significant octet equals "0".
Frames received which don't comply with these rules should be
considered as having an unrecognized Protocol, and should be
handled as specified by the LCP. The Protocol field is
transmitted and received most significant octet first.
このプロトコル分野は、PPPによって定義されて、HDLCによって定義された分野ではありません。 しかしながら、プロトコル分野はAddress分野へのISO3309拡大メカニズムと一致しています。 すべてのプロトコルが変であるに違いありません。 最も重要でない八重奏の最下位ビットは「1インチ」と等しくなければなりません。 また、最も重要な八重奏の最下位ビットが「0インチ」と等しいように、すべてのプロトコルを割り当てなければなりません。 これらの規則に従わない受け取られたフレームは、認識されていないプロトコルを持ちながらみなされるべきであり、LCPによって指定されるように扱われるべきです。 最初に、プロトコル分野は伝えられて容認された最も重要な八重奏です。
Perkins [Page 6] RFC 1134 PPP November 1989
パーキンス[6ページ]RFC1134ppp1989年11月
The Protocol field is initially assigned as follows:
プロトコル分野は初めは、以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
0001 to 001f reserved (transparency inefficient)
0021 Internet Protocol
0023 * ISO CLNP
0025 * Xerox NS IDP
0027 * DECnet Phase IV
0029 * Appletalk
002b * Novell IPX
002d * Van Jacobson Compressed TCP/IP 1
002f * Van Jacobson Compressed TCP/IP 2
001fへの0001は0021年の(透明効率の悪い)のインターネットプロトコル0023*ISO CLNP0025*ゼロックスNS IDP0027*DECnet Phase IV0029*Appletalk 002b*ノベルIPX 002d*ヴァンジェーコブソンCompressed TCP/IP1 002f*ヴァンジェーコブソンCompressed TCP/IP2を予約しました。
8021 Internet Protocol Control Protocol
8023 * ISO CLNP 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
8021インターネットプロトコル制御プロトコル8023*ISO CLNP制御プロトコル8025*ゼロックスナノ秒、IDP制御プロトコル8027*DECnetフェーズIV制御プロトコル8029*Appletalk制御プロトコル802b*ノベルIPX制御プロトコル802d*は*が予約した802fを予約しました。
c021 Link Control Protocol
c023 * User/Password Authentication Protocol
c021リンクControlプロトコルc023*ユーザ/パスワード認証プロトコル
* Reserved for future use; not described in this document.
* 今後の使用のために、予約されます。 本書では説明されていません。
Information Field
情報フィールド
The Information field is zero or more octets. The Information
field contains the datagram for the protocol specified in the
Protocol field. The end of the Information field is found by
locating the closing Flag Sequence and allowing two octets for the
Frame Check Sequence field. The default maximum length of the
Information field is 1500 octets. By prior agreement, consenting
PPP implementations may use other values for the maximum
Information field length.
情報分野はゼロであるか以上が八重奏です。 情報分野はプロトコル分野で指定されたプロトコルのためのデータグラムを含んでいます。 情報分野の端は、終わりのFlag Sequenceの場所を見つけて、2つの八重奏を許容することによって、Frame Check Sequence分野に見つけられます。 情報分野のデフォルトの最大の長さは1500の八重奏です。 先の協定、PPP実現が使用するかもしれない同意で、最大の情報のための他の値は長さをさばきます。
On transmission, the Information field may be padded with an
arbitrary number of octets up to the maximum length. It is the
responsibility of each protocol to disambiguate padding characters
from real information.
トランスミッションのときに、情報分野は八重奏の特殊活字の数字で最大の長さまで水増しされるかもしれません。 本当の情報から暫定記号のあいまいさを除くのは、それぞれのプロトコルの責任です。
Frame Check Sequence (FCS) Field
フレームチェックシーケンス(FCS)分野
The Frame Check Sequence field is normally 16 bits (two octets).
By prior agreement, consenting PPP implementations may use a 32-
通常、Frame Check Sequence分野は16ビット(2つの八重奏)です。 あらかじめ取り決めて、同意して、PPP実現は32を使用するかもしれません。
Perkins [Page 7] RFC 1134 PPP November 1989
パーキンス[7ページ]RFC1134ppp1989年11月
bit (four-octet) FCS for improved error detection.
改良された誤り検出のためのビット(4八重奏)FCS。
The FCS field is calculated over all bits of the Address, Control,
Protocol and Information fields not including any start and stop
bits (asynchronous) and any bits (synchronous) or octets
(asynchronous) inserted for transparency. This does not include
the Flag Sequences or FCS field. The FCS is transmitted with the
coefficient of the highest term first.
FCS分野は透明ために挿入されたどんなどんな始めとストップビット(非同期な)とビット(同期)や八重奏(非同期な)も含まないAddress、Control、プロトコル、および情報分野のすべてのビットの上計算されます。 これはFlag SequencesかFCS分野を含んでいません。 FCSは最初に、最も高い用語の係数で伝えられます。
For more information on the specification of the FCS, see ISO 3309
or CCITT X.25.
FCSの仕様の詳しい情報に関しては、ISO3309かCCITT X.25を見てください。
Note: A fast, table-driven implementation of the 16-bit FCS
algorithm is shown in Appendix B. This implementation is based
on [7] and [8].
以下に注意してください。 16ビットのFCSアルゴリズムの速くて、テーブル駆動の実現はAppendixにB.This実現が[7]と[8]に基づいているのが示されます。
Modifications to the Basic Frame Format
基本枠形式への変更
The Link Control Protocol can negotiate modifications to the
standard PPP frame structure. However, modified frames will
always be clearly distinguishable from standard frames.
Link Controlプロトコルは標準のPPP枠組構造への変更を交渉できます。 しかしながら、変更されたフレームは標準のフレームから区別可能にいつも明確になるでしょう。
4. The PPP Link Control Protocol (LCP)
4. pppリンク制御プロトコル(LCP)
The Link Control Protocol (LCP) provides a method of establishing, configuring, maintaining and terminating the point-to-point connection. LCP goes through four distinct phases:
Link Controlプロトコル(LCP)は二地点間接続を設立して、構成して、維持して、終える方法を提供します。 LCPは4つの異なったフェーズに直面しています:
Phase 1: Link Establishment and Configuration Negotiation
フェーズ1: リンク設立と構成交渉
Before any network-layer datagrams (e.g., IP) may be exchanged,
LCP must first open the connection through an exchange of
Configure packets. This exchange is complete, and the Open state
entered, once a Configure-Ack packet (described below) has been
both sent and received. Any non-LCP packets received before this
exchange is complete are silently discarded.
どんなネットワーク層データグラム(例えば、IP)も交換するかもしれない前に、LCPは最初に、Configureパケットの交換を通して接続を開かなければなりません。 この交換は完全です、そして、オープン状態に入りました、いったん、Configure-Ackパケット(以下で、説明される)を送って、受け取ると。 この交換が完全になる前に受け取られたどんな非LCPパケットも静かに捨てられます。
It is important to note that LCP handles configuration only of the
link; LCP does not handle configuration of individual network-
layer protocols. In particular, all Configuration Parameters
which are independent of particular network-layer protocols are
configured by LCP. All Configuration Options are assumed to be at
default values unless altered by the configuration exchange.
LCPがリンクだけの構成を扱うことに注意するのは重要です。 LCPは個々のネットワーク層のプロトコルの構成を扱いません。 特に、すべての特定のネットワーク層プロトコルから独立しているConfiguration ParametersがLCPによって構成されます。 構成交換で変更されない場合、デフォルト値にはすべてのConfiguration Optionsがいると思われます。
Phase 2: Link Quality Determination
フェーズ2: リンク品質決定
LCP allows an optional Link Quality Determination phase following
transition to the LCP Open state. In this phase, the link is
LCPオープン状態への変遷に続いて、LCPは任意のLink Quality Determinationフェーズを許容します。 このフェーズでは、リンクはそうです。
Perkins [Page 8] RFC 1134 PPP November 1989
パーキンス[8ページ]RFC1134ppp1989年11月
tested to determine if the link quality is sufficient to bring up
network-layer protocols. This phase is completely optional. LCP
may delay transmission of network-layer protocol information until
this phase is completed.
リンク品質がネットワーク層プロトコルを持って来るために十分であるかどうか決定するために、テストされます。 このフェーズは完全に任意です。 このフェーズが完成するまで、LCPはネットワーク層プロトコル情報の伝達を遅らせるかもしれません。
The procedure for Link Quality Determination is unspecified and
may vary from implementation to implementation, or because of
user-configured parameters, but only so long as the procedure
doesn't violate other aspects of LCP. One suggested method is to
use LCP Echo-Request and Echo-Reply packets.
単にLCPの他の局面に違反しない限り、Link Quality Determinationのための手順は、不特定であり、実現から実現までユーザによって構成されたパラメタので異なるかもしれません。 あるものは、方法がLCP Echo-要求とEcho-回答パケットを使用することであることを示しました。
What is important is that this phase may persist for any length of
time. Therefore, implementations should avoid fixed timeouts when
waiting for their peers to advance to phase 3.
重要なことはこのフェーズがどんな長さの時にも持続するかもしれないということです。 したがって、彼らの同輩がフェーズ3に達するのを待つとき、実現は固定タイムアウトを避けるべきです。
Phase 3: Network-Layer Protocol Configuration Negotiation
フェーズ3: ネットワーク層プロトコル構成交渉
Once LCP has finished the Link Quality Determination phase,
network-layer protocols may be separately configured by the
appropriate Network Control Protocols (NCP), and may be brought up
and taken down at any time. If LCP closes the link, it informs
the network-layer protocols so that they may take appropriate
action.
LCPがいったんLink Quality Determinationフェーズを終えると、ネットワーク層プロトコルは、いつでも、別々に適切なNetwork Controlプロトコル(NCP)によって構成されて、持って来られて、降ろされるかもしれません。 LCPがリンクを閉じるなら、それは、適切な行動を取ることができるようにネットワーク層プロトコルを知らせます。
Phase 4: Link Termination
フェーズ4: リンク終了
LCP may terminate the link at any time. This will usually be done
at the request of a human user, but may happen because of a
physical event such as the loss of carrier, or the expiration of
an idle-period timer.
LCPはいつでも、リンクを終えるかもしれません。 通常、キャリヤーの損失、または活動していない期間のタイマの満了などの物理的な出来事のために起こるかもしれないのを除いて、人間のユーザの依頼でこれをするでしょう。
4.1. The LCP Automation
4.1. LCPオートメーション
4.1.1. Overview
4.1.1. 概観
LCP is specified by a number of packet formats and a finite-state automation. This section presents an overview of the LCP automation, followed by a representation of it as both a state diagram and a state transition table.
LCPは多くのパケット・フォーマットと有限州のオートメーションで指定されます。 このセクションはそれの表現が州のダイヤグラムと状態遷移テーブルの両方としてあとに続いたLCPオートメーションの概観を提示します。
There are three classes of LCP packets:
3つのクラスのLCPパケットがあります:
1. Link Establishment packets used to establish and configure a
link, (e.g., Configure-Request, Configure-Ack, Configure-Nak
and Configure-Reject)
1. リンク特権階級パケットは、リンクを設立して、以前はよく構成していました。(例えば、Ackを構成していて、Nakを構成していて廃棄物を構成している要求を構成します)
2. Link Termination packets used to terminate a link, (e.g.,
Terminate-Request and Terminate-Ack)
2. リンクTerminationパケットは以前はよくリンクを終えていました。(例えば、要求とAckを終えて、終わります)
Perkins [Page 9] RFC 1134 PPP November 1989
パーキンス[9ページ]RFC1134ppp1989年11月
3. Link Maintenance packets used to manage and debug a link,
(e.g., Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply
and Discard-Request)
3. リンクMaintenanceパケットは、リンクを管理して、以前はよくデバッグしていました。(例えば、コード廃棄物、プロトコル廃棄物、回答をまねていて要求を捨てているエコー要求)
The finite-state automation is defined by events, state transitions and actions. Events include receipt of external commands such as Open and Close, expiration of the Restart timer, and receipt of packets from a LCP peer. Actions include the starting of the Restart timer and transmission of packets.
有限州のオートメーションは出来事、状態遷移、および動作で定義されます。 出来事はオープンやCloseなどの外部のコマンドの受領、Restartタイマの満了、およびLCP同輩からのパケットの受領を含んでいます。 動作はRestartタイマの始めとパケットのトランスミッションを含んでいます。
4.1.2. State Diagram
4.1.2. 州のダイヤグラム
The state diagram which follows describes the sequence of events for reaching agreement on Configuration Options (opening the PPP connection) and for later closing of the connection. The state machine is initially in the Closed state (1). Once the Open state (6) has been reached, both ends of the link have met the requirement of having both sent and received a Configure-Ack packet.
従う州のダイヤグラムはConfiguration Options(PPP接続を開く)で合意に達して、接続の後の閉鎖のために出来事の系列について説明します。 州のマシンが初めはClosed状態(1)にあります。 オープン状態(6)にいったん達すると、リンクの両端は、両方を送らせる必要条件を満たして、Configure-Ackパケットを受けました。
In the state diagram, events are shown above horizontal lines. Actions are shown below horizontal lines. Two types of LCP packets - Configure-Naks and Configure-Rejects - are not differentiated in the state diagram. As will be described later, these packets do indeed serve different, though similar, functions. However, at the level of detail of this state diagram, they always cause the same transition.
州のダイヤグラムで、出来事は水平な線の上に示されます。 動作は水平な線の下に示されます。 2つのタイプのLCPパケット--、Naksを構成する、Configure-廃棄物--そして、州のダイヤグラムで、微分されません。 本当に、後で説明されるように、これらのパケットは異なって、もっとも、同様の機能を果たします。 しかしながら、この州のダイヤグラムの細部のレベルでは、彼らは同じ変遷をいつも引き起こします。
Since a more detailed specification of the LCP automation is given in a state transition table in the following section, implementation should be done by consulting it rather than this state diagram.
以下のセクションで状態遷移テーブルでLCPオートメーションの、より詳細な仕様を与えるので、この州のダイヤグラムよりむしろそれに相談することによって、実現するべきです。
Perkins [Page 10] RFC 1134 PPP November 1989
パーキンス[10ページ]RFC1134ppp1989年11月
+------------------------------+
| |
V |
+---2---+ PO +---1---+ RTA +---7---+ |
| |<-------------| |<-----------| | |
|Listen | |Closed | |Closing| |
RCR | | C | | PLD | | |
+----| |----->+------>| |<---Any | |<--+ |
|scr +-------+ ^ +-------+ State +-------+ | |
| | AO | ^ | TO | |
| +-----------+ --- | | +---->+ |
| | SCR | C | str ^ |
| C | RCN/TO | +----------------+ | |
| -- | +-------->+<--------+ | str | |
| | | scr | | | |
| +---3---+ V TO +---4---+ +-------+ | |
| | |<-----+<------| |<-----------| | | |
| | Req- | scr | Ack- | scn | Good | | |
| | Sent | RCA | Rcvd | RCR | Req? | | |
| | |------------->| |----------->| | | |
| +-------+ +-------+ +-------+ | |
| | ^ | | |
| RCR | +<--------+ | | |
| --- | | | TO RCN --- | | |
| | | --- +---------+ +-----+ sca | | |
| V | scn scr | | scr | V | |
| +-------+ +---5---+ | +---6---+ C | |
+--->| |------------->| |<--+ | |---+ |
| Good | sca | Ack- | | Open | str |
| Req? | RCR | Sent | RCA | | |
| |<-------------| |----------->| | |
+-------+ +-------+ +-------+ |
^ | | |
| RCR | | RTR |
+---------------------------------------+ +--------+
scr sta
+------------------------------+ | | V| +---2---+ ポー+---1---+ RTA+---7---+ | | | <、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、--、|、|、| |聴いてください。| |閉じられます。| |閉じます。| | RCR| | C| | PLD| | | +----| |----->+------>| | <、-、--いくらか| | <--+ | |scr+-------+ ^ +-------+ 状態+-------+ | | | | AO| ^ | to| | | +-----------+ --- | | +---->+| | | SCR| C| str^| | C| RCN/| +----------------+ | | | -- | +-------->+<。--------+ | str| | | | | scr| | | | | +---3---+ +へのV---4---+ +-------+ | | | | | <、-、-、-、--+ <。------| | <、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| Req| scr| Ack| scn| 利益| | | | | 発信します。| RCA| Rcvd| RCR| Req? | | | | | |、-、-、-、-、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| +-------+ +-------+ +-------+ | | | | ^ | | | | RCR| + <。--------+ | | | | --- | | | RCNに--- | | | | | | --- +---------+ +-----+ sca| | | | V| scn scr| | scr| V| | | +-------+ +---5---+ | +---6---+ C| | +--->| |、-、-、-、-、-、-、-、-、-、-、-、--、>| | <--+ | |---+ | | 利益| sca| Ack| | 開いてください。| str| | Req? | RCR| 発信します。| RCA| | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、| |、-、-、-、-、-、-、-、-、-、--、>|、|、| +-------+ +-------+ +-------+ | ^ | | | | RCR| | RTR| +---------------------------------------+ +--------+ scr sta
Events Actions RCR - Receive-Configure-Request scr - Send Configure-Request RCA - Receive-Configure-Ack sca - Send Configure-Ack RCN - Receive-Configure-Nak or Reject scn - Send Configure-Nak or RTR - Receive-Terminate-Req Reject RTA - Receive-Terminate-Ack str - Send Terminate-Req AO - Active-Open sta - Sent Terminate-Ack PO - Passive-Open C - Close TO - Timeout PLD - Physical-Layer-Down
または、イベントActions RCR--、受信、要求を構成してください、scr--Configure-要求RCAを送ってください--、受信、Ack scaを構成してください、--Configure-Ack RCNを送ってください--、受信、Nakを構成してください、Reject scn--Configure-NakかRTRを送ってください--、受信、Req Reject RTAを終えてください、--、受信、Ack strを終えてください、--送られたTerminate-Ack PO--受け身に開いているC--近いTO--タイムアウトPLD--物理的な層の下であるのをTerminate-Req AO(アクティブに開いているsta)に送ってください
Perkins [Page 11] RFC 1134 PPP November 1989
パーキンス[11ページ]RFC1134ppp1989年11月
4.1.3. State Transition Table
4.1.3. 状態遷移テーブル
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. Two actions caused by the same event are represented as action1&action2.
完全な状態遷移テーブルは続きます。 州は水平に示されます、そして、出来事は垂直に読まれます。 状態遷移と動作はフォームに新しい動作/状態で表されます。 同じ出来事によって引き起こされた2つの動作がaction1とaction2として表されます。
| State
| 1 2 3 4 5 6 7
Events| Closed Listen Req-Sent Ack-Rcvd Ack-Sent Open Closing
------+-------------------------------------------------------------
AO | scr/3 scr/3 3 4 5 6 scr/3
PO | 2 2 2* 4 5 6 sta/3*
C | 1 1 1* 1 str/7 str/7 7
TO | 1 2 scr/3 scr/3 scr/3 6 str/7*
PLD | 1 1 1 1 1 1 1
RCR+ | sta/1 scr&sca/5 sca/5 sca/6 sca/5 scr&sca/5 7
RCR- | sta/1 scr&scn/3 scn/3 scn/4 scn/3 scr&scn/3 7
RCA | sta/1 sta/2 4 scr/3 6 scr/3 7
RCN | sta/1 sta/2 scr/3 scr/3 scr/5 scr/3 7
RTR | sta/1 sta/2 sta/3 sta/3 sta/3 sta/1 sta/7
RTA | 1 2 3 3 3 1 1
RCJ | 1 2 1 1 1 1 1
RUC | scj/1 scj/1 scj/1 scj/1 scj/1 scj/1 1 scj/1
RER | sta/1 sta/2 3 4 5 ser/1 7
| 状態| 1 2 3 4 5 6 7回の出来事| 閉じられて、Reqによって送られたAck-Rcvd Ackによって送られた開いている閉鎖を聴いてください。------+------------------------------------------------------------- AO| scr/3scr/3 3 4 5 6scr/3PO| 2 2 2*4 5 6sta/3*C| 1 1 1*1str/7str/7 7TO| 1 2scr/3scr/3scr/3 6str/7*PLD| 1 1 1 1 1 1 1RCR+| sta/1scr、sca/5sca/5sca/6sca/5scr、およびsca/5 7RCR| sta/1scrとscn/3scn/3scn/4scn/3scrとscn/3 7RCA| sta/1sta/2 4scr/3 6scr/3 7RCN| sta/1sta/2scr/3scr/3scr/5scr/3 7RTR| sta/1sta/2sta/3sta/3sta/3sta/1sta/7RTA| 1 2 3 3 3 1 1RCJ| 1 2 1 1 1 1 1RUC| scj/1scj/1scj/1scj/1scj/1scj/1 1scj/1RER| sta/1sta/2 3 4 5ser/1 7
Notes:
RCR+ - Receive-Configure-Request (Good)
RCR- - Receive-Configure-Request (Bad)
RCJ - Receive-Code-Reject
RUC - Receive-Unknown-Code
RER - Receive-Echo-Request
scj - Send-Code-Reject
ser - Send-Echo-Reply
* - Special attention necessary, see detailed text
注意: RCR+--、受信、要求を構成してください、(利益)RCR--、受信、要求を構成してください、(悪い)のRCJ--コード廃棄物を受けているRUC--未知のコードを受け取っているRER--エコー要求を受け取っているscj--コード廃棄物を送っているser--エコー回答を送っている*--特別な注意必要です、詳細なテキストを見てください。
4.1.4. Events
4.1.4. 出来事
Transitions and actions in the LCP state machine are caused by events. Some events are caused by commands executed at the local end (e.g., Active-Open, Passive-Open, and Close), others are caused by the receipt of packets from the remote end (e.g., Receive- Configure- Request, Receive-Configure-Ack, Receive-Configure-Nak, Receive- Terminate-Request and Receive-Terminate-Ack), and still others are caused by the expiration of the Restart timer started as the result of other events (e.g., Timeout).
LCP州のマシンでの変遷と動作は出来事によって引き起こされます。 いくつかの出来事が地方の終わり(例えば、開いているActive、開いているPassive、およびClose)に実行されたコマンドで引き起こされます、そして、他のものはリモートエンドからパケットの領収書で引き起こされます、そして、(例えば、Receiveが要求を終えて要求、ReceiveがAckを構成していて、ReceiveがNakを構成しているReceiveを構成します、そして、ReceiveはAckを終えます)それでも、他のものは他の出来事(例えば、Timeout)の結果として始動されたRestartタイマの満了で引き起こされます。
Following is a list of LCP events.
以下に、LCP出来事のリストがあります。
Perkins [Page 12] RFC 1134 PPP November 1989
パーキンス[12ページ]RFC1134ppp1989年11月
Active-Open (AO)
アクティブに開きます。(AO)
The Active-Open event indicates the local execution of an Active-
Open command by the network administrator (human or program).
When this event occurs, LCP should immediately attempt to open the
connection by exchanging configuration packets with the LCP peer.
Active-オープン・ゲームはネットワーク管理者(人間かプログラム)によるActiveの開いているコマンドの地方の実行を示します。 この出来事が起こると、LCPは、すぐに、LCP同輩と構成パケットを交換することによって接続を開くのを試みるはずです。
Passive-Open (PO)
開いている受動態(po)
The Passive-Open event is similar to the Active-Open event.
However, instead of immediately exchanging configuration packets,
LCP should wait for the peer to send the first packet. This will
only happen after an Active-Open event in the LCP peer.
Passive-オープン・ゲームはActive-オープン・ゲームと同様です。 しかしながら、すぐに構成パケットを交換することの代わりに、LCPは、同輩が最初のパケットを送るのを待つはずです。 これはLCP同輩のActive-オープン・ゲームの後に起こるだけでしょう。
Close (C)
閉鎖(C)
The Close event indicates the local execution of a Close command.
When this event occurs, LCP should immediately attempt to close
the connection.
Close出来事はCloseコマンドの地方の実行を示します。 この出来事が起こると、LCPは、すぐに、接続を終えるのを試みるはずです。
Timeout (TO)
タイムアウト(TO)
The Timeout event indicates the expiration of the LCP Restart
timer. The LCP Restart timer is started as the result of other
LCP events.
Timeout出来事はLCP Restartタイマの満了を示します。 LCP Restartタイマは他のLCP出来事の結果として始動されます。
The Restart timer is used to time out transmissions of Configure-
Request and Terminate-Request packets. Expiration of the Restart
timer causes a Timeout event, which triggers the corresponding
Configure-Request or Terminate-Request packet to be retransmitted.
The Restart timer MUST be configurable, but should default to
three (3) seconds.
RestartタイマはConfigure要求とTerminate-リクエスト・パケットのタイムアウトトランスミッションに使用されます。 Restartタイマの満了はTimeout出来事を再送します。(それは、対応するConfigure-要求かTerminate-リクエスト・パケットの引き金となります)。 Restartタイマは、構成可能でなければなりませんが、3(3)秒をデフォルトとするはずです。
Receive-Configure-Request (RCR)
受信、要求を構成してください。(RCR)
The Receive-Configure-Request event occurs when a Configure-
Request packet is received from the LCP peer. The Configure-
Request packet indicates the desire to open a LCP connection and
may specify Configuration Options. The Configure-Request packet
is more fully described in a later section.
LCP同輩からConfigureリクエスト・パケットを受け取るとき、Receiveが要求を構成している出来事は起こります。 Configureリクエスト・パケットは、LCP接続を開く願望を示して、Configuration Optionsを指定するかもしれません。 Configure-リクエスト・パケットは後のセクションで、より完全に説明されます。
Receive-Configure-Ack (RCA)
受信、Ackを構成してください。(RCA)
The Receive-Configure-Ack event occurs when a valid Configure-Ack
packet is received from the LCP peer. The Configure-Ack packet is
a positive response to a Configure-Request packet.
LCP同輩から有効なConfigure-Ackパケットを受け取るとき、ReceiveがAckを構成している出来事は起こります。 Configure-AckパケットはConfigure-リクエスト・パケットへの積極的な応答です。
Perkins [Page 13] RFC 1134 PPP November 1989
パーキンス[13ページ]RFC1134ppp1989年11月
Receive-Configure-Nak (RCN)
受信、Nakを構成してください。(RCN)
The Receive-Configure-Nak event occurs when a valid Configure-Nak
or Configure-Reject packet is received from the LCP peer. The
Configure-Nak and Configure-Reject packets are negative responses
to a Configure-Request packet.
LCP同輩から有効なConfigure-NakかConfigure-廃棄物パケットを受け取るとき、ReceiveがNakを構成している出来事は起こります。 Configure-NakとConfigure-廃棄物パケットはConfigure-リクエスト・パケットへの否定応答です。
Receive-Terminate-Request (RTR)
受信、要求を終えてください。(RTR)
The Receive-Terminate-Request event occurs when a Terminate-
Request packet is received from the LCP peer. The Terminate-
Request packet indicates the desire to close the LCP connection.
LCP同輩からTerminateリクエスト・パケットを受け取るとき、Receiveが要求を終えている出来事は起こります。 Terminateリクエスト・パケットはLCP接続を終える願望を示します。
Receive-Terminate-Ack (RTA)
受信、Ackを終えてください。(RTA)
The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
is received from the LCP peer. The Terminate-Ack packet is a
response to a Terminate-Request packet.
LCP同輩からTerminate-Ackパケットを受け取るとき、ReceiveがAckを終えている出来事は起こります。 Terminate-AckパケットはTerminate-リクエスト・パケットへの応答です。
Receive-Code-Reject (RCJ)
コード廃棄物を受けてください。(RCJ)
The Receive-Code-Reject event occurs when a Code-Reject packet is
received from the LCP peer. The Code-Reject packet communicates
an error that immediately closes the connection.
LCP同輩からCode-廃棄物パケットを受け取るとき、Receiveコード廃棄物出来事は起こります。 Code-廃棄物パケットはすぐに接続を終える誤りを伝えます。
Receive-Unknown-Code (RUC)
未知のコードを受け取ってください。(RUC)
The Receive-Unknown-Code event occurs when an un-interpretable
packet is received from the LCP peer. The Code-Reject packet is a
response to an unknown packet.
LCP同輩から不-解明できるパケットを受け取るとき、Receiveの未知のコードイベントは起こります。 Code-廃棄物パケットは未知のパケットへの応答です。
Receive-Echo-Request (RER)
エコー要求を受け取ります。(RER)
The Receive-Echo-Request event occurs when a Echo-Request, Echo-
Reply, or Discard-Request packet is received from the LCP peer.
The Echo-Reply packet is a response to a Echo-Request packet.
There is no reply to a Discard-Request.
LCP同輩からEcho-要求、Echo回答、またはDiscard-リクエスト・パケットを受け取るとき、Receiveエコー要求イベントは起こります。 Echo-回答パケットはEcho-リクエスト・パケットへの応答です。 Discard-要求に関する回答が全くありません。
Physical-Layer-Down (PLD)
物理的な層の下(PLD)
The Physical-Layer-Down event occurs when the Physical Layer
indicates that it is down.
Physical Layerが、それが下がっているのを示すとき、Physical層がダウンしている出来事は起こります。
4.1.5. Actions
4.1.5. 動作
Actions in the LCP state machine are caused by events and typically indicate the transmission of packets and/or the starting or stopping of the Restart timer. Following is a list of LCP actions.
LCP州のマシンでの動作は、出来事によって引き起こされて、Restartタイマのパケットのトランスミッション、そして/または、始めか停止を通常示します。 以下に、LCP動作のリストがあります。
Perkins [Page 14] RFC 1134 PPP November 1989
パーキンス[14ページ]RFC1134ppp1989年11月
Send-Configure-Request (scr)
発信、要求を構成してください。(scr)
The Send-Configure-Request action transmits a Configure-Request
packet. This indicates the desire to open a LCP connection with a
specified set of Configuration Options. The Restart timer is
started after the Configure-Request packet is transmitted, to
guard against packet loss.
Sendが要求を構成している動作はConfigure-リクエスト・パケットを伝えます。 これはConfiguration Optionsの指定されたセットとのLCP接続を開く願望を示します。 Configure-リクエスト・パケットがパケット損失に用心するために伝えられた後にRestartタイマは始動されます。
Send-Configure-Ack (sca)
発信、Ackを構成してください。(sca)
The Send-Configure-Ack action transmits a Configure-Ack packet.
This acknowledges the receipt 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 receipt 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 vs. 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-Req (str)
発信、Reqを終えてください。(str)
The Send-Terminate-Request action transmits a Terminate-Request
packet. This indicates the desire to close a LCP connection. The
Restart timer is started after the Terminate-Request packet is
transmitted, to guard against packet loss.
Sendが要求を終えている動作はTerminate-リクエスト・パケットを伝えます。 これはLCP接続を終える願望を示します。 Terminate-リクエスト・パケットがパケット損失に用心するために伝えられた後にRestartタイマは始動されます。
Send-Terminate-Ack (sta)
発信、Ackを終えてください。(sta)
The Send-Terminate-Request action transmits a Terminate-Ack
packet. This acknowledges the receipt of a Terminate-Request
packet or otherwise confirms the belief that a LCP connection is
Closed.
Sendが要求を終えている動作はTerminate-Ackパケットを伝えます。 これは、Terminate-リクエスト・パケットの領収書を受け取ったことを知らせるか、または別の方法で、LCP接続がClosedであるという信念を確認します。
Send-Code-Reject (scj)
コード廃棄物を送ってください。(scj)
The Send-Code-Reject action transmits a Code-Reject packet. This
indicates the receipt of an unknown type of packet. This is an
unrecoverable error which causes immediate transitions to the
Closed state on both ends of the link.
Sendコード廃棄物動作はCode-廃棄物パケットを伝えます。 これは未知のタイプのパケットの領収書を示します。 これはリンクの両端のClosed状態への即座の変遷を引き起こす回復不能エラーです。
Perkins [Page 15] RFC 1134 PPP November 1989
パーキンス[15ページ]RFC1134ppp1989年11月
Send-Echo-Reply (ser)
エコー・リプライを発信させます。(ser)
The Send-Echo-Reply action transmits an Echo-Reply packet. This
acknowledges the receipt of an Echo-Request packet.
Sendエコー回答動作はEcho-回答パケットを伝えます。 これはEcho-リクエスト・パケットの領収書を受け取ったことを知らせます。
4.1.6. States
4.1.6. 状態
Following is a more detailed description of each LCP state.
以下に、それぞれのLCP状態の、より詳細な記述があります。
Closed (1)
閉じられます。(1)
The initial and final state is the Closed state. In the Closed
state the connection is down and there is no attempt to open it;
all connection requests from peers are rejected. Physical-Layer-
Down events always cause an immediate transition to the Closed
state.
初期的、そして、最終的な状態はClosed状態です。 Closed状態では、接続は下がっています、そして、それを開く試みが全くありません。 同輩からのすべての接続要求が拒絶されます。 下に物理的な層の出来事はいつもClosed状態への即座の変遷を引き起こします。
There are two events which cause a transition out of the Closed
state, Active-Open and Passive-Open. Upon an Active-Open event, a
Configure-Request is transmitted, the Restart timer is started,
and the Request-Sent state is entered. Upon a Passive-Open event,
the Listen state is entered immediately. Upon receipt of any
packet, with the exception of a Terminate-Ack, a Terminate-Ack is
sent. Terminate-Acks are silently discarded to avoid creating a
loop.
Closed状態、開いているActive、および開いているPassiveから変遷を引き起こす2回の出来事があります。 Active-オープン・ゲームでは、Configure-要求は伝えられます、そして、Restartタイマは始動されます、そして、Requestによって送られた状態は入られます。 Passive-オープン・ゲームに、Listen状態はすぐに、入れられます。 Terminate-Ack以外のどんなパケットを受け取り次第、Terminate-Ackを送ります。 輪を作成するのを避けるために捨てられて、Acksを終えるのは、静かにそうです。
The Restart timer is not running in the Closed state.
RestartタイマはClosed状態に遺伝していません。
The Physical Layer connection may be disconnected at any time when
in the LCP Closed state.
いつでも、LCP Closed状態にあるとき、Physical Layer接続は外されるかもしれません。
Listen (2)
聴いてください。(2)
The Listen state is similar to the Closed state in that the
connection is down and there is no attempt to open it. However,
peer connection requests are no longer rejected.
Listen状態は接続が下がっていて、それを開く試みが全くないという点においてClosed状態と同様です。 しかしながら、同輩接続要求はもう拒絶されません。
Upon receipt of a Configure-Request, a Configure-Request is
immediately transmitted and the Restart timer is started. The
received Configuration Options are examined and the proper
response is sent. If a Configure-Ack is sent, the Ack-Sent state
is entered. Otherwise, if a Configure-Nak or Configure-Reject is
sent, the Request-Sent state is entered. In either case, LCP
exits its passive state, and begins to actively open the
connection. Terminate-Ack packets are sent in response to either
Configure-Ack or Configure-Nak packets,
Configure-要求を受け取り次第、Configure-要求はすぐに伝えられます、そして、Restartタイマは始動されます。 容認されたConfiguration Optionsを調べます、そして、適切な応答を送ります。 Configure-Ackを送るなら、Ackによって送られた状態に入ります。 さもなければ、Configure-NakかConfigure-廃棄物を送るなら、Requestによって送られた状態に入ります。 どちらの場合ではも、LCPは不動態を出て、活発に接続を開き始めます。 Configure-AckかConfigure-Nakパケットのどちらかに対応してAckを終えているパケットを送ります。
The Restart timer is not running in the Listen state.
RestartタイマはListen状態に遺伝していません。
Perkins [Page 16] RFC 1134 PPP November 1989
パーキンス[16ページ]RFC1134ppp1989年11月
Request-Sent (3)
要求で、送ります。(3)
In the Request-Sent state an active attempt is made to open 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つは送りません。
Upon receipt of a Configure-Ack, the Ack-Received state is
immediately entered. Upon receipt of a Configure-Nak or
Configure-Reject, the Configure-Request Configuration Options are
adjusted appropriately, a new Configure-Request is transmitted,
and the Restart timer is restarted. Similarly, upon the
expiration of the Restart timer, a new Configure-Request is
transmitted and the Restart timer is restarted. Upon receipt of a
Configure-Request, the Configuration Options are examined and if
acceptable, a Configure-Ack is sent and the Ack-Sent state is
entered. If the Configuration Options are unacceptable, a
Configure-Nak or Configure-Reject is sent as appropriate.
Configure-Ackを受け取り次第、Ackによって容認された状態はすぐに、入られます。 Configure-NakかConfigure-廃棄物を受け取り次第、Configure-要求Configuration Optionsは適切に調整されます、そして、新しいConfigure-要求は伝えられます、そして、Restartタイマは再開されます。 同様に、Restartタイマの満了のときに新しいConfigure-要求は伝えられます、そして、Restartタイマは再開されます。 Configure-要求を受け取り次第、Configuration Optionsを調べます、そして、許容できるなら、Configure-Ackを送ります、そして、Ackによって送られた状態に入ります。 Configuration Optionsが容認できないなら、適宜Configure-NakかConfigure-廃棄物を送ります。
Since there is an outstanding Configure-Request in the Request-
Sent state, special care must be taken to implement the Passive-
Open and Close events; otherwise, it is possible for the LCP peer
to think the connection is open. Processing of either event
should be postponed until there is reasonable assurance that the
peer is not open. In particular, the Restart timer should be
allowed to expire.
傑出しているConfigure-要求がRequestの送られた状態にあるので、Passive開くのとClose出来事を実行するために特別な注意を払わなければなりません。 さもなければ、LCP同輩が、接続がオープンであると考えるのは、可能です。 同輩がオープンでないという手頃な保証があるまで、どちらかの出来事の処理は延期されるべきです。 特に、Restartタイマは期限が切れるはずであることができます。
Ack-Received (4)
Ackを受け取られていさせます。(4)
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 transmitted.
Ackによって容認された状態では、Configure-要求を送りました、そして、Configure-Ackを受け取りました。 Configure-Ackがまだ伝えられていないので、Restartタイマはまだ動いています。
Upon receipt of a Configure-Request with acceptable Configuration
Options, a Configure-Ack is transmitted, the Restart timer is
stopped and the Open state is entered. If the Configuration
Options are unacceptable, a Configure-Nak or Configure-Reject is
sent as appropriate. Upon the expiration of the Restart timer, a
new Configure-Request is transmitted, the Restart timer is
restarted, and the state machine returns to the Request-Sent
state.
許容できるConfiguration OptionsとのConfigure-要求を受け取り次第、Configure-Ackは伝えられます、そして、Restartタイマは止められます、そして、オープン状態は入られます。 Configuration Optionsが容認できないなら、適宜Configure-NakかConfigure-廃棄物を送ります。 Restartタイマの満了のときに、新しいConfigure-要求は送られます、そして、Restartタイマは再開されます、そして、州のマシンはRequestによって送られた状態に戻ります。
Ack-Sent (5)
Ackによって送られます。(5)
In the Ack-Sent state, a Configure-Ack and a Configure-Request
have been sent but a Configure-Ack has not yet been received. The
Restart timer is always running in the Ack-Sent state.
Ackによって送られた状態では、Configure-AckとConfigure-要求を送りましたが、まだConfigure-Ackを受け取っていません。 RestartタイマはいつもAckによって送られた状態に遺伝しています。
Perkins [Page 17] RFC 1134 PPP November 1989
パーキンス[17ページ]RFC1134ppp1989年11月
Upon receipt of a Configure-Ack, the Restart timer is stopped and
the Open state is entered. Upon receipt of a Configure-Nak or
Configure-Reject, the Configure-Request Configuration Options are
adjusted appropriately, a new Configure-Request is transmitted,
and the Restart timer is restarted. Upon the expiration of the
Restart timer, a new Configure-Request is transmitted, the Restart
timer is restarted, and the state machine returns to the Request-
Sent state.
Configure-Ackを受け取り次第、Restartタイマは止められます、そして、オープン状態は入られます。 Configure-NakかConfigure-廃棄物を受け取り次第、Configure-要求Configuration Optionsは適切に調整されます、そして、新しいConfigure-要求は伝えられます、そして、Restartタイマは再開されます。 Restartタイマの満了のときに、新しいConfigure-要求は送られます、そして、Restartタイマは再開されます、そして、州のマシンはRequestの送られた状態に戻ります。
Open (6)
開いてください。(6)
In the Open state, a connection exists and data may be
communicated over the link. The Restart timer is not running in
the Open state.
オープン州では、接続が存在しています、そして、データがリンクの上に伝えられるかもしれません。 Restartタイマはオープン状態に遺伝していません。
In normal operation, only two events cause transitions out of the
Open state. Upon receipt of a Close command, a Terminate-Request
is transmitted, the Restart timer is started, and the Closing
state is entered. Upon receipt of a Terminate-Request, a
Terminate-Ack is transmitted and the Closed state is entered.
Upon receipt of an Echo-Request, an Echo-Reply is transmitted.
Similarly, Echo-Reply and Discard-Request packets are silently
discarded or processed as expected. All other events cause
immediate transitions out of the Open state and should be handled
as if the state machine were in the Listen state.
通常の操作では、2回の出来事だけがオープン状態から変遷を引き起こします。 Closeコマンドを受け取り次第、Terminate-要求は伝えられます、そして、Restartタイマは始動されます、そして、Closing状態は入られます。 Terminate-要求を受け取り次第、Terminate-Ackは伝えられます、そして、Closed状態は入られます。 Echo-要求を受け取り次第、Echo-回答は伝えられます。 同様に、Echo-回答とDiscard-リクエスト・パケットは、予想されるように静かに捨てられるか、または処理されます。 他のすべての出来事が、オープン状態から即座の変遷を引き起こして、まるで州のマシンがListen状態にあるかのように扱われるべきです。
Closing (7)
閉じます。(7)
In the Closing state, an active attempt is made to close 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 receipt of a Terminate-Ack, the Closed state is immediately
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-Restart times,
this action may be skipped, and the Closed state may be entered.
Max-Restart MUST be a configurable parameter.
Terminate-Ackを受け取り次第、Closed状態はすぐに、入られます。 Restartタイマの満了のときに、新しいTerminate-要求は伝えられます、そして、Restartタイマは再開されます。 Restartタイマがマックス-再開時間を吐き出した後に、この動作はサボられるかもしれません、そして、Closed状態は入られるかもしれません。 マックス-再開は構成可能なパラメタであるに違いありません。
Since there is an outstanding Terminate-Request in the Closing
state, special care must be taken to implement the Passive-Open
event; otherwise, it is possible for the LCP peer to think the
connection is open. Processing of the Passive-Open event should
be postponed until there is reasonable assurance that the peer is
not open. In particular, the implementation should wait until the
state machine would normally transition to the Closed state
because of a Receive-Terminate-Ack event or Max-Restart Timeout
events.
傑出しているTerminate-要求がClosing状態にあるので、Passive-オープン・ゲームを実行するために特別な注意を払わなければなりません。 さもなければ、LCP同輩が、接続がオープンであると考えるのは、可能です。 同輩がオープンでないという手頃な保証があるまで、Passive-オープン・ゲームの処理は延期されるべきです。 特に、州のマシンは通常ReceiveがAckを終えている出来事かマックス-再開Timeout出来事によるClosed状態への変遷が待つだろうまで、実現は待つべきです。
Perkins [Page 18] RFC 1134 PPP November 1989
パーキンス[18ページ]RFC1134ppp1989年11月
4.2. Loop Avoidance
4.2. 輪の回避
Note that 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. If a timeout is implemented, it MUST be configurable.
プロトコルがConfiguration Optionネゴシエーション・ループを避けることへの合理的な試みをすることに注意してください。 しかしながら、プロトコルは、輪が起こらないのを保証しません。 どんな交渉のようにも、決して一点に集まらない闘争方針で2つのPPP実装を構成するのは可能です。 また、一点に集まりますが、そうするには重要な時間がかかる方針を構成するのも可能です。 作成者は、これを覚えておくべきであり、輪の検出がメカニズムか、より高い平らなタイムアウトであると実装するべきです。 タイムアウトが実装されるなら、構成可能であるに違いありません。
For example, implementations could take care to avoid Configure- Request or Terminate-Request livelocks by using a Max-Retries counter. A Configure-Request livelock could occur when an originating PPP sends and re-sends a C-R without receiving a reply (e.g., the receiving PPP entity may have died). A Terminate-Request livelock could occur when the originating PPP sends and re-sends a T-R without receiving a Terminate-Ack (e.g., the T-A may have been lost, but the remote PPP may have already terminated). Max-Retries indicates the number of packet retransmissions that are allowed before there is reasonable assurance that a livelock situation exists. Max-Retries MUST also be configurable, but should default to ten (10) retransmissions.
例えば、実装は、マックス-再試行カウンタを使用することによってConfigure要求かTerminate-要求livelocksを避けるために注意されることができました。 起因するPPPが回答を受け取らないでC-Rを送って、再送するとき(例えば受信PPP実体は消え失せたかもしれません)、Configure-要求livelockは現れることができました。 起因しているPPPがTerminate-Ackを受けないでT-Rを送って、再送するとき(例えばT-Aはなくされたかもしれませんが、リモートPPPは既に終わったかもしれません)、Terminate-要求livelockは現れることができました。 マックス-再試行はlivelock状況が存在しているという手頃な保証がある前に許容されているパケット「再-トランスミッション」の数を示します。 マックス-再試行は、また、構成可能でなければなりませんが、10(10)「再-トランスミッション」をデフォルトとするべきです。
4.3 Packet Format
4.3 パケット・フォーマット
Exactly one Link Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex c021 (Link Control Protocol).
ちょうど1つのLink Controlプロトコルパケットがプロトコル分野がタイプ十六進法c021を示す(Controlプロトコルをリンクしてください)PPP Data Link Layerフレームの情報分野でカプセルに入れられます。
A summary of the Link Control Protocol packet format is shown below. The fields are transmitted from left to right.
Link Controlプロトコルパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
The Code field is one octet and identifies the kind of LCP packet.
LCP Codes are assigned as follows:
Code分野は、1つの八重奏であり、LCPパケットの種類を特定します。 LCP Codesは以下の通り割り当てられます:
Perkins [Page 19] RFC 1134 PPP November 1989
パーキンス[19ページ]RFC1134ppp1989年11月
1 Configure-Request
2 Configure-Ack
3 Configure-Nak
4 Configure-Reject
5 Terminate-Request
6 Terminate-Ack
7 Code-Reject
8 Protocol-Reject
9 Echo-Request
10 Echo-Reply
11 Discard-Request
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.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。
Length
長さ
The Length field is two octets and indicates the length of the LCP
packet including the Code, Identifier, Length and Data fields.
Octets outside the range of the Length field should be treated as
Data Link Layer padding and should be ignored on reception.
Length分野は、2つの八重奏であり、Code、Identifier、Length、およびData分野を含むLCPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、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分野のそばで決定しています。
Regardless of which Configuration Options are enabled, all LCP packets are always sent in the full, standard form, as if no Configuration Options were enabled. This ensures that LCP Configure-Request packets are always recognizable even when one end of the link mistakenly believes the link to be Open.
どのConfiguration Optionsが有効にされるかにかかわらず、完全で、標準のフォームでいつもすべてのLCPパケットを送ります、まるでConfiguration Optionsが全く有効にされないかのように。 これはLCP Configure-リクエスト・パケットが確実にリンクの片端が、リンクがオープンであると誤って信じるときさえ、いつも認識可能になるようにします。
This document describes Version 1 of the Link Control Protocol. In the interest of simplicity, there is no version field in the LCP packet. If a new version of LCP is necessary in the future, the intention is that a new Data Link Layer Protocol field value should be used to differentiate Version 1 LCP from all other versions. A correctly functioning Version 1 LCP implementation will always respond to unknown Protocols (including other versions) with an easily recognizable Version 1 packet, thus providing a deterministic fallback mechanism for implementations of other versions.
このドキュメントはLink Controlプロトコルのバージョン1について説明します。 簡単さのために、バージョン分野は全くLCPパケットにありません。 LCPの新しいバージョンが将来必要であるなら、意志は新しいData Link Layerプロトコル分野価値が他のすべてのバージョンとバージョン1LCPを区別するのに使用されるべきであるということです。 正しく機能しているバージョン1LCP実装はいつも容易に認識可能なバージョン1パケットで未知のプロトコル(他のバージョンを含んでいる)に応じるでしょう、その結果、決定論的な後退メカニズムを他のバージョンの実装に提供します。
Perkins [Page 20] RFC 1134 PPP November 1989
パーキンス[20ページ]RFC1134ppp1989年11月
4.3.1. Configure-Request
4.3.1. 要求を構成します。
Description
記述
A LCP implementation wishing to open a connection MUST transmit a
LCP packet with the Code field set to 1 (Configure-Request) and
the Options field filled with any desired changes to the default
link Configuration Options.
接続を開くLCP実装願望は1(要求を構成している)に設定されたCode分野とデフォルトリンクConfiguration Optionsへのどんな必要な変化でも満たされたOptions分野でLCPパケットを伝えなければなりません。
Upon reception of a Configure-Request, an appropriate reply MUST
be transmitted.
Configure-要求のレセプションでは、適切な回答を伝えなければなりません。
A summary of the Configure-Request packet format is shown below. The fields are transmitted from left to right.
Configure-リクエスト・パケット形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
1 for Configure-Request.
1、要求を構成します。
Identifier
識別子
The Identifier field should be changed on each transmission. On
reception, the Identifier field should be copied into the
Identifier field of the appropriate reply packet.
各トランスミッションのときにIdentifier分野を変えるべきです。 レセプションでは、Identifier分野は適切な回答パケットのIdentifier分野にコピーされるべきです。
Options
オプション
The options field is variable in length and contains the list of
zero or more Configuration Options that the sender desires to
negotiate. All Configuration Options are always negotiated
simultaneously. The format of Configuration Options is further
described in a later section.
オプション分野は、長さで可変であり、ゼロのリストか送付者が交渉することを望んでいるより多くのConfiguration Optionsを含んでいます。 すべてのConfiguration Optionsが同時に、いつも交渉されます。 Configuration Optionsの形式は後のセクションでさらに説明されます。
4.3.2. Configure-Ack
4.3.2. Ackを構成します。
Description
記述
If every Configuration Option received in a Configure-Request is
both recognizable and acceptable, then a LCP implementation should
transmit a LCP packet with the Code field set to 2 (Configure-
Configure-要求に受け取られたあらゆるConfiguration Optionが認識可能であって、かつ許容できるならLCP実装がCode分野セットでLCPパケットを2に伝えるべきである、(構成
Perkins [Page 21] RFC 1134 PPP November 1989
パーキンス[21ページ]RFC1134ppp1989年11月
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.
Ack)、Identifier分野は受信されたConfigure要求からコピーされて、Options分野は受信されたConfigure-要求からコピーされました。 何らかの方法で承認されたConfiguration Optionsを再命令されてはいけないか、変更してはいけません。
On reception of a Configure-Ack, the Identifier field must match
that of the last transmitted Configure-Request, or the packet is
invalid. Additionally, the Configuration Options in a Configure-
Ack must match those of the last transmitted Configure-Request, or
the packet is invalid. Invalid packets should be silently
discarded.
Configure-Ackのレセプションに、Identifier分野が最後に伝えられたConfigure-要求のものを合わせなければならない、さもなければ、パケットは無効です。 さらに、Configure- AckのConfiguration Optionsが最後に伝えられたConfigure-要求のものに合わなければならない、さもなければ、パケットは無効です。 無効のパケットは静かに捨てられるべきです。
Reception of a valid Configure-Ack indicates that all
Configuration Options sent in the last Configure-Request are
acceptable.
有効なConfigure-Ackのレセプションは、最後のConfigure-要求で送られたすべてのConfiguration Optionsが許容できるのを示します。
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が同時に、いつも承認されます。
4.3.3. Configure-Nak
4.3.3. Nakを構成します。
Description
記述
If every element of the received Configuration Options is
容認されたConfiguration Optionsのあらゆる要素がそうなら
Perkins [Page 22] RFC 1134 PPP November 1989
パーキンス[22ページ]RFC1134ppp1989年11月
recognizable but some are not acceptable, then a LCP
implementation should transmit a LCP packet with the Code field
set to 3 (Configure-Nak), the Identifier field copied from the
received Configure-Request, and the Options field filled with only
the unacceptable Configuration Options from the Configure-Request.
All acceptable Configuration Options should be filtered out of the
Configure-Nak, but otherwise the Configuration Options from the
Configure-Request MUST NOT be reordered. Each of the nak'd
Configuration Options MUST be modified to a value acceptable to
the Configure-Nak sender. Finally, an implementation may be
configured to require the negotiation of a specific option. If
that option is not listed, then that option may be appended to the
list of nak'd Configuration Options in order to request the remote
end to list that option in its next Configure-Request packet. The
appended option must include a value acceptable to the Configure-
Nak sender.
認識可能である、或るものだけが許容できないで、次に、LCP実装はCode分野セットで3(Nakを構成している)にLCPパケットを伝えるべきであり、Identifier分野は受信されたConfigure-要求からコピーされて、Options分野はConfigure-要求から容認できないConfiguration Optionsだけで満ちました。 すべての許容できるConfiguration OptionsがConfigure-Nakからフィルターにかけられるべきですが、さもなければ、Configure-要求からのConfiguration Optionsを再命令してはいけません。 それぞれ、nakについて、Configure-Nak送付者にとって、許容できる値にConfiguration Optionsを変更しなければならないでしょうか? 最終的に、実装は、特定のオプションの交渉を必要とするように構成されるかもしれません。 そのオプションが記載されていないなら、nakのリストにオプションを追加するかもしれないその時が記載するだろう、Configuration Options、リモートを要求して、終わって、次のConfigure-リクエスト・パケットにそのオプションを記載してください。 追加されたオプションはConfigure- Nak送付者にとって、許容できる値を含まなければなりません。
On reception of a Configure-Nak, the Identifier field must match
that of the last transmitted Configure-Request, or the packet is
invalid and should be silently discarded.
Configure-Nakのレセプションに、Identifier分野が最後に伝えられたConfigure-要求のものを合わせなければならないか、パケットは、無効であり、静かに捨てられるべきです。
Reception of a valid Configure-Nak indicates that a new
Configure-Request should be sent with the Configuration Options
modified as specified in the Configure-Nak.
有効なConfigure-Nakのレセプションは、Configuration Optionsが変更されている状態で新しいConfigure-要求がConfigure-Nakで指定されるように送られるべきであるのを示します。
A summary of the Configure-Nak packet format is shown below. The fields are transmitted from left to right.
Configure-Nakパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
3 for Configure-Nak.
3、Nakを構成します。
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Configure-Request which caused this Configure-Nak.
Identifier分野はこのConfigure-Nakを引き起こしたConfigure-要求のIdentifier分野のコピーです。
Options
オプション
The Options field is variable in length and contains the list of
分野が長さで可変であり、リストを含むOptions
Perkins [Page 23] RFC 1134 PPP November 1989
パーキンス[23ページ]RFC1134ppp1989年11月
zero or more Configuration Options that the sender is nak'ing.
All Configuration Options are always nak'd simultaneously.
送付者がそうであるゼロか、より多くのConfiguration Options、nak'ing。 いつもすべてのConfiguration Optionsがそうです。nakは同時に、そうするでしょう。
4.3.4. Configure-Reject
4.3.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 manager), then a LCP implementation should
transmit a LCP packet with the Code field set to 4 (Configure-
Reject), the Identifier field copied from the received Configure-
Request, and the Options field filled with only the unrecognized
Configuration Options from the Configure-Request. All
recognizable and negotiable Configuration Options must be filtered
out of the Configure-Reject, but otherwise the Configuration
Options MUST not be reordered.
Configure-要求に受け取られたいくつかのConfiguration Optionsが認識可能でないか、または交渉において、許容できないなら(ネットワークマネージャによって構成されるように)、LCP実装はCode分野セットでLCPパケットを4に伝えるべきです、そして、(廃棄物を構成してください)Identifier分野は受信されたConfigure要求からコピーされました、そして、Options分野はConfigure-要求から認識されていないConfiguration Optionsだけで満ちました。 Configure-廃棄物からすべての認識可能で交渉可能なConfiguration Optionsをフィルターにかけなければなりませんが、さもなければ、Configuration Optionsを再命令してはいけません。
On reception of a Configure-Reject, the Identifier field must
match that of the last transmitted Configure-Request, or the
packet is invalid. Additionally, the Configuration Options in a
Configure-Reject must be a proper subset of those in the last
transmitted Configure-Request, or the packet is invalid. Invalid
packets should be silently discarded.
Configure-廃棄物のレセプションに、Identifier分野が最後に伝えられたConfigure-要求のものを合わせなければならない、さもなければ、パケットは無効です。 さらに、Configure-廃棄物のConfiguration Optionsは最後に伝えられたConfigure-要求におけるそれらの真部分集合であるに違いありませんかパケットが無効です。 無効のパケットは静かに捨てられるべきです。
Reception of a 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-廃棄物に記載されたConfiguration Optionsのいずれも含んでいない新しいConfigure要求が送られるべきであるのを示します。
A summary of the Configure-Reject packet format is shown below. The fields are transmitted from left to right.
Configure-廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+
Code
コード
4 for Configure-Reject.
4、廃棄物を構成します。
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Configure-Request which caused this Configure-Reject.
Identifier分野はこのConfigure-廃棄物を引き起こしたConfigure-要求のIdentifier分野のコピーです。
Perkins [Page 24] RFC 1134 PPP November 1989
パーキンス[24ページ]RFC1134ppp1989年11月
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が同時に、いつも拒絶されます。
4.3.5. Terminate-Request and Terminate-Ack
4.3.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 Physical Layer indicates that it has gone down, or a
sufficiently large number have been transmitted such that the
remote end is down with reasonable certainty.
接続を終えるのがCode分野セットでLCPパケットを5に伝えるべきであることを(要求を終えている)願って、DataがさばくLCP実装はどんな必要なデータでも満ちました。 Requestを終えているパケットが、Terminate-Ackが受け取られているまで送られ続けているはずであるか、Physical Layerが、それが落ちたのを示すか、または十分大きい数が伝えられたので、リモートエンドが妥当な確実性と共にあります。
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
connection has been closed.
unelicited Terminate-Ackのレセプションは、接続が閉店したのを示します。
A summary of the Terminate-Request and Terminate-Ack packet formats is shown below. The fields are transmitted from left to right.
Terminate-要求とTerminate-Ackパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
5 for Terminate-Request;
5、要求を終えます。
6 for Terminate-Ack.
6、Ackを終えます。
Perkins [Page 25] RFC 1134 PPP November 1989
パーキンス[25ページ]RFC1134ppp1989年11月
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。
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 established value
for the peer's MRU.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した値まで同輩のMRUのためのどんな長さのものであるかもしれません。
4.3.6. Code-Reject
4.3.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-Packet
field.
未知のCodeとのLCPパケットのレセプションは、交信しているLCP実装の1つが不完全であるか、または不完全であることを示します。 Code分野セットで7(コード廃棄物)にLCPパケットを伝えることによって、未知のCodeの送付者にこの誤りの報告を持ちかえらなければなりませんでした、そして、誘発しているパケットはRejected-パケット分野にコピーされました。
Upon reception of a Code-Reject, a LCP implementation should make
an immediate transition to the Closed state, and should report the
error, since it is unlikely that the situation can be rectified
automatically.
Code-廃棄物のレセプションに関して、LCP実装は、Closed状態への即座の変遷をするべきであり、誤りを報告するべきです、自動的に事態を収拾できるのがありそうもないので。
A summary of the Code-Reject packet format is shown below. The fields are transmitted from left to right.
Code-廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Packet ...
+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拒絶されたパケット… +-+-+-+-+-+-+-+-+
Code
コード
7 for Code-Reject.
7 コード廃棄物のために。
Identifier
識別子
The Identifier field is one octet and is for use by the
transmitter.
Identifier分野は、1つの八重奏であり、送信機による使用のためのものです。
Perkins [Page 26] RFC 1134 PPP November 1989
パーキンス[26ページ]RFC1134ppp1989年11月
Rejected-Packet
拒絶されたパケット
The Rejected-Packet field contains a copy of the LCP packet which
is being rejected. It begins with the rejected Code field; it
does not include any PPP Data Link Layer headers. The Rejected-
Packet should be truncated to comply with the established value of
the peer's MRU.
Rejected-パケット分野は拒絶されているLCPパケットのコピーを含んでいます。 それは拒絶されたCode分野で始まります。 それはどんなPPP Data Link Layerヘッダーも含んでいません。 Rejectedパケットは、同輩のMRUの確立した値に従うために先端を切られるべきです。
4.3.7. Protocol-Reject
4.3.7. プロトコル廃棄物
Description
記述
Reception of a PPP frame with an unknown Data Link Layer Protocol
indicates that the remote end is attempting to use a protocol
which is unsupported at the local end. This typically occurs when
the remote end attempts to configure a new, but unsupported
protocol. If the LCP state machine is in the Open state, then
this error MUST be reported back to the sender of the unknown
protocol 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 Data field filled with any desired data.
未知のData Link LayerプロトコルがあるPPPフレームのレセプションは、リモートエンドが、地方の終わりにサポートされないプロトコルを使用するのを試みているのを示します。 リモートエンドが、新しい、しかし、サポートされないプロトコルを構成するのを試みるとき、これは通常起こります。 LCP州のマシンがオープン状態にあるなら、Code分野セットで8(プロトコル廃棄物)にLCPパケットを伝えることによって、未知のプロトコルの送付者にこの誤りの報告を持ちかえらなければなりませんでした、そして、Rejected-プロトコル分野は容認されたプロトコルにセットしました、そして、Data分野はどんな必要なデータでも満ちました。
Upon reception of a Protocol-Reject, a LCP implementation should
stop transmitting frames of the indicated protocol.
プロトコル廃棄物のレセプションでは、LCP実装は、示されたプロトコルのフレームを伝えるのを止めるべきです。
Protocol-Reject packets may only be sent in the LCP Open state.
Protocol-Reject packets received in any state other than the LCP
Open state should be discarded and no further action should be
taken.
LCPオープン状態でプロトコル廃棄物パケットを送るだけであるかもしれません。 LCPオープン状態以外のどんな状態にも受け取られたプロトコル廃棄物パケットを捨てるべきです、そして、さらなる行動を全く取るべきではありません。
A summary of the Protocol-Reject packet format is shown below. The fields are transmitted from left to right.
プロトコル廃棄物パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Protocol | Rejected-Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拒絶されたプロトコル| 拒絶された情報… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
8 for Protocol-Reject.
8 プロトコル廃棄物のために。
Identifier
識別子
The Identifier field is one octet and is for use by the
Identifier分野は、ある八重奏であり、使用のためのものです。
Perkins [Page 27] RFC 1134 PPP November 1989
パーキンス[27ページ]RFC1134ppp1989年11月
transmitter.
送信機。
Rejected-Protocol
拒絶されたプロトコル
The Rejected-Protocol field is two octets and contains the
Protocol of the Data Link Layer frame which is being rejected.
Rejected-プロトコル分野は、2つの八重奏であり、拒絶されているData Link Layerフレームのプロトコルを含んでいます。
Rejected-Information
拒絶された情報
The Rejected-Information field contains a copy from the frame
which is being rejected. It begins with the Information field,
and does not include any PPP Data Link Layer headers or the FCS.
The Rejected-Information field should be truncated to comply with
the established value of the peer's MRU.
Rejected-情報フィールドは拒絶されているフレームからのコピーを含んでいます。 それは、情報分野で始まって、どんなPPP Data Link LayerヘッダーかFCSも含んでいません。 Rejected-情報フィールドは、同輩のMRUの確立した値に従うために先端を切られるべきです。
4.3.8. Echo-Request and Echo-Reply
4.3.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) and the Data field filled with any desired
data, up to but not exceeding the receivers established MRU.
Echo-要求送付者はCode分野セットで9(エコー要求)にLCPパケットを伝えます、そして、Data分野は上がっていますが、受信機を超えていない少しの必要なデータでも確立したMRUをいっぱいにしました。
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, and the
Data field copied from the Echo-Request, truncating as necessary
to avoid exceeding the peer's established MRU.
Echo-要求のレセプションでは、Code分野セットで10(エコー回答)にLCPパケットを伝えなければなりませんでした、そして、Identifier分野は受信されたEcho-要求からコピーされました、そして、Data分野は、同輩の確立したMRUを超えているのを避けるためにEcho-要求、必要に応じて先端を切るのからコピーされました。
Echo-Request and Echo-Reply packets may only be sent in the LCP
Open state. Echo-Request and Echo-Reply packets received in any
state other than the LCP Open state should be discarded and no
further action should be taken.
LCPオープン状態でエコー要求とEcho-回答パケットを送るだけであるかもしれません。 LCPオープン状態以外のどんな状態にも受け取られたエコー要求と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-回答パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
Perkins [Page 28] RFC 1134 PPP November 1989
パーキンス[28ページ]RFC1134ppp1989年11月
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
識別子
The Identifier field is one octet and aids in matching Echo-
Requests and Echo-Replies.
Identifier分野は、合っているEcho要求とEcho-回答で1つの八重奏と援助です。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting
loopbacked links. Unless modified by a Configuration Option, the
Magic-Number MUST always be transmitted as zero and MUST always be
ignored on reception. Further use of the Magic-Number is beyond
the scope of this discussion.
マジックナンバーフィールドは、loopbackedリンクを検出することにおいて4つの八重奏と援助です。 Configuration Optionによって変更されない場合、マジック数をゼロとしていつも伝えなければならなくて、レセプションでいつも無視しなければなりません。 マジック数のさらなる使用はこの議論の範囲を超えています。
Data
データ
The Data field is zero or more octets and contains uninterpreted
data for use by the sender. The data may consist of any binary
value and may be of any length from zero to the established value
for the peer's MRU.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した値まで同輩のMRUのためのどんな長さのものであるかもしれません。
4.3.9. Discard-Request
4.3.9. 要求を捨てます。
Description
記述
LCP includes a Discard-Request Code in order to provide a Data
Link Layer data sink mechanism for use in exercising the local to
remote direction of the link. This is useful as an aid in
debugging, performance testing, and and for numerous other
functions.
LCPは、リンクのリモート方向への地方を運動させることにおける使用にData Link Layerデータ受信端末メカニズムを提供するためにDiscard-要求Codeを含んでいます。 これはデバッグにおける援助、機能をテストしてそして、他の多数の機能のための性能として役に立ちます。
A discard sender transmits a LCP packet with the Code field set to
11 (Discard-Request) and the Data field filled with any desired
破棄、11(破棄して要求する)に設定されたCode分野とData分野が望まれているいずれでもいっぱいにされている状態で、送付者はLCPパケットを伝えます。
Perkins [Page 29] RFC 1134 PPP November 1989
パーキンス[29ページ]RFC1134ppp1989年11月
data, up to but not exceeding the receivers established MRU.
データであり、超過だけでないまで、受信機はMRUを設立しました。
A discard receiver MUST simply throw away an Discard-Request that
it receives.
受信機が単にそうしなければならない破棄は受信するというDiscard-要求を無駄にします。
Discard-Request packets may only be sent in the LCP Open state.
LCPオープン状態でRequestを捨てているパケットを送るだけであるかもしれません。
A summary of the Discard-Request packet formats is shown below. The fields are transmitted from left to right.
Discard-リクエスト・パケット形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
11 for Discard-Request.
11、破棄して要求します。
Identifier
識別子
The Identifier field is one octet and is for use by the Discard-
Request transmitter.
Identifier分野は、1つの八重奏であり、Discard要求送信機による使用のためのものです。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting
loopbacked links. Unless modified by a configuration option, the
Magic-Number MUST always be transmitted as zero and MUST always be
ignored on reception. Further use of the Magic-Number is beyond
the scope of this discussion.
マジックナンバーフィールドは、loopbackedリンクを検出することにおいて4つの八重奏と援助です。 設定オプションで変更されない場合、マジック数をゼロとしていつも伝えなければならなくて、レセプションでいつも無視しなければなりません。 マジック数のさらなる使用はこの議論の範囲を超えています。
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 established value
for the peer's MRU.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した値まで同輩のMRUのためのどんな長さのものであるかもしれません。
4.4. Configuration Options
4.4. 設定オプション
LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated.
LCP Configuration Optionsは、ポイントツーポイント接続の標準の特性への変更が交渉されるのを許容します。
Perkins [Page 30] RFC 1134 PPP November 1989
パーキンス[30ページ]RFC1134ppp1989年11月
Negotiable modifications include such things as the maximum receive unit, async control character mapping, the link authentication method, the link encryption method, etc.. The Configuration Options themselves are described in separate documents. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
交渉可能な変更は最大がユニット、async制御文字マッピング、リンク認証方法、リンク暗号化メソッドを受けるのなどようなものを含んでいます。 Configuration Options自身は別々のドキュメントで説明されます。 Configuration OptionがConfigure-リクエスト・パケットに含まれていないなら、そのConfiguration Optionのためのデフォルト値は想定されます。
The end of the list of Configuration Options is indicated by the end of the LCP packet.
Configuration Optionsのリストの終わりはLCPパケットの端までに示されます。
Unless otherwise specified, a specific Configuration Options should be listed no more than once in a Configuration Options list. Specific Configuration Options may override this general rule and may be listed more than once. The effect of this is Configuration Option specific and is specified by each such Configuration Option.
別の方法で指定されない場合、特定のConfiguration OptionsはConfiguration Optionsリストの一度より多くの記載されたノーであるべきです。 特定のConfiguration Optionsは一度よりこの一般的な規則をくつがえして、もう少し記載されているかもしれません。 この効果は、Configuration Option特有であり、そのような各Configuration Optionによって指定されます。
Also unless otherwise specified, all Configuration Options apply in a half-duplex fashion. When negotiated, they apply to only one direction of the link, typically in the receive direction when interpreted from the point of view of the Configure-Request sender.
また、別の方法で指定されない場合、すべてのConfiguration Optionsが半二重ファッションで適用します。 交渉されています、彼らがいつリンクの一方向だけに通常適用するか、Configure-要求送付者の観点から解釈されたら、方向を受けてください。
4.4.1. Format
4.4.1. 形式
A summary of the Configuration Option format is shown below. The fields are transmitted from left to right.
Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
The Type field is one octet and indicates the type of
Configuration Option. The most up-to-date values of the Type
field are specified in the most recent "Assigned Numbers" RFC
[11].
Type分野は、1つの八重奏であり、Configuration Optionのタイプを示します。 Type分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。
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の長さを示します。 Configure要求に交渉可能なConfiguration Optionを受け取りますが、無効のLengthと共に適切なLengthとDataと必要なConfiguration Optionを含んでいるConfigure-Nakを伝えるなら。
Perkins [Page 31] RFC 1134 PPP November 1989
パーキンス[31ページ]RFC1134ppp1989年11月
Data
データ
The Data field is zero or more octets and indicates the value or
other information for this Configuration Option. The format and
length of the Data field is determined by the Type and Length
fields.
Data分野は、ゼロか、より多くの八重奏であり、このConfiguration Optionのための値か他の情報を示します。 Data分野の形式と長さはTypeとLength分野のそばで決定しています。
5. A PPP Network Control Protocol (NCP) for IP
5. IPのためのpppネットワーク制御プロトコル(NCP)
The IP Control Protocol (IPCP) is responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. IPCP packets may not be exchanged until LCP has reached the network-layer Protocol Configuration Negotiation phase. Likewise, IP datagrams may not be exchanged until IPCP has first opened the connection.
ポイントツーポイント接続の両端でIPプロトコルがモジュールであると構成して、可能にして、無効にするのにIP Controlプロトコル(IPCP)は原因となります。 Link Controlプロトコルのように、これはパケットの交換を通して達成されます。 LCPがネットワーク層プロトコルConfiguration Negotiationフェーズに達するまで、IPCPパケットは交換されないかもしれません。 同様に、IPCPが最初に接続を開くまで、IPデータグラムは交換されないかもしれません。
The IP Control Protocol is exactly the same as the Link Control Protocol with the following exceptions:
IP Controlプロトコルはまさに以下の例外でLink Controlプロトコルと同じです:
Data Link Layer Protocol Field
データリンク層プロトコル分野
Exactly one IP Control Protocol packet is encapsulated in the
Information field of PPP Data Link Layer frames where the Protocol
field indicates type hex 8021 (IP Control Protocol).
ちょうど1つのIP Controlプロトコルパケットがプロトコル分野が、タイプが8021(IP Controlプロトコル)人に魔法をかけるのを示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Code field
コード分野
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes should be treated as
unrecognized and should result in Code-Rejects.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
Timeouts
タイムアウト
IPCP packets may not be exchanged until the Link Control Protocol
has reached the network-layer Protocol Configuration Negotiation
phase. An implementation should be prepared to wait for Link
Quality testing to finish before timing out waiting for a
Configure-Ack or other response. It is suggested that an
implementation give up only after user intervention or a
configurable amount of time.
Link Controlプロトコルがネットワーク層プロトコルConfiguration Negotiationフェーズに達するまで、IPCPパケットは交換されないかもしれません。 実装は以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのをLink Qualityテストを待つように準備されるべきです。 実装がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。
Configuration Option Types
設定オプションタイプ
The IPCP has a separate set of Configuration Options. The most
up-to-date values of the type field are specified in the most
recent "Assigned Numbers" RFC [11].
IPCPには、Configuration Optionsの別々のセットがあります。 タイプ分野の最も最新の値は最新の「規定番号」RFC[11]で指定されます。
Perkins [Page 32] RFC 1134 PPP November 1989
パーキンス[32ページ]RFC1134ppp1989年11月
5.1. Sending IP Datagrams
5.1. 送付IPデータグラム
Before any IP packets may be communicated, both the Link Control Protocol and the IP Control Protocol must reach the Open state.
どんなIPパケットも伝えられるかもしれない前に、Link ControlプロトコルとIP Controlプロトコルの両方がオープン状態に達しなければなりません。
Exactly one IP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0021 (Internet Protocol).
ちょうど1つのIPパケットがプロトコル分野が、タイプが0021(インターネットプロトコル)人に魔法をかけるのを示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
The maximum length of an IP packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger IP datagrams must be fragmented as necessary. If a system wishes to avoid fragmentation and reassembly, it should use the TCP Maximum Segment Size option [12], or a similar mechanism, to discourage others from sending large datagrams.
PPPリンクの上に伝えられたIPパケットの最大の長さはPPPデータ・リンク層フレームの情報分野の最大の長さと同じです。 必要に応じてより大きいIPデータグラムを断片化しなければなりません。 システムが断片化を避けて、再アセンブリしたいなら、それは、他のものが大きいデータグラムを送るのを思いとどまるのにTCP Maximum Segment Sizeオプション[12]、または同様のメカニズムを使用するべきです。
A. Asynchronous HDLC
A。 非同期なHDLC
This appendix summarizes the modifications to ISO 3309-1979 proposed in ISO 3309:1984/PDAD1. These modifications allow HDLC to be used with 8-bit asynchronous links.
This appendix summarizes the modifications to ISO 3309-1979 proposed in ISO 3309:1984/PDAD1. These modifications allow HDLC to be used with 8-bit asynchronous links.
Transmission Considerations
Transmission Considerations
Each octet is delimited by a start and a stop element.
Each octet is delimited by a start and a stop element.
Flag Sequence
Flag Sequence
The Flag Sequence is a single octet and indicates the beginning or
end of a frame. The Flag Sequence consists of the binary sequence
01111110 (hexadecimal 0x7e).
The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e).
Transparency
Transparency
On asynchronous links, a character stuffing procedure is used.
The Control Escape octet is defined as binary 01111101
(hexadecimal 0x7d) where the bit positions are numbered 87654321
(not 76543210, BEWARE).
On asynchronous links, a character stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d) where the bit positions are numbered 87654321 (not 76543210, BEWARE).
After FCS computation, the transmitter examines the entire frame
between the two Flag Sequences. Each Flag Sequence, Control
Escape octet and octet with value less than hexadecimal 0x20 is
replaced by a two character sequence consisting of the Control
Escape octet and the original octet with bit 6 complemented (i.e.,
exclusive-or'd with hexadecimal 0x20).
After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence, Control Escape octet and octet with value less than hexadecimal 0x20 is replaced by a two character sequence consisting of the Control Escape octet and the original octet with bit 6 complemented (i.e., exclusive-or'd with hexadecimal 0x20).
Prior to FCS computation, the receiver examines the entire frame
between the two Flag Sequences. For each Control Escape octet,
Prior to FCS computation, the receiver examines the entire frame between the two Flag Sequences. For each Control Escape octet,
Perkins [Page 33] RFC 1134 PPP November 1989
Perkins [Page 33] RFC 1134 PPP November 1989
that octet is removed and bit 6 of the following octet is
complemented. A Control Escape octet immediately preceding the
closing Flag Sequence indicates an invalid frame.
that octet is removed and bit 6 of the following octet is complemented. A Control Escape octet immediately preceding the closing Flag Sequence indicates an invalid frame.
Note: The inclusion of all octets less than hexadecimal 0x20
allows all ASCII control characters [10] excluding DEL (Delete)
to be transparently communicated through almost all known data
communications equipment.
Note: The inclusion of all octets less than hexadecimal 0x20 allows all ASCII control characters [10] excluding DEL (Delete) to be transparently communicated through almost all known data communications equipment.
A few examples may make this more clear. Packet data is
transmitted on the link as follows:
A few examples may make this more clear. Packet data is transmitted on the link as follows:
0x7e is encoded as 0x7d, 0x5e.
0x7d is encoded as 0x7d, 0x5d.
0x01 is encoded as 0x7d, 0x21.
0x7e is encoded as 0x7d, 0x5e. 0x7d is encoded as 0x7d, 0x5d. 0x01 is encoded as 0x7d, 0x21.
Aborting a Transmission
Aborting a Transmission
On asynchronous links, frames may be aborted by transmitting a "0"
stop bit where a "1" bit is expected (framing error) or by
transmitting a Control Escape octet followed immediately by a
closing Flag Sequence.
On asynchronous links, frames may be aborted by transmitting a "0" stop bit where a "1" bit is expected (framing error) or by transmitting a Control Escape octet followed immediately by a closing Flag Sequence.
Inter-frame Time Fill
Inter-frame Time Fill
On asynchronous links, inter-octet and inter-frame time fill
should be accomplished by transmitting continuous "1" bits (mark-
hold state).
On asynchronous links, inter-octet and inter-frame time fill should be accomplished by transmitting continuous "1" bits (mark- hold state).
Note: On asynchronous links, inter-frame time fill can be
viewed as extended inter-octet time fill. Doing so can save
one octet for every frame, decreasing delay and increasing
bandwidth. This is possible since a Flag Sequence may serve as
both a frame close and a frame begin. After having received
any frame, an idle receiver will always be in a frame begin
state.
Note: On asynchronous links, inter-frame time fill can be viewed as extended inter-octet time fill. Doing so can save one octet for every frame, decreasing delay and increasing bandwidth. This is possible since a Flag Sequence may serve as both a frame close and a frame begin. After having received any frame, an idle receiver will always be in a frame begin state.
Robust transmitters should avoid using this trick over-
zealously since the price for decreased delay is decreased
reliability. Noisy links may cause the receiver to receive
garbage characters and interpret them as part of an incoming
frame. If the transmitter does not transmit a new opening Flag
Sequence before sending the next frame, then that frame will be
appended to the noise characters causing an invalid frame (with
high reliability). Transmitters should avoid this by
transmitting an open Flag Sequence whenever "appreciable time"
has elapsed since the prior closing Flag Sequence. It is
suggested that implementations will achieve the best results by
Robust transmitters should avoid using this trick over- zealously since the price for decreased delay is decreased reliability. Noisy links may cause the receiver to receive garbage characters and interpret them as part of an incoming frame. If the transmitter does not transmit a new opening Flag Sequence before sending the next frame, then that frame will be appended to the noise characters causing an invalid frame (with high reliability). Transmitters should avoid this by transmitting an open Flag Sequence whenever "appreciable time" has elapsed since the prior closing Flag Sequence. It is suggested that implementations will achieve the best results by
Perkins [Page 34] RFC 1134 PPP November 1989
Perkins [Page 34] RFC 1134 PPP November 1989
always sending an opening Flag Sequence if the new frame is not
back-to-back with the last. The maximum value for "appreciable
time" is likely to be no greater than the typing rate of a slow
to average typist, say 1 second.
always sending an opening Flag Sequence if the new frame is not back-to-back with the last. The maximum value for "appreciable time" is likely to be no greater than the typing rate of a slow to average typist, say 1 second.
B. Fast Frame Check Sequence (FCS) Implementation
B. Fast Frame Check Sequence (FCS) Implementation
B.1. FCS Computation Method
B.1. FCS Computation Method
The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. The table is created by the code in section 2.
The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. The table is created by the code in section 2.
/*
* FCS lookup table as calculated by the table generator in section 2.
*/
static unsigned short fcstab[256] = {
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
/* * FCS lookup table as calculated by the table generator in section 2. */ static unsigned short fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
Perkins [Page 35] RFC 1134 PPP November 1989
Perkins [Page 35] RFC 1134 PPP November 1989
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
};
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 };
#define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */
#define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */
/*
* Calculate a new fcs given the current fcs and the new data.
*/
unsigned short pppfcs(fcs, cp, len)
register unsigned short fcs;
register unsigned char *cp;
register int len;
{
while (len--)
fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
/* * Calculate a new fcs given the current fcs and the new data. */ unsigned short pppfcs(fcs, cp, len) register unsigned short fcs; register unsigned char *cp; register int len; { while (len--) fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
return (fcs);
}
return (fcs); }
B.2. Fast FCS table generator
B.2. Fast FCS table generator
The following code creates the lookup table used to calculate the FCS.
The following code creates the lookup table used to calculate the FCS.
/*
* Generate a FCS table for the HDLC FCS.
*
* Drew D. Perkins at Carnegie Mellon University.
*
* Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
*/
/* * Generate a FCS table for the HDLC FCS. * * Drew D. Perkins at Carnegie Mellon University. * * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. */
/*
* The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408).
*/
#define P 0x8408
/* * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408). */ #define P 0x8408
main()
{
register unsigned int b, v;
register int i;
main() { register unsigned int b, v; register int i;
printf("static unsigned short fcstab[256] = {");
for (b = 0; ; ) {
if (b % 8 == 0)
printf("static unsigned short fcstab[256] = {"); for (b = 0; ; ) { if (b % 8 == 0)
Perkins [Page 36] RFC 1134 PPP November 1989
Perkins [Page 36] RFC 1134 PPP November 1989
printf("0);
printf("0);
v = b;
for (i = 8; i--; )
v = v & 1 ? (v >> 1) ^ P : v >> 1;
v = b; for (i = 8; i--; ) v = v & 1 ? (v >> 1) ^ P : v >> 1;
printf("0x%04x", v & 0xFFFF);
printf("0x%04x", v & 0xFFFF);
if (++b == 256)
break;
printf(",");
}
printf("0;0);
}
if (++b == 256) break; printf(","); } printf("0;0); }
References
References
[1] Electronic Industries Association, "Interface Between Data
Terminal Equipment and Data Communications Equipment Employing
Serial Binary Data Interchange", EIA Standard RS-232-C, August
1969.
[1] Electronic Industries Association, "Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange", EIA Standard RS-232-C, August 1969.
[2] International Organization For Standardization, "Data
Communication - High-level Data Link Control Procedures - Frame
Structure", ISO Standard 3309-1979, 1979.
[2] International Organization For Standardization, "Data Communication - High-level Data Link Control Procedures - Frame Structure", ISO Standard 3309-1979, 1979.
[3] International Organization For Standardization, "Data
Communication - High-level Data Link Control Procedures -
Elements of Procedures", ISO Standard 4335-1979, 1979.
[3] International Organization For Standardization, "Data Communication - High-level Data Link Control Procedures - Elements of Procedures", ISO Standard 4335-1979, 1979.
[4] International Organization For Standardization, "Data
Communication - High-Level Data Link Control Procedures -
Elements of Procedures - Addendum 1", ISO Standard 4335-
1979/Addendum 1, 1979.
[4] International Organization For Standardization, "Data Communication - High-Level Data Link Control Procedures - Elements of Procedures - Addendum 1", ISO Standard 4335- 1979/Addendum 1, 1979.
[5] International Organization For Standardization, "Information
Processing Systems - Data Communication - High-level Data Link
Control Procedures - Frame structure - Addendum 1: Start/stop
Transmission", Proposed Draft International Standard ISO
3309:1983/PDAD1, 1984.
[5] International Organization For Standardization, "Information Processing Systems - Data Communication - High-level Data Link Control Procedures - Frame structure - Addendum 1: Start/stop Transmission", Proposed Draft International Standard ISO 3309:1983/PDAD1, 1984.
[6] International Telecommunication Union, CCITT Recommendation X.25,
"Interface Between Data Terminal Equipment (DTE) and Data Circuit
Terminating Equipment (DCE) for Terminals Operating in the Packet
Mode on Public Data Networks", CCITT Red Book, Volume VIII,
Fascicle VIII.3, Rec. X.25., October 1984.
[6] International Telecommunication Union, CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks", CCITT Red Book, Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984.
Perkins [Page 37] RFC 1134 PPP November 1989
Perkins [Page 37] RFC 1134 PPP November 1989
[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September
1986.
[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983. Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September 1986.
[8] LeVan, J., "A Fast CRC", Byte, November 1987.
[8] LeVan, J., "A Fast CRC", Byte, November 1987.
[9] American National Standards Institute, "American National
Standard Code for Information Interchange", ANSI X3.4-1977, 1977.
[9] American National Standards Institute, "American National Standard Code for Information Interchange", ANSI X3.4-1977, 1977.
[10] Postel, J., "Internet Protocol", RFC 791, USC/Information
Sciences Institute, September 1981.
[10] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981.
[11] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 1010,
USC/Information Sciences Institute, May 1987.
[11] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 1010, USC/Information Sciences Institute, May 1987.
[12] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC 879, USC/Information Sciences Institute, November
1983.
[12] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November 1983.
Security Considerations
Security Considerations
Security issues are not addressed in this memo.
Security issues are not addressed in this memo.
Author's Address
Author's Address
This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair:
This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair:
Russ Hobby UC Davis Computing Services Davis, CA 95616
Russ Hobby UC Davis Computing Services Davis, CA 95616
Phone: (916) 752-0236
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.edu
EMail: rdhobby@ucdavis.edu
Acknowledgments
Acknowledgments
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: Ken Adelman (TGV), Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz (cisco systems) and Asher Waldfogel (Wellfleet).
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: Ken Adelman (TGV), Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz (cisco systems) and Asher Waldfogel (Wellfleet).
Perkins [Page 38]
Perkins [Page 38]
一覧
スポンサーリンク
