RFC1172 日本語訳
1172 Point-to-Point Protocol (PPP) initial configuration options. D.Perkins, R. Hobby. July 1990. (Format: TXT=76132 bytes) (Obsoleted by RFC1331, RFC1332) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Perkins
Request for Comments: 1172 CMU
R. Hobby
UC Davis
July 1990
コメントを求めるワーキンググループD.パーキンス要求をネットワークでつないでください: 1172 米カーネギーメロン大学R.趣味UCデイヴィス1990年7月
The Point-to-Point Protocol (PPP) Initial Configuration Options
二地点間プロトコル(ppp)の初期の設定オプション
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
Pointからポイントへのプロトコル(PPP)は連続のポイントツーポイント接続の上にデータグラムを送るためのメソッドを提供します。 PPPから構成されます。
1) a method for encapsulating datagrams over serial links,
2) an extensible Link Control Protocol (LCP), and
3) a family of Network Control Protocols (NCP) for establishing
and configuring different network-layer protocols.
1) 連続のリンクの上にデータグラムをカプセル化するためのメソッド、2) 広げることができるLink Controlプロトコル(LCP)、および3) 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called the IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol (PPP) [1].
インターネットプロトコル(IP)(IPをControlプロトコル、IPCPと呼ぶ)を制御して、確立するために体系、基本的なLCP、およびNCPをカプセル化するPPPはPointからポイントへのプロトコル(PPP)[1]で定義されます。
This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme.
このドキュメントはLCPとIPCPによって使用されたintialオプションを定義します。 また、それはLink Quality Monitoringのメソッドと簡易認証体系を定義します。
Perkins & Hobby [Page i] RFC 1172 PPP Initial Options July 1990
パーキンスとHobby[ページi]RFC1172PPP Initial Options1990年7月
Table of Contents
目次
1. Introduction .......................................... 1
1. 序論… 1
2. Link Control Protocol (LCP) Configuration Options ..... 1
2.1 Maximum-Receive-Unit ............................ 2
2.2 Async-Control-Character-Map ..................... 3
2.3 Authentication-Type ............................. 5
2.4 Magic-Number .................................... 7
2.5 Link-Quality-Monitoring ......................... 10
2.6 Protocol-Field-Compression ...................... 11
2.7 Address-and-Control-Field-Compression ........... 13
2. 制御プロトコル(LCP)設定オプションをリンクしてください… 1 2.1 最大はユニットを受けます… 2 2.2 Asyncはキャラクター地図を制御します… 3 2.3 認証してタイプしてください… 5 2.4マジックナンバー… 7 2.5 リンクの上質のモニター… 10 2.6 プロトコル分野圧縮… 11 2.7 アドレスとコントロールは圧縮をさばきます… 13
3. Link Quality Monitoring ............................... 15
3.1 Design Motivation ............................... 15
3.2 Design Overview ................................. 15
3.3 Processes ....................................... 16
3.4 Counters ........................................ 18
3.5 Measurements, Calculations, State Variables ..... 19
3.6 Link-Quality-Report Packet Format ............... 21
3.7 Policy Suggestions .............................. 25
3.8 Example ......................................... 25
3. 上質のモニターをリンクしてください… 15 3.1 動機を設計してください… 15 3.2 概要を設計してください… 15 3.3 処理します… 16 3.4 反対します… 18 3.5の測定値(計算)が変数を述べます… 19 3.6 リンクの上質のレポートパケット・フォーマット… 21 3.7 方針提案… 25 3.8の例… 25
4. Password Authentication Protocol ...................... 27
4.1 Packet Format ................................... 27
4.2 Authenticate .................................... 29
4.3 Authenticate-Ack ................................ 31
4.4 Authenticate-Nak ................................ 32
4. パスワード認証プロトコル… 27 4.1 パケット形式… 27 4.2 認証します。 29 4.3 Ackを認証します… 31 4.4 Nakを認証します… 32
5. IP Control Protocol (IPCP) Configuration Options ...... 33
5.1 IP-Addresses .................................... 34
5.2 Compression-Type ................................ 36
5. IP制御プロトコル(IPCP)設定オプション… 33 5.1 IP-アドレス… 34 5.2 圧縮してタイプしてください… 36
REFERENCES ................................................... 37
参照… 37
SECURITY CONSIDERATIONS ...................................... 37
セキュリティ問題… 37
AUTHOR'S ADDRESS ............................................. 37
作者のアドレス… 37
Perkins & Hobby [Page ii] RFC 1172 PPP Initial Options July 1990
パーキンスとHobby[ページii]RFC1172PPP Initial Options1990年7月
1. Introduction
1. 序論
The Point-to-Point Protocol (PPP) [1] proposes a standard method of encapsulating IP datagrams, and other Network Layer protocol information, over point-to-point links. PPP also proposes an extensible Option Negotiation Protocol. [1] specifies only the protocol itself; the initial set of Configuration Options are described in this document. These Configuration Options allow MTUs to be changed, IP addresses to be dynamically assigned, header compression to be enabled, and much more.
Pointからポイントへのプロトコル(PPP)[1]はIPがデータグラムであるとカプセル化する標準方法、および他のNetwork Layerプロトコル情報を提案します、ポイントツーポイント接続の上で。 また、PPPは広げることができるOption Negotiationプロトコルを提案します。 [1]はプロトコル自体だけを指定します。 Configuration Optionsの始発は本書では説明されます。 これらのConfiguration Optionsは変えられるべきMTUs、ダイナミックに割り当てられるIPアドレス、可能にされるべきヘッダー圧縮、およびはるかに多くを許容します。
This memo is divided into several sections. Section 2 describes Configuration Options for the Link Control Protocol. Section 3 specifies the use of the Link Quality Monitoring option. Section 4 defines a simple Password Authentication Protocol. Finally, Section 5 specifies Configuration Options for the IP Control Protocol.
このメモは数人のセクションに分割されます。 セクション2はLink ControlプロトコルのためにConfiguration Optionsについて説明します。 セクション3はLink Quality Monitoringオプションの使用を指定します。 セクション4は簡単なパスワード認証プロトコルを定義します。 最終的に、セクション5はIP ControlプロトコルにConfiguration Optionsを指定します。
2. Link Control Protocol (LCP) Configuration Options
2. リンク制御プロトコル(LCP)設定オプション
As described in [1], LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated. Negotiable modifications proposed in this document include such things as the maximum receive unit, async control character mapping, the link authentication method, etc.
[1]で説明されるように、LCP Configuration Optionsは、ポイントツーポイント接続の標準の特性への変更が交渉されるのを許容します。 本書では提案された交渉可能な変更は最大がユニット、async制御文字マッピング、リンク認証方法を受けるのなどようなものを含んでいます。
The initial proposed values for the LCP Configuration Option Type field (see [1]) are assigned as follows:
初期はLCP Configuration Option Type分野に値を提案しました。([1])が以下の通り割り当てられるのを確実にしてください:
1 Maximum-Receive-Unit
2 Async-Control-Character-Map
3 Authentication-Type
4 NOT ASSIGNED
5 Magic-Number
6 Link-Quality-Monitoring
7 Protocol-Field-Compression
8 Address-and-Control-Field-Compression
1 アドレスとコントロールが圧縮をさばいた状態で、最大がユニットを受けている2 3認証タイプAsync規制キャラクター地図4は上質のモニターをリンクしている5マジックナンバー6 7プロトコル分野圧縮8を割り当てませんでした。
Perkins & Hobby [Page 1] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[1ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
2.1. Maximum-Receive-Unit
2.1. 最大はユニットを受けます。
Description
記述
This Configuration Option provides a way to negotiate the maximum
packet size used across one direction of a link. By default, all
implementations must be able to receive frames with 1500 octets of
Information.
このConfiguration Optionはリンクの一方向の向こう側に使用される最大のパケットサイズを交渉する方法を提供します。 デフォルトで、すべての実装が情報の1500の八重奏でフレーム搬入できなければなりません。
This Configuration Option may be sent to inform the remote end
that you can receive larger frames, or to request that the remote
end send you smaller frames. If smaller frames are requested, an
implementation MUST still be able to receive 1500 octet frames in
case link synchronization is lost.
あなたが、より大きいフレームを受け取ることができることをリモートエンドに知らせるか、またはリモートエンドが、より小さいフレームをあなたに送るよう要求するためにこのConfiguration Optionを送るかもしれません。 より小さいフレームが要求されるなら、リンク同期が無くなるといけないので、実装はまだ1500個の八重奏フレームを受け取ることができなければなりません。
A summary of the Maximum-Receive-Unit Configuration Option format is shown below. The fields are transmitted from left to right.
Maximumがユニットを受けているConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Maximum-Receive-Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 最大はユニットを受けます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
4
4
Maximum-Receive-Unit
最大はユニットを受けます。
The Maximum-Receive-Unit field is two octets and indicates the new
maximum receive unit. The Maximum-Receive-Unit covers only the
Data Link Layer Information field but not the header, trailer or
any transparency bits or bytes.
Maximumがユニットを受けている分野は、2つの八重奏であり、新しい最大がユニットを受けるのを示します。 Maximumがユニットを受けるのは、Data Link Layer情報分野だけをカバーしていますが、どんなヘッダーや、トレーラや、透明ビットやまたはバイトカバーするというわけではありません。
Default
デフォルト
1500
1500
Perkins & Hobby [Page 2] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[2ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
2.2. Async-Control-Character-Map
2.2. Async規制キャラクター地図
Description
記述
This Configuration Option provides a way to negotiate the use of
control character mapping on asynchronous links. By default, PPP
maps all control characters into an appropriate two character
sequence. However, it is rarely necessary to map all control
characters and often times it is unnecessary to map any
characters. A PPP implementation may use this Configuration
Option to inform the remote end which control characters must
remain mapped and which control characters need not remain mapped
when the remote end sends them. The remote end may still send
these control characters in mapped format if it is necessary
because of constraints at its (the remote) end. This option does
not solve problems for communications links that can send only 7-
bit characters or that can not send all non-control characters.
このConfiguration Optionは非同期なリンクにおける制御文字マッピングの使用を交渉する方法を提供します。 デフォルトで、PPPは適切な2キャラクタシーケンスにすべての制御文字を写像します。 しかしながら、すべての制御文字としばしば回を写像するために、どんなキャラクタも写像するのが不要であることはめったに必要ではありません。 PPP実装は、どの制御文字が写像されたままで残らなければならないか、そして、どの制御文字はリモートエンドがそれらを送るとき、写像されたままで残る必要はないかをリモートエンドに知らせるのにこのConfiguration Optionを使用するかもしれません。 それが(リモート)終わりに規制のために必要であるなら、リモートエンドは写像している形式でまだこれらの制御文字を送るかもしれません。 このオプションは7の噛み付いているキャラクタしか送ることができないというわけではないか、またはすべての非制御文字を送ることができるというわけではないコミュニケーションリンクへの問題を解決しません。
There may be some use of synchronous-to-asynchronous converters
(some built into modems) in Point-to-point links resulting in a
synchronous PPP implementation on one end of a link and an
asynchronous implemention on the other. It is the responsibility
of the converter to do all mapping conversions during operation.
To enable this functionality, synchronous PPP implementations MUST
always accept a Async-Control-Character-Map Configuration Option
(it MUST always respond to an LCP Configure-Request specifying
this Configuration Option with an LCP Configure-Ack). However,
acceptance of this Configuration Option does not imply that the
synchronous implementation will do any character mapping, since
synchronous PPP uses bit-stuffing rather than character-stuffing.
Instead, all such character mapping will be performed by the
asynchronous-to-synchronous converter.
Pointからポイントへのリンクでの非同期であるのと同期のコンバータ(モデムが組み込まれたいくつか)のもう片方でリンクと非同期なimplementionの片端で同期PPP実装をもたらす何らかの使用があるかもしれません。 操作の間、すべてのマッピング変換をするのは、コンバータの責任です。 この機能性を可能にするために、同期PPP実装はいつもAsync規制キャラクター地図Configuration Optionを受け入れなければなりません(それはLCP Configure-Ackと共にこのConfiguration Optionを指定しながら、いつもLCP Configure-要求に応じなければなりません)。 しかしながら、このConfiguration Optionの承認は、同期実装がどんなキャラクタマッピングもするのを含意しません、同期PPPがキャラクタ詰め物よりむしろビット・スタッフィングを使用するので。 代わりに、そのようなすべてのキャラクタマッピングが同期変流機への非同期によって実行されるでしょう。
A summary of the Async-Control-Character-Map Configuration Option format is shown below. The fields are transmitted from left to right.
Async規制キャラクター地図Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Async-Control-Character-Map
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| Async規制キャラクター地図+++++++++++++++++++++++++++++++++(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2
2
Perkins & Hobby [Page 3] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[3ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Length
長さ
6
6
Async-Control-Character-Map
Async規制キャラクター地図
The Async-Control-Character-Map field is four octets and indicates
the new async control character map. The map is encoded in big-
endian fashion where each numbered bit corresponds to the ASCII
control character of the same value. If the bit is cleared to
zero, then that ASCII control character need not be mapped. If
the bit is set to one, then that ASCII control character must
remain mapped. E.g., if bit 19 is set to zero, then the ASCII
control character 19 (DC3, Control-S) may be sent in the clear.
Async規制キャラクター地図分野は、4つの八重奏であり、新しいasync制御文字地図を示します。 地図はそれぞれの番号付のビットが同じ価値のASCII制御文字に対応する大きいエンディアンファッションでコード化されます。 ビットがゼロまできれいにされるなら、そのASCII制御文字は写像される必要はありません。 ビットが1つに設定されるなら、そのASCII制御文字は写像されたままで残らなければなりません。 例えば、ビット19をゼロに設定するなら、明確でASCII制御文字19(DC3、Control-S)を送るかもしれません。
Default
デフォルト
All ones (0xffffffff).
すべてのもの(0xffffffff)。
Perkins & Hobby [Page 4] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[4ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
2.3. Authentication-Type
2.3. 認証タイプ
Description
記述
On some links it may be desirable to require a peer to
authenticate itself before allowing Network Layer protocol data to
be exchanged. This Configuration Option provides a way to
negotiate the use of a specific authentication protocol. By
default, authentication is not necessary. If an implementation
requires that the remote end authenticate with some specific
authentication protocol, then it should negotiate the use of that
authentication protocol with this Configuration Option.
いくつかのリンクでは、同輩がNetwork Layerプロトコルデータが交換されるのを許容する前にそれ自体を認証するのが必要であるのは望ましいかもしれません。 このConfiguration Optionは特定の認証プロトコルの使用を交渉する方法を提供します。 デフォルトで、認証は必要ではありません。 実装が、何かが特定の状態でリモートエンドが認証プロトコルを認証するのを必要とするなら、それはこのConfiguration Optionとのその認証プロトコルの使用を交渉するべきです。
Successful negotiation of the Authentication-Type option adds an
additional Authentication phase to the Link Control Protocol.
This phase is after the Link Quality Determination phase, and
before the Network Layer Protocol Configuration Negotiation phase.
Advancement from the Authentication phase to the Network Layer
Protocol Configuration Negotiation phase may not occur until the
peer is successfully authenticated using the negotiated
authentication protocol.
Authentication-タイプオプションのうまくいっている交渉は追加AuthenticationフェーズをLink Controlプロトコルに追加します。 Link Quality Determinationフェーズの後、およびNetwork LayerプロトコルConfiguration Negotiationフェーズの前に、このフェーズはあります。 同輩が交渉された認証プロトコルを使用することで首尾よく認証されるまで、AuthenticationフェーズからNetwork LayerプロトコルConfiguration Negotiationフェーズまでの前進は起こらないかもしれません。
An implementation may allow the remote end to pick from more than
one authentication protocol. To achieve this, it may include
multiple Authentication-Type Configuration Options in its
Configure-Request packets. An implementation receiving a
Configure-Request specifying multiple Authentication-Types may
accept at most one of the negotiable authentication protocols and
should send a Configure-Reject specifying all of the other
specified authentication protocols.
実装は1つ以上の認証プロトコルから選ぶリモートエンドを許容するかもしれません。 これを達成するために、それはConfigure-リクエスト・パケットに複数のAuthentication-タイプConfiguration Optionsを含むかもしれません。 複数のAuthentication-タイプを指定しながらConfigure-要求を受け取る実装で、Configure-廃棄物は、交渉可能な認証プロトコルの1つを高々受け入れるかもしれなくて、他の指定された認証プロトコルのすべてを指定するべきです。
It is recommended that each PPP implementation support
configuration of authentication parameters at least on a per-
interface basis, if not a per peer entity basis. The parameters
should specify which authetication techniques are minimally
required as a prerequisite to establishment of a PPP connection,
either for the specified interface or for the specified peer
entity. Such configuration facilities are necessary to prevent an
attacker from negotiating a reduced security authentication
protocol, or no authentication at all, in an attempt to circumvent
this authentication facility.
それぞれのPPP実装が少なくともaに関する認証パラメタの構成をサポートするのが、お勧めである、-、同輩実体基礎単位で基礎、またはaを連結してください。 パラメタは、どのautheticationのテクニックがPPP接続の設立への前提条件、指定されたインタフェースまたは指定された同輩実体に最少量で必要であるかを指定するべきです。 そのような構成施設が減少しているセキュリティ認証プロトコルを交渉しますが、攻撃者がどんな認証も全く交渉するのを防がないように必要です、この認証施設を回避する試みで。
If an implementation sends a Configure-Ack with this Configuration
Option, then it is agreeing to authenticate with the specified
protocol. An implementation receiving a Configure-Ack with this
Configuration Option should expect the remote end to authenticate
with the acknowledged protocol.
実装がこのConfiguration OptionとConfigure-Ackを送るなら、それが指定されたプロトコルで認証するのに同意しているその時です。 承認されたプロトコルで認証するこのConfiguration Optionと共にConfigure-Ackを受けるとリモートエンドが予想されるべきである実装。
Perkins & Hobby [Page 5] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[5ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
There is no requirement that authentication be full duplex or that
the same authentication protocol be used in both directions. It
is perfectly acceptable for different authentication protocols to
be used in each direction. This will, of course, depend on the
specific authentication protocols negotiated.
認証が全二重であるか同じ認証プロトコルが両方の方向に使用されるという要件が全くありません。 異なった認証プロトコルが各方向に使用されるのは、完全に許容できます。 これはもちろん交渉された特定の認証プロトコルによるでしょう。
This document defines a simple Password Authentication Protocol in
Section 4. Development of other more secure protocols is
encouraged.
このドキュメントはセクション4で簡単なパスワード認証プロトコルを定義します。 他の、より安全なプロトコルの開発は奨励されます。
A summary of the Authentication-Type Configuration Option format is shown below. The fields are transmitted from left to right.
Authentication-タイプConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
3
3
Length
長さ
>= 4
>= 4
Authentication-Type
認証タイプ
The Authentication-Type field is two octets and indicates the type
of authentication protocol desired. Values for the
Authentication-Type are always the same as the PPP Data Link Layer
Protocol field values for that same authentication protocol. The
most up-to-date values of the Authentication-Type field are
specified in "Assigned Numbers" [2]. Initial values are assigned
as follows:
Authentication-タイプ分野は、2つの八重奏であり、認証プロトコルのタイプが望んでいたのを示します。 Authentication-タイプのための値はその同じ認証のためのPPP Data Link Layerプロトコル分野値が議定書を作るのといつも同じです。 Authentication-タイプ分野の最も最新の値は「規定番号」[2]で指定されます。 初期の値は以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
c023 Password Authentication Protocol
c023パスワード認証プロトコル
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the particular authentication protocol.
Data分野は、ゼロか、より多くの八重奏であり、特定の認証プロトコルで決定するように追加データを含んでいます。
Perkins & Hobby [Page 6] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[6ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Default
デフォルト
No authentication protocol necessary.
いいえ認証プロトコル必要です。
2.4. Magic-Number
2.4. マジックナンバー
Description
記述
This Configuration Option provides a way to detect looped-back
links and other Data Link Layer anomalies. This Configuration
Option may be required by some other Configuration Options such as
the Link-Quality-Monitoring Configuration Option.
このConfiguration Optionは輪にされて逆リンクと他のData Link Layer例外を検出する方法を提供します。 このConfiguration OptionはLinkの上質のモニターConfiguration Optionなどのある他のConfiguration Optionsによって必要とされるかもしれません。
Before this Configuration Option is requested, an implementation
must choose its Magic-Number. It is recommended that the Magic-
Number be chosen in the most random manner possible in order to
guarantee with very high probability that an implementation will
arrive at a unique number. A good way to choose a unique random
number is to start with an unique seed. Suggested sources of
uniqueness include machine serial numbers, other network hardware
addresses, time-of-day clocks, etc. Particularly good random
number seeds are precise measurements of the inter-arrival time of
physical events such as packet reception on other connected
networks, server response time, or the typing rate of a human
user. It is also suggested that as many sources as possible be
used simultaneously.
このConfiguration Optionが要求されている前に、実装はマジック番号を選ばなければなりません。 マジック数が実装がそうするという非常に高い確率でユニークな数に達するように保証するために可能な最も無作為の方法で選ばれているのは、お勧めです。 ユニークな乱数を選ぶ早道はユニークな種子から始めることです。 ユニークさの提案された源はマシン通し番号、他のネットワークハードウェアアドレス、時刻時計などを含んでいます。 特に良い乱数種子は物理的なイベントの相互到着時間の人間のユーザの他の接続ネットワーク、サーバ応答時間、またはタイプレートにおけるパケットレセプションなどの正確な寸法です。 また、できるだけ多くのソースが同時に使用されることが提案されます。
When a Configure-Request is received with a Magic-Number
Configuration Option, the received Magic-Number should be compared
with the Magic-Number of the last Configure-Request sent to the
peer. If the two Magic-Numbers are different, then the link is
not looped-back, and the Magic-Number should be acknowledged. If
the two Magic-Numbers are equal, then it is possible, but not
certain, that the link is looped-back and that this Configure-
Request is actually the one last sent. To determine this, a
Configure-Nak should be sent specifying a different Magic-Number
value. A new Configure-Request should not be sent to the peer
until normal processing would cause it to be sent (i.e., until a
Configure-Nak is received or the Restart timer runs out).
マジック数のConfiguration Optionと共にConfigure-要求を受け取るとき、同輩に送る最後のConfigure-要求のマジック数に容認されたマジック数をたとえるべきです。 2つのマジック番号が異なるなら、リンクは-逆で輪にされません、そして、マジック数は承認されるべきです。 2つのマジック番号が等しいなら、可能ですが、確かでない、リンクが-逆で輪にされて、このConfigure要求が最後に実際にものであることは発信しました。 これを決定するために、Configure-Nakに異なったマジック数の値を指定させるべきです。 正常処理でそれを送るだろうまで(すなわち、Configure-Nakが受け取られているか、またはRestartタイマがなくなるまで)新しいConfigure-要求を同輩に送るべきではありません。
Reception of a Configure-Nak with a Magic-Number different from
that of the last Configure-Nak sent to the peer proves that a link
is not looped-back, and indicates a unique Magic-Number. If the
Magic-Number is equal to the one sent in the last Configure-Nak,
the possibility of a loop-back is increased, and a new Magic-
Number should be chosen. In either case, a new Configure-Request
should be sent with the new Magic-Number.
同輩に送られた最後のConfigure-Nakのものと異なったマジック数があるConfigure-Nakのレセプションは、リンクが-逆で輪にされないと立証して、ユニークなマジック数を示します。 マジック数が最後のConfigure-Nakで送られたものと等しいなら、ループバックの可能性は増強されます、そして、新しいマジック数は選ばれるべきです。 どちらの場合ではも、新しいマジック数と共に新しいConfigure-要求を送るべきです。
Perkins & Hobby [Page 7] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[7ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
If the link is indeed looped-back, this sequence (transmit
Configure-Request, receive Configure-Request, transmit Configure-
Nak, receive Configure-Nak) will repeat over and over again. If
the link is not looped-back, this sequence may occur a few times,
but it is extremely unlikely to occur repeatedly. More likely,
the Magic-Numbers chosen at either end will quickly diverge,
terminating the sequence. The following table shows the
probability of collisions assuming that both ends of the link
select Magic-Numbers with a perfectly uniform distribution:
リンクが本当に-逆で輪にされると、この系列(Configure-要求を送信してください、そして、Configure-要求を受け取ってください、そして、Configure- Nakを送信してください、そして、Configure-Nakを受ける)は再三再び繰り返すでしょう。 リンクが-逆で輪にされないなら、この系列は数回起こるかもしれませんが、それは繰り返して非常に起こりそうにはありません。 おそらく、系列を終えると、どちらの終わりにも選ばれたマジック数は急速に分岐するでしょう。 以下のテーブルは衝突が、リンクの両端が完全に一定の分配があるマジック数を選択すると仮定するという確率を示しています:
Number of Collisions Probability
-------------------- ---------------------
1 1/2**32 = 2.3 E-10
2 1/2**32**2 = 5.4 E-20
3 1/2**32**3 = 1.3 E-29
衝突確率の数-------------------- --------------------- 1 1/2**32 = 2.3E-10 2 1/2**32**2 = 5.4E-20 3 1/2**32**3 = 1.3E-29
Good sources of uniqueness or randomness are required for this
divergence to occur. If a good source of uniqueness cannot be
found, it is recommended that this Configuration Option not be
enabled; Configure-Requests with the option should not be
transmitted and any Magic-Number Configuration Options which the
peer sends should be either acknowledged or rejected. In this
case, loop-backs cannot be reliably detected by the
implementation, although they may still be detectable by the peer.
ユニークさか偶発性の良い源が、この分岐が起こるのに必要です。 ユニークさの良い源を見つけることができないなら、このConfiguration Optionが有効にされないのは、お勧めです。 オプションで要求を構成するのは、伝えられて承認されるべきであるか、または拒絶されて、同輩が送るどんなマジック数のConfiguration Optionsであるべきではありません。 この場合、それらは同輩がまだ検出可能であるかもしれませんが、実装はループバックを確かに検出できません。
If an implementation does transmit a Configure-Request with a
Magic-Number Configuration Option, then it MUST NOT respond with a
Configure-Reject if its peer also transmits a Configure-Request
with a Magic-Number Configuration Option. That is, if an
implementation desires to use Magic Numbers, then it MUST also
allow its peer to do so. If an implementation does receive a
Configure-Reject in response to a Configure-Request, it can only
mean that the link is not looped-back, and that its peer will not
be using Magic-Numbers. In this case, an implementation may act
as if the negotiation had been successful (as if it had instead
received a Configure-Ack).
実装がマジック数のConfiguration OptionとのConfigure-要求を伝えるなら、また、同輩がマジック数のConfiguration OptionとのConfigure-要求を伝えるなら、それはConfigure-廃棄物で応じてはいけません。 また、すなわち、実装が、マジック民数記を使用することを望んでいるなら、それで、同輩はそうすることができなければなりません。 実装がConfigure-要求に対応してConfigure-廃棄物を受けるなら、それは、リンクが-逆で輪にされないで、また同輩がマジック数を使用しないことを意味できるだけです。 この場合、まるで交渉がうまくいったかのように(まるで代わりにConfigure-Ackを受けたかのように)実装は行動するかもしれません。
The Magic-Number also may be used to detect looped-back links
during normal operation as well as during Configuration Option
negotiation. All Echo-Request, Echo-Reply, Discard-Request, and
Link-Quality-Report LCP packets have a Magic-Number field which
MUST normally be transmitted as zero, and MUST normally be ignored
on reception. However, once a Magic-Number has been successfully
negotiated, an LCP implementation MUST begin transmitting these
packets with the Magic-Number field set to its negotiated Magic-
Number. Additionally, the Magic-Number field of these packets may
be inspected on reception. All received Magic-Number fields should
be equal to either zero or the peer's unique Magic-Number,
マジック数も、通常の操作とConfiguration Option交渉の間、輪にされて逆リンクを検出するのに使用されるかもしれません。 Echo-要求、Echo-回答、Discard-要求、およびLinkの上質のレポートLCPパケットにはすべて、通常、ゼロとして伝えなければならなくて、通常、レセプションで無視しなければならないマジックナンバーフィールドがあります。 しかしながら、マジック数がいったん首尾よく交渉されると、LCP実装は、マジックナンバーフィールドセットで交渉されたマジック番号にこれらのパケットを伝え始めなければなりません。 さらに、これらのパケットのマジックナンバーフィールドはレセプションで点検されるかもしれません。 すべての容認されたマジックナンバーフィールドがゼロか同輩のユニークなマジック番号のどちらかと等しいはずです。
Perkins & Hobby [Page 8] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[8ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
depending on whether or not the peer negotiated one. Reception of
a Magic-Number field equal to the negotiated local Magic-Number
indicates a looped-back link. Reception of a Magic-Number other
than the negotiated local Magic-Number or or the peer's negotiated
Magic-Number, or zero if the peer didn't negotiate one, indicates
a link which has been (mis)configured for communications with a
different peer.
同輩が1つを交渉したかどうかによります。 交渉された地方のマジック数と等しいマジックナンバーフィールドのレセプションは輪にされて逆リンクを示します。 または、交渉された地方のマジック数以外のマジック数のレセプション、同輩が1つを交渉しないで、そうするリンクを示すなら同輩がマジック数、またはゼロを交渉した、(誤、)、異なった同輩とのコミュニケーションのために、構成されています。
Procedures for recovery from either case are unspecified and may
vary from implementation to implementation. A somewhat
pessimistic procedure is to assume an LCP Physical-Layer-Down
event and make an immediate transition to the Closed state. A
further Active-Open event will begin the process of re-
establishing the link, which can't complete until the loop-back
condition is terminated and Magic-Numbers are successfully
negotiated. A more optimistic procedure (in the case of a loop-
back) is to begin transmitting LCP Echo-Request packets until an
appropriate Echo-Reply is received, indicating a termination of
the loop-back condition.
どちらかのケースからの回復のための手順は、不特定であり、実装によって異なるかもしれません。 いくらか悲観的な手順は、LCP Physical層がダウンしているイベントを仮定して、Closed状態への即座の変遷をすることです。 一層のActive-オープン・ゲームはリンクを再設立するプロセスを開始するでしょう、そして、どれがループバックまで状態を完成できないかは、終えられます、そして、マジック数は首尾よく交渉されます。 より楽観的な手順(輪の後部の場合における)は適切なEcho-回答が受け取られているまでLCP Echo-リクエスト・パケットを伝え始めることです、ループバック状態の終了を示して。
A summary of the Magic-Number Configuration Option format is shown below. The fields are transmitted from left to right.
マジック数のConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Magic-Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-Number (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| マジックナンバー+++++++++++++++++++++++++++++++++マジックナンバー(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5
5
Length
長さ
6
6
Magic-Number
マジックナンバー
The Magic-Number field is four octets and indicates a number which
is very likely to be unique to one end of the link. A Magic-
Number of zero is illegal and must not be sent.
マジックナンバーフィールドは、4つの八重奏であり、非常にありそうな数がリンクの片端に特有であることを示します。 マジック数のゼロを不法であり、送ってはいけません。
Default
デフォルト
None.
なし。
Perkins & Hobby [Page 9] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[9ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
2.5. Link-Quality-Monitoring
2.5. リンクの上質のモニター
Description
記述
On some links it may be desirable to determine when, and how
often, the link is dropping data. This process is called Link
Quality Monitoring and is implemented by periodically transmitting
Link-Quality-Report packets as described in Section 3. The Link-
Quality-Monitoring Configuration Option provides a way to enable
the use of Link-Quality-Report packets, and also to negotiate the
rate at which they are transmitted. By default, Link Quality
Monitoring and the use of Link-Quality-Report packets is disabled.
いくつかのリンクでは、しばしば、リンクがいつ、どのようにデータを下げているかを決定するのは望ましいかもしれません。 このプロセスは、セクション3で説明されるようにLinkの上質のレポートパケットを伝えながら、Link Quality Monitoringと呼ばれて、定期的によって実装されます。 品質をモニターするLink Configuration OptionはLinkの上質のレポートパケットの使用を可能にして、また、それらが伝えられるレートを交渉する方法を提供します。 デフォルトで、Linkの上質のレポートパケットのLink Quality Monitoringと使用は障害があります。
A summary of the Link-Quality-Monitoring Configuration Option format is shown below. The fields are transmitted from left to right.
Configuration OptionがフォーマットするLinkの上質のモニターの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reporting-Period
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reporting-Period (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 報告期間の+++++++++++++++++++++++++++++++++報告期間(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6
6
Length
長さ
6
6
Reporting-Period
報告期間
The Reporting-Period field is four octets and indicates the
maximum time in micro-seconds that the remote end should wait
between transmission of LCP Link-Quality-Report packets. A value
of zero is illegal and should always be nak'd or rejected. An LCP
implementation is always free to transmit LCP Link-Quality-Report
packets at a faster rate than that which was requested by, and
acknowledged to, the remote end.
Reporting-期間の分野は、4つの八重奏であり、マイクロセカンドの最大の時にリモートエンドがLCP Linkの上質のレポートパケットのトランスミッションの間で待つべきであるのを示します。 ゼロの値が不法であり、いつもnakであるべきである、または、拒絶されているでしょう。 LCP実装はいつも自由にそれより速いレートにおける要求されていて、承認されるLCP Linkの上質のレポートパケットを伝えることができます、リモートエンド。
Default
デフォルト
None
なし
Perkins & Hobby [Page 10] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[10ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
2.6. Protocol-Field-Compression
2.6. プロトコル分野圧縮
Description
記述
This Configuration Option provides a way to negotiate the
compression of the Data Link Layer Protocol field. By default,
all implementations must transmit standard PPP frames with two
octet Protocol fields. However, PPP Protocol field numbers are
chosen such that some values may be compressed into a single octet
form which is clearly distinguishable from the two octet form.
This Configuration Option may be sent to inform the remote end
that you can receive compressed single octet Protocol fields.
Compressed Protocol fields may not be transmitted unless this
Configuration Option has been received.
このConfiguration OptionはData Link Layerプロトコル分野の圧縮を交渉する方法を提供します。 デフォルトで、すべての実装が2つの八重奏プロトコル分野がある標準のPPPフレームを伝えなければなりません。 しかしながら、PPPプロトコル分野番号は、2八重奏フォームから明確に区別可能なただ一つの八重奏フォームにいくつかの値を圧縮できるように選ばれています。 あなたが圧縮されたただ一つの八重奏プロトコル野原を受けることができることをリモートエンドに知らせるためにこのConfiguration Optionを送るかもしれません。 このConfiguration Optionが受け取られていない場合、圧縮されたプロトコル野原は伝えられないかもしれません。
As previously mentioned, the Protocol field uses an extension
mechanism consistent with the ISO 3309 extension mechanism for the
Address field; the Least Significant Bit (LSB) of each octet is
used to indicate extension of the Protocol field. A binary "0" as
the LSB indicates that the Protocol field continues with the
following octet. The presence of a binary "1" as the LSB marks
the last octet of the Protocol field. Notice that any number of
"0" octets may be prepended to the field, and will still indicate
the same value (consider the two representations for 3, 00000011
and 00000000 00000011).
以前に言及されるように、プロトコル分野はAddress分野において、3309年のISO拡張機能と一致した拡張機能を使用します。 それぞれの八重奏のLeast Significant Bit(LSB)は、プロトコル分野の拡大を示すのに使用されます。 バイナリー「LSBが、プロトコル分野が以下の八重奏を続行するのを示すような0インチ。」 「LSBとしての1インチはプロトコル分野の最後の八重奏であるとマークする」バイナリーの存在。 いずれも付番する「0インチの八重奏は、その分野にprependedされるかもしれなくて、それでも、同じ値を示3、00000011、および00000000 00000011の2つの表現を(考えてください)」通知。
In the interest of simplicity, the standard PPP frame uses this
fact and always sends Protocol fields with a two octet
representation. Protocol field values less than 256 (decimal) are
prepended with a single zero octet even though transmission of
this, the zero and most significant octet, is unnecessary.
簡単さのために、標準のPPPフレームは、この事実を使用して、プロトコル野原は2八重奏表現と共にいつも行きます。 このトランスミッション(ゼロと最も重要な八重奏)は、不要ですが、256(10進)がシングルでprependedされるより少ないプロトコル分野値は八重奏のゼロに合っています。
However, when using low speed links, it is desirable to conserve
bandwidth by sending as little redundant data as possible. The
Protocol Compression Configuration Option allows a trade-off
between implementation simplicity and bandwidth efficiency. If
successfully negotiated, the ISO 3309 extension mechanism may be
used to compress the Protocol field to one octet instead of two.
The large majority of frames are compressible since data protocols
are typically assigned with Protocol field values less than 256.
しかしながら、低速リンクを使用するとき、できるだけ少ししか冗長データを送らないことによって帯域幅を保存するのは望ましいです。 プロトコルCompression Configuration Optionは実装の簡単さと帯域幅効率の間のトレードオフを許容します。 首尾よく交渉されるなら、3309年のISO拡張機能は、2の代わりに1つの八重奏にプロトコル分野を圧縮するのに使用されるかもしれません。 データプロトコルがプロトコル分野値256で通常割り当てられるので、フレームの大多数は圧縮性です。
To guarantee unambiguous recognition of LCP packets, the Protocol
field must never be compressed when sending any LCP packet. In
addition, PPP implementations must continue to be robust and MUST
accept PPP frames with double-octet, as well as single-octet,
Protocol fields, and MUST NOT distinguish between them.
どんなLCPパケットも送るとき、LCPの明白な認識にパケット、プロトコル分野を保証するのは決して圧縮していてはいけません。 さらに、PPP実装は、ずっと強健でなければならなく、二重八重奏の、そして、ただ一つの八重奏のプロトコル分野があるPPPフレームを受け入れなければならなくて、それらを見分けてはいけません。
When a Protocol field is compressed, the Data Link Layer FCS field
プロトコルであるときに、分野は圧縮されて、Data Link Layer FCSは分野です。
Perkins & Hobby [Page 11] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[11ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
is calculated on the compressed frame, not the original
uncompressed frame.
オリジナルの解凍されたフレームではなく、圧縮されたフレームの上に計算されます。
A summary of the Protocol-Field-Compression Configuration Option format is shown below. The fields are transmitted from left to right.
プロトコル分野圧縮Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7
7
Length
長さ
2
2
Default
デフォルト
Disabled.
障害がある。
Perkins & Hobby [Page 12] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[12ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
2.7. Address-and-Control-Field-Compression
2.7. アドレスとコントロール分野圧縮
Description
記述
This Configuration Option provides a way to negotiate the
compression of the Data Link Layer Address and Control fields. By
default all implementations must transmit frames with Address and
Control fields and must use the hexadecimal values 0xff and 0x03
respectively. Since these fields have constant values, they are
easily compressed. this Configuration Option may be used to
inform the remote end that you can receive compressed Address and
Control fields.
このConfiguration OptionはData Link Layer AddressとControl分野の圧縮を交渉する方法を提供します。 デフォルトで、すべての実装が、AddressがあるフレームとControl野原を伝えなければならなくて、それぞれ16進値0xffと0x03を使用しなければなりません。 これらの分野には恒常価値があるので、それらが容易に圧縮されます。このConfiguration Optionは、あなたが圧縮されたAddressとControl野原を受け取ることができることをリモートエンドに知らせるのに使用されるかもしれません。
Compressed Address and Control fields are formed by simply
omitting them in all non-ambiguous cases. Ambiguous frames may
not be compressed. Ambiguous cases result when the two octets
following the Address and Control fields have values that could be
interpreted as valid Address and Control fields (i.e., 0xff,
0x03). This can happen when Protocol-Field-Compression is enabled
and the Protocol field is compressed to one octet. If the
Protocol value is 0xff, and the first octet of the Information
field is 0x03, the result is ambiguous and the Address and Control
fields must not be compressed on transmission.
圧縮されたAddressとControl分野は、すべての非あいまいな場合で単にそれらを省略することによって、形成されます。 あいまいなフレームは圧縮されないかもしれません。 AddressとControl野原に続く2つの八重奏がそれが値であることができたことを持っているとき、あいまいなケース結果は有効なAddressとControl分野(すなわち、0xff、0×03)を解釈しました。 プロトコル分野圧縮が可能にされて、プロトコル分野が1つの八重奏に圧縮されるとき、これは起こることができます。 プロトコル値が0xffであり、情報分野の最初の八重奏が0×03であるなら、結果はあいまいです、そして、AddressとControl分野はトランスミッションのときに圧縮されてはいけません。
On reception, the Address and Control fields are decompressed by
examining the first two octets. If they contain the values 0xff
and 0x03, they are assumed to be the Address and Control fields.
If not, it is assumed that the fields were compressed and were not
transmitted.
レセプションでは、AddressとControl分野は、最初の2つの八重奏を調べることによって、減圧されます。 値0xffと0x03を含んでいるなら、それらはAddressとControl分野であると思われます。 そうでなければ、野原が圧縮されて、伝えられなかったと思われます。
One additional case in which the Address and Control fields must
never be compressed is when sending any LCP packet. This rule
guarantees unambiguous recognition of LCP packets.
どんなLCPパケットも送るとき、AddressとControl分野を決して圧縮してはいけないある追加場合があります。 この規則はLCPパケットの明白な認識を保証します。
When the Address and Control fields are compressed, the Data Link
Layer FCS field is calculated on the compressed frame, not the
original uncompressed frame.
AddressとControl分野が圧縮されるとき、Data Link Layer FCS分野はオリジナルの解凍されたフレームではなく、圧縮されたフレームの上に計算されます。
A summary of the Address-and-Control-Field-Compression configuration option format is shown below. The fields are transmitted from left to right.
Addressとコントロール分野圧縮設定オプション形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins & Hobby [Page 13] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[13ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Type
タイプ
8
8
Length
長さ
2
2
Default
デフォルト
Not compressed.
圧縮されません。
Perkins & Hobby [Page 14] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[14ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
3. Link Quality Monitoring
3. 上質のモニターをリンクしてください。
Data communications links are rarely perfect. Packets can be dropped or corrupted for various reasons (line noise, equipment failure, buffer overruns, etc.). Sometimes, it is desirable to determine when, and how often, the link is dropping data. Routers, for example, may want to temporarily allow another route to take precedence. An implementation may also have the option of disconnecting and switching to an alternate link. The process of determining data loss is called "Link Quality Monitoring".
データ通信リンクはめったに完全ではありません。 パケットは、様々な理由(回線雑音、設備故障、バッファ超過など)で落とされるか、または崩壊できます。 時々、しばしば、リンクがいつ、どのようにデータを落としているかを決定するのは望ましいです。 例えば、ルータは、別のルートが優先するのを一時許容したがっているかもしれません。 また、実現には、交互のリンクに連絡を断って、切り替わるオプションがあるかもしれません。 データの損失を決定する過程は「リンクの上質のモニター」と呼ばれます。
3.1. Design Motivation
3.1. デザイン動機
There are many different ways to measure link quality, and even more ways to react to it. Rather than specifying a single scheme, Link Quality Monitoring is divided into a "mechanism" and a "policy". PPP fully specifies the "mechanism" for Link Quality Monitoring by defining the LCP Link-Quality-Report (LQR) packet and specifying a procedure for its use. PPP does NOT specify a Link Quality Monitoring "policy" -- how to judge link quality or what to do when it is inadequate. That is left as an implementation decision, and can be different at each end of the link. Implementations are allowed, and even encouraged, to experiment with various link quality policies. The Link Quality Monitoring mechanism specification insures that two implementations with different policies may communicate and interoperate.
リンク品質を測定する多くの異なった方法、およびそれに反応するさらに多くの方法があります。 ただ一つの計画を指定するよりむしろ、Link Quality Monitoringは「メカニズム」と「方針」に分割されます。 PPPは、「メカニズム」をLCP Linkの上質のレポート(LQR)パケットを定義して、使用のための手順を指定することによって、Link Quality Monitoringに完全に指定します。 PPPはLink Quality Monitoring「方針」を指定しません--どうリンク品質を判断するか、そして、それが不十分であるときにするべきこと。 それは、実現決定として出られて、リンクの各端のときに異なっている場合があります。 実現は、様々なリンク品質方針を実験するよう許容されていて、奨励さえされます。 Link Quality Monitoringメカニズム仕様は異なった方針がある2つの実現が交信して、共同利用するかもしれないのを保障します。
To allow flexible policies to be implemented, the PPP Link Quality Monitoring mechanism measures data loss in units of packets, octets, and Link-Quality-Reports. Each measurement is made separately for each half of the link, both inbound and outbound. All measurements are communicated to both ends of the link so that each end of the link can implement its own link quality policy for both its outbound and inbound links.
フレキシブルな政策が実施されるのを許容するために、PPP Link Quality Monitoringメカニズムはユニットのパケット、八重奏、およびLinkの上質のレポートにおけるデータの損失を測定します。 各測定が別々に本国行きの、そして、外国行きの両方のリンクの各半分に行われます。 すべての測定値はリンクの各端が両方のためにそれ自身のリンク品質方針を実行できるようにリンクの両端とコミュニケートして、それが外国行きであるということです。そして、インバウンドリンク。
Finally, the Link Quality Monitoring protocol is designed to be implementable on many different kinds of systems. Although it may be common to implement PPP (and especially Link Quality Monitoring) as a single software process, multi-process implementations with hardware support are also envisioned. The PPP Link Quality Monitoring mechanism provides for this by careful definition of the Link- Quality-Report packet format, and by specifiying reference points for all data transmission and reception measurements.
最終的に、Link Quality Monitoringプロトコルは、多くの異種のシステムの上で実行可能になるように設計されています。ただ一つのソフトウェア処理としてPPP(そして、特にLink Quality Monitoring)を実行するのは一般的であるかもしれませんが、また、ハードウェアサポートによるマルチプロセス実現は思い描かれます。 Link上質のレポートパケット・フォーマットの慎重な定義と、すべてのデータ伝送とレセプション測定値のために基準点をspecifiyingすることによって、PPP Link Quality Monitoringメカニズムはこれに備えます。
3.2. Design Overview
3.2. デザイン概観
Each Link Quality Monitoring implementation maintains counts of the number of packets and octets transmitted and successfully received,
それぞれのLink Quality Monitoring実現は送信されて、首尾よく受けられたパケットと八重奏の数のカウントを維持します。
Perkins & Hobby [Page 15] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[15ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
and periodically transmits this information to its peer in a Link- Quality-Report packet. These packets contain three sections: a Header section, a Counters section, and a Measurements section.
そして、定期的にLink上質のレポートパケットの同輩にこの情報を伝えます。 これらのパケットは3つのセクションを含みます: Header部、Counters部、およびMeasurements部。
The Header section of the packet consists of the normal LCP Link Maintenance packet header including Code, Identifier, Length and Magic-Number fields.
パケットのHeader部はCode、Identifier、Length、およびマジックナンバーフィールドを含む普通のLCP Link Maintenanceパケットのヘッダーから成ります。
The Counters section of the packet consists of four counters, and provides the information necessary to measure the quality of the link. The LQR transmitter fills in two of these counters: Out-Tx- Packets-Ctr and Out-Tx-Octets-Ctr (described later). The LQR receiver fills in the two remaining counters: In-Rx-Packets-Ctr and In-Rx-Octets-Ctr (described later). These counters are similar to sequence numbers; they are constantly increasing to give a "relative" indication of the number of packets and octets communicated across the outbound link. By comparing the values in successive Link- Quality-Reports, an LQR receiver can compute the "absolute" number of packets and octets communicated across its inbound link. Comparing these absolute numbers then gives an indication of an inbound link's quality. Relative numbers, rather than absolute, are transmitted because they greatly simplify link synchronization; an implementation merely waits to receive two LQR packets.
パケットのCounters部は、リンクの品質を測定するために4台のカウンタから成って、必要情報を提供します。 LQR送信機はこれらの2台のカウンタに記入します: 出ているTxパケット-CtrとOut-Tx八重奏Ctr(後で説明されます)。 LQR受信機は2台の残っているカウンタに記入します: RxパケットCtr、そして、In-Rx八重奏Ctr(後で説明されます)。 これらのカウンタは一連番号と同様です。 それらは、アウトバウンドリンクの向こう側に伝えられたパケットと八重奏の数の「相対的な」しるしを与えるために絶えず増加しています。 連続したLink上質のレポートの値を比較することによって、LQR受信機はインバウンドリンクの向こう側に伝えられたパケットと八重奏の「絶対」の数を計算できます。 その時これらの無名数を比較すると、インバウンドリンクの品質のしるしは与えられます。 リンク同期を大いに簡素化するので、相対数は絶対よりむしろ伝えられます。 実現は、2つのLQRパケットを受けるのを単に待っています。
The Measurements section of the packet consists of six state variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In- Rx-Packets, and In-Rx-Octets (described later). This section allows an implementation to report inbound link quality measurements to its peer (for which the report will instead indicate outbound link quality) by transmitting the absolute, rather than relative, number of LQRs, packets, and octets communicated across the inbound link. These values are calculated by observing the Counters section of the Link-Quality-Report packets received on the inbound link. Absolute numbers may be used in this section without synchronization problems because it is necessary to receive only one LQR packet to have valid information.
パケットのMeasurements部は6つの州の変数から成ります: コネ-Tx-LQRs、イドのLast、In-Tx-パケット、In-Tx-八重奏、In- Rx-パケット、およびIn-Rx-八重奏(後で説明されます)。 LQRs、パケット、および八重奏の数は、インバウンドリンクの向こう側に実現がこのセクションで親類よりむしろ絶対を伝えることによって同輩(レポートが代わりにアウトバウンドリンク品質を示す)にインバウンドリンク品質測定を報告できると伝えました。 これらの値は、インバウンドリンクに受け取られたLinkの上質のレポートパケットのCounters部を観測することによって、計算されます。 有効な情報を持つために1つのLQRパケットだけを受けるのが必要であるので、無名数はこのセクションで同期問題なしで使用されるかもしれません。
Link Quality Monitoring is described in more detail in the following sections. First, a description of the processes comprising the Link Quality Monitoring mechanism is presented. This is followed by the packet and byte counters maintained; the measurements, calculations, and state variables used; the format of the Link-Quality-Report packet; some policy suggestions; and, finally, an example link quality calculation.
リンクQuality Monitoringはさらに詳細に以下のセクションで説明されます。 まず最初に、Link Quality Monitoringメカニズムを包括する過程の記述は提示されます。 カウンタが維持したパケットとバイトはこれのあとに続いています。 変数が使用した測定、計算、および状態。 Linkの上質のレポートパケットの形式。 いくつかの方針提案。 そして、最終的に、例は上質の計算をリンクします。
3.3. Processes
3.3. 過程
The PPP Link Quality Monitoring mechanism is described using a
PPP Link Quality Monitoringメカニズムは、aを使用することで説明されます。
Perkins & Hobby [Page 16] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[16ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
"logical process" model. As shown below, there are five logical processes duplicated at each end of the duplex link.
「論理的な過程」モデル。 以下に示すように、複式のリンクの各端のときにコピーされた5つの論理的な過程があります。
+---------+ +-------+ +----+ Outbound | |-->| Mux |-->| Tx |=========> | Link- | +-------+ +----+ | Manager | | | +-------+ +----+ Inbound | |<--| Demux |<--| Rx |<========= +---------+ +-------+ +----+
+---------+ +-------+ +----+外国行きです。| | -->、| Mux| -->、| Tx|=========>| リンクしてください。| +-------+ +----+ | マネージャ| | | +-------+ +----+本国行きです。| | <--、| Demux| <--、| Rx|<===== +---------+ +-------+ +----+
Link-Manager
リンクマネージャ
The Link-Manager process transmits and receives Link-Quality-
Reports, and implements the desired link quality policy. LQR
packets are transmitted at a constant rate, which is negotiated by
the LCP Link-Quality-Monitoring Configuration Option. The Link-
Manager process fills in only the Header and Measurements sections
of the packet; the Counters section of the packet is filled in by
the Tx and Rx processes.
Link-マネージャの過程は、Link上質のレポートを送信して、受け取って、必要なリンク品質方針を実行します。 LQRパケットは一定のレートで伝えられます。(それは、LCP Linkの上質のモニターConfiguration Optionによって交渉されます)。 Linkマネージャの過程はパケットのHeaderとMeasurements部だけに記入します。 TxとRx工程でパケットのCounters部は記入されます。
Mux
Mux
The Mux process multiplexes packets from the various protocols
(e.g., LCP, IP, XNS, etc.) into a single, sequential, and
prioritized stream of packets. Link-Quality-Report packets MUST
be given the highest possible priority to insure that link quality
information is communicated in a timely manner.
Muxの過程はパケットを様々なプロトコル(例えば、LCP、IP、XNSなど)からパケットの単一の、そして、連続して、最優先している流れの中に多重送信します。 リンク品質情報が伝えられるのを保障するためにリンクの上質のレポートパケットはタイムリーな方法で優先しなければなりません可能な限り高い。
Tx
Tx
The Tx process maintains the counters Out-Tx-Packets-Ctr and Out-
Tx-Octets-Ctr which are used to measure the amount of data which
is transmitted on the outbound link. When Tx processes a Link-
Quality-Report packet, it inserts the values of these counters
into the Counters section of the packet. Because these counters
represent relative, rather than absolute, values, the question of
when to update the counters, before or after they are inserted
into a Link-Quality-Report packet, is left as an implementation
decision. However, an implementation MUST make this decision the
same way every time. The Tx process MUST follow the Mux process
so that packets are counted in the order transmitted to the link.
過程がアウトバウンドリンクで伝えられるデータ量を測定するのに使用されるカウンタのOut-TxパケットCtrとOut- Tx八重奏Ctrであることを支持するTx。 TxがLink上質のレポートパケットを処理するとき、それはこれらのカウンタの値をパケットのCounters部に挿入します。 これらのカウンタが絶対よりむしろ親類の代理をするので、値、以前かそれらがLinkの上質のレポートパケットに挿入された後にいつカウンタをアップデートするかに関する質問は実現決定として残されます。 しかしながら、実現は毎回、同じようにこの決定をしなければなりません。 Txの過程がMuxの過程に従わなければならないので、パケットはリンクに伝えられたオーダーで数えられます。
Rx
Rx
The Rx process maintains the counters In-Rx-Packets-Ctr and In-
Rx-Octets-Ctr which are used to measure the amount of data which
is received by the inbound link. When Rx processes a Link-
過程がインバウンドリンクによって受け取られるデータ量を測定するのに使用されるカウンタのIn-RxパケットCtrとIn- Rx八重奏Ctrであることを支持するRx。 RxがLinkを処理するとき
Perkins & Hobby [Page 17] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[17ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Quality-Report packet, it inserts the values of these counters
into the Counters section of the packet. Again, the question of
when to update the counters, before or after they are inserted
into a Link-Quality-Report packet, is left as an implementation
decision which MUST be made consistently the same way.
パケットを品質で報告してください、そして、それはこれらのカウンタの値をパケットのCounters部に挿入します。 一方、以前かそれらがLinkの上質のレポートパケットに挿入された後にいつカウンタをアップデートするかに関する質問は一貫して同じようにしなければならない実現決定として残されます。
Demux
Demux
The Demux process demultiplexes packets for the various protocols.
The Demux process MUST follow the Rx process so that packets are
counted in the order received from the link.
Demuxは様々なプロトコルのために「反-マルチプレックス」パケットを処理します。 Demuxの過程がRxの過程に従わなければならないので、パケットはリンクから受注で数えられます。
3.4. Counters
3.4. カウンタ
In order to fill in the Counters section of a Link-Quality-Report packet, Link Quality Monitoring requires the implementation of one 8-bit unsigned, and four 32-bit unsigned, monotonically increasing counters. These counters may be reset to any initial value before the first Link-Quality-Report is transmitted, but MUST NOT be reset again until LCP has left the Open state. Counters wrap to zero when their maximum value is reached (for 32 bit counters: 0xffffffff + 1 = 0).
Linkの上質のレポートパケットのCounters部に記入するために、Link Quality Monitoringは無記名で1 8ビットの32無記名と4ビットの実現を必要とします、カウンタを単調に増加させて。 これらのカウンタは、最初のLink上質のレポートが伝えられる前にどんな初期の値にもリセットされるかもしれませんが、LCPがオープン状態を出るまで、再びリセットしてはいけません。 それらの最大値に達しているとき(32ビットのカウンタ: 0xffffffff+1 = 0であるのに)、包装をゼロまで打ち返します。
Out-Identifier-Ctr
出ている識別子Ctr
Out-Identifier-Ctr is an 8-bit counter maintained by the Link-
Manager process which increases by one for each transmitted Link-
Quality-Report packet.
出ている識別子Ctrはそれぞれの伝えられたLink上質のレポートパケットあたり1つ増加するLinkマネージャの過程によって維持された8ビットのカウンタです。
Out-Tx-Packets-Ctr
出ているTxパケットCtr
Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx
process which increases by one for each transmitted Data Link
Layer packet.
出ているTxパケットCtrはそれぞれの伝えられたData Link Layerパケットあたり1つ増加するTxの過程によって維持された32ビットのカウンタです。
Out-Tx-Octets-Ctr
出ているTx八重奏Ctr
Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process
which increases by one for each octet in a transmitted Data Link
Layer packet. All octets which are included in the FCS
calculation MUST be counted, as should the FCS octets themselves.
All other octets MUST NOT be counted.
出ているTx八重奏Ctrは伝えられたData Link Layerパケットの各八重奏あたり1つ増加するTxの過程によって維持された32ビットのカウンタです。 FCS八重奏自体であるべきであることのようにFCS計算に含まれているすべての八重奏を数えなければなりません。 他のすべての八重奏を数えなければならないというわけではありません。
In-Rx-Packets-Ctr
RxパケットCtrです。
In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process
which increases by one for each successfully received Data Link
Layer packet. Packets with incorrect FCS fields or other problems
RxパケットCtrであることは、それぞれの首尾よく受け取られたData Link Layerパケットあたり1つ増加するRxの過程によって維持された32ビットのカウンタです。 不正確なFCS分野か他の問題があるパケット
Perkins & Hobby [Page 18] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[18ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
MUST not be counted.
数えられてはいけません。
In-Rx-Octets-Ctr
Rx八重奏Ctrです。
In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process
which increases by one for each octet in a successfully received
Data Link Layer packet. All octets which are included in an FCS
calculation MUST be counted, as should the FCS octets themselves.
All other octets MUST NOT be counted.
Rx八重奏Ctrであることは、首尾よく受け取られたData Link Layerパケットの各八重奏あたり1つ増加するRxの過程によって維持された32ビットのカウンタです。 FCS八重奏自体であるべきであることのようにFCS計算に含まれているすべての八重奏を数えなければなりません。 他のすべての八重奏を数えなければならないというわけではありません。
3.5. Measurements, Calculations, State Variables
3.5. 測定値(計算)は変数を述べます。
In order to fill in the Measurements section of a Link-Quality-Report packet, Link Quality Monitoring requires the Link-Manager process to make a number of calculations and keep a number of state variables. These calculations are made, and these state variables updated, each time a Link-Quality-Report packet is received from the inbound link.
Linkの上質のレポートパケットのMeasurements部に記入して、Link Quality Monitoringは、多くの計算をして、多くの状態が変数であることを保つためにLink-マネージャの過程を必要とします。 これらの計算をします、そして、これらはインバウンドリンクからLinkの上質のレポートパケットを受け取るたびにアップデートされた変数を述べます。
In-Tx-LQRs
Tx-LQRs
In-Tx-LQRs is an 8-bit state variable which indicates the number
of Link-Quality-Report packets which the peer had to transmit in
order for the local end to receive exactly one LQR. In-Tx-LQRs
defines the length of the "period" over which In-Tx-Packets, In-
Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured. In-Tx-
LQRs is calculated by subtracting Last-In-Id from the received
Identifier. If more than 255 LQRs in a row are lost, In-Tx-LQRs
will be ambiguous since the Identifier field and all state
variables based on it are only 8 bits. It is assumed that the
Link Quality Monitoring policy will be robust enough to handle
this case (it should probably close down the link long before this
happens).
Tx-LQRsであることは、地方の終わりがちょうど1LQRを受け取るように同輩が伝えなければならなかったLinkの上質のレポートパケットの数を示す8ビットの州の変数です。 Tx-LQRsでは、In-Tx-パケット、In- Tx-八重奏、In-Rx-パケット、およびIn-Rx-八重奏が測定された「期間」の長さを定義します。 Tx- LQRsでは、容認されたIdentifierからイドのLastを引き算することによって、計算されます。 並んでいる255LQRsが無くなると、In-Tx-LQRsは、Identifier分野とそれに基づくすべての州の変数が8ビットにすぎないのであいまいになるでしょう。 Link Quality Monitoring方針が本件を扱うほど強健になる(これが起こるずっと前にそれはたぶんリンクを閉鎖するべきである)と思われます。
Last-In-Id
イドの最終
Last-In-Id is an 8-bit state variable which stores the value of
the last received Identifier. Last-In-Id should be updated after
In-Tx-LQRs has been calculated.
イドの最終は最後の容認されたIdentifierの値を格納する8ビットの州の変数です。 In-Tx-LQRsについて計算した後にイドの最終をアップデートするべきです。
In-Tx-Packets
Txパケットです。
In-Tx-Packets is a 32-bit state variable which indicates the
number of packets which were transmitted on the inbound link
during the last period. In-Tx-Packets is calculated by
subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx-
Packets-Ctr.
Txパケットであることは、最後の期間、インバウンドリンクで伝えられたパケットの数を示す32ビットの州の変数です。 Txパケットでは、容認されたOut-Txパケット-Ctrからの引いている計算されたLast出ているTxパケットCtrがあります。
Perkins & Hobby [Page 19] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[19ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Last-Out-Tx-Packets-Ctr
TxはパケットCtrを持ってください。
Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores
the value of the last received Out-Tx-Packets-Ctr. Last-Out-Tx-
Packets-Ctr should be updated after In-Tx-Packets has been
calculated.
最後の出ているTxパケットCtrは最後の容認されたOut-TxパケットCtrの値を格納する32ビットの州の変数です。 In-Tx-パケットについて計算した後に外で持続する-Txパケット-Ctrをアップデートするべきです。
In-Tx-Octets
Tx八重奏です。
In-Tx-Octets is a 32-bit state variable which indicates the number
of octets which were transmitted on the inbound link during the
last period. In-Tx-Octets is calculated by subtracting Last-Out-
Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr.
Tx八重奏であることは、最後の期間、インバウンドリンクで伝えられた八重奏の数を示す32ビットの州の変数です。 Tx八重奏、外のLastを引き算することによって、Tx八重奏Ctrは容認されたOut-Tx八重奏Ctrから計算されます。
Last-Out-Tx-Octets-Ctr
Txは八重奏Ctrを持ってください。
Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the
value of the last received Out-Tx-Octets-Ctr. Last-Out-Tx-
Octets-Ctr should be updated after In-Tx-Octets has been
calculated.
最後の出ているTx八重奏Ctrは最後の容認されたOut-Tx八重奏Ctrの値を格納する32ビットの州の変数です。 In-Tx-八重奏について計算した後に外で持続する-Tx八重奏-Ctrをアップデートするべきです。
In-Rx-Packets
Rxパケットです。
In-Rx-Packets is a 32-bit state variable which indicates the
number of packets which were received on the inbound link during
the last period. In-Rx-Packets is calculated by subtracting
Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr.
Rxパケットであることは、最後の期間、インバウンドリンクに受け取られたパケットの数を示す32ビットの州の変数です。 Rxパケットでは、容認されたIn-RxパケットCtrからRxパケットCtrのLastを引き算することによって、計算されます。
Last-In-Rx-Packets-Ctr
RxパケットCtrの最終
Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the
value of the last received In-Rx-Packets-Ctr. Last-In-Rx-
Packets-Ctr should be updated after In-Rx-Packets has been
calculated.
RxパケットCtrの最終は最後の容認されたIn-RxパケットCtrの値を格納する32ビットの州の変数です。 In-Rx-パケットについて計算した後に中で持続する-Rxパケット-Ctrをアップデートするべきです。
In-Rx-Octets
Rx八重奏です。
In-Rx-Octets is a 32-bit state variable which indicates the number
of octets which were received on the inbound link during the last
period. In-Rx-Octets is calculated by subtracting Last-In-Rx-
Octets-Ctr from the received In-Rx-Octets-Ctr.
Rx八重奏であることは、最後の期間、インバウンドリンクで受けられた八重奏の数を示す32ビットの州の変数です。 Rx八重奏では、容認されたIn-Rx八重奏Ctrから中のLast Rx八重奏-Ctrを引き算することによって、計算されます。
Last-In-Rx-Octets-Ctr
Rx八重奏Ctrの最終
Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the
value of the last received In-Rx-Octets-Ctr. Last-In-Rx-Octets-
Ctr should be updated after In-Rx-Octets has been calculated.
Rx八重奏Ctrの最終は最後の容認されたIn-Rx八重奏Ctrの値を格納する32ビットの州の変数です。 In-Rx-八重奏について計算した後に中で持続する-Rx八重奏-Ctrをアップデートするべきです。
Perkins & Hobby [Page 20] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[20ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Measurements-Valid
測定値有効です。
Measurements-Valid is a 1-bit boolean state variable which
indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx-
Packets, and In-Rx-Octets state variables contain valid
measurements. These measurements cannot be considered valid until
two or more Link-Quality-Report packets have been received on the
inbound link. This bit should be reset when LCP reaches the Open
state and should be set after the receipt of exactly two LQRs.
測定値有効であるのは、In-Tx-パケット、In-Tx-八重奏、In-Rxパケット、およびIn-Rx-八重奏州の変数が有効な測定値を含むかどうかを示す1ビットの論理演算子州の変数です。 有効であるとこれらの測定値をインバウンドリンクに2つ以上のLinkの上質のレポートパケットを受け取るまで考えることができません。 このビットは、LCPがオープン状態に達するとき、リセットされるべきであり、ちょうど2LQRsの領収書の後に設定されるべきです。
3.6. Link-Quality-Report Packet Format
3.6. リンクの上質のレポートパケット・フォーマット
A Summary of the Link-Quality-Report packet format is shown below. The fields are transmitted from left to right. The Code, Identifier, Length, and Magic-Number fields make up the normal LCP Link Maintenance packet header; the In-Tx-LQRS, Last-In-Id, V, In-Tx- Packets, In-Tx-Octets, In-Rx-Packets, In-Rx-Octets fields contain digested absolute measurements; and the Out-Tx-Packets-Ctr, Out-Tx- Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr fields contain raw relative counts. Note that as transmitted over the link, this packet format does not include the In-Rx-Packets-Ctr and In-Rx- Octets-Ctr fields which are logically appended to the packet by the Rx process after reception on the inbound link.
Linkの上質のレポートパケット・フォーマットのSummaryは以下で見せられます。 野原は左から右まで伝えられます。 Code、Identifier、Length、およびマジックナンバーフィールドは普通のLCP Link Maintenanceパケットのヘッダーを作ります。 In-Tx-LQRS(イドのLast、V、In-Txパケット、In-Tx-八重奏、In-Rx-八重奏分野が含むIn-Rx-パケット)は絶対測定値を読みこなしました。 そして、Out-TxパケットCtr、Out-Tx八重奏-Ctr、In-RxパケットCtr、およびIn-Rx八重奏Ctr分野は生の相対的なカウントを含んでいます。 このパケット・フォーマットがリンクの上に伝えられるようにレセプションの後にインバウンドリンクでパケットにRx工程で論理的に追加されるIn-RxパケットCtrとIn-Rx八重奏-Ctr野原を含んでいないことに注意してください。
Perkins & Hobby [Page 21] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[21ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Tx-LQRs | Last-In-Id | Reserved |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Tx-Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Tx-Octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-Tx-Packets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-Tx-Octets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Packets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| In-Rx-Octets-Ctr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx-LQRs| イドの最終| 予約されます。|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Txパケットです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx八重奏です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rxパケットです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx八重奏です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出ているTxパケットCtr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 出ているTx八重奏Ctr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RxパケットCtrです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx八重奏Ctrです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
12 for Link-Quality-Report.
12 リンクの上質のレポートのために。
Identifier
識別子
The Identifier field is one octet and indicates the sequence
number for this Link-Quality-Report. The Identifier field is
copied from the Out-Identifier-Ctr counter on transmission. On
reception, the Identifier field is used to calculate In-Tx-LQRs
and is then stored in Last-In-Id.
Identifier分野は、1つの八重奏であり、このLinkの上質のレポートのために一連番号を示します。 Identifier分野はトランスミッションのときにOut識別子Ctrカウンタからコピーされます。 レセプションでは、Identifier分野は、In-Tx-LQRsについて計算するのに使用されて、アイダホ州のLastに格納されて、その時です。
The Link-Quality-Report Identifier sequence number space MUST be
separate from that of all other LCP packets; for example,
transmission of an LCP Echo-Request must not cause the Out-
Identifier-Ctr counter to be incremented.
Linkの上質のレポートIdentifier一連番号スペースは他のすべてのLCPパケットのものから別々であるに違いありません。 例えば、LCP Echo-要求の伝達で、Out識別子-Ctrカウンタを増加してはいけません。
Perkins & Hobby [Page 22] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[22ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Length
長さ
The Length field is two octets and indicates the length of the LQM
packet including the Code, Identifier, Length and all defined
fields. Octets outside the range of the length field should be
treated as Data Link Layer padding and should be ignored on
reception. In order for the correct In-Tx-Octets and In-Rx-Octets
values to be calculated, Link-Quality-Reports MUST be consistently
transmitted with the same amount of padding.
Length分野は、2つの八重奏であり、Code、Identifier、Length、およびすべてを含むLQMパケットの長さが分野を定義したのを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、長さの分野の範囲の外での八重奏は扱われるべきです。 正しいIn-Tx-八重奏とIn-Rx-八重奏値が計算されるために、同じ量の詰め物でLinkの上質のレポートを一貫して伝えなければなりません。
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting
looped-back links. Unless modified by a Configuration Option, the
Magic-Number MUST always be transmitted as zero and MUST always be
ignored on reception. If Magic-Numbers have been negotiated,
incoming LQM packets should be checked to make sure that the local
end is not seeing its own Magic-Number and thus a looped-back
link.
マジックナンバーフィールドは、輪にされて逆リンクを検出することにおいて4つの八重奏と援助です。 Configuration Optionによって変更されない場合、マジック数をゼロとしていつも伝えなければならなくて、レセプションでいつも無視しなければなりません。 マジック数が交渉されたなら、入って来るLQMパケットは、地方の終わりがそれ自身のマジック番号とその結果輪にされて逆リンクが見えていないのを確実にするためにチェックされるべきです。
In-Tx-LQRs
Tx-LQRs
The In-Tx-LQRs field is one octet and indicates the number of
periods covered by the Measurements section of this Link-Quality-
Report. The In-Tx-LQRs field is copied from the In-Tx-LQRs state
variable on transmission.
In-Tx-LQRs分野は、1つの八重奏であり、このLink上質のレポートのMeasurements部でカバーされた期間の数を示します。 In-Tx-LQRs分野はトランスミッションのIn-Tx-LQRs州の変数からコピーされます。
Last-In-Id
イドの最終
The Prev-In-Id field is one octet and indicates the age of the
Measurements section of this Link-Quality-Report. The Last-In-Id
field is copied from the Last-In-Id field on transmission. On
reception, the Last-In-Id field may be compared with the Out-
Identifier-Ctr to determine how many, if any, outbound Link-
Quality-Reports have been lost.
イドのPrev分野は、1つの八重奏であり、このLinkの上質のレポートのMeasurements部の時代を示します。 イドのLast分野はトランスミッションのイドのLast分野からコピーされます。 レセプションでは、イドのLast分野は、いくつのもしあれば外国行きのLink上質のレポートが失われたかを決定するためにOut識別子-Ctrと比較されるかもしれません。
V
V
The V field is 1 bit and indicates whether or not the Measurements
section of this Link-Quality-Report is valid. The V field is
copied from the Measurements-Valid state variable on transmission.
If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id,
In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields
should be ignored.
V分野は、1ビットであり、このLinkの上質のレポートのMeasurements部が有効であるかどうかを示します。 V分野はトランスミッションのMeasurements有効な州の変数からコピーされます。 V分野が1に設定されないなら、In-Tx-LQRs、イドのLast、In-Tx-パケット、In-Tx-八重奏、In-Rx-パケット、およびIn-Rx-八重奏分野は無視されるべきです。
Reserved
予約されます。
The Reserved field is 15 bits and is intended to pad the remaining
Reserved分野は、15ビットであり、残りを水増しすることを意図します。
Perkins & Hobby [Page 23] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[23ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
packet fields to even four-octet boundaries for the convenience of
hardware implementations. The Reserved field should always be
transmitted as zero and ignored on reception.
ハードウェア実装の都合のための4八重奏の境界さえへのパケット分野。 Reserved野原は、いつもゼロとして伝えられて、レセプションで無視されるべきです。
In-Tx-Packets
Txパケットです。
The In-Tx-Packets field is four octets and indicates the number of
packets transmitted on the inbound link of the Link-Quality-Report
transmitter during the last measured period. The In-Tx-Packets
field is copied from the In-Tx-Packets state variable on
transmission.
In-Tx-パケット分野は、4つの八重奏であり、パケットの数が最後に測定された期間Linkの上質のレポート送信機のインバウンドリンクを伝わったのを示します。 In-Tx-パケット分野はトランスミッションのIn-Tx-パケット州の変数からコピーされます。
In-Tx-Octets
Tx八重奏です。
The In-Tx-Octets field is four octets and indicates the number of
octets transmitted on the inbound link of the Link-Quality-Report
transmitter during the last measured period. The In-Tx-Octets
field is copied from the In-Tx-Octets state variable on
transmission.
In-Tx-八重奏分野は、4つの八重奏であり、八重奏の数が最後に測定された期間Linkの上質のレポート送信機のインバウンドリンクを伝わったのを示します。 In-Tx-八重奏分野はトランスミッションのIn-Tx-八重奏州の変数からコピーされます。
In-Rx-Packets
Rxパケットです。
The In-Rx-Packets field is four octets and indicates the number of
packets received on the inbound link of the Link-Quality-Report
transmitter during the last measured period. The In-Rx-Packets
field is copied from the In-Rx-Packets state variable on
transmission.
In-Rx-パケット分野は、4つの八重奏であり、最後に測定された期間、Linkの上質のレポート送信機のインバウンドリンクに受け取られたパケットの数を示します。 In-Rx-パケット分野はトランスミッションのIn-Rx-パケット州の変数からコピーされます。
In-Rx-Octets
Rx八重奏です。
The In-Rx-Octets field is four octets and indicates the number of
octets received on the inbound link of the Link-Quality-Report
transmitter during the last measured period. The In-Rx-Octets
field is copied from the In-Rx-Octets state variable on
transmission.
In-Rx-八重奏分野は、4つの八重奏であり、最後に測定された期間、Linkの上質のレポート送信機のインバウンドリンクで受けられた八重奏の数を示します。 In-Rx-八重奏分野はトランスミッションのIn-Rx-八重奏州の変数からコピーされます。
Out-Tx-Packets
出ているTxパケット
The Out-Tx-Packets field is four octets and is used to calculate
the number of packets transmitted on the outbound link of the
Link-Quality-Report transmitter during a period. The Out-Tx-
Packets field is copied from the Out-Tx-Packets-Ctr counter on
transmission.
Out-Tx-パケット分野は、4つの八重奏であり、期間、Linkの上質のレポート送信機のアウトバウンドリンクで伝えられたパケットの数について計算するのに使用されます。 Out-Txパケット分野はトランスミッションのときにOut-TxパケットCtrカウンタからコピーされます。
Out-Tx-Octets
出ているTx八重奏
The Out-Tx-Octets field is four octets and is used to calculate
the number of octets transmitted on the outbound link of the
Out-Tx-八重奏分野は、4つの八重奏であり、八重奏の数がアウトバウンドリンクを伝わったと見込むのにおいて使用されています。
Perkins & Hobby [Page 24] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[24ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Link-Quality-Report transmitter during a period. The Out-Tx-
Octets field is copied from the Out-Tx-Octets-Ctr counter on
transmission.
期間のリンクの上質のレポート送信機。 Out-Tx八重奏分野はトランスミッションのときにOut-Tx八重奏Ctrカウンタからコピーされます。
In-Rx-Packets
Rxパケットです。
The In-Rx-Packets field is four octets and is used to calculate
the number of packets received on the inbound link of the Link-
Quality-Report receiver during a period. The In-Rx-Packets field
is copied from the In-Rx-Packets-Ctr counter on reception. The
In-Rx-Packets is not shown because it is not actually transmitted
over the link. Rather, it is logically appended (in an
implementation dependent manner) to the packet by the
implementation's Rx process.
In-Rx-パケット分野は、4つの八重奏であり、期間、Link上質のレポート受信機のインバウンドリンクに受け取られたパケットの数について計算するのに使用されます。 In-Rx-パケット分野はレセプションのIn-RxパケットCtrカウンタからコピーされます。 それが実際にリンクの上に伝えられないので、In-Rx-パケットは見せられません。 むしろ、それをパケットに実現のRx工程で論理的に追加します(実現に依存する方法で)。
In-Rx-Octets
Rx八重奏です。
The In-Rx-Octets field is four octets and is used to calculate the
number of octets received on the inbound link of the Link-
Quality-Report receiver during a period. The In-Rx-Octets field
is copied from the In-Rx-Octets-Ctr counter on reception. The
In-Rx-Octets is not shown because it is not actually transmitted
over the link. Rather, it is logically appended (in an
implementation dependent manner) to the packet by the
implementation's Rx process.
In-Rx-八重奏分野は、4つの八重奏であり、期間、Link上質のレポート受信機のインバウンドリンクで受けられた八重奏の数について計算するのに使用されます。 In-Rx-八重奏分野はレセプションのIn-Rx八重奏Ctrカウンタからコピーされます。 それが実際にリンクの上に伝えられないので、In-Rx-八重奏は示されません。 むしろ、それをパケットに実現のRx工程で論理的に追加します(実現に依存する方法で)。
3.7. Policy Suggestions
3.7. 方針提案
Link-Quality-Report packets provide a mechanism to determine the link quality, but it is up to each implementation to decide when the link is usable. It is recommended that this policy implement some amount of hysteresis so that the link does not bounce up and down. A particularly good policy is to use a K out of N algorithm. In such an algorithm, there must be K successes out of the last N periods for the link to be considered of good quality.
リンクの上質のレポートパケットはリンク品質を決定するためにメカニズムを提供しますが、リンクがいつ使用可能であるかを決めるのが各実現まで達しています。 この方針がいくらかの量のヒステリシスを実行するのが、お勧めであるので、リンクは上下に弾みません。 特に良い方針はNアルゴリズムからKを使用することです。 そのようなアルゴリズムでは、K成功はリンクが良質であるのについて考えられるここN期間から脱しているに違いありません。
Procedures for recovery from poor quality links are unspecified and may vary from implementation to implementation. A suggested approach is to immediately close all other Network-Layer protocols (i.e., cause IPCP to transmit a Terminate-Req), but to continue transmitting Link-Quality-Reports. Once the link quality again reaches an acceptable level, Network-Layer protocols can be reconfigured.
貧しい上質のリンクからの回復のための手順は、不特定であり、実現によって異なるかもしれません。 提案されたアプローチがすぐに他のすべてのNetwork-層のプロトコル(Terminate-Reqを伝えるすなわち、原因IPCP)を閉じることですが、伝わり続けるために、Link品質は報告します。 リンク品質が再びいったん合格水準に達すると、Network-層のプロトコルを再構成できます。
3.8. Example
3.8. 例
An example may be helpful. Assume that Link-Manager implementation A transmits a Link-Quality-Report which is received by Link-Manager implementation B at time t0 with the following values:
例は有用であるかもしれません。 Link-マネージャ実現Aが時間t0のときに以下の値でLink-マネージャ実現Bで受け取られるLinkの上質のレポートを伝えると仮定してください:
Perkins & Hobby [Page 25] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[25ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Out-Tx-Packets 5
Out-Tx-Octets 100
In-Rx-Packets 3
In-Rx-Octets 70
出ているTxパケット5出ているTx八重奏100、Rxパケットの3、Rx八重奏の70
Assume that A then transmits 20 IP packets with 200 octets, of which 15 packets and 150 octets are received by B. At time t1, A transmits another LQR which is received by B as follows:
次に、Aが15のパケットと150の八重奏がB.At時間t1によって受けられる200の八重奏で20のIPパケットを伝えて、Aが以下のBによって受け取られる別のLQRを伝えると仮定してください:
Out-Tx-Packets 26 (5 old, plus 20 IP, plus 1 LQR)
Out-Tx-Octets 342 (42 for LQR)
In-Rx-Packets 19
In-Rx-Octets 262
出ているTxパケット26(5古いLQR、プラス20IP、および1LQR)出ているTx八重奏342(LQRのための42)のRxパケットの19In-Rx-八重奏262
Implementation B can now calculate the number of packets and octets transmitted, received and lost on its inbound link as follows:
実現Bは、今、パケットと八重奏の数が以下のインバウンドリンクを送信して、受けて、失ったと見込むことができます:
In-Tx-Packets = 26 - 5 = 21
In-Tx-Octets = 342 - 100 = 242
In-Rx-Packets = 10 - 3 = 16
In-Rx-Octets = 262 - 70 = 192
In-Lost-Packets = 21 - 16 = 5
In-Lost-Octets = 242 - 192 = 50
Txパケットでは、26--5 = 21 Tx八重奏の=342--100 = 242 Rxパケットの=10--3 = 16 Rx八重奏の=262--70 = 192 無くなっているパケットの=21--16 = 5 無くなっている八重奏の=242--192 = 50と等しいです。
After doing these calculations, B evaluates the measurements in what ever way its implemented policy specifies. Also, the next time that B transmits an LQR to A, it will report these values in the Measurements section, thereby allowing A to evaluate these same measurements.
これらの計算をするBが測定を評価した後に、ずっと、それがいったい何で政策を実施したかは指定します。 またと、BがLQRをAに伝える次回、Measurements部でこれらの値を報告するでしょう、その結果、Aがこれらの同じ測定を評価するのを許容します。
Perkins & Hobby [Page 26] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[26ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
4. Password Authentication Protocol
4. パスワード認証プロトコル
The Password Authentication Protocol (PAP) may be used to authenticate a peer by verifying the identity of the remote end of the link. Use of the PAP must first be negotiated using the LCP Authentication-Type Configuration Option. Successful negotiation adds an additional Authentication phase to the Link Control Protocol, after the Link Quality Determination phase, and before the Network Layer Protocol Configuration Negotiation phase. PAP packets received before the Authentication phase is reached should be silently discarded. The Authentication phase is exited once an Authenticate- Ack packet is sent or received.
パスワード認証プロトコル(PAP)は、リンクのリモートエンドのアイデンティティについて確かめることによって同輩を認証するのに使用されるかもしれません。 最初に、LCP Authentication-タイプConfiguration Optionを使用することでPAPの使用を交渉しなければなりません。 うまくいっている交渉はLink Quality Determinationフェーズの後、およびLink Controlプロトコルと、Network LayerプロトコルConfiguration Negotiationフェーズの前に追加Authenticationフェーズを加えます。 Authenticationフェーズに達する前に受け取られたPAPパケットは静かに捨てられるべきです。 いったんAuthenticate- Ackパケットを送るか、または受け取ると、Authenticationフェーズを出ます。
PAP is intended for use primarily by hosts and routers that connect via switched circuits or dial-up lines to a PPP network server. The server can then use the identification of the connecting host or router in the selection of options for network layer negotiations or failing authentication, drop the connection.
PAPは使用のために主として交換回線網かダイヤルアップ線を通してPPPネットワークサーバに接続するホストとルータで意図します。次に、サーバはネットワーク層交渉か失敗認証にオプションの品揃えにおける、接続ホストかルータの識別を使用できて、低下は接続です。
Note that PAP is not a strong authentication method. Passwords are passed over the circuit in the clear and there is no protection from repeated trial and error attacks. Work is currently underway on more secure authentication methods for PPP and other protocols. It is strongly recommended to switch to these methods when they become available.
PAPが強い認証方法でないことに注意してください。 パスワードは明確の回路の上に向かいます、そして、繰り返された試行錯誤攻撃からのノー・プロテクションがあります。 PPPと他のプロトコルにおいて、仕事は現在、より安全な認証方法で進行中です。 利用可能になるとき、それがこれらのメソッドに切り替わることが強く勧められます。
4.1. Packet Format
4.1. パケット・フォーマット
Exactly one Password Authentication Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the protocol field indicates type hex c023 (Password Authentication Protocol). A summary of the Password Authentication Protocol packet format is shown below. The fields are transmitted from left to right.
ちょうど1つのパスワード認証プロトコルパケットがプロトコル分野がタイプ十六進法c023(パスワード認証プロトコル)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。 パスワード認証プロトコルパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 type of PAP packet.
PAP Codes are assigned as follows:
Code分野は、1つの八重奏であり、PAPパケットのタイプを特定します。 PAP Codesは以下の通り割り当てられます:
Perkins & Hobby [Page 27] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[27ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
1 Authenticate
2 Authenticate-Ack
3 Authenticate-Nak
1がAckを認証する状態で2を認証する、3、Nakを認証します。
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 PAP
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分野を含むPAPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。
Data
データ
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Data分野はゼロであるか以上が八重奏です。 Data分野の形式はCode分野のそばで決定しています。
Perkins & Hobby [Page 28] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[28ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
4.2. Authenticate
4.2. 認証します。
Description
記述
The Authenticate packet is used to begin the Password
Authentication Protocol. An implementation having sent a LCP
Configure-Ack packet with an Authentication-Type Configuration
Option further specifying the Password Authentication Protocol
must send an Authenticate packet during the Authentication phase.
An implementation receiving a Configure-Ack with said
Configuration Option should expect the remote end to send an
Authenticate packet during this phase.
Authenticateパケットは、パスワード認証プロトコルを始めるのに使用されます。 Authentication-タイプConfiguration Optionがさらにパスワード認証プロトコルを指定している状態で有がLCP Configure-Ackパケットを送った実装はAuthentication段階の間、Authenticateパケットを送らなければなりません。 前述のConfiguration Optionと共にConfigure-Ackを受ける実装は、リモートエンドがこの段階の間、Authenticateパケットを送ると予想するべきです。
An Authenticate packet is sent with the Code field set to 1
(Authenticate) and the Peer-ID and Password fields filled as
desired.
1(認証する)に設定されたCode分野、Peer-ID、およびPassword分野がいっぱいにされている状態で、望まれているようにAuthenticateパケットを送ります。
Upon reception of an Authenticate, some type of Authenticate reply
MUST be transmitted.
Authenticateのレセプションでは、タイプのAuthenticate回答を伝えなければなりません。
A summary of the Authenticate packet format is shown below. The fields are transmitted from left to right.
Authenticateパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩IDの長さ| 同輩イド… +-+-+-+-+-+-+-+-+-+-+-+-+ | Passwd-長さ| パスワード… +-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
1 for Authenticate.
1、認証します。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field should be changed each time a
Authenticate is transmitted which is different from the preceding
request.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 前の要求と異なったAuthenticateが伝えられるたびにIdentifier分野を変えるべきです。
Peer-ID-Length
同輩IDの長さ
The Peer-ID-Length field is one octet and indicates the length of
the Peer-ID field
Peer IDの長さの分野は、1つの八重奏であり、Peer-ID分野の長さを示します。
Perkins & Hobby [Page 29] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[29ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Peer-ID
同輩ID
The Peer-ID field is zero or more octets and indicates the name of
the peer to be authenticated.
Peer-ID分野は、ゼロか、より多くの八重奏であり、認証されるために同輩の名前を示します。
Passwd-Length
Passwd-長さ
The Passwd-Length field is one octet and indicates the length of
the Password field
Passwd-長さの分野は、1つの八重奏であり、Password分野の長さを示します。
Password
パスワード
The Password field is zero or more octets and indicates the
password to be used for authentication.
Password分野は、ゼロか、より多くの八重奏であり、認証に使用されるためにパスワードを示します。
Perkins & Hobby [Page 30] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[30ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
4.3. Authenticate-Ack
4.3. Ackを認証します。
Description
記述
If the Peer-ID/Password pair received in an Authenticate is both
recognizable and acceptable, then a PAP implementation should
transmit a PAP packet with the Code field set to 2 (Authenticate-
Ack), the Identifier field copied from the received Authenticate,
and the Message field optionally filled with an ASCII message.
Authenticateに受け取られたPeer-ID/パスワード組が認識可能であって、かつ許容できるなら、PAP実装はCode分野セットでPAPパケットを2に伝えるべきです、そして、(Ackを認証してください)Identifier分野は容認されたAuthenticateからコピーされました、そして、Message分野はASCIIメッセージで任意に満ちました。
A summary of the Authenticate-Ack packet format is shown below. The fields are transmitted from left to right.
Authenticate-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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 Authenticate-Ack.
2、Ackを認証します。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate which caused this
Authenticate-Ack.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 このAuthenticate-Ackを引き起こしたAuthenticateのIdentifier分野からIdentifier分野をコピーしなければなりません。
Msg-Length
エムエスジー長さ
The Msg-Length field is one octet and indicates the length of the
Message field
エムエスジー長さの分野は、1つの八重奏であり、Message分野の長さを示します。
Message
メッセージ
The Message field is zero or more octets and indicates an ASCII
message.
Message分野は、ゼロか、より多くの八重奏であり、ASCIIメッセージを示します。
Perkins & Hobby [Page 31] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[31ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
4.4. Authenticate-Nak
4.4. Nakを認証します。
Description
記述
If the Peer-ID/Password pair received in a Authenticate is not
recognizable or acceptable, then a PAP implementation should
transmit a PAP packet with the Code field set to 3 (Authenticate-
Nak), the Identifier field copied from the received Authenticate,
and the Message field optionally filled with an ASCII message.
Authenticateに受け取られたPeer-ID/パスワード組が認識可能でなく、また許容できないなら、PAP実装はCode分野セットでPAPパケットを3に伝えるべきです、そして、(Nakを認証してください)Identifier分野は容認されたAuthenticateからコピーされました、そして、Message分野はASCIIメッセージで任意に満ちました。
A summary of the Authenticate-Nak packet format is shown below. The fields are transmitted from left to right.
Authenticate-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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 Authenticate-Nak.
3、Nakを認証します。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate which caused this
Authenticate-Nak.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 このAuthenticate-Nakを引き起こしたAuthenticateのIdentifier分野からIdentifier分野をコピーしなければなりません。
Msg-Length
エムエスジー長さ
The Msg-Length field is one octet and indicates the length of the
Message field
エムエスジー長さの分野は、1つの八重奏であり、Message分野の長さを示します。
Message
メッセージ
The Message field is zero or more octets and indicates an ASCII
message.
Message分野は、ゼロか、より多くの八重奏であり、ASCIIメッセージを示します。
Perkins & Hobby [Page 32] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[32ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
5. IP Control Protocol (IPCP) Configuration Options
5. IP制御プロトコル(IPCP)設定オプション
IPCP Configuration Options allow negotiatiation of desirable Internet Protocol parameters. Negotiable modifications proposed in this document include IP addresses and compression protocols.
IPCP Configuration Optionsは望ましいインターネットプロトコルパラメタのnegotiatiationを許容します。 本書では提案された交渉可能な変更はIPアドレスと圧縮プロトコルを含んでいます。
The initial proposed values for the IPCP Configuration Option Type field (see [1]) are assigned as follows:
初期はIPCP Configuration Option Type分野に値を提案しました。([1])が以下の通り割り当てられるのを確実にしてください:
1 IP-Addresses 2 Compression-Type
1 IP-アドレス2圧縮タイプ
Perkins & Hobby [Page 33] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[33ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
5.1. IP-Addresses
5.1. IP-アドレス
Description
記述
This Configuration Option provides a way to negotiate the IP
addresses to be used on each end of the link. By default, no IP
addresses are assigned to either end. An address specified as
zero shall be interpreted as requesting the remote end to specify
the address. If an implementation allows the assignment of
multiple IP addresses, then it may include multiple IP Address
Configuration Options in its Configure-Request packets. An
implementation receiving a Configure-Request specifying multiple
IP Address Configuration Options may send a Configure-Reject
specifying one or more of the specified IP Addresses. An
implementation which desires that no IP addresses be assigned
(such as a "half-gateway") may reject all IP Address Configuration
Options.
このConfiguration Optionはリンクの各端で使用されるためにIPアドレスを交渉する方法を提供します。 デフォルトで、IPアドレスは、全く終わるために割り当てられません。 アドレスを指定するようリモートエンドに要求しながら、ゼロとして指定されたアドレスは解釈されるものとします。 実装が複数のIPアドレスの課題を許容するなら、それはConfigure-リクエスト・パケットに複数のIP Address Configuration Optionsを含むかもしれません。 複数のIP Address Configuration Optionsを指定しながらConfigure-要求を受け取る実装で、Configure-廃棄物は指定されたIP Addressesの1つ以上を指定するかもしれません。 IPアドレスが全く割り当てられないというそれの願望(「半分ゲートウェイ」などの)がすべてのIP Address Configuration Optionsを拒絶するかもしれない実装。
A summary of the IP-Addresses Configuration Option format is shown below. The fields are transmitted from left to right.
IP-アドレスConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source-IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source-IP-Address (cont) | Destination-IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination-IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ソースIPアドレス+++++++++++++++++++++++++++++++++ソースIPアドレス(cont)| 送付先IPアドレス+++++++++++++++++++++++++++++++++送付先IPアドレス(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
10
10
Source-IP-Address
ソースIPアドレス
The four octet Source-IP-Address is the desired local address of
the sender of a Configure-Request. In a Configure-Ack,
Configure-Nak or Configure-Reject, the Source-IP-Address is the
remote address of the sender, and is thus a local address with
respect to the Configuration Option receiver.
4八重奏Source IPアドレスはConfigure-要求の送付者の必要なローカルアドレスです。 Configure-Ack、Configure-NakまたはConfigure-廃棄物では、Source IPアドレスは、リモート送信者のアドレスであり、その結果、Configuration Option受信機に関するローカルアドレスです。
Perkins & Hobby [Page 34] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[34ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Destination-IP-Address
送付先IPアドレス
The four octet Destination-IP-Address is the remote address with
respect to the sender of a Configure-Request. In a Configure-Ack,
Configure-Nak or Configure-Reject, the Destination-IP-Address is
the local address of the sender, and is thus a remote address with
respect to the Configuration Option receiver.
4八重奏Destination IPアドレスはConfigure-要求の送付者に関するリモートアドレスです。 Configure-Ack、Configure-NakまたはConfigure-廃棄物では、Destination IPアドレスは、送付者のローカルアドレスであり、その結果、Configuration Option受信機に関するリモートアドレスです。
Default
デフォルト
No IP addresses assigned.
アドレスが割り当てたIPがありません。
Perkins & Hobby [Page 35] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[35ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
5.2. Compression-Type
5.2. 圧縮タイプ
Description
記述
This Configuration Option provides a way to negotiate the use of a
specific compression protocol. By default, compression is not
enabled.
このConfiguration Optionは特定の圧縮プロトコルの使用を交渉する方法を提供します。 デフォルトで、圧縮は可能にされません。
A summary of the Compression-Type Configuration Option format is shown below. The fields are transmitted from left to right.
Compression-タイプConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Compression-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 圧縮タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
2
2
Length
長さ
>= 4
>= 4
Compression-Type
圧縮タイプ
The Compression-Type field is two octets and indicates the type of
compression protocol desired. Values for the Compression-Type are
always the same as the PPP Data Link Layer Protocol field values
for that same compression protocol. The most up-to-date values of
the Compression-Type field are specified in "Assigned Numbers"
[2]. Initial values are assigned as follows:
Compression-タイプ分野は、2つの八重奏であり、圧縮プロトコルのタイプが望んでいたのを示します。 Compression-タイプのための値はその同じ圧縮のためのPPP Data Link Layerプロトコル分野値が議定書を作るのといつも同じです。 Compression-タイプ分野の最も最新の値は「規定番号」[2]で指定されます。 初期の値は以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
0037 Van Jacobson Compressed TCP/IP
0037 バンジェーコブソンはTCP/IPを圧縮しました。
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the compression protocol indicated in the
Compression-Type field.
Data分野は、Compression-タイプ分野で示された圧縮プロトコルで決定するようにゼロか、より多くの八重奏であり、追加データを含んでいます。
Perkins & Hobby [Page 36] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[36ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
Default
デフォルト
No compression protocol enabled.
プロトコルは圧縮可能にされませんでした。
References
参照
[1] Perkins, D., "The Point-to-Point Protocol for the Transmission
of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC
1171, July, 1990.
[1] パーキンス、D.、「ポイントツーポイント接続の上のデータグラムのマルチプロトコルの送信のための二地点間プロトコル」、RFC1171、1990年7月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[2] USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
Security Considerations
セキュリティ問題
Security issues are discussed in Section 2.3.
セクション2.3で安全保障問題について議論します。
Author's Address
作者のアドレス
This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair:
この提案は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
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
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
Perkins & Hobby [Page 37] RFC 1172 PPP Initial Options July 1990
パーキンスと趣味[37ページ]RFC1172pppは1990年7月にオプションに頭文字をつけます。
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 & Hobby [Page 38]
パーキンスと趣味[38ページ]
一覧
スポンサーリンク
