RFC1663 日本語訳
1663 PPP Reliable Transmission. D. Rand. July 1994. (Format: TXT=17281 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Rand Request for Comments: 1663 Novell Category: Standards Track July 1994
コメントを求めるワーキンググループD.底ならし革要求をネットワークでつないでください: 1663年のノベルカテゴリ: 標準化過程1994年7月
PPP Reliable Transmission
pppの信頼できる送信
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
This document defines a method for negotiating and using Numbered- Mode, as defined by ISO 7776 [2], to provide a reliable serial link.
このドキュメントはNumberedモードを交渉して、使用するためのメソッドを定義します、ISO7776[2]によって定義されて、信頼できる連続のリンクを提供するように。
This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 ietf-ppp@ucdavis.edu メーリングリストにコメントを提出するべきです。
Table of Contents
目次
1. Introduction .......................................... 1 2. Physical Layer Requirements ........................... 2 3. The Data Link Layer ................................... 2 3.1 Frame Format ....................................... 2 4. Configuration Option Format ........................... 4 5. Numbered-Mode Operation ............................... 5 5.1 Single Link ........................................ 6 5.2 Inverse Multiplexing ............................... 6 5.3 Using Multi-Link Procedure... ...................... 7 5.4 LAPB Parameter defaults ............................ 8 SECURITY CONSIDERATIONS ...................................... 9 REFERENCES ................................................... 9 ACKNOWLEDGEMENTS ............................................. 9 CHAIR'S ADDRESS .............................................. 10 AUTHOR'S ADDRESS ............................................. 10
1. 序論… 1 2. 物理的な層の要件… 2 3. データ・リンク層… 2 3.1 形式を縁どってください… 2 4. 設定オプション形式… 4 5. 番号付のモード操作… 5.1が選抜する人5はリンクされます… 6 5.2の逆さのマルチプレクシング… 6 5.3 マルチリンク手順を用います… ...................... 7 5.4 LAPB Parameterはデフォルトとします… 8 セキュリティ問題… 9つの参照箇所… 9つの承認… 9 議長のアドレス… 10作者のアドレス… 10
Rand [Page 1] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[1ページ]RFC1663ppp
1. Introduction
1. 序論
By default, PPP packets over HDLC framed links consist of "connectionless" datagrams. If reliable transmission over the HDLC link is desired, the implementation MUST specify the Numbered-Mode Configuration Option during Link Establishment phase.
デフォルトで、PPPパケットはHDLCの上でリンクを縁どりました。「コネクションレスな」データグラムから成ってください。HDLCリンクの上の信頼できるトランスミッションが望まれているなら、実装はLink特権階級段階の間、Numbered-モードConfiguration Optionを指定しなければなりません。
Generally, serial link reliability is not a major issue. The architecture of protocols used in datagram networking presume best-effort non-sequential delivery. When errors are detected, datagrams are discarded.
一般に、連続のリンクの信頼性は主要な問題ではありません。 データグラムネットワークに使用されるプロトコルのアーキテクチャはベストエフォート型非連続した配送を推定します。 誤りが検出されるとき、データグラムは捨てられます。
However, in certain circumstances, it is advisable to provide a reliable link, at least for a subset of the messages. The most obvious case is when the link is compressed. Since the dictionary is recovered from the compressed data stream, and a lost datagram corrupts the dictionary, datagrams must not be lost. Not all compression types will require a reliable data stream, since the cost to detect and reset a corrupt dictionary is small.
しかしながら、ある特定の状況では、少なくともメッセージの部分集合に信頼できるリンクを提供するのは賢明です。 最も明白なケースはリンクが圧縮される時です。 圧縮されたデータ・ストリームを辞書から取り戻して、無くなっているデータグラムが辞書を改悪するので、データグラムをなくしてはいけません。 すべての圧縮タイプが確実な資料ストリームを必要とするというわけではないでしょう、改悪された辞書を検出して、リセットする費用がわずかであるので。
The ISO 7776 LAPB can be used guarantee delivery. This is referred to in this document as "Numbered Mode" to distinguish it from the use of "Unnumbered Information", which is standard PPP framing practice.
ISO7776LAPBは中古の保証配送であるかもしれません。 これは、一般的なPPP縁どり練習である「無数の情報」の使用とそれを区別するために本書では「番号付のモード」に言及されます。
Where multiple parallel links are used to emulate a single link of higher speed, Bridged traffic, Source Routed traffic, and traffic subjected to Van Jacobsen TCP/IP header compression must be delivered to the higher layer in a certain sequence. However, the fact of the links being relatively asynchronous makes traffic ordering uncertain.
ある系列で複数の平行なリンクがヴァンジェイコブセンTCP/IPヘッダー圧縮にかけられたより高い速度、Bridgedトラフィック、Source Routedトラフィック、およびトラフィックの単一のリンクを見習うのにどこで使用されるかより高い層に提供しなければなりません。 しかしながら、比較的非同期なリンクの事実で、トラフィック注文は不確実になります。
The ISO 7776 Multi-Link Procedure MAY be used to restore order. Implementation of the ISO Multi-Link Procedure is deprecated. It is recommended that the PPP multilink procedure [4] be used instead.
ISO7776Multi-リンクProcedureは、秩序を回復するのに使用されるかもしれません。 ISO Multi-リンクProcedureの実装は推奨しないです。 PPPマルチリンク手順[4]が代わりに使用されるのは、お勧めです。
2. Physical Layer Requirements
2. 物理的な層の要件
PPP Reliable Transmission imposes the same requirements that are described in "PPP in HDLC Framing" [3], with the following exceptions.
PPP Reliable Transmissionは「HDLC縁どりにおけるppp」[3]で以下の例外で説明されるのと同じ要件を課します。
Control Signals
制御信号
While PPP does not normally require the use of control signals,
implementation of Numbered-Mode LAPB or LAPD requires the
provision of control signals, which indicate when the link has
become connected or disconnected. These in turn provide the Up
and Down events to the LCP state machine.
PPPは通常制御信号の使用を必要としませんが、Numbered-モードのLAPBかLAPDの実装は制御信号の設備を必要とします。(信号はリンクがいつ接続されるようになるか、または切断したかを示します)。 これらは順番にUpとDownイベントをLCP州のマシンに供給します。
Rand [Page 2] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[2ページ]RFC1663ppp
3. The Data Link Layer
3. データ・リンク層
Numbered-Mode affects only the Address and Control fields. The remainder of the frame conforms to the framing in use for PPP.
番号付のモードはAddressとControl分野だけに影響します。 フレームの残りはPPPに、使用中の縁どりに従います。
The Address Field of the frame MUST take the value announced in the Numbered-Mode Configuration Option, and the Control Field MAY take any value valid in ISO 7776.
フレームのAddress FieldはNumbered-モードConfiguration Optionで発表された値を取らなければなりません、そして、Control FieldはISO7776で有効などんな値も取るかもしれません。
Once the link enters Numbered-Mode, Numbered-Mode MUST be used on all frames, as some implementations do not support the use of the Unnumbered-Information control field or the use of the All-Stations address intermixed with Numbered-Mode frames.
リンクがいったんNumbered-モードを入れると、すべてのフレームの上にNumbered-モードを使用しなければなりません、いくつかの実装がUnnumbered-情報管理分野の使用かNumbered-モードフレームで混ぜられたAll-駅のアドレスの使用をサポートしないとき。
3.1. Frame Format
3.1. フレーム形式
The following frame format is valid under Numbered-Mode. The fields are transmitted from left to right.
以下のフレーム形式はNumbered-モードの下で有効です。 野原は左から右まで伝えられます。
Numbered Mode
+----------+----------+----------+
| Flag | Address | Control |
| 01111110 |1-2 octets|1-2 octets|
+----------+----------+----------+
+----------+-------------+---------+
| Protocol | Information | Padding |
|1-2 octets| * | * |
+----------+-------------+---------+
+----------+----------+-----------------
| FCS | Flag | Inter-frame Fill
| 16 bits | 01111110 | or next Address
+----------+----------+-----------------
番号付のモード+----------+----------+----------+ | 旗| アドレス| コントロール| | 01111110 |1-2 八重奏|1-2 八重奏| +----------+----------+----------+ +----------+-------------+---------+ | プロトコル| 情報| 詰め物| |1-2 八重奏| * | * | +----------+-------------+---------+ +----------+----------+----------------- | FCS| 旗| インターフレーム中詰め| 16ビット| 01111110 | または、次のAddress+----------+----------+-----------------
The Protocol, Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [1]. The FCS and Flag Sequence fields are described in "PPP in HDLC Framing" [3].
プロトコル、情報、およびPadding分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。 FCSとFlag Sequence分野は「HDLC縁どりにおけるppp」[3]で説明されます。
4. Configuration Option Format
4. 設定オプション形式
Description
記述
The LCP Numbered-Mode Configuration Option negotiates the use of
Numbered-Mode on the link. By default or ultimate disagreement,
Unnumbered-Mode is used.
LCP Numbered-モードConfiguration OptionはリンクにおけるNumbered-モードの使用を交渉します。 または、デフォルトで、究極の不一致、Unnumbered-モードは使用されています。
A summary of the Numbered-Mode Configuration Option format is shown below. The fields are transmitted from left to right.
Numbered-モードConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Rand [Page 3] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[3ページ]RFC1663ppp
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 | Window | Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
11
11
Length
長さ
>= 4
>= 4
Window
窓
A value between 1 and 127. This indicates the number of frames
the receiver will buffer, which is the maximum number that the
sender should send without receiving an acknowledgement. If
window < 8, then modulo 8 sequencing is used on the link.
Otherwise, modulo 128 sequencing is used.
1と127の間の値。 これは受信機がバッファリングするフレームの数を示します。(それは、送付者が承認を受けないで送るべきである最大数です)。 窓<8であるなら、法8配列はリンクの上に使用されます。 さもなければ、法128配列は使用されています。
It is conceivable and legal that differing window values might be
announced. However, it is not permitted for one system to use
modulo 8 sequencing and the other to use modulo 128. Therefore,
the rule is: a Configure-Nak may reduce the window but may not
increase it.
異なった窓の値が発表されるのは、想像できて法的です。 しかしながら、それは1台のシステムが法128を使用するのに法8配列ともう片方を使用することが許可されていません。 したがって、規則は以下の通りです。 Configure-Nakは窓を減少させますが、それを増強しないかもしれません。
Address
アドレス
An HDLC Address as specified in ISO 3309. ISO 7776 specifies four
of the possible values: 1 and 3 for single link operation, 7 and
15 for the Multi-Link Procedure. Other values consistent with ISO
3309 are considered legal.
ISO3309の指定されるとしてのHDLC Address。 ISO7776は4つの可能な値を指定します: シングルのための1と3はMulti-リンクProcedureに操作、7、および15をリンクします。 ISO3309と一致した他の値は法的であると考えられます。
Implementation of the Multi-Link Procedure is optional; A
Multi-リンクProcedureの実装は任意です。 A
Configure-Nak may therefore force a change from MLP to single link
mode, but not the reverse.
Nakを構成する、したがって、MLPからただ一つの逆ではなく、リンクモードまでの変化を強制するかもしれません。
Should the address be zero upon receipt, the receiver MUST
Configure-Nak with an appropriate address. If both peers send
address zero, the system advertising the numerically smaller
window will select the smaller address. If both windows are the
same size, a random choice MUST be made; when good sources of
randomness are used, the link will converge in a reasonable time.
アドレスが領収書のゼロであるなら、受信機は適切なアドレスがあるConfigure-Nakをゼロに合わせなければなりません。 両方の同輩がゼロをアドレスに送ると、数の上でより小さい窓の広告を出すシステムは、より小さいアドレスを選択するでしょう。 両方の窓が同じサイズであるなら、無作為の選択をしなければなりません。 偶発性の良い源が使用されているとき、リンクは妥当な時間で一点に集まるでしょう。
Rand [Page 4] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[4ページ]RFC1663ppp
If magic numbers have been negotiated on the link, the system with
the numerically smaller magic number SHOULD specify the smaller
address.
マジックナンバーに関して交渉されたなら、リンク、数の上でよりわずかなマジックナンバーSHOULDがあるシステムは、より小さいアドレスを指定します。
5. Numbered-Mode Operation
5. 番号付のモード操作
When using the Numbered-Mode, each link is established in the usual manner for the type of link. The Numbered-Mode Configuration Option is negotiated, the Magic-Number Configuration Option MUST also be negotiated, and the Address-and-Control-Field-Compression Configuration Option MUST NOT be negotiated.
Numbered-モードを使用するとき、各リンクは常法でリンクのタイプのために設立されます。 Numbered-モードConfiguration Optionを交渉します、そして、また、マジック数のConfiguration Optionを交渉しなければなりません、そして、Addressとコントロールが圧縮をさばいているConfiguration Optionは交渉してはいけません。
Following the successful negotiation of the Numbered-Mode Configuration Option during LCP Link Establishment phase, the system with the numerically smaller Magic-Number will send a SABM or SABM(E), and the other will respond with a UA. In the event that either the SABM or UA is lost, this exchange may be repeated according to the same parameters as the configuration exchange itself, using the Restart Timer and counter values. Authentication, Link Quality Determination, and NCP Configuration follow this step.
LCP Link特権階級段階の間、Numbered-モードConfiguration Optionのうまくいっている交渉に続いて、数の上でより少ないマジック数があるシステムはSABMかSABM(E)を送るでしょう、そして、もう片方がUAと共に応じるでしょう。 SABMかUAのどちらかが無くなる場合、構成交換自体と同じパラメタによると、この交換は繰り返されるかもしれません、Restart Timerと対価を使用して。 認証、Link Quality Determination、およびNCP Configurationはこの方法に従います。
Once the link has been established with Numbered-Mode, when re- negotiation of link configuration occurs, the entire re-negotiation MUST be conducted in Numbered-Mode. If the Numbered-Mode Configuration Option is not successfully re-negotiated, the link reverts to Unnumbered-Information operation prior to Authentication, Link Quality Determination, and NCP Configuration.
リンク構成の再交渉が起こるとき、リンクがNumbered-モードでいったん設立されると、Numbered-モードで全体の再交渉を行わなければなりません。 Numbered-モードConfiguration Optionが首尾よく再交渉されないなら、リンクはAuthentication、Link Quality Determination、およびNCP Configurationの前でUnnumbered-情報操作に戻ります。
When an implementation which is capable of Numbered-Mode, and is not currently configured for Numbered-Mode operation, detects a frame which has a correct FCS but does not have a UI Control octet, the implementation MUST send a DM message, immediately followed by a LCP Configure-Request.
Numbered-モードができて、現在Numbered-モード操作のために構成されない実装が正しいFCSを持っているフレームを検出しますが、UI Control八重奏を持っていないとき、実装はDMメッセージを送らなければなりません、すぐに、続いてLCP Configure-要求を送ります。
When an implementation which is currently configured for Numbered- Mode operation receives a DM message, it MUST revert to Unnumbered- Information operation, and immediately send a LCP Configure-Request.
現在Numberedモード操作のために構成される実装がすぐにDMメッセージを受け取るとき、それは、Unnumbered情報操作に戻って、LCP Configure-要求を送らなければなりません。
5.1. Single Link
5.1. 単一のリンク
When Network-Layer packets are sent over a single link, the packets are encapsulated in the following order:
Network-層のパケットを単一のリンクの上に送るとき、以下のオーダーでパケットをカプセルに入れります:
+----------+ +----------+ +----------+
| | | | | Numbered |
| Header |-->| Data |-->| Mode |--> link
| Compress | | Compress | | Header |
+----------+ +----------+ +----------+
+----------+ +----------+ +----------+ | | | | | 付番されます。| | ヘッダー| -->、| データ| -->、| モード|-->リンク| 湿布| | 湿布| | ヘッダー| +----------+ +----------+ +----------+
Rand [Page 5] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[5ページ]RFC1663ppp
5.2. Inverse Multiplexing
5.2. 逆さのマルチプレクシング
Since sending several connections over a single link is often called "multiplexing", sending packets from a single connection over multiple parallel links is sometimes called "inverse-multiplexing". By default, PPP performs no special processing for such links. Each link is established and terminated independently, negotiates its own configuration options, and may have different combinations of such options as ACCM, Protocol Field Compression and IP-Address. This facilitates using the links simultaneously over dissimilar media, such as 56K sync with async backup.
単一のリンクの上にいくつかの接続を送るのがしばしば「マルチプレクシング」と呼ばれるので、複数の平行なリンクの上の単独結合からパケットを送るのは時々「逆さのマルチプレクシング」であると呼ばれます。 デフォルトで、PPPはそのようなリンクのためのどんな特別な処理も実行しません。 各リンクは、独自に設立されて、終えられて、それ自身の設定オプションを交渉して、ACCM、プロトコルField Compression、およびIP-アドレスのようなオプションの異なった組み合わせを持っているかもしれません。 これは、56Kの同時性などの異なったメディアの上でasyncバックアップで同時にリンクを使用するのを容易にします。
Every link in a single machine MUST have different Magic Numbers, and each end of every link between two peers SHOULD have Magic Numbers which are unique to those peers. This protects against patch-panel errors in addition to looped-back links.
単一マシンのあらゆるリンクには、異なったマジック民数記がなければなりません、そして、各端のときに、2人の同輩の間のあらゆるリンクでは、SHOULDはマジック民数記を持っています(それらの同輩にユニークです)。 これは輪にされて逆リンクに加えてパッチ盤誤りから守ります。
The distribution to each link is controlled by higher level routing mechanisms. When Network-Layer specific compression techniques (such as Van Jacobsen Compression) rely on sequential delivery, without Multi-Link Procedure support such compression MUST be applied on a link by link basis.
それぞれリンクする分配は、より高い平らなルーティングメカニズムによって制御されます。Network-層の特定の圧縮のテクニック(ヴァンジェイコブセンCompressionなどの)が連続した配送に依存すると、Multi-リンクProcedureサポートがなければ、そのような圧縮をリンクにリンク基礎で付けなければなりません。
+----------+ +----------+ +----------+
| | | | | Numbered |
+--->| Header |-->| Data |-->| Mode |--> link 1
| | Compress | | Compress | | Header |
+--------------+ +----------+ +----------+ +----------+
| Distribution |
+--------------+ +----------+ +----------+ +----------+
| | | | | | Numbered |
+--->| Header |-->| Data |-->| Mode |--> link 2
| Compress | | Compress | | Header |
+----------+ +----------+ +----------+
+----------+ +----------+ +----------+ | | | | | 付番されます。| +--->| ヘッダー| -->、| データ| -->、| モード|-->リンク1| | 湿布| | 湿布| | ヘッダー| +--------------+ +----------+ +----------+ +----------+ | 分配| +--------------+ +----------+ +----------+ +----------+ | | | | | | 付番されます。| +--->| ヘッダー| -->、| データ| -->、| モード|-->リンク2| 湿布| | 湿布| | ヘッダー| +----------+ +----------+ +----------+
5.3. Using Multi-Link Procedure
5.3. マルチリンク手順を用います。
This document does not offer a standard for ISO Multi-Link, but does offer a method for agreeing on the addressing scheme usable with Multi-Link. A sample implementation is shown below. Implementation of Multi-Link is not required.
このドキュメントは、ISO Multi-リンクのために規格を提供しませんが、Multi-リンクで使用可能なアドレシング体系に同意するためにメソッドを提供します。 サンプル実装は以下に示されます。 Multi-リンクの実装は必要ではありません。
When using the ISO 7776 Multi-Link Procedure, each link is established as described above. In addition, the Numbered-Mode Configuration Option is negotiated with appropriate addresses for the Multi-Link Procedure. The distribution to each link is controlled by the Multi-Link Procedure, as is the recovery of sequence in the receiving system.
ISO7776Multi-リンクProcedureを使用するとき、各リンクは上で説明されるように設立されます。 さらに、Numbered-モードConfiguration OptionはMulti-リンクProcedureへの適切なアドレスと交渉されます。 それぞれリンクする分配はMulti-リンクProcedureによって制御されます、受電方式における、系列の回復のように。
Rand [Page 6] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[6ページ]RFC1663ppp
+---> link 1
+----------+ +----------+ +----------+ |
| | | | | Multi | +--------------+
| Header |-->| Data |-->| Link |-->| Distribution |
| Compress | | Compress | | Procedure| +--------------+
+----------+ +----------+ +----------+ |
+---> link 2
+--->リンク1+----------+ +----------+ +----------+ | | | | | | マルチ| +--------------+ | ヘッダー| -->、| データ| -->、| リンク| -->、| 分配| | 湿布| | 湿布| | 手順| +--------------+ +----------+ +----------+ +----------+ | +--->リンク2
5.4. LAPB Parameter defaults
5.4. LAPB Parameterはデフォルトとします。
The following guidelines specify the default values of LAPB configurable parameters.
以下のガイドラインはLAPBの構成可能なパラメタのデフォルト値を指定します。
Timer T1
タイマT1
Timer T1 is the maximum time permitted before a retransmission
is started, as a result of no response to a transmitted I
frame. This value must be greater than the time required for a
maximum sized frame to be received by the other side of the
link, and for a response to be generated for the frame. This
SHOULD be determined dynamically, based on the measured round
trip time delay of the link at the LAPB level. In the event
that the system cannot determine the round trip time of the
link, this value SHOULD be set to twice the bit rate of the
link, divided by the maximum number of bits per frame, plus 100
milliseconds processing time. For example, on a 14,400 bps
link, with a maximum frame size of 8000 bits (1000 octects),
the T1 value would be set to 3.7 seconds.
タイマT1は「再-トランスミッション」が始動される前に受入れられた最大の時間です、伝えられたIフレームへの応答の結果、ではなく。 この値は、リンクの反対側で最大の大きさで分けられたフレームを受け取って、フレームに応答を生成するために時間が必要であるというよりも大きくなければなりません。 このSHOULDがダイナミックに決定して、測定に基づいてLAPBレベルでリンクの旅行時間遅れを一周させてください。 1フレームあたりのビットの最大数が割られたリンクのビット伝送速度の2倍へのセットと100ミリセカンドが処理時間であり、システムがラウンドを決定できないなら、リンクの時間、この値のSHOULDをつまずかせてください。 例えば、1万4400ビーピーエスリンクの上では、最大8000ビット(1000octects)のフレーム・サイズで、T1値は3.7秒に設定されるでしょう。
Timer T3
タイマT3
Timer T3 gives an indication of the idle state of the link.
Its value must be greater than the T1 value.
タイマT3はリンクの活動していない状態のしるしを与えます。 値はT1値より大きいに違いありません。
Maximum number of attempts to complete a transmission, N2
トランスミッション、N2を完成する最大数の試み
Parameter N2 gives the maximum number of retransmission
attempts for a given frame. If this value is exceeded, the
link SHOULD be terminated. The default value for parameter N2
SHOULD be 3.
パラメタN2は与えられたフレームのための「再-トランスミッション」試みの最大数を与えます。 値はこれであるなら超えられて、リンクはSHOULDです。終えられます。 デフォルトはパラメタのためにN2 SHOULDを評価します。3になってください。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Rand [Page 7] RFC 1663 PPP Reliable Transmission July 1994
トランスミッション1994年7月に信頼できる底ならし革[7ページ]RFC1663ppp
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, Daydreamer, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
[2] ISO 7776, Information Processing Systems - Data Communication -
High Level Data Link Control Procedures - Description of the X.25
LAPB-Compatible DTE Data Link Procedures
[2] ISO7776、情報処理システム--データ通信--ハイレベル・データ・リンク制御手順--X.25 LAPBコンパチブルDTEデータ・リンク手順の記述
[3] Simpson, W., Editor, "PPP in HDLC Framing", STD 51, RFC 1662,
Daydreamer, July 1994.
[3] シンプソン、W.、エディタ、「HDLC縁どりにおけるppp」、STD51、RFC1662、空想家、1994年7月。
[4] Sklower, K., "PPP MultiLink Procedure", Work in Progress.
[4] K.、「pppマルチリンク手順」というSklowerは進行中で働いています。
Acknowledgments
承認
Fred Baker was the original author of this document.
フレッド・ベイカーはこのドキュメントの原作者でした。
Bill Simpson contributed materially to the document.
ビル・シンプソンは物質的にドキュメントに貢献しました。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117
フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollay Driveサンタバーバラ、カリフォルニア 93117
EMail: fbaker@acc.com
メール: fbaker@acc.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Dave Rand 2180 Fortune Drive San Jose, CA 95131
Driveサンノゼ、デーヴRand2180のFortuneカリフォルニア 95131
Phone: +1 408 321-1259 EMail: dave_rand@novell.com
以下に電話をしてください。 +1 408 321-1259 メールしてください: dave_rand@novell.com
Rand [Page 8]
底ならし革[8ページ]
一覧
スポンサーリンク
