RFC1547 日本語訳
1547 Requirements for an Internet Standard Point-to-Point Protocol. D.Perkins. December 1993. (Format: TXT=49810 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Perkins Request for Comments: 1547 Carnegie Mellon University Category: Informational December 1993
コメントを求めるワーキンググループD.パーキンス要求をネットワークでつないでください: 1547年のカーネギーメロン大学カテゴリ: 情報の1993年12月
Requirements for an Internet Standard Point-to-Point Protocol
インターネットの標準の二地点間プロトコルのための要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an Internet Standard. In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an Internet Standard are discussed in detail. An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues.
このドキュメントは、インターネットStandard Data Link Layerプロトコルがポイントツーポイント接続と共に使用されるために評価基準について議論します。 なにも、であることができる多くの産業標準プロトコルと臨時のプロトコルはデータ・リンク層のために既に存在していますが、かつ完全であって、かつ多能ではありません。インターネットStandardとして、認められます。 そのようなプロトコルを設計することへの準備では、詳細にインターネットStandardとして二地点間プロトコルに資格を与えるのに必要な特徴について議論します。 これらの要件に基づいたいくつかの既存のプロトコルの長所と短所の分析はそれぞれが主要な問題を扱わないことを示します。
Historical Note: This was the design requirements document dated
June 1989, which was followed for RFC-1134 through the present.
It is now published for completeness and future guidance.
歴史的な注意: これは1989年6月付けの設計の品質ドキュメントでした。(RFC-1134のためにプレゼントを通してそのドキュメントということになられました)。 それは現在、完全性と今後の指導のために発行されます。
Perkins [Page 1] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[1ページ]RFC1547 1993年12月
Table of Contents
目次
1. Introduction ................................................3 1.1 Definitions of Terms ........................................4 2. Required Features ...........................................6 2.1 Simplicity ..................................................7 2.2 Transparency ................................................7 2.3 Packet Framing ..............................................7 2.4 Bandwidth Efficiency ........................................8 2.5 Protocol Processing Efficiency ..............................8 2.6 Protocol Multiplexing .......................................8 2.7 Multiple Physical and Data Link Layer Protocols..............8 2.8 Error Detection .............................................9 2.9 Standardized Maximum Packet Length (MTU) ....................9 2.10 Switched and Non-Switched Media .............................9 2.11 Symmetry ....................................................9 2.12 Connection Liveness .........................................10 2.13 Loopback Detection ..........................................10 2.14 Misconfiguration Detection ..................................11 2.15 Network Layer Address Negotiation ...........................11 2.16 Data Compression Negotiation ................................11 2.17 Extensibility and Option Negotiation ........................12 3. Features Not Required .......................................12 3.1 Error Correction ............................................12 3.2 Flow Control ................................................13 3.3 Sequencing ..................................................13 3.4 Backward Compatibility ......................................13 3.5 Multi-Point Links ...........................................13 3.6 Half-Duplex or Simplex Links ................................14 3.7 7-bit Asynchronous RS-232 Links .............................14 4. Prior Work On PPP Protocols .................................14 4.1 Internet Protocols ..........................................14 4.1.1 RFC 891 - DCN Local-Network Protocols, Appendix A............14 4.1.2 RFC 914 - Thinwire Protocols ................................14 4.1.3 RFC 916 - Reliable Asynchronous Transfer Protocol............15 4.1.4 RFC 935 - Reliable Link Layer Protocols .....................15 4.1.5 RFC 1009 - Requirements for Internet Gateways ...............15 4.1.6 RFC 1055 - Serial Line IP ...................................16 4.2 International Protocols .....................................16 4.2.1 ISO 3309 - HDLC Frame Structure .............................16 4.2.2 ISO 6256 - HDLC Balanced Class of Procedures.................16 4.2.3 CCITT X.25 and X.25 LAPB ....................................17 4.2.4 CCITT I.441 LAPD ............................................17 4.3 Other Protocols .............................................17 4.3.1 Cisco Systems point-to-point protocols ......................17 4.3.2 MIT PC/IP framing protocol ..................................18 4.3.3 Proteon p4200 point-to-point protocol .......................18 4.3.4 Ungermann Bass point-to-point protocol ......................18
1. 序論…3 用語の1.1の定義…4 2. 特徴を必要とします…6 2.1の簡単さ…7 2.2透明…7 2.3パケット縁どり…7 2.4 帯域幅効率…8 2.5 処理効率について議定書の中で述べてください…8 2.6 マルチプレクシングについて議定書の中で述べてください…8 倍数物理的、そして、データ・リンク層2.7のプロトコル…8 2.8 誤り検出…9 2.9は最大のパケット長(MTU)を標準化しました…9 2.10の切り換えられて非切り換えられたメディア…9 2.11シンメトリ社…9 2.12接続活性…10 2.13 ループバック検出…10 2.14 Misconfiguration検出…11 2.15 ネットワーク層アドレス交渉…11 2.16 データ圧縮交渉…11 2.17伸展性とオプション交渉…12 3. 特徴は必要ではありません…12 3.1エラー修正…12 3.2フロー制御…13 3.3 配列します。13 3.4 後方の互換性…13 3.5 マルチポイントはリンクされます…13 3.6の半二重かシンプレクスがリンクされます…14 3.7 7ビットの非同期なRS-232はリンクします…14 4. pppプロトコルに対する先の仕事…14 4.1 インターネットプロトコル…14 4.1 .1 RFC891--DCN企業内情報通信網プロトコル、付録A.…14 4.1 .2 RFC914--Thinwireプロトコル…14 4.1 .3 RFC916--信頼できる非同期な転送プロトコル…15 4.1 .4 RFC935--信頼できるリンクレイヤプロトコル…15 4.1.5RFC1009--インターネットゲートウェイのための要件、…15 4.1 .6 RFC1055--シリアル・ラインIP…16 4.2 国際プロトコル…16 4.2 .1 ISO3309--HDLCは構造を縁どっています…16 4.2 .2 ISO6256--HDLCは手順のクラスのバランスをとりました…16 4.2 .3 CCITTのX.25とX.25 LAPB…17 4.2 .4 CCITT I.441 LAPD…17 他の4.3のプロトコル…17 4.3 .1 シスコシステムズの二地点間プロトコル…17 4.3 .2MIT PC/IP縁どりプロトコル…18 4.3 .3のProteon p4200の二地点間プロトコル…18 4.3 .4のアンガマンBass二地点間のプロトコル…18
Perkins [Page 2] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[2ページ]RFC1547 1993年12月
4.3.5 Wellfleet point-to-point protocol ...........................19 4.3.6 XNS Synchronous Point-to-Point Protocol .....................19 REFERENCES ........................................................20 SECURITY CONSIDERATION.............................................21 CHAIR'S ADDRESS ...................................................21 AUTHOR'S ADDRESS ..................................................21 EDITOR'S ADDRESS ..................................................21
4.3.5 Wellfleetの二地点間プロトコル…19 4.3 .6のXNSの同期二地点間プロトコル…19の参照箇所…20 セキュリティの考慮…21 議長のアドレス…21作者のアドレス…21エディタのアドレス…21
1. Introduction
1. 序論
The Internet has seen explosive growth in the number of hosts supporting IP [1]. 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).
インターネットは、ホストの数における爆発的成長が、IPが[1]であるとサポートしているのを見ました。 これらのホストのかなりの大部分が様々なタイプ(最も一般的なイーサネット)のローカル・エリア・ネットワーク(LAN)に接続されます。 他のホストの大部分はX.25スタイルPublic Data Networksなどのワイドエリアネットワーク(WAN)(PDNs)を通して接されます。
In the past, relatively few of these hosts were connected with simple point-to-point links. Yet, point-to-point serial links are among the oldest methods of data communications, and almost every host supports point-to-point connections. For example, asynchronous RS-232 interfaces are essentially ubiquitous.
過去に比較的、これらのホストのわずかしか簡単なポイントツーポイント接続に接続されませんでした。 しかし、データ通信の最も古いメソッドの中に二地点間連続のリンクがあります、そして、ほとんどすべてのホストが二地点間接続をサポートします。 例えば、非同期なRS-232インタフェースは本質的には遍在しています。
One reason for the small number of point-to-point IP links was the lack of a single established encapsulation protocol. There were plenty of non-standard (and at least one de facto standard) encapsulation protocols available, but there was not one which was agreed upon as an Internet Standard.
二地点間IPリンクの少ない数の1つの理由がただ一つの確立したカプセル化プロトコルの不足でした。 利用可能な多くの標準的でない(そして、少なくとも1つのデファクトスタンダード)カプセル化プロトコルがありましたが、インターネットStandardとして同意されたのはありませんでした。
A number of protocols have been proposed to the Internet community, but no consensus was reached as to which protocol should be adopted as a standard. The reason may be that these proposals often addressed specific problems rather than providing general purpose service.
多くのプロトコルがインターネットコミュニティに提案されましたが、どのプロトコルが規格として採用されるべきであるかに関してコンセンサスに全く達しませんでした。 理由はこれらの提案が汎用のサービスを提供するよりしばしばむしろその特定の問題を訴えたということであるかもしれません。
For example, one of the most successful protocols to-date was Rick Adam's SLIP protocol for BSD UNIX [9]. SLIP provides only the most rudimentary support for sending IP datagrams over asynchronous serial lines, and ignores issues such as the use of protocols other than IP and the use of synchronous links.
例えば、これまで最もうまくいっているプロトコルの1つはBSD UNIX[9]のためのリック・アダムのSLIPプロトコルでした。 SLIPは非同期なシリアル・ラインの上にIPデータグラムを送る最も初歩的なサポートだけを提供して、IP以外のプロトコルの使用や同期リンクの使用などの問題を無視します。
This document proposes a set of requirements for an Internet Standard point-to-point protocol (ISPPP). Its purpose is not to propose any one design for the standard; any solutions outlined in the text are intended only as examples, and do not preclude other implementations.
このドキュメントはインターネットのStandardの二地点間プロトコル(ISPPP)のための1セットの要件を提案します。 目的は規格のためにどんなデザインも提案しないことです。 テキストに概説されたどんなソリューションも、単に例として意図して、他の実装を排除しません。
The document is divided into four major sections. The first section defines a number of technical terms used in this document. The second section lists the proposed requirements and details some
ドキュメントは4つの主要なセクションに分割されます。 最初のセクションは本書では使用される多くの専門用語を定義します。 第2セクションは、提案された要件をリストアップして、いくつかを詳しく述べます。
Perkins [Page 3] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[3ページ]RFC1547 1993年12月
issues that are ignored by other protocols. The third section attempts to clarify a number of non-requirements. The fourth section analyzes existing protocols in light of the proposed requirements and discusses the failure of each to address key issues.
他のプロトコルによって無視される問題。 第3セクションは、多くの非要件をはっきりさせるのを試みます。 第4セクションは、提案された要件の観点から既存のプロトコルを分析して、それぞれが主要な問題を扱わないことについて論じます。
1.1 Definitions of Terms
1.1 用語の定義
This section defines many of the terms which will be used in further sections of this document. The terms "layer" and "level" are used extensively and refer to protocol layers as defined by the International Organization For Standardization's Reference Model (ISORM) standard. In particular, the terms Physical Layer, Data Link Layer and Network Layer refer to layers one, two and three respectively of the ISORM. A "higher layer" refers to one with a numerically larger layer number.
このセクションはこのドキュメントのさらなるセクションで使用される用語の多くを定義します。 用語「層」と「レベル」は、手広く使用されて、国際標準化機構のReference Model(ISORM)規格によって定義されるプロトコル層について言及します。 特に、Physical Layerという用語、Data Link Layer、およびNetwork LayerはISORMについてそれぞれ層1、2、およびthreeを参照します。 「より高い層」は数の上でより大きい層の番号で1を示します。
datagram
データグラム
The unit of transmission in the network layer (such as IP). A
datagram may be encapsulated in one or more packets (q.v.) passed
to the data link layer.
ネットワーク層(IPなどの)における、トランスミッションのユニット。 データグラムはデータ・リンク層に通過された1つ以上のパケット(q.v.)でカプセル化されるかもしれません。
data link layer
データ・リンク層
Layer two in the ISO reference model. Defines how bits
transmitted and received by the physical layer are recognized as
bytes and frames. May also define procedures for error detection
and correction, sequencing and flow control.
ISO参照における層twoはモデル化されます。 物理的な層に送信されて、受け取られたビットがバイトとフレームとしてどう認識されるかを定義します。 また、誤り検出と訂正、配列、およびフロー制御のために手順を定義するかもしれません。
fragment
断片
The result of fragmentation. Fragmentation at the network layer
breaks large datagrams into multiple parts less than or equal to
the size of the packets passed to the data link layer.
Fragmentation at the data link layer breaks large packets into
multiple frames.
断片化の結果。 ネットワーク層における断片化は大きいデータグラムを複数のデータ・リンク層に通過されたパケットの、よりサイズの部品に細かく分けます。 データ・リンク層における断片化は大きいパケットを複数のフレームに細かく分けます。
frame
フレーム
The unit of transmission at the data link layer. A frame may
include a header and/or a trailer along with some number of units
of data.
データ・リンク層におけるトランスミッションのユニット。 フレームは何らかの数のユニットのデータに伴うヘッダー、そして/または、トレーラを含むかもしれません。
framing protocol
縁どりプロトコル
A protocol at the data link level for marking the beginning and
end of a frame transmitted across a link.
フレームの首尾をマークするためのデータリンク・レベルにおけるプロトコルはリンクの向こう側に伝わりました。
Perkins [Page 4] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[4ページ]RFC1547 1993年12月
internet
インターネット
An interconnected system of networks tied together by a common
"internet protocol" providing a common and consistent network
address structure.
ネットワークの相互接続システムは一般的で一貫したネットワーク・アドレス構造を提供する一般的な「インターネットプロトコル」によって結びつけられました。
Internet
インターネット
Specifically refers to the IP Internet.
明確に、IPインターネットについて言及します。
Internet Standard Point-to-Point Protocol (ISPPP)
インターネットの標準の二地点間プロトコル(ISPPP)
A point-to-point protocol which is declared an official Internet
Standard. This protocol does not yet exist, but its proposed
characteristics are presented in this paper.
公式のインターネットStandardであると宣言される二地点間プロトコル。 このプロトコルはまだ存在していませんが、提案された特性はこの論文に示されます。
Maximum Transmission Unit (MTU)
マキシマム・トランスミッション・ユニット(MTU)
The maximum allowable length for a packet (q.v.) transmitted over
a point-to-point link without incurring network layer
fragmentation.
ネットワーク層断片化を被らないで、パケット(q.v.)のための最大の許容できる長さはポイントツーポイント接続の上を伝わりました。
network layer
ネットワーク層
Layer three in the ISO reference model. Responsible for routing
packets (q.v) between physical networks.
ISO参照における層threeはモデル化されます。 物理ネットワークの間でルーティングパケット(q.v)に責任があります。
octet
八重奏
A unit of transmission consisting of 8 bits. On most machines an
octet is the same as a byte or a character, but this need not be
true.
8ビットから成るトランスミッションのユニット。 ほとんどのマシンでは、八重奏は1バイトかキャラクタと同じですが、これは本当である必要はありません。
packet
パケット
The unit of transmission passed across the interface between the
network layer and the data link layer. A packet is usually mapped
to a frame (q.v); the exception is when data link layer
fragmentation is being performed.
トランスミッションのユニットはネットワーク層とデータ・リンク層とのインタフェースの向こう側に通りました。 通常、パケットはフレーム(q.v)に写像されます。 例外はデータ・リンク層断片化が実行されている時です。
physical layer
物理的な層
The first layer in the ISO reference model. Describes electrical,
mechanical and timing characteristics of a link.
ISO規範モデルの初層。 リンクの電気的で、機械的で調節している特性について説明します。
point-to-point protocol (ppp)
二地点間プロトコル(ppp)
A data link layer protocol for the transmission of packets (q.v.)
パケットのトランスミッションのためのデータリンク層プロトコル(q.v.)
Perkins [Page 5] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[5ページ]RFC1547 1993年12月
over a point-to-point link. In the following discussion, the
acronym "ppp" refers to any generic point-to-point protocol.
ポイントツーポイントの上では、リンクしてください。 以下の議論では、頭文字語「ppp」はどんなジェネリックポイントツーポイントプロトコルも示します。
serial line IP (slip)
シリアル・ラインIP(メモ用紙)
Often incorrectly used as a synonym for "point-to-point protocol",
"slip" specifically refers to any protocol for the transmission of
IP datagrams over a serial point-to-point line.
「二地点間プロトコル」のための同義語としてしばしば不当に使用されていて、「メモ用紙」は連続の二地点間系列の上にIPデータグラムのトランスミッションについて明確にどんなプロトコルも示します。
SLIP
メモ用紙
Although many proposed protocols are named "SLIP", this document
will use SLIP (uppercase) to refer to Rick Adam's slip (q.v.) for
BSD UNIX [9].
多くの提案されたプロトコルが「メモ用紙」と命名されますが、このドキュメントは、BSD UNIX[9]についてリック・アダムのメモ用紙(q.v.)について言及するのにメモ用紙(大文字)を使用するでしょう。
2. Required Features
2. 必要な特徴
In order for a point-to-point protocol to be accepted by the Internet community it must adequately address many requirements. This section itemizes and discusses the proposed requirements. Although the main emphasis of the discussion is on protocol architecture requirements, implementation requirements are sometimes discussed as well.
インターネットコミュニティで二地点間プロトコルを受け入れるために、それは適切に多くの要件を扱わなければなりません。 このセクションは、提案された要件を箇条書きして、論じます。 議論の主な強調がプロトコルアーキテクチャ要件にありますが、また、時々実装要件について議論します。
These particular requirements were chosen to assure that the ISPPP adequately serves the needs of its users. Some of these needs are universal and dictate clear requirements for the protocol; for example, a packet framing protocol is a fundamental necessity. Other needs are more specific and may even be conflicting. Connection liveness determination is very important on some links but can be very expensive on others. A standard protocol must address all of these needs; in particular, it must be able to resolve conflicts effectively.
これらの特定の要件は、ISPPPが適切にユーザの必要性に役立つことを保証するために選ばれました。 これらの必要性のいくつかが、普遍的であり、プロトコルのための明確な要件を決めます。 例えば、パケット縁どりプロトコルは基本的な必要性です。 他の必要性は、より特定であり、闘争してさえいるかもしれません。 接続活性決断は、いくつかのリンクで非常に重要ですが、他のもので非常に高価である場合があります。 標準プロトコルはこれらの必要性のすべてを扱わなければなりません。 特に、それは有効に闘争を解決できなければなりません。
Resolving these conflicts requires that a protocol feature have both enabled and disabled modes and that these modes must be compatible with each other. The enabled mode allows the protocol to solve problems in environments where they exist. The disabled mode allows problems to be ignored in environments where they do not exist. To assure interoperabilty, implementations are required to support both modes and allow the user (not necessarily human) to dynamically choose which is appropriate.
これらの闘争を解決するのは両方がモードであると可能にされて、無効にされるのをプロトコル機能がさせて、これらのモードは互いと互換性があるに違いないのを必要とします。 可能にされたモードで、プロトコルはそれらが存在するところで環境における問題を解決できます。 障害があるモードは、それらが存在しないところに問題が環境で無視されるのを許容します。 interoperabiltyを保証するために、実装が両方のモードをサポートして、ユーザ(必ず人間であるというわけではない)が、どれが適切であるかをダイナミックに選ぶのを許容するのに必要です。
This is essentially the same solution used in the User Datagram Protocol (UDP) [2]. The UDP datagram checksum may be computed (enabled mode) or it may not (disabled mode). Compatibility is maintained by requiring the checksum to be transmitted as zero in disabled mode and ignored when received as zero in either mode. Implementations of UDP are generally encouraged to support both modes
これはユーザー・データグラム・プロトコル(UDP)[2]で使用される本質的には同じソリューションです。 UDPデータグラムチェックサムが計算されるかもしれませんか(モードを可能にします)、またはそれは計算されないかもしれません(モードであると無効にされます)。 ゼロとしてどちらのモードでも受け取ると、互換性をチェックサムが障害があるモードにおけるゼロとして伝えられるのを必要とすることによって維持して、無視します。 一般に、UDPの実装が両方のモードをサポートするよう奨励されます。
Perkins [Page 6] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[6ページ]RFC1547 1993年12月
but allow the application to choose modes.
しかし、アプリケーションにモードを選ばせてください。
2.1 Simplicity
2.1 簡単さ
The ISPPP must be simple. The Internet architecture very carefully places the most complexity in the transport layer (that is, TCP). The internetwork layer (IP) is a fairly simple, almost stateless protocol providing an unreliable datagram service. The data link layer need provide no more capability than the IP protocol; no error correction, sequencing or flow control is necessary. Including these would in most cases needlessly duplicate the capabilities of the transport layer, and might possibly decrease efficiency. This is not to say that these capabilities must never be included; there are some cases which may warrant them. For instance, very noisy links may be more efficiently handled using a more complex data link layer protocol such as CCITT's LAPB. Nevertheless, the watchword for a point-to-point protocol should be simplicity.
ISPPPは簡単であるに違いありません。 インターネットアーキテクチャは非常に慎重にトランスポート層(すなわち、TCP)に最も多くの複雑さを置きます。 インターネットワーク(IP)層は頼り無いデータグラムサービスを提供するかなり簡単で、ほとんど状態がないプロトコルです。 データ・リンク層はIPプロトコルが能力でないことのようなどんな能力も提供する必要はありません。 エラー修正、配列またはどんなフロー制御も必要ではありません。 これらを含んでいるのは、多くの場合、不必要にトランスポート層の能力をコピーして、ことによると減少効率をコピーするかもしれません。 これはこれらの能力を決して含んではいけないと言わないためのものです。 それらを保証するかもしれないいくつかのケースがあります。 例えば、非常に騒がしいリンクは、CCITTのLAPBなどの、より複雑なデータリンク層プロトコルを使用することで、より効率的に扱われるかもしれません。 それにもかかわらず、二地点間プロトコルのための合言葉は簡単さであるべきです。
A simple design also decreases the incidence of programming errors, thereby increasing the likelihood of interoperability among different implementations. Since interoperability is a primary goal of standardization, this is another strong argument for simplicity.
また、単純なデザインはプログラミング・エラーの発生を静まらせて、その結果、異なった実装の中で相互運用性の可能性を広げます。 相互運用性が標準化のプライマリ目標であるので、これは簡単さのための別の強い議論です。
2.2 Transparency
2.2 透明
The ISPPP must be transparent to higher layers. The protocol must not place any constraints on transmitted data. All ISPPP data, including higher level headers as well as data, must be transported unmodified end-to-end. No restrictions are placed on how the ISPPP accomplishes this. For example, if the ISPPP uses a particular character for framing, it must also provide some way of disambiguating higher level data containing that character from a framing character (such as escaping or bit-stuffing). This is mainly an issue for the data link and physical layer protocols incorporated into the ISPPP.
ISPPPは、より高い層に透明であるに違いありません。 プロトコルは伝えられたデータに少しの規制も置いてはいけません。 データと同様により高い平らなヘッダーを含むすべてのISPPPデータが、輸送された変更されていない終わりから終わりであるに違いありません。 ISPPPがどうこれを達成するかに関して制限は全く課されません。 例えば、また、ISPPPが縁どりに特定のキャラクタを使用するなら、それは何らかの道に縁どりキャラクタ(エスケープかビット・スタッフィングなどの)からそのキャラクタを含むより高い平らなデータのあいまいさを除くのを提供しなければなりません。 これは、主にデータ・リンクへの問題とISPPPに組み入れられた物理的な層のプロトコルです。
2.3 Packet Framing
2.3 パケット縁どり
The ISPPP must be able to correctly and efficiently frame packets. A receiver must be able to locate correctly the beginning and end of each transmitted packet. Within each packet, the receiver must be able to identify the boundaries of each octet. Finally, within each octet, each bit must be located and identified. No restrictions other than those specified in this document are placed on the packet framing protocol.
ISPPPは正しく効率的にパケットを縁どることができなければなりません。 受信機は正しくそれぞれの伝えられたパケットの首尾の場所を見つけることができなければなりません。 各パケットの中では、受信機はそれぞれの八重奏の境界を特定できなければなりません。 最終的に、各八重奏の中では、各ビットを位置していて、特定しなければなりません。 本書では指定されたもの以外の制限は全くパケット縁どりプロトコルに関して課されません。
Perkins [Page 7] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[7ページ]RFC1547 1993年12月
2.4 Bandwidth Efficiency
2.4 帯域幅効率
The ISPPP must make efficient use of available bandwidth. At most, the ppp overhead may impose a few percent reduction in raw link bandwidth.
ISPPPは利用可能な帯域幅の効率的な使用をしなければなりません。 高々、pppオーバーヘッドは生のリンク帯域幅での減少を数パーセント課すかもしれません。
2.5 Protocol Processing Efficiency
2.5 プロトコル処理効率
The processing of the ISPPP headers must typically be very fast and efficient. The format for data packets should be very simple in the normal case, without complex field checking.
ISPPPヘッダーの処理は、通常非常に速くて、効率的でなければなりません。 データ・パケットのための形式は複雑な分野の照合なしで正常な場合で非常に簡単であるべきです。
2.6 Protocol Multiplexing
2.6 プロトコルマルチプレクシング
The ISPPP must support multiplexing of many higher level protocols. Although the Internet community is interested mainly in IP, co- existence of other protocols is frequently required. IP networks must often support additional protocols such as AppleTalk, DECnet, IPX, and XNS. For point-to-point links to connect gateways on geographically separated Local Area Networks (LANs), the ISPPP must simultaneously support all protocols implemented on both the LANs and the gateways. This suggests that the ISPPP must include a protocol type field or other multiplexing scheme. Given the large number of protocols, the potential use of the protocol type field as a data compression aid, and the experimental nature of the Internet, eight bits of type field are not sufficient. Sixteen bits of type field are suggested, although twelve bits (4096 protocols) should suffice.
ISPPPは多くの、より高い平らなプロトコルのマルチプレクシングをサポートしなければなりません。 インターネットコミュニティは主にIPに興味を持っていますが、他のプロトコルの共同存在が頻繁に必要です。 IPネットワークはしばしばAppleTalkや、DECnetや、IPXや、XNSなどの追加議定書をサポートしなければなりません。 ポイントツーポイント接続が地理的に切り離されたローカル・エリア・ネットワーク(LAN)にゲートウェイを接続するように、ISPPPは同時に、LANとゲートウェイの両方で実装されたすべてのプロトコルをサポートしなければなりません。 これは、ISPPPがプロトコルタイプ分野か他のマルチプレクシング体系を含まなければならないのを示します。 多くのプロトコル、データ圧縮援助としてのプロトコルタイプ分野の潜在的使用、およびインターネットの実験本質を考えて、タイプ分野の8ビットは十分ではありません。 12ビット(4096のプロトコル)は十分であるはずですが、タイプ分野の16ビットは示されます。
2.7 Multiple Physical and Data Link Layer Protocols
2.7 複数の物理的、そして、データ・リンク層プロトコル
The ISPPP must support a multiplicity of physical and data link layer protocols. Many types of point-to-point links exist. Links can be serial or parallel, synchronous or asynchronous, low speed or high speed, electrical or optical. Standards are required for the transmission of IP datagrams over each type of commonly used link.
ISPPPは物理的、そして、データ・リンク層プロトコルの多様性をサポートしなければなりません。 多くのタイプのポイントツーポイント接続は存在しています。 リンクは、連続の、または、平行であるか、同時の、または、非同期な低速か電気的であるか光学の高速であるかもしれません。 規格がIPデータグラムのトランスミッションにそれぞれのタイプの一般的に使用されたリンクの上に必要です。
The ISPPP must not inhibit the use of any type of link. This includes, but is not limited to, asynchronous, bit-oriented synchronous (HDLC [10] and X.25 LAPB [11]), and byte-oriented synchronous (BISYNC and DDCMP [15]) links.
ISPPPはどんなタイプのリンクの使用も抑制してはいけません。 これが含んでいる、同時の状態で有限で、非同期で、またはビット指向でない、(HDLC[10]とX.25 LAPB[11])、およびバイト指向、同期、(BISYNCとDDCMP[15])リンク。
The ISPPP must initially provide support for at least the following types of links:
ISPPPは初めは、少なくとも以下のタイプのリンクのサポートを提供しなければなりません:
Full duplex asynchronous RS-232 [3] links with 8 bits of data and
no parity, ranging in speeds from 300 to 19.2k bps or more.
全二重の非同期なRS-232[3]は8ビットのデータにもかかわらず、どんな同等にもリンクされません、19.2kビーピーエスか300〜以上まで速度のねらいを定めて。
Full duplex bit-oriented synchronous links including RS-422, RS-
RS-422、RSを含む全二重のビット指向の同期リンク
Perkins [Page 8] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[8ページ]RFC1547 1993年12月
423, V.35 and T1.
423、V.35、およびT1。
Other links should be standardized as the need arises.
他のリンクは必要に応じて標準化されるべきです。
2.8 Error Detection
2.8 誤り検出
The ISPPP must provide some form of basic error detection. Most
network and transport layer protocols provide mechanisms to detect
corrupted packets. However, some network protocols expect error
free transmission and either provide error detection only on a
conditional basis or do not provide it at all. It is the
consensus of the Internet community that error correction should
always be implemented in the end-to-end transport, but that link
error detection in the form of a checksum, Cyclic Redundancy Check
(CRC) or other frame check mechanism is useful to prevent wasted
bandwidth from propagation of corrupted packets. Link level error
correction is not required.
ISPPPは何らかの形式の基本的な誤り検出を提供しなければなりません。 ほとんどのネットワークとトランスポート層プロトコルが、崩壊したパケットを検出するためにメカニズムを提供します。 しかしながら、いくつかのネットワーク・プロトコルは、エラーのないトランスミッションを予想して、条件付きベースだけで誤り検出を提供するか、またはそれを全く提供しません。 それはエラー修正が終わらせる終わりの輸送であるといつも実装されるべきですが、チェックサム、Cyclic Redundancy Check(CRC)または他のフレームチェックメカニズムの形におけるリンク誤り検出が崩壊したパケットの伝播からの無駄な帯域幅を防ぐために役に立つというインターネットコミュニティのコンセンサスです。 リンク・レベルエラー修正は必要ではありません。
2.9 Standardized Maximum Packet Length (MTU)
2.9 標準化された最大のパケット長(MTU)
The ISPPP must have a standardized default maximum packet length
for each type of point-to-point link. This standardization helps
to promote interoperable implementations. Higher layer protocols
must not attempt to transmit packets longer than the MTU. If a
higher layer protocol does try to transmit a packet which is too
long, the ISPPP must drop the packet and return an error. The MTU
may potentially be changed from the default via some sort of
explicit negotiation or private agreement, but the default must be
enforced in all other cases. The default should be at least 1500
bytes, to efficiently carry common LAN traffic.
ISPPPには、それぞれのタイプのポイントツーポイント接続への標準化されたデフォルト最大のパケット長がなければなりません。 この標準化は、共同利用できる実装を促進するのを助けます。 より高い層のプロトコルは、MTUより長い間パケットを伝えるのを試みてはいけません。 より高い層のプロトコルが長過ぎるパケットを伝えようとするなら、ISPPPはパケットを下げて、誤りを返さなければなりません。 デフォルトからある種の明白な交渉か個人的な協定でMTUを潜在的に変えるかもしれませんが、他のすべての場合でデフォルトを励行しなければなりません。 デフォルトは、効率的に一般的なLANトラフィックを運ぶためには少なくとも1500バイトであるべきです。
2.10 Switched and Non-Switched Media
2.10 切り換えられて非切り換えられたメディア
The ISPPP must be able to support both switched (dynamic) and non-
switched (static) point-to-point links. A common example of a
non- switched link is a 3-wire asynchronous RS-232 cable which
might connect a host to a particular gateway. Switched media may
be exemplified by connections over a standard voice network or an
Integrated Services Digital Network (ISDN). Links over ISDN are
currently rare, but are expected to become increasingly
commonplace. To be a viable standard, the ISPPP must be able to
effectively support both types of links. Procedures for
establishing switched connections are beyond the scope of this
document.
ISPPPはともに切り換えられた(ダイナミックな)サポートと非切り換えられた(静的な)ポイントツーポイント接続にできるに違いありません。 非切り換えられたリンクの一般的な例は特定のゲートウェイにホストを接続するかもしれない3ワイヤの非同期なRS-232ケーブルです。 切り換えられたメディアは標準の声のネットワークかIntegrated Services Digital Network(ISDN)の上の接続によって例示されるかもしれません。 ISDNの上のリンクは、現在、まれですが、ますます平凡になると予想されます。 実行可能な規格に、なるように、事実上、ISPPPは両方のタイプのリンクを支えることができなければなりません。 切り換えられた接続を確立するための手順はこのドキュメントの範囲を超えています。
2.11 Symmetry
2.11 対称
The ISPPP should operate symmetrically to maximize flexibility.
ISPPPは、柔軟性を最大にするために対称的に作動するはずです。
Perkins [Page 9] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[9ページ]RFC1547 1993年12月
The ISPPP must allow communications among any combination of
gateways and hosts. One host may need to communicate directly
with another host, or it may be connected to a gateway to gain
access to a whole network. A gateway may establish a connection
to a single host in order to deliver a packet, or it may connect
to another gateway on a permanent or transient basis. Symmetry is
destroyed by pre-assigned static roles, such as master and slave
or gateway and host. If necessary, roles may be dynamically
determined on a per connection basis.
ISPPPはゲートウェイとホストのどんな組み合わせの中にもコミュニケーションを許容しなければなりません。 1人のホストが、別のホストと共に直接伝達する必要があるかもしれませんか、またはそれは、全体のネットワークへのアクセスを得るためにゲートウェイに接続されるかもしれません。 ゲートウェイがパケットを提供するために独身のホストに取引関係を築くかもしれませんか、またはそれは永久的であるか一時的なベースでもう1門に接続するかもしれません。 対称はマスターや奴隷かゲートウェイやホストなどのあらかじめ割り当てられた固定的な役割によって破壊されます。 必要なら、役割は接続基礎あたりのaでダイナミックに決定するかもしれません。
2.12 Connection Liveness
2.12 接続活性
The ISPPP must include a mechanism to automatically determine when
a link is functioning properly and when it is defunct. This
mechanism should be enabled by default, but the protocol and all
implementations must allow this mechanism to be disabled.
ISPPPは、リンクがいつ適切に機能しているか、そして、それがいつ死んでいるかを自動的に決定するためにメカニズムを含まなければなりません。 このメカニズムはデフォルトで可能にされるべきですが、プロトコルとすべての実装が、このメカニズムが無効にされるのを許容しなければなりません。
When enabled, this mechanism should discover changes in a link's
status in a timely fashion -- no more than a few minutes.
Continuing to utilize a link which is down often causes routing
problems commonly referred to as "black holes". These problems
can be hard to find and diagnose. By automatically detecting a
failing link, a point-to-point protocol can avoid such problems,
and also provide a powerful tool for a network manager trying to
locate and remedy the fault.
可能にされると、このメカニズムはリンクの状態で直ちに変化を発見するはずです--数分だけ。 下がっているリンクを利用し続けているのがしばしば一般的に「ブラックホール」と呼ばれたルーティング問題を引き起こします。 これらの問題は見つけて、診断するのは困難である場合があります。 自動的に失敗リンクを検出することによって、また、二地点間プロトコルは、場所を見つけるトライをネットワークマネージャのための強力な道具に提供して、そのような問題を避けて、欠点を療法に提供できます。
When a point-to-point connection is not functioning properly, it
must be declared "down" for the purposes of routing packets for
higher level protocols. In order to certify a link "up", the
systems on either end of the link must be able to successfully
exchange packets. In other words, the systems at both ends must
be able both to transmit and to receive packets, and the link must
be able to transport packets in both directions. Links are
defined to be "down" at initialization, their liveness must be
verified before they may be declared "up".
二地点間接続が適切に機能していないとき、より高い平らなプロトコルのためのルーティングパケットの目的のための“down"であるとそれを宣言しなければなりません。 リンクが“up"であることを公認するために、リンクのどちらかの端のシステムは首尾よくパケットを交換できなければなりません。 言い換えれば、両端のシステムは、ともに送信して、パケットを受けることができなければなりません、そして、リンクは両方の方向にパケットを輸送できなければなりません。 リンクは初期化における“down"になるように定義されて、それらが“up"であると宣言されるかもしれない前にそれらの活性について確かめなければなりません。
This feature may be disabled in situations where connection status
determination is "expensive". For example, a link may traverse a
Public Data Network (such as TELENET or TYMNET) which accounts for
bandwidth utilization. Constant pinging would result in charges
being accrued even in the absence of useful communications.
この特徴は接続形態決断が「高価である」状況で無効にされるかもしれません。 例えば、リンクは帯域幅利用を説明するPublic Data Network(テレネットかTYMNETなどの)を横断するかもしれません。 一定のノッキングは役に立つコミュニケーションがないときでさえ生じる充電をもたらすでしょう。
2.13 Loopback Detection
2.13 ループバック検出
The ISPPP must be capable of automatically detecting a looped-back link without operator assistance. Modems and other communications gear are often placed in a loopback mode to aid in diagnosis of circuit failures. Detection of this condition must take no longer
ISPPPはオペレータ支援なしで輪にされて逆リンクを自動的に検出できなければなりません。 モデムと他のコミュニケーションギヤは、回路の故障の診断で支援するためにしばしばループバックモードに置かれます。 この状態の検出はもうかかってはいけません。
Perkins [Page 10] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[10ページ]RFC1547 1993年12月
than one period of the liveness protocol. While the link is in loopback mode, each end of the link must declare the other end to be unreachable. However, to aid in diagnosis, each end of the link may declare itself reachable for any higher-level protocol which distinguishes between the two ends of the link.
活性プロトコルのある期間より。 リンクがループバックモードである間、リンクの各端は、もう一方の端が手が届かないと宣言しなければなりません。 しかしながら、診断で支援するために、リンクの各端は、リンクの2つの端を見分けるどんな上位レベル・プロトコルにおいても、それ自体に届いていると宣言するかもしれません。
2.14 Misconfiguration Detection
2.14 Misconfiguration検出
The ISPPP must be able to quickly detect misconfigured point-to-point connections. A connection which is misconfigured must never be declared to be up. Many systems, gateways in particular, have more than one point-to-point connection. When many cables terminate within a small area, the possibility for confusion abounds. It becomes very easy to mistakenly plug a cable into the wrong connector, or even to swap cables. The protocol should do its best to provide protection against these errors by verifying the remote end's identity whenever possible before marking an interface as operational. The purpose of this verification is not rigorous authentication but the detection of simple errors.
ISPPPはすぐにmisconfigured二地点間接続を検出できなければなりません。 上がるとmisconfiguredされる接続を決して宣言してはいけません。 多くのシステム(特にゲートウェイ)には、1人以上の二地点間接続がいます。 多くのケーブルが狭い面積の中で終わると、混乱のための可能性は富みます。 誤って間違ったコネクタにケーブルのプラグを差し込むか、またはケーブルを交換するのさえ非常に簡単になります。 プロトコルは、操作上としてインタフェースを示す前に可能であるときはいつも、リモートエンドのアイデンティティについて確かめることによってこれらの誤りに対する保護を提供するために最善をつくすべきです。 この検証の目的は厳しい認証ではなく、簡単な誤りの検出です。
2.15 Network Layer Address Negotiation
2.15 ネットワーク層アドレス交渉
The ISPPP must allow network layer (such as IP) addresses to be negotiated. The negotiation algorithm should be as simple as possible and must be guaranteed to terminate in all cases. Many network layer protocols and implementations are required to know the addresses at both ends of a point-to-point link before packets may be routed. These addresses may be statically configured, but it may sometimes be necessary or convenient for these addresses be dynamically ascertained at connection establishment. This is especially important when switched media are used. For example, a dial-up IP gateway must know the IP address of its peer before packets can be successfully routed. This address can be either statically or dynamically configured. In the former case, the gateway's peer must therefore learn the static address (static with respect to the gateway). In the latter situation, the gateway must dynamically learn the address used by its peer.
ISPPPは、ネットワーク層(IPなどの)アドレスが交渉されるのを許容しなければなりません。 交渉アルゴリズムをできるだけ簡単であるべきであり、すべての場合で終わるために保証しなければなりません。 多くのネットワーク層プロトコルと実装が、パケットが発送されるかもしれない前にポイントツーポイント接続の両端でアドレスを知るのに必要です。 これらのアドレスは静的に構成されるかもしれませんが、それが時々必要であるかもしれませんか、コネクション確立で確かめられて、これらのアドレスに便利であるのは、ダイナミックにそうです。 切り換えられたメディアが使用されているとき、これは特に重要です。 例えば、首尾よくパケットを発送できる前にダイヤルアップIPゲートウェイは同輩のIPアドレスを知らなければなりません。 静的かダイナミックにこのアドレスを構成できます。 したがって、前の場合では、ゲートウェイの同輩は静的なアドレス(ゲートウェイに関して静的な)を学ばなければなりません。 後者の状況で、ゲートウェイはダイナミックに同輩によって使用されたアドレスを学ばなければなりません。
2.16 Data Compression Negotiation
2.16 データ圧縮交渉
The ISPPP must provide a way to negotiate the use of data compression algorithms. This mechanism should be as simple as possible and must be guaranteed to terminate in all cases. The protocol is not required to standardize any data compression algorithms; conforming implementations of the protocol therefore may refuse to do data compression when negotiating (refusal to do data compression always takes precedence over an offer to do it). However, to allow the use of data compression between consenting systems, the point-to-point
ISPPPはデータ圧縮アルゴリズムの使用を交渉する方法を提供しなければなりません。このメカニズムをできるだけ簡単であるべきであり、すべての場合で終わるために保証しなければなりません。 プロトコルはどんなデータ圧縮アルゴリズムも標準化するのに必要ではありません。 したがって、プロトコルの実装を従わせるのは、交渉するとき、データ圧縮をするのを拒否するかもしれません(データ圧縮をすることへの拒否はそれをするという申し出の上でいつも優先します)。 しかしながら、同意することの間のデータ圧縮の使用にシステム、ポイントツーポイントを許容します。
Perkins [Page 11] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[11ページ]RFC1547 1993年12月
protocol must not impede the use of data compression. In fact, it should be possible to use multiple, independent data compression schemes simultaneously. Because data compression algorithms are still very experimental in the Internet environment, it is likely that many different algorithms will be tried. The negotiation protocol must distinguish between these different algorithms to ensure that data compression is not enabled unless the same algorithm or algorithms are used at both ends of the connection. The number of such supported algorithms must be easily extensible.
プロトコルはデータ圧縮の使用を妨害してはいけません。 事実上、同時に複数の、そして、独立しているデータ圧縮体系を使用するのは可能であるべきです。 データ圧縮アルゴリズムがインターネット環境でまだ非常に実験しているので、多くの異なったアルゴリズムが試みられそうでしょう。 交渉プロトコルは、同じアルゴリズムかアルゴリズムが接続の両端で使用されない場合データ圧縮が可能にされないのを保証するためにこれらの異なったアルゴリズムを見分けなければなりません。 アルゴリズムであるとサポートされたそのようなものの数は容易に広げることができなければなりません。
2.17 Extensibility and Option Negotiation
2.17 伸展性とオプション交渉
The ISPPP must allow for future extensions in a flexible way. The Internet will never cease to evolve. Changes in technology and user demands create new requirements. To function effectively as a standard, the protocol must have the ability to evolve along with its environment.
ISPPPはフレキシブルな方法で今後の拡大を考慮しなければなりません。 インターネットは、発展するのを決してやめないでしょう。 技術における変化とユーザ要求は新しい要件を作成します。 規格として有効に機能するように、プロトコルには、環境と共に発展する能力がなければなりません。
To accomplish this, the ISPPP should be designed to be as extensible as possible and to allow for experimentation within the guidelines of the other requirements presented in this document. A proposed solution is to specify an option negotiation protocol. The option negotiation protocol could be used for the negotiation of network layer addresses, data compression schemes, MTU, encryption, etc. The option negotiation protocol must itself be extensible; it should allow the negotiation of a large number of future options and it should allow the use of other types of point-to-point links and encapsulation schemes.
これを達成するなら、ISPPPは、できるだけ広げることができて、本書では提示された他の要件のガイドラインの中で実験を考慮するように設計されるべきです。 提案されたソリューションはオプション交渉プロトコルを指定することです。 ネットワーク層アドレス、データ圧縮体系、MTU、暗号化などの交渉にオプション交渉プロトコルを使用できました。 オプション交渉は必須自体について議定書の中で述べます。広げることができてください。 それは多くの今後のオプションの交渉を許すべきです、そして、他のタイプのポイントツーポイント接続とカプセル化体系の使用を許すべきです。
3. Features Not Required
3. 特徴は必要ではありません。
This section discusses functionality which is explicitly not required. These functions may potentially be included in implementations as long as the inclusion does not violate any of the requirements itemized in the previous section.
このセクションは明らかに必要でない機能性について論じます。 包含が前項に箇条書きされた要件のいずれにも違反しない限り、これらの機能は実装に潜在的に含まれるかもしれません。
3.1 Error Correction
3.1エラー修正
As discussed above in the sections on Simplicity and Error Detection, error correction is the responsibility of the transport layer and is not required in a point-to-point protocol. However, on links with high error rates, performance may be increased by adding error correction at the data link level. Therefore, the ISPPP must not prevent the addition of error correction by private agreement, even though such mechanisms are not required in the basic implementation.
上でSimplicityとError Detectionの上のセクションで議論するように、エラー修正は、トランスポート層の責任であり、二地点間プロトコルで必要ではありません。 しかしながら、高い誤り率とのリンクでは、性能は、データリンク・レベルでエラー修正を加えることによって、増強されるかもしれません。 したがって、ISPPPは個人的な協定でエラー修正の追加を防いではいけません、そのようなメカニズムが基本的な実装では必要ではありませんが。
Perkins [Page 12] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[12ページ]RFC1547 1993年12月
3.2 Flow Control
3.2フロー制御
Flow control (such as XON/XOFF) is not required. Any implementation of the ISPPP is expected to be capable of receiving packets at the full rate possible for the particular data link and physical layers used in the implementation. If higher layers cannot receive packets at the full rate possible, it is up to those layers to discard packets or invoke flow control procedures. As discussed above, end- to-end flow control is the responsibility of the transport layer. Including flow control within a point-to-point protocol often causes violation of the simplicity requirement.
フロー制御(XON/XOFFなどの)は必要ではありません。 ISPPPのどんな実装も実装に使用される特定のデータ・リンクと物理的な層に、可能な全額料金でパケットを受けることができると予想されます。 より高い層が可能な全額料金でパケットを受けることができないなら、パケットを捨てるか、またはフロー制御手順を呼び出すのがそれらの層まで達しています。 上で議論するように、終わりまでの終わりのフロー制御はトランスポート層の責任です。 二地点間プロトコルの中にしばしばフロー制御を含んでいると、簡単さ要件の違反は引き起こされます。
3.3 Sequencing
3.3 配列
Sequencing of packets is not required. The ISPPP need provide no more service than the IP protocol, an unreliable datagram service which is free to reorder packets. In fact, it is specifically allowed to reorder packets based upon some type-of-service criteria implemented in higher-level protocols.
パケットの配列は必要ではありません。 ISPPPはIPプロトコルがサービスでないののようなどんなサービス(追加注文パケットに無料であることの頼り無いデータグラムサービス)も提供する必要はありません。 事実上、それは明確に上位レベル・プロトコルで実装された業務基準のタイプに基づく追加注文パケットに許容されています。
3.4 Backward Compatibility
3.4 後方の互換性
There is no requirement for the ISPPP to provide backward compatibility with any other point-to-point protocol. First, there are no official Internet Standards with which backward compatibility must be maintained. Second, attempting to maintain backward compatibility may lead to needless restrictions on the new protocol. However, there is no need for the designers of the ISPPP to go out of their way to inhibit backward compatibility.
ISPPPがいかなる他の二地点間プロトコルも後方の互換性に提供するという要件が全くありません。 まず最初に、後方の互換性を維持しなければならないどんな公式のインターネットStandardsもありません。 2番目に、後方の互換性を維持するのを試みるのが新しいプロトコルにおける不必要な制限に通じるかもしれません。 しかしながら、ISPPPのデザイナーがわざわざ後方の互換性を禁止する必要は全くありません。
3.5 Multi-Point Links
3.5 マルチポイントリンク
There is no requirement for supporting multi-point links. Many features which are required are only valid between two peers. These links are sufficiently rare that the benefits of supporting them are outweighed by the added complexity their support would introduce into the ISPPP.
マルチポイントがリンクであるとサポートするための要件が全くありません。 必要である多くの特徴が2人の同輩の間で有効であるだけです。 これらのリンクは十分まれです。それらをサポートする利益は彼らのサポートがISPPPに紹介する加えられた複雑さより軽いです。
Historical Note: The original rationale also stated: "Furthermore,
it is unlikely that many new types of multi-point links will be
introduced in the foreseeable future." Since this was written,
considerable effort has been expended in new multi-point links,
including Switched Multimegabit Data Service, Frame Relay, and
Asynchronous Transfer Mode. However, it is clear that these are
considerably more complex than ISPPP.
歴史的な注意: また、述べられたオリジナルの原理: 「その上、すぐに多くの新しいタイプのマルチポイントリンクを導入するのはありそうもないです。」 これが書かれて以来、かなりの取り組みが新しいマルチポイントリンクで費やされています、Switched Multimegabit Data Service、Frame Relay、およびAsynchronous Transfer Modeを含んでいて。 しかしながら、これらがISPPPよりかなり複雑であることは、明確です。
Perkins [Page 13] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[13ページ]RFC1547 1993年12月
3.6 Half-Duplex or Simplex Links
3.6 半二重かシンプレクスリンク
Support for half-duplex or simplex links is not required. These types of links are not in common use in the current Internet. Half- duplex links require some method of turning the line around. The ISPPP need not have an explicit mechanism for handling line turn- around. Such support might possibly be added in the future via the required extension mechanism.
半二重かシンプレクスリンクのサポートは必要ではありません。 これらのタイプのリンクは現在のインターネットで共用ではありません。 半分デュプレックスリンクは系列を変える何らかのメソッドを必要とします。 ISPPPは周囲に取り扱い系列回転のための明白なメカニズムを持つ必要はありません。 そのようなサポートは将来、ことによると必要な拡張機能で加えられるかもしれません。
3.7 7-bit Asynchronous RS-232 Links
3.7 7ビットの非同期なRS-232リンク
The use of asynchronous RS-232 need not support 7-bit links. 8-bit links are predominant in the Internet environment and supporting 7- bit links introduces unnecessary complexity.
非同期なRS-232の使用は7ビットのリンクを支える必要はありません。 8ビットのリンクはインターネット環境で支配的です、そして、7ビットがリンクであるとサポートするのが不要な複雑さを導入します。
4. Prior Work On PPP Protocols
4. pppプロトコルに対する先の仕事
This section reviews a number of existing point-to-point and data link layer protocols and points out which of our requirements are not satisfied.
このセクションは、多くの既存のポイントツーポイントとデータリンク層プロトコルを見直して、私たちの要件のどれが満足していないかを指摘します。
4.1 Internet Protocols
4.1 インターネットプロトコル
4.1.1 RFC 891 - DCN Local-Network Protocols, Appendix A
4.1.1 RFC891--DCN企業内情報通信網プロトコル、付録A
In Appendix A of RFC 891, "DCN Local-Network Protocols" [4], D.L. Mills describes the data link layer packet formats used by the Fuzzball system for asynchronous, character-oriented synchronous, DDCMP, HDLC, ARPANET 1822, X.25 LAPB and ethernet links. These protocols meet the stated requirements for simplicity, transparency, packet framing and efficiency, but fall short of many of the others. Most of these protocols assume the use of the IP protocol, and do not include any type of protocol demultiplexing field. No error detection mechanism is provided except when necessary to comply with another standard such as ethernet. RFC 891 does not mention the MTU used for any of these links. Other requirements such as loopback detection and misconfiguration detection are not discussed. Finally, no option negotiation scheme is defined; without a protocol demultiplexing field it would be difficult or impossible to include one.
RFC891のAppendix A、「DCN企業内情報通信網プロトコル」[4]では、D.L.ミルズは同期非同期で、キャラクタ指向のDDCMP、HDLC、アルパネット1822、X.25 LAPB、およびイーサネットリンクのFuzzballシステムによって使用されるデータ・リンク層パケット・フォーマットについて説明します。 これらのプロトコルは、簡単さ、透明、パケット縁どり、および効率のための述べられた必要条件を満たしますが、他のものの多くより下回っています。 これらのプロトコルの大部分は、IPプロトコルの使用を仮定して、どんなタイプのプロトコル逆多重化分野も含んでいません。 いつ以外に、イーサネットなどの別の規格に従うのに必要な状態で誤り検出メカニズムを全く提供しないか。 RFC891はこれらのリンクのいずれにも使用されるMTUについて言及しません。 ループバック検出やmisconfiguration検出などの他の要件について議論しません。 最終的に、オプション交渉体系は全く定義されません。 プロトコル逆多重化分野がなければ、1つを含んでいるのは、難しいか、または不可能でしょう。
4.1.2 RFC 914 - Thinwire Protocols
4.1.2 RFC914--Thinwireプロトコル
RFC 914, "Thinwire Protocols" [5], discusses the use of low speed links in the Internet. This document places its main emphasis on decreasing round-trip delay and increasing link efficiency with the help of header compression (vs. data compression) techniques. Three "Thinwire" protocols are discussed, Thinwire I, Thinwire II and
RFC914(「Thinwireプロトコル」[5])はインターネットでの低速リンクの使用について議論します。 このドキュメントは減少している往復の遅れと増加するリンク効率へのヘッダー圧縮(データ圧縮に対する)のテクニックの助けによる主な強調を置きます。 そしてThinwire I、3つの"Thinwire"プロトコルについて議論して、ThinwireがIIである。
Perkins [Page 14] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[14ページ]RFC1547 1993年12月
Thinwire III. The latter two protocols require the use of a reliable data link layer protocol; one such protocol, "SLIP" (not to be confused with Rick Adams' SLIP), is proposed in Appendix D of the RFC. As proposed, "SLIP" does not meet many of the stated requirements. Although not terribly complex, as a reliable, error detecting and correcting protocol, it is not "simple". The 32 octet packet size makes it inefficient for large or uncompressed packets, requiring complex fragmentation and reassembly. The use of other than asynchronous links is not mentioned. The entire reliable link layer would be redundant over LAPB links. There is no mechanism for option negotiation or future extensibility.
Thinwire III。 後者の2つのプロトコルが信頼できるデータリンク層プロトコルの使用を必要とします。 「メモ用紙」(リック・アダムスのメモ用紙に混乱しない)というそのようなプロトコルの1つはRFCの付録Dで提案されます。 提案されるように、「メモ用紙」は述べられた必要条件の多くを満たしません。 信頼できる誤り検出と修正プロトコルとしてものすごく複雑ではありませんが、それは「簡単ではありません」。 32八重奏パケットサイズで、複雑な断片化と再アセンブリを必要として、それは大きいか解凍されたパケットに効率が悪くなります。 使用、非同期なリンク以外に、言及されません。 全体の信頼できるリンクレイヤはLAPBリンクの上に余分でしょう。 オプション交渉か将来の伸展性のためのメカニズムが全くありません。
4.1.3 RFC 916 - Reliable Asynchronous Transfer Protocol
4.1.3 RFC916--信頼できる非同期な転送プロトコル
RFC 916 [6] presents RATP, the Reliable Asynchronous Transfer Protocol. RATP provides error detection and correction, sequencing and flow control across a point-to-point connection. It is directed towards full duplex RS-232 links although it is useful for other point-to-point links. Although the author claims that RATP is not as complex as some other protocols, it is far from simple. RATP solves many of the problems which we have labeled non-requirements and fails to solve many of our stated requirements. Specifically, RATP does not support option negotiation and has no mechanism for future extensibility. Since RFC 916 was published, no consensus has emerged advocating RATP. For these reasons RATP is not recommended as the ISPPP.
RFC916[6]はRATP、Reliable Asynchronous Transferにプロトコルを提示します。 RATPは二地点間接続の向こう側に誤り検出と訂正、配列、およびフロー制御を提供します。 他のポイントツーポイント接続の役に立ちますが、それは全二重RS-232リンクに向けられます。 作者は、RATPがある他のプロトコルほど複雑でないと主張しますが、それは全く簡単ではありません。 RATPは私たちが非要件とラベルした問題の多くを解決して、私たちの述べられた要件の多くは解決しません。 明確に、RATPはオプションが交渉であることをサポートしないで、また将来の伸展性のためのメカニズムを全く持っていません。 RFC916が発行されて以来、コンセンサスは、全くRATPについて提唱しながら、現れていません。 これらの理由で、RATPはISPPPとして推薦されません。
4.1.4 RFC 935 - Reliable Link Layer Protocols
4.1.4 RFC935--信頼できるリンクレイヤプロトコル
RFC 935 [7] is a rebuttal to the protocols proposed in RFCs 914 and 916. J. Robinson discusses existing and widely-used national and international standards which meet the needs addressed by the two prior RFCs. The standards reviewed include character-oriented asynchronous and synchronous (bisynch) protocols and bit-oriented synchronous protocols. RFC 935 does not present any higher level issues such as option negotiation or extensibility.
RFC935[7]はRFCs914と916で提案されたプロトコルへの反論です。 J。 ロビンソンは存在と2先のRFCsによって扱われた需要を満たす広く使用された国家的、そして、国際的な規格について議論します。 見直された規格はキャラクタ指向の非同期で同期の(bisynch)プロトコルとビット指向の同期プロトコルを含んでいます。 RFC935はオプション交渉か伸展性などのどんなより高い平らな問題も提示しません。
4.1.5 RFC 1009 - Requirements for Internet Gateways
4.1.5 RFC1009--インターネットゲートウェイのための要件
Section 3 of RFC 1009, "Constituent Network Interfaces" [8], briefly discusses requirements for transmission of IP datagrams over a number of types of point-to-point links including X.25 LAPB, HDLC framed synchronous links, Xerox Synchronous Point-to-Point synchronous lines and the MIT Serial Line Framing Protocol for asynchronous lines. RFC 1009 merely mentions these as reasonable candidates and does not go into depth on any of them. All are discussed further in this document.
X.25 LAPBを含んでいて、RFC1009のセクション3(「構成しているネットワーク・インターフェース」[8])は多くのタイプのポイントツーポイント接続の上で簡潔にIPデータグラムのトランスミッションのための要件について論じて、HDLCは非同期な系列のために同期リンク、ゼロックスSynchronous Pointからポイントへの同期線、およびMIT Serial線Framingプロトコルを縁どりました。 RFC1009は合理的な候補として単にこれらについて言及して、彼らのいずれでも深さに入りません。 さらに本書ではすべてについて議論します。
Perkins [Page 15] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[15ページ]RFC1547 1993年12月
4.1.6 RFC 1055 - Serial Line IP
4.1.6 RFC1055--シリアル・ラインIP
Rick Adams' Serial Line IP (SLIP) protocol [9] has become something of a de facto standard due to the popularity of the 4.2 and 4.3BSD UNIX operating systems. SLIP is easily added to 4.2 systems and is included with 4.3. Many other TCP/IP implementation have added SLIP implementations in order to be compatible. Yet SLIP is not a real standard; the protocol was only recently published in RFC form. Before RFC 1055 it was specified in the SLIP source code. SLIP does not meet most of the requirements set forth above. SLIP certainly meets the requirement for simplicity, and also meets the requirements for transparency and bandwidth efficiency. But SLIP only provides for sending IP packets over asynchronous serial lines. Since it provides no higher level protocol field for demultiplexing, SLIP cannot support multiple concurrent higher level protocols. Providing only a framing protocol, SLIP would be entirely redundant when used with a LAPB synchronous link. SLIP includes absolutely no mechanism for error detection, not even parity. Again due to its lack of a protocol type field, SLIP does not support any type of option negotiation or extensibility.
リック・アダムスのSerial線IP(SLIP)プロトコル[9]は4.2と4.3BSD Unixオペレーティングシステムの人気のためある種のデファクトスタンダードになりました。SLIPは容易に4.2台のシステムに追加されて、4.3で含められています。 他の多くのTCP/IPインプリメンテーションが、互換性があるようにSLIP実装を加えました。 しかし、SLIPは本当の規格ではありません。 プロトコルは最近、RFCフォームで発表されただけです。 RFC1055の前では、それはSLIPソースコードで指定されました。 SLIPは上に詳しく説明された要件の大部分に会いません。 SLIPは確かに、簡単さのために条件を満たして、また、透明と帯域幅効率のために条件を満たします。 しかし、SLIPは非同期なシリアル・ラインで送付IPパケットに備えるだけです。 どんなより高い平らなプロトコル野原も逆多重化に供給しないので、SLIPは複数の同時発生の、より高い平らなプロトコルをサポートできません。 縁どりプロトコルだけを提供して、LAPBの同期リンクと共に使用されると、SLIPは完全に余分でしょう。 SLIPは同等ではなくさえ、誤り検出のためのメカニズムを全く絶対に含んでいません。 再びプロトコルタイプ分野の不足のため、SLIPはどんなタイプのオプション交渉か伸展性もサポートしません。
4.2 International Protocols
4.2 国際プロトコル
4.2.1 ISO 3309 - HDLC Frame Structure
4.2.1 ISO3309--HDLC枠組構造
ISO 3309 [10], the HDLC frame structure, is a simple data link layer protocol which provides framing of packets transmitted over bit- oriented synchronous links. Special flag sequences mark the beginning and end of frames and bit stuffing allows data containing flag characters to be transmitted. A 16-bit Frame Check Sequence provides error detection.
ISO3309[10](HDLC枠組構造)はビット指向の同期リンクの上に伝えられたパケットの縁どりを提供する簡単なデータリンク層プロトコルです。 特別なフラグ・シーケンスはフレームの首尾をマークします、そして、ビット・スタッフィングは旗のキャラクタを含むデータが送られるのを許容します。 16ビットのFrame Check Sequenceは誤り検出を提供します。
By itself, the HDLC frame structure does not meet most of the requirements. HDLC does not provide protocol multiplexing, standard MTUs, fault detection or option negotiation. There is no mechanism for future extensibility.
HDLC枠組構造自体は必要条件の大部分を満たしません。 HDLCはプロトコルマルチプレクシング、標準のMTUs、欠点検出またはオプション交渉を提供しません。 将来の伸展性のためのメカニズムが全くありません。
Given the HDLC frame structure's wide acceptance and simplicity, it may be an ideal building block for the ISPPP.
HDLC枠組構造の広い承認と簡単さを考えて、それはISPPPに、理想的なブロックであるかもしれません。
4.2.2 ISO 6256 - HDLC Balanced Class of Procedures
4.2.2 ISO6256--手順に関するHDLC平衡型クラス
ISO 6256, the HDLC Balanced Class of Procedures, specifies a data link layer protocol which provides error correction, sequencing and flow control. ISO 6256 builds on ISO 3309 and ISO 4335, HDLC Elements of Procedures.
ISO6256(ProceduresのHDLC Balanced Class)はエラー修正、配列、およびフロー制御を提供するデータリンク層プロトコルを指定します。 ISO6256はISO3309とISO4335、ProceduresのHDLC Elementsの上に建てます。
As far as meeting our requirements is concerned, ISO 6256 does not
私たちの要件を満たすのに関する限り、ISO6256は限りではなく。
Perkins [Page 16] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[16ページ]RFC1547 1993年12月
provide any more utility than does ISO 3309. The capabilities that are provided are all considered unnecessary and overly complex.
ISO3309よりそれ以上のユーティリティを提供してください。 提供される能力は不要であって、ひどく複雑であるとすべて考えられます。
4.2.3 CCITT X.25 and X.25 LAPB
4.2.3 CCITT X.25とX.25 LAPB
CCITT recommendation X.25 [11] describes a network layer protocol providing error-free, sequenced, flow controlled virtual circuits. X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 and 6256. Neither X.25 LAPB or full LAPB meet any more of our requirements than the ISO protocols.
エラーのなくて、配列された流れが仮想の回路を制御したなら、CCITT推薦X.25[11]はネットワーク層プロトコルについて説明します。 X.25はデータ・リンク層、ISO3309、4335と6256を使用するX.25 LAPBを含んでいます。 X.25 LAPBも完全なLAPBも私たちの要件にISOプロトコルよりもう会いません。
4.2.4 CCITT I.441 LAPD
4.2.4 CCITT I.441 LAPD
CCITT I.441 LAPD [12] defines the Link Access Procedure on the ISDN D-Channel. The data link layer of LAPD is very similar to that of LAPB and fails to meet the same requirements.
CCITT I.441 LAPD[12]はISDN D-チャンネルの上にLink Access Procedureを定義します。 LAPDのデータ・リンク層は、LAPBのものと非常に同様であり、同じ必要条件を満たしません。
4.3 Other Protocols
4.3 他のプロトコル
4.3.1 Cisco Systems point-to-point protocols
4.3.1 シスコシステムズの二地点間プロトコル
The Cisco Systems gateway supports both asynchronous links using SLIP and synchronous links using either simple HDLC framing, X.25 LAPB or full X.25. The HDLC framing procedure includes a four byte header. The first octet (address) is either 0x0F (unicast intent) or 0x8F (multicast intent). The second octet (control byte) is left zero and is not checked on reception. The third and fourth octets contain a standard 16 bit Ethernet protocol type code.
シスコシステムズゲートウェイは、SLIPを使用する非同期なリンクと同期リンクの両方がどちらの簡単なHDLC縁どりも使用するか、X.25 LAPBまたは完全なX.25であるとサポートします。 HDLC縁どり手順は4バイトのヘッダーを含んでいます。 最初の八重奏(アドレス)は、0x0F(ユニキャスト意図)か0x8F(マルチキャスト意図)のどちらかです。 2番目の八重奏(コントロールバイト)は、ゼロに残されて、レセプションでチェックされません。 3番目と4番目の八重奏は16ビットの標準のイーサネットプロトコルタイプコードを含んでいます。
A "keepalive" or "beaconing" protocol is used to ensure the two-way connectivity of the serial line. Each end of the link periodically sends two 32 bit sequence numbers to the other side. One sequence number is the local side's sequence number, the other is the sequence number received from the other side. Hearing the local sequence number from the other side indicates that the link is working in both directions.
"keepalive"か「航路標識」プロトコルは、シリアル・ラインの両用接続性を確実にするのに使用されます。 リンクの各端は定期的に32ビットの2つの一連番号を反対側に送ります。 1つの一連番号がローカル・サイドの一連番号である、もう片方が反対側から受け取られた一連番号です。 反対側から局所的配列番号を聞くのは、リンクが両方の方向に働いているのを示します。
The keepalive protocol is extensible. One extension is used to default IP addresses on serial lines of systems without non-volatile memory. A request for address is sent to the remote side. The remote side responds with its own IP address and a subnet mask. When the querying side receives the reply, it checks if the host portion of the remote address is either 1 or 2. If so, the opposite address is chosen for the local address. If not, the protocol cannot be used and we must rely on other address resolution means. This protocol assumes that each serial link uses one subnet or network number.
keepaliveプロトコルは広げることができます。 1つの拡張子がIPがシステムのシリアル・ラインの上で非揮発性メモリーなしで扱うデフォルトに使用されます。 アドレスを求める要求を遠隔地側に送ります。 遠隔地側はそれ自身のIPアドレスとサブネットマスクで応じます。 質問側が回答を受け取るとき、それは、リモートアドレスのホスト部分が1かそれとも2であるかどうかチェックします。 そうだとすれば、反対のアドレスはローカルアドレスに選ばれています。 そうでなければ、プロトコルを使用できません、そして、私たちは他のアドレス解決手段を当てにしなければなりません。 このプロトコルは、それぞれの連続のリンクが1つのサブネットかネットワーク・ナンバーを使用すると仮定します。
LAPB assuming IP is another possible encapsulation. A multi-protocol
IPを仮定するLAPBは別の可能なカプセル化です。 マルチプロトコル
Perkins [Page 17] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[17ページ]RFC1547 1993年12月
extension of LAPB (multi-LAPB) includes a 16 bit Ethernet type code after the address and control bytes and in front of the actual protocol data. DDN X.25 and Commercial X.25 encapsulations are also supported. Multiple protocols are supported by making protocol dependent CALL REQUEST's.
LAPB(マルチLAPB)の拡大はアドレスとコントロールバイトの後と実際のプロトコルデータの正面に16ビットのイーサネットタイプコードを含んでいます。 また、DDN X.25とCommercial X.25カプセル化はサポートされます。 複数のプロトコルが、プロトコルを依存するCALL REQUESTのものにすることによって、サポートされます。
4.3.2 MIT PC/IP framing protocol
4.3.2 MIT PC/IP縁どりプロトコル
The MIT PC/IP framing protocol [13] provides a mechanism for the transmission of IP datagrams over asynchronous links. The low-level protocol (LLP) sublayer provides encapsulation while the local net protocol provides multiplexing of IP datagrams and IP address request packets. The protocol only allows host-to-gateway connections. Host-to-gateway flow control is provided by requiring the host to transmit request packets to the gateway until an acknowledgment is received. Rudimentary IP address negotiation requires the host to ascertain its IP address from the gateway.
MIT PC/IP縁どりプロトコル[13]は非同期なリンクの上にIPデータグラムのトランスミッションにメカニズムを提供します。 ローカルのネットのプロトコルはIPデータグラムとIPアドレスリクエスト・パケットのマルチプレクシングを提供しますが、低レベルであるプロトコル(LLP)副層はカプセル化を提供します。 プロトコルはホストからゲートウェイとの接続を許すだけです。 承認が受け取られているまでホストがリクエスト・パケットをゲートウェイに伝えるのを必要とすることによって、ホストからゲートウェイへのフロー制御を提供します。 初歩的なIPアドレス交渉は、ホストがゲートウェイからのIPアドレスを確かめるのを必要とします。
The protocol does not implement error detection, connection status determination, fault detection or option negotiation. Only asynchronous links are supported.
プロトコルは、誤りが検出、接続形態決断、欠点検出またはオプション交渉であると実装しません。 非同期なリンクだけが支えられます。
4.3.3 Proteon p4200 point-to-point protocol
4.3.3 Proteon p4200の二地点間プロトコル
The Proteon p4200 multi-protocol router supports transmission of packets over bit-oriented synchronous links with a wide range of speeds (zero to 2 Mb/sec). The p4200 point-to-point protocol encapsulates packets inside HDLC frames but does not use the HDLC address or control fields; these two octets are instead used for a 16-bit type field. The p4200 does use the HDLC frame check sequence trailer. Protocol type numbers are ad hoc and do not correspond to any existing standard. A simple liveness protocol detects dead connections.
Proteon p4200マルチプロトコルルータはさまざまな速度(ゼロ〜2Mb/秒)とのビット指向の同期リンクの上にパケットのトランスミッションをサポートします。 p4200の二地点間プロトコルは、HDLCフレームの中にパケットをカプセルに入れりますが、HDLCアドレスか制御フィールドを使用しません。 これらの2つの八重奏が16ビットのタイプ分野に代わりに使用されます。 p4200はHDLCフレームチェックシーケンストレーラを使用します。 プロトコル形式数は、臨時であり、どんな既存の規格とも食い違っています。 簡単な活性プロトコルは停止コネクションを検出します。
Although the Proteon protocol does meet many of our requirements, it does not meet our requirements for option negotiation.
Proteonプロトコルは私たちの要件の多くを満たしますが、それはオプション交渉のための私たちの要件を満たしません。
4.3.4 Ungermann Bass point-to-point protocol
4.3.4 アンガマンBass二地点間のプロトコル
The Ungermann Bass router supports synchronous links using simple HDLC framing. Neither the HDLC address or control field are used, IP datagrams are placed immediately after the HDLC flag.
アンガマンBassルータは、簡単なHDLC縁どりを使用することで同期リンクを支えます。 HDLCが扱わないどちらも制御フィールドが使用されている、IPデータグラムはHDLC旗直後置かれます。
The U-B protocol does not meet any of our requirements for fault detection or option negotiation. No mechanism for future extensibility is currently defined.
U-Bプロトコルは欠点検出かオプション交渉のための私たちの要件のいずれも満たしません。 将来の伸展性のためのメカニズムは全く現在、定義されません。
Perkins [Page 18] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[18ページ]RFC1547 1993年12月
4.3.5 Wellfleet point-to-point protocol
4.3.5 Wellfleetの二地点間プロトコル
The Wellfleet router supports synchronous links using simple HDLC framing. The HDLC framing procedure uses the HDLC address and places the Unnumbered Information (UI) command in all frames. A simple header following the UI command provides a two octet type field using the same values as Ethernet.
Wellfleetルータは、簡単なHDLC縁どりを使用することで同期リンクを支えます。 HDLC縁どり手順はUnnumbered情報(UI)がすべてのフレームで命令するHDLCアドレスと場所を使用します。 UIコマンドの後をつける簡単なヘッダーは、イーサネットと同じ値を使用することで2八重奏タイプ野原を供給します。
The Wellfleet protocol does not meet any of our requirements for fault detection or option negotiation. No mechanism for future extensibility is currently defined, although one could be added.
Wellfleetプロトコルは欠点検出かオプション交渉のための私たちの要件のいずれも満たしません。 1つを加えることができましたが、将来の伸展性のためのメカニズムは全く現在、定義されません。
4.3.6 XNS Synchronous Point-to-Point Protocol
4.3.6 XNSの同期二地点間プロトコル
The Xerox Network Systems Synchronous Point-to-Point protocol (XNS PPP) [14] was designed to address most of the same issues that an ISPPP must address. In particular, it addresses the issues of simplicity, transparency, efficiency, packet framing, protocol multiplexing, error detection, standard MTUs, symmetry, switched and non-switched media, connection status, network address negotiation and future extensibility. However, the XNS SPPP does not meet our requirements for multiple data link layer protocols, fault detection and data compression negotiation. Although protocol multiplexing is provided, the packet type field has only 8 bits which is too few.
ゼロックスNetwork Systems Synchronous Pointからポイントへのプロトコル(XNS PPP)[14]は、ISPPPが扱わなければならない同じ問題の大部分を扱うように設計されました。 特に、それは簡単さ、透明、効率、パケット縁どり、プロトコルマルチプレクシング、誤り検出、標準のMTUs、対称、切り換えられて非切り換えられたメディア、接続形態、ネットワーク・アドレス交渉、および将来の伸展性の問題を扱います。 しかしながら、XNS SPPPは複数のデータリンク層プロトコル、欠点検出、およびデータ圧縮交渉のための私たちの要件を満たしません。 プロトコルマルチプレクシングを提供しますが、パケットタイプ分野には、わずか過ぎる8ビットしかありません。
Perkins [Page 19] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[19ページ]RFC1547 1993年12月
References
参照
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[1] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[2] Postel, J., "User Datagram Protocol", STD 6, RFC768, USC/Information
Sciences Institute, August 1980.
[2] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[3] Electronic Industries Association, EIA Standard RS-232-C,
"Interface Between Data Terminal Equipment and Data
Communications Equipment Employing Serial Binary Data
Interchange", August 1969.
[3] 電子工業会、EIAの標準のRS232Cは「連続のバイナリ・データ置き換えを使って、データ端末装置とデータ通信装置の間で連結します」、1969年8月。
[4] Mills, D. L., "DCN Local-Network Protocols", STD 44, RFC 891,
University of Delaware, December 1983.
[4]工場、D.L.、「DCN企業内情報通信網プロトコル」、STD44、RFC891、デラウエア大学、1983年12月。
[5] Farber, David J., Delp, Gary S., and Conte, Thomas M., "A
Thinwire Protocol for Connecting Personal Computers to the
Internet", RFC 914, University of Delaware, September 1984.
[5] ファーバーとデヴィッドJ.とデルプ、ゲーリーS.とコンテ、トーマスM.、「パーソナルコンピュータをインターネットに接続するためのThinwireプロトコル」RFC914、デラウエア大学(1984年9月)。
[6] Finn, G., "Reliable Asynchronous Transfer Protocol (RATP)",
RFC 916, USC/Information Sciences Institute, October 1984.
[6] フィンランド人、G.、「信頼できる非同期な転送プロトコル(RATP)」、RFC916、科学が1984年10月に設けるUSC/情報。
[7] Robinson, J., "Reliable Link Layer Protocols", RFC 935, BBN,
January 1985.
[7] ロビンソン、J.、「信頼できるリンクレイヤプロトコル」、RFC935、BBN、1985年1月。
[8] Braden, R., and J. Postel, "Requirements for Internet
Gateways", STD 4, RFC1009, USC/Information Sciences Institute,
June 1987.
[8] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」STD4、RFC1009、科学が1987年6月に設けるUSC/情報。
[9] Romkey, J., "A Nonstandard for the Transmission of IP Datagrams
Over Serial Lines: SLIP", STD 47, RFC 1055, June 1988. STD
4, RFC 1009, June 1987.
[9] J.、Romkeyに、「IPデータグラムの送信に、シリーズの上で標準的でないAは立ち並んでいます」。 「メモ用紙」、STD47、RFC1055、1988年6月。 STD4、1987年6月のRFC1009。
[10] ISO International Standard (IS) 3309, "Data Communications -
High-level Data Link Control Procedures - Frame Structure",
1979.
[10] ISO国際規格(ある)3309、「データ通信--ハイレベル・データリンク制御手順--枠組構造」、1979。
[11] 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", Vol. VIII, Fascicle VIII.2, Rec. X.25.
[11]CCITT推薦X.25、「データ端末装置(DTE)とデータ回線終端装置(DCE)との端末へのパケット形態で公共のデータ網を作動させるインタフェース」、Vol.VIII、分冊VIII.2、Rec。 X.25。
[12] CCITT Recommendation Q.921 "ISDN User-Network Interface Data
Link Layer Specification".
[12] CCITT推薦Q.921「ISDNユーザネットワーク・インターフェースデータ・リンク層仕様。」
Perkins [Page 20] RFC 1547 Point-to-Point Protocol Requirements December 1993
二地点間プロトコル要件パーキンス[20ページ]RFC1547 1993年12月
[13] Romkey, J.L., "PC/IP Programmer's Manual", Massachussetts
Institute of Technology Laboratory for Computer Science,
January 1986.
[13]Romkey、J.L.、「PC/IPプログラマのマニュアル」、Massachussetts工科大学コンピュータ科学研究所、1986年1月。
[14] Xerox Corporation, "Synchronous Point-to-Point Protocol", Xerox
System Integration Standard, Stamford, Connecticut, XSIS
158412, December 1984.
[14]ゼロックス社、「同期二地点間プロトコル」、ゼロックスシステムインテグレーション規格、スタンフォード、コネチカット、XSIS158412、1984年12月。
[15] "Digital Data Communications Message Protocol", Digital
Equipment Corporation.
[15] 「ディジタルデータコミュニケーションメッセージプロトコル」、DEC。
Security Consideration
警備上の配慮
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollay Driveサンタバーバラ、カリフォルニア 93117
EMail: fbaker@acc.com
メール: fbaker@acc.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Drew Perkins
4015 Holiday Park Drive
Murrysville, PA 15668
ドリュー・パーキンス4015休日公園ドライブMurrysville、PA 15668
EMail: perkins+@cmu.edu
メール: perkins+@cmu.edu
Editor's Address
エディタのアドレス
Typographic revision and historical notes by:
以下による印刷の改正と歴史的な注意
William Allen Simpson
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンシンプソン1384フォンテーヌマディソンの高さ、48071
EMail: Bill.Simpson@um.cc.umich.edu
メール: Bill.Simpson@um.cc.umich.edu
Perkins [Page 21]
パーキンス[21ページ]
一覧
スポンサーリンク
