RFC1171 日本語訳
1171 Point-to-Point Protocol for the transmission of multi-protocoldatagrams over Point-to-Point links. D. Perkins. July 1990. (Format: TXT=92321 bytes) (Obsoletes RFC1134) (Obsoleted by RFC1331) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Perkins Request for Comments: 1171 CMU Obsoletes: RFC 1134 July 1990
コメントを求めるワーキンググループD.パーキンス要求をネットワークでつないでください: 1171 米カーネギーメロン大学は以下を時代遅れにします。 RFC1134 1990年7月
The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links
ポイントツーポイント接続の上のマルチプロトコルデータグラムの送信のための二地点間プロトコル
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定します。
Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.
このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。
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.
この提案はPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 IETF Pointからポイントへのプロトコル作業部会いすにこのメモのコメントを提出するべきです。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
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)以外に他のネットワーク層プロトコルを構成して、利用するための制御プロトコルによって開発されると予想されます。
Perkins [Page i] RFC 1171 Point-to-Point Protocol July 1990
1171年のPointからポイントのパーキンス[ページi]RFCプロトコル1990年7月
Table of Contents
目次
1. Introduction .......................................... 1 1.1 Motivation ...................................... 1 1.2 Overview of PPP ................................. 1 1.3 Organization of the document .................... 2
1. 序論… 1 1.1動機… 1 pppの1.2概要… 1 1.3 ドキュメントの組織… 2
2. Physical Layer Requirements ........................... 3
2. 物理的な層の要件… 3
3. The Data Link Layer ................................... 4 3.1 Frame Format .................................... 5
3. データ・リンク層… 4 3.1 形式を縁どってください… 5
4. The PPP Link Control Protocol (LCP) ................... 9 4.1 The LCP Automaton ............................... 11 4.1.1 Overview ........................................ 11 4.1.2 State Diagram ................................... 11 4.1.3 State Transition Table .......................... 13 4.1.4 Events .......................................... 13 4.1.5 Actions ......................................... 16 4.1.6 States .......................................... 17 4.2 Loop Avoidance .................................. 20 4.3 Timers and Counters ............................. 20 4.4 Packet Format ................................... 21 4.4.1 Configure-Request ............................... 23 4.4.2 Configure-Ack ................................... 24 4.4.3 Configure-Nak ................................... 25 4.4.4 Configure-Reject ................................ 27 4.4.5 Terminate-Request and Terminate-Ack ............. 29 4.4.6 Code-Reject ..................................... 31 4.4.7 Protocol-Reject ................................. 32 4.4.8 Echo-Request and Echo-Reply ..................... 34 4.4.9 Discard-Request ................................. 36 4.5 Configuration Options ........................... 38 4.5.1 Format .......................................... 39
4. pppは制御プロトコル(LCP)をリンクします… 9 4.1 LCPオートマトン… 11 4.1 .1概要… 11 4.1 .2 ダイヤグラムを述べてください… 11 4.1 .3 変遷テーブルを述べてください… 13 4.1 .4のイベント… 13 4.1 .5の動作… 16 4.1 .6 述べます。 17 4.2 回避を輪にしてください… 20 4.3台のタイマとカウンタ… 20 4.4 パケット形式… 21 4.4 .1 要求を構成します… 23 4.4 .2 Ackを構成します… 24 4.4 .3 Nakを構成します… 25 4.4 .4 廃棄物を構成します… 27 4.4 .5 要求を終えてAckを終えます… 29 4.4 .6コード廃棄物… 31 4.4 .7プロトコル廃棄物… 32 4.4 .8のエコー要求とエコー・リプライ… 34 4.4 .9 …を破棄して要求してください… 36 4.5 構成オプション… 38 4.5 .1 形式… 39
5. A PPP Network Control Protocol (NCP) for IP ........... 40 5.1 Sending IP Datagrams ............................ 40
5. pppネットワークはIPのためにプロトコル(NCP)を制御します… 40 5.1 IPデータグラムを送ります… 40
APPENDICES ................................................... 42
付録… 42
A. Asynchronous HDLC ..................................... 42
A.の非同期なHDLC… 42
B. Fast Frame Check Sequence (FCS) Implementation ........ 44 B.1 FCS Computation Method .......................... 44 B.2 Fast FCS table generator ........................ 46
B.の速いフレームチェックシーケンス(FCS)実装… 44B.1 FCS計算メソッド… 44 B.2の速いFCSはジェネレータをテーブルの上に置きます… 46
REFERENCES ................................................... 47
参照… 47
Perkins [Page ii] RFC 1171 Point-to-Point Protocol July 1990
1171年のPointからポイントのパーキンス[ページii]RFCプロトコル1990年7月
SECURITY CONSIDERATIONS ...................................... 48
セキュリティ問題… 48
CHAIRMAN'S ADDRESS ........................................... 48
委員長のアドレス… 48
Perkins [Page iii] RFC 1171 Point-to-Point Protocol July 1990
1171年のPointからポイントのパーキンス[ページiii]RFCプロトコル1990年7月
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 every host supports point-to-point connections. For example, asynchronous RS-232-C [1] interfaces are essentially ubiquitous.
ここ数年間で、インターネットは、ホストの数における爆発的成長がTCP/IPをサポートしているのを見ました。 これらのホストのかなりの大部分が様々なタイプ(最も一般的なイーサネット)のローカル・エリア・ネットワーク(LAN)に接続されます。 他のホストの大部分はX.25スタイルPublic Data Networks(PDNs)などのワイドエリアネットワーク(WAN)を通して接されます。 比較的、これらのホストのわずかしか簡単な二地点間(すなわち、連続の)のリンクに接続されません。 しかし、データ通信の最も古いメソッドの中にポイントツーポイント接続があります、そして、ほとんどすべてのホストが二地点間接続をサポートします。 例えば、非同期なRS232C[1]インタフェースは本質的には遍在しています。
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 circuit switched point-to-point circuits (e.g., dialups).
このメモの1つの目的はこの問題を改善することです。 しかし、まさしくカプセル化体系よりさらに重要に、Pointからポイントへのプロトコルは提案します。 指すポイントリンクは、ネットワーク・プロトコルの現在のファミリーに関する多くの問題を悪化させる傾向があります。 例えば、IPアドレスの課題と管理(LAN環境においてさえ問題である)は回路の切り換えられた二地点間回路(例えば、ダイアルアップ)の上に特に難しいです。
Some additional issues addressed by this specification of 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. At this time, PPP specifies the use of
1. シリーズの上でデータグラムをカプセル化するためのメソッドはリンクされます。 PPPはデータグラムがある程度ポイントの上のリンクであるとカプセル化する基礎としてHDLCを使用します。 このとき、PPPは使用を指定します。
Perkins [Page 1] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[1ページ]RFC1171 1990年7月
asynchronous or synchronous duplex circuits, either dedicated or circuit switched.
非同期であるか同期の複式の回路、捧げられたどちらかまたは回路が切り替わりました。
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 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は最初に、構成するパケットをLCPに送って、データ・リンクをテストに送るでしょう。 そして、リンクがあった後、設立、任意の施設は必要に応じてLCP、PPPが1つ以上のネットワーク層プロトコルを選んで、構成するためにNCPパケットを送る起因することで交渉されました。 いったんそれぞれの選ばれたネットワーク層プロトコルを構成すると、各ネットワーク層プロトコルからのデータグラムをリンクの上に送ることができます。
The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (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)計算のための効率的な索表アルゴリズムを説明します。
Perkins [Page 2] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[2ページ]RFC1171 1990年7月
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 circuit switched, which can operate in either an asynchronous (start/stop) or synchronous bit-serial mode, transparent to PPP Data Link Layer frames. PPP does not impose any restrictions regarding transmission rate, other than those imposed by the particular DTE/DCE interface in use.
PointからポイントへのプロトコルはどんなDTE/DCEインタフェース(例えば、EIA RS232C、EIA RS-422、EIA RS-423、およびCCITT V.35)の向こう側にも作動できます。 PPPによって課された唯一の絶対条件が捧げられた複式の回路の設備であるか回路(非同期な(始め/停止)かシンクロナスビット連続のモードのどちらかで作動できる)は切り替わりました、PPP Data Link Layerフレームに、透明です。 PPPは特定のDTE/DCEインタフェースによって使用中に課されたもの以外の通信速度に関する少しの制限も課しません。
PPP does not require 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)などのように。 しかしながら、利用可能であるときに、そのような信号を使用すると、より大きい機能性と性能を許容できます。
Perkins [Page 3] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[3ページ]RFC1171 1990年7月
3. The Data Link Layer
3. データ・リンク層
The Point-to-Point Protocol uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) High-level Data Link Control (HDLC) procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/stop transmission" [5]. ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments.
Pointからポイントへのプロトコルが国際標準化機構(ISO)のハイレベルのData Link Control(HDLC)手順の原則、用語、および枠組構造を使用する、(ISO3309によって変更されるようなISO3309-1979[2])、1984/PDAD1、「付加物1:」 「始め/停止送信」[5]。 ISO3309-1979は同期環境における使用にHDLC枠組構造を指定します。 ISO3309: 1984/PDAD1は、非同期な環境における使用を許すためにISO3309-1979への提案された変更を指定します。
The PPP control procedures use the definitions and Control field encodings standardized in ISO 4335-1979 [3] and ISO 4335- 1979/Addendum 1-1979 [4]. The PPP frame structure is also consistent with CCITT Recommendation X.25 LAPB [6], since that too is based on HDLC.
PPPコントロール手順はISO4335-1979[3]とISO4335- 1979/付加物1-1979[4]で標準化された定義とControl分野encodingsを使用します。 また、それもHDLCに基づいているので、PPP枠組構造もCCITT Recommendation X.25 LAPB[6]と一致しています。
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にまとめられます。
Perkins [Page 4] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[4ページ]RFC1171 1990年7月
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 | 11111111 | 00000011 | 16 bits | * +----------+----------+----------+----------+------------ ---+---------+----------+ | FCS | Flag | | 16 bits | 01111110 | ---+---------+----------+
+----------+----------+----------+----------+------------ | 旗| アドレス| コントロール| プロトコル| 情報| 01111110 | 11111111 | 00000011 | 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 standards documents.
一般的なインターネット習慣と一致していたままで残って、読書RFCsに慣れている人々のために混乱を避けるために、Least Significant Bitオーダーには以下の記述におけるすべての2進の数がMost Significant Bitにあります、左から右まで読んで、別の方法で示されない場合。 これが標準のISOとCCITT習慣に合わないことに注意してください(伝えられるようにビットを配置します)(すなわち、ネットワークはオーダーに噛み付きました)。 世界規格ドキュメントとこのドキュメントを比べるときにはこれを覚えておいてください。
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. The use of other address lengths and values may be defined at a later time, or by prior agreement. Frames with unrecognized Addresses should be reported through the normal network management facility.
Address分野は、ただ一つの八重奏であり、2進の系列11111111(16進0xff)、All-駅のアドレスを含んでいます。 PPPは個々のステーションアドレスを割り当てません。 いつもAll駅のアドレスを認識して、受け取るべきです。 他のアドレスの長さと値の使用は後で、またはあらかじめ取り決めて定義されるかもしれません。 認識されていないAddressesがあるフレームは正常なネットワークマネージメント施設で報告されるべきです。
Control Field
制御フィールド
The Control field is a single octet and contains the binary
Control分野は、ただ一つの八重奏であり、バイナリーを含んでいます。
Perkins [Page 5] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[5ページ]RFC1171 1990年7月
sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the P/F bit set to zero. Frames with other Control field values should be silently discarded.
系列00000011(16進0x03)、ゼロに設定されたP/FビットによるUnnumbered情報(UI)コマンド。 他の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 [12]. Initial values are also listed below.
プロトコル分野は2つの八重奏です、そして、値はフレームの情報分野で要約されたプロトコルを特定します。 プロトコル分野の最も最新の値は最新の「規定番号」RFC[12]で指定されます。 また、初期の値は以下に記載されています。
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 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[6ページ]RFC1171 1990年7月
The Protocol field is initially assigned as follows:
プロトコル分野は初めは、以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
0001 to 001f reserved (transparency inefficient) 0021 Internet Protocol 0023 * OSI Network Layer 0025 * Xerox NS IDP 0027 * DECnet Phase IV 0029 * Appletalk 002b * Novell IPX 002d * Van Jacobson Compressed TCP/IP 1 002f * Van Jacobson Compressed TCP/IP 2
001fへの0001は0021年の(透明効率の悪い)のインターネットプロトコル0023*OSI Network Layer0025*ゼロックスNS IDP0027*DECnet Phase IV0029*Appletalk 002b*ノベルIPX 002d*ヴァンジェーコブソンCompressed TCP/IP1 002f*ヴァンジェーコブソンCompressed TCP/IP2を予約しました。
8021 Internet Protocol Control Protocol 8023 * OSI Network Layer Control Protocol 8025 * Xerox NS IDP Control Protocol 8027 * DECnet Phase IV Control Protocol 8029 * Appletalk Control Protocol 802b * Novell IPX Control Protocol 802d * Reserved 802f * Reserved
8021インターネットプロトコル制御プロトコル8023*OSIネットワーク層制御プロトコル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 octets 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 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[7ページ]RFC1171 1990年7月
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], [8], and [9].
以下に注意してください。 16ビットのFCSアルゴリズムの速くて、テーブル駆動の実現はAppendixにB.This実現が[7]、[8]、および[9]に基づいているのが示されます。
Modifications to the Basic Frame Format
基本枠形式への変更
The Link Control Protocol can negotiate modifications to the standard PPP frame structure. However, modified frames will always be clearly distinguishable from standard frames.
Link Controlプロトコルは標準のPPP枠組構造への変更を交渉できます。 しかしながら、変更されたフレームは標準のフレームから区別可能にいつも明確になるでしょう。
Perkins [Page 8] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[8ページ]RFC1171 1990年7月
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 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オープン状態への変遷に続いて、LCPは任意のLink Quality Determinationフェーズを許容します。 このフェーズでは、リンクは、リンク品質がネットワーク層プロトコルを持って来るために十分であるかどうか決定するためにテストされます。 このフェーズは完全に任意です。 このフェーズが完成するまで、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
LCPがいったんLink Quality Determinationフェーズを終えると、ネットワーク層プロトコルは、いつでも、別々に適切なNetwork Controlプロトコル(NCP)によって構成されて、持って来られて、降ろされるかもしれません。 LCPがリンクを閉じるなら、それは、適切な状態で取ることができるようにネットワーク層プロトコルを知らせます。
Perkins [Page 9] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[9ページ]RFC1171 1990年7月
action.
動作。
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はいつでも、リンクを終えるかもしれません。 通常、キャリヤーの損失、または活動していない期間のタイマの満了などの物理的な出来事のために起こるかもしれないのを除いて、人間のユーザの依頼でこれをするでしょう。
Perkins [Page 10] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[10ページ]RFC1171 1990年7月
4.1. The LCP Automaton
4.1. LCPオートマトン
4.1.1. Overview
4.1.1. 概観
LCP is specified by a number of packet formats and a finite-state automaton. This section presents an overview of the LCP automaton, 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を終えて、終わります)
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 automaton 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 automaton 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 11] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[11ページ]RFC1171 1990年7月
+------------------------------+ | | V | +---2---+ PO +---1---+ RTA +---7---+ | | |<-------------| |<-----------| | | |Listen | |Closed | |Closing| | RCR | | C | | PLD | | | +----| |----->+------>| |<---Any | |<--+ | |scr +-------+ ^ +-------+ State +-------+ | | | | AO | ^ | TO | | | +-----------+ --- | | +---->+ | | | SCR | | str ^ | | C | RCN/TO | | C | | | --- | +-------->+<--------+ | --- | | | | | 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| | str^| | C| RCN/| | C| | | --- | +-------->+<。--------+ | --- | | | | | 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 RTR - Receive-Terminate-Req or Reject RTA - Receive-Terminate-Ack str - Send Terminate-Req AO - Active-Open sta - Sent Terminate-Ack PO - Passive-Open C - Close TO - Timeout
または、または、RCR--、受信、要求を構成してください、scr--Configure-要求RCAを送ってください--、受信、Ack scaを構成してください、--Configure-Ack RCNを送ってください--、受信、Nakを構成してください、Reject scn--Configure-Nak RTRを送ってください--、受信、Reqを終えてください、Reject RTA--、受信、Ack strを終えてください、--受け身に開いているC--近いTO--タイムアウトをアクティブに開いているsta--Terminate-Ack POを送るというTerminate-Req AOに送ってください
Perkins [Page 12] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[12ページ]RFC1171 1990年7月
PLD - Physical-Layer-Down
PLD--物理的な層の下
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/2 scj/1 scj/1 scj/1 scj/1 1 scj/7 RER | sta/1 sta/2 3 4 5 ser/6 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/2scj/1scj/1scj/1scj/1 1scj/7RER| sta/1sta/2 3 4 5ser/6 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
LCP州のマシンでの変遷と動作は出来事によって引き起こされます。 いくつかの出来事が地方の終わり(例えば、開いているActive、開いているPassive、およびClose)に実行されたコマンドで引き起こされて、他のものがリモートエンドからパケットの領収書で引き起こされる、(例えば、要求を構成していて、ReceiveがAckを構成していて、ReceiveがNakを構成しているReceive Receive、要求を終えてReceiveがAckを終える、)、それでも、他のものは始められたRestartタイマの満了で引き起こされます。
Perkins [Page 13] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[13ページ]RFC1171 1990年7月
the result of other events (e.g., Timeout).
他の出来事(例えば、Timeout)の結果。
Following is a list of LCP events.
以下に、LCP出来事のリストがあります。
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
有効なConfigure-Ackであるときに、ReceiveがAckを構成している出来事は起こります。
Perkins [Page 14] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[14ページ]RFC1171 1990年7月
packet is received from the LCP peer. The Configure-Ack packet is a positive response to a Configure-Request packet.
LCP同輩からパケットを受け取ります。 Configure-AckパケットはConfigure-リクエスト・パケットへの積極的な応答です。
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層がダウンしている出来事は起こります。
Perkins [Page 15] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[15ページ]RFC1171 1990年7月
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動作のリストがあります。
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であるという信念を確認します。
Perkins [Page 16] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[16ページ]RFC1171 1990年7月
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状態への即座の変遷を引き起こす回復不能エラーです。
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
Configure-要求を受け取り次第、Configure-要求はすぐに伝えられます、そして、Restartタイマは始動されます。 容認されたConfiguration Optionsを調べます、そして、適切な応答を送ります。 Ackに送りにされるのが、Configure-Ackが送られると述べるなら
Perkins [Page 17] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[17ページ]RFC1171 1990年7月
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-NakかConfigure-廃棄物を送るなら、Requestによって送られた状態に入ります。 どちらの場合ではも、LCPは不動態を出て、活発に接続を開き始めます。 Configure-AckかConfigure-Nakパケットのどちらかに対応してAckを終えているパケットを送ります。
The Restart timer is not running in the Listen state.
RestartタイマはListen状態に遺伝していません。
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
許容できるConfiguration OptionsとのConfigure-要求を受け取り次第、Configure-Ackは伝えられます、そして、Restartタイマは止められます、そして、オープン状態は入られます。 Configuration Optionsが容認できないなら、適宜Configure-NakかConfigure-廃棄物を送ります。 Restartタイマの満了のときに、新しいConfigure-要求は伝えられます、そして、Restartタイマは再開されます、そして、州のマシンはRequestによって送りにされるのに戻ります。
Perkins [Page 18] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[18ページ]RFC1171 1990年7月
state.
状態。
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によって送られた状態に遺伝しています。
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
傑出しているTerminate-要求がClosingにあるので
Perkins [Page 19] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[19ページ]RFC1171 1990年7月
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.
Passive-オープン・ゲームを実装するために状態、特別な注意を払わなければなりません。 さもなければ、LCP同輩が、接続がオープンであると考えるのは、可能です。 同輩がオープンでないという手頃な保証があるまで、Passive-オープン・ゲームの処理は延期されるべきです。 特に、州のマシンは通常ReceiveがAckを終えているイベントかマックス-再開TimeoutイベントによるClosed状態への変遷が待つだろうまで、実装は待つべきです。
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実装を構成するのは可能です。 また、一点に集まりますが、そうするには重要な時間がかかる方針を構成するのも可能です。 作成者は、これを覚えておくべきであり、輪の検出がメカニズムか、より高い平らなタイムアウトであると実装するべきです。 タイムアウトが実装されるなら、構成可能であるに違いありません。
4.3. Timers and Counters
4.3. タイマとカウンタ
There is one special timer used by LCP, the Restart timer. 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, and the corresponding Configure-Request or Terminate-Request packet retransmission. The Restart timer MUST be configurable, but should default to three (3) seconds.
LCPによって使用された、1個の特別なタイマ、Restartタイマがあります。 RestartタイマはConfigure-要求とTerminate-リクエスト・パケットのタイムアウトトランスミッションに使用されます。 Restartタイマの満了はTimeoutイベント、および対応するConfigure-要求かTerminate-リクエスト・パケット「再-トランスミッション」を引き起こします。 Restartタイマは、構成可能でなければなりませんが、3(3)秒をデフォルトとするはずです。
There is one additional restart parameter, Max-Restarts. Max- Restarts indicates the number of packet retransmissions that are required before there is reasonable assurance that the link closed. Max-Restarts MUST also be configurable, but should default to ten (10) retransmissions.
1つの追加再開パラメタであり、マックスと同じくらい再開します。 マックスRestartsはリンクが閉じたという手頃な保証がある前に必要であるパケット「再-トランスミッション」の数を示します。 マックス-再開は、また、構成可能でなければなりませんが、10(10)「再-トランスミッション」をデフォルトとするべきです。
Perkins [Page 20] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[20ページ]RFC1171 1990年7月
4.4. Packet Format
4.4. パケット・フォーマット
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は以下の通り割り当てられます:
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分野の範囲の外での八重奏は扱われるべきです。
Perkins [Page 21] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[21ページ]RFC1171 1990年7月
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 22] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[22ページ]RFC1171 1990年7月
4.4.1. Configure-Request
4.4.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の形式は後のセクションでさらに説明されます。
Perkins [Page 23] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[23ページ]RFC1171 1990年7月
4.4.2. Configure-Ack
4.4.2. Ackを構成します。
Description
記述
If every Configuration Option received in a Configure-Request is both recognizable and acceptable, then a LCP implementation should transmit a LCP packet with the Code field set to 2 (Configure- Ack), the Identifier field copied from the received Configure- Request, and the Options field copied from the received Configure-Request. The acknowledged Configuration Options MUST NOT be reordered or modified in any way.
Configure-要求に受け取られたあらゆるConfiguration Optionが認識可能であって、かつ許容できるなら、LCP実装はCode分野セットでLCPパケットを2に伝えるべきです、そして、(Ackを構成してください)Identifier分野は受信されたConfigure要求からコピーされました、そして、Options分野は受信されたConfigure-要求からコピーされました。 何らかの方法で承認されたConfiguration Optionsを再命令されてはいけないか、変更してはいけません。
On reception of a Configure-Ack, the Identifier field must match that of the last transmitted Configure-Request, 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
Options分野は、長さで可変であり、送付者はConfiguration Optionsですが、ゼロか以上のリストを含んでいます。
Perkins [Page 24] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[24ページ]RFC1171 1990年7月
acknowledging. All Configuration Options are always acknowledged simultaneously.
承認します。 すべてのConfiguration Optionsが同時に、いつも承認されます。
4.4.3. Configure-Nak
4.4.3. Nakを構成します。
Description
記述
If every element of the received Configuration Options is recognizable but some are not acceptable, then a LCP implementation should transmit a LCP packet with the Code field set to 3 (Configure-Nak), the Identifier field copied from the received Configure-Request, and the Options field filled with only the unacceptable Configuration Options from the Configure-Request. All acceptable Configuration Options 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.
容認されたConfiguration Optionsのあらゆる要素が認識可能ですが、或るものが許容できないなら、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を構成します。
Perkins [Page 25] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[25ページ]RFC1171 1990年7月
Identifier
識別子
The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Nak.
Identifier分野はこのConfigure-Nakを引き起こしたConfigure-要求のIdentifier分野のコピーです。
Options
オプション
The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is nak'ing. All Configuration Options are always nak'd simultaneously.
Options分野は、長さで可変であり、ゼロのリストか、より多くのConfiguration Optionsを含んでいます。送付者はnak'ingです。 いつもすべてのConfiguration Optionsがそうです。nakは同時に、そうするでしょう。
Perkins [Page 26] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[26ページ]RFC1171 1990年7月
4.4.4. Configure-Reject
4.4.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 27] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[27ページ]RFC1171 1990年7月
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が同時に、いつも拒絶されます。
Perkins [Page 28] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[28ページ]RFC1171 1990年7月
4.4.5. Terminate-Request and Terminate-Ack
4.4.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を終えます。
Identifier
識別子
The Identifier field is one octet and aids in matching requests and replies.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。
Perkins [Page 29] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[29ページ]RFC1171 1990年7月
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 maximum Information field length minus four.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した最大の情報フィールド長まで4を引いたどんな長さのものであるかもしれません。
Perkins [Page 30] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[30ページ]RFC1171 1990年7月
4.4.6. Code-Reject
4.4.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つの八重奏であり、送信機による使用のためのものです。
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 maximum Information field length.
Rejected-パケット分野は拒絶されているLCPパケットのコピーを含んでいます。 それは拒絶されたCode分野で始まります。 それはどんなPPP Data Link Layerヘッダーも含んでいません。 Rejectedパケットは、確立した最大の情報フィールド長に従うために先端を切られるべきです。
Perkins [Page 31] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[31ページ]RFC1171 1990年7月
4.4.7. Protocol-Reject
4.4.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 transmitter.
Identifier分野は、1つの八重奏であり、送信機による使用のためのものです。
Rejected-Protocol
拒絶されたプロトコル
The Rejected-Protocol field is two octets and contains the Protocol of the Data Link Layer frame which is being rejected.
Rejected-プロトコル分野は、2つの八重奏であり、拒絶されているData Link Layerフレームのプロトコルを含んでいます。
Perkins [Page 32] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[32ページ]RFC1171 1990年7月
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 maximum Information field length.
Rejected-情報フィールドは拒絶されているフレームからのコピーを含んでいます。 それは、情報分野で始まって、どんなPPP Data Link LayerヘッダーかFCSも含んでいません。 Rejected-情報フィールドは、確立した最大の情報フィールド長に従うために先端を切られるべきです。
Perkins [Page 33] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[33ページ]RFC1171 1990年7月
4.4.8. Echo-Request and Echo-Reply
4.4.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 receiver's established maximum Information field length minus eight.
9(エコー要求)に設定されたCode分野とData分野がどんな必要なデータでもいっぱいにされて、上がっているLCPパケットを伝えますが、Echo-要求送付者は受信機の確立した最大の情報フィールド長を超えていません8。
Upon reception of an Echo-Request, a LCP packet MUST be transmitted with the Code field set to 10 (Echo-Reply), the Identifier field copied from the received Echo-Request, and the Data field copied from the Echo-Request, truncating as necessary to avoid exceeding the peer's established maximum Information field length.
Echo-要求のレセプションでは、Code分野セットで10(エコー回答)にLCPパケットを伝えなければなりませんでした、そして、Identifier分野は受信されたEcho-要求からコピーされました、そして、Data分野は、同輩の確立した最大の情報フィールド長を超えているのを避けるために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-回答パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 エコー・リプライのために。
Perkins [Page 34] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[34ページ]RFC1171 1990年7月
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 maximum Information field length minus eight.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した最大の情報フィールド長まで8を引いたどんな長さのものであるかもしれません。
Perkins [Page 35] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[35ページ]RFC1171 1990年7月
4.4.9. Discard-Request
4.4.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 data, up to but not exceeding the receiver's established maximum Information field length minus eight.
しかし送付者が8を引いて受信機の確立した最大の情報フィールド長を超えないことで11(破棄して要求する)に設定されたCode分野とData分野がどんな必要なデータでもいっぱいにされて、上がっているLCPパケットを伝える破棄。
A discard receiver MUST simply throw away an Discard-Request that it receives.
受信機が単にそうしなければならない破棄は受信するというDiscard-要求を無駄にします。
Discard-Request packets may only be sent in the LCP 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
マジックナンバーフィールドは、loopbackedリンクを検出することにおいて4つの八重奏と援助です。 設定オプションで変更されない場合、マジック数をゼロとしていつも伝えなければならなくて、レセプションでいつも無視しなければなりません。 マジック数のさらなる使用は向こうにあります。
Perkins [Page 36] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[36ページ]RFC1171 1990年7月
the scope of this discussion.
この議論の範囲。
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 maximum Information field length minus four.
Data分野は、ゼロか、より多くの八重奏であり、送付者による使用のために非解釈されたデータを含んでいます。 データは、どんな2進の価値からも成って、ゼロ〜確立した最大の情報フィールド長まで4を引いたどんな長さのものであるかもしれません。
Perkins [Page 37] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[37ページ]RFC1171 1990年7月
4.5. Configuration Options
4.5. 設定オプション
LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated. Negotiable modifications include such things as the maximum receive unit, async control character mapping, the link authentication method, etc. 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.
LCP Configuration Optionsは、ポイントツーポイント接続の標準の特性への変更が交渉されるのを許容します。 交渉可能な変更は最大がユニット、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 Option 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 OptionはConfiguration Optionsリストの一度より多くの記載されたノーであるべきです。 特定のConfiguration Optionsは一度よりこの一般的な規則をくつがえして、もう少し記載されているかもしれません。 この効果は、Configuration Option特有であり、そのような各Configuration Optionによって指定されます。
Also unless otherwise specified, all Configuration Options apply in a half-duplex fashion. When negotiated, they apply to only one direction of the link, typically in the receive direction when interpreted from the point of view of the Configure-Request sender.
また、別の方法で指定されない場合、すべてのConfiguration Optionsが半二重ファッションで適用します。 交渉されています、彼らがいつリンクの一方向だけに通常適用するか、Configure-要求送付者の観点から解釈されたら、方向を受けてください。
Perkins [Page 38] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[38ページ]RFC1171 1990年7月
4.5.1. Format
4.5.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 [12].
Type分野は、1つの八重奏であり、Configuration Optionのタイプを示します。 Type分野の最も最新の値は最新の「規定番号」RFC[12]で指定されます。
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を伝えるなら。
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分野のそばで決定しています。
Perkins [Page 39] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[39ページ]RFC1171 1990年7月
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. IPCP packets received before this phase is reached should be silently discarded. Likewise, IP datagrams may not be exchanged until IPCP has first opened the connection (reached the Open state).
IP Controlプロトコル(IPCP)はポイントツーポイント接続の両端でIPプロトコルモジュールを構成して、可能にして、無効にするのに原因となります。 Link Controlプロトコルのように、これはパケットの交換を通して達成されます。 LCPがNetwork-層のプロトコルConfiguration Negotiationフェーズに達するまで、IPCPパケットは交換されないかもしれません。 このフェーズに達する前に受け取られた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 [12].
IPCPには、Configuration Optionsの別々のセットがあります。 タイプ分野の最も最新の値は最新の「規定番号」RFC[12]で指定されます。
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プロトコルの両方がオープン状態に達しなければなりません。
Perkins [Page 40] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[40ページ]RFC1171 1990年7月
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 [13], or a similar mechanism, to discourage others from sending large datagrams.
PPPリンクの上に伝えられたIPパケットの最大の長さはPPPデータ・リンク層フレームの情報分野の最大の長さと同じです。 必要に応じてより大きいIPデータグラムを断片化しなければなりません。 システムが断片化を避けて、再アセンブリしたいなら、それは、他のものが大きいデータグラムを送るのを思いとどまるのにTCP Maximum Segment Sizeオプション[13]、または同様のメカニズムを使用するべきです。
Perkins [Page 41] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[41ページ]RFC1171 1990年7月
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.
この付録はISO3309で提案されたISO3309-1979への変更をまとめます: 1984/PDAD1。 これらの変更は、HDLCが8ビットの非同期なリンクと共に使用されるのを許容します。
Transmission Considerations
トランスミッション問題
Each octet is delimited by a start and a stop element.
各八重奏は始めとストップ・エレメントによって区切られます。
Flag Sequence
フラグ・シーケンス
The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e).
Flag Sequenceはただ一つの八重奏であり、フレームの始めか端を示します。 Flag Sequenceは2進の系列01111110(16進0x7e)から成ります。
Transparency
透明
On asynchronous links, a character stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d) where the bit positions are numbered 87654321 (not 76543210, BEWARE).
非同期なリンクでは、キャラクタ詰め物の手順は使用されています。 Control Escape八重奏はビット位置が番号付の87654321(76543210、BEWAREでない)である2進の01111101(16進0x7d)と定義されます。
After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence, Control Escape octet and octet with value less than hexadecimal 0x20 is replaced by a two octet sequence consisting of the Control Escape octet and the original octet with bit 6 complemented (i.e., exclusive-or'd with hexadecimal 0x20).
FCS計算の後に、送信機は2Flag Sequencesの間の全体のフレームを調べます。 各Flag Sequence、Control Escape八重奏、および値が16進0x20をビット6によるControl Escape八重奏から成る系列とオリジナルの八重奏が補足となった2八重奏に取り替えるより(すなわち、排他的論理和は16進0x20でそうするでしょう)少ない八重奏。
Prior to FCS computation, the receiver examines the entire frame between the two Flag Sequences. Each octet with value less than hexadecimal 0x20 is simply removed (it may have been inserted by intervening data communications equipment). For each Control Escape octet, that octet is also removed, but bit 6 of the following octet is complemented. A Control Escape octet immediately preceding the closing Flag Sequence indicates an invalid frame.
FCS計算の前に、受信機は2Flag Sequencesの間の全体のフレームを調べます。 単に値が16進0x20より少ない各八重奏を取り除きます(それはデータ通信装置に介入することによって、挿入されたかもしれません)。 また、それぞれのControl Escape八重奏において、その八重奏を取り除きますが、以下の八重奏のビット6は補足となります。 すぐに終わりのFlag Sequenceに先行するControl Escape八重奏は無効のフレームを示します。
Note: The inclusion of all octets less than hexadecimal 0x20 allows all ASCII control characters [10] excluding DEL (Delete) to be transparently communicated through almost all known data communications equipment.
以下に注意してください。 16進0x20より少ないすべての八重奏の包含は、ほとんどすべての知られているデータ通信装置を通って透明にコミュニケートするために、DEL(削除する)を除きながら、すべてのASCII制御文字[10]を許容します。
A few examples may make this more clear. Packet data is transmitted on the link as follows:
いくつかの例がこの以上を明らかにするかもしれません。 パケットデータは以下のリンクの上に送られます:
0x7e is encoded as 0x7d, 0x5e.
0x7eは0x7d、0x5eとしてコード化されます。
Perkins [Page 42] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[42ページ]RFC1171 1990年7月
0x7d is encoded as 0x7d, 0x5d. 0x01 is encoded as 0x7d, 0x21.
0x7dは0x7d、0x5dとしてコード化されます。 0×01 0x7d、0×21として、コード化されます。
Aborting a Transmission
トランスミッションを中止します。
On asynchronous links, frames may be aborted by transmitting a "0" stop bit where a "1" bit is expected (framing error) or by transmitting a Control Escape octet followed immediately by a closing Flag Sequence.
非同期なリンクの上では、フレームがaを伝えることによって中止されるかもしれない、「0インチのストップビット、どこ、「1インチのビットが予想されたか(誤りを縁どっていて)、または伝わることによって、コントロールエスケープ八重奏はすぐ終わりのフラグ・シーケンスで続いたか」。
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).
非同期なリンクでは、相互八重奏とインターフレームタイム・フィルは、連続した「1インチのビット(マーク保持状態)」を伝えることによって、実行されるべきです。
Note: On asynchronous links, inter-frame time fill can be viewed as extended inter-octet time fill. Doing so can save one octet for every frame, decreasing delay and increasing bandwidth. This is possible since a Flag Sequence may serve as both a frame close and a frame begin. After having received any frame, an idle receiver will always be in a frame begin state.
以下に注意してください。 非同期なリンクの上では、拡張相互八重奏タイム・フィルとしてインターフレームタイム・フィルを見なすことができます。 遅れを減少させて、帯域幅を増加させて、そうするのは各フレームあたり1つの八重奏を救うことができます。 フレーム閉鎖とフレームの両方が始まるときFlag Sequenceが役立つかもしれないので、これは可能です。 どんなフレームも受けた後に、使用されていない受信機はフレームで状態を始めるためにいつもことになるでしょう。
Robust transmitters should avoid using this trick over- zealously since the price for decreased delay is decreased reliability. Noisy links may cause the receiver to receive garbage characters and interpret them as part of an incoming frame. If the transmitter does not transmit a new opening Flag Sequence before sending the next frame, then that frame will be appended to the noise characters causing an invalid frame (with high reliability). Transmitters should avoid this by transmitting an open Flag Sequence whenever "appreciable time" has elapsed since the prior closing Flag Sequence. It is suggested that implementations will achieve the best results by always sending an opening Flag Sequence if the new frame is not back-to-back with the last. The maximum value for "appreciable time" is likely to be no greater than the typing rate of a slow to average typist, say 1 second.
強健な送信機は、減少している遅れの価格が減少している信頼性であるので過剰熱心にこのトリックを使用するのを避けるはずです。 騒がしいリンクは、受信機が入って来るフレームの一部としてゴミキャラクタを受けて、彼らを解釈することを引き起こすかもしれません。 隣のフレームを送る前に送信機が新しい初めのFlag Sequenceを伝えないと、無効のフレーム(高信頼性がある)を引き起こす雑音キャラクタにそのフレームを追加するでしょう。 送信機は、先の終わりのFlag Sequence以来「かなりの時間」が経過しているときはいつも、開いているFlag Sequenceを伝えることによって、これを避けるはずです。 新しいフレームが獲得しないと実現がいつも初めのFlag Sequenceを送ることによって最も良い結果を獲得することが提案される、背中合わせである、最終で。 「かなりの時間」のための最大値はタイピストを平均するのが遅いaのタイプよりレートである傾向があります、たとえば、1秒。
Perkins [Page 43] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[43ページ]RFC1171 1990年7月
B. Fast Frame Check Sequence (FCS) Implementation
B。 速いフレームチェックシーケンス(FCS)実現
B.1. FCS Computation Method
B.1。 FCS計算方法
The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. The table is created by the code in section 2.
以下のコードはデータがインタフェースに到着するのでFrame Check Sequenceについて計算するための索表計算を提供します。 テーブルはセクション2でコードによって作成されます。
/* * u16 represents an unsigned 16-bit number. Adjust the typedef for * your hardware. */ typedef unsigned short u16;
/**u16は無記名の16ビットの数を表します。 *のためにtypedefを調整してください。あなたのハードウェア。 */typedef無記名の短いu16。
/* * FCS lookup table as calculated by the table generator in section 2. */ static u16 fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
計算されるとしてのセクション2のテーブルジェネレータによる/**FCSルックアップ表。 */静的なu16 fcstab256が等しい、0×0000 0×1189 0×2312 0x329b、0×4624、0x57ad、0×6536、0x74bf、0x8c48、0x9dc1、0xaf5a、0xbed3、0xca6c、0xdbe5、0xe97e、0xf8f7、0×1081、0×0108、0×3393、0x221a、0x56a5、0x472c、0x75b7、0x643e、0x9cc9、0x8d40、0xbfdb、0xae52、0xdaed; 0xcb64、0xf9ff、0xe876、0×2102、0x308b、0×0210、0×1399、0×6726、0x76af、0×4434、0x55bd、0xad4a、0xbcc3、0x8e58、0x9fd1、0xeb6e、0xfae7、0xc87c、0xd9f5、0×3183、0x200a、0×1291、0×0318、0x77a7、0x662e、0x54b5、0x453c、0xbdcb、0xac42、0x9ed9、0x8f50、0xfbef; 0xea66、0xd8fd、0xc974、0×4204、0x538d、0×6116、0x709f、0×0420、0x15a9、0×2732、0x36bb、0xce4c、0xdfc5、0xed5e、0xfcd7、0×8868、0x99e1、0xab7a、0xbaf3、0×5285、0x430c、0×7197、0x601e、0x14a1、0×0528、0x37b3、0x263a、0xdecd、0xcf44、0xfddf、0xec56、0x98e9、0×8960、0xbbfb、0xaa72、0×6306、0x728f、0×4014、0x519d、0×2522、0x34ab、0×0630、0x17b9、0xef4e、0xfec7、0xcc5c、0xddd5、0xa96a、0xb8e3、0x8a78、0x9bf1、0×7387、0x620e、0×5095、0x411c、0x35a3、0x242a、0x16b1、0×0738、0xffcf、0xee46、0xdcdd、0xcd54、0xb9eb、0xa862、0x9af9、0x8b70、0×8408、0×9581、0xa71a、0xb693、0xc22c、0xd3a5、0xe13e、0xf0b7、0×0840、0x19c9、0x2b52、0x3adb、0x4e64、0x5fed、0x6d76、0x7cff、0×9489、0×8500、0xb79b、0xa612、0xd2ad、0xc324、0xf1bf、0xe036、0x18c1、0×0948、0x3bd3、0x2a5a、0x5ee5、0x4f6c、0x7df7、0x6c7e、0xa50a、0xb483、0×8618、0×9791、0xe32e、0xf2a7、0xc03c、0xd1b5、0×2942、0x38cb、0x0a50、0x1bd9、0x6f66、0x7eef、0x4c74、0x5dfd、0xb58b、0xa402; 0×9699 0×8710 0xf3af、0xe226、0xd0bd、0xc134、0x39c3、0x284a、0x1ad1、0x0b58、0x7fe7、0x6e6e、0x5cf5、0x4d7c、0xc60c、0xd785、0xe51e、0xf497、0×8028、0x91a1、0xa33a、0xb2b3、0x4a44、0x5bcd、0×6956、0x78df、0x0c60、0x1de9、0x2f72、0x3efb、0xd68d、0xc704、0xf59f、0xe416、0x90a9、0×8120、0xb3bb、0xa232、0x5ac5、0x4b4c、0x79d7、0x685e、0x1ce1、0x0d68、0x3ff3、0x2e7a、0xe70e、0xf687、0xc41c、0xd595、0xa12a、0xb0a3、0×8238、0x93b1
Perkins [Page 44] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[44ページ]RFC1171 1990年7月
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 };
0x6b46、0x7acf、0×4854、0x59dd、0x2d62、0x3ceb、0x0e70、0x1ff9、0xf78f、0xe606、0xd49d、0xc514、0xb1ab、0xa022、0x92b9、0×8330、0x7bc7、0x6a4e、0x58d5、0x495c、0x3de3、0x2c6a、0x1ef1、0x0f78、。
#define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */
#定義、PPPINITFCS 0xffff/*初期のFCS値*/#、はPPPGOODFCS 0xf0b8/*良い最終的なFCS値*/を定義します。
/* * Calculate a new fcs given the current fcs and the new data. */ u16 pppfcs(fcs, cp, len) register u16 fcs; register unsigned char *cp; register int len; { ASSERT(sizeof (u16) == 2); ASSERT(((u16) -1) > 0); while (len--) fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
現在のfcsと新しいデータを考えて、/**は新しいfcsについて計算します。 */u16 pppfcs(fcs、cp、len)レジスタu16 fcs。 無記名の炭*cpを登録してください。 int lenを登録してください。 ASSERT(sizeof(u16)=2)(ASSERT(((u16)-1)>0))がゆったり過ごす、(len--、)、fcsは^fcstab[(fcs^ *cp++)と0xff]と等しいです(>>8をfcsします)。
return (fcs); }
戻ってください(fcs)。 }
Perkins [Page 45] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[45ページ]RFC1171 1990年7月
B.2. Fast FCS table generator
B.2。 速いFCSテーブルジェネレータ
The following code creates the lookup table used to calculate the FCS.
以下のコードはFCSについて計算するのに使用されるルックアップ表を作成します。
/* * Generate a FCS table for the HDLC FCS. * * Drew D. Perkins at Carnegie Mellon University. * * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. */
/**はHDLC FCSのためにFCSテーブルを発生させます。 * * カーネギーメロン大学のドリュー・D.パーキンス。 * * コードはモホセンBananとD.ヒューRedelmeierから気前よく借りました。 */
/* * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408). */ #define P 0x8408
/**、HDLC多項式: x**0+x**5+x**12+x**16(0×8408)。 */#はP0x8408を定義します。
main() { register unsigned int b, v; register int i;
メイン()、無記名のint b、vを登録してください; int iを登録してください。
printf("typedef unsigned short u16;\n"); printf("static u16 fcstab[256] = {"); for (b = 0; ; ) { if (b % 8 == 0) printf("\n");
printf(「typedefの無記名の短いu16; \n」)。 printf、(「静的なu16 fcstab[256]が等しい、「)、(b=0)、(b%8 == 0)printf(「\n」)であるなら;」
v = b; for (i = 8; i--; ) v = v & 1 ? (v >> 1) ^ P : v >> 1;
v=b。 =vと1? (>>1に対する)^Pに対する(i=8(i))のために: v>>1。
printf("0x%04x", v & 0xFFFF); if (++b == 256) break; printf(","); } printf("\n};\n"); }
printf(「0x%04x」、v、および0xFFFF)。 (+ + b=256)が壊れるなら。 printf、(「」、)、。 printf、(「\n、;、\n」)、。 }
Perkins [Page 46] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[46ページ]RFC1171 1990年7月
References
参照
[1] Electronic Industries Association, EIA Standard RS-232-C, "Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange", August 1969.
[1] 電子工業会、EIAの標準のRS232Cは「連続の2進のデータ置き換えを使って、データ端末装置とデータ通信装置の間で連結します」、1969年8月。
[2] International Organization For Standardization, ISO Standard 3309-1979, "Data communication - High-level data link control procedures - Frame structure", 1979.
[2]国際標準化機構、ISO Standard3309-1979、「データ通信--ハイレベル・データリンク制御手順--枠組構造」、1979。
[3] International Organization For Standardization, ISO Standard 4335-1979, "Data communication - High-level data link control procedures - Elements of procedures", 1979.
[3]国際標準化機構、ISO Standard4335-1979、「データ通信--ハイレベル・データリンク制御手順--手順のElements」1979。
[4] International Organization For Standardization, ISO Standard 4335-1979/Addendum 1, "Data communication - High-level data link control procedures - Elements of procedures - Addendum 1", 1979.
[4]国際標準化機構、ISO Standard4335-1979/付加物1、「データ通信--ハイレベル・データリンク制御手順--手順のElements--付加物1インチ、1979。」
[5] International Organization For Standardization, Proposed Draft International Standard ISO 3309:1983/PDAD1, "Information processing systems - Data communication - High-level data link control procedures - Frame structure - Addendum 1: Start/stop transmission", 1984.
ISO3309: [5]国際標準化機構、Proposed国際規格案1983/PDAD1、「情報処理システム--データ通信--ハイレベル・データリンク制御手順--枠組構造--付加物1:、」 「始め/停止送信」、1984。
[6] International Telecommunication Union, CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks", CCITT Red Book, Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984.
[6] 国際電気通信連合、CCITT推薦X.25は「公共のデータ網がパケット形態で作動して、データ端末装置(DTE)とデータ回線終端装置(DCE)の間で端末に連結します」、CCITT職員録、巻VIII、分冊VIII.3、Rec。 X.25、10月1984日
[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983.
[7] ペレス、「バイト的なCRC計算」、IEEEミクロ、1983年6月。
[8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September 1986.
[8] モース、G.、「ビットとバイトの計算のCRCのもの」、バイト、1986年9月。
[9] LeVan, J., "A Fast CRC", Byte, November 1987.
1987年11月の[9] レバン、J.、「速いCRC」バイト。
[10] American National Standards Institute, ANSI X3.4-1977, "American National Standard Code for Information Interchange", 1977.
[10]American National Standards Institut、ANSI X3.4-1977、「情報交換用米国標準コード」1977。
[11] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981.
[11] ポステル、J.、「インターネットプロトコル」、RFC791、科学が1981年9月に設けるUSC/情報。
[12] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
[12] USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
Perkins [Page 47] RFC 1171 Point-to-Point Protocol July 1990
二地点間プロトコルパーキンス[47ページ]RFC1171 1990年7月
[13] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November 1983.
[13] ポステル、J.、「TCPの最大のセグメントサイズは、話題をゆだねて、関係づけた」RFC879、科学が1983年11月に設けるUSC/情報。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Chairman'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:
この提案はPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 いすを通してワーキンググループに連絡できます:
Russ Hobby UC Davis Computing Services Davis, CA 95616
デイヴィス、ラス趣味UCデイヴィスComputing Servicesカリフォルニア 95616
Phone: (916) 752-0236
以下に電話をしてください。 (916) 752-0236
EMail: rdhobby@ucdavis.edu
メール: rdhobby@ucdavis.edu
Author's Address
作者のアドレス
Questions about this memo can also be directed to the author:
また、このメモに関する質問を作者に向けることができます:
Drew D. Perkins Carnegie Mellon University Networking and Communications Pittsburgh, PA 15213
ピッツバーグ、Communications PA ドリューD.パーキンスカーネギーメロン大学ネットワークと15213
Phone: (412) 268-8576
以下に電話をしてください。 (412) 268-8576
EMail: ddp@andrew.cmu.edu
メール: ddp@andrew.cmu.edu
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).
Pointからポイントへのプロトコルを開発するのを助けるのに多くの人々が重要な時間を費やしました。 人々の全リストは記載できないくらい非常に多いのですが、以下の人々は特別な感謝に値します: ケン・エーデルマン(TGV)、クレイグフォックス(NSC)、フィルGross(NRI)、ラスHobby(UCデイヴィス)、デヴィッド・コーフマン(Proteon)、ジョンLoVerso(Xylogics)、ビルMelohn(サン・マイクロシステムズ)、マイク・パットン(MIT)、ドリュー・パーキンス(米カーネギーメロン大学)、グレッグSatz(コクチマスシステム)、およびアシャーWaldfogel(Wellfleet)。
Perkins [Page 48]
パーキンス[48ページ]
一覧
スポンサーリンク