RFC1333 日本語訳
1333 PPP Link Quality Monitoring. W. Simpson. May 1992. (Format: TXT=29965 bytes) (Obsoleted by RFC1989) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson
Request for Comments: 1333 Daydreamer
May 1992
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1333 空想家1992年5月
PPP Link Quality Monitoring
pppのリンクの上質のモニター
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上にNetwork Layerプロトコル情報を要約する標準方法を提供します。 また、PPPは広げることができるLink Controlプロトコルを定義します。(それは、リンクの生存力の連続監視のためのQualityプロトコルの交渉を許します)。
This document defines a protocol for generating Link-Quality-Reports.
このドキュメントは、Linkの上質のレポートを作るためにプロトコルを定義します。
This RFC is a 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-ppp@ucdavis.edu mailing list.
このRFCはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 このメモのコメントを ietf-ppp@ucdavis.edu メーリングリストに提出するべきです。
Simpson [Page i] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[ページi]RFC1333PPP Link Quality Monitoring1992年5月
Table of Contents
目次
1. Introduction .......................................... 1
1. 序論… 1
2. Link Quality Monitoring ............................... 2
2.1 Design Motivation ............................... 2
2.2 Counters ........................................ 2
2.3 Counting Packets and Octets ..................... 4
2.4 Processes ....................................... 4
2.5 Configuration Option Format ..................... 6
2.6 Packet Format ................................... 8
2.7 Transmission of Reports ......................... 12
2.8 Calculations .................................... 12
2.9 Failure Detection ............................... 13
2.10 Policy Suggestions .............................. 14
2. 上質のモニターをリンクしてください… 2 2.1 動機を設計してください… 2 2.2 反対します… 2 2.3 パケットと八重奏を数えます… 4 2.4 処理します… 4 2.5 設定オプション形式… 6 2.6 パケット形式… 8 2.7 レポートの伝達… 12 2.8の計算… 12 2.9 失敗検出… 13 2.10 方針提案… 14
SECURITY CONSIDERATIONS ...................................... 14
セキュリティ問題… 14
REFERENCES ................................................... 14
参照… 14
ACKNOWLEDGEMENTS ............................................. 14
承認… 14
CHAIR'S ADDRESS .............................................. 15
議長のアドレス… 15
AUTHOR'S ADDRESS ............................................. 15
作者のアドレス… 15
Simpson [Page ii] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[ページii]RFC1333PPP Link Quality Monitoring1992年5月
1. Introduction
1. 序論
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating datagrams over serial links.
1. シリーズの上にデータグラムを要約するための方法はリンクされます。
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)の家族。
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during the Establishment phase. During the Authentication and Network-Layer Protocol phases, the link may be tested to determine if quality is sufficient for operation. This testing is completely optional.
ポイントツーポイント接続の上でコミュニケーションを確立して、PPPリンクの各端は、最初に、特権階級段階の間、データ・リンクを構成するためにパケットをLCPに送らなければなりません。 AuthenticationとNetwork-層のプロトコル段階の間、リンクは、品質が操作に十分であるかどうか決定するためにテストされるかもしれません。 このテストは完全に任意です。
If an implementation desires that the peer use some specific link quality monitoring protocol, then it MUST negotiate the use of that protocol using the Quality-Protocol Configuration Option during Link Establishment phase.
実現はそれを望んでいます。いくつかの特定のリンク品質モニターが議定書の中で述べる同輩使用、次に、Link特権階級段階の間、Quality-プロトコルConfiguration Optionを使用して、それはそのプロトコルの使用を交渉しなければなりません。
The negotiation mechanism is independent in each direction. However, if the peer agrees to send Quality-Protocol packets, it MUST correctly process such packets on reception, even if it does not request such packets or implement a monitoring policy.
交渉メカニズムは各方向に独立しています。 しかしながら、同輩が、Quality-プロトコルパケットを送るのに同意するなら、正しくそのようなパケットをレセプションに処理しなければなりません、そのようなパケットを要求しない、またはモニターしている政策を実施しないでも。
Simpson [Page 1] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[1ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
2. Link Quality Monitoring
2. 上質のモニターをリンクしてください。
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".
データ通信リンクはめったに完全ではありません。 パケットは、様々な理由(回線雑音、設備故障、バッファ超過など)で落とされるか、または崩壊できます。 時々、しばしば、リンクがいつ、どのようにデータを落としているかを決定するのは望ましいです。 例えば、ルータは、別のルートが優先するのを一時許容したがっているかもしれません。 また、実現には、交互のリンクに連絡を断って、切り替わるオプションがあるかもしれません。 データの損失を決定する過程は「リンクの上質のモニター」と呼ばれます。
2.1. Design Motivation
2.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 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は、「メカニズム」を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 specifying reference points for all data transmission and reception measurements.
最終的に、Link Quality Monitoringプロトコルは、多くの異種のシステムの上で実行可能になるように設計されています。ただ一つのソフトウェア処理としてPPP(そして、特にLink Quality Monitoring)を実行するのは一般的であるかもしれませんが、また、ハードウェアサポートによるマルチプロセス実現は思い描かれます。 Link上質のレポートパケット・フォーマットの慎重な定義と、すべてのデータ伝送とレセプション測定値に基準点を指定することによって、PPP Link Quality Monitoringメカニズムはこれに備えます。
2.2. Counters
2.2. カウンタ
Each Link Quality Monitoring implementation maintains counts of the number of packets and octets transmitted and successfully received,
それぞれのLink Quality Monitoring実現は送信されて、首尾よく受けられたパケットと八重奏の数のカウントを維持します。
Simpson [Page 2] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[2ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
and periodically transmits this information to its peer in a Link- Quality-Report packet.
そして、定期的にLink上質のレポートパケットの同輩にこの情報を伝えます。
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 "delta" number of packets and octets successfully communicated across the link. Comparing these absolute numbers then gives an indication of a link's quality. Relative numbers, rather than absolute, are transmitted because they greatly simplify link synchronization.
これらのカウンタは一連番号と同様です。 それらは、アウトバウンドリンクの向こう側に伝えられたパケットと八重奏の数の「相対的な」しるしを与えるために絶えず増加しています。 連続したLink上質のレポートの値を比較することによって、LQR受信機はリンクの向こう側に首尾よく伝えられたパケットと八重奏の「デルタ」番号を計算できます。 その時これらの無名数を比較すると、リンクの品質のしるしは与えられます。 リンク同期を大いに簡素化するので、相対数は絶対よりむしろ伝えられます。
The Link-Quality-Report uses the Interface counters defined by SNMP MIB-II [2]. These counters are not initialized to any particular value when the LCP enters the Establishment phase.
Linkの上質のレポートはSNMP MIB-II[2]によって定義されたInterfaceカウンタを使用します。 LCPが特権階級フェーズに入るとき、これらのカウンタはどんな特定の値にも初期化されません。
In addition, the Link-Quality-Report requires the implementation of the following three unsigned, monotonically increasing counters which conform to the type and size requirements for SNMP MIB Counters [3].
さらに、Linkの上質のレポートはSNMP MIB Counters[3]のためのタイプとサイズ要件に従う以下の3台の無記名の、そして、単調に増加するカウンタの実現を必要とします。
OutLQRs
OutLQRs
OutLQRs is a 32-bit counter which increases by one for each
tranmitted Link-Quality-Report packet. This counter MUST be set
to zero when the LCP enters the Establishment phase, and MUST NOT
be reset until the LCP leaves the Termination phase. This counter
is incremented before it is inserted into the LQR packet.
OutLQRsはそれぞれのtranmitted Linkの上質のレポートパケットあたり1つ増加する32ビットのカウンタです。 このカウンタは、LCPが特権階級フェーズに入るとき、ゼロに設定しなければならなくて、LCPがTerminationフェーズを残すまで、リセットされてはいけません。 それがLQRパケットに挿入される前にこのカウンタは増加されています。
InLQRs
InLQRs
InLQRs is a 32-bit counter which increases by one for each
received Link-Quality-Report packet. This counter MUST be set to
zero when the LCP enters the Establishment phase, and MUST NOT be
reset until the LCP leaves the Termination phase. This counter is
incremented before it is inserted (in an implementation dependent
fashion) into the LQR packet.
InLQRsはそれぞれの容認されたLinkの上質のレポートパケットあたり1つ増加する32ビットのカウンタです。 このカウンタは、LCPが特権階級フェーズに入るとき、ゼロに設定しなければならなくて、LCPがTerminationフェーズを残すまで、リセットされてはいけません。 それがLQRパケットに挿入される(実現に依存するファッションで)前にこのカウンタは増加されています。
InGoodOctets
InGoodOctets
InGoodOctets is a 32-bit counter which increases by the number of
octets in each successfully received Data Link Layer packet.
Unlike the MIB ifInOctets, octets for frames which are counted in
ifInDiscards and ifInErrors MUST NOT be counted. This counter MAY
be set to any initial value when the LCP enters the Establishment
phase, but MUST NOT be reset until the LCP leaves the Termination
phase.
InGoodOctetsはそれぞれの首尾よく受け取られたData Link Layerパケットの八重奏の数に従って増加する32ビットのカウンタです。 MIB ifInOctetsと異なって、ifInDiscardsとifInErrorsで数えられるフレームのための八重奏を数えてはいけません。 このカウンタを、LCPが特権階級フェーズに入るとき、どんな初期の値にも設定されるかもしれませんが、LCPがTerminationフェーズを残すまで、リセットしてはいけません。
Simpson [Page 3] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[3ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
2.3. Counting Packets and Octets
2.3. パケットと八重奏を数えます。
The intent of the counters is to provide an indication of the amount of information passing over the link, rather than an actual measurement of the total bandwidth used. This specification is designed to yield the same count in various circumstances, such as when a separate device provides the framing and escaping mechanisms invisibly to the implementation, or a synchronous-to-asynchronous converter in the link changes between mechanisms.
カウンタの意図は合計の実測よりむしろ帯域幅が使用したリンクを通り過ぎる情報量のしるしを供給することです。 この仕様は様々な事情における同じカウントをもたらすように設計されています、別々の装置が縁どりと目につかないほど実現にメカニズムから逃げるか、リンク変化における非同期であるのと同期のコンバータをメカニズムの間に供給する時のように。
All octets which are included in the FCS calculation MUST be counted, including the packet header, the information field, and any padding. The FCS octets MUST also be counted, and one flag octet per frame MUST be counted. All other octets (such as additional flag sequences, and escape bits or octets) MUST NOT be counted.
FCS計算に含まれているすべての八重奏を数えなければなりません、パケットのヘッダー、情報フィールド、およびどんな詰め物も含んでいて。 また、FCS八重奏を数えなければなりません、そして、1フレームあたり1つの旗の八重奏を数えなければなりません。 他のすべての八重奏(追加フラグ・シーケンスや、エスケープビットや八重奏などの)を数えなければならないというわけではありません。
When inserting the packet and octet counts in the LQR, the counts MUST include the expected values for the LQR itself.
パケットと八重奏カウントをLQRに挿入するとき、カウントはLQR自身のための期待値を含まなければなりません。
2.4. Processes
2.4. 過程
The PPP Link Quality Monitoring mechanism is described using a "logical process" model. As shown below, there are five logical processes duplicated at each end of the duplex link.
PPP Link Quality Monitoringメカニズムは、「論理的な過程」モデルを使用することで説明されます。 以下に示すように、複式のリンクの各端のときにコピーされた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 Quality-Protocol Configuration Option.
Link-マネージャの過程は、Link上質のレポートを送信して、受け取って、必要なリンク品質方針を実行します。 LQRパケットは一定のレートで伝えられます。(それは、LCP Quality-プロトコルConfiguration Optionによって交渉されます)。
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など)からパケットの単一の、そして、連続して、最優先している流れの中に多重送信します。 リンク品質情報が伝えられるのを保障するためにリンクの上質のレポートパケットはタイムリーな方法で優先しなければなりません可能な限り高い。
Simpson [Page 4] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[4ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
Tx
Tx
The Tx process maintains the MIB counters ifOutUniPackets and
ifOutOctets, and the internal counter OutLQRs, 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 corresponding PeerOut...
fields of the packet. The Tx process MUST follow the Mux process
so that packets are counted in the order transmitted to the link.
Txの過程は、MIBカウンタがifOutUniPacketsと、ifOutOctetsと、内部のカウンタOutLQRsであることを支持します。(OutLQRsは、アウトバウンドリンクで伝えられるデータ量を測定するのに使用されます)。 TxがLinkの上質のレポートパケットを処理するとき、それはパケットの対応するPeerOut…分野にこれらのカウンタの値を挿入します。 Txの過程がMuxの過程に従わなければならないので、パケットはリンクに伝えられたオーダーで数えられます。
Rx
Rx
The Rx process maintains the MIB counters ifInUniPackets,
ifInDiscards, ifInErrors and IfInOctets, and the internal counters
InLQRs and InGoodOctets, which are used to measure the amount of
data which is received by the inbound link. When Rx processes a
Link-Quality-Report packet, it inserts the values of these
counters into the corresponding SaveIn... fields of the packet (in
an implementation dependent manner).
Rxの過程は、MIBカウンタが内部のカウンタのifInUniPacketsと、ifInDiscardsと、ifInErrorsと、IfInOctetsと、InLQRsとInGoodOctetsであることを支持します。(InGoodOctetsは、インバウンドリンクによって受け取られるデータ量を測定するのに使用されます)。 RxがLinkの上質のレポートパケットを処理するとき、それはパケット(実現に依存する方法による)の対応するSaveIn…分野にこれらのカウンタの値を挿入します。
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の過程に従わなければならないので、パケットはリンクから受注で数えられます。
Simpson [Page 5] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[5ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
2.5. Configuration Option Format
2.5. 設定オプション形式
Description
記述
Implementations MUST be prepared to receive the Quality-Protocol
Configuration Option for the Link-Quality-Report. However,
negotiation is not required. Negotiation is only necessary when
the implementation wishes to ensure that the peer transmits Link-
Quality-Reports as opposed to some other Quality-Protocol, or else
to prevent the peer from maintaining its own timer, or else to
establish a maximum time between transmissions of Link-Quality-
Reports.
Linkの上質のレポートのためにQuality-プロトコルConfiguration Optionを受け取るように実現を準備しなければなりません。 しかしながら、交渉は必要ではありません。 実現が同輩がある他のQuality-プロトコルと対照的にLinkの上質のレポートを伝えるのを保証したいか、同輩がそれ自身のタイマを維持するのを防ぎたいか、または単にLink上質のレポートの送信の間で最大の時間を証明したがっているとき、交渉が必要です。
A summary of the Quality-Protocol Configuration Option format to negotiate the Link-Quality-Report is shown below. The fields are transmitted from left to right.
Configuration OptionがLinkの上質のレポートを交渉するためにフォーマットするQuality-プロトコルの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Quality-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporting-Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 上質のプロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 報告期間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
4
4
Length
長さ
8
8
Quality-Protocol
上質のプロトコル
c025 (hex) for Link-Quality-Report
Linkの上質のレポートのためのc025(十六進法)
Reporting-Period
報告期間
The Reporting-Period field is four octets and indicates the
maximum time in hundredths of seconds between transmission of
packets. The peer MAY transmit packets at a faster rate than that
which was negotiated.
Reporting-期間の分野は、4つの八重奏であり、パケットのトランスミッションの間の秒の100分の1で最大の時間を示します。 同輩は交渉されたそれより速いレートでパケットを伝えるかもしれません。
A value of zero indicates that the peer does not need to maintain
a timer. Instead, the peer generates a LQR immediately upon
receiving a LQR. A value of zero MUST be Nak'd by the peer with
ゼロの値は、同輩がタイマを維持する必要はないのを示します。 代わりに、すぐLQRを受けるとき、同輩はLQRを発生させます。 ゼロの値がNakでなければならない、同輩で、そうするでしょう。
Simpson [Page 6] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[6ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
an appropriate non-zero value when that peer has sent or will send
a Configure-Request packet containing the Quality-Protocol
Configuration Option for the Link-Quality-Report with a zero
Reporting-Period.
その同輩であるときに、適切な非ゼロ値が発信したか、またはゼロでLinkの上質のレポートのためのQuality-プロトコルConfiguration Optionを含むConfigure-リクエスト・パケットReporting-期間を送るでしょう。
Simpson [Page 7] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[7ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
2.6. Packet Format
2.6. パケット・フォーマット
Exactly one Link-Quality-Report packet is encapsulated in the Information field of PPP Data Link Layer frames where the protocol field indicates type hex c025 (Link-Quality-Report). A summary of the LQR packet format is shown below. The names of the fields are relative to the packet receiver, since it is the receiver who requested the packet in the Configuration Option. The fields are transmitted from left to right.
ちょうど1つのLinkの上質のレポートパケットがプロトコル分野がタイプ十六進法c025を示す(上質のレポートをリンクしてください)PPP Data Link Layerフレームの情報分野でカプセルに入れられます。 LQRパケット・フォーマットの概要は以下に示されます。 分野の名前はパケット受信機に比例しています、それが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastOutLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastOutPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInDiscards |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInErrors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerOutLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerOutPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジックナンバー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LastOutLQRs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LastOutPackets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LastOutOctets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerInLQRs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerInPackets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerInDiscards| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerInErrors| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerInOctets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerOutLQRs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerOutPackets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PeerOutOctets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are not actually transmitted over the inbound link. Rather, they are logically appended (in an implementation dependent manner) to the packet by the implementation's Rx process.
以下の野原は実際にインバウンドリンクについて送信されません。 むしろ、それらをパケットに実現のRx工程で論理的に追加します(実現に依存する方法で)。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInLQRs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInPackets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInDiscards |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInLQRs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInPackets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInDiscards|
Simpson [Page 8] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[8ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInErrors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInErrors| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInOctets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-Number
マジックナンバー
The Magic-Number field is four octets and aids in detecting links
which are in the looped-back condition. Unless modified by a
Configuration Option, the Magic-Number MUST be transmitted as zero
and MUST be ignored on reception. If Magic-Numbers have been
negotiated, incoming LQR packets SHOULD be checked to ensure that
the local end is not seeing its own Magic-Number and thus a
looped-back link. See the Magic-Number Configuration Option for
further explanation.
マジックナンバーフィールドは、輪にされて逆状態であるリンクを検出することにおいて4つの八重奏と援助です。 Configuration Optionによって変更されない場合、マジック数をゼロとして伝えなければならなくて、レセプションで無視しなければなりません。 マジック数が交渉されて、入って来るLQRパケットSHOULDであるならチェックされて、地方の終わりがそれ自身のマジック番号とその結果輪にされて逆リンクが見えていないのを保証してください。 詳細な説明のマジック数のConfiguration Optionを見てください。
LastOutLQRs
LastOutLQRs
The LastOutLQRs field is four octets, and is copied from the most
recently received PeerOutLQRs on transmission.
LastOutLQRs分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたPeerOutLQRsからコピーされます。
LastOutPackets
LastOutPackets
The LastOutPackets field is four octets, and is copied from the
most recently received PeerOutPackets on transmission.
LastOutPackets分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたPeerOutPacketsからコピーされます。
LastOutOctets
LastOutOctets
The LastOutOctets field is four octets, and is copied from the
most recently received PeerOutOctets on transmission.
LastOutOctets分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたPeerOutOctetsからコピーされます。
PeerInLQRs
PeerInLQRs
The PeerInLQRs field is four octets, and is copied from the most
recently received SaveInLQRs on transmission.
PeerInLQRs分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたSaveInLQRsからコピーされます。
Whenever the PeerInLQRs field is discovered to be zero, the
LastOut... fields are indeterminate, and the PeerIn... fields
contain the initial values for the peer.
PeerInLQRs分野がゼロであると発見されるときはいつも、LastOut…分野は不確定です、そして、PeerIn…分野は同輩のための初期の値を含んでいます。
PeerInPackets
PeerInPackets
The PeerInPackets field is four octets, and is copied from the
most recently received SaveInPackets on transmission.
PeerInPackets分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたSaveInPacketsからコピーされます。
Simpson [Page 9] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[9ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
PeerInDiscards
PeerInDiscards
The PeerInDiscards field is four octets, and is copied from the
most recently received SaveInDiscards on transmission.
PeerInDiscards分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたSaveInDiscardsからコピーされます。
PeerInErrors
PeerInErrors
The PeerInErrors field is four octets, and is copied from the most
recently received SaveInErrors on transmission.
PeerInErrors分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたSaveInErrorsからコピーされます。
PeerInOctets
PeerInOctets
The PeerInOctets field is four octets, and is copied from the most
recently received SaveInOctets on transmission.
PeerInOctets分野は、4つの八重奏であり、トランスミッションのときに最も最近容認されたSaveInOctetsからコピーされます。
PeerOutLQRs
PeerOutLQRs
The PeerOutLQRs field is four octets, and is copied from OutLQRs
on transmission. This number MUST include this LQR.
PeerOutLQRs分野は、4つの八重奏であり、トランスミッションのときにOutLQRsからコピーされます。 この数はこのLQRを含まなければなりません。
PeerOutPackets
PeerOutPackets
The PeerOutPackets field is four octets, and is copied from the
current MIB ifOutUniPackets and ifOutNUniPackets on transmission.
This number MUST include this LQR.
PeerOutPackets分野は、4つの八重奏であり、トランスミッションのときに現在のMIB ifOutUniPacketsとifOutNUniPacketsからコピーされます。 この数はこのLQRを含まなければなりません。
PeerOutOctets
PeerOutOctets
The PeerOutOctets field is four octets, and is copied from the
current MIB ifOutOctets on transmission. This number MUST include
this LQR.
PeerOutOctets分野は、4つの八重奏であり、トランスミッションのときに現在のMIB ifOutOctetsからコピーされます。 この数はこのLQRを含まなければなりません。
SaveInLQRs
SaveInLQRs
The SaveInLQRs field is four octets, and is copied from InLQRs on
reception. This number MUST include this LQR.
SaveInLQRs分野は、4つの八重奏であり、レセプションにInLQRsからコピーされます。 この数はこのLQRを含まなければなりません。
SaveInPackets
SaveInPackets
The SaveInPackets field is four octets, and is copied from the
current MIB ifInUniPackets and ifInNUniPackets on reception. This
number MUST include this LQR.
SaveInPackets分野は、4つの八重奏であり、レセプションに現在のMIB ifInUniPacketsとifInNUniPacketsからコピーされます。 この数はこのLQRを含まなければなりません。
SaveInDiscards
SaveInDiscards
The SaveInDiscards field is four octets, and is copied from the
current MIB ifInDiscards on reception. This number MUST include
this LQR.
SaveInDiscards分野は、4つの八重奏であり、レセプションの現在のMIB ifInDiscardsからコピーされます。 この数はこのLQRを含まなければなりません。
Simpson [Page 10] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[10ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
SaveInErrors
SaveInErrors
The SaveInErrors field is four octets, and is copied from the
current MIB ifInErrors on reception. This number MUST include
this LQR.
SaveInErrors分野は、4つの八重奏であり、レセプションの現在のMIB ifInErrorsからコピーされます。 この数はこのLQRを含まなければなりません。
SaveInOctets
SaveInOctets
The SaveInOctets field is four octets, and is copied from the
current InGoodOctets on reception. This number MUST include this
LQR.
SaveInOctets分野は、4つの八重奏であり、レセプションの現在のInGoodOctetsからコピーされます。 この数はこのLQRを含まなければなりません。
Note that InGoodOctets is not the same as the MIB ifInOctets
counter, as InGoodOctets does not include octets for packets which
are discards or errors.
MIB ifInOctetsが反対するようにInGoodOctetsが同じでないことに注意してください、InGoodOctetsが破棄か誤りであるパケットのための八重奏を含んでいないとき。
Simpson [Page 11] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[11ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
2.7. Transmission of Reports
2.7. レポートの伝達
When the PPP Link Control Protocol has reached the Opened state, the Link Quality Monitoring process MAY commence sending Link-Quality- Reports. If a Protocol-Reject is received specifying a LQR packet, the LQM process MUST cease sending LQRs.
PPP Link ControlプロトコルがOpened状態に達したとき、Link Quality Monitoringの過程は送付Link-品質レポートを始めるかもしれません。 プロトコル廃棄物がLQRパケットを指定するのにおいて受け取られているなら、LQMの過程は、LQRsを送るのをやめなければなりません。
Usually, the LQR is transmitted when the LQR timer for the link expires. If no LQR timer is used, a LQR is generated upon receipt of an incoming LQR. The negotiation process ensures that at least one side of the link is using a LQR timer.
リンクへのLQRタイマが期限が切れるとき、通常、LQRは伝えられます。 どんなLQRタイマも使用されていないなら、LQRは入って来るLQRを受け取り次第発生します。 交渉の過程は、少なくともリンクの半面がLQRタイマを使用しているのを確実にします。
In addition, a LQR is generated whenever two successive LQRs are received which have the same PeerInLQRs value. This may indicate that a LQR has been missed, or that the implementation is sending at a significantly slower rate than the peer, or that the peer has accelerated LQR generation to better quantify errors on the link.
さらに、2連続したLQRsが受け取られているときはいつも、LQRは発生します(同じPeerInLQRs値があります)。 これは、LQRがいなくて寂しかった、実現が同輩よりかなり遅いレートで発信するか、または同輩がリンクで誤りをよりよく定量化するためにLQR世代を加速したのを示すかもしれません。
Whenever a LQR is sent, the LQR timer MUST be restarted.
LQRを送るときはいつも、LQRタイマを再開しなければなりません。
2.8. Calculations
2.8. 計算
Each time a Link-Quality-Report packet is received from the inbound link, the Link-Manager can compare the associated fields. The fields of the previous LQR can be subtracted from the current LQR values to obtain an absolute "delta", which allows comparision of the changes seen by each end of the link.
Link-マネージャはインバウンドリンクからLinkの上質のレポートパケットを受け取るたびに関連分野を比較できます。 リンクの各端までに見られた変化のcomparisionを許容する絶対「デルタ」を得るために現在のLQR値から前のLQRの分野を引き算できます。
If the received PeerInLQRs field is zero, the LastOut... fields are indeterminate, and the PeerIn... fields contain the initial values for the peer. No calculations using these fields can be performed at this time.
容認されたPeerInLQRs分野がゼロであるなら、LastOut…分野は不確定です、そして、PeerIn…分野は同輩のための初期の値を含んでいます。 このとき、これらの分野を使用する計算は全く実行できません。
Implementation Note:
実現注意:
The following counters wrap to zero when their maximum value is
reached. Care must be taken to ensure that correct "delta"
calculations are performed at that time.
それらの最大値に達しているとき、以下は包装をゼロまで打ち返します。 正しい「デルタ」計算がその時実行されるのを保証するために注意しなければなりません。
The LastOutLQRs field may be directly compared with the PeerInLQRs field to determine how many outbound LQRs have been lost.
LastOutLQRs分野は、いくつの外国行きのLQRsがなくされたかを決定するために直接PeerInLQRs分野にたとえられるかもしれません。
The LastOutLQRs field may be directly compared with the OutLQRs counter to determine how many outbound LQRs are still in the pipeline.
LastOutLQRs分野は、いくつの外国行きのLQRsがまだパイプラインにあるかを決定するために直接OutLQRsカウンタと比較されるかもしれません。
The change in PeerInPackets may be compared with the change in LastOutPackets to determine the number of lost packets over the
PeerInPacketsにおける変化は、無くなっているパケットの数を測定するためにLastOutPacketsにおける変化と比較されるかもしれません。
Simpson [Page 12] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[12ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
outgoing link.
出発しているリンク。
The change in PeerInOctets may be compared with the change in LastOutOctets to determine the number of lost octets over the outgoing link.
PeerInOctetsにおける変化は、出発しているリンクの上の無くなっている八重奏の数を測定するためにLastOutOctetsにおける変化と比較されるかもしれません。
The change in SaveInPackets may be compared with the change in PeerOutPackets to determine the number of lost packets over the incoming link.
SaveInPacketsにおける変化は、入って来るリンクの上に無くなっているパケットの数を測定するためにPeerOutPacketsにおける変化と比較されるかもしれません。
The change in SaveInOctets may be compared with the change in PeerOutOctets to determine the number of lost octets over the incoming link.
SaveInOctetsにおける変化は、入って来るリンクの上の無くなっている八重奏の数を測定するためにPeerOutOctetsにおける変化と比較されるかもしれません。
The change in the PeerInDiscards and PeerInErrors fields may be used to determine whether packet loss is due to congestion in the peer rather than physical link failure.
PeerInDiscardsとPeerInErrors分野の変化は、物理的なリンクの故障よりむしろ同輩でパケット損失が混雑のためであるかを決定するのに使用されるかもしれません。
2.9. Failure Detection
2.9. 失敗検出
When the link is operating well in both directions of the link, the LQR is superfluous. The maximum time interval for transmitting LQRs SHOULD be chosen to minimally interfere with active traffic.
リンクがリンクの両方の方向によく作動しているとき、LQRは余計です。 最大はLQRs SHOULDを伝えるための間隔を調節します。活発な交通を最少量で妨げるために、選ばれています。
When there is a measurable loss of data in either direction, if the overall throughput is adequate, conditions are not severe enough to warrant dropping the link. Sending LQRs faster will gain nothing, except to measure peaks in the loss rate. The time interval MUST be chosen to be long enough to have a good smoothing effect on the data, while short enough to ensure fast enough response to complete failure.
総合的なスループットが適切であるならどちらかの方向へのデータの測定できる損失があるとき、状態はリンクを落とすのを保証するくらいには厳しくはありません。 損失率におけるピークを測定する以外に、より速くLQRsを送るのは何ら利するところがないでしょう。 失敗を完成するために十分速い応答を確実にすることができるくらい短い間の良いスムージング影響をデータに与えることができるくらい長くなるように時間間隔を選ばなければなりません。
When the link is good incoming, but very bad outgoing, incoming LQRs indicate a high loss on the outgoing side of the link. Sending LQRs faster won't help, because they are probably lost on the way to the peer.
リンクが良いときに、入って来ますが、非常に悪い外向的で、入って来るLQRsはリンクの出発している側面で高い損失を示します。 彼らがたぶん同輩への途中で失われているので、より速くLQRsを送るのは助けないでしょう。
When the link is good outgoing, but very bad incoming, incoming LRQs will be frequently lost. In this case, LQRs SHOULD be sent at a faster rate. This primarily relies on the peer to make an informed policy decision. The peer will also send LQRs in response (due to the duplicate PeerInLQRs field), and some of those LQRs may successfully arrive.
リンクが良い外向的な、しかし、非常に悪い入来であるときに、入って来るLRQsは頻繁になくされるでしょう。 この場合LQRs SHOULD、 より速いレートで、送ってください。 これは、知識がある政策決定をするように主として同輩に頼ります。 また、同輩は応答(写しPeerInLQRs分野による)でLQRsを送るでしょう、そして、それらのいくつかのLQRsが首尾よく到着するかもしれません。
When a LQR does not arrive within the time expected, or the LQR received indicates that the links are truly bad, at least one additional LQR SHOULD be sent. An algorithmic decision requires at least 2 round trip intervals. The loss rate could be transient, due
LQRが予想された時中にそうしないとき、到着してください。さもないと、受け取られたLQRは、本当に、リンクが悪いのを示します、少なくとも1追加LQR SHOULD。送ります。 アルゴリズムの決定は少なくとも2回の周遊旅行間隔を必要とします。 損失率は、一時的であって、当然であるかもしれません。
Simpson [Page 13] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[13ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
to a heavily loaded link, or a lost outgoing LQR.
大いに積み込まれたリンク、または無くなっている出発しているLQRに。
2.10. Policy Suggestions
2.10. 方針提案
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. One 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.
リンクの上質のレポートパケットはリンク品質を決定するためにメカニズムを提供しますが、リンクがいつ使用可能であるかを決めるのが各実現まで達しています。 この方針がいくらかの量のヒステリシスを実行するのが、お勧めであるので、リンクは上下に弾みません。 1つの方針は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-Request), but to continue transmitting Link-Quality-Reports. Once the link quality again reaches an acceptable level, Network-Layer protocols can be reconfigured.
貧しい上質のリンクからの回復のための手順は、不特定であり、実現によって異なるかもしれません。 提案されたアプローチがすぐに他のすべてのNetwork-層のプロトコル(Terminate-要求を伝えるすなわち、原因IPCP)を閉じることですが、伝わり続けるために、Link品質は報告します。 リンク品質が再びいったん合格水準に達すると、Network-層のプロトコルを再構成できます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.
[1] シンプソン(W.、「二地点間プロトコル」、RFC1331)は1992がそうするかもしれません。
[2] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets: MIB-II", RFC
1213, March 1991.
[2]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、RFC1213、1991年3月。
[3] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
May 1990.
[3] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(RFC1155)は1990がそうするかもしれません。
Acknowledgments
承認
Some of the text in this document is taken from RFC 1172, by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis.
テキストのいくつかがRFC1172、カーネギーメロン大学のドリュー・パーキンス、およびカリフォルニア大学デイビス校のラスHobbyによって本書では取られます。
Special thanks to Craig Fox (Network Systems), and Karl Fox (Morning Star Technologies), for design suggestions based on implementation experience.
クレイグフォックスへの特別な感謝(ネットワークSystems)、および実現経験に基づくデザイン提案のためのカールフォックス(朝のStar Technologies)。
Simpson [Page 14] RFC 1333 PPP Link Quality Monitoring May 1992
シンプソン[14ページ]RFC1333pppはモニターしている1992年5月に品質をリンクします。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
ブライアン・ロイド・ロイドと3420年のサドベリー道路キャメロン公園、仲間カリフォルニア 95682
Phone: (916) 676-1147
以下に電話をしてください。 (916) 676-1147
EMail: brian@ray.lloyd.com
メール: brian@ray.lloyd.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6025
P O Box6205イーストランシング、Services MI48826-6025に相談するウィリアムアレンシンプソン空想家コンピュータシステムズ
EMail: bsimpson@ray.lloyd.com
メール: bsimpson@ray.lloyd.com
Simpson [Page 15]
シンプソン[15ページ]
一覧
スポンサーリンク
