RFC1008 日本語訳
1008 Implementation guide for the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT=204664 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Wayne McCoy Request for Comments: 1008 June 1987
コメントを求めるワーキンググループウェインマッコイRequestをネットワークでつないでください: 1008 1987年6月
IMPLEMENTATION GUIDE
実現ガイド
FOR THE
THE
ISO TRANSPORT PROTOCOL
ISOトランスポート・プロトコル
Status of this Memo
このMemoの状態
This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors. Distribution of this memo is unlimited.
このRFCは、Implementorsガイドのコメントに請求するためにインターネットコミュニティのメンバーに分配されています。 このドキュメントが直接インターネットの研究課題に関連していないかもしれない間、それは多くの研究者と作成者にいくつかおもしろいかもしれません。 このメモの分配は無制限です。
IMPLEMENTATION GUIDE FOR THE ISO TRANSPORT PROTOCOL
ISOトランスポート・プロトコルのための実現ガイド
1 Interpretation of formal description.
1 形式的記述の解釈。
It is assumed that the reader is familiar with both the formal description technique, Estelle [ISO85a], and the transport protocol as described in IS 8073 [ISO84a] and in N3756 [ISO85b].
読者が形式的記述のテクニック、エステル[ISO85a]、および輸送が説明されるとして議定書を作る両方になじみ深いのが、[ISO84a]とN3756[ISO85b]の8073であるということであると思われます。
1.1 General interpretation guide.
1.1の一般解釈ガイド。
The development of the formal description of the ISO Transport Protocol was guided by the three following assumptions.
ISO Transportプロトコルの形式的記述の開発は3時までに仮定に続くのが誘導されました。
1. A generality principle
1. 一般性原則
The formal description is intended to express all of the behavior that any implementation is to demonstrate, while not being bound to the way that any particular implementation would realize that behavior within its operating context.
どんな特定の実現も操作文脈の中でその振舞いがわかる方法に縛られていない間、形式的記述がどんな実現も示すことになっている振舞いのすべてを言い表すことを意図します。
2. Preservation of the deliberate
nondeterminism of IS 8073
2. 慎重な「非-決定論」の保存、8073です。
The text description in the IS 8073 contains deliberate expressions of nondeterminism and indeterminism in the behavior of the transport protocol for the sake of flexibility in application. (Nondeterminism in this context means that the order of execution for a set of actions that can be taken is not specified. Indeterminism means that the execution of a given action cannot be predicted on the basis of system state or the executions of other actions.)
中のテキスト記述、8073 アプリケーションにおける柔軟性のためにトランスポート・プロトコルの振舞いにおける「非-決定論」と非決定論の慎重な表現を含んでいます。 (Nondeterminismは、取ることができる1セットの行動のための執行命令が指定されないことをこのような関係においては意味します。 非決定論は、他の動作のシステム状態か実行に基づいて与えられた動作の実行を予測できないことを意味します。)
McCoy [Page 1] RFC 1008 June 1987
マッコイ[1ページ]RFC1008 1987年6月
3. Discipline in the usage of Estelle
3. エステルの使用法による規律
A given feature of Estelle was to be used only if the nature of the mechanism to be described strongly indicates its usage, or to adhere to the generality principle, or to retain the nondeterminism of IS 8073.
エステルの当然のことの機能が強く説明されるべきメカニズムの本質が用法を示す場合にだけ使用されるか、一般性原則を固く守るか、または「非-決定論」を保有することであった、8073です。
Implementation efficiency was not a particular goal nor was there an attempt to directly correlate Estelle mechanisms and features to implementation mechanisms and features. Thus, the description does not represent optimal behavior for the implemented protocol.
実現効率は特定の目標ではありませんでした、そして、実現メカニズムと特徴にエステルメカニズムと特徴を直接関連させる試みがありませんでした。 したがって、記述は実行されたプロトコルのための最適の振舞いを表しません。
These assumptions imply that the formal description contains higher levels of abstraction than would be expected in a description for a particular operating environment. Such abstraction is essential, because of the diversity of networks and network elements by which implementation and design decisions are influenced. Even when operating environments are essentially identical, design choice and originality in solving a technical problem must be allowed. The same behavior may be expressed in many different ways. The goal in producing the transport formal description was to attempt to capture this equivalence. Some mechanisms of transport are not fully described or appear to be overly complicated because of the adherence to the generality principle. Resolution of these situations may require significant effort on the part of the implementor.
これらの仮定は、形式的記述が特定の操作環境のための記述で予想されるだろうより高いレベルの抽象化を含むのを含意します。 そのような抽象化はネットワークとネットワーク要素の多様性のためにどの実現で不可欠であるか、そして、デザイン決定は影響を及ぼされます。 操作環境が本質的には同じであるときにさえ、技術的問題を解決することにおけるデザイン選択と独創性を許容しなければなりません。 同じ振舞いは多くの異なった方法で示されるかもしれません。 輸送形式的記述を起こすことにおける目標はこの等価性を得るのを試みることでした。 輸送のいくつかのメカニズムが、完全に説明されるというわけではありませんし、一般性原則への固守のためにひどく複雑であるように見えもします。 これらの状況の決議は作成者側の重要な努力を必要とするかもしれません。
Since the description does not represent optimal behavior for the implemented protocol, implementors should take the three assumptions above into account when using the description to implement the protocol. It may be advisable to adapt the standard description in such a way that:
記述が実行されたプロトコルのための最適の振舞いを表さないので、プロトコルを実行するのに記述を使用するとき、作成者は上で3つの仮定を考慮に入れるべきです。 以下のことのような方法で標準の記述を適合させるのは賢明であるかもしれません。
a. abstractions (such as modules, channels, spontaneous
transitions and binding comments) are interpreted and realized
as mechanisms appropriate to the operating environment and
service requirements;
a. メカニズムが操作環境とサービスに要件を当てるのに従って、抽象化(モジュールや、チャンネルや、自然発生的な変遷や拘束力があるコメントなどの)は、解釈されて、実現されます。
b. modules, transitions, functions and procedures containing
material irrelevant to the classes or options to be supported
are reduced or eliminated as needed; and
b. モジュールか変遷か機能とクラスと無関係の材料を含む手順か支持されるべきオプションが、必要に応じて抑えられるか、または省かれます。 そして
c. desired real-time behavior is accounted for.
c. 必要なリアルタイムの振舞いは説明されます。
The use in the formal description of an Estelle feature (for instance, "process"), does not imply that an implementation must necessarily realize the feature by a synonymous feature of the operating context. Thus, a module declared to be a "process" in an Estelle description need not represent a real process as seen by a host operating system; "process" in Estelle refers to the
エステルの形式的記述における使用は、(例えば、「過程」)を特集して、実現が必ず操作文脈の同義の特徴で特徴がわからなければならないのを含意しません。 したがって、モジュールは、エステル記述における「過程」であることがホスト・オペレーティング・システムによって見られるように本当の過程を表す必要はないと宣言しました。 エステルの「過程」は示します。
McCoy [Page 2] RFC 1008 June 1987
マッコイ[2ページ]RFC1008 1987年6月
synchronization properties of a set of procedures (transitions).
1セットの手順(変遷)の同期の特性。
Realizations of Estelle features and mechanisms are dependent in an essential way upon the performance and service an implementation is to provide. Implementations for operational usage have much more stringent requirements for optimal behavior and robustness than do implementations used for simulated operation (e.g., correctness or conformance testing). It is thus important that an operational implementation realize the abstract features and mechanisms of a formal description in an efficient and effective manner.
エステルの特徴とメカニズムの実現は不可欠の方法で実現が提供することになっている性能とサービスに依存しています。 操作上の用法のための実現には、最適の振舞いと丈夫さのためのシミュレートされた操作(例えば、正当性か順応テスト)に使用される実現をするよりはるかに厳しい要件があります。 その結果、操作上の実現が効率的で効果的な方法で形式的記述の抽象的な特徴とメカニズムがわかるのは、重要です。
For operational usage, two useful criteria for interpretation of formal mechanisms are:
操作上の用法のために、正式なメカニズムの解釈の2つの役に立つ評価基準は以下の通りです。
[1] minimization of delays caused by the mechanism
itself; e.g.,
[1] メカニズム自体によって引き起こされた遅れの最小化。 例えば
--transit delay for a medium that realizes a
channel
--チャンネルがわかる媒体のためのトランジット遅れ
--access delay or latency for channel medium
--チャンネル媒体のためのアクセス遅延か潜在
--scheduling delay for timed transitions
(spontaneous transitions with delay clause)
--調節された変遷のために遅れの計画をします。(支払猶予条項による自然発生的な変遷)
--execution scheduling for modules using
exported variables (delay in accessing
variable)
--輸出された変数を使用するモジュールのための実行スケジューリング(変数にアクセスする遅れ)
[2] minimization of the "handling" required by each
invocation of the mechanism; e.g.,
[2] 「取り扱い」の最小化がメカニズムの各実施が必要です。 例えば
--module execution scheduling and context
switching
--モジュール実行スケジューリングとコンテキストスイッチ
--synchronization or protocols for realized
channel
--実感されたチャンネルのための同期かプロトコル
--predicate evaluation for spontaneous
transitions
--自然発生的な変遷のための述部評価
Spontaneous transitions represent nondeterminism and indeterminism, so that uniform realization of them in an implementation must be questioned as an implementation strategy. The time at which the action described by a spontaneous transition will actually take place cannot be specified because of one or more of the following situations:
自然発生的な変遷は「非-決定論」と非決定論を表します、実現戦略として実現における、それらの一定の実現に質問しなければならないように。 以下の状況の1つ以上のために、自然発生的な変遷で説明された動作が実際に行われる時を指定できません:
a. it is not known when, relative to any specific event defining
the protocol (e.g., input network, input from user, timer
a.、プロトコルを定義するどんな特定の出来事に比例していつかを知らない、(例えば、ネットワークを入力してください、ユーザからの入力、タイマ
McCoy [Page 3] RFC 1008 June 1987
マッコイ[3ページ]RFC1008 1987年6月
expirations), the conditions enabling the transition will
actually occur;
満期)、変遷を可能にする状態は実際に現れるでしょう。
b. even if the enabling conditions are ultimately deterministic,
it is not practical to describe all the possible ways this
could occur, given the different ways in which implementations
will examine these conditions; and
b. 可能な状態が結局決定論的であっても、これが起こることができたすべての可能な方法を述べるのは実用的ではありません、実現がこれらの状態を調べる異なった方法を考えて。 そして
c. a particular implementation may not be concerned with the
enabling conditions or will account for them in some other
way; i.e., it is irrelevant when the action takes place, if
ever.
c. 特定の実現は、可能な状態に関係がないかもしれないか、またはある他の方法でそれらの原因になるでしょう。 動作が行われるとき、かつてなら、すなわち、無関係です。
As an example of a), consider the situation when splitting over the network connection, in Class 4, in which all of the network connections to which the transport connection has been assigned have all disconnected, with the transport connection still in the OPEN state. There is no way to predict when this will happen, nor is there any specific event signalling its occurrence. When it does occur, the transport protocol machine may want to attempt to obtain a new network connection.
ネットワーク接続の上で分かれるときにはa)に関する例と、状況を考えてください、Class4で、まだオープン状態での輸送接続と共に。((そこでは、連絡を断ちました)輸送接続が選任されたネットワーク接続皆、皆、)。 いつ、これが起こって、何か発生に合図する特定の出来事がないかを予測する方法が全くありません。 起こると、トランスポート・プロトコルマシンは、新しいネットワーク接続を得るのを試みたがっているかもしれません。
As an example of b), consider that timers may be expressed succinctly in Estelle by transitions similar to the following:
b)に関する例として、タイマがエステルで以下と同様の変遷で簡潔に急送されるかもしれないと考えてください:
from A to B
provided predicate delay( timer_interval )
Aから提供されたB述部遅れまで(タイマ_間隔)
begin
(* action driven by timeout *)
end;
終わりを始めてください(タイムアウト*によって追い立てられた*動作)。
But there are operations for which the timer period may need to be very accurate (close to real time) and others in which some delay in executing the action can be tolerated. The implementor must determine the optimal behavior desired for each instance and use an appropriate mechanism to realize it, rather than using a uniform approach to implementing all spontaneous transitions.
しかし、タイマの期間が非常に正確である(リアルタイムで近くの)必要があるかもしれない操作と動作を実行する何らかの遅れを許容できる他のものがいます。 作成者は、すべての自然発生的な変遷を実行することへの一定のアプローチを使用するよりむしろそれがわかるのに各例のために望まれていた最適の振舞いを決定して、適切な手段を使用しなければなりません。
As an example of the situation in c), consider the closing of an unused network connection. If the network is such that the cost of letting the network connection remain open is small compared cost of opening it, then an implementation might not want to consider closing the network connection until, say, the weekend. Another implementation might decide to close the network connection within 30 msec after discovering that the connection is not busy. For still another implementation, this could be
c)の状況に関する例と、未使用のネットワーク接続の閉鎖を考えてください。 ネットワーク接続を開いたままで残らせる費用がネットワークがそのようなものであるのでそれを開くわずかな比較された費用であるなら、実現は、たとえば、週末までネットワーク接続を終えると考えたがっていないかもしれません。 別の実現は、接続が忙しくないと発見した後に30msecの中でネットワーク接続を終えると決めるかもしれません。 まだ別の実現のために、これはそうであるかもしれません。
McCoy [Page 4] RFC 1008 June 1987
マッコイ[4ページ]RFC1008 1987年6月
meaningless because it operates over a connectionless network service.
コネクションレスなネットワーク・サービスの上で作動するので、無意味です。
If a description has only a very few spontaneous transitions, then it may be relatively easy to implement them literally (i.e., to schedule and execute them as Estelle abstractly does) and not incur the overhead from examining all of the variables that occur in the enabling conditions. However, the number and complexity of the enabling conditions for spontaneous transitions in the transport description strongly suggests that an implementation which realizes spontaneous transitions literally will suffer badly from such overhead.
記述にほんのわずかな自然発生的な変遷しかないなら、文字通り(すなわち、それらは、エステルとして計画をして、抽象的に実行される)それらを実行して、可能な状態で起こる変数のすべてを調べるのでオーバーヘッドを被らないのは比較的簡単であるかもしれません。 しかしながら、輸送記述における自然発生的な変遷のための可能な状態の数と複雑さは、自然発生的な変遷がわかる実現が文字通りひどくそのようなオーバーヘッドに苦しむのを強く示します。
1.2 Guide to the formal description.
1.2 形式的記述に誘導します。
So that implementors gain insight into interpretation of the mechanisms and features of the formal description of transport, the following paragraphs discuss the meanings of such mechanisms and features as intended by the editors of the formal description.
作成者が洞察を獲得するように、メカニズムの解釈と輸送の形式的記述の特徴、以下のパラグラフと、形式的記述のエディタによる意図されるようなメカニズムと特徴の意味について議論してください。
1.2.1 Transport Protocol Entity.
1.2.1 プロトコル実体を輸送してください。
1.2.1.1 Structure.
1.2.1.1 構造。
The diagram below shows the general structure of the Transport Protocol Entity (TPE) module, as given in the formal description. >From an abstract operational viewpoint, the transport protocol Machines (TPMs) and the Slaves operate as child processes of the the TPE process. Each TPM represents the endpoint actions of the protocol on a single transport connection. The Slave represents control of data output to the network. The internal operations of the TPMs and the Slave are discussed below in separate sections.
以下のダイヤグラムは形式的記述で与えるようにTransportプロトコルEntity(TPE)モジュールの一般構造体を示しています。 TPEの子プロセスが処理されるとき、抽象的な操作上の観点からの>、トランスポート・プロトコルMachines(TPMs)、およびSlavesは作動します。 各TPMは単独の輸送接続へのプロトコルの終点動作を表します。 Slaveはデータ出力のコントロールをネットワークに表します。 以下で別々のセクションでTPMsとSlaveの社内業務について議論します。
This structure permits describing multiple connections, multiplexing and splitting on network connections, dynamic existence of endpoints and class negotiation. In the diagram, interaction points are denoted by the symbol "O", while (Estelle) channels joining these interaction points are denoted by
ネットワーク接続、終点とクラス交渉のダイナミックな存在で多重送信して、分かれて、この構造は、複数の接続について説明するのを可能にします。 ダイヤグラムで、相互作用ポイントはシンボル「O」によって指示されます、(エステル)はこれらの相互作用ポイントが指示される接合にチャネルを開設しますが
McCoy [Page 5] RFC 1008 June 1987
マッコイ[5ページ]RFC1008 1987年6月
*
*
*
* * *
The symbol "X" represents a logical association through variables, and the denotations
シンボル「X」は変数、および表示を通して論理的な協会を代表します。
<<<<<<<
<<<<<<<。
>>>>>>>
>>>>>>>。
V
V
V
V V V
indicate the passage of data, in the direction of the symbol vertices, by way of these associations. The acronyms TSAP and NSAP denote Transport Service Access Point and Network Service Access Point, respectively. The structure of the TSAPs and NSAPs shown is discussed further on, in Parts 1.2.2.1 and 1.2.2.2.
シンボル頭頂の向きにこれらの協会を通してデータの節を示してください。 頭文字語のTSAPとNSAPはそれぞれTransport Service Access PointとNetwork Service Access Pointを指示します。 そして、さらに見せられたTSAPsとNSAPsの構造について議論する、Parts1.2.2でオンである、.1、1.2 .2 .2。
|<-----------------TSAP---------------->|
----------O---------O---------O---------O---------O---------
| TPE * * * |
| * * * |
| ____O____ ____O____ ____O____ |
| | | | | | | |
| | TPM | | TPM | | TPM | |
| | | | | | | |
| |___X___| |__X_X__| |___X___| |
| V V V V |
| V multiplex V V V |
| >>>>>>>> <<<<<<<<<<< V V |
| V V split V V |
| V V V V |
| ---X---- ---X---- ---X---- |
| |Slave | |Slave | |Slave | |
| |__O___| |__O___| |__O___| |
| V V V |
| V V V |
|-----------------O------------O--------O------------------|
NSAP |<------>|
| <。-----------------TSAP---------------->| ----------O---------O---------O---------O---------O--------- | TPE***| | * * * | | ____O____ ____O____ ____O____ | | | | | | | | | | | TPM| | TPM| | TPM| | | | | | | | | | | |___X___| |__X_X__| |___X___| | | V V V V| | V多重V V V| | >>>>>>>><<<<<<<<<<<V V| | V VはV Vを分けました。| | V V V V| | ---X---- ---X---- ---X---- | | |奴隷| |奴隷| |奴隷| | | |__O___| |__O___| |__O___| | | V V V| | V V V| |-----------------O------------O--------O------------------| NSAP| <、-、-、-、-、--、>|
NSAP
NSAP
McCoy [Page 6] RFC 1008 June 1987
マッコイ[6ページ]RFC1008 1987年6月
The structuring principles of Estelle provide a formal means of
expressing and enforcing certain synchronization properties between
communicating processes. It must be stressed that the scheduling
implied by Estelle descriptions need not and in some cases should
not be implemented. The intent of the structure in the transport
formal description is to state formally the synchronization of
access tovariables shared by the transport entity and the transport
connection endpoints and to permit expression of dynamic objects
within the entity. In nearly all aspects of operation except these,
it may be more efficient in some implementation environments to
permit the TPE and the TPMs to run in parallel (the Estelle
scheduling specifically excludes the parallel operation of the TPE
and the TPMs). This is particularly true of internal management
("housekeeping") actions and those actions not directly related to
communication between the TPE and the TPMs or instantiation of TPMs.
Typical actions of this latter sort are: receipt of NSDUs from the
network, integrity checking and decoding of TPDUs, and network
connection management. Such actions could have been collected into
other modules for scheduling closer to that of an implementation,
but surely at the risk of further complicating the description.
Consequently, the formal description structure should be understood
as expressing relationships among actions and objects and not
explicit implementation behavior.
プロセスを伝えることの間にエステルの構造原則はある同期の特性を示して、実施する正式な手段を提供します。 スケジューリングがエステル記述がそうする必要はないのを含意して、いくつかの場合、実装されるべきでないと強調しなければなりません。 輸送形式的記述における構造の意図は、アクセスtovariablesの同期が輸送実体と輸送接続終点のそばで共有されたと正式に述べて、実体の中でダイナミックなオブジェクトの式を許可することです。 ほとんどこれらを除いた操作の全面では、TPEとTPMsが平行に立候補することを許可するいくつかの実装環境でそれは、より効率的であるかもしれません(エステルスケジューリングは明確にTPEとTPMsの並列操作を除きます)。 これはTPMsのTPEとTPMsか具体化の間で内部経営(「家事」)動作と直接コミュニケーションに関連しないそれらの動作に関して特に本当です。この後者の種類の典型的な動きは以下の通りです。 ネットワークからのNSDUsの受領、TPDUsをチェックして、解読する保全、およびネットワーク接続経営者側。 そのような動作は実装のものの、より近くで計画となっていますが、確実にさらに記述を複雑にするリスクにおいて他のモジュールに集められたかもしれません。 その結果、形式的記述構造は明白な実装の振舞いではなく、動作とオブジェクトの中で関係を言い表すとして理解されるべきです。
1.2.1.2 Transport protocol entity operation.
1.2.1.2 プロトコル実体操作を輸送してください。
The details of the operation of the TPE from a conceptual point of view are given in the SYS section of the formal description. However, there are several further comments that can be made regarding the design of the TPE. The Estelle body for the TPE module has no state variable. This means that any transition of the TPE may be enabled and executed at any time. Choice of transition is determined primarily by priority. This suggests that the semantics of the TPE transitions is that of interrupt traps.
概念的な観点からのTPEの操作の詳細は形式的記述のSYS部で明らかにされます。 しかしながら、TPEのデザインに関してすることができるさらなるいくつかのコメントがあります。 TPEモジュールのためのエステルボディーで、状態は全く可変になりません。 これは、TPEのどんな変遷もいつでも可能にされて、実行されるかもしれないことを意味します。 変遷の選択は主として優先的に決定しています。 これは、TPE変遷の意味論が割り込みトラップのものであると示唆します。
The TPE handles only the T-CONNECT-request from the user and the TPM handle all other user input. All network events are handled by the TPE, in addition to resource management to the extent defined in the description. The TPE also manages all aspects of connection references, including reference freezing. The TPE does not explicitly manage the CPU resource for the TPMs, since this is implied by the Estelle scheduling across the module hierarchy. Instantiation of TPMs is also the responsibility of the TPE, as is TPM release when the transport connection is to be closed. Once a TPM is created, the TPE does not in general interfere with TPM's activities, with the following exceptions: the TPE may reduce credit to a Class 4 TPM without notice; the TPE may dissociate a Class 4 TPM from a network connection when splitting is being used. Communication between the TPE and the TPMs is through a set of exported variables owned by the TPMs, and through a channel which
TPEはユーザからのT-CONNECT-要求だけを扱います、そして、TPMは他のすべてのユーザ入力を扱います。 すべてのネットワークイベントが記述で定義された範囲への資源管理に加えてTPEによって扱われます。 また、TPEは参照冷凍を含む接続参照の全面を管理します。 TPEは明らかにTPMsのためのCPUリソースを管理しません、これがモジュール階層構造の向こう側にエステルスケジューリングによって含意されるので。 また、TPMsの具体化はTPEの責任です、輸送接続が閉店していることになっているときのTPMリリースのように。 TPMがいったん作成されると、一般に、TPEは以下の例外でTPMの活動を妨げません: TPEは予告なしでクレジットをClass4TPMに変えるかもしれません。 分かれるのが使用していることにされるのであるとき、TPEはネットワーク接続からClass4TPMを離すかもしれません。 TPEとTPMsとのコミュニケーションはエクスポートされることのセットを通して、変数がTPMsと、チャンネルを通してどれを所有していたかということです。
McCoy [Page 7] RFC 1008 June 1987
マッコイ[7ページ]RFC1008 1987年6月
passes TPDUs to be transmitted to the remote peer. This channel is not directly connected to any network connection, so each interaction on it carries a reference number indicating which network connection is to be used. Since the reference is only a reference, this permits usage of this mechanism when the network service is connectionless, as well. The mechanism provides flexibility for both splitting and multiplexing on network connections.
リモート同輩に伝えられるためにTPDUsを渡します。 このチャンネルが直接どんなネットワーク接続にも接続されないので、それにおける各相互作用は使用されるためにネットワーク接続がどれであるかを示す参照番号を運びます。 ネットワーク・サービスもまた、コネクションレスであるときに、参照が参照にすぎないことで、これはこのメカニズムの使用法を可能にします。 メカニズムは分かれるのとネットワーク接続のときに多重送信する両方に柔軟性を提供します。
One major function that the TPE performs for all its TPMs is that of initial processing of received TPDUs. First, a set of integrity checks is made to determine if each TPDU in an NSDU is decodable:
TPEがすべてのTPMsのために実行する1つの主要な機能が容認されたTPDUsの初期の処理のものです。 まず最初に、NSDUのそれぞれのTPDUが解読可能かどうか決定するのを1セットの保全チェックをします:
a. PDU length indicators and their sums are checked against the
NSDU length for consistency;
a。 PDU長さのインディケータとそれらの合計は一貫性がないかどうかNSDUの長さに対してチェックされます。
b. TPDU types versus minimum header lengths for the types are
checked, so that if the TPDU can be decoded, then proper
association to TPMs can be made without any problem;
b。 TPDUタイプ対タイプに、最小のヘッダ長はチェックされます、TPDUを解読できるなら少しも問題なしでTPMsへの適切な協会を作ることができるように。
c. TPDUs are searched for checksums and the local checksum is
computed for any checksum found; and
c。 TPDUsはチェックサムを捜されます、そして、地方のチェックサムは見つけられたどんなチェックサムのためにも計算されます。 そして
d. parameter codes in variable part of headers are checked where
applicable.
d. ヘッダーの可変一部のパラメタコードは適切であるところでチェックされます。
These integrity checks guarantee that an NSDU passing the check can be separated as necessary into TPDUs, these TPDUs can be associated to the transport connections or to the Slave as appropriate and they can be further decoded without error.
これらの保全チェックはTPDUsに必要に応じてチェックを通過するNSDUを切り離すことができて、適宜輸送の接続、または、SlaveにこれらのTPDUsを関連づけることができて、誤りなしで彼らをさらに解読できるのを保証します。
The TPE next decodes the fixed part of the TPDU headers to determine the disposition of the TPDU. The Slave gets TPDUs that cannot be assigned to a TPM (spurious TPDU). New TPMs are created in response to CR TPDUs that correspond to a TSAP for this TPE.
次のTPEは、TPDUの気質を決定するためにTPDUヘッダーの固定一部を解読します。 SlaveはTPM(偽物のTPDU)に割り当てることができないTPDUsを手に入れます。 新しいTPMsはこのTPEのためのTSAPに対応するCR TPDUsに対応して作成されます。
All management of NSAPs is done by the TPE. This consists of keeping track of all network connections, their service quality characteristics and their availability, informing the TPMs associated with these network connections.
TPEはNSAPsのすべての管理を完了しています。 ネットワーク接続、彼らのすべてのサービス品質の道が特性とそれらの有用性であることを保つのからこれは成ります、これらのネットワーク接続に関連しているTPMsに知らせて。
The TPE has no timer module as such. Timing is handled by using the DELAY feature of Estelle, since this feature captures the essence of timing without specifying how the actual timing is to be achieved within the operating environment. See Part 1.2.5 for more details.
TPEには、そういうもののタイマモジュールが全くありません。 タイミングはエステルのDELAYの特徴を使用することによって、扱われます、この特徴が操作環境の中で達成される実際のタイミングがことである方法を指定しないでタイミングの本質を得るので。 その他の詳細に関してPart1.2.5を見てください。
1.2.2 Service Access Points.
1.2.2 サービスアクセスポイント。
The service access points (SAP) of the transport entity are modeled using the Estelle channel/interaction point formalism. (Note: The
輸送実体のサービスアクセスポイント(SAP)は、エステルチャンネル/相互作用ポイント形式を使用することでモデル化されます。 (以下に注意してください。
McCoy [Page 8] RFC 1008 June 1987
マッコイ[8ページ]RFC1008 1987年6月
term "channel" in Estelle is a keyword that denotes a set of interactions which may be exchanged at interaction points [LIN85]. However, it is useful conceptually to think of "channel" as denoting a communication path that carries the interactions between modules.) The abstract service primitives for a SAP are interactions on channels entering and leaving the TPE. The transport user is considered to be at the end of the channel connected to the transport SAP (TSAP) and the network service provider is considered to be at the end of the channel connected to the network SAP (NSAP). An interaction put into a channel by some module can be considered to move instantaneously over the channel onto a queue at the other end. The sender of such an interaction no longer has access to the interaction once it has been put into the channel. The operation of the system modeled by the formal description has been designed with this semantics in mind, rather than the equivalent but much more abstract Estelle semantics. (In the Estelle semantics, each interaction point is considered to have associated with it an unbounded queue. The "attach" and "connect" primitives bind two interaction points, such that an action, implied by the keyword "out", at one interaction point causes a specified interaction to be placed onto the queue associated with the other interaction point.) The sections that follow discuss the TSAP and the NSAP and the way that these SAPs are described in the formal description.
エステルの「チャンネル」という用語は相互作用ポイント[LIN85]で交換されるかもしれない1セットの相互作用を指示するキーワードです。 しかしながら、モジュールの間の相互作用を運ぶ通信路を指示すると「チャンネル」を考えるのは概念的に役に立ちます。) SAPのための抽象的なサービス基関数はTPEに入って、残すチャンネルにおける相互作用です。 輸送ユーザが輸送SAP(TSAP)に接されたチャンネルの端にいると考えられて、ネットワークサービスプロバイダーがネットワークSAP(NSAP)に接続されたチャンネルの端にあると考えられます。 何らかのモジュールでチャンネルに入れられた相互作用が即座にもう一方の端の待ち行列にチャンネルを譲ると考えることができます。 いったんチャンネルにそれを入れると、そのような相互作用の送付者はもう相互作用に近づく手段を持っていません。 形式的記述でモデル化されたシステムの操作は同等な、しかし、はるかに抽象的なエステル意味論より念頭と、むしろこの意味論で設計されています。 (エステル意味論では、それぞれの相互作用ポイントが限りない待ち行列をそれに関連づけたと考えられます。 2「付いてください」と基関数が縛る「接続してください」相互作用ポイント(1相互作用ポイントでキーワード“out"によって含意された動作でもう片方の相互作用ポイントに関連している待ち行列に指定された相互作用を置くようなもの)) 従うセクションはTSAP、NSAP、およびこれらのSAPsが形式的記述で説明される方法を論じます。
1.2.2.1 Transport Service Access Point.
1.2.2.1 サービスアクセスポイントを輸送してください。
The international transport standard allows for more than one TSAP to be associated with a transport entity, and multiple users may be associated with a given TSAP. A situation in which this is useful is when it is desirable to have a certain quality of service correlated with a given TSAP. For example, one TSAP could be reserved for applications requiring a high throughput, such as file transfer. The operation of transport connections associated with this TSAP could then be designed to favor throughput. Another TSAP might serve users requiring short response time, such as terminals. Still another TSAP could be reserved for encryption reasons.
国際輸送規格は、1TSAPが輸送実体に関連しているのを許容します、そして、複数のユーザが与えられたTSAPに関連しているかもしれません。 これが役に立つ状況は与えられたTSAPと共にあるサービスの質を関連させるのが望ましい時です。 例えば、ファイル転送などの高生産性を必要とするアプリケーションのために1TSAPを予約できました。 そして、スループットを支持するようにこのTSAPに関連している輸送の接続の操作を設計できました。 別のTSAPは短い応答時間を必要とする端末などのユーザに役立つかもしれません。 暗号化理由でまだ、別のTSAPを予約できました。
In order to provide a way of referencing users associated with TSAPs, the user access to transport in the formal description is through an array of Estelle interaction points. This array is indexed by a TSAP address (T_address) and a Transport Connection Endpoint Identifier (TCEP_id). Note that this dimensional object (TSAP) is considered simply to be a uniform set of abstract interfaces. The indices must be of (Pascal) ordinal type in Estelle. However, the actual address structure of TSAPs may not conform easily to such typing in an implementation. Consequently, the indices as they appear in the formal description should be viewed as an organizational mechanism rather than as an explicit way of associating objects in an operational setting. For example, actual TSAP addresses might be kept in some kind of table, with the table index being used to reference objects associated with the TSAP.
TSAPsに関連しているユーザに参照をつける方法を提供するために、エステル相互作用ポイントの配列を通して形式的記述で輸送するユーザアクセスはあります。 この配列はTSAPアドレス(T_アドレス)とTransport Connection Endpoint Identifier(TCEP_イド)によって索引をつけられます。 この次元オブジェクト(TSAP)が単に一定のセットの抽象的なインタフェースであると考えられることに注意してください。 エステルという(パスカル)序数タイプにはインデックスリストがあるに違いありません。 しかしながら、TSAPsの絶対番地構造は容易に実装におけるそのようなタイプに一致しないかもしれません。 その結果、インデックスリストは形式的記述に現れるように操作上の設定でオブジェクトを関連づける明白な方法としてというよりむしろ組織的なメカニズムとして見なされるべきです。 例えば、実際のTSAPアドレスはある種のテーブルに保管されるかもしれません、テーブルインデックスがTSAPに関連している参照物体に使用されている状態で。
McCoy [Page 9] RFC 1008 June 1987
マッコイ[9ページ]RFC1008 1987年6月
One particular issue concerned with realizing TSAPs is that of making known to the users the means of referencing the transport interface, i.e., somehow providing the T_addresses and TCEP_ids to the users. This issue is not considered in any detail by either IS 7498 [ISO84b] or IS 8073. Abstractly, the required reference is the T_address/TCEP_id pair. However, this gives no insight as to how the mechanism could work. Some approaches to this problem are discussed in Part 5.
TSAPsがわかるのに関する特定の1冊はすなわち、どうにかT_アドレスとTCEP_イドをユーザに提供しながら輸送インタフェースに参照をつける手段をユーザに明らかにするものです。 この問題は、どちらかによるどんな詳細にも考えられていないのが、7498[ISO84b]であるということであるか8073です。 抽象的に、必要な参照はT_アドレス/TCEP_イド組です。 しかしながら、メカニズムがどう動作できたかに関してこれは洞察を全く与えません。 Part5でこの問題へのいくつかのアプローチについて議論します。
Another issue is that of flow control on the TSAP channels. Flow control is not part of the semantics for the Estelle channel, so the problem must be dealt with in another way. The formal description gives an abstract definition of interface flow control using Pascal and Estelle mechanisms. This abstraction resembles many actual schemes for flow control, but the realization of flow control will still be dependent on the way the interface is implemented. Part 3.2 discusses this in more detail.
別の問題はTSAPチャンネルの上のフロー制御のものです。 フロー制御がエステルチャンネルのための意味論の一部でないので、別の方法的に問題に対処しなければなりません。 形式的記述は、パスカルとエステルメカニズムを使用することでインタフェースフロー制御の抽象的な定義を与えます。この抽象化はフロー制御の多くの実際の体系に類似していますが、フロー制御の実現はまだインタフェースが実装される方法に依存するようになっているでしょう。 パート3.2はさらに詳細にこれについて議論します。
1.2.2.2 Network Service Access Point.
1.2.2.2 サービスアクセスポイントをネットワークでつないでください。
An NSAP may also have more than one network connection associated with it. For example, the virtual circuits of X.25 correspond with this notion. On the other hand, an NSAP may have no network connection associated with it, for example when the service at the NSAP is connectionless. This certainly will be the case when transport operates on a LAN or over IP. Consequently, although the syntactical appearance of the NSAP in the formal description is similar to that for the TSAP, the semantics are essentially distinct [NTI85].
また、NSAPには、それに関連している1人以上のネットワーク接続がいるかもしれません。 例えば、X.25の仮想の回路はこの概念に対応しています。 他方では、NSAPには、それに関連しているどんなネットワーク接続もいないかもしれません、例えば、NSAPでのサービスがコネクションレスであるときに。 輸送がLANの上、または、IPの上で作動するとき、確かに、これはそうになるでしょう。 その結果、形式的記述における、NSAPの構文の外観は同様ですが、TSAP、意味論のためのそれには、本質的には異なった[NTI85]があります。
Distinct NSAPs can correspond or not to physically distinct networks. Thus, one NSAP could access X.25 service, another might access an IEEE 802.3 LAN, while a third might access a satellite link. On the other hand, distinct NSAPs could correspond to different addresses on the same network, with no particular rationale other than facile management for the distinction. There are performance and system design issues that arise in considering how NSAPs should be managed in such situations. For example, if distinct NSAPs represent distinct networks, then a transport entity which must handle all resource management for the transport connections and operate these connections as well may have trouble keeping pace with data arriving concurrently from two LANs and a satellite link. It might be a better design solution to separate the management of the transport connection resources from that of the NSAP resources and inputs, or even to provide separate transport entities to handle some of the different network services, depending on the service quality to be maintained. It may be helpful to think of the (total) transport service as not necessarily being provided by a single monolithic entity--several distinct entities can reside at the transport layer on the same end-system.
異なったNSAPsは物理的に異なったネットワークに対応できます。 したがって、1NSAPがX.25サービスにアクセスできて、別のものはIEEE802.3LANにアクセスするかもしれません、3分の1が衛星中継にアクセスするかもしれませんが。 他方では、異なったNSAPsは同じネットワークに関する異なったアドレスに対応するかもしれません、区別のための軽快な管理以外のどんな特定の原理でも、そうしません。 NSAPsがそのような状況でどのように管理されるべきであるかを考える際に起こる性能とシステム設計問題があります。 例えば、異なったNSAPsが異なったネットワークを代表するなら、輸送の接続のためのすべての資源管理を扱って、また、これらの接続を手術しなければならない輸送実体は、同時に2つのLANと衛星中継から到着するデータと足並をそろえるのに苦労するかもしれません。 NSAPリソースと入力のものと輸送接続リソースの管理を切り離すか、または異なったネットワーク・サービスのいくつかを扱うために別々の輸送実体を提供するのさえ、より良いデザイン解決であるかもしれません、維持されるサービス品質によって。 必ずただ一つの一枚岩的な実体によって提供されるというわけではない(総)の輸送サービスを考えるのは役立っているかもしれません--いくつかの別個の物が同じエンドシステムの上にトランスポート層に住むことができます。
McCoy [Page 10] RFC 1008 June 1987
マッコイ[10ページ]RFC1008 1987年6月
The issues of NSAP management come primarily from connection-oriented network services. This is because a connectionless service is either available to all transport connections or it is available to none, representing infinite degrees of multiplexing and splitting. In the connection-oriented case, NSAP management is complicated by multiplexing, splitting, service quality considerations and the particular character of the network service. These issues are discussed further in Part 3.4.1. In the formal description, network connection management is carried out by means of a record associated with each possible connection and an array, associated with each TPM, each array member corresponding to a possible network connection. Since there is, on some network services, a very large number of possible network connections, it is clear that in an implementation these data structures may need to be made dynamic rather than static. The connection record, indexed by NSAP and NCEP_id, consists of a Slave module reference, virtual data connections to the TPMs to be associated with the network connection, a data connection (out) to the NSAP, and a data connection to the Slave. There is also a "state" variable for keeping track of the availability of the connection, variables for managing the Slave and an internal reference number to identify the connection to TPMs. A member of the network connection array associated with a TPM provides the TPM with status information on the network connection and input data (network) events and TPDUs). A considerable amount of management of the network connections is provided by the formal description, including splitting, multiplexing, service quality (when defined), interface flow control, and concatenation of TPDUs. This management is carried out solely by the transport entity, leaving the TPMs free to handle only the explicit transport connection issues. This management scheme is flexible enough that it can be simplified and adapted to handle the NSAP for a connectionless service.
NSAP管理の問題は主として接続指向のネットワーク・サービスから来ます。 これはすべての輸送の接続にとって、コネクションレス型サービスが利用可能であるか、またはそれがなにもに利用可能でないからです、多重送信して、分かれる無限の度合いを表して。 接続指向の場合では、管理が多重送信することによって複雑である分かれているNSAPはネットワーク・サービスの上質の問題と特定のキャラクタにサービスを提供します。 Part3.4.1で、より詳しくこれらの問題について議論します。 形式的記述では、それぞれの可能な接続と配列に関連している記録によってネットワーク接続管理が行われます、各TPM(可能なネットワーク接続にとって、対応するそれぞれの配列メンバー)に関連しています。 いくつかのネットワーク・サービスには非常に多くの可能なネットワーク接続がいるので、実装において、これらのデータ構造が、静的であるというよりむしろダイナミックに作られている必要があるのは、明確です。 NSAPとNCEP_イドによって索引をつけられた接続記録は、NSAPにSlaveモジュール参照、ネットワーク接続、データ接続に関連しているTPMsとの仮想データ接続から(out)を成らせて、データ接続をSlaveに成らせます。 また、接続の有用性の動向をおさえるための「状態」変数があります、TPMsに接続を特定するためにSlaveと内部の参照番号を管理するための変数。TPMに関連しているネットワーク接続配列のメンバーはネットワーク接続と入力データ(ネットワーク) イベントとTPDUs)の状態情報をTPMに提供します。 形式的記述でネットワーク接続のかなりの量の管理を提供します、TPDUsの分かれる、マルチプレクシング、サービス品質(定義されると)、インタフェースフロー制御、および連結を含んでいて。 この管理が唯一輸送実体によって行われます、TPMsを明白な輸送接続問題だけを扱うのにおいて自由なままにして。 この管理体系はコネクションレス型サービスのためにNSAPを扱うためにそれを簡素化して、適合させることができるくらいフレキシブルです。
The principal issue for management of connectionless NSAPs is that of buffering, particularly if the data transmission rates are high, or there is a large number of transport connections being served. It may also be desirable for the transport entity to monitor the service it is getting from the network. This would entail, for example, periodically computing the mean transmission delays for adjusting timers or to exert backpressure on the transport connections if network access delay rises, indicating loading. (In the formal description, the Slave processor provides a simple form of output buffer management: when its queue exceeds a threshold, it shuts off data from the TPMs associated with it. Through primitive functions, the threshold is loosely correlated with network behavior. However, this mechanism is not intended to be a solution to this difficult performance problem.)
コネクションレスなNSAPsの管理に、主要な問題はバッファリングのものです、特に、データ伝送レートが高いか、または役立たれている多くの輸送の接続がいれば。 また、輸送実体がそれがネットワークから得ているサービスをモニターするのも、望ましいかもしれません。 これは、例えば、ネットワークアクセス遅延が上昇するなら調整しているタイマか輸送の接続に背圧を加えるために定期的に意地悪なトランスミッション遅れを計算するのを伴うでしょう、ローディングを示して。 (形式的記述に、Slaveプロセッサは単純形の出力バッファ管理を提供します: 待ち行列が敷居を超えていると、それはそれに関連しているTPMsからのデータを止めます。 原始関数を通して、敷居はネットワークの振舞いで緩く関連します。 しかしながら、このメカニズムはこの難しい性能問題の解決であることを意図しません。)
McCoy [Page 11] RFC 1008 June 1987
マッコイ[11ページ]RFC1008 1987年6月
1.2.3 Transport Protocol Machine.
1.2.3 プロトコルマシンを輸送してください。
Transport Protocol Machines (TPM) in the formal description are in six classes: General, Class 0, Class 1, Class 2, Class 3 and Class 4. Only the General, Class 2 and Class 4 TPMs are discussed here. The reason for this diversity is to facilitate describing class negotiations and to show clearly the actions of each class in the data transfer phase. The General TPM is instantiated when a connection request is received from a transport user or when a CR TPDU is received from a remote peer entity. This TPM is replaced by a class-specific TPM when the connect response is received from the responding user or when the CC TPDU is received from the responding peer entity.
6つのクラスには形式的記述における輸送プロトコルMachines(TPM)があります: 一般、クラス0、クラス1、クラス2、クラス3、およびクラス4。 ここで司令官、Class2、およびClass4TPMsだけについて議論します。 この多様性の理由は、クラス交渉について説明するのを容易にして、明確にデータ転送段階における、それぞれのクラスの動作を示していることです。 輸送ユーザから接続要求を受け取るか、またはリモート同輩実体からCR TPDUを受け取るとき、司令官のTPMを例示します。 このTPMをクラス特有のTPMに取り替える、いつ、応じているユーザかそれともいつ応じている同輩実体からCC TPDUを受け取るかから受けられた応答を接続してくださいか。
The General, Class 2 and Class 4 TPMs are discussed below in more detail. In an implementation, it probably will be prudent to merge the Class 2 and Class 4 operations with that of the General TPM, with new variables selecting the class-specific operation as necessary (see also Part 9.4 for information on obtaining Class 2 operation from a Class 4 implementation). This may simplify and improve the behavior of the implemented protocol overall.
以下でさらに詳細に司令官、Class2、およびClass4TPMsについて議論します。 実現では、Class2とClass4つの操作を司令官のTPMのものに合併するのはたぶん慎重でしょう、新しい変数が必要(また、Class4実現からClass2操作を得ることの情報に関してPart9.4を見る)としてクラス特有の操作を選定していて。 これは、全体的に見て実行されたプロトコルの振舞いを簡素化して、改良するかもしれません。
1.2.3.1 General Transport Protocol Machine.
1.2.3.1 一般トランスポート・プロトコルマシン。
Connection negotiation and establishment for all classes can be handled by the General Transport Protocol Machine. Some parts of the description of this TPM are sufficiently class dependent that they can safely be removed if that class is not implemented. Other parts are general and must be retained for proper operation of the TPM. The General TPM handles only connection establishment and negotiation, so that only CR, CC, DR and DC TPDUs are sent or received (the TPE prevents other kinds of TPDUs from reaching the General TPM).
司令官のTransportプロトコルMachineはすべてのクラスのための接続交渉と設立を扱うことができます。 このTPMの記述のいくつかの部品がクラスに十分依存しています。実行されて、そのクラスがないなら、安全にそれらは移すことができます。 他の部品を一般的であり、TPMの適切な操作のために保有しなければなりません。 司令官のTPMはコネクション確立と交渉だけを扱います、CR、CC、DR、およびDC TPDUsだけを送るか、または受ける(TPEは、TPDUsの他の種類が司令官のTPMに達するのを防ぐ)ように。
Since the General TPM is not instantiated until a T-CONNECT-request or a CR TPDU is received, the TPE creates a special internal connection to the module's TSAP interaction point to pass the T-CONNECT-request event to the TPM. This provides automaton completeness according to the specfication of the protocol. When the TPM is to be replaced by a class-specific TPM, the sent or received CC is copied to the new TPM so that negotiation information is not lost.
T-CONNECT-要求かCR TPDUが受信されるまで司令官のTPMが例示されないので、TPEはT-CONNECT-要求イベントをTPMに通過するためにモジュールのTSAP相互作用ポイントに特別な内部の接続を創造します。 プロトコルのspecficationに応じて、これはオートマトンの完全性を提供します。 TPMがクラス特有のTPMに取り替えられることになっているとき、送られたか容認されたCCが新しいTPMにコピーされるので、交渉情報は無くなっていません。
In the IS 8073 state tables for the various classes, the majority of the behavioral information for the automaton is contained in the connection establishment phase. The editors of the formal description have retained most of the information contained in the state tables of IS 8073 in the description of the General TPM.
中、8073年の状態は様々なクラス(中の接続設立が位相を合わせる含まれたオートマトンのための挙動情報の大部分)のためのテーブルです。 形式的記述のエディタが中に含まれた情報だいたいの州のテーブルを保有した、司令官のTPMの記述における8073はそうです。
1.2.3.2 Class 2 Transport Protocol Machine.
1.2.3.2 クラス2はプロトコルマシンを輸送します。
The formal description of the Class 2 TPM closely resembles that of
TPMが密接にそれに類似しているClass2の形式的記述
McCoy [Page 12] RFC 1008 June 1987
マッコイ[12ページ]RFC1008 1987年6月
Class 4, in many respects. This is not accidental, in that: the conformance statement in IS 8073 links Class 2 with Class 4; and the editors of the formal description produced the Class 2 TPM description by copying the Class 4 TPM description and removing material on timers, checksums, and the like that is not part of the Class 2 operation. The suggestion of obtaining Class 2 operation from a Class 4 implementation, described in Part 9.4, is in fact based on this adaptation.
あらゆる点でクラス4。 これはそれで偶然ではありません: コネが8073であるという順応声明はClass2をClass4にリンクします。 そして、形式的記述のエディタは、Class4TPM記述をコピーして、材料を取り除くことによって、タイマ、チェックサム、およびClass2操作の一部でない同様のものにClass2TPM記述を起こしました。 事実上、Part9.4で説明されたClass4実現からClass2操作を得る提案はこの適合に基づいています。
One feature of Class 2 that does not appear in Class 4, however, is the option to not use end-to-end flow control. In this mode of operation, Class 2 is essentially Class 0 with multiplexing. In fact, the formal description of the Class 0 TPM was derived from Class 2 (in IS 8073, these two classes have essentially identical state tables). This implies that Class 0 operation could be obtained from Class 2 by not multiplexing, not sending DC TPDUs, electing not to use flow control and terminating the network connection when a DR TPDU is received (expedited data cannot be used if flow control is not used). When Class 2 is operated in this mode, a somewhat different procedure is used to handle data flow internal to the TPM than is used when end-to-end flow control is present.
しかしながら、Class4に現れないClass2の1つの特徴が終わりから終わりへのフロー制御を使用しないオプションです。 この運転モードで、Class2は本質的にはマルチプレクシングがあるClass0です。 事実上、Class2からClass0TPMの形式的記述を得ました(中に8073があって、これらの2つのクラスには本質的には同じステートテーブルがあります)。 これは、Class2からDC TPDUsを送らないで、多重送信しないことによってClass0操作を得ることができるだろうというのを含意します、フロー制御を使用しないのを選んで、DR TPDUが受け取られているときネットワーク接続を終えて(フロー制御が使用されていないなら、速められたデータを使用できません)。 Class2がこのモードで操作されるとき、いくらか異なった手順は、TPMへの内部のデータフローを扱うのに用いられます。終わらせる終わりのフロー制御が存在しているとき、使用されるより。
1.2.3.3 Class 4 Transport Protocol Machine.
1.2.3.3 クラス4はプロトコルマシンを輸送します。
Dynamic queues model the buffering of TPDUs in both the Class 4 and Class 2 TPMs. This provides a more general model of implementations than does the fixed array representation and is easier to describe. Also, the fixed array representation has semantics that, carried into an implementation, would produce inefficiency. Consequently, linked lists with queue management functions make up the TPDU storage description, despite the fact that pointers have a very implementation-like flavor. One of the queue management functions permits removing several TPDUs from the head of the send queue, to model the acknowledgement of several TPDUs at once, as specified in IS 8073. Each TPDU record in the queue carries the number of retransmissions tried, for timer control (not present in the Class 2 TPDU records).
ダイナミックな待ち行列はClass4とClass両方の2TPMsでのTPDUsのバッファリングをモデル化します。これは実現の固定アレイ表現をして、説明するのが、より簡単であるより一般的なモデルを提供します。 また、固定アレイ表現には、実現まで運ばれた状態で非能率を生産する意味論があります。 その結果、待ち行列管理機能がある繋がっているリストはTPDU格納記述を作ります、ポインタには実現の非常にような風味があるという事実にもかかわらず。 待ち行列管理機能のひとりは、すぐに数個のTPDUsの承認をモデル化するために送信キューのヘッドから数個のTPDUsを取り外すことを許可して、中に8073が指定されるようにあります。 待ち行列におけるそれぞれのTPDU記録はタイマ制御装置(Class2TPDUでは、記録を提示しない)のために試された「再-トランスミッション」の数を運びます。
There are two states of the Class 4 TPM that do not appear in IS 8073. One of these was put in solely to facilitate obtaining credit in case no credit was granted for the CR or CC TPDU. The other state was put in to clarify operations when there is unacknowledged expedited data outstanding (Class 2 does not have this state).
2があります。それが現れないClass4TPMの州は8073です。 これらの1つは、唯一CRかCC TPDUのためにクレジットを全く与えないといけなかったので信用を得るのを容易にするために入れられました。 もう片方の状態は、未払いの不承認の速められたデータがあるとき(クラス2には、この状態がありません)、操作をはっきりさせるために中に入れられました。
The timers used in the Class 4 TPM are discussed below, as is the description of end-to-end flow control.
終わりから終わりへのフロー制御の記述のように以下でClass4TPMで使用されるタイマについて議論します。
For simplicity in description, the editors of the formal description assumed that no queueing of expedited data would occur at the user interface of the receiving entity. The user has the capability to block the up-flow of expedited data until it is ready. This
記述における簡単さのために、形式的記述のエディタは、速められたデータの待ち行列が全く受信実体のユーザーインタフェースに起こらないと仮定しました。 ユーザには、それが準備ができるまで速められたデータの上昇流を妨げる能力があります。 これ
McCoy [Page 13] RFC 1008 June 1987
マッコイ[13ページ]RFC1008 1987年6月
assumption has several implications. First, an ED TPDU cannot be acknowledged until the user is ready to accept it. This is because the receipt of an EA TPDU would indicate to the sending peer that the receiver is ready to receive the next ED TPDU, which would not be true. Second, because of the way normal data flow is blocked by the sending of an ED TPDU, normal data flow ceases until the receiving user is ready for the ED TPDU. This suggests that the user interface should employ separate and noninterfering mechanisms for passing normal and expedited data to the user. Moreover, the mechanism for expedited data passage should be blocked only in dire operational conditions. This means that receipt of expedited data by the user should be a procedure (transition) that operates at nearly the highest priority in the user process. The alternative to describing the expedited data handling in this way would entail a scheme of properly synchronizing the queued ED TPDUs with the DT TPDUs received. This requires some intricate handling of DT and ED sequence numbers. While this alternative may be attractive for implementations, for clarity in the formal description it provides only unnecessary complication.
仮定には、いくつかの意味があります。 まず最初に、ユーザがそれを受け入れる準備ができるまで、ED TPDUを承認できません。 EA TPDUの領収書は、受信機を次の本当でないだろうというED TPDUを受け取る準備ができているのを送付同輩に示すでしょう、したがって、これはそうです。 2番目に、正常なデータフローがED TPDUの発信で妨げられる方法のために、受信ユーザがED TPDUの準備ができるまで、正常なデータフローはやみます。 これは、ユーザーインタフェースが正常で速められたデータをユーザに渡すのに別々の、そして、非干渉しているメカニズムを使うはずであると示唆します。 そのうえ、速められたデータ通路へのメカニズムは恐ろしい稼動状況だけで妨げられるべきです。 これは、ユーザによる速められたデータの領収書がほとんどユーザ・プロセスによる最優先で作動する手順であるべきであること(変遷)を意味します。 このように速められたデータハンドリングについて説明することへの代替手段は受け取るDT TPDUsに列に並ばせられたED TPDUsを適切に連動させる計画を伴うでしょう。 これはDTとED一連番号の何らかの複雑な取り扱いを必要とします。 実現に、この代替手段は魅力的であるかもしれませんが、形式的記述における明快ために、それは不要な複雑さだけを提供します。
The description of normal data TSDU processing is based on the assumption that the data the T-DATA-request refers to is potentially arbitrarily long. The semantic of the TSDU in this case is analogous to that of a file pointer, in the sense that any file pointer is a reference to a finite but arbitrarily large set of octet-strings. The formation of TPDUs from this string is analogous to reading the file in fixed-length segments--records or blocks, for example. The reassembly of TPDUs into a string is analogous to appending each TPDU to the tail of a file; the file is passed when the end-of-TSDU (end-of-file) is received. This scheme permits conceptual buffering of the entire TSDU in the receiver and avoids the question of whether or not received data can be passed to the user before the EOT is received. (The file pointer may refer to a file owned by the user, so that the question then becomes moot.)
通常のデータTSDU処理の記述はT-DATA-要求が示すデータが潜在的に任意に長いという仮定に基づいています。 この場合、TSDUの意味はファイル・ポインタのものに類似しています、どんなファイル・ポインタも有限な、しかし、任意に大きいセットの八重奏ストリングの参照であるという意味で。 このストリングからのTPDUsの構成は固定長セグメントでファイルを読むのに類似しています--例えば、記録かブロック。 ストリングへのTPDUsの再アセンブリは各TPDUをファイルのテールに追加するのに類似しています。 TSDUの端(ファイルの終り)が受け取られているとき、ファイルは渡されます。 この計画は、受信機での全体のTSDUの概念的なバッファリングを可能にして、EOTが受け取られている前に受信データをユーザに渡すことができるかどうかに関する質問を避けます。 (ファイル・ポインタがユーザによって所有されていたファイルを示すかもしれないので、次に、質問は論争中になります。)
The encoding of TPDUs is completely described, using Pascal functions and some special data manipulation functions of Estelle (these are not normally part of Pascal). There is one encoding function corresponding to each TPDU type, rather than a single parameterized function that does all of them. This was done so that the separate structures of the individual types could be readily discerned, since the purpose of the functions is descriptive and not necessarily computational.
TPDUsのコード化は完全に説明されます、パスカルの機能とエステルのいくつかの特別なデータマニピュレーション機能を使用して(通常、これらはパスカルの一部ではありません)。 すべてをするただ一つのparameterized機能よりむしろそれぞれのTPDUタイプのそれらにおいて、対応する1つのコード化機能があります。 容易に独特のタイプの別々の構造について明察できるようにこれをしました、機能の目的が描写的であって、必ずコンピュータであるというわけではないので。
The output of TPDUs from the TPM is guarded by an internal flow control flag. When the TPDU is first sent, this flag is ignored, since if the TPDU does not get through, a retransmission may take care of it. However, when a retransmission is tried, the flag is heeded and the TPDU is not sent, but the retransmission count is incremented. This guarantees that either the TPDU will eventually be sent or the connection will time out (this despite the fact that
TPMからのTPDUsの出力は内部のフロー制御旗で警備されます。 最初にTPDUを送るとき、この旗を無視します、TPDUが通らないなら、「再-トランスミッション」がそれの世話をするかもしれないので。 しかしながら、「再-トランスミッション」が試験済みであるときに、旗は意に介されます、そして、TPDUは送られませんが、「再-トランスミッション」カウントは増加されています。 これが、TPDUが結局送られるどちらかか接続がタイムアウトを望んでいるのを保証する、(事実にもかかわらず、これ、それ
McCoy [Page 14] RFC 1008 June 1987
マッコイ[14ページ]RFC1008 1987年6月
the peer will never have received any TPDU to acknowledge). Checksum computations are done in the TPM rather than by the TPE, since the TPE must handle all classes. Also, if the TPMs can be made to truly run in parallel, the performance may be greatly enhanced.
意志が承認するためにどんなTPDUも一度も受けたことがない同輩) TPEがすべてのクラスを扱わなければならないので、TPEでというよりむしろTPMでチェックサム計算をします。 また、TPMsを本当に平行線に立候補させることができるなら、性能は大いに高められるかもしれません。
The decoding of received TPDUs is partially described in the Class 4 TPM description. Only the CR and CC TPDUs present any problems in decoding, and these are largely due to the nondeterministic order of parameters in the variable part of the TPDU headers and the locality-and class-dependent content of this variable part. Since contents of this variable part (except the TSAP-IDs) do not affect the association of the TPDU with a transport connection, the decoding of the variable part is not described in detail. Such a description would be very lengthy indeed because of all the possibilities and would not contribute measurably to understanding by the reader.
容認されたTPDUsの解読はClass4TPM記述で部分的に説明されます。 そして、そして、CRとCC TPDUsだけが解読する際にどんな問題も提示して、これらが主にTPDUヘッダーの可変一部でのパラメタの非決定論的注文のためである、場所、-、この可変部分のクラス依存する内容。 この可変部分(TSAP-IDを除いた)の内容が輸送接続と共にTPDUの協会に影響しないので、可変部分の解読は詳細に説明されません。 そのような記述は、本当にすべての可能性のために非常に長いだろう、読者で分かるのにある程度まで貢献しないでしょう。
1.2.4 Network Slave.
1.2.4 奴隷をネットワークでつないでください。
The primary functions of the Network Slave are to provide downward flow control in the TPE, to concatenate TPDUs into a single NSDU and to respond to the receipt of spurious TPDUs. The Slave has an internal queue on which it keeps TPDUs until the network is ready to accept them for transmission. The TPE is kept informed as to the length of queue, and the output of the TPMs is throttled if the length exceeds this some threshold. This threshold can be adjusted to meet current operating conditions. The Slave will concatenate the TPDUs in its queue if the option to concatenate is exercised and the conditions for concatenating are met. Concatenation is a TPE option, which may be exercised or not at any time.
Network Slaveの第一の機能は、TPEの下向きのフロー制御を提供して、独身のNSDUにTPDUsを連結して、偽物のTPDUsの領収書に応じることです。 Slaveには、ネットワークがトランスミッションのために彼らを受け入れる準備ができるまでそれがTPDUsを保つ内部の待ち行列があります。 TPEは待ち行列の長さに関して知識があるように保たれます、そして、長さがこれを超えているなら、TPMsの出力は阻止されます。何らかの敷居。 現在の運転条件を満たすようにこの敷居を調整できます。 連結するオプションが運動させられて、連結のための条件が満たされると、Slaveは待ち行列でTPDUsを連結するでしょう。 連結はTPEオプションです。(そのオプションはいつでも、運動させられるかもしれません)。
1.2.5 Timers.
1.2.5 タイマ。
In the formal description timers are all modeled using a spontaneous transition with delay, where the delay parameter is the timer period. To activate the timer, a timer identifier is placed into a set, thereby satisfying a predicate of the form
形式的記述タイマに、遅れがある自然発生的な変遷を使用することでモデル化されたすべてがあります、遅れパラメタがタイマの期間であるところで。 タイマを動かすために、タイマ識別子はセットに置かれて、その結果、フォームに関する述部を満たします。
provided timer_x in active_timers
アクティブな_タイマの提供されたタイマ_x
However, the transition code is not executed until the elapsed time ;from the placement of the identifier in the set is at least equal to the delay parameter. The editors of the formal description chose to model timers in this fashion because it provided a simply expressed description of timer behavior and eliminated having to consider how timing is done in a real system or to provide special timer modules and communication to them. It is thus recommended that implementors not follow the timer model closely in implementations, considering instead the simplest and most efficient means of timing permitted by the implementation environment. Implementors should
しかしながら、変遷コードは経過時間まで実行されません; セットにおける、識別子のプレースメントから、少なくとも遅れパラメタへの同輩は来ています。 形式的記述のエディタは、こんなやり方でタイマの振舞いの単に言い表された記述を提供したのでタイマをモデル化するのを選んで、実システムでどのようにタイミングをするかを考えるか、または特別なタイマモジュールとコミュニケーションをそれらに前提とするために有を排除しました。 その結果、作成者が実現で密接にタイマモデルについて来ないのは、お勧めです、代わりに実現環境によって受入れられたタイミングの最も簡単で最も効率的な手段を考える場合。 作成者はそうするべきです。
McCoy [Page 15] RFC 1008 June 1987
マッコイ[15ページ]RFC1008 1987年6月
also note that the delay parameter is typed "integer" in the formal description. No scale conversion from actual time is expressed in the timer transition, so that this scale conversion must be considered when timers are realized.
また、遅れパラメタが形式的記述でタイプされた「整数」であると述べてください。 実際の時間からの小数点法変換は全くタイマ変遷で表現されません、タイマが実感されるとこの小数点法変換が考えなければならないように。
1.2.5.1 Transport Protocol Entity timers.
1.2.5.1 プロトコルEntityタイマを輸送してください。
There is only one timer given in the formal description of the TPE--the reference timer. The reference timer was placed here ;so that it can be used by all classes and all connections, as needed. There is actually little justification for having a reference timer within the TPM--it wastes resources by holding the transport endpoint, even though the TPM is incapable of responding to any input. Consequently, the TPE is responsible for all aspects of reference management, including the timeouts.
TPEには形式的記述で与えられたワンタイマーしかありません--参照タイマ。 参照タイマは、すべてのクラスとすべての接続が必要であるようにそれを使用できるように、ここに置かれました。 TPMの中に参照タイマを持つための実際に少ない正当化があります--輸送終点を保持することによって、リソースを浪費します、TPMはどんな入力にも応じることができませんが。 その結果、TPEはタイムアウトを含む参照経営者側の全面に責任があります。
1.2.5.2 Transport Protocol Machine timers.
1.2.5.2 プロトコルMachineタイマを輸送してください。
Class 2 transport does not have any timers that are required by IS 8073. However, the standard does recommend that an optional timer be used by Class 2 in certain cases to avoid deadlock. The formal description provides this timer, with comments to justify its usage. It is recommended that such a timer be provided for Class 2 operation. Class 4 transport has several timers for connection control, flow control and retransmissions of unacknowledged data. Each of these timers is discussed briefly below in terms of how they were related to the Class 4 operations in the formal description. Further discussion of these timers is given in Part 8.
輸送が必要であるタイマを持っていないクラス2は8073です。 しかしながら、規格は、任意のタイマが行き詰まりを避けるのにある場合には、Class2によって使用されることを勧めます。 形式的記述は、用法を正当化するためにこのタイマをコメントに提供します。 Class2操作にそのようなタイマを提供するのはお勧めです。 クラス4輸送には、不承認のデータの接続コントロール、フロー制御、および「再-トランスミッション」のための数個のタイマがあります。 簡潔に以下でどう形式的記述におけるClass4操作に関連したかに関してそれぞれのこれらのタイマについて議論します。 Part8でこれらのタイマのさらなる議論を与えます。
1.2.5.2.1 Window timer.
1.2.5.2.1 ウィンドウタイマ。
The window timer is used for transport connection control as well as providing timely updates of flow control credit information. One of these timers is provided in each TPM. It is reset each time an AK TPDU is sent, except during fast retransmission of AKs for flow control confirmation, when it is disabled.
ウィンドウタイマは、輸送接続コントロールに使用されて、フロー制御信用情報のタイムリーなアップデートを提供しています。 これらのタイマの1つを各TPMに提供します。 それはAK TPDUを送るたびにリセットされます、フロー制御確認のためのAKsの速い「再-トランスミッション」を除いて、それが障害があるとき。
1.2.5.2.2 Inactivity timer.
1.2.5.2.2 不活発タイマ。
The primary usage of the inactivity timer is to detect when the remote peer has ceased to send anything (including AK TPDUs). This timer is mandatory when operating over a connectionless network service, since there is no other way to determine whether or not the remote peer is still functioning. On a connection-oriented network service it has an additional usage since to some extent the continued existence of the network connection indicates that the peer host has not crashed.
不活発タイマのプライマリ使用法はリモート同輩が、いつ何か送るのをやめたかを(AK TPDUsを含んでいて)検出することです。 コネクションレスなネットワーク・サービスの上で作動するとき、このタイマは義務的です、リモート同輩がまだ機能しているかどうか決定する他の方法が全くないので。 ある程度ネットワーク接続の存続が、同輩ホストがダウンしていないのを示すので、接続指向のネットワーク・サービスのときに、それには追加用法があります。
Because of splitting, it is useful to provide an inactivity timer on each network connection to which a TPM is assigned. In this manner, if a network connection is unused for some time, it can be released,
分かれるので、TPMが割り当てられる各ネットワーク接続のときに不活発タイマを提供するのは役に立ちます。 この様に、ネットワーク接続がしばらく未使用であるなら、それをリリースできます。
McCoy [Page 16] RFC 1008 June 1987
マッコイ[16ページ]RFC1008 1987年6月
even though a TPM assigned to it continues to operate over other network connections. The formal description provides this capability in each TPM.
それに割り当てられたTPMは、他のネットワーク接続の上で作動し続けていますが。 形式的記述はこの能力を各TPMに供給します。
1.2.5.2.3 Network connection timer.
1.2.5.2.3 接続タイマをネットワークでつないでください。
This timer is an optional timer used to ensure that every network connection to which a TPM is assigned gets used periodically. This prevents the expiration of the peer entity's inactivity timer for a network connection. There is one timer for each network connection to which the TPM is assigned. If there is a DT or ED TPDU waiting to be sent, then it is chosen to be sent on the network connection. If no such TPDU is waiting, then an AK TPDU is sent. Thus, the NC timer serves somewhat the same purpose as the window timer, but is broader in scope.
このタイマはTPMが割り当てられるすべてのネットワーク接続が定期的に使用されるのを保証するのにおいて中古の任意のタイマです。 これはネットワーク接続のために同輩実体の不活発タイマの満了を防ぎます。 TPMが割り当てられる各ネットワーク接続のためのワンタイマーがあります。 送られるのを待つDTかED TPDUがあれば、それは、ネットワーク接続に送るために選ばれています。 どれかそのようなTPDUが待っていないなら、AK TPDUを送ります。 したがって、NCタイマは、ウィンドウタイマといくらか同じ目的に役立ちますが、範囲では、より広いです。
1.2.5.2.4 Give-up timer.
1.2.5.2.4 タイマをあきらめてください。
There is one give-up timer for a TPM which is set whenever the retransmission limit for any CR, CC, DT, ED or DR TPDU is reached. Upon expiration of this timer, the transport connection is closed.
いずれもCR、CC、DT、EDまたはDR TPDUのための「再-トランスミッション」限界に達しているときはいつも、用意ができているTPMのための1個の上にあきらめタイマがあります。 このタイマの満了のときに、輸送接続は閉じられます。
1.2.5.2.5 Retransmission timers.
1.2.5.2.5 再送信タイマー。
Retransmission timers are provided for CR, CC, DT, ED and DR TPDUs. The formal description provides distinct timers for each of these TPDU types, for each TPM. However, this is for clarity in the description, and Part 8.2.5 presents arguments for other strategies to be used in implementations. Also, DT TPDUs with distinct sequence numbers are each provided with timers, as well. There is a primitive function which determines the range within the send window for which timers will be set. This has been done to express flexibility in the retransmission scheme.
CR、CC、DT、ED、およびDR TPDUsに再送信タイマーを提供します。 形式的記述はこれらのTPDUタイプ各人、各TPMに異なったタイマを供給します。 しかしながら、これは記述における明快のためのそうであり、Part8.2.5個のプレゼントが他の戦略が実装に使用される議論です。 また、それぞれ異なった一連番号があるDT TPDUsにまた、タイマを提供します。 範囲を決定する原始関数が中にある、タイマが設定される窓を送ってください。 「再-トランスミッション」体系における柔軟性を言い表すためにこれをしました。
The flow control confirmation scheme specified in IS 8073 also provides for a "fast" retransmission timer to ensure the reception of an AK TPDU carrying window resynchronization after credit reduction or when opening a window that was previously closed. The formal description permits one such timer for a TPM. It is disabled after the peer entity has confirmed the window information.
確認体系が指定したフロー制御はまた、「速い」再送信タイマーがAK TPDU携帯の窓のレセプションを確実にするように再同期がクレジット減少の後に提供するか、または窓を開けて、それが以前に閉じられた8073年です。 形式的記述はTPMのためにそのようなタイマの1つを可能にします。 同輩実体が窓の情報を確認した後にそれは障害があります。
1.2.5.2.6 Error transport protocol data unit timer.
1.2.5.2.6 誤りトランスポート・プロトコルデータ単位タイマ。
In IS 8073, there is a provision for an optional timeout to limit the wait for a response by the peer entity to an ER TPDU. When this timer expires, the transport connection is terminated. Each Class 2 or Class 4 TPM is provided with one of these timers in N3756.
中に8073があって、同輩実体で応答のための待ちをER TPDUに制限するために、任意のタイムアウトへの支給があります。 このタイマが期限が切れるとき、輸送接続は終えられます。 N3756でそれぞれのClass2かClass4TPMにこれらのタイマの1つを提供します。
1.2.6 End-to-end Flow Control.
1.2.6 終わりから終わりへのフロー制御。
Flow control in the formal description has been written in such a way
形式的記述におけるフロー制御はそのような方法で書かれています。
McCoy [Page 17] RFC 1008 June 1987
マッコイ[17ページ]RFC1008 1987年6月
as to permit flexibility in credit control schemes and acknowledgement strategies.
クレジットにおける許可証の柔軟性に関して、体系と承認戦略を制御してください。
1.2.6.1 Credit control.
1.2.6.1 コントロールを掛けてください。
The credit mechanism in the formal description provides for actual management of credit by the TPE. This is done through variables exported by the TPMs which indicate to the TPE when credit is needed and for the TPE to indicate when credit has been granted. In this manner, the TPE has control over the credit a TPM has. The mechanism allows for reduction in credit (Class 4 only) and the possibility of precipitous window closure. The mechanism does not preclude the use of credit granted by the user or other sources, since credit need is expressed as current credit being less than some threshold. Setting the threshold to zero permits these other schemes. An AK TPDU is sent each time credit is updated.
形式的記述におけるクレジットメカニズムはTPEによるクレジットの実際の管理に備えます。 クレジットがいつ与えられたかを示すためにクレジットがいつ必要であるかをTPEに示すTPMsとTPEのためにエクスポートされた変数を通してこれをします。 この様に、TPEはTPMが持っているクレジットを管理します。 メカニズムはクレジット(クラス4専用)の減少と険しい窓の閉鎖の可能性を考慮します。 メカニズムはユーザか他のソースによって与えられたクレジットの使用を排除しません、クレジットの必要性が何らかの敷居以下である現在のクレジットとして述べられるので。 ゼロに敷居を設定すると、これらの他の体系は可能にします。 クレジットをアップデートするたびにAK TPDUを送ります。
The end-to-end flow control is also coupled to the interface flow control to the user. If the user has blocked the interface up-flow, then the TPM is prohibited from requesting more credit when the current window is used up.
また、終わりから終わりへのフロー制御はユーザへのインタフェースフロー制御と結合されます。 ユーザがインタフェース上昇流を妨げたなら、TPMは現在の窓が使いきられるとき、より多くのクレジットを要求するのが禁止されます。
1.2.6.2 Acknowledgement.
1.2.6.2 承認。
The mechanism for acknowledging normal data provides flexibility sufficient to send an AK TPDU in response to every Nth DT TPDU received where N > 0 and N may be constant or dynamically determined. Each TPM is provided with this, independent of all other TPMs, so that acknowledgement strategy can be determined separately for each transport connection. The capability of altering the acknowledgement strategy is useful in operation over networks with varying error rates.
正常なデータを承認するためのメカニズムはN>0とNが一定であるか、またはダイナミックに断固とするかもしれないところに受け取られたあらゆるNth DT TPDUに対応してAK TPDUを送ることができるくらいの柔軟性を提供します。 各TPMにこれを提供します、他のすべてのTPMsの如何にかかわらず、承認戦略がそれぞれの輸送接続のために別々に決定できるように。 異なった誤り率のために、承認戦略を変更する能力はネットワークの上の操作で役に立ちます。
1.2.6.3 Sequencing of received data.
1.2.6.3 受信データの配列。
It is not specified in IS 8073 what must be done with out-of-sequence but within-window DT TPDUs received, except that an AK TPDU with current window and sequence information be sent. There are performance reasons why such DT TPDUs should be held (cached): in particular, avoidance of retransmissions. However, this buffering scheme is complicated to implement and worse to describe formally without resorting to mechanisms too closely resembling implementation. Thus, the formal description mechanism discards such DT TPDUs and relies on retransmission to fill the gaps in the window sequence, for the sake of simplicity in the description.
中に順序が狂って処理しなければならないことにもかかわらず、窓の中のDT TPDUsが受け取った8073があって、現在の窓と系列情報があるAK TPDUが送られると指定されません。 そのようなDT TPDUsが持たれるべきである(キャッシュされます)性能理由があります: 特に「再-トランスミッション」の回避。 しかしながら、このバッファリング方式は、実装に類似しながら、道具で、より悪いのに正式に密接にメカニズムに頼り過ぎるというわけではなくて説明する複雑にされます。 したがって、形式的記述メカニズムは、窓の系列の不足をいっぱいにするためにそのようなDT TPDUsを捨てて、「再-トランスミッション」を当てにします、簡単にするために記述で。
1.2.7 Expedited data.
1.2.7 速められたデータ。
The transmission of expedited data, as expressed by IS 8073, requires the blockage of normal data transmission until the acknowledgement is received. This is handled in the formal description by providing a
言い表されるとしての速められたデータの伝達、承認が受け取られているまで、8073であり、正常なデータ伝送の封鎖を必要とします。 これは、形式的記述でaを提供することによって、扱われます。
McCoy [Page 18] RFC 1008 June 1987
マッコイ[18ページ]RFC1008 1987年6月
special state in which normal data transmission cannot take place. However, recent experiments with Class 4 transport over network services with high bandwidth, high transit delay and high error rates, undertaken by the NBS and COMSAT Laboratories, have shown that the protocol suffers a marked decline in its performance in such conditions. This situation has been presented to ISO, with the result that the the protocol will be modified to permit the sending of normal data already accepted by the transport entity from the user before the expedited data request but not yet put onto the network. When the modification is incorporated into IS 8073, the formal description will be appropriately aligned.
特別な状態はどの正常なデータ伝送で行われることができないか。 しかしながら、NBSとコムサット研究所によって引き受けられた高帯域があるネットワーク・サービスの上にClass4輸送がある最近の実験、高いトランジット遅れ、および高い誤り率は、プロトコルがそのような状態における性能で著しく減少するのを示しました。 この状況はISOに提示されました、その結果、プロトコルが、速められたデータ要求の前に輸送実体でユーザから既に受け入れましたが、まだネットワークに置かなかった正常なデータの発信を可能にするように変更されるでしょう。 変更がいつまで法人組織であるかが、8073である、形式的記述は適切に並べられるでしょう。
2 Environment of implementation.
2 実装の環境。
The following sections describe some general approaches to implementing the transport protocol and the advantages and disadvantages of each. Certain commercial products are identified throughout the rest of this document. In no case does such identification imply the recommendation or endorsement of these products by the Department of Defense, nor does it imply that the products identified are the best available for the purpose described. In all cases such identification is intended only to illustrate the possibility of implementation of an idea or approach. UNIX is a trademark of AT&T Bell Laboratories.
以下のセクションはそれぞれのトランスポート・プロトコルを実装することへのいくつかの一般的方法、利点、および損失について説明します。 ある商品はこのドキュメントの残りの間中特定されます。 そのような識別は国防総省によるこれらの製品の推薦か裏書きを決して、含意しません、そして、それは特定された製品が説明された目的に利用可能な最善であることを含意しません。 すべての場合では、そのような識別が単に考えかアプローチの実装の可能性を例証することを意図します。 UNIXはAT&Tベル研究所の商標です。
Most of the discussions in the remainder of the document deal with Class 4 exclusively, since there are far more implementation issues with Class 4 than for Class 2. Also, since Class 2 is logically a special case of Class 4, it is possible to implement Class 4 alone, with special provisions to behave as Class 2 when necessary.
ドキュメントの残りにおける議論の大部分は排他的にClass4に対処します、Class4があるClass2よりはるかに多くの導入問題があるので。 また、Class以来、2は論理的にそうです。Class4の特別なケース、単独でClass4を実装するのは可能です、必要であるときにClass2として振る舞わせる特別条項で。
2.1 Host operating system program.
2.1はオペレーティングシステムプログラムを主催します。
A common method of implementing the OSI transport service is to integrate the required code into the specific operating system supporting the data communications applications. The particular technique for integration usually depends upon the structure and facilities of the operating system to be used. For example, the transport software might be implemented in the operating system kernel, accessible through a standard set of system calls. This scheme is typically used when implementing transport for the UNIX operating system. Class 4 transport has been implemented using this technique for System V by AT&T and for BSD 4.2 by several organizations. As another example, the transport service might be structured as a device driver. This approach is used by DEC for the VAX/VMS implementation of classes 0, 2, and 4 of the OSI transport protocol. The Intel iRMX-86 implementation of Class 4 transport is another example. Intel implements the transport software as a first level job within the operating system. Such an approach allows the software to be linked to the operating system and loaded with every
OSIが輸送サービスであると実装する共通方法はデータコミュニケーションアプリケーションをサポートする特定のオペレーティングシステムと必要なコードを統合することです。 通常、統合のための特定のテクニックは、使用されるためにオペレーティングシステムの構造と施設に依存します。 例えば、輸送ソフトウェアはオペレーティングシステムカーネルで実装されるかもしれません、システムコールの標準セットを通してアクセスしやすいです。 Unixオペレーティングシステムのための輸送を実装するとき、この体系は通常使用されます。 クラス4輸送は、AT&TによるSystem VとBSD4.2にいくつかの組織でこのテクニックを使用することで実装されました。 別の例として、輸送サービスはデバイスドライバとして構造化されるかもしれません。このアプローチはOSIトランスポート・プロトコルのクラス0、2、および4のVAX/VMS実装に12月までに使用されます。 Class4輸送のインテルiRMX-86実装は別の例です。 インテルは、最初の平らな仕事としてオペレーティングシステムの中で輸送がソフトウェアであると実装します。 そのようなアプローチが、ソフトウェアがオペレーティングシステムにリンクされて、積まれるのを許容する、あらゆる
McCoy [Page 19] RFC 1008 June 1987
マッコイ[19ページ]RFC1008 1987年6月
boot of the system.
システムのブーツ。
Several advantages may accrue to the communications user when transport is implemented as an integral part of the operating system. First, the interface to data communications services is well known to the application programmer since the same principles are followed as for other operating system services. This allows the fast implementation of communications applications without the need for retraining of programmers. Second, the operating system can support several different suites of protocols without the need to change application programs. This advantage can be realized only with careful engineering and control of the user-system call interface to the transport services. Third, the transport software may take advantage of the normally available operating system services such as scheduling, flow control, memory management, and interprocess communication. This saves time in the development and maintenance of the transport software.
輸送がオペレーティングシステムの不可欠の部分として実装されるとき、いくつかの利点がコミュニケーションユーザに生じるかもしれません。 同じ原則が他のオペレーティングシステムサービスのように従われているので、まず最初に、アプリケーション・プログラマーにとって、データ通信へのインタフェースはよく知られています。 これはプログラマに再教育する必要性なしでコミュニケーションアプリケーションの速い実装を許容します。 2番目に、オペレーティングシステムはアプリケーション・プログラムを変える必要性なしでプロトコルのいくつかの異なったスイートを支えることができます。単にユーザシステムコールインタフェースの慎重な工学とコントロールでこの利点は輸送サービスに実現できます。 3番目に、輸送ソフトウェアはオペレーティングシステムが計画となっていながらそのようなものを修理する通常利用可能の利点、フロー制御、メモリ管理、およびプロセス間通信を取るかもしれません。 これは、輸送の開発とメインテナンスにおける時間がソフトウェアであると保存します。
The disadvantages that exist with operating system integration of the TP are primarily dependent upon the specific operating system. However, the major disadvantage, degradation of host application performance, is always present. Since the communications software requires the attention of the processor to handle interrupts and process protocol events, some degradation will occur in the performance of host applications. The degree of degradation is largely a feature of the hardware architecture and processing resources required by the protocol. Other disadvantages that may appear relate to limited performance on the part of the communications service. This limited performance is usually a function of the particular operating system and is most directly related to the method of interprocess communication provided with the operating system. In general, the more times a message must be copied from one area of memory to another, the poorer the communications software will perform. The method of copying and the number of copies is often a function of the specific operating system. For example, copying could be optimized if true shared memory is supported in the operating system. In this case, a significant amount of copying can be reduced to pointer-passing.
TPのオペレーティングシステム統合である難点は主として特定のオペレーティングシステムに依存しています。 しかしながら、主要な不都合(ホストアプリケーション性能の退行)はいつも存在しています。 コミュニケーションソフトウェアが中断とプロセスプロトコルイベントを扱うためにプロセッサの注意を必要とするので、いくらかの退行がホストアプリケーションの性能に起こるでしょう。 退行の度合いは主にハードウェアアーキテクチャの特徴です、そして、処理リソースがプロトコルが必要です。 現れるかもしれない他の損失は情報提供サービス側の限られた性能に関連します。 この限られた性能は、通常特定のオペレーティングシステムの機能であり、最も直接オペレーティングシステムが提供されたプロセス間通信のメソッドに関連します。 一般に、より多くの回、メモリの1つの領域から別のもの(より貧しいコミュニケーションソフトウェアが実行する)までメッセージをコピーしなければなりません。 しばしばコピーするメソッドとコピーの数は特定のオペレーティングシステムの機能です。 例えば、本当の共有メモリがオペレーティングシステムでサポートされるなら、コピーは最適化されるかもしれません。 この場合、かなりの量のコピーが指針通過に減少できます。
2.2 User program.
2.2 ユーザ・プログラム。
The OSI transport service can be implemented as a user job within any operating system provided a means of multi-task communications is available or can be implemented. This approach is almost always a bad one. Performance problems will usually exist because the communication task is competing for resources like any other application program. The only justification for this approach is the need to develop a simple implementation of the transport service quickly. The NBS implemented the transport protocol using this approach as the basis for a transport protocol correctness testing system. Since performance was not a goal of the NBS implementation,
マルチタスクコミュニケーションの手段を利用可能であるか、または実装することができるなら、ユーザ仕事としてどんなオペレーティングシステムの中でもOSI輸送サービスを実装することができます。 ほとんどいつもこのアプローチは悪いものです。 リソースにおいて、コミュニケーションタスクが競争しているので、通常、パフォーマンス問題はいかなる他のアプリケーション・プログラムのようにも存在するでしょう。 このアプローチのための唯一の正当化がすぐに輸送サービスの簡単な実装を開発する必要性です。 輸送であると実装されたNBSは、トランスポート・プロトコル正当性テストシステムの基礎としてこのアプローチを使用することで議定書を作ります。 以来、性能はNBS実装の目標ではありませんでした。
McCoy [Page 20] RFC 1008 June 1987
マッコイ[20ページ]RFC1008 1987年6月
the ease of development and maintenance made this approach attractive.
開発とメインテナンスの容易さで、このアプローチは魅力的になりました。
2.3 Independent processing element attached to a system bus.
2.3の独立している処理要素はシステムバスに付きました。
Implementation of the transport service on an independent processor that attaches to the system bus may provide substantial performance improvements over other approaches. As computing power and memory have become cheaper this approach has become realistic. Examples include the Intel implementation of iNA-961 on a variety of multibus boards such as the iSBC 186/51 and the iSXM 554. Similar products have been developed by Motorola and by several independent vendors of IBM PC add-ons. This approach requires that the transport software operate on an independent hardware set running under operating system code developed to support the communications software environment. Communication with the application programs takes place across the system bus using some simple, proprietary vendor protocol. Careful engineering can provide the application programmer with a standard interface to the communications processor that is similar to the interface to the input/output subsystem.
システムバスに付く独立しているプロセッサにおける輸送サービスの実装はかなりの性能改良を他のアプローチの上に提供するかもしれません。 コンピューティングパワーとメモリが、より安くなるのに従って、このアプローチは現実的になりました。 例はiSBC186/51やiSXM554などのさまざまなマルチバスボードのiNA-961のインテル実装を含んでいます。 類似品はモトローラとIBM PCアドオンのいくつかの独立しているベンダーによって開発されました。 このアプローチは、輸送ソフトウェアがオペレーティングシステムコードの下における稼働がコミュニケーションソフトウェア環境であるとサポートするために発展させた独立しているハードウェアセットを経営するのを必要とします。 アプリケーション・プログラムとのコミュニケーションは、システムバスの向こう側に何らかの簡単で、独占であるベンダープロトコルを使用することで行われます。 慎重な工学は入力/出力サブシステムへのインタフェースと同様のコミュニケーションプロセッサへの標準インターフェースをアプリケーション・プログラマーに提供できます。
The advantages of this approach are mainly concentrated upon enhanced performance both for the host applications and the communications service. Depending on such factors as the speed of the communications processor and the system bus, data communications throughput may improve by one or two orders of magnitude over that available from host operating system integrated implementations. Throughput for host applications should also improve since the communications processing and interrupt handling for timers and data links have been removed from the host processor. The communications mechanism used between the host and communication processors is usually sufficiently simple that no real burden is added to either processor.
このアプローチの利点はホストアプリケーションと情報提供サービスのための高められた性能に主に集結されます。 コミュニケーションプロセッサとシステムバスの速度のような要素によって、データ通信スループットが1時までに向上したかもしれませんか、またはホスト・オペレーティング・システムからそれの上の有効な2つの桁は実装を統合しました。 また、ホストアプリケーションのためのスループットは、ホスト処理装置からタイマとデータ・リンクのためのコミュニケーション処理と割込み処理を取り除いたので、向上するべきです。 ホストと通信プロセッサの間で使用されるコミュニケーションメカニズムは通常十分簡単なそんなに本当の負担がどちらのプロセッサにも加えられるということです。
The disadvantages for this approach are caused by complexity in developing the communications software. Software development for the communications board cannot be supported with the standard operating system tools. A method of downloading the processor board and debugging the communications software may be required; a trade-off could be to put the code into firmware or microcode. The communications software must include at least a hardware monitor and, more typically, a small operating system to support such functions as interprocess communication, buffer management, flow control, and task synchronization. Debugging of the user to communication subsystem interface may involve several levels of system software and hardware.
このアプローチのための損失は複雑さによってコミュニケーションソフトウェアを開発する際に引き起こされます。 標準のオペレーティングシステムツールでコミュニケーションボードのためのソフトウェア開発をサポートすることができません。 プロセッサボードをダウンロードして、コミュニケーションソフトウェアをデバッグするメソッドが必要であるかもしれません。 トレードオフはファームウェアかマイクロコードにコードを入れることであることができました。 コミュニケーションソフトウェアは、プロセス間通信、バッファ管理、フロー制御、およびタスク同期化のような機能をサポートするために少なくともハードウェア・モニタと、より典型的に小さいオペレーティングシステムを含まなければなりません。 コミュニケーションサブシステム・インタフェースへのユーザのデバッグはいくつかのレベルのシステムソフトとハードウェアにかかわるかもしれません。
The design of the processing element can follow conventional lines, in which a single processor handling almost all of the operation of the protocol. However, with inexpensive processor and memory chips now available, a multiprocessor design is economically viable. The diagram below shows one such design, which almost directly
処理要素のデザインは在来線に従うことができます、プロトコルの操作のほとんどすべてを扱うどのa単一のプロセッサで。 しかしながら、安価なプロセッサとメモリー用チップが現在利用可能な状態で、マルチプロセッサデザインは経済的に実行可能です。 ダイヤグラムの下がそのようなデザインの1つを示している、どれ、ほとんど直接。
McCoy [Page 21] RFC 1008 June 1987
マッコイ[21ページ]RFC1008 1987年6月
corresponds to the structure of the formal description. There are several advantages to this design:
形式的記述の構造に対応しています。 このデザインのいくつかの利点があります:
1) management of CPU and memory resources is at a minimum;
1) CPUとメモリリソースの管理が最小限であります。
2) essentially no resource contention;
2) 本質的にはリソース主張がありません。
3) transport connection operation can be written in microcode,
separate from network service handling;
3) 輸送接続操作は、マイクロコードに書かれていて、ネットワーク・サービス取り扱いから別々である場合があります。
4) transport connections can run with true parallelism;
4) 輸送の接続は本当の平行関係と共に走ることができます。
5) throughput is not limited by contention of connections for CPU
and network access; and
5) スループットはCPUのための接続とネットワークアクセスの主張で制限されません。 そして
6) lower software complexity, due to functional separation.
6) 機能分離によるソフトウェアの複雑さを下げてください。
Possible disadvantages are greater inflexibility and hardware complexity. However, these might be offset by lower development costs for microcode, since the code separation should provide overall lower code complexity in the TPE and the TPM implementations.
可能な損失は、より大きい不屈とハードウェアの複雑さです。 しかしながら、コード分離が提供するべきであるので、これらの力がマイクロコードのために低い開発コストによって相殺されて、TPEとTPM実装における総合的な下側のコードの複雑さを提供してください。
In this system, the TPE instantiates a TPM by enabling its clock. Incoming Outgoing are passed to the TPMs along the memory bus. TPDUs TPDUs from a TPM are sent on the output data bus. The user interface controller accepts connect requests from the user and directs them to the TPE. The TPE assigns a connection reference and informs the interface controller to direct further inputs for this connection to the designated TPM. The shared TPM memory is analogous to the exported variables of the TPM modules in the formal description, and is used by the TPE to input TPDUs and other information to the TPM.
このシステムでは、TPEは、時計を可能にすることによって、TPMを例示します。 入って来るOutgoingはメモリバスに沿ったTPMsに渡されます。 出力データバスでTPMからのTPDUs TPDUsを送ります。 コントローラが受け入れるユーザーインタフェースは、ユーザから要求を接続して、TPEにそれらを向けます。 TPEは、この接続のために指定されたTPMにさらなる入力を向けるために接続参照を割り当てて、インタフェースコントローラを知らせます。 共有されたTPMメモリは、形式的記述における、TPMモジュールのエクスポートしている変数に類似していて、TPDUsと他の情報をTPMに入力するのにTPEによって使用されます。
In summary, the off-loading of communications protocols onto independent processing systems attached to a host processor across a system bus is quite common. As processing power and memory become cheaper, the amount of software off-loaded grows. it is now typical to fine transport service available for several system buses with interfaces to operating systems such as UNIX, XENIX, iRMX, MS-DOS, and VERSADOS.
概要では、システムバスの向こう側にホスト処理装置に取り付けられた独立している処理システムへの通信規約の陸揚は全く一般的です。 処理能力とメモリが、より安くなるのに従って、積み下ろされたソフトウェアの量は成長します。それは現在、UNIXや、XENIXや、iRMXや、MS-DOSや、VERSADOSなどのオペレーティングシステムへのインタフェースでいくつかのシステムバスに利用可能なよい輸送サービスに典型的です。
McCoy [Page 22] RFC 1008 June 1987
マッコイ[22ページ]RFC1008 1987年6月
Legend: **** data channel
.... control channel
==== interface i/o bus
O channel or bus connection point
伝説: **** データ・チャンネル… 制御チャンネル==== インタフェース入出力バスOは、接続ポイントをチャネルを開設するか、またはバスで運びます。
user
input
*
*
__________V_________
| user interface | input bus
| controller |=================O==============O=======
|__________________| * *
* * *
* * _______*_______
* * | data buffers|
* * ...| TPM1 |
* * : |_____________|
* * : *
* * : *
_________ _____*__________ ________ __*____:______ *
| TPE | | TPE processor| |shared| | TPM1 | *
|buffers|***| | | TPM1 |***| processor | *
|_______| |______________| | mem. | |____________| *
* : : * |______| : *
* : : * * : *
* : : ***********O***********:********************
* : : memory bus : *
* : : : *
* : :...........................O...........*........
____*_________:___ clock enable *
| network | *
| interface |=========================================O========
| controller | output data bus
|________________|
*
*
V
to network
interface
ユーザ入力**__________V_________ | ユーザーインタフェース| 入力バス| コントローラ|=================O==============O======= |__________________| * * * * * * * _______*_______ * * | データバッファ| * * ...| TPM1| * * : |_____________| * * : * * * : * _________ _____*__________ ________ __*____:______ * | TPE| | TPEプロセッサ| |共有されます。| | TPM1| * |バッファ|***| | | TPM1|***| プロセッサ| * |_______| |______________| | mem。 | |____________| * * : : * |______| : * * : : * * : * * : : ***********O***********: *********************: : メモリバス: * * : : : * * : :...........................O.…*........ ____*_________:___ 時計は*を可能にします。| ネットワーク| * | インタフェース|=========================================O======== | コントローラ| 出力データバス|________________| * * ネットワーク・インターフェースへのV
2.4 Front end processor.
2.4フロントエンドプロセッサ。
A more traditional approach to off-loading communications protocols involves the use of a free-standing front end processor, an approach very similar to that of placing the transport service onto a board attached to the system bus. The difference is one of scale. Typical front end p interface locally as desirable, as long as such additions are strictly local (i.e., the invoking of such services does not
通信規約を積み下ろすことへの、より伝統的なアプローチは無料の地位のフロントエンドプロセッサ(システムバスに取り付けられたボードに輸送サービスを置くものと非常に同様のアプローチ)の使用にかかわります。 違いは1です。スケールについて。 局所的同じくらい望ましい典型的なフロントエンドpインタフェース、同じくらい長いときにそういうものとして、追加が厳密に地方である、(すなわち、そのようなサービスの呼び出しはそうしません。
McCoy [Page 23] RFC 1008 June 1987
マッコイ[23ページ]RFC1008 1987年6月
result in the exchange of TPDUs with the peer entity).
同輩実体があるTPDUsの交換における結果)
The interface between the user and transport is by nature asynchronous (although some hypothetical implementation that is wholly synchronous could be conjectured). This characteristic is due to two factors: 1) the interprocess communications (IPC) mechanism--used between the user and transport--decouples the two, and to avoid blocking the user process (while waiting for a response) requires an asynchronous response mechanism, and 2) there are some asynchronously-generated transport indications that must be handled (e.g., the arrival of user data or the abrupt termination of the transport connection due to network errors).
自然で、ユーザと輸送とのインタフェースは非同期です(何らかの完全に同時の仮定している実装を推測できましたが)。 この特性は2つの要素のためです: 1) そこのプロセス間通信(IPC) メカニズム(ユーザと輸送の間で使用される)は2の衝撃を吸収します、そして、ユーザ・プロセス(応答を待っている間)を妨げるのを避けるのが非同期な反応機構、および2を必要とする)は扱わなければならないいくつかの非同期に発生している輸送指摘(例えば、利用者データの到着かネットワーク誤りによる輸送接続の突然の終了)です。
If it is assumed that the user interface to transport is asynchronous, there are other aspects of the interface that are also predetermined. The most important of these is that transport service requests are confirmed twice. The first confirmation occurs at the time of the transport service request initiation. Here, interface routines can be used to identify invalid sequences of requests, such as a request to send data on a connection that is not yet open. The second confirmation occurs when the service request crosses the interface into the transport entity. The entity may accept or reject the request, depending on its resources and its assessment of connection (transport and network) status, priority, service quality.
輸送するユーザーインタフェースが非同期であると思われるなら、また、予定されるインタフェースの他の局面があります。 これらで最も重要であるのは、輸送サービスのリクエストが二度確認されるということです。 最初の確認は輸送サービスのリクエスト開始の時代起こります。 ここで、要求の無効の系列を特定するのにインタフェースルーチンを使用できます、まだオープンでない接続にデータを送るという要求のように。 サービスのリクエストが輸送実体にインタフェースを越えるとき、2番目の確認は起こります。 実体は、要求を受け入れるか、または拒絶するかもしれません、リソースとその接続(輸送して、ネットワークでつなぐ)状態の査定によって、優先権、サービス品質。
If the interface is to be asynchronous, then some mechanism must be provided to handle the asynchronous (and sometimes unexpected) events. Two ways this is commonly achieved are: 1) by polling, and 2) by a software interrupt mechanism. The first of these can be wasteful of host resources in a multiprogramming environment, while the second may be complicated to implement. However, if the interface is a combination of hardware and software, as in the cases discussed in Parts 2.3 and 2.4, then hardware interrupts may be available.
インタフェースが非同期であるつもりであるなら、非同期で(時々予期していません)のイベントを扱うために何らかのメカニズムを提供しなければなりません。 これが一般的に達成される2つの方法は以下の通りです。 1) 世論調査、およびソフトウェア中断メカニズムによる2で)。 これらの第1はマルチプログラミング環境におけるホストリソースで無駄である場合があります、2番目が道具に複雑にされるかもしれませんが。 しかしながら、インタフェースがParts2.3と2.4で議論したケースのようにハードウェアとソフトウェアの組み合わせであるなら、ハードウェア割込みは利用可能であるかもしれません。
One way of implementing the abstract services is to associate with each service primitive an actual function that is invoked. Such functions could be held in a special interface library with other functions and procedures that realize the interface. Each service primitive function would access the interprocess communication (IPC) mechanism as necessary to pass parameters to/from the transport entity.
抽象的なサービスを実装する1つの方法はそれぞれのサービスが原始的に呼び出される実際の関数を関連づけることです。 そのような機能は特別なインタフェース図書館にインタフェースがわかる他の機能と手順で保持されるかもしれません。 それぞれのサービス原始関数は、輸送実体からの/にパラメタを通過するために必要に応じてプロセス間通信(IPC)メカニズムにアクセスするでしょう。
The description of the abstract service in IS 8073 and N3756 implies that the interface must handle TSDUs of arbitrary length. This situation suggests that it may be useful to implement a TSDU as an object such as a file-pointer rather than as the message itself. In this way, in the sending entity, TPDUs can be formed by reading segments of TPDU-size from the file designated, without regard for the actual length of the file. In the receiving entity, each new
中の抽象的にサービスの記述は8073です、そして、N3756はインタフェースが任意の長さのTSDUsを扱わなければならないのを含意します。 この状況は、メッセージ自体としてというよりむしろファイル・ポインタなどのオブジェクトとしてTSDUを実装するのが役に立つかもしれないと示唆します。 このよう、送付実体では、ファイルの実際の長さへの尊敬なしで指定されたファイルからTPDU-サイズのセグメントを読むことによって、TPDUsを形成できます。 受信実体と、それぞれ新しいところで
McCoy [Page 24] RFC 1008 June 1987
マッコイ[24ページ]RFC1008 1987年6月
TPDU could be buffered in a file designated by a file-pointer, which would then be passed to the user when the EOT arrives. In the formal description of transport, this procedure is actually described, although explicit file-pointers and files are not used in the description. This method of implementing the data interface is not essentially different from maintaining a linked list of buffers. (A disk file is arranged in precisely this fashion, although the file user is usually not aware of the structure.)
次にEOTが到着するときユーザに渡されるだろうファイル・ポインタによって指定されたファイルでTPDUをバッファリングできました。 輸送の形式的記述では、この手順は実際に説明されます、明白なファイル・ポインタとファイルは記述では使用されませんが。 データインタフェースを実装するこのメソッドはバッファの繋がっているリストを維持するのと本質的には異なっていません。 (ファイルユーザは通常構造を意識していませんが、ディスクファイルは正確にこのファッションでアレンジされます。)
The abstract service definition describes the set of parameters that must be passed in each of the service primitives so that transport can act properly on behalf of the user. These parameters are required for the transport protocol to operate correctly (e.g., a called address must be passed with the connect request and the connect response must contain a responding address). The abstract service defintion does not preclude, however, the inclusion of local parameters. Local parameters may be included in the implementation of the service interface for use by the local entity. One example is a buffer management parameter passed from the user in connect requests and confirms, providing the transport entity with expected buffer usage estimates. The local entity could use this in implementing a more efficient buffer management strategy than would otherwise be possible.
抽象的なサービス定義は輸送が適切にユーザを代表して行動できるようにそれぞれに関するサービス基関数で通過しなければならないパラメタのセットについて説明します。 そして、これらのパラメタがトランスポート・プロトコルが正しく作動するのに必要である、(例えば、着呼アドレスで通らなければならない、要求を接続してください、接続、応答が応じるアドレスを含まなければならない、) しかしながら、抽象的なサービスdefintionはローカルのパラメタの包含を排除しません。 ローカルのパラメタは使用のためのサービスインタフェースの実装にローカル要素によって含まれるかもしれません。 1つの例が、パラメタがユーザから通ったバッファ管理が要求を接続するということであり、輸送実体を予想されるのに提供して、用法見積りをバッファリングするように確認します。 ローカル要素はそうでなければ、可能であるだろうより効率的なバッファ経営戦略を実装する際にこれを使用するかもしれません。
One issue that is of importance when designing and implementing a transport entity is the provision of a registration mechanism for transport users. This facility provides a means of identifying to the transport entity those users who are willing to participate in communications with remote users. An example of such a user is a data base management system, which ordinarily responds to connections requests rather than to initiate them. This procedure of user identification is sometimes called a "passive open". There are several ways in which registration can be implemented. One is to install the set of users that provide services in a table at system generation time. This method may have the disadvantage of being inflexible. A more flexible approach is to implement a local transport service primitive, "listen", to indicate a waiting user. The user then registers its transport suffix with the transport entity via the listen primitive. Another possibility is a combination of predefined table and listen primitive. Other parameters may also be included, such as a partially or fully qualified transport address from which the user is willing to receive connections. A variant on this approach is to provide an ACTIVE/PASSIVE local parameter on the connect request service primitive. Part 5 discusses this issue in more detail.
輸送実体を設計して、実装するとき重要な1冊は輸送ユーザのための登録メカニズムに関する条項です。 この施設はリモート・ユーザーとのコミュニケーションに参加しても構わないと思っているユーザを輸送実体に特定する手段を提供します。 そのようなユーザの例はそれらを開始するよりデータベースの管理システムです。(通常、そのシステムはむしろ接続要求に応じます)。 ユーザ登録名のこの手順は時々「開いている受動態」と呼ばれます。 登録を実装することができるいくつかの方法があります。 1つはシステム生成時にサービスをテーブルに供給するユーザのセットをインストールすることになっています。 このメソッドには、融通がきかないことの不都合があるかもしれません。 よりフレキシブルなアプローチは、待ちユーザを示すためには原始的にローカル運送サービスを実装するためには、「聴いてください」ということです。 を通して次に、ユーザが輸送実体に輸送接尾語を登録する、原始的に、聴いてください。 別の可能性は事前に定義されたテーブルの組み合わせです、そして、原始的に、聴いてください。 また、他のパラメタは含まれるかもしれません、ユーザが接続を受けても構わないと思っている部分的か完全に適切な輸送アドレスのように。 このアプローチでの異形がACTIVE/PASSIVEのローカルのパラメタを提供することになっている、原始的に要求サービスを接続してください。 パート5はさらに詳細にこの問題について議論します。
3.2 Flow control.
3.2フロー制御。
Interface flow control is generally considered to be a local implementation issue. However, in order to completely specify the behavior of the transport entity, it was necessary to include in the
一般に、インタフェースフロー制御はローカルの導入問題であると考えられます。 しかしながら、輸送実体の振舞いを完全に指定して、それが、中に含むのに必要でした。
McCoy [Page 25] RFC 1008 June 1987
マッコイ[25ページ]RFC1008 1987年6月
formal description a model of the control of data flow across the service boundaries of transport. The international standards for transport and the OSI reference model state only that interface flow control shall be provided but give no guidance on its features.
輸送のサービス境界の向こう側のデータフローのコントロールの形式的記述aモデル。 輸送のための世界規格とOSI参照モデルは、そのインタフェースフロー制御だけが特徴で提供しますが、指導を全く与えないだろうと述べます。
The actual mechanisms used to accomplish flow control, which need not explicitly follow the model in the formal description, are dependent on the way in which the interface itself is realized, i.e., what TSDUs and service primitives really are and how the transport entity actually communicates with its user, its environment, and the network service. For example, if the transport entity communicates with its user by means of named (UNIX) pipes, then flow control can be realized using a special interface library routine, which the receiving process invokes, to control the pipe. This approach also entails some consideration for the capacity of the pipe and blocking of the sending process when the pipe is full (discussed further in Part 3.3). The close correspondence of this interpretation to the model is clear. However, such an interpretation is apparently not workable if the user process and the transport entity are in physically separate processors. In this situation, an explicit protocol between the receiving process and the sending process must be provided, which could have the complexity of the data transfer portion of the Class 0 transport protocol (Class 2 if flow controlled). Note that the formal model, under proper interpretation, also describes this mechanism.
形式的記述で明らかにモデルに従う必要はないフロー制御を達成するのに使用される実際のメカニズムはインタフェース自体が実感される方法、すなわち、TSDUsとサービス基関数が本当にものであり、輸送実体が実際にどうユーザとコミュニケートするか、そして、環境、およびネットワーク・サービスに依存しています。 例えば、輸送実体が命名された(UNIX)パイプによってユーザとコミュニケートするなら、パイプを制御するのに、特別なインタフェースライブラリ・ルーチン(受信プロセスは呼び出す)を使用することでフロー制御を実現できます。 また、パイプが完全であるときに(Part3.3で、より詳しく、議論します)、このアプローチはパイプの容量と送付プロセスのブロッキングのための何らかの考慮を伴います。 モデルへのこの解釈の近い通信は明確です。 しかしながら、ユーザ・プロセスと輸送実体が肉体的に別々のプロセッサにあるなら、そのような解釈は明らかに実行可能ではありません。 この状況に、受信プロセスと送付プロセスの間の明白なプロトコル(Class0トランスポート・プロトコルのデータ転送部分の複雑さを持つことができた)を提供しなければなりません(流れが制御されたなら、2を分類してください)。 また、形式モデルが適切な解釈でこのメカニズムについて説明することに注意してください。
3.3 Interprocess communication.
3.3プロセス間通信。
One of the most important elements of a data communication system is the approach to interprocess communication (IPC). This is true because suites of protocols are often implemented as groups of cooperating tasks. Even if the protocol suites are not implemented as task groups, the communication system is a funnel for service requests from multiple user processes. The services are normally communicated through some interprocess pathway. Usually, the implementation environment places some restrictions upon the interprocess communications method that can be used. This section describes the desired traits of IPC for use in data communications protocol implementations, outlines some possible uses for IPC, and discusses three common and generic approaches to IPC.
データ通信システムの最も重要な原理の1つはプロセス間通信(IPC)へのアプローチです。 プロトコルのスイートが協力タスクのグループとしてしばしば実装されるので、これは本当です。 プロトコル群が任務群として実装されないでも、通信系は複数のユーザ・プロセスからのサービスのリクエストのための漏斗です。 通常、サービスはいくつかのインタプロセス小道を通って伝えられます。 通常、実装環境は使用できるプロセス間通信メソッドにいくつかの制限を置きます。 このセクションは、データ通信規約実装における使用のためにIPCの必要な特色について説明して、IPCのためにいくつかの可能な用途について概説して、IPCへの一般的、そして、ジェネリック3つのアプローチについて論じます。
To support the implementation of data communications protocols, IPC should possess several desirable traits. First, IPC should be transaction based. This permits sending a message without the overhead of establishing and maintaining a connection. The transactions should be confirmed so that a sender can detect and respond to non-delivery. Second, IPC should support both the synchronous and the asynchronous modes of message exchange. An IPC receiver should be able to ask for delivery of any pending messages and not be blocked from continuing if no messages are present. Optionally, the receiver should be permitted to wait if no messages
データ通信規約の実装をサポートするために、IPCには、いくつかの望ましい特色があるはずです。 まず最初に、IPCは基づくトランザクションであるべきです。 これは、接続を確立して、維持するオーバーヘッドなしでメッセージを送ることを許可します。 トランザクションは、送付者が非配送に検出して、応じることができるように、確認されるべきです。 2番目に、IPCは同期と交換処理の非同期モードの両方をサポートするはずです。 IPC受信機は、どんな未定のメッセージの配送も求めて、どんなメッセージも存在していないなら続くのを妨げるはずであることができません。 任意に、メッセージでないなら受信機が待つことが許可されるべきです。
McCoy [Page 26] RFC 1008 June 1987
マッコイ[26ページ]RFC1008 1987年6月
are present, or to continue if the path to the destination is congested. Third, IPC should preserve the order of messages sent to the same destination. This allows the use of the IPC without modification to support protocols that preserve user data sequence. Fourth, IPC should provide a flow control mechanism to allow pacing of the sender's transmission speed to that of the receiver.
存在している、目的地への経路が混雑しているなら、続きます。 3番目に、IPCは同じ目的地に送られたメッセージの注文を保存するはずです。 これで、変更のないIPCの使用は利用者データ系列を保存するプロトコルをサポートできます。 4番目に、IPCは、送付者の伝送速度を受信機のものに歩き回らせるのを許容するためにフロー制御メカニズムを提供するはずです。
The uses of IPC in implementation of data communication systems are many and varied. A common and expected use for IPC is that of passing user messages among the protocol tasks that are cooperating to perform the data communication functions. The user messages may contain the actual data or, more efficiently, references to the location of the user data. Another common use for the IPC is implementation and enforcement of local interface flow control. By limiting the number of IPC messages queued on a particular address, senders can be slowed to a rate appropriate for the IPC consumer. A third typical use for IPC is the synchronization of processes. Two cooperating tasks can coordinate their activities or access to shared resources by passing IPC messages at particular events in their processing.
データ通信システムの実装における、IPCの用途は、多くであって様々です。 IPCの一般的で予想された使用はプロトコルタスクの中の協力している、働くユーザメッセージにデータ伝送機能を通過するものです。 ユーザメッセージは実際のデータか、より効率的に利用者データの位置の参照を含むかもしれません。 IPCの別の一般の使用は、局所界面フロー制御の実装と実施です。 特定のアドレスに列に並ばせられたIPCメッセージの数を制限することによって、送付者をIPC消費者にとって、適切なレートまで遅くすることができます。 IPCの3番目の典型的な使用はプロセスの同期です。 2つの協力タスクが、彼らの処理における特定のイベントでメッセージをIPCに通過することによって、共用資源への彼らの活動かアクセスを調整できます。
More creative uses of IPC include buffer, timer, and scheduling management. By establishing buffers as a list of messages available at a known address at system initialization time, the potential exists to manage buffers simply and efficiently. A process requiring a buffer would simply read an IPC message from the known address. If no messages (i.e., buffers) are available, the process could block (or continue, as an option). A process that owned a buffer and wished to release it would simply write a message to the known address, thus unblocking any processes waiting for a buffer.
IPCの、より創造的な用途はバッファ、タイマ、およびスケジュール管理を含んでいます。 システム初期化時に知られているアドレスで利用可能なメッセージのリストとバッファを書き立てることによって、可能性は簡単に効率的にバッファを管理するために存在しています。 バッファを必要とするプロセスは知られているアドレスからIPCメッセージを単に読むでしょう。 どんなメッセージ(すなわち、バッファ)も利用可能でないなら、プロセスは立ち塞がるかもしれません(オプションとして、続いてください)。 バッファを所有していたプロセスとそれが単に知られているアドレスへのメッセージを書くリリースに願われて、その結果、いずれかも「非-妨げ」ると、バッファの待ちは処理されます。
To manage timers, messages can be sent to a known address that represents the timer module. The timer module can then maintain the list of timer messages with respect to a hardware clock. Upon expiration of a timer, the associated message can be returned to the originator via IPC. This provides a convenient method to process the set of countdown timers required by the transport protocol.
タイマを管理するために、タイマモジュールを表す知られているアドレスにメッセージを送ることができます。 そして、タイマモジュールはハードウェア時計に関してタイマメッセージのリストを維持できます。 タイマの満了のときに、IPCを通して関連メッセージを創始者に返すことができます。 これはトランスポート・プロトコルによって必要とされたカウントダウンタイマのセットを処理する便利な方法を提供します。
Scheduling management can be achieved by using separate IPC addresses for message classes. A receiving process can enforce a scheduling discipline by the order in which the message queues are read. For example, a transport process might possess three queues: 1) normal data from the user, 2) expedited data from the user, and 3) messages from the network. If the transport process then wants to give top priority to network messages, middle priority to expedited user messages, and lowest priority to normal user messages, all that is required is receipt of IPC messages on the highest priority queue until no more messages are available. Then the receiver moves to the next lower in priority and so on. More sophistication is possible by setting limits upon the number of consecutive messages received from each queue and/or varying the order in which each queue is examined.
メッセージのクラスに別々のIPCアドレスを使用することによって、スケジュール管理を達成できます。 受信プロセスはメッセージキューが読まれるオーダーでスケジューリング規律を実施できます。 例えば、輸送プロセスには、3つの待ち行列があるかもしれません: 1) 2歳のユーザからの)正常なデータはデータがユーザから速められて、ネットワークから3つの)メッセージを速められました。 メッセージをネットワークでつなぐために最優先を与える必需品、速められたユーザメッセージの中くらいの優先権、および正常なユーザメッセージの最も低い優先度、輸送プロセスであるなら、それ以上のメッセージが利用可能にならないまで、必要であるすべてが最優先待ち行列に関するIPCメッセージの領収書です。 そして、受信機は優先権においてより多くの下であるなどに次に移行します。 より多くの洗練が各待ち行列から受け取る、そして/または、各待ち行列が調べられるオーダーを変えながら連続したメッセージの数で制限を加えることによって、可能です。
McCoy [Page 27] RFC 1008 June 1987
マッコイ[27ページ]RFC1008 1987年6月
It is easy to see how a round-robin scheduling discipline could be implemented using this form of IPC.
IPCのこのフォームを使用することでどう連続スケジューリング規律を実装することができるだろうかを見るのは簡単です。
Approaches to IPC can be placed into one of three classes: 1) shared memory, 2) memory-memory copying, and 3) input/output channel copying. Shared memory is the most desirable of the three classes because the amount of data movement is kept to a minimum. To pass IPC messages using shared memory, the sender builds a small message referencing a potentially large amount of user data. The small message is then either copied from the sender's process space to the receiver's process space or the small message is mapped from one process space to another using techniques specific to the operating system and hardware involved. These approaches to shared memory are equivalent since the amount of data movement is kept to a minimum. The price to be paid for using this approach is due to the synchronization of access to the shared memory. This type of sharing is well understood, and several efficient and simple techniques exist to manage the sharing.
3つのクラスの1つにIPCへのアプローチを置くことができます: 1)共有メモリ、2)メモリメモリコピー、および3) 入出力チャネルコピー。 データ量運動が最小限に保たれるので、3つのクラスで共有メモリは最も望ましいです。 共有メモリを使用することでメッセージをIPCに通過するために、送付者は潜在的に多量の利用者データに参照をつける小さいメッセージを築き上げます。 次に、小さいメッセージが送付者のプロセススペースから受信機のプロセススペースまでコピーされるか、または小さいメッセージは別のものへのオペレーティングシステムに特定のテクニックを使用するスペースとハードウェアがかかわった1つのプロセスから写像されます。 データ量運動が最小限に保たれるので、共有メモリへのこれらのアプローチは同等です。 このアプローチを使用する代価は共有メモリへのアクセスの同期のためです。 このタイプの共有はよく理解されています、そして、いくつかの効率的で簡単なテクニックが、共有を管理するために存在しています。
Memory-memory copying is an approach that has been commonly used for IPC in UNIX operating system implementations. To pass an IPC message under UNIX data is copied from the sender's buffer to a kernel buffer and then from a kernel buffer to the receiver's buffer. Thus two copy operations are required for each IPC message. Other methods might only involve a single copy operation. Also note that if one of the processes involved is the transport protocol implemented in the kernel, the IPC message must only be copied once. The main disadvantage of this approach is inefficiency. The major advantage is simplicity.
メモリメモリコピーはUnixオペレーティングシステム実装でIPCに一般的に使用されたアプローチです。 IPCメッセージの下を通るために、UNIXデータは送付者のバッファからカーネルバッファまでそして、カーネルバッファから受信機のバッファまでコピーされます。 したがって、2つのコピー操作がそれぞれのIPCメッセージに必要です。 他のメソッドはただ一つのコピー操作を伴うだけであるかもしれません。 また、かかわったプロセスの1つがカーネルで実装されたトランスポート・プロトコルであるなら、一度IPCメッセージをコピーするだけでよいことに注意してください。 このアプローチの主な不都合は非能率です。 主要な利点は簡単さです。
When the processes that must exchange messages reside on physically separate computer systems (e.g., a host and front end), an input/output channel of some type must be used to support the IPC. In such a case, the problem is similar to that of the general problem of a transport protocol. The sender must provide his IPC message to some standard operating system output mechanism from where it will be transmitted via some physical medium to the receiver's operating system. The receiver's operating system will then pass the message on to the receiving process via some standard operating system input mechanism. This set of procedures can vary greatly in efficiency and complexity depending upon the operating systems and hardware involved. Usually this approach to IPC is used only when the circumstances require it.
メッセージを交換しなければならないプロセスが肉体的に別々のコンピュータ・システム(例えば、ホストとフロントエンド)の上に住んでいるとき、IPCをサポートするのにタイプの入出力チャネルを使用しなければなりません。 このような場合には、問題はトランスポート・プロトコルの一般的問題のものと同様です。 送付者はそれが物理的な媒体で伝えられるところから受信機のオペレーティングシステムまで何らかの標準のオペレーティングシステム出力メカニズムに彼のIPCメッセージを供給しなければなりません。 そして、受信機のオペレーティングシステムは何らかの標準のオペレーティングシステム入力メカニズムで受信プロセスにメッセージを通過するでしょう。 このセットの手順はかかわったオペレーティングシステムとハードウェアに依存する効率と複雑さにおいて大いに異なることができます。 事情がそれを必要とするときだけ、通常、IPCへのこのアプローチは使用されています。
3.4 Interface to real networks.
3.4は本当のネットワークに連結します。
Implementations of the class 4 transport protocol have been operated over a wide variety of networks including: 1) ARPANET, 2) X.25 networks, 3) satellite channels, 4) CSMA/CD local area networks, 5) token bus local area networks, and 6) token ring local area networks. This section briefly describes known instances of each use
操作されて、:さまざまなネットワークの上でクラス4トランスポート・プロトコルの実装を操作してあります。 1) アルパネット、2) X.25ネットワーク、3) 4歳の衛星チャンネル) CSMA/CDローカル・エリア・ネットワーク、5つの)トークンバスローカル・エリア・ネットワーク、および6) トークンリングローカル・エリア・ネットワーク。 このセクションは簡潔にそれぞれの使用の知られているインスタンスについて説明します。
McCoy [Page 28] RFC 1008 June 1987
マッコイ[28ページ]RFC1008 1987年6月
of class 4 transport and provides some quantitative evaluation of the performance expectations for transport over each network type.
クラスでは、4は、それぞれのネットワークタイプで輸送への業績期待の何らかの定量的評価を輸送して、提供します。
3.4.1 Issues.
3.4.1 問題。
The interface of the transport entity to the network service in general will be realized in a different way from the user interface. The network service processor is often separate from the host CPU, connected to it by a bus, direct memory access (DMA), or other link. A typical way to access the network service is by means of a device driver. The transfer of data across the interface in this instance would be by buffer-copying. The use of double-buffering reduces some of the complexity of flow control, which is usually accomplished by examining the capacity of the target buffer. If the transport processor and the network processor are distinct and connected by a bus or external link, the network access may be more complicated since copying will take place across the bus or link rather than across the memory board. In any case, the network service primitives, as they appear in the formal description and IS 8073 must be carefully correlated to the actual access scheme, so that the semantics of the primitives is preserved. One way to do this is to create a library of routines, each of which corresponds to one of the service primitives. Each routine is responsible for sending the proper signal to the network interface unit, whether this communication is directly, as on a bus, or indirectly via a device driver. In the case of a connectionless network service, there is only one primitive, the N_DATA_request (or N_UNIT_DATA_request), which has to be realized.
一般に、ネットワーク・サービスへの輸送実体のインタフェースはユーザーインタフェースと異なった方法で実感されるでしょう。 ネットワークサービスプロセッサは、ホストCPUからしばしば別々であって、バス、ダイレクトメモリアクセス(DMA)、または他のリンクのそばでそれに接続されています。 ネットワーク・サービスにアクセスする典型的な方法がデバイスドライバによってあります。インタフェースの向こう側のデータ転送が、バッファでコピーすることによって、この場合あるでしょう。 二重にバッファリングしていることの使用は通常、目標バッファの容量を調べることによって達成されるフロー制御の複雑さのいくつかを減少させます。 輸送プロセッサとネットワークプロセッサが異なってバスか外部のリンクのそばで接続されているなら、コピーがバスかメモリ基板の向こう側にというよりむしろリンクの向こう側に行われるので、ネットワークアクセスは、より複雑であるかもしれません。 どのような場合でも、形式的記述に現れるように基関数を修理して、ネットワークは8073が慎重に実際のアクセス体系に関連しなければなりません、基関数の意味論が保存されるようにことです。 これをする1つの方法はルーチンのライブラリを創設することです。それはそれぞれサービス基関数の1つに対応します。 それぞれのルーチンは適切な信号をネットワーク・インターフェースユニットに送るのに原因となります、このコミュニケーションが直接、バス、または間接的にデバイスドライバであるか否かに関係なく。コネクションレスなネットワーク・サービスの場合には、原始的な1つしかありません、N_DATA_要求(または、N_UNIT_DATA_要求)、実感されなければならないどれ。
In the formal description, flow control to the NSAP is controlled by by a Slave module, which exerts the "backpressure" on the TPM if its internal queue gets too long. Incoming flow, however, is controlled in much the same way as the flow to the transport user is controlled. The implementor is reminded that the formal description of the flow control is specified for completeness and not as an implementation guide. Thus, an implementation should depend upon actual interfaces in the operating environment to realize necessary functions.
形式的記述では、NSAPへのフロー制御によってSlaveモジュールで制御されます。(内部の待ち行列が長くなり過ぎるなら、それは、「背圧」をTPMに出します)。 大体同じようなやり方で輸送ユーザへの流れが制御されているので、しかしながら、入って来る流れは制御されています。 作成者はフロー制御の形式的記述が実装ガイドではなく、完全性に指定されるのを思い出させられています。 したがって、実装は、必要な機能がわかるために操作環境における実際のインタフェースによるべきです。
3.4.2 Instances of operation.
3.4.2 操作のインスタンス。
3.4.2.1 ARPANET
3.4.2.1 アルパネット
An early implementation of the class 4 transport protocol was developed by the NBS as a basis for conformance tests [NBS83]. This implementation was used over the ARPANET to communicate between NBS, BBN, and DCA. The early NBS implementation was executed on a PDP-11/70. A later revision of the NBS implementation has been moved to a VAX-11/750 and VAX-11/7;80. The Norwegian Telecommunication Administration (NTA) has implemented class 4 transport for the UNIX BSD 4.2 operating system to run on a VAX [NTA84]. A later NTA implementation runs on a Sun 2-120 workstation. The University of
順応の基礎が[NBS83]をテストするとき、クラス4トランスポート・プロトコルの早めの実装はNBSによって開発されました。 この実装は、NBSと、BBNと、DCAの間で交信するのにアルパネットの上で使用されました。 早めのNBS実装はPDP-11/70で実行されました。 NBS実装の後の改正はVAX-11/750とVAX-11/7に動かされました; 80。 UNIX BSD4.2オペレーティングシステムがVAXの上で作業するように、ノルウェーのTelecommunication政権(NTA)はクラス4に輸送を実装しました[NTA84]。 後のNTA実装はSun2-120ワークステーションで動きます。 大学
McCoy [Page 29] RFC 1008 June 1987
マッコイ[29ページ]RFC1008 1987年6月
Wisconsin has also implemented the class 4 transport protocol on a VAX-11/750 [BRI85]. The Wisconsin implementation is embedded in the BSD 4.2 UNIX kernel. For most of these implementations class 4 transport runs above the DOD IP and below DOD application protocols.
また、ウィスコンシンは、VAX-11/750[BRI85]でクラスが4トランスポート・プロトコルであると実装しました。 ウィスコンシン実装はBSD4.2UNIXカーネルに埋め込まれています。 これらの実装の大部分のために、クラス4輸送はDOD IPの上と、そして、DODアプリケーション・プロトコルの下に稼働しています。
3.4.2.2 X.25 networks
3.4.2.2 X.25ネットワーク
The NBS implementations have been used over Telenet, an X.25 public data network (PDN). The heaviest use has been testing of class 4 transport between the NBS and several remotely located vendors, in preparation for a demonstration at the 1984 National Computing Conference and the 1985 Autofact demonstration. Several approaches to implementation were seen in the vendors' systems, including ones similar to those discussed in Part 6.2. At the Autofact demonstration many vendors operated class 4 transport and the ISO internetwork protocol across an internetwork of CSMA/CD and token bus local networks and Accunet, an AT&T X.25 public data network.
NBS実装はテレネット、X.25公衆データネットワーク(PDN)の上で使用されました。 最も重い使用は、NBSの間のクラス4輸送のテストと1984年のNational Computingコンファレンスと1985年のAutofactデモンストレーションにおけるデモンストレーションに備えたいくつかの離れて見つけられたベンダーです。 実装へのPart6.2で議論したものと同様のものを含むベンダーのシステムのいくつかのアプローチが見られました。 Autofactデモンストレーションのときに、多くのベンダーがトークンバスのCSMA/CD、企業内情報通信網、およびAccunet(AT&T X.25公衆データネットワーク)のインターネットワークの向こう側にクラス4輸送とISOインターネットワークプロトコルを運用しました。
3.4.2.3 Satellite channels.
3.4.2.3 衛星は精神を集中します。
The COMSAT Laboratories have implemented class 4 transport for operation over point-to-point satellite channels with data rates up to 1.544 Mbps [CHO85]. This implementation has been used for experiments between the NBS and COMSAT. As a result of these experiments several improvements have been made to the class 4 transport specification within the international standards arena (both ISO and CCITT). The COMSAT implementation runs under a proprietary multiprocessing operating system known as COSMOS. The hardware base includes multiple Motorola 68010 CPUs with local memory and Multibus shared memory for data messages.
コムサット研究所はデータ信号速度で操作のためのポイントツーポイントの上のクラス4輸送に衛星チャンネルを1.544Mbpsまで実装しました[CHO85]。 この実装はNBSとコムサットの間の実験に使用されました。 これらの実験の結果、世界規格アリーナ(ISOとCCITTの両方)の中でいくつかの改良をクラス4輸送仕様にしました。 コミュニケーションサテライトコーポレーション実装はCOSMOSとして知られている独占多重処理オペレーティングシステムで実行されます。 ハードウェアベースはローカルの記憶がある複数のモトローラ68010CPUとデータメッセージのためのMultibus共有メモリを含んでいます。
3.4.2.4 CSMA/CD networks.
3.4.2.4 CSMA/CDネットワーク。
The CSMA/CD network as defined by the IEEE 802.3 standard is the most popular network over which the class 4 transport has been implemented. Implementations of transport over CSMA/CD networks have been demonstrated by: AT&T, Charles River Data Systems, Computervision, DEC, Hewlitt-Packard, ICL, Intel, Intergraph, NCR and SUN. Most of these were demonstrated at the 1984 National Computer Conference [MIL85b] and again at the 1985 Autofact Conference. Several of these vendors are now delivering products based on the demonstration software.
IEEE802.3規格によって定義されるCSMA/CDネットワークはクラス4輸送が実装された最もポピュラーなネットワークです。 CSMA/CDネットワークの上の輸送の実装は以下によって示されました。 これらのAT&T、チャールズ川のデータシステムズ、Computervision、12月、Hewlitt-パッカード、ICL、インテル、インターグラフ、NCR、および日曜日のMostは1984年のNationalコンピュータコンファレンス[MIL85b]において再び1985年のAutofactコンファレンスにおいてデモをしました。 これらのいくつかのベンダーが現在、デモンストレーションソフトウェアに基づく製品を提供しています。
3.4.2.5 Token bus networks.
3.4.2.5 トークンバスネットワーク。
Due to the establishment of class 4 transport as a mandatory protocol within the General Motor's manufacturing automation protocol (MAP), many implementations have been demonstrated operating over a token bus network as defined by the IEEE 802.4 standard. Most past implementations relied upon a Concord Data Systems token interface module (TIM) to gain access to the 5 Mbps broadband 802.4 service.
ゼネラルモーターズのマニュファクチャリング・オートメーション・プロトコル(MAP)の中の義務的なプロトコルとしてのクラス4輸送の設立のため、多くの実装が、IEEE802.4規格によって定義されるようにトークンバスネットワークの上で作動しながら、示されました。 実装の先における大部分は、広帯域の802.4サービスを5Mbpsへのアクセスに獲得するためにコンコードデータシステムズトークンインタフェース・モジュール(TIM)を当てにされました。
McCoy [Page 30] RFC 1008 June 1987
マッコイ[30ページ]RFC1008 1987年6月
Several vendors have recently announced boards supporting a 10 Mbps broadband 802.4 service. The newer boards plug directly into computer system buses while the TIM's are accessed across a high level data link control (HDLC) serial channel. Vendors demonstrating class 4 transport over IEEE 802.4 networks include Allen-Bradley, AT&T, DEC, Gould, Hewlett-Packard, Honeywell, IBM, Intel, Motorola, NCR and Siemens.
いくつかのベンダーが最近、10Mbpsが広帯域の802.4サービスであるとサポートするボードを発表しました。 TIMのものがハイレベル・データ・リンク制御(HDLC)の連続のチャンネルの向こう側にアクセスされている間、より新しいボードは直接コンピュータシステムバスのプラグを差し込みます。 IEEE802.4ネットワークの上のクラス4輸送を示すベンダーがアレン-ブラッドリー、AT&T、12月、グールド、ヒューレット・パッカード、ハネウェル、IBM、インテル、モトローラ、NCR、およびシーメンスを含めます。
3.4.2.6 Token ring networks.
3.4.2.6 トークンリングネットワーク。
The class 4 transport implementations by the University of Wisconsin and by the NTA run over a 10 Mbps token ring network in addition to ARPANET. The ring used is from Proteon rather than the recently finished IEEE 802.5 standard.
ウィスコンシン大学とNTAによるクラス4輸送実装はアルパネットに加えた10Mbpsトークンリングネットワークをひきます。 使用されるリングは最近完成しているIEEE802.5規格よりむしろProteonから来ています。
3.4.3 Performance expectations.
3.4.3 業績期待。
Performance research regarding the class 4 transport protocol has been limited. Some work has been done at the University of Wisconsin, at NTA, at Intel, at COMSAT, and at the NBS. The material presented below draws from this limited body of research to provide an implementor with some quantitative feeling for the performance that can be expected from class 4 transport implementations using different network types. More detail is available from several published reports [NTA84, BRI85, INT85, MIL85b, COL85]. Some of the results reported derive from actual measurements while other results arise from simulation. This distinction is clearly noted.
クラス4トランスポート・プロトコルに関するパフォーマンス調査は制限されました。 ウィスコンシン大学においてNTAにおいてインテルにおいてコムサットにおいてNBSにおいていくらかの仕事をしました。 以下で寄贈された材料は、クラス4輸送実装から異なったネットワークタイプを使用することで予想できる性能に関する何らかの量的な感じを作成者に提供するために研究のこの限られたボディーから描かれます。 その他の詳細はいくつかの発行されたレポート[NTA84、BRI85、INT85、MIL85b、COL85]から利用可能です。 結果のいくつかが、他の結果がシミュレーションから起こっている間実測を得るように報告しました。 この区別は明確に注意されます。
3.4.3.1 Throughput.
3.4.3.1 スループット。
Several live experiments have been conducted to determine the throughput possible with implementations of class 4 transport. Achievable throughput depends upon many factors including: 1) CPU capabilities, 2) use or non-use of transport checksum, 3) IPC mechanism, 4) buffer management technique, 5) receiver resequencing, 6) network error properties, 7) transport flow control, 8) network congestion and 9) TPDU size. Some of these are specifically discussed elsewhere in this document. The reader must keep in mind these issues when interpreting the throughput measures presented here.
いくつかのライブ実験が、クラス4輸送の実装で可能なスループットを測定するために行われました。 依存して、:達成可能なスループットは多くの要素に依存します。 1) CPU能力、2) 使用か輸送チェックサム、3の)非使用 IPCメカニズム、4) バッファ管理のテクニック、5)受信機再配列、6つの)ネットワーク誤り所有地、7)輸送フロー制御、8)ネットワークの混雑、および9) TPDUサイズ。 ほかの場所で明確に本書ではこれらの或るものについて議論します。 ここで寄贈されたスループット測定を解釈するとき、読者はこれらの問題を覚えておかなければなりません。
The University of Wisconsin implemented class 4 transport in the UNIX kernel for a VAX-11/750 with the express purpose of measuring the achievable throughput. Throughputs observed over the ARPANET ranged between 10.4 Kbps and 14.4 Kbps. On an unloaded Proteon ring local network, observed throughput with checksum ranged between 280 Kbps and 560 Kbps. Without checksum, throughput ranged between 384 Kbps and 1 Mbps.
ウィスコンシン大学はVAX-11/750のために達成可能なスループットを測定するはっきりとした目的でUNIXカーネルにおける輸送をクラス4に実装しました。 アルパネットの上で観測されたスループットは10.4Kbpsと14.4Kbpsの間で及びました。 降ろされたProteonでは、チェックサムが280Kbpsと560Kbpsの間で及んで、企業内情報通信網、観測されたスループットを鳴らしてください。 チェックサムがなければ、スループットは384Kbpsと1Mbpsの間で及びました。
The COMSAT Laboratories implemented class 4 transport under a proprietary multiprocessor operating system for a multiprocessor
マルチプロセッサのための独占マルチプロセッサオペレーティングシステムの下におけるクラス4輸送であると実装されたコムサット研究所
McCoy [Page 31] RFC 1008 June 1987
マッコイ[31ページ]RFC1008 1987年6月
68010 hardware architecture. The transport implementation executed on one 68010 while the traffic generator and link drivers executed on a second 68010. All user messages were created in a global shared memory and were copied only for transmission on the satellite link. Throughputs as high as 1.4 Mbps were observed without transport checksumming while up to 535 Kbps could be achieved when transport checksums were used. Note that when the 1.4 Mbps was achieved the transport CPU was idle 20% of the time (i.e., the 1.544 Mbps satellite link was the bottleneck). Thus, the transport implementation used here could probably achieve around 1.9 Mbps user throughput with the experiment parameters remaining unchanged. Higher throughputs are possible by increasing the TPDU size; however, larger messages stand an increased chance of damage during transmission.
68010 ハードウェアアーキテクチャ。 トラフィックジェネレータである間に16万8010で実行された輸送実装と2番目の68010で処刑されたリンクドライバー。 すべてのユーザメッセージが、グローバルな共有メモリで作成されて、トランスミッションのためだけに衛星中継の上にコピーされました。 輸送チェックサムが使用されたとき、最大535Kbpsを達成できましたが、1.4Mbpsとしての高い同じくらいスループットは輸送checksummingなしで観測されました。 1.4Mbpsが達成されたとき、輸送CPUが20%の割合で使用されていなかったという(すなわち、1.544に、Mbps衛星中継はボトルネックでした)メモ。 したがって、ここで使用された輸送実装はたぶん1.9Mbpsの周りに実験パラメタが変わりがないユーザスループットを実現するかもしれません。 より高いスループットはTPDUサイズを増強することによって、可能です。 しかしながら、より大きいメッセージには、トランスミッションの間、損害の増強された見込みがあります。
Intel has implemented a class 4 transport product for operation over a CSMA/CD local network (iNA-960 running on the iSBC 186/51 or iSXM 552). Intel has measured throughputs achieved with this combination and has published the results in a technical analysis comparing iNA-960 performance on the 186/51 with iNA-960 on the 552. The CPU used to run transport was a 6 MHz 80186. An 82586 co-processor was used to handle the medium access control. Throughputs measured ranged between 360 Kbps and 1.32 Mbps, depending on the parameter values used.
インテルは、クラスがCSMA/CD企業内情報通信網(iSBC186/51かiSXM552の上で作業するiNA-960)の上の操作のための4輸送製品であると実装しました。 インテルは、この組み合わせで達成されたスループットを測定して、552で186/51に関するiNA-960性能をiNA-960と比べるテクニカル分析における結果を発表しました。 輸送を実行するのに使用されるCPUは6MHz80186でした。 82586コプロセッサは、媒体アクセス制御を扱うのに使用されました。 値が使用したパラメタによって、測定されたスループットは360Kbpsと1.32Mbpsの間で及びました。
Simulation of class 4 transport via a model developed at the NBS has been used to predict the performance of the COMSAT implementation and is now being used to predict the performance of a three processor architecture that includes an 8 MHz host connected to an 8 MHz front end over a system bus. The third processor provides medium access control for the specific local networks being modeled. Early model results predict throughputs over an unloaded CSMA/CD local network of up to 1.8 Mbps. The same system modeled over a token bus local network with the same transport parameters yields throughput estimates of up to 1.6 Mbps. The token bus technology, however, permits larger message sizes than CSMA/CD does. When TPDUs of 5120 bytes are used, throughput on the token bus network is predicted to reach 4.3 Mbps.
NBSで開発されたモデルを通したクラス4輸送のシミュレーションは、コミュニケーションサテライトコーポレーション実装の性能を予測するのに使用されて、現在、8MHzのホストを含んでいる3プロセッサアーキテクチャの性能がシステムバスの上で8MHzのフロントエンドに接続したと予測するのに使用されています。 3番目のプロセッサはモデル化される特定の企業内情報通信網に媒体アクセス制御を提供します。 早めのモデル結果は最大1.8Mbpsの降ろされたCSMA/CD企業内情報通信網の上でスループットを予測します。 同じシステムは同じ輸送パラメタがある企業内情報通信網がスループット見積りを1.6Mbpsまでもたらすトークンバスの上でモデル化されました。 しかしながら、トークンバス技術はCSMA/CDがそうするより大きいメッセージサイズを可能にします。 5120バイトのTPDUsが使用されているとき、トークンバスネットワークに関するスループットは4.3Mbpsに達すると予測されます。
3.4.3.2 Delay.
3.4.3.2 延着してください。
The one-way delay between sending transport user and receiving transport user is determined by a complex set of factors. Readers should also note that, in general, this is a difficult measure to make and little work has been done to date with respect to expected one-way delays with class 4 transport implementations. In this section a tutorial is given to explain the factors that determine the one-way delay to be expected by a transport user. Delay experiments performed by Intel are reported [INT85], as well as some simulation experiments conducted by the NBS [MIL85a].
輸送ユーザを送って、輸送ユーザを受けることの間の一方向遅れは複雑なセットの要素で決定します。 また、読者は一般に、これが作るのが難しい測定であり、これまでクラス4輸送実装で予想された一方向遅れに関してほとんど仕事をしていないことに注意するべきです。 このセクションでは、一方向遅れが輸送ユーザによって予想されることを決定する要素について説明するためにチュートリアルを与えます。 インテルによって行われた遅れ実験はNBS[MIL85a]によって行われたいくつかのシミュレーション実験と同様に報告されます[INT85]。
McCoy [Page 32] RFC 1008 June 1987
マッコイ[32ページ]RFC1008 1987年6月
The transport user can generally expect one-way delays to be determined by the following equation.
一般に、輸送ユーザは、一方向遅れが以下の方程式で決定すると予想できます。
D = TS + ND + TR + [IS] + [IR] (1)
Dはt+ノースダコタ+TR+[あります]+[IR]と等しいです。(1)
where:
どこ:
[.] means the enclosed quantity may be 0
[]、同封の量が0であるかもしれないことを意味します。
D is the one-way transport user delay,
Dは一方向輸送ユーザ遅れです。
TS is the transport data send processing time,
TSはデータが処理時間を送る輸送です。
IS is the internet datagram send processing time,
データグラムが送るインターネットは処理時間です。
ND is the network delay,
ノースダコタはネットワーク遅延です。
IR is the internet datagram receive processing
time, and
そしてIRがインターネットデータグラムが処理時間を受けるということである。
TR is the transport data receive processing time.
TRによる輸送データが処理時間を受けるということです。
Although no performance measurements are available for the ISO internetwork protocol (ISO IP), the ISO IP is so similar to the DOD IP that processing times associated with sending and receiving datagrams should be the about the same for both IPs. Thus, the IS and IR terms given above are ignored from this point on in the discussion. Note that many of these factors vary depending upon the application traffic pattern and loads seen by a transport implementation. In the following discussion, the transport traffic is assumed to be a single message.
どんな性能測定もISOインターネットワークプロトコル(ISO IP)に利用可能ではありませんが、ISO IPがとてもDOD IPと同様であるので、送受信データグラムに関連している処理時間は両方のIPsのためのほぼ同じくらいであるべきです。 このようにして、そして、上がこの地点から先は議論で無視されるというIR用語当然のこと。 輸送実装によって見られたアプリケーショントラフィック・パターンと負荷によって、これらの要素の多くが異なることに注意してください。 以下の議論では、輸送トラフィックはただ一つのメッセージであると思われます。
The value for TS depends upon the CPU used, the IPC mechanism, the use or non-use of checksum, the size of the user message and the size of TPDUs, the buffer management scheme in use, and the method chosen for timer management. Checksum processing times have been observed that include 3.9 us per octet for a VAX-11/750, 7.5 us per octet on a Motorola 68010, and 6 us per octet on an Intel 80186. The class 4 transport checksum algorithm has considerable effect on achievable performance. This is discussed further in Part 7. Typical values for TS, excluding the processing due to the checksum, are about 4 ms for CPUs such as the Motorola 68010 and the Intel 80186. For 1024 octet TPDUs, checksum calculation can increase the TS value to about 12 ms.
TSのための値は使用されるCPUとIPCメカニズムとチェックサムの使用か非使用とユーザメッセージのサイズとTPDUs、使用中であるバッファ管理体系、およびタイマ管理に選ばれたメソッドのサイズに依存します。 VAX-11/750のために八重奏単位で3.9に私たちを含んでいるチェックサム処理回数が観測されました、7.5、モトローラ68010、および6における八重奏あたりの私たち、インテル80186における八重奏あたりの私たち クラス4輸送チェックサムアルゴリズムは達成可能な性能にかなりの影響を与えます。 Part7で、より詳しくこれについて議論します。 チェックサムによる処理を除いて、TSのための典型的な値はモトローラ68010やインテル80186などのCPUへのおよそ4msです。 1024年の八重奏TPDUs、計算が増強できるチェックサムのために、TSはおよそ12に原稿を評価します。
The value of TR depends upon similar details as TS. An additional consideration is whether or not the receiver caches (buffers) out of order TPDUs. If so, the TR will be higher when no packets are lost (because of the overhead incurred by the resequencing logic). Also,
TRの値はTSとして同様の詳細に依存します。 追加的約因は受信機が(バッファ)故障しているTPDUsをキャッシュするかどうかということです。 どんなパケットも無くならないとき(再配列論理によって被られたオーバーヘッドによる)、そうだとすれば、TRは、より高くなるでしょう。 また
McCoy [Page 33] RFC 1008 June 1987
マッコイ[33ページ]RFC1008 1987年6月
when packets are lost, TR can appear to increase due to transport resequencing delay. When out of order packets are not cached, lost packets increase D because each unacknowledged packet must be retransmitted (and then only after a delay waiting for the retransmission timer to expire). These details are not taken into account in equation 1. Typical TR values that can be expected with non-caching implementations on Motorola 68010 and Intel 80186 CPUs are approximately 3 to 3.5 ms. When transport checksumming is used on these CPUs, TR becomes about 11 ms for 1024 byte TPDUs.
パケットが無くなるとき、TRは、遅れを再配列する輸送のため増加するように見えることができます。 故障しているパケットがキャッシュされないとき、それぞれの不承認のパケットを再送しなければならないので(そしてそして、再送信タイマーが期限が切れるのを待つ遅れの後にだけ)、無くなっているパケットはDを増強します。 これらの詳細は方程式1で考慮に入れられません。 モトローラ68010とインテル80186個のCPUの上に非キャッシュ実装がある状態で予想できる典型的なTR値がおよそ3〜3.5原稿When輸送checksummingがこれらのCPUの上に使用されるということである、TRは1024年のバイトのTPDUsのためのおよそ11msになります。
The value of ND is highly variable, depending on the specific network technology in use and on the conditions in that network. In general, ND can be defined by the following equation.
ノースダコタの値は非常に可変です、そのネットワークで使用中の特定のネットワーク技術と、そして、条件によって。 一般に、以下の方程式でノースダコタを定義できます。
ND = NQ + MA + TX + PD + TQ (2)
ノースダコタ=NQ+MA+テキサス+PD+TQ(2)
where:
どこ:
NQ is network queuing delay,
NQはネットワーク列を作り遅れです。
MA is medium access delay,
MAは中型のアクセス遅延です。
TX is message transmission time,
テキサスはメッセージトランスミッション時間です。
PD is network propagation delay, and
そしてPDがネットワーク伝播遅延である。
TQ is transport receive queuing delay.
TQによる輸送が遅れを列に並ばせながら受信されるということです。
Each term of the equation is discussed in the following paragraphs.
以下のパラグラフで方程式の各用語について議論します。
Network queuing delay (NQ) is the time that a TPDU waits on a network transmit queue until that TPDU is the first in line for transmission. NQ depends on the size of the network transmit queue, the rate at which the queue is emptied, and the number of TPDUs already on the queue. The size of the transmit queue is usually an implementation parameter and is generally at least two messages. The rate at which the queue empties depends upon MA and TX (see the discussion below). The number of TPDUs already on the queue is determined by the traffic intensity (ratio of mean arrival rate to mean service rate). As an example, consider an 8 Kbps point-to-point link serving an eight message queue that contains 4 messages with an average size of 200 bytes per message. The next message to be placed into the transmit queue would experience an NQ of 800 ms (i.e., 4 messages times 200 ms). In this example, MA is zero. These basic facts permit the computation of NQ for particular environments. Note that if the network send queue is full, back pressure flow control will force TPDUs to queue in transport transmit buffers and cause TS to appear to increase by the amount of the transport queuing delay. This condition depends on application traffic patterns but is ignored for
ネットワーク列を作り遅れ(NQ)はTPDUがネットワークで待っている時間がそのTPDUがトランスミッションのための系列で1日になるまで待ち行列を伝えるということです。 NQはサイズに依存します。ネットワークでは、待ち行列のときに既にTPDUsの待ち行列、待ち行列が空にされているレート、および数を伝えてください。 伝わってください。サイズ、待ち行列は、通常実装パラメタであり、一般に、少なくとも2つのメッセージです。 待ち行列が空になるレートはMAとテキサスに依存します(以下での議論を見てください)。 呼量(平均である到着率対平均であるサービス率の比率)によって既に待ち行列のTPDUsの数は測定されます。 例として、8Kbpsが1メッセージあたり200バイトの平均のサイズがある4つのメッセージを含む8メッセージキューに役立つポイントツーポイント接続であると考えてください。 待ち行列を伝えてください。置かれる次のメッセージ、800ms(すなわち、4つのメッセージ回200ms)のNQを経験するでしょう。 この例では、MAはゼロです。 これらの基本の事実は特定の環境のためにNQの計算を可能にします。 送信キューがネットワークであるならフロー制御によって、TPDUsが輸送でやむを得ず列を作るという完全で、逆圧力であるというメモはバッファと輸送の列を作りの量に従って遅れを増強するように見える原因TSを伝えます。 この状態は型に基づいて作りますが、トラフィックが無視されるアプリケーションに依存します。
McCoy [Page 34] RFC 1008 June 1987
マッコイ[34ページ]RFC1008 1987年6月
the purpose of this discussion.
この議論の目的。
The value of MA depends upon the network access method and on the network congestion or load. For a point-to-point link MA is zero. For CSMA/CD networks MA depends upon the load, the number of stations, the arrival pattern, and the propagation delay. For CSMA/CD networks MA has values that typically range from zero (no load) up to about 3 ms (80% loads). Note that the value of MA as seen by individual stations on a CSMA/CD network is predicted (by NBS simulation studies) to be as high as 27 ms under 70% loads. Thus, depending upon the traffic patterns, individual stations may see an average MA value that is much greater than the average MA value for the network as a whole. On token bus networks MA is determined by the token rotation time (TRT) which depends upon the load, the number of stations, the arrival pattern, the propagation delay, and the values of the token holding time and target rotation times at each station.
MAの値はネットワークアクセス法とネットワークの混雑か負荷に依存します。 ポイントツーポイント接続に関しては、MAはゼロです。 CSMA/CDネットワークのために、MAは負荷、ステーションの数、到着パターン、および伝播遅延に依存します。 CSMA/CDネットワークのために、MAには、ゼロから通常変化する値(負荷がない)がおよそ3ms(80%の負荷)まであります。 CSMA/CDネットワークの個々のステーションのそばの見られるとしてのMAの値がmsの70%未満の27の荷重と同じくらい高いと予測されることに(NBSシミュレーション研究で)注意してください。 したがって、個々のステーションは全体でネットワークに平均したMA値よりはるかにすばらしい平均したMA値を見て、トラフィック・パターンによるかもしれません。 トークンバスネットワークでは、MAは各ステーションに時間と目標回転回数を保持するトークンの負荷、ステーションの数、到着パターン、伝播遅延、および値に依存するトークン回転時間(TRT)までに断固としています。
For small networks of 12 stations with a propagation delay of 8 ns, NBS simulation studies predict TRT values of about 1 ms for zero load and 4.5 ms for 70% loads for 200 byte messages arriving with exponential arrival distribution. Traffic patterns also appear to be an important determinant of target rotation time. When a pair of stations performs a continuous file transfer, average TRT for the simulated network is predicted to be 3 ms for zero background load and 12.5 ms for 70% background load (total network load of 85%).
8ナノ秒の伝播遅延がある12のステーションの小さいネットワークのために、NBSシミュレーション研究は指数の到着分配と共に届くゼロ荷重のためのおよそ1msと200バイトのメッセージのための70%の負荷のための4.5msのTRT値を予測します。 また、トラフィック・パターンは目標回転時間の重要な決定的であるように見えます。 1組のステーションが連続したファイル転送を実行するとき、シミュレートされたネットワークのための平均したTRTはバックグラウンド負荷でない3msであると予測されます、そして、70%のバックグラウンドのための12.5msが(85%の総ネットワーク積荷)をロードします。
The message size and the network transmission speed directly determine TX. Typical transmission speeds include 5 and 10 Mbps for standard local networks; 64 Kbps, 384 Kbps, or 1.544 Mbps for point-to-point satellite channels; and 9.6 Kbps or 56 Kbps for public data network access links.
メッセージサイズとネットワーク送信速度は直接テキサスを決定します。 典型的な伝送速度は標準の企業内情報通信網のための5と10Mbpsを含んでいます。 二地点間衛星チャンネルのための64キロビット毎秒、384Kbps、または1.544Mbps。 そして、公衆データネットワークアクセスのための9.6Kbpsか56Kbpsがリンクします。
The properties of the network in use determine the values of PD. On an IEEE 802.3 network, PD is limited to 25.6 us. For IEEE 802.4 networks, the signal is propagated up-link to a head end and then down-link from the head end. Propagation delay in these networks depends on the distance of the source and destination stations from the head end and on the head end latency. Because the maximum network length is much greater than with IEEE 802.3 networks, the PD values can also be much greater. The IEEE 802.4 standard requires that a network provider give a value for the maximum transmission path delay. For satellite channels PD is typically between 280 and 330 ms. For the ARPANET, PD depends upon the number of hops that a message makes between source and destination nodes. The NBS and NTIA measured ARPANET PD average values of about 190 ms [NTI85]. In the ARPA internet system the PD is quite variable, depending on the number of internet gateway hops and the PD values of any intervening networks (possibly containing satellite channels). In experiments on an internetwork containing a a satellite link to Korea, it was determined by David Mills [RFC85] that internet PD values could range from 19 ms to 1500 ms. Thus, PD values ranging from 300 to 600 ms
使用中のネットワークの特性はPDの値を決定します。 IEEE802.3ネットワークでは、PDは25.6に制限されます。私たち。 IEEEに関しては、802.4のネットワークであり、信号はギヤエンドからギヤエンドまでのアップリンクが伝播されて、次に、ダウンリンクを伝播されます。 これらのネットワークの伝播遅延はギヤエンドからのソースと目的地ステーションの距離と、そして、ギヤエンドの潜在に依存します。 最大のネットワークの長さがIEEEよりはるかに大きいので、また、802.3のネットワーク、PD値もはるかに大きい場合があります。 IEEE802.4規格は、ネットワーク内の提供者が最大の伝送経路遅延のために値を与えるのを必要とします。 衛星チャンネルにおいて、PDが通常280〜330原稿Forアルパネットである、PDはメッセージがソースと目的地ノードの間で作るホップの数に依存します。 NBSとNTIAはおよそ190ms[NTI85]のARPANET PD平均値を測定しました。 ARPAインターネットシステムでは、PDはかなり可変です、インターネットゲートウェイホップの数とどんな介入しているネットワークのPD値にもよって(ことによると衛星チャンネルを含んでいて)。 a衛星中継を韓国に含むインターネットワークの実験では、それはデヴィッド・ミルズで決定している[RFC85]インターネットPD値が19msから1500年まで及ぶことができたのを原稿Thusでした、PD値が300〜600msから変化して
McCoy [Page 35] RFC 1008 June 1987
マッコイ[35ページ]RFC1008 1987年6月
can be considered as typical for ARPANET internetwork operation.
アルパネットインターネットワーク操作に同じくらい典型的に考えることができてください。
The amount of time a TPDU waits in the network receive queue before being processed by the receiving transport is represented by TQ, similar to NQ in that the value of TQ depends upon the size of the queue, the number of TPDUs already in the queue, and the rate at which the queue is emptied by transport.
TQの値が待ち行列のサイズ、既に待ち行列における、TPDUsの数、および待ち行列が輸送で空にされているレートによるので、TPDUがネットワークで待つ時間に処理されて、受信輸送はTQによって表されます、NQと同様であるということである前の待ち行列を受けてください。
Often the user delay D will be dominated by one of the components. On a satellite channel the principal component of D is PD, which implies that ND is a principal component by equation (2). On an unloaded LAN, TS and TR might contribute most to D. On a highly loaded LAN, MA may cause NQ to rise, again implying that ND is a major factor in determining D.
しばしば、ユーザ遅れDはコンポーネントの1つによって支配されるでしょう。 衛星チャンネルの上では、Dの主成分はPDです。(そのPDはノースダコタが方程式(2)によって主成分であることを含意します)。 降ろされたLANでは、TSとTRは非常にロードされたLANをD.Onに最も寄付するかもしれなくて、MAはNQを上昇させるかもしれません、ノースダコタがDを決定することにおいて重要な要因であることを再び含意して。
Some one-way delay measures have been made by Intel for the iNA-960 product running on a 6 MHz 80186. For an unloaded 10 Mbps CSMA/CD network the Intel measures show delays as low as 22 ms. The NBS has done some simulations of class 4 transport over 10 Mbps CSMA/CD and token bus networks. These (unvalidated) predictions show one-way delays as low as 6 ms on unloaded LANs and as high as 372 ms on CSMA/CD LANs with 70% load.
いくつかの一方向遅れ測定が6MHz80186で走るiNA-960製品のためにインテルによって行われます。 降ろされた10Mbps CSMA/CDネットワークのために、インテルの測定は、NBSが10Mbps CSMA/CDの上のクラス4輸送のいくつかのシミュレーションをした原稿とトークンがネットワークをバスで運ぶのを22としての低い同じくらい遅れに示します。 これらの(非有効にしました)予測は6msと同じくらい低く一方向遅れを70%があるCSMA/CD LANの372msがロードされるのと降ろされた同じくらいLANと同じくらい高く示しています。
3.4.3.3 Response time.
3.4.3.3 応答時間。
Determination of transport user response time (i.e., two-way delay) depends upon many of the same factors discussed above for one-way delay. In fact, response time can be represented by equation 3 as shown below.
輸送ユーザ応答時間(すなわち、両用遅れ)の決断は一方向遅れのために上で議論した同じ要素の多くに依存します。 事実上、方程式3で以下に示すように応答時間を表すことができます。
R = 2D + AS + AR (3)
Rは+ アルゴンとして2D+と等しいです。(3)
where:
どこ:
R is transport user response time,
Rは輸送ユーザ応答時間です。
D is one-way transport user delay,
Dは一方向輸送ユーザ遅れです。
AS is acknowledgement send processing time, and
そしてASによる承認が処理時間を送るということである。
AR is acknowledgement receive processing time.
ARによる承認が処理時間を受けるということです。
D has been explained above. AS and AR deal with the acknowledgement sent by transport in response to the TPDU that embodies the user request.
Dは上で説明されました。 ASとARは輸送でユーザ要求を具体化するTPDUに対応して送られた承認に対処します。
AS is simply the amount of time that the receiving transport must spend to generate an AK TPDU. Typical times for this function are about 2 to 3 ms on processors such as the Motorola 68010 and the Intel 80186. Of course the actual time required depends upon factors such as those explained for TS above.
ASは単に受信輸送がAK TPDUを生成するために費やされなければならない時間です。 この機能のための典型的な時勢はモトローラ68010やインテル80186などのプロセッサの上のおよそ2〜3msです。 もちろん、必要である実際の時間は上のTSのために説明されたものなどの要素に依存します。
McCoy [Page 36] RFC 1008 June 1987
マッコイ[36ページ]RFC1008 1987年6月
The amount of time, AR, that the sending transport must spend to process a received AK TPDU. Determination of the actual time required depends upon factors previously described. Note that for AR and AS, processing when the checksum is included takes somewhat longer. However, AK TPDUs are usually between 10 and 20 octets in length and therefore the increased time due to checksum processing is much less than for DT TPDUs.
時間、AR、送付輸送がaを処理するために費やされなければならないのがAK TPDUを受けました。 必要である実際の現代の決断は以前に説明された要素に依存します。 チェックサムが含まれているとき、ARとASに関して、処理にいくらか時間がかかることに注意してください。 しかしながら、通常、AK TPDUsが長さが10〜20の八重奏であり、したがって、チェックサム処理による増強された時間はDT TPDUsよりはるかに少ないです。
No class 4 transport user response time measures are available; however, some simulations have been done at the NBS. These predictions are based upon implementation strategies that have been used by commercial vendors in building microprocessor-based class 4 transport products. Average response times of about 21 ms on an unloaded 10 Mbps token bus network, 25 ms with 70% loading, were predicted by the simulations. On a 10 Mbps CSMA/CD network, the simulations predict response times of about 17 ms for no load and 54 ms for a 70% load.
いいえクラス4輸送ユーザ応答時間測定は利用可能です。 しかしながら、いくつかのシミュレーションをNBSにしました。 これらの予測はマイクロプロセッサを拠点とするクラス4輸送製品を造る際に商業ベンダーによって使用された実装戦略に基づいています。 降ろされた10Mbpsトークンバスネットワークのおよそ21msの平均応答倍(70%がロードされている25ms)はシミュレーションで予測されました。 10Mbps CSMA/CDネットワークでは、シミュレーションは負荷でないおよそ17msと70%の負荷のための54msの応答倍を予測します。
3.5 Error and status reporting.
3.5 誤りと状態報告。
Although the abstract service definition for the transport protocol specifies a set of services to be offered, the actual set of services provided by an implementation need not be limited to these. In particular, local status and error information can be provided as a confirmed service (request/response) and as an asynchronous "interrupt" (indication). One use for this service is to allow users to query the transport entity about the status of their connections. An example of information that could be returned from the entity is:
トランスポート・プロトコルのための抽象的なサービス定義は提供される1セットのサービスを指定しますが、実装によって提供された実際のサービスはこれらに制限される必要はありません。 特に、確認されたサービス(要求/応答)として非同期な「中断」(指示)としてローカルの状態とエラー情報を提供できます。 このサービスの1つの使用はユーザが彼らの接続の状態に関して輸送実体について質問するのを許容することです。 実体から返すことができた情報に関する例は以下の通りです。
o connection state
o current send sequence number
o current receive and transmit credit windows
o transport/network interface status
o number of retransmissions
o number of DTs and AKs sent and received
o current timer values
o 接続州のo電流が電流が受ける一連番号oを送って、DTsの「再-トランスミッション」o番号のクレジット窓のo輸送/ネットワーク・インターフェース状態o番号を伝えて、AKsはo現在のタイマ値を送って、受けました。
Another use for the local status and error reporting service is for administration purposes. Using the service, an administrator can gather information such as described above for each open connection. In addition, statistics concerning the transport entity as a whole can be obtained, such as number of transport connections open, average number of connections open over a given reporting period, buffer use statistics, and total number of retransmitted DT TPDUs. The administrator might also be given the authority to cancel connections, restart the entity, or manually set timer values.
ローカルの状態と誤りニュース配信の別の使用は管理目的のためのものです。 サービスを利用して、管理者はそれぞれのオープンな接続のために上で説明されるように情報を収集できます。 さらに、輸送の接続戸外の数などのように全体の缶としての輸送実体に関する統計を得て、平均したポートの数は以上と報告する当然のこと、バッファ使用の上で統計、および再送されたDT TPDUsの総数を開きます。 また、接続を中止するか、実体を再開するか、または手動でタイマ値を設定する権威を管理者に与えるかもしれません。
McCoy [Page 37] RFC 1008 June 1987
マッコイ[37ページ]RFC1008 1987年6月
4 Entity resource management.
4 実体資源管理。
4.1 CPU management.
4.1 CPU管理。
The formal description has implicit scheduling of TPM modules, due to the semantics of the Estelle structuring principles. However, the implementor should not depend on this scheduling to obtain optimal behavior, since, as stated in Part 1, the structures in the formal description were imposed for purposes other than operational efficiency.
形式的記述には、TPMモジュールの暗黙のスケジューリングが原則を構造化するエステルの意味論のためあります。 しかしながら、作成者は最適の振舞いを得るためにこのスケジューリングを当てにするべきではありません、形式的記述における構造が経営効率以外の目的のためにPart1に述べられているように課されたので。
Whether by design or by default, every implementation of the transport protocol embodies some decision about allocating the CPU resource among transport connections. The resource may be monolithic, i.e. a single CPU, or it may be distributed, as in the example design given in Part 2.3. In the former, there are two simple techniques for apportioning CPU processing time among transport connections. The first of these, first-come/first-served, consists of the transport entity handling user service requests in the order in which they arrive. No attempt is made to prevent one transport connection from using an inordinate amount of the CPU.
故意にかデフォルトでであることにかかわらず、トランスポート・プロトコルのあらゆる実装がCPUリソースを輸送の接続に割り当てることに関する何らかの決定を具体化します。 リソースは一枚岩的であるかもしれません、すなわち、単一のCPU、または、それが分配されるかもしれません、Part2.3で与えられた例のデザインのように。 前者には、輸送の接続でCPU処理時間を分配するための2つの簡易技術があります。 これらの1番目、最初に来ている/は、それらが到達するオーダーで最初に、役立って、輸送実体取り扱いユーザサービスのリクエストから成ります。 1つの輸送接続がCPUの過度の量を使用するのを防ぐのを試みを全くしません。
The second simple technique is round-robin scheduling of connections. Under this method, each transport connection is serviced in turn. For each connection, transport processes one user service request, if there is one present at the interface, before proceeding to the next connection.
2番目の簡易技術は接続の連続スケジューリングです。 このメソッドの下では、順番にそれぞれの輸送接続にサービスを提供します。 各接続のために、輸送は1つのユーザサービスのリクエストを処理します、インタフェースに存在している1つがあれば、次の接続に続く前に。
The quality of service parameters provided in the connection request can be used to provide a finer-grained strategy for managing the CPU. The CPU could be allocated to connections requiring low delay more often while those requiring high throughput would be served less often but for longer periods (i.e., several connections requiring high throughput might be serviced in a concurrent cluster).
CPUを管理するための、よりきめ細かに粒状の戦略を提供するのに接続要求に提供されたサービスの質パラメタは使用できます。 よりしばしば高生産性を必要とするものが、よりしばしば役立たれるでしょうが、より長い期間、低い遅れを必要とする接続にCPUを割り当てることができました(すなわち、高生産性を必要とするいくつかの接続が同時発生のクラスタでサービスを提供されるかもしれません)。
For example, in the service sequence below, let "T" represent m > 0 service requests, each requiring high throughput, let "D" represent one service request requiring low delay and let the suffix n = 1,2,3 represent a connection identifier, unique only within a particular service requirement type (T,D). Thus T1 represents a set of service requests for connection 1 of the service requirement type T, and D1 represents a service set (with one member) for connection 1 of service requirement type D.
例えば、「T」は、それぞれ高生産性を必要として、>0サービスが要求するmを表して、「D」に低い遅れを必要とする1つのサービスのリクエストを表させて、以下のサービス系列では、1、2、接尾語n=3に接続識別子を表させてください、特定のサービス要件タイプ(T、D)だけの中でユニークです。 したがって、T1はサービス要件タイプTの接続1のために1セットのサービスのリクエストを表します、そして、D1はサービス要件タイプDの接続1のために、サービスセット(1人のメンバーがいる)を表します。
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1…
If m = 4 in this service sequence, then service set D1 will get worst-case service once every seventh service request processed. Service set T1 receives service on its four requests only once in
このサービス系列のm=4であるなら、あらゆる7番目のサービスのリクエストがいったん処理されると、サービスセットD1は最悪の場合サービスを得るでしょう。 サービスセットT1は中で一度だけ4つの要求にサービスを受けます。
McCoy [Page 38] RFC 1008 June 1987
マッコイ[38ページ]RFC1008 1987年6月
fourteen requests processed.
14の要求が処理されました。
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1... | | | | | | | 3 requests | 4 | 3 | 4 | 3 |
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1… | | | | | | | 3つの要求| 4 | 3 | 4 | 3 |
This means that the CPU is allocated to T1 29% ( 4/14 ) of the available time, whereas D1 obtains service 14% ( 1/7 ) of the time, assuming processing requirements for all service requests to be equal. Now assume that, on average, there is a service request arriving for one out of three of the service requirement type D connections. The CPU is then allocated to the T type 40% ( 4/10 ) while the D type is allocated 10% ( 1/10 ).
これは、CPUをT1に使用可能時間の29%(4/14)割り当てますが、D1が現代のサービス14%( 1/7 )を得ることを意味します、処理がすべてのサービスのリクエストが等しいという要件であると仮定して。 今度は、1のために3つのサービス要件タイプD接続から到着するサービスのリクエストが平均的にあると仮定してください。 10%(1/10)をDタイプに割り当てますが、そして、TタイプにCPUを40%(4/10)割り当てます。
4.2 Buffer management.
4.2は管理をバッファリングします。
Buffers are used as temporary storage areas for data on its way to or arriving from the network. Decisions must be made about buffer management in two areas. The first is the overall strategy for managing buffers in a multi-layered protocol environment. The second is specifically how to allocate buffers within the transport entity.
バッファがデータに一時記憶域として途中で使用される、または、ネットワークから到着すること。 2つの領域でバッファ管理に関して決定をしなければなりません。 1番目は、多層性のプロトコル環境でバッファを管理するための総合的な戦略です。 2番目は明確に輸送実体の中にどうバッファを割り当てるかということです。
In the formal description no details of buffer strategy are given, since such strategy depends so heavily on the implementation environment. Only a general mechanism is discussed in the formal description for allocating receive credit to a transport connection, without any expression as to how this resource is managed.
形式的記述では、バッファ戦略の詳細は全く明らかにされません、そのような戦略が非常に大いに実装環境によるので。 割り当てが輸送接続にクレジットを受けるこのリソースがどう管理されるかに関する少しも式なしで形式的記述で一般的機構だけについて議論します。
Good buffer management should correlate to the traffic presented by the applications using the transport service. This traffic has implications as well for the performance of the protocol. At present, the relationship of buffer strategy to optimal service for a given traffic distribution is not well understood. Some work has been done, however, and the reader is referred to the work of Jeffery Spirn [SPI82, SPI83] and to the experiment plan for research by the NBS [HEA85] on the effect of application traffic patterns on the performance of Class 4 transport.
良いバッファ管理は輸送サービスを使用しながらアプリケーションで提示されたトラフィックに関連するべきです。 このトラフィックには、また、意味がプロトコルの性能のためにあります。 現在のところ、与えられたトラヒック分配のための最適のサービスへのバッファ戦略の関係はよく理解されていません。 しかしながら、いくらかの仕事をしました、そして、読者はジェフェリーSpirn[SPI82、SPI83]の仕事とClass4輸送の性能へのアプリケーショントラフィック・パターンの効果のNBS[HEA85]による調査のために実験プランを参照します。
4.2.1 Overall buffer strategy.
4.2.1 総合的なバッファ戦略。
Three schemes for management of buffers in a multilayered environment are described here. These represent a spectrum of possibilities available to the implementor. The first of these is a strictly layered approach in which each entity in the protocol hierarchy, as a process, manages its own pool of buffers independently of entities at other layers. One advantage of this approach is simplicity; it is not necessary for an entity to coordinate buffer usage with a resource manager which is serving the needs of numerous protocol entities. Another advantage is modularity. The interface presented to entities in other layers is
多層の環境におけるバッファの管理の3つの体系がここで説明されます。 これらは作成者にとって、利用可能な可能性のスペクトルを表します。 これらの1番目は他の層の実体の如何にかかわらずプロトコル階層の各実体がプロセスとしてそれ自身のバッファのプールを管理する厳密に層にされたアプローチです。 このアプローチの1つの利点が簡単さです。 実体が多数のプロトコル実体の必要性に役立っている資源管理プログラムでバッファの使用状況を調整するのは必要ではありません。 別の利点はモジュール方式です。 他の層の実体に提示されたインタフェースはそうです。
McCoy [Page 39] RFC 1008 June 1987
マッコイ[39ページ]RFC1008 1987年6月
well defined; protocol service requests and responses are passed between layers by value (copying) versus by reference (pointer copying). In particular, this is a strict interpretation of the OSI reference model, IS 7498 [ISO84b], and the protocol entities hide message details from each other, simplifying handling at the entity interfaces.
よく定義されます。 参照(指針コピー)で値の(コピー)による層が要求と応答に渡されるサービスについて議定書の中で述べてください。 これは、特に、OSI参照モデルの厳しい解釈であり、7498[ISO84b]です、そして、プロトコル実体はメッセージの詳細に互いから隠します、実体インタフェースで取り扱いを簡素化して。
The single disadvantage to a strictly layered scheme derives from the value-passing nature of the interface. Each time protocol data and control information is passed from one layer to another it must be copied from one layer's buffers to those of another layer. Copying between layers in a multi-layered environment is expensive and imposes a severe penalty on the performance of the communications system, as well as the computer system on which it is running as a whole.
厳密に層にされた体系へのただ一つの不都合がインタフェースの値が一時的な自然に由来しています。 情報が1より移られるプロトコルデータとコントロールが層にされるたびに別のものに、1つの層のバッファから別の層のものまでそれをコピーしなければなりません。 層の間に多層性の環境でコピーするのは、高価であり、通信網の性能に厳しい刑罰を課します、それが全体で稼働する予定であるコンピュータ・システムと同様に。
The second scheme for managing buffers among multiple protocol layers is buffer sharing. In this approach, buffers are a shared resource among multiple protocol entities; protocol data and control information contained in the buffers is exchanged by passing a buffer pointer, or reference, rather than the values as in the strictly layered approach described above. The advantage to passing buffers by reference is that only a small amount of information, the buffer pointer, is copied from layer to layer. The resulting performance is much better than that of the strictly layered approach.
複数のプロトコル層の中でバッファを管理することの2番目の体系はバッファ共有です。 このアプローチでは、バッファは複数のプロトコル実体の中の共用資源です。 上で説明された厳密に層にされたアプローチのようにバッファでバッファ指針、または値よりむしろ参照に合格することによって、データと制御情報が含んだプロトコルを交換します。 参照でバッファを渡す利点は少量の情報(バッファ指針)だけが層から層までコピーされるということです。 結果として起こる性能は厳密に層にされたアプローチのものよりはるかに良いです。
There are several requirements that must be met to implement buffer sharing. First, the host system architecture must allow memory sharing among protocol entities that are sharing the buffers. This can be achieved in a variety of ways: multiple protocol entities may be implemented as one process, all sharing the same process space (e.g., kernel space), or the host system architecture may allow processes to map portions of their address space to common buffer areas at some known location in physical memory.
バッファ共有を実装するために満たさなければならないいくつかの必要条件があります。 まず最初に、ホストシステム構築はバッファを共有しているプロトコル実体の中で共有されるメモリを許容しなければなりません。 さまざまな方法でこれを達成できます: プロセスが1つのプロセス、同じすべて共有しているプロセススペース(例えば、カーネルスペース)、またはホストシステム構築で物理的なメモリのいくらかの知られている位置の共通バッファ領域にそれらのアドレス空間の部分を写像できるとき、複数のプロトコル実体が実装されるかもしれません。
A buffer manager is another requirement for implementing shared buffers. The buffer manager has the responsibility of providing buffers to protocol entities when needed from a list of free buffers and recycling used buffers back into the free list. The pool may consist of one or more lists, depending on the level of control desired. For example, there could be separate lists of buffers for outgoing and incoming messages.
バッファマネージャは、共有バッファを実装するための別の要件です。 バッファマネージャには、無料のバッファのリストから必要であると、実体について議定書の中で述べるバッファを提供する責任があります、そして、再生は免税品リストの中にバッファを使用して戻しました。 望まれていた管理水準によって、プールは1つ以上のリストから成るかもしれません。 例えば、送受信のメッセージのためのバッファの別々のリストがあるかもしれません。
The protocol entities must be implemented in such a way as to cooperate with the buffer manager. While this appears to be an obvious condition, it has important implications for the strategy used by implementors to develop the communications system. This cooperation can be described as follows: an entity at layer N requests and is allocated a buffer by the manager; each such buffer
プロトコル実体をバッファマネージャと協力するほどそのような方法で実装しなければなりません。 これは明白な状態であるように見えますが、それは通信網を開発するのに作成者によって使用された戦略のために重要な意味を持っています。 以下の通りこの協力について説明できます: 実体、Nが要求して、割り当てられる層では、aはマネージャをバッファリングします。 そのような各バッファ
McCoy [Page 40] RFC 1008 June 1987
マッコイ[40ページ]RFC1008 1987年6月
is returned to the manager by some entity at layer N - k (outgoing data) or N + k (incoming data).
返す、層Nの何らかの実体によるマネージャ--k(発信データ)かN+k(受信データ)。
Protocol entities also must be designed to cooperate with each other. As buffers are allocated and sent towards the network from higher layers, allowance must be made for protocol control information to be added at lower layers. This usually means allocating oversized buffers to allow space for headers to be prepended at lower layers. Similarly, as buffers move upward from the network, each protocol entity processes its headers before passing the buffer on. These manipulations can be handled by managing pointers into the buffer header space.
互いと協力するようにプロトコル実体も設計しなければなりません。 バッファをより高い層からネットワークに向かって割り当てて、送るとき、プロトコル制御情報が下層で加えられるのを考慮をしなければなりません。 通常、これは、ヘッダーが下層でprependedされるように紙面を割くために特大のバッファを割り当てることを意味します。 同様に、バッファがネットワークから上方に動くとき、バッファを伝える前に、それぞれのプロトコル実体はヘッダーを処理します。 バッファヘッダースペースに指針を管理することによって、これらの操作を扱うことができます。
In their pure forms, both strictly layered and shared buffer schemes are not practical. In the former, there is a performance penalty for copying buffers. On the other hand, it is not practical to implement buffers that are shared by entities in all layers of the protocol hierarchy: the lower protocol layers (OSI layers 1 - 4) have essentially static buffer requirements, whereas the upper protocol layers (OSI layers 5 - 7) tend to be dynamic in their buffer requirements. That is, several different applications may be running concurrently, with buffer requirements varying as the set of applications varies. However, at the transport layer, this latter variation is not visible and variations in buffer requirements will depend more on service quality considerations than on the specific nature of the applications being served. This suggests a hybrid scheme in which the entities in OSI layers 1 - 4 share buffers while the entities in each of the OSI layers 5 - 7 share in a buffer pool associated with each layer. This approach provides most of the efficiency of a pure shared buffer scheme and allows for simple, modular interfaces where they are most appropriate.
それらの純粋なフォームでは、厳密に層にされた両方と共有バッファ体系は実用的ではありません。 前者には、バッファをコピーするためのパフォーマンスに不利な条件があります。 他方では、プロトコル階層のすべての層で実体によって共有されるバッファを実装するのは実用的ではありません: 低級プロトコル層(OSIは1--4を層にする)には、本質的には静的なバッファ要件がありますが、上側のプロトコル層(OSIは5--7を層にする)は、それらのバッファ要件でダイナミックである傾向があります。 すなわち、アプリケーションのセットが異なるのに従ってバッファ要件が異なって、いくつかの異なったアプリケーションが同時に稼働しているかもしれません。 しかしながら、トランスポート層では、この後者の変化は目に見えません、そして、バッファ要件の変化は役立たれているアプリケーションの特定の本質よりサービス品質問題によるでしょう。 これはバッファプールの5--7シェアがそれぞれに関連づけたそれぞれのOSI層の実体が層にされている間OSI層1--4の実体がバッファを共有するハイブリッド体系を示します。 このアプローチは、それらが最も適切であるところで純粋な共有バッファ体系の効率の大部分を提供して、簡単で、モジュールのインタフェースを考慮します。
4.2.2 Buffer management in the transport entity.
4.2.2 輸送実体における管理をバッファリングしてください。
Buffers are allocated in the transport entity for two purposes: sending and receiving data. For sending data, the decision of how much buffer space to allocate is relatively simple; enough space should be allocated for outgoing data to hold the maximum number of data messages that the entity will have outstanding (i.e., sent but unacknowledged) at any time. The send buffer space is determined by one of two values, whichever is lower: the send credit received from the receiving transport entity, or a maximum value imposed by the local implementation, based on such factors as overall buffer capacity.
2つの目的のために輸送実体でバッファを割り当てます: データを送って、受け取ります。 送付データに関しては、どのくらいのバッファ領域を割り当てるかに関する決定は比較的簡単です。 発信データが実体がいずれでも傑出している(すなわち、送られましたが、不承認の)時間を過すというデータメッセージの最大数を保持するように、十分なスペースを割り当てるべきです。 どれが低くても、2つの値の1つをスペースが決定しているバッファに送ってください: 受信輸送実体から受け取られたクレジット、または地方の実装によって課された最大値を送ってください、総合的な緩衝能のような要素に基づいて。
The allocation of receive buffers is a more interesting problem because it is directly related to the credit value transmitted the peer transport entity in CR (or CC) and AK TPDUs. If the total credit offered to the peer entity exceeds the total available buffer space and credit reduction is not implemented, deadlock may occur, causing termination of one or more transport connections. For
受信バッファの配分は、よりおもしろい問題が直接クレジット値に関連するのでCR(または、CC)とAK TPDUsで同輩輸送実体を伝えたということです。 同輩実体に提供された総クレジットが総利用可能なバッファ領域を超えて、クレジット減少が実装されないなら、行き詰まりは起こるかもしれません、1人以上の輸送の接続の終了を引き起こして。 for
McCoy [Page 41] RFC 1008 June 1987
マッコイ[41ページ]RFC1008 1987年6月
the purposes of this discussion, offered credit is assumed to be equivalent to available buffer space.
この議論の目的であり、提供されたクレジットが利用可能なバッファ領域に相当させていると思われます。
The simplest scheme for receive buffer allocation is allocation of a fixed amount per transport connection. This amount is allocated regardless of how the connection is to be used. This scheme is fair in that all connections are treated equally. The implementation approach in Part 2.3, in which each transport connection is handled by a physically separate processor, obviously could use this scheme, since the allocation would be in the form of memory chips assigned by the system designer when the system is built.
受信バッファ配分の最も簡単な体系は輸送接続あたり1つの定額の配分です。 接続によってどう使用されていることになっているかにかかわらずこの量を割り当てます。 すべての接続が等しく扱われるので、この体系は公正です。 それぞれの輸送接続が肉体的に別々のプロセッサによって扱われるPart2.3での実装アプローチは明らかにこの体系を使用するかもしれません、配分がシステムが組立しているときシステム設計者によって割り当てられたメモリー用チップの形にあるでしょう、したがって。
A more flexible method of allocating receive buffer space is based on the connection quality of service (QOS) requested by the user. For instance, a QOS indicating high throughput would be given more send and receive buffer space than one a QOS indicating low delay. Similarly, connection priority can be used to determine send and receive buffer allocation, with important (i.e., high priority) connections allocated more buffer space.
受信バッファスペースを割り当てるよりフレキシブルなメソッドはユーザによって要求された接続サービスの質(QOS)に基づいています。 例えば、高生産性がもう少し与えられているのを示すQOSは低い遅れを示す1QOSあたりのものより、バッファ領域を送って、受けます。 同様に、バッファ配分を送って、受けるように決定するのに接続優先権を使用できます、より多くのバッファ領域を割り当てる重要な(すなわち、高い優先度)接続で。
A slightly more complex scheme is to apportion send and receive buffer space using both QOS and priority. For each connection, QOS indicates a general category of operation (e.g., high throughput or low delay). Within the general category, priority determines the specific amount of buffer space allocated from a range of possible values. The general categories may well overlap, resulting, for example, in a high priority connection with low throughput requirements being allocated more buffer space than low priority connection requiring a high throughput.
複雑な体系が分配することになっている以上は、QOSと優先権の両方を使用することで、よりもみ皮製のスペースをわずかに、送って、受けます。 各接続のために、QOSは操作(例えば、高生産性か低い遅れ)の一般的なカテゴリを示します。 一般的なカテゴリの中では、優先権はさまざまな可能な値から割り当てられた特定の量のバッファ領域を決定します。 一般的なカテゴリはたぶん重なるでしょう、例えば、高生産性を必要とする低い優先権接続より多くのバッファ領域を割り当てる少ないスループット要件との高い優先権関係となって。
5 Management of Transport service endpoints.
5 Transportの経営者側は終点を修理します。
As mentioned in Part 1.2.1.1, a transport entity needs some way of referencing a transport connection endpoint within the end system: a TCEP_id. There are several factors influencing the management of TCEP_ids:
Partで言及される、1.2、.1、.1、輸送実体はエンドシステムの中で輸送接続終点に参照をつける何らかの方法を必要とします: TCEP_イド。 TCEP_イドの管理に影響を及ぼすいくつかの要素があります:
1) IPC mechanism between the transport entity and the session
entity (Part 3.3);
1) 輸送実体とセッション実体(パート3.3)の間のIPCメカニズム。
2) transport entity resources and resource management (Part 4);
2) 実体リソースと資源管理(パート4)を輸送してください。
3) number of distinct TSAPs supported by the entity (Part 1.2.2.1);
and
異なったTSAPsの3)番号が実体でサポートした、(第1部.2.2、.1)。 そして
4) user process rendezvous mechanism (the means by which session
processes identify themselves to the transport entity, at a
given TSAP, for association with a transport connection);
4) ユーザ・プロセスランデブーメカニズム(輸送接続との仲間のための与えられたTSAPのセッションプロセスが輸送実体に自分たちを特定する手段)。
The IPC mechanism and the user process rendezvous mechanism have more direct influence than the other two factors on how the TCEP_id
IPCメカニズムとユーザの加工処理したランデブーメカニズムには他の2つの要素より多くの直接の影響がある、どのように、TCEP_イド
McCoy [Page 42] RFC 1008 June 1987
マッコイ[42ページ]RFC1008 1987年6月
management is implemented.
管理は実装されます。
The number of TCEP_ids available should reflect the resources that are available to the transport entity, since each TCEP_id in use represents a potential transport connection. The formal description assumes that there is a function in the TPE which can decide, on the basis of current resource availability, whether or not to issue a TCEP_id for any connection request received. If the TCEP_id is issued, then resources are allocated for the connection endpoint. However, there is a somewhat different problem for the users of transport. Here, the transport entity must somehow inform the session entity as to the TCEP_ids available at a given TSAP.
TCEP_イドの有効な数は輸送実体に利用可能なリソースを反映するべきです、使用中のそれぞれのTCEP_イドが潜在的輸送接続の代理をするので。 形式的記述は、機能が決めることができるTPEにあると仮定します、現在のリソースの有用性に基づいて、どんな接続要求のためにもTCEP_イドを発行するのが受信されたか否かに関係なく。 TCEP_イドを発行するなら、接続終点にリソースを割り当てます。 しかしながら、輸送のユーザのためのいくらか異なった問題があります。 ここで、輸送実体は与えられたTSAPで利用可能なTCEP_イドに関してどうにかセッション実体を知らせなければなりません。
In the formal description, a T-CONNECT-request is permitted to enter at any TSAP/TCEP_id. A function in the TPE considers whether or not resources are availble to support the requested connection. There is also a function which checks to see if a TSAP/TCEP_id is busy by seeing if there is a TPM allocated to it. But this function is not useful to the session entity which does not have access to the transport entity's operations. This description of the procedure is clearly too loose for an implementation.
形式的記述では、T-CONNECT-要求がどんなTSAP/TCEP_イドでも入ることが許可されています。 TPEでの機能は、要求された接続をサポートするためにリソースがavailbleであるかどうか考えます。 また、それに割り当てられたTPMがあるかどうかわかることによってTSAP/TCEP_イドが忙しいかどうか確認するためにチェックする機能があります。 しかし、この機能は輸送実体の操作に近づく手段を持っていないセッション実体の役に立ちません。 実装には、手順のこの記述は明確にゆる過ぎます。
One solution to this problem is to provide a new (abstract) service, T-REGISTER, locally, at the interface between transport and session.
この問題への1つの解決は輸送とセッションとのインタフェースで局所的に新しい(抽象的な)サービス、T-REGISTERを提供することです。
___________________________________________________________________ | Primitives Parameters | |_________________________________________________________________| | T-REGISTER request | Session process identifier | |________________________________|________________________________| | T-REGISTER indication | Transport endpoint identifier,| | | Session process identifier | |________________________________|________________________________| | T-REGISTER refusal | Session process identifier | |________________________________|________________________________|
___________________________________________________________________ | 基関数パラメタ| |_________________________________________________________________| | T-REGISTER要求| セッションプロセス識別子| |________________________________|________________________________| | T-REGISTER指示| 終点識別子を輸送してください。| | | セッションプロセス識別子| |________________________________|________________________________| | T-REGISTER拒否| セッションプロセス識別子| |________________________________|________________________________|
This service is used as follows:
このサービスは以下の通り利用されます:
1) A session process is identified to the transport entity by a
T-REGISTER-request event. If a TCEP_id is available, the
transport entity selects a TCEP_id and places it into a table
corresponding to the TSAP at which the T-REGISTER-request
event occurred, along with the session process identifier. The
TCEP_id and the session process identifier are then
transmitted to the session entity by means of the T-REGISTER-
indication event. If no TCEP_id is available, then a T-
REGISTER-refusal event carrying the session process identifier
is returned. At any time that an assigned TCEP_id is not
associated with an active transport connection process
(allocated TPM), the transport entity can issue a T-REGISTER-
1) セッションプロセスはT-REGISTER-要求イベントによって輸送実体に特定されます。 TCEP_イドが利用可能であるなら、輸送実体は、TCEP_イドを選択して、T-REGISTER-要求イベントが起こったTSAPに対応するテーブルにそれを置きます、セッションプロセス識別子と共に。 そして、TCEP_イドとセッションプロセス識別子はT-REGISTER指示イベントによってセッション実体に伝えられます。 どんなTCEP_イドも利用可能でないなら、セッションプロセス識別子を運ぶT REGISTER-拒否イベントを返します。 割り当てられたTCEP_イドが能動輸送接続プロセス(TPMを割り当てる)に関連づけられない何時でも、輸送実体はT-REGISTERを発行できます。
McCoy [Page 43] RFC 1008 June 1987
マッコイ[43ページ]RFC1008 1987年6月
refusal to the session entity to indicate, for example, that
resources are no longer available to support a connection,
since TC resources are not allocated at registration time.
例えばリソースが接続をサポートするためにもう利用可能でないことを示すセッション実体への拒否、TC以来、リソースは登録時に割り当てられません。
2) If the session entity is to initiate the transport connection,
it issues a T-CONNECT-request with the TCEP_id as a parameter.
(Note that this procedure is at a slight variance to the
procedure in N3756, which specifies no such parameter, due to
the requirement of alignment of the formal description with
the service description of transport and the definition of the
session protocol.) If the session entity is expecting a
connection request from a remote peer at this TSAP, then the
transport does nothing with the TCEP_id until a CR TPDU
addressed to the TSAP arrives. When such a CR TPDU arrives,
the transport entity issues a T-CONNECT-indication to the
session entity with a TCEP_id as a parameter. As a management
aid, the table entry for the TCEP_id can be marked "busy" when
the TCEP_id is associated with an allocated TPM.
2) セッション実体が輸送接続を開始することであるなら、それはパラメタとしてTCEP_イドでT-CONNECT-要求を出します。 (輸送のサービス記述とセッションプロトコルの定義による形式的記述の整列の要件のためN3756の手順にはこの手順がわずかな変化にあることに注意してください。)N3756はどんなそのようなパラメタも指定しません。 セッション実体がこのTSAPのリモート同輩からの接続要求を予想しているなら、TSAPに扱われたCR TPDUが到着するまで、輸送はTCEP_イドで何もしません。 そのようなCR TPDUが到着するとき、輸送実体はパラメタとしてTCEP_イドでT-CONNECT-指示をセッション実体に発行します。 管理が支援されるとき、TCEP_イドが割り当てられたTPMに関連しているとき、「忙しいこと」をTCEP_イドのためのテーブル項目を示されることができます。
3) If a CR TPDU is received and no TCEP_id is in the table for
the TSAP addressed, then the transport selects a TCEP_id,
includes it as a parameter in the T-CONNECT-indication sent to
the session entity, and places it in the table. The T-
CONNECT-response returned by the session entity will carry the
TCEP_id and the session process identifier. If the session
process identifier is already in the table, the new one is
discarded; otherwise it is placed into the table. This
procedure is also followed if the table has entries but they
are all marked busy or are empty. If the table is full and
all entries ar marked busy, then the transport entity
transmits a DR TPDU to the peer transport entity to indicate
that the connection cannot be made. Note that the transport
entity can disable a TSAP by marking all its table entries
busy.
3) CR TPDUが受け取られていて、TCEP_イドが全く扱われたTSAPのためのテーブルにないなら、輸送は、TCEP_イドを選択して、T-CONNECT-指示におけるパラメタがセッション実体に発信したのでそれを含んで、それをテーブルに置きます。 セッション実体によって返されたT CONNECT-応答はTCEP_イドとセッションプロセス識別子を運ぶでしょう。 セッションプロセス識別子がテーブルに既にあるなら、新しい方は捨てられます。 さもなければ、それはテーブルに置かれます。 また、テーブルにはエントリーがありますが、それらが忙しいとすべてマークされるか、または空であるなら、この手順は従われています。 テーブルが完全であるか、そして、arが忙しいのを示したすべてのエントリー、そして、輸送実体は接続を作ることができないのを示すために同輩輸送実体にDR TPDUを伝えます。 すべてのテーブル項目が忙しいとマークすることによって輸送実体がTSAPを無効にすることができることに注意してください。
The realization of the T-REGISTER service will depend on the IPC mechanisms available between the transport and session entities. The problem of user process rendezvous is solved in general by the T- REGISTER service, which is based on a solution proposed by Michael Chernik of the NBS [CHK85].
T-REGISTERサービスの実現は輸送とセッション実体の間で利用可能なIPCメカニズムによるでしょう。 一般に、ユーザ・プロセスランデブーの問題はT REGISTERサービスで解決されています。(それは、NBS[CHK85]のマイケルChernikによって提案されたソリューションに基づいています)。
6 Management of Network service endpoints in Transport.
6 Networkの経営者側はTransportの終点を修理します。
6.1 Endpoint identification.
6.1 終点識別。
The identification of endpoints at an NSAP is different from that for the TSAP. The nature of the services at distinct TSAPs is fundamentally the same, although the quality could vary, as a local
TSAPにおいて、NSAPの終点の識別はそれと異なっています。 品質はローカルとして異なるかもしれませんが、異なったTSAPsでのサービスの本質は基本的に同じです。
McCoy [Page 44] RFC 1008 June 1987
マッコイ[44ページ]RFC1008 1987年6月
choice. However, it is possible for distinct NSAPs to represent access to essentially different network services. For example, one NSAP may provide access to a connectionless network service by means of an internetwork protocol. Another NSAP may provide access to a connection-oriented service, for use in communicating on a local subnetwork. It is also possible to have several distinct NSAPs on the same subnetwork, each of which provides some service features of local interest that distinguishes it from the other NSAPs.
選択。 しかしながら、異なったNSAPsが本質的には異なったネットワーク・サービスへのアクセスを表すのは、可能です。 例えば、1NSAPがインターネットワークプロトコルによってコネクションレスなネットワーク・サービスへのアクセスを提供するかもしれません。 別のNSAPは地方のサブネットワークについて話し合うことにおける使用のためのコネクション型サービスへのアクセスを提供するかもしれません。 また、それのそれぞれが他のNSAPsとそれを区別する地方の関心のいくつかのサービス機能を提供するのと同じサブネットワークの上に数個の異なったNSAPsを持っているのも可能です。
A transport entity accessing an X.25 service could use the logical channel numbers for the virtual circuits as NCEP_ids. An NSAP providing access only to a permanent virtual circuit would need only a single NCEP_id to multiplex the transport connections. Similarly, a CSMA/CD network would need only a single NCEP_id, although the network is connectionless.
X.25サービスにアクセスする輸送実体はNCEP_イドとして仮想の回路の論理チャネル番号を使用するかもしれません。 相手固定接続だけへのアクセスを提供するNSAPは、輸送の接続を多重送信するためにただ一つのNCEP_イドだけを必要とするでしょう。 同様に、ネットワークはコネクションレスですが、CSMA/CDネットワークはただ一つのNCEP_イドだけを必要とするでしょう。
6.2 Management issues.
6.2 管理問題。
The Class 4 transport protocol has been succesfully operated over both connectionless and connection-oriented network services. In both modes of operation there exists some information about the network service that a transport implementation could make use of to enhance performance. For example, knowledge of expected delay to a destination would permit optimal selection of retransmission timer value for a connection instance. The information that transport implementations could use and the mechanisms for obtaining and managing that information are, as a group, not well understood. Projects are underway within ISO committees to address the management of OSI as an architecture and the management of the transport layer as a layer.
コネクションレスなものと同様に接続指向のネットワーク・サービスの上でsuccesfullyにClass4トランスポート・プロトコルを操作してあります。 両方の運転モードで、輸送実装が性能を高めるのに利用できたネットワーク・サービスの何らかの情報が存在しています。 例えば、目的地への予想どおりの遅延に関する知識は接続インスタンスのために再送信タイマー価値の最適の選択を可能にするでしょう。 グループとして実装が使用できた輸送とその情報を得て、管理するためのメカニズムがあるという情報はよく分かりませんでした。 プロジェクトは輸送のアーキテクチャと管理が層として層にされるときOSIの管理に演説するISO委員会の中で進行中です。
For operation of the Class 4 transport protocol over connection-oriented network service several issues must be addressed including:
扱って、:接続指向のネットワーク・サービスの上のClass4トランスポート・プロトコルの操作において、いくつかの問題を扱わなければなりません。
a. When should a new network connection be opened to support a
transport connection (versus multiplexing)?
a。 新しいネットワーク接続は、輸送接続(マルチプレクシングに対する)をサポートするためにいつ開かれるべきですか?
b. When a network connection is no longer being used by any
transport connection, should the network connection be closed
or remain open awaiting a new transport connection?
b。 ネットワーク接続がもう何か輸送接続によって使用されていないとき、ネットワーク接続は、新しい輸送接続を待ちながら、閉じられるべきですか、開いたままで残るべきですか?
c. When a network connection is aborted, how should the peer
transport entities that were using the connection cooperate to
re-establish it? If splitting is not to be used, how can this
re-establishment be achieved such that one and only one
network connection results?
c。 ネットワーク接続が中止されるとき、接続を使用していた同輩輸送実体はどのように協力するか、そして、それを復職させるべきですか? 分かれるのが使用されていないことであるなら、どうしたらこの再建を達成できるかので、唯一無二の1人のネットワーク接続が結果になりますか?
The Class 4 transport specification permits a transport entity to multiplex several transport connections (TCs) over a single network
Class4輸送仕様は、輸送実体が数人の輸送の接続(TCs)をただ一つのネットワークの上に多重送信することを許可します。
McCoy [Page 45] RFC 1008 June 1987
マッコイ[45ページ]RFC1008 1987年6月
connection (NC) and to split a single TC across several NCs. The implementor must decide whether to support these options and, if so, how. Even when the implementor decides never to initiate splitting or multiplexing the transport entity must be prepared to accept this behavior from other transport implementations. When multiplexing is used TPDUs from multiple TCs can be concatenated into a single network service data unit (NSDU). Therefore, damage to an NSDU may effect several TCs. In general, Class 2 connections should not be multiplexed with Class 4 connections. The reason for this is that if the error rate on the network connection is high enough that the error recovery capability of Class 4 is needed, then it is too high for Class 2 operation. The deciding criterion is the tolerance of the user for frequent disconnection and data errors.
数個のNCsの向こう側に接続(NC)とスプリットのaにTCを選抜してください。 作成者は、これらのオプションをサポートするかどうか決めなければなりません、そして、そうだとすれば、どのようにですか? 他の輸送実装からこの振舞いを受け入れるように作成者が、いつ分かれることを決して開始しないと決めるか、そして、または輸送実体を多重送信するのを準備さえしなければなりません。 マルチプレクシングが使用されているとき、1つのネットワーク・サービスデータ単位(NSDU)に複数のTCsからのTPDUsを連結できます。 したがって、NSDUへの損害は数個のTCsに作用するかもしれません。 一般に、Class4接続と共にClass2接続を多重送信するべきではありません。 この理由はClass2操作には、ネットワーク接続の誤り率がClass4のエラー回復能力が必要であるほど高いなら高過ぎるということです。 決めている評価基準は頻繁な断線とデータ誤りのためのユーザの寛容です。
Several issues in splitting must be considered:
分かれることにおけるいくつかの問題を考えなければなりません:
1) maximum number of NCs that can be assigned to a given TC;
1) 与えられたTCに割り当てることができるNCsの最大数。
2) minimum number of NCs required by a TC to maintain the "quality
of service" expected (default of 1);
;2) NCsの最小の数がTCが、予想された「サービスの質」(1のデフォルト)を維持するのが必要です
3) when to split;
3) 分裂に。
4) inactivity control;
4) 不活発コントロール。
5) assignment of received TPDU to TC; and
5) TCへの容認されたTPDUの課題。 そして
6) notification to TC of NC status (assigned, dissociated, etc ).
6) NC状態(割り当てられて、分離したなど)のTCへの通知。
All of these except 3) are covered in the formal description. The methods used in the formal description need not be used explicitly, but they suggest approaches to implementation.
3)つを除いたこれらのすべてが形式的記述でカバーされています。 形式的記述に使用されるメソッドは明らかに使用される必要はありませんが、彼らは実装へのアプローチを示します。
To support the possibility of multiplexing and splitting the implementor must provide a common function below the TC state machines that maps a set of TCs to a set of NCs. The formal description provides a general means of doing this, requiring mainly implementation environment details to complete the mechanism. Decisions about when network connections are to be opened or closed can be made locally using local decision criteria. Factors that may effect the decision include costs of establishing an NC, costs of maintaining an open NC with little traffic flowing, and estimates of the probability of data flow between the source node and known destinations. Management of this type is feasible when a priori knowledge exists but is very difficult when a need exists to adapt to dynamic traffic patterns and/or fluctuating network charging mechanisms.
作成者を多重送信して、分ける可能性をサポートするのはTCsの1セットをNCsの1セットに写像する州が機械加工するTCの下に一般的な機能を供給しなければなりません。 形式的記述はメカニズムを完成するために実装環境の詳細を主に必要として、これをする一般的な手段を提供します。 局所的に地方の決定基準を使用することでネットワーク接続が開かれることになっているか、または閉店することになっている時に関する決定をすることができます。 決定に作用するかもしれない要素がNCを確立するコスト、トラフィックが少ししか流れていない開いているNCを維持するコスト、およびソースノードと知られている目的地の間のデータフローの確率の見積りを含んでいます。 このタイプの管理は、先験的な知識が存在するとき、可能ですが、必要性がダイナミックなトラフィック・パターン、そして/または、ネットワーク充電メカニズムを変動させるのに適合するように存在するとき、非常に難しいです。
To handle the issue of re-establishment of the NC after failure, the ISO has proposed an addendum N3279 [ISO85c] to the basic transport standard describing a network connection management subprotocol
失敗の後にNCの再建の問題を扱うために、ISOはネットワーク接続管理「副-プロトコル」について説明する基本的な輸送規格に付加物N3279[ISO85c]を提案しました。
McCoy [Page 46] RFC 1008 June 1987
マッコイ[46ページ]RFC1008 1987年6月
(NCMS) to be used in conjunction with the transport protocol.
輸送に関連して使用されるべき(NCMS)は議定書を作ります。
7 Enhanced checksum algorithm.
7はチェックサムアルゴリズムを高めました。
7.1 Effect of checksum on transport performance.
7.1 輸送性能へのチェックサムの効果。
Performance experiments with Class 4 transport at the NBS have revealed that straightforward implementation of the Fletcher checksum using the algorithm recommended in the ISO transport standard leads to severe reduction of transport throughput. Early modeling indicated throughput drops of as much as 66% when using the checksum. Work by Anastase Nakassis [NAK85] of the NBS led to several improved implementations. The performance degradation due to checksum is now in the range of 40-55%, when using the improved implementations.
Class4輸送がNBSにあるパフォーマンス実験は、ISO輸送規格におけるお勧めのアルゴリズムを使用するフレッチャーチェックサムの簡単な実現が輸送スループットの厳しい減少に通じるのを明らかにしました。 チェックサムを使用するとき、早めのモデルは最大66%のスループット低下を示しました。 NBSのAnastase Nakassis[NAK85]による仕事はいくつかの改良された実現につながりました。 改良された実現を使用するとき、チェックサムによる性能退行が現在、40-55%の範囲にあります。
It is possible that transport may be used over a network that does not provide error detection. In such a case the transport checksum is necessary to ensure data integrity. In many instances, the underlying subnetwork provides some error checking mechanism. The HDLC frame check sequence as used by X.25, IEEE 802.3 and 802.4 rely on a 32 bit cyclic redundancy check and satellite link hardware frequently provides the HDLC frame check sequence. However, these are all link or physical layer error detection mechanisms which operate only point-to-point and not end-to-end as the transport checksum does. Some links provide error recovery while other links simply discard damaged messages. If adequate error recovery is provided, then the transport checksum is extra overhead, since transport will detect when the link mechanism has discarded a message and will retransmit the message. Even when the IP fragments the TPDU, the receiving IP will discover a hole in the reassembly buffer and discard the partially assembled datagram (i.e., TPDU). Transport will detect this missing TPDU and recover by means of the retransmission mechanism.
輸送が誤り検出を提供しないネットワークの上で使用されるのは、可能です。 このような場合には輸送チェックサムが、データ保全を確実にするのに必要です。 多くの例に、基本的なサブネットワークは何らかの誤り照合メカニズムを提供します。 X.25によって使用されるHDLCフレームチェックシーケンス、IEEE802.3と802.4は32ビットの周期冗長検査に依存します、そして、衛星中継ハードウェアは頻繁にHDLCフレームチェックシーケンスを提供します。 しかしながら、これらは、終わらせる終わりではなく、輸送チェックサムがメカニズムであることのようにすべてのリンクかポイントツーポイントだけを操作する物理的な層の誤り検出メカニズムです。 他のリンクが単に破損しているメッセージを捨てている間、いくつかのリンクがエラー回復を提供します。 適切なエラー回復を提供するなら、輸送チェックサムは余分なオーバーヘッドです、輸送が、リンク・メカニズムがいつメッセージを捨てて、メッセージを再送するかを検出するので。 IPがTPDUを断片化すると、受信IPは再アセンブリバッファの穴を発見して、部分的に組み立てられたデータグラム(すなわち、TPDU)を捨てるでしょう。 輸送は、このなくなったTPDUを検出して、「再-トランスミッション」メカニズムによって回復するでしょう。
7.2 Enhanced algorithm.
7.2はアルゴリズムを高めました。
The Fletcher checksum algorithm given in an annex to IS 8073 is not part of the standard, and is included in the annex as a suggestion to implementors. This was done so that as improvements or new algorithms came along, they could be incorporated without the necessity to change the standard.
別館で与えられたフレッチャーチェックサムアルゴリズム、8073が規格の一部でないということであり、提案として別館で作成者に含められています。 改良か新しいアルゴリズムがやって来たとき規格を変える必要性なしでそれらを取り入れることができるようにこれをしました。
Nakassis has provided three ways of coding the algorithm, shown below, to provide implementors with insight rather than universally transportable code. One version uses a high order language (C). A second version uses C and VAX assembler, while a third uses only VAX assembler. In all the versions, the constant MODX appears. This represents the maximum number of sums that can be taken without experiencing overflow. This constant depends on the processor's word size and the arithmetic mode, as follows:
Nakassisは一般に輸送可能なコードよりむしろ洞察を作成者に提供する以下に示されたアルゴリズムをコード化する3つの方法を提供しました。 1つのバージョンが高位言語(C)を使用します。 第2のバージョンはCとVAXアセンブラを使用しますが、3分の1はVAXアセンブラだけを使用します。 すべてのバージョンでは、一定のMODXは現れます。 これはオーバーフローを経験しないで取ることができる合計の最大数を表します。 この定数を以下の通りプロセッサの語長と算数のモードに依存します:
McCoy [Page 47] RFC 1008 June 1987
マッコイ[47ページ]RFC1008 1987年6月
Choose n such that
nにそのようなものを選んでください、それ
(n+1)*(254 + 255*n/2) <= 2**N - 1
(n+1) *(254+255*n/2)<は2**N--1と等しいです。
where N is the number of usable bits for signed (unsigned) arithmetic. Nakassis shows [NAK85] that it is sufficient to take
Nがサインされた(無記名の)演算のための使用可能なビットの数であるところ。 Nakassisは、取るのが十分であることを[NAK85]に示します。
n <= sqrt( 2*(2**N - 1)/255 )
n<はsqrtと等しいです。(2*(2**N--1)/255)
and that n = sqrt( 2*(2**N - 1)/255 ) - 2 generally yields usable values. The constant MODX then is taken to be n.
そして、そのnはsqrt(2*(2**N--1)/255)と等しいです--一般に、2は使用可能な値をもたらします。 そして、nになるように一定のMODXを取ります。
Some typical values for MODX are given in the following table.
以下のテーブルでMODXのためのいくつかの典型的な値を与えます。
BITS/WORD MODX ARITHMETIC
15 14 signed
16 21 unsigned
31 4102 signed
32 5802 unsigned
BITS/WORD MODX ARITHMETIC15 14が無記名の31 4102がサインした16 21にサインした、32 5802、無記名
This constant is used to reduce the number of times mod 255 addition is invoked, by way of speeding up the algorithm.
この定数はモッズ風の255添加が呼び出されるという回の数を減少させるのに使用されます、アルゴリズムを早くすることを通して。
It should be noted that it is also possible to implement the checksum in separate hardware. However, because of the placement of the checksum within the TPDU header rather than at the end of the TPDU, implementing this with registers and an adder will require significant associated logic to access and process each octet of the TPDU and to move the checksum octets in to the proper positions in the TPDU. An alternative to designing this supporting logic is to use a fast, microcoded 8-bit CPU to handle this access and the computation. Although there is some speed penalty over separate logic, savings may be realized through a reduced chip count and development time.
また、別々のハードウェアのチェックサムを実行するのも可能であることに注意されるべきです。 しかしながら、TPDUの端でというよりむしろTPDUヘッダーの中のチェックサムのプレースメントのためにレジスタと毒蛇と共にこれを実行するのは、重要な関連論理がTPDUの各八重奏にアクセスして、処理して、TPDUの適切な位置への中のチェックサム八重奏を動かすのを必要とするでしょう。 論理をサポートしながらこれを設計することへの代替手段はこのアクセスと計算を扱うのに速くて、microcodedされた8ビットのCPUを使用することです。 別々の論理の上に何らかの速度刑罰がありますが、貯蓄は減少しているチップカウントと開発時代を通して実現されるかもしれません。
7.2.1 C language algorithm.
7.2.1 C言語アルゴリズム。
#define MODX 4102
#MODX4102を定義してください。
encodecc( mess,len,k )
unsigned char mess[] ; /* the TPDU to be checksummed */
int len,
k; /* position of first checksum octet
as an offset from mess[0] */
encodecc(混乱、len、k)の無記名の炭の混乱[]。 /*、checksummed*/int len、kであるTPDU。 混乱[0]*/からのオフセットとしての最初のチェックサム八重奏の/*位置
McCoy [Page 48] RFC 1008 June 1987
マッコイ[48ページ]RFC1008 1987年6月
{ int ip,
iq,
ir,
c0,
c1;
unsigned char *p,*p1,*p2,*p3 ;
int ip、iq、不-、c0、c1(無記名の炭の*p、*p1、*p2、*p3)
p = mess ; p3 = mess + len ;
pは混乱と等しいです。 p3は混乱+lenと等しいです。
if ( k > 0) { mess[k-1] = 0x00 ; mess[k] = 0x00 ; }
/* insert zeros for checksum octets */
(k>0)混乱[k-1]=0x00; 混乱[k]=0x00;/*がチェックサム八重奏*/のためにゼロを挿入するなら
c0 = 0 ; c1 = 0 ; p1 = mess ;
while (p1 < p3) /* outer sum accumulation loop */
{
p2 = p1 + MODX ; if (p2 > p3) p2 = p3 ;
for (p = p1 ; p < p2 ; p++) /* inner sum accumulation loop */
{ c0 = c0 + (*p) ; c1 = c1 + c0 ;
}
c0 = c0%255 ; c1 = c1%255 ; p1 = p2 ;
/* adjust accumulated sums to mod 255 */
}
ip = (c1 << 8) + c0 ; /* concatenate c1 and c0 */
c0=0。 c1=0。 p1は混乱と等しいです。 外側..合計..蓄積..輪..等しい..内側..合計..蓄積..輪..等しい..調整..蓄積..まとめる..モッズ /*はc1とc0*/を連結します。
if (k > 0)
{ /* compute and insert checksum octets */
(k>0)である、/*は、チェックサム八重奏*/を計算して、挿入します。
iq = ((len-k)*c0 - c1)%255 ; if (iq <= 0) iq = iq + 255 ;
mess[k-1] = iq ;
ir = (510 - c0 - iq) ;
if (ir > 255) ir = ir - 255 ; mess[k] = ir ;
}
return(ip) ;
}
iqは(len-k)*c0と等しいです--c1) %255 (iq<=0)iq=iq+255であるなら。 混乱[k-1]はiqと等しいです。 不-=(510--c0--iq)。 (不->255)不-=である、不-、--、255。 [k]=を台無しにしてください、不-、。 戻ってください(ip)。 }
7.2.2 C/assembler algorithm.
7.2.2 C/アセンブラアルゴリズム。
#include <math>
#<数学>を含めてください。
encodecm(mess,len,k)
unsigned char *mess ;
int len,k ;
{
int i,ip,c0,c1 ;
encodecm(混乱、len、k)の無記名の炭*混乱。 int len、k。 int i、ip、c0、c1。
if (k > 0) { mess[k-1] = 0x00 ; mess[k] = 0x00 ; }
ip = optm1(mess,len,&c0,&c1) ;
if (k > 0)
{ i = ( (len-k)*c0 - c1)%255 ; if (i <= 0) i = i + 255 ;
mess[k-1] = i ;
i = (510 - c0 - i) ; if (i > 255) i = i - 255 ;
(k>0)が[k-1]=0x00(混乱[k]=0x00)を台無しにするなら、ipはoptm1(混乱、len、c0、およびc1)と等しいです。 (i<=0)iがi+255; 混乱[k-1]=iと等しいなら{iは(len-k)*c0と等しいです--c1)という(k>0)%255であるなら、iは(i>255)iはiと等しいです--255なら(510--c0--i)と等しいです。
McCoy [Page 49] RFC 1008 June 1987
マッコイ[49ページ]RFC1008 1987年6月
mess[k] = i ;
}
return(ip) ;
}
; calling sequence optm(message,length,&c0,&c1) where
; message is an array of bytes
; length is the length of the array
; &c0 and &c1 are the addresses of the counters to hold the
; remainder of; the first and second order partial sums
; mod(255).
混乱[k]はiと等しいです。 戻ってください(ip)。 } ; 呼出し手順は(メッセージ、長さ、c0、およびc1)どこをoptmするか。 メッセージはバイトの勢ぞろいです。 長さはアレイの長さです。 そして、c0、c1が保持するカウンタのアドレスである、。 残り、。 1番目と2番目の注文部分和。 モッズ(255)。
.ENTRY optm1,^M<r2,r3,r4,r5,r6,r7,r8,r9,r10,r11>
movl 4(ap),r8 ; r8---> message
movl 8(ap),r9 ; r9=length
clrq r4 ; r5=r4=0
clrq r6 ; r7=r6=0
clrl r3 ; clear high order bytes of r3
movl #255,r10 ; r10 holds the value 255
movl #4102,r11 ; r11= MODX
xloop: movl r11,r7 ; if r7=MODX
cmpl r9,r7 ; is r9>=r7 ?
bgeq yloop ; if yes, go and execute the inner
; loop MODX times.
movl r9,r7 ; otherwise set r7, the inner loop
; counter,
yloop: movb (r8)+,r3 ;
addl2 r3,r4 ; sum1=sum1+byte
addl2 r4,r6 ; sum2=sum2+sum1
sobgtr r7,yloop ; while r7>0 return to iloop
; for mod 255 addition
ediv r10,r6,r0,r6 ; r6=remainder
ediv r10,r4,r0,r4 ;
subl2 r11,r9 ; adjust r9
bgtr xloop ; go for another loop if necessary
movl r4,@12(ap) ; first argument
movl r6,@16(ap) ; second argument
ashl #8,r6,r0 ;
addl2 r4,r0 ;
ret
^.ENTRY optm1、M<r2、r3、r4、r5、r6、r7、r8、r9、r10、r11>movl4(ap)、r8。 r8--->メッセージmovl8(ap)、r9。 r9は長さのclrq r4と等しいです。 r5=r4=0 clrq r6。 r7=r6=0 clrl r3。 r3 movl#255、r10を高位バイトから取り除いてください。 r10は値の255movl#4102、r11を持っています。 r11はMODX xloopと等しいです: movl r11、r7。 r7=MODX cmpl r9であるなら、r7です。 r7?r9>=bgeq yloopです。 はいなら、内側を実行しに行ってください。 輪のMODX回数movl r9、r7。 さもなければ、r7、内側の輪を設定してください。 カウンタ、yloop: movb(r8)+、r3。 addl2 r3、r4。 sum1=sum1+バイトaddl2 r4、r6。 sum2=sum2+sum1 sobgtr r7、yloop。 r7>0はiloopに戻りますが。 モッズ255添加ediv r10、r6、r0、r6のために。 r6は残りediv r10、r4、r0、r4と等しいです。 subl2 r11、r9。 r9 bgtr xloopを調整してください。 必要なら別の輪のmovl r4、@12(ap)のために、行ってください。 最初に、議論movl r6、@16(ap)。 2番目の議論ashl#8、r6、r0。 addl2 r4、r0。 浸水してください。
7.2.3 Assembler algorithm.
7.2.3 アセンブラアルゴリズム。
buff0: .blkb 3 ; allocate 3 bytes so that aloop is
; optimally aligned
; macro implementation of Fletcher's algorithm.
; calling sequence ip=encodemm(message,length,k) where
; message is an array of bytes
; length is the length of the array
; k is the location of the check octets if >0,
; an indication not to encode if 0.
;
buff0: .blkb3。 aloopがあるように、3バイトを割り当ててください。 最適に並べられます。 フレッチャーのアルゴリズムのマクロ実現。 ; 呼出し手順ip=encodemm、(メッセージ、長さ、k)どこ。 メッセージはバイトの勢ぞろいです。 長さはアレイの長さです。 >0であるなら、kはチェック八重奏の位置です。 0であるならコード化しない指示。 ;
McCoy [Page 50] RFC 1008 June 1987
マッコイ[50ページ]RFC1008 1987年6月
movl 4(ap),r8 ; r8---> message
movl 8(ap),r9 ; r9=length
clrq r4 ; r5=r4=0
clrq r6 ; r7=r6=0
clrl r3 ; clear high order bytes of r3
movl #255,r10 ; r10 holds the value 255
movl 12(ap),r2 ; r2=k
bleq bloop ; if r2<=0, we do not encode
subl3 r2,r9,r11 ; set r11=L-k
addl2 r8,r2 ; r2---> octet k+1
clrb (r2) ; clear check octet k+1
clrb -(r2) ; clear check octet k, r2---> octet k.
bloop: movw #4102,r7 ; set r7 (inner loop counter) = to MODX
cmpl r9,r7 ; if r9>=MODX, then go directly to adjust r9
bgeq aloop ; and execute the inner loop MODX times.
movl r9,r7 ; otherwise set r7, the inner loop counter,
; equal to r9, the number of the
; unprocessed characters
aloop: movb (r8)+,r3 ;
addl2 r3,r4 ; c0=c0+byte
addl2 r4,r6 ; sum2=sum2+sum1
sobgtr r7,aloop ; while r7>0 return to iloop
; for mod 255 addition
ediv r10,r6,r0,r6 ; r6=remainder
ediv r10,r4,r0,r4 ;
subl2 #4102,r9 ;
bgtr bloop ; go for another loop if necessary
ashl #8,r6,r0 ; r0=256*r6
addl2 r4,r0 ; r0=256*r6+r4
cmpl r2,r7 ; since r7=0, we are checking if r2 is
bleq exit ; zero or less: if yes we bypass
; the encoding.
movl r6,r8 ; r8=c1
mull3 r11,r4,r6 ; r6=(L-k)*c0
ediv r10,r6,r7,r6 ; r6 = (L-k)*c0 mod(255)
subl2 r8,r6 ; r6= ((L-k)*c0)%255 -c1 and if negative,
bgtr byte1 ; we must
addl2 r10,r6 ; add 255
byte1: movb r6,(r2)+ ; save the octet and let r2---> octet k+1
addl2 r6,r4 ; r4=r4+r6=(x+c0)
subl3 r4,r10,r4 ; r4=255-(x+c0)
bgtr byte2 ; if >0 r4=octet (k+1)
addl2 r10,r4 ; r4=255+r4
byte2: movb r4,(r2) ; save y in octet k+1
exit: ret
movl4(ap)、r8。 r8--->メッセージmovl8(ap)、r9。 r9は長さのclrq r4と等しいです。 r5=r4=0 clrq r6。 r7=r6=0 clrl r3。 r3 movl#255、r10を高位バイトから取り除いてください。 r10は値の255movl12(ap)、r2を持っています。 r2=k bleq大失敗。 r2<=0であるなら、私たちはsubl3 r2、r9、r11をコード化しません。 r11=L-k addl2 r8、r2を設定してください。 r2---+1 >八重奏k clrb(r2)。 +1 チェック八重奏k clrbをきれいにしてください--(r2) 明確なチェック八重奏k、r2--->八重奏k.大失敗: movw#4102、r7。 MODX cmpl r9、r7へのr7(内側のループ・カウンタ)=を設定してください。 r9>がMODXと等しいなら、r9 bgeq aloopを調整しに直接行ってください。 そして、輪のMODX回数movl r9、r7を作ってください。 さもなければ、r7、内側のループ・カウンタを設定してください。 r9、数と等しさ、。 未加工のキャラクタaloop: movb(r8)+、r3。 addl2 r3、r4。 c0=c0+バイトaddl2 r4、r6。 sum2=sum2+sum1 sobgtr r7、aloop。 r7>0はiloopに戻りますが。 モッズ255添加ediv r10、r6、r0、r6のために。 r6は残りediv r10、r4、r0、r4と等しいです。 subl2#4102、r9。 bgtr大失敗。 別のものが必要ならashl#8、r6、r0を輪にするので、行ってください。 r0=256*r6 addl2 r4、r0。 r0=256*r6+r4 cmpl r2、r7。 r7=0以来、私たちは、r2がbleq出口であるかどうかチェックしています。 ゼロか以下: はい私たちが迂回させる。 コード化movl r6、r8。 r8=c1 mull3 r11、r4、r6。 r6は*c0 ediv r10、r6、r7、r6と等しいです(L-k)。 r6は(L-k)*c0モッズ(255)subl2 r8、r6と等しいです。 そして、r6が((L-k)*c0)%255-c1と等しい、ネガ、bgtr byte1であるなら。 私たちはaddl2 r10、r6がそうしなければなりません。 255byte1を加えてください: movb r6、(r2)+。 八重奏を救ってください、そして、r2をさせてください。--->八重奏k+1addl2 r6、r4。 r4=r4+r6はsubl3 r4、r10、r4と等しいです(x+c0)。 r4は255(x+c0)のbgtr byte2と等しいです。 >0r4が八重奏(k+1)addl2 r10と等しいなら、r4です。 r4=255+r4 byte2: movb r4、(r2)。 八重奏k+1出口でyを救ってください: 浸水してください。
8 Parameter selection.
8 パラメタ選択。
8.1 Connection control.
8.1 接続コントロール。
Expressions for timer values used to control the general transport
タイマ値のための表現は以前はよく一般的な輸送を制御していました。
McCoy [Page 51] RFC 1008 June 1987
マッコイ[51ページ]RFC1008 1987年6月
connection behavior are given in IS 8073. However, values for the specific factors in the expressions are not given and the expressions are only estimates. The derivation of timer values from these expressions is not mandatory in the standard. The timer value expressions in IS 8073 are for a connection-oriented network service and may not apply to a connectionless network service.
振舞いが与えられている接続は8073です。 しかしながら、表現における特殊生産要素のための値は与えられていません、そして、表現は見積りにすぎません。 これらの表現からのタイマ値の派生は規格で義務的ではありません。 タイマ値の表現は8073が接続指向のネットワーク・サービスのためにあって、コネクションレスなネットワーク・サービスに適用されないかもしれないという中のことです。
The following symbols are used to denote factors contributing to timer values, throughout the remainder of this Part.
以下のシンボルは、このPartの残り中でタイマ値に貢献する要素を指示するのに使用されます。
Elr = expected maximum transit delay, local to remote
Elr=はリモートへの地方の最大のトランジット遅れを予想しました。
Erl = expected maximum transit delay, remote to local
Erl=は地方にリモートな最大のトランジット遅れを予想しました。
Ar = time needed by remote entity to generate an acknowledgement
アルゴン=時間は、リモート実体で承認を発生させる必要がありました。
Al = time needed by local entity to generate an acknowledgement
アル=時間は、ローカル要素で承認を発生させる必要がありました。
x = local processing time for an incoming TPDU
入って来るTPDUのためのローカル処理x=時間
Mlr = maximum NSDU lifetime, local to remote
Mlrはリモートへの地方の最大のNSDU生涯と等しいです。
Mrl = maximum NSDU lifetime, remote to local
Mrlは生涯の、そして、地方にリモートな最大のNSDUと等しいです。
T1 = bound for maximum time local entity will wait for
acknowledgement before retransmitting a TPDU
TPDUを再送する前に、最大の時間ローカル要素に向かっているT1=は承認を待っています。
R = bound for maximum local entity will continue to transmit a
TPDU that requires acknowledgment
最大のローカル要素に向かっているR=は、承認を必要とするTPDUを伝え続けるでしょう。
N = bound for maximum number of times local entity will transmit
a TPDU requiring acknowledgement
最大の回数ローカル要素に向かっているN=は承認を必要とするTPDUを伝えるでしょう。
L = bound for the maximum time between the transmission of a
TPDU and the receipt of any acknowledgment relating to it.
L=は、最大の時にそれに関連しながら、TPDUのトランスミッションとどんな承認の受領の間でも付きました。
I = bound for the time after which an entity will initiate
procedures to terminate a transport connection if a TPDU is
not received from the peer entity
私はTPDUが同輩実体から受け取られないなら実体が輸送接続を終えるために手順に着手する時のバウンドと等しいです。
W = bound for the maximum time an entity will wait before
transmitting up-to-date window information
最新の窓の情報を伝える前に実体が待っている最大の時に縛られたW=
These symbols and their definitions correspond to those given in Clause 12 of IS 8073.
これらのシンボルと彼らの定義がClause12で与えられたものに対応している、8073です。
8.1.1 Give-up timer.
8.1.1 タイマをあきらめてください。
The give-up timer determines the amount of time the transport entity will continue to await an acknowledgement (or other appropriate reply) of a transmitted message after the message
上にあきらめタイマは輸送実体がメッセージの後に伝えられたメッセージの承認(または、他の適切な回答)を待ち続けている時間を決定します。
McCoy [Page 52] RFC 1008 June 1987
マッコイ[52ページ]RFC1008 1987年6月
has been retransmitted the maximum number of times. The recommendation given in IS 8073 for values of this timer is expressed by
再送された、最大の回数。 中の当然のことがこのタイマの値のための8073であるという推薦は言い表されます。
T1 + W + Mrl, for DT and ED TPDUs
DTと教育TPDUsのためのT1+W+Mrl
T1 + Mrl, for CR, CC, and DR TPDUs,
CR、CC、およびDR TPDUsのためのT1+Mrl
where
どこ
T1 = Elr + Erl + Ar + x.
T1はElr+Erl+アルゴン+xと等しいです。
However, it should be noted that Ar will not be known for either the CR or the CC TPDU, and that Elr and Erl may vary considerably due to routing in some conectionless network services. In Part 8.3.1, the determination of values for T1 is discussed in more detail. Values for Mrl generally are relatively fixed for a given network service. Since Mrl is usually much larger than expected values of T1, a rule-of-thumb for the give-up timer value is 2*Mrl + Al + x for the CR, CC and DR TPDUs and 2*Mrl + W for DT and ED TPDUs.
しかしながら、アルゴンがCRかCC TPDUのどちらかで知られていなくて、ElrとErlがいくつかのconectionlessネットワーク・サービスにおけるルーティングのためかなり異なるかもしれないことに注意されるべきです。 Part8.3.1では、さらに詳細にT1のための値の決断について議論します。 一般に、Mrlのための値は与えられたネットワーク・サービスのために比較的固定されています。 MrlがT1の期待値よりはるかに通常大きいので、上にあきらめタイマ価値のための経験則はDTとED TPDUsのためのCR、CC、DR TPDUs、および2*Mrl+Wのための2*Mrl+アル+xです。
8.1.2 Inactivity timer.
8.1.2 不活発タイマ。
This timer measures the maximum time period during which a transport connection can be inactive, i.e., the maximum time an entity can wait without receiving incoming messages. A usable value for the inactivity timer is
このタイマは輸送接続が不活発である場合がある最大の期間を測定します、すなわち、実体が入力メッセージを受け取らないで待つことができる最大の時代に。 不活発タイマのための使用可能な値はそうです。
I = 2*( max( T1,W )*N ).
私は2*(最大(T1、W)*N)と等しいです。
This accounts for the possibility that the remote peer is using a window timer value different from that of the local peer. Note that an inactivity timer is important for operation over connectionless network services, since the periodic receipt of AK TPDUs is the only way that the local entity can be certain that its peer is still functioning.
これはリモート同輩が地元の同輩のものと異なった窓のタイマ価値を使用している可能性を説明します。 コネクションレスなネットワーク・サービスの上の操作に、不活発タイマが重要であることに注意してください、AK TPDUsの周期的な領収書がローカル要素が同輩がまだ機能しているのを確信している場合がある唯一の方法であることで。
8.1.3 Window timer.
8.1.3 ウィンドウタイマ。
The window timer has two purposes. It is used to assure that the remote peer entity periodically receives the current state of the local entity's flow control, and it ensures that the remote peer entity is aware that the local entity is still functioning. The first purpose is necessary to place an upper bound on the time necessary to resynchronize the flow control should an AK TPDU which notifies the remote peer of increases in credit be lost. The second purpose is necessary to prevent the inactivity timer of the remote peerfrom expiring. The value for the window timer, W, depends on several factors, among which are the transit delay, the acknowledgement strategy, and the probability of TPDU loss in the network. Generally, W should satisfy the following condition:
ウィンドウタイマには、2つの目的があります。 それはリモート同輩実体が定期的にローカル要素のフロー制御の現状を得ることを保証するのに使用されます、そして、リモート同輩実体がローカル要素がまだ機能しているのを意識しているのを確実にします。 クレジットの増加についてリモート同輩に通知するAK TPDUがなくされているなら、最初の目的が、フロー制御を再連動させるのに必要な時に上限を置くのに必要です。 2番目の目的が、リモートpeerfromの不活発タイマが期限が切れるのを防ぐのに必要です。 ウィンドウタイマのための値(W)をいくつかの要素に依存します、どれがネットワークのTPDUの損失のトランジット遅れと、承認戦略と、確率であるかの中で。 一般に、Wは以下の条件を満たすべきです:
McCoy [Page 53] RFC 1008 June 1987
マッコイ[53ページ]RFC1008 1987年6月
W > C*(Erl + x)
W>C*(Erl+x)
where C is the maximum amount of credit offered. The rationale for this condition is that the right-hand side represents the maximum time for receiving the entire window. The protocol requires that all data received be acknowledged when the upper edge of the window is seen as a sequence number in a received DT TPDU. Since the window timer is reset each time an AK TPDU is transmitted, there is usually no need to set the timer to any less than the value on the right-hand side of the condition. An exception is when both C and the maximum TPDU size are large, and Erl is large.
Cが提供された信用状の最高額であるところ。 この状態のための原理は右側が全体の窓を受けるための最大の時間を表すということです。 プロトコルは、容認されたDT TPDUの窓の上側の縁が一連番号が見られるとデータが受けたすべてが承認されるのを必要とします。 AK TPDUが伝えられるたびにウィンドウタイマがリセットされるので、値どんな以下にもタイマを設定する必要は全く状態の右側に通常ありません。 例外はCと最大のTPDUサイズの両方が大きく、Erlが大きい時です。
When the probability that a TPDU will be lost is small, the value of W can be quite large, on the order of several minutes. However, this increases the delay the peer entity will experience in detecting the deactivation of the local transport entity. Thus, the value of W should be given some consideration in terms of how soon the peer entity needs to detect inactivity. This could be done by placing such information into a quality of service record associated with the peer's address.
TPDUがなくされるという確率がわずかであるときに、Wの値はかなり大きい場合があります、数分の注文に関して。 しかしながら、これは同輩実体がローカル運送実体の非活性化を検出する際になる遅れを増加させます。 したがって、同輩実体が、どれくらい早く不活発を検出する必要があるかに関する何らかの考慮をWの値に対して払うべきです。 同輩のアドレスに関連しているサービスの質記録にそのような情報を置くことによって、これができるでしょう。
When the expected network error rate is high, it may be necessary to reduce the value of W to ensure that AK TPDUs are being received by the remote entity, especially when both entities are quiescent for some period of time.
予想されたネットワーク誤り率が高いときに、AK TPDUsがリモート実体によって受け取られているのを保証するためにWの値を減少させるのが必要であるかもしれません、特に両方の実体がいつかの期間の間静かであるときに。
8.1.4 Reference timer.
8.1.4 参照タイマ。
The reference timer measures the time period during which a source reference must not be reassigned to another transport connection, in order that spurious duplicate messages not interfere with a new connection. The value for this timer given in IS 8073 is
参照タイマは別の輸送接続にソース参照を再選任してはいけない期間を測定します、偽りの写しメッセージが新しい接続を妨げないように。 値が、中に与えられたこのタイマが8073であるので、あります。
L = Mlr + Mrl + R + Ar
L=Mlr+Mrl+R+アルゴン
where
どこ
R = T1*N + z
R=T1*N+z
in which z is a small tolerance quantity to allow for factors internal to the entity. The use of L as a bound, however, must be considered carefully. In some cases, L may be very large, and not realistic as an upper or a lower bound. Such cases may be encountered on routes over several catenated networks where R is set high to provide adequate recovery from TPDU loss. In other cases L may be very small, as when transmission is carried out over a LAN and R is set small due to low probability of TPDU loss. When L is computed to be very small, the reference need not be timed out at all, since the probability of interference is zero. On the other hand, if L is computed to be very large a smaller value can be used.
zは実体への内部の要素のために許容する少寛容量です。 しかしながら、慎重にバウンドとしてのLの使用を考えなければなりません。 いくつかの場合、Lは、上側のバウンドか下側のバウンドとして非常に大きくて、現実的でないかもしれません。 そのような場合はRがTPDUの損失から適切な回復を供給するように高く設定されるいくつかのcatenatedネットワークの上でルートの上で遭遇するかもしれません。 他の場合では、Lは非常に小さいかもしれません、トランスミッションがLANの上に行われて、RがTPDUの損失の低い確率のため小さく設定される時として。 Lが非常に小さくなるように計算されるとき、参照はすべてで調節される必要はありません、干渉の確率がゼロであるので。 他方では、Lが非常に大きくなるように計算されるなら、より小さい値を使用できます。
McCoy [Page 54] RFC 1008 June 1987
マッコイ[54ページ]RFC1008 1987年6月
One choice for the value might be
値のための1つの選択がそうです。
L = min( R,(Mrl + Mlr)/2 )
L=分(R、(Mrl+Mlr)/2)
If the reference number assigned to a new connection by an entity is monotonically incremented for each new connection through the entire available reference space (maximum 2**16 - 1), the timer is not critical: the sequence space is large enough that it is likely that there will be no spurious messages in the network by the time reference numbers are reused.
実体によって新しい接続に割り当てられた参照番号が全体の利用可能な基準スペース(最大の2**16--1)を通るそれぞれの新しい関係のために単調に増加されるなら、タイマは重要ではありません: 系列スペースは参照番号が再利用される時までにネットワークにはどんな偽りのメッセージもありそうにないほど大きいです。
8.2 Flow control.
8.2フロー制御。
The peer-to-peer flow control mechanism in the transport protocol determines the upper bound on the pace of data exchange that occurs on transport connections. The transport entity at each end of a connection offers a credit to its peer representing the number of data messages it is currently willing to accept. All received data messages are acknowledged, with the acknowledgement message containing the current receive credit information. The three credit allocation schemes discussed below present a diverse set of examples of how one might derive receive credit values.
トランスポート・プロトコルのピアツーピアフロー制御メカニズムは輸送の接続のときに起こるデータ交換のペースのときに上限を決定します。 接続の各端の輸送実体はそれが現在受け入れても構わないと思っているデータメッセージの数を表す同輩にクレジットを提供します。 すべての受信データメッセージが承認されて、確認メッセージが電流を含んでいて、信用情報を受け取ってください。 現在のaさまざまのセットに関する例の下で議論した人がどう派生するかもしれないかに関する3つのクレジット配分体系がクレジット値を受けます。
8.2.1 Pessimistic credit allocation.
8.2.1 悲観的なクレジット配分。
Pessimistic credit allocation is perhaps the simplest form of flow control. It is similar in concept to X-on/X-off control. In this method, the receiver always offers a credit of one TPDU. When the DT TPDU is received, the receiver responds with an AK TPDU carrying a credit of zero. When the DT TPDU has been processed by the receiving entity, an additional AK TPDU carrying a credit of one will be sent. The advantage to this approach is that the data exchange is very tightly controlled by the receiving entity. The disadvantages are: 1) the exchange is slow, every data message requiring at least the time of two round trips to complete the transfer transfer, and 2) the ratio of acknowledgement to data messages sent is 2:1. While not recommeneded, this scheme illustrates one extreme method of credit allocation.
悲観的なクレジット配分は恐らく最も簡単なフォームのフロー制御です。 それは概念において下にXオン/Xコントロールと同様です。 この方法で、受信機は1TPDUのクレジットをいつも提供します。 DT TPDUが受け取られているとき、AK TPDUがゼロのクレジットを運んでいて、受信機は応じます。 受信実体でDT TPDUを処理したとき、1のクレジットを運ぶ追加AK TPDUを送るでしょう。 このアプローチの利点はデータ交換が受信実体によって非常にしっかり制御されるということです。 損失は以下の通りです。 1) 交換が遅い、2つの周遊旅行が転送転送、および2を終了する時間) 承認対メッセージが送ったデータの比率を必要とするあらゆるデータメッセージが2:1です。 recommenededされていない間、この計画はクレジット配分の1つの極端な方法を例証します。
8.2.2 Optimistic credit allocation.
8.2.2 楽観的なクレジット配分。
At the other extreme from pessimistic credit allocation is optimistic credit allocation, in which the receiver offers more credit than it has buffers. This scheme has two dangers. First, if the receiving user is not accepting data at a fast enough rate, the receiving transport's buffers will become filled. Since the credit offered was optimistic, the sending entity will continue to transmit data, which must be dropped by the receiving entity for lack of buffers. Eventually, the sender may reach the maximum number of retransmissions and terminate the connection.
それとは正反対に悲観的なクレジット配分から、楽観的なクレジット配分(受信機はそれにはバッファがあるより多くのクレジットを提供する)があります。 この計画には、2つの危険があります。 まず最初に、受信ユーザが十分速いレートでデータを受け入れていないなら、受信輸送のバッファはいっぱいにされるようになるでしょう。 提供されたクレジットが楽観的であったので、送付実体は、データを送り続けるでしょう。(バッファの不足によって受信実体でデータを落とさなければなりません)。 結局、送付者は、「再-トランスミッション」の最大数に達して、接続を終えるかもしれません。
McCoy [Page 55] RFC 1008 June 1987
マッコイ[55ページ]RFC1008 1987年6月
The second danger in using optimistic flow control is that the sending entity may transmit faster than the receiving entity can consume. This could result from the sender being implemented on a faster machine or being a more efficient implementation. The resultant behavior is essentially the same as described above: receive buffer saturation, dropped data messages, and connection termination.
楽観的なフロー制御を使用することにおける2番目の危険は送付実体が受信実体が消費できるより速く伝わるかもしれないということです。 これは、より速いマシンか、より効率的な実現であるときに実行される送付者から生じるかもしれません。 結果の振舞いは上で説明されるのと本質的には同じです: バッファ飽和、低下しているデータメッセージ、および接続終了を受け取ってください。
The two dangers cited above can be ameliorated by implementing the credit reduction scheme as specified in the protocol. However, optimistic credit allocation works well only in limited circumstances. In most situations it is inappropriate and inefficient even when using credit reduction. Rather than seeking to avoid congestion, optimistic allocation causes it, in most cases, and credit reduction simply allows one to recover from congestion once it has happened. Note that optimistic credit allocation combined with caching out-of-sequence messages requires a sophisticated buffer management scheme to avoid reasssembly deadlock and subsequent loss of the transport connection.
プロトコルでの指定されるとしてのクレジット減少計画を実行することによって、上で引用された2つの危険は改善できます。 しかしながら、楽観的なクレジット配分は限られた事情だけでうまくいきます。 ほとんどの状況で、クレジット減少を使用さえするとき、それは、不適当であって、効率が悪いです。 混雑を避けようとするよりむしろ、多くの場合、楽観的な配分はそれを引き起こします、そして、いったん起こると、クレジット減少は1つが混雑から回復するのを単に許容します。 順序が狂ってメッセージをキャッシュすると結合された楽観的なクレジット配分が輸送接続のreasssembly行き詰まりとその後の損失を避けるために洗練されたバッファ管理計画を必要とすることに注意してください。
8.2.3 Buffer-based credit allocation.
8.2.3 バッファベースのクレジット配分。
Basing the receive credit offered on the actual availability of receive buffers is a better method for achieving flow control. Indeed, with few exceptions, the implementations that have been studied used this method. It continuous flow of data and eliminating the need for the credit-restoring acknowledgements. Since only available buffer space is offered, the dangers of optimistic credit allocation are also avoided.
実際であることに対しては提供して、クレジットを受けてください。基づく、受信バッファの有用性は達成フロー制御のための、より良い方法です。 本当に、ほとんど例外はなく、研究された実現はこの方法を使用しました。 それ、データとクレジットを回復する承認の必要性を排除する連続した流れ。 利用可能なバッファ領域だけを提供するので、また、楽観的なクレジット配分という危険は避けられます。
The amount of buffer space needed to maintain a continuous bulk data transfer, which represents the maximum buffer requirement, is dependent on round trip delay and network speed. Generally, one would want the buffer space, and hence the credit, large enough to allow the sender to send continuously, so that incremental credit updates arrive just prior to the sending entity exhausting the available credit. One example is a single-hop satellite link operating at 1.544 Mbits/sec. One report [COL85] indicates that the buffer requirement necessary for continuous flow is approximately 120 Kbytes. For 10 Mbits/sec. IEEE 802.3 and 802.4 LANs, the figure is on the order of 10K to 15K bytes [BRI85, INT85, MIL85].
バッファ領域の量は、連続したバルク・データ転送(最大のバッファ要件を表す)に周遊旅行遅れとネットワーク速度に依存していると主張する必要がありました。 一般に、1は、バッファ領域が欲しく、したがって、クレジットが欲しいでしょう、送付者が絶え間なく送るのを許容できるくらい大きいです、増加のクレジットアップデートが送付実体のすぐ前に利用可能なクレジットを消耗させながら到着するように。 1つの例が1.544メガビット/秒のときに作動する単一のホップ衛星中継です。 1つのレポート[COL85]が、連続した流れに必要なバッファ要件がおよそ120キロバイトであることを示します。 10メガビット/秒の間 IEEE802.3と802.4のLANであり、10Kから15Kのバイト[BRI85、INT85、MIL85]の注文には図があります。
An interesting modification to the buffer-based credit allocation scheme is suggested by R.K. Jain [JAI85]. Whereas the approach described above is based strictly on the available buffer space, Jain suggests a scheme in which credit is reduced voluntarily by the sending entity when network congestion is detected. Congestion is implied by the occurrence of retransmissions. The sending entity, recognizing retransmissions, reduces the local value of credit to one, slowly raising it to the actual receive credit allocation as error-free transmissions continue to occur. This
バッファベースのクレジット配分体系へのおもしろい変更はR.のK.のジャイナ教の[JAI85]によって示されます。 上で説明されたアプローチは厳密に利用可能なバッファ領域に基づいています、ジャイナ教です。ところが、クレジットはネットワークの混雑が検出される送付実体によって自発的に減少させられる計画を示します。 混雑は「再-トランスミッション」の発生によって含意されます。 「再-トランスミッション」を認識して、送付実体はクレジットの地方の値を1まで減少させて、ゆっくり実際それを上げると、エラーのないトランスミッションが、起こり続けているとき、クレジット配分は受けられます。 これ
McCoy [Page 56] RFC 1008 June 1987
マッコイ[56ページ]RFC1008 1987年6月
technique can overcome various types of network congestion occurring when a fast sender overruns a slow receiver when no link level flow control is available.
テクニックはどんなリンク・レベルフロー制御も利用可能でないときに、速い送付者が遅い受信機をオーバーランであるなら起こる様々なタイプのネットワークの混雑に打ち勝つことができます。
8.2.4 Acknowledgement policies.
8.2.4 承認方針。
It is useful first to review the four uses of the acknowledgement message in Class 4 transport. An acknowledgement message:
Class4輸送における、確認メッセージの4つの用途を見直すのは最初に、役に立ちます。 確認メッセージ:
1) confirms correct receipt of data messages,
1) データメッセージの正しい領収書を確認します。
2) contains a credit allocation, indicating how many
data messages the entity is willing to receive
from the correspondent entity,
2) 通信員実体からいくつのデータメッセージを受け取るかを構わない実体が、思っている示して、クレジット配分を含んでいます。
3) may optionally contain fields which confirm
receipt of critical acknowledgement messages,
known as flow control confirmation (FCC), and
そして3) 任意にフロー制御確認(FCC)として知られている批判的な確認メッセージの領収書を確認する分野を含むかもしれない。
4) is sent upon expiration of the window timer to
maintain a minimum level of traffic on an
otherwise quiescent connection.
4) そうでなければ、静かな接続における最低水準の交通を維持するためにウィンドウタイマの満了に送ります。
In choosing an acknowledgement strategy, the first and third uses mentioned above, data confirmation and FCC, are the most relevant; the second, credit allocation, is determined according to the flow control strategy chosen, and the fourth, the window acknowledgement, is only mentioned briefly in the discussion on flow control confirmation.
承認戦略を選ぶ際に、1番目と前記のように3番目の用途(データ確認とFCC)は、最も関連しています。 選ばれたフロー制御戦略によると、2番目(クレジット配分)は決定しています、そして、フロー制御確認についての議論で簡潔に4(窓の承認)番目について言及するだけです。
8.2.4.1 Acknowledgement of data.
8.2.4.1 データの承認。
The primary purpose of the acknowledgement message is to confirm correct receipt of data messages. There are several choices that the implementor must make when designing a specific implementation. Which choice to make is based largely on the operating environment (e.g., network error characteristics). The issues to be decided upon are discussed in the sections below.
確認メッセージの第一の目的はデータメッセージの正しい領収書を確認することです。 特定の実現を設計するとき作成者がしなければならないいくつかの選択があります。 どの選択をしたらよいかは操作環境(例えば、ネットワーク誤りの特性)に主に基づいています。 下のセクションで決められるべき問題について議論します。
8.2.4.1.1 Misordered data messages.
8.2.4.1.1 Misorderedデータメッセージ。
Data messages received out of order due to network misordering or loss can be cached or discarded. There is no single determinant that guides the implementor to one or the other choice. Rather, there are a number of issues to be considered.
データメッセージがネットワークmisorderingで故障していた状態で受信されたか、または損失をキャッシュするか、捨てることができます。 1かもう片方の選択に作成者を誘導するどんなただ一つの決定因もありません。 むしろ、考えられる多くの問題があります。
One issue is the importance of maintaining a low delay as perceived by the user. If transport data messages are lost or damaged in transit, the absence of a positive acknowledgement will trigger a retransmission at the sending entity. When the retransmitted data message arrives at the receiving transport, it can be delivered
1冊はユーザによって知覚されるように低い遅れを維持する重要性です。 輸送データメッセージがトランジットで失われているか、または破損すると、積極的な承認の欠如は送付実体で「再-トランスミッション」の引き金となるでしょう。 再送されたデータメッセージが受信輸送に到達するとき、それを届けることができます。
McCoy [Page 57] RFC 1008 June 1987
マッコイ[57ページ]RFC1008 1987年6月
to the user. If subsequent data messages had been cached, they could be delivered to the user at the same time. The delay between the sending and receiving users would, on average, be shorter than if messages subsequent to a lost message were dependent on retransmission for recovery.
ユーザに。 順次データメッセージをキャッシュしたなら、同時に、それらをユーザに渡すかもしれません。 送受信ユーザの間の遅れが平均的に少しであるだろう、回復において、無くなっているメッセージへのその後のメッセージが「再-トランスミッション」に依存していたなら。
A second factor that influences the caching choice is the cost of transmission. If transmission costs are high, it is more economical to cache misordered data, in conjunction with the use of selective acknowledgement (described below), to avoid retransmissions.
キャッシュ選択に影響を及ぼす2番目の要素はトランスミッションの費用です。 トランスミッションコストが高いなら、misorderedデータをキャッシュするのは、より経済的です、「再-トランスミッション」を避けるために選択している承認(以下で、説明される)の使用に関連して。
There are two resources that are conserved by not caching misordered data: design and implementation time for the transport entity and CPU processing time during execution. Savings in both categories accrue because a non-caching implementation is simpler in its buffer management. Data TPDUs are discarded rather than being reordered. This avoids the overhead of managing the gaps in the received data sequence space, searching of sequenced message lists, and inserting retransmitted data messages into the lists.
misorderedデータをキャッシュしないことによって節約される2つの資源があります: 輸送実体のためのデザインと実行時間と実行の間のCPU処理時間。 バッファ管理で非キャッシュ実現が、より簡単であるので、両方のカテゴリにおける貯蓄は生じます。 データTPDUsは再命令されるよりむしろ捨てられます。 これは受信データ系列スペースでギャップを管理するオーバーヘッドを避けます、配列されたメッセージリストを探して、再送されたデータメッセージをリストの中に挿入して。
8.2.4.1.2 Nth acknowledgement.
8.2.4.1.2 n番目の承認。
In general, an acknowledgement message is sent after receipt of every N data messages on a connection. If N is small compared to the credit offered, then a finer granularity of buffer control is afforded to the data sender's buffer management function. Data messages are confirmed in small groups, allowing buffers to be reused sooner than if N were larger. The cost of having N small is twofold. First, more acknowledgement messages must be generated by one transport entity and processed by another, consuming some of the CPU resource at both ends of a connection. Second, the acknowledgement messages consume transmission bandwidth, which may be expensive or limited.
一般に、Nデータメッセージ毎の領収書の後に確認メッセージを接続に送ります。 提供されたクレジットと比べて、Nが小さいなら、データ送付者のバッファ管理機能にバッファ管理の、よりすばらしい粒状を提供します。 バッファが、より早く再利用されるのを許容して、データメッセージが小集団で確認される、Nが、より大きいなら。 Nを小さくする費用は二つです。 まず最初に、より多くの確認メッセージを1つの輸送実体で発生して、別のものは処理しなければなりません、接続の両端でCPUリソースのいくつかを消費して。 2番目に、確認メッセージはトランスミッション帯域幅を消費します。(それは、高価であるか限られるかもしれません)。
For larger N, buffer management is less efficient because the granularity with which buffers are controlled is N times the maximum TPDU size. For example, when data messages are transmitted to a receiving entity employing this strategy with large N, N data messages must be sent before an acknowledgement is returned (although the window timer causes the acknowledgement to be sent eventually regardless of N). If the minimum credit allocation for continuous operation is actually a fraction of N, a credit of N must still be offered, and N receive buffers reserved, to achieve a continuous flow of data messages. Thus, more receive buffers are used than are actually needed. (Alternatively, if one relies on the timer, which must be adjusted to the receipt time for N and will not expire until some time after the fraction of N has been sent, there may be idle time.)
より大きいNに関しては、バッファが制御されている粒状が最大のTPDUサイズのN倍であるので、バッファ管理はそれほど効率的ではありません。 データメッセージを受信実体に送るとき、例えば、大きいNがあるこの戦略を使って、承認を返す(結局、Nにかかわらずウィンドウタイマで承認を送りますが)前にNデータメッセージを送らなければなりません。 継続的作業のための最小のクレジット配分が実際にNの部分であるなら、まだNのクレジットを提供しなければなりません、そして、Nはデータメッセージの連続した流れを達成するために予約されたバッファを受け取ります。 したがって、より多くの受信バッファが実際に必要とされるより使用されています。 (あるいはまた、人がNのための領収書時間に調整しなければならなくて、Nの部分を送った後にいつかまで期限が切れないタイマを当てにするなら、遊休時間があるかもしれません。)
The choice of values for N depends on several factors. First, if the
Nのための値のこの選択はいくつかの要素次第です。 最初に
McCoy [Page 58] RFC 1008 June 1987
マッコイ[58ページ]RFC1008 1987年6月
rate at which DT TDPUs are arriving is relatively low, then there is not much justification for using a value for N that exceeds 2. On the other hand, if the DT TPDU arrival rates is high or the TPDU's arrive in large groups (e.g., in a frame from a satellite link), then it may be reasonable to use a larger value for N, simply to avoid the overhead of generating and sending the acknowledgements while procesing the DT TPDUs. Second, the value of N should be related to the maximum credit to be offered. Letting C be the maximum credit to be offered, one should choose N < C/2, since the receipt of C TPDUs without acknowledging will provoke sending one in any case. However, since the extended formats option for transport provides max C = 2**16 - 1, a choice of N = 2**15 - 2 is likely to cause some of the sender's retransmission timers to expire. Since the retransmitted TPDU's will arrive out of sequence, they will provoke the sending of AK TPDU's. Thus, not much is gained by using an N large. A better choice is N = log C (base 2). Third, the value of should be related to the maximum TPDU size used on the connection and the overall buffer management. For example, the buffer management may be tied to the largest TPDU that any connection will use, with each connection managing the actual way in which the negotiated TPDU size relates to this buffer size. In such case, if a connection has negotiated a maximum TPDU size of 128 octets and the buffers are 2048 octets, it may provide better management to partially fill a buffer before acknowledging. If the example connection has two buffers and has based offered credit on this, then one choice for N could be 2*log( 2048/128 ) = 8. This would mean that an AK TPDU would be sent when a buffer is half filled ( 2048/128 = 16 ), and a double buffering scheme used to manage the use of the two buffers. the use of the t There are two studies which indicate that, in many cases, 2 is a good choice for N [COL85, BRI85]. The increased granularity in buffer management is reasonably small when compared to the credit allocation, which ranges from 8K to 120K octets in the studies cited. The benefit is that the number of acknowledgements generated (and consumed) is cut approximately in half.
DT TDPUsが達しているレートが比較的低い、そして、2を超えているNに値を使用するためのそれほど多くない正当化があります。 他方では、到着が評定するDT TPDUが高いか、またはTPDUのものが大きいグループ(例えば、衛星中継からのフレームの)に到着するなら、Nにより大きい値を使用して、単にDT TPDUsをprocesingしている間、承認を発生して、送るオーバーヘッドを避けるのは妥当であるかもしれません。 2番目に、Nの値は提供される最大のクレジットに関連するべきです。 Cが提供される最大のクレジットであることをさせて、C TPDUsの領収書以来のN<C/2に発信をあるコネで引き起こすために望むように認めることのないどんなケースも選ぶべきです。 しかしながら、輸送のための拡張フォーマットオプションが=2**16--1を最大Cに提供するので、Nの選択は15--2が送付者のいくつかの再送信タイマーが吐き出すことを引き起こしそうである2**と等しいです。 再送されたTPDUのものが順序が狂って到着するので、彼らはAK TPDUの発信を引き起こすでしょう。 したがって、Nを使用することによって、大きい状態で多くを獲得するというわけではありません。 より良い選択はN=ログCです(ベース2)。 3番目、値、接続のときに使用された最大のTPDUサイズと総合的なバッファ管理に関連されるべきです。 例えば、バッファ管理はどんな接続も使用する中で最も大きいTPDUに結ばれるかもしれません、各接続が交渉されたTPDUサイズがこのバッファサイズに関連する実際の方法を管理していて。 そのような場合では、それは、接続が128の八重奏の最大のTPDUサイズを交渉して、バッファが2048の八重奏であるなら、承認の前にバッファを部分的にいっぱいにするために、より良い管理を提供するかもしれません。 2つのバッファを持って、例の接続の提供されたクレジットがこれに基づいていたなら、Nのための1つの選択が2*ログ( 2048/128 )=8であるかもしれません。 バッファが半分が( 2048/128 = 16 )をいっぱいにしたということであるときに、これは、AK TPDUが送られることを意味するでしょう、そして、二重バッファリング方式は以前はよく2つのバッファの使用を管理していました。t Thereの使用は2が多くの場合でN[COL85、BRI85]のための良い選択であることを示す2研究です。 クレジット配分(8Kから研究における八重奏が引用した120Kまで及ぶ)と比べると、バッファ管理における増加する粒状は合理的に小さいです。 利益は発生する(そして、消費されます)承認の数がほとんど半分に切られるということです。
8.2.4.1.3 Selective acknowledgement.
8.2.4.1.3 選択している承認。
Selective acknowledgement is an option that allows misordered data messages to be confirmed even in the presence of gaps in the received message sequence. (Note that selective acknowledgement is only meaningul whe caching out-of-orderdata messags.) The advantage to using this mechanism is hat i grealy reduces the number of unnecessary retransmissions, thus saving both computing time and transmission bandwidth [COL85] (see the discussion in Part 8.2.4.1.1 for more details).
選択している承認は容認されたメッセージ系列のギャップがあるときさえ確認されるべきmisorderedデータメッセージを許容するオプションです。 (選択している承認がorderdata messagsの外でキャッシュされるmeaningul wheにすぎないことに注意してください。) このメカニズムを使用する利点が帽子iは不要な「再-トランスミッション」の数をgrealyに減少させます、その結果、帯域幅[COL85]を計算時間とトランスミッションの両方に救うということである、(Part8.2.4における議論を見てください、.1、その他の詳細のための.1)
8.2.4.2 Flow control confirmation and fast retransmission.
8.2.4.2 フロー制御確認と速い「再-トランスミッション」。
Flow control confirmation (FCC) is a mechanism of the transport protocol whereby acknowledgement messages containing critical flow control information are confirmed. The critical acknowledgement
フロー制御確認(FCC)は批判的なフロー制御情報を含む確認メッセージが確認されるトランスポート・プロトコルのメカニズムです。 批判的な承認
McCoy [Page 59] RFC 1008 June 1987
マッコイ[59ページ]RFC1008 1987年6月
messages are those that open a closed flow control window and certain ones that occur subsequent to a credit reduction. In principle, if these critical messages are lost, proper resynchroniztion of the flow control relies on the window timer, which is generally of relatively long duration. In order to reduce delay in resynchronizing the flow control, the receiving entity can repeatedly send, within short intervals, AK TPDUs carrying a request for confirmation of the flow control state, a procedure known as "fast" retransmission (of the acknowledgement). If the sender responds with an AK TPDU carrying an FCC parameter, fast retransmission is halted. If no AK TPDU carrying the FCC parameter is received, the fast transmission halts after having reached a maximum number of retransmissions, and the window timer resumes control of AK TPDU transmission. It should be noted that FCC is an optional mechanism of transport and the data sender is not required to respond to a request for confirmation of the flow control state wih an AK TPDU carrying the FCC parameter.
メッセージは、閉じているフロー制御ウィンドウを開けるものとクレジット減少にその後で起こるあるものです。 原則として、これらの批判的なメッセージが無くなるなら、フロー制御の適切なresynchroniztionはウィンドウタイマを当てにします。(それは、一般に、比較的長い持続時間のものです)。 フロー制御を再連動させる際に遅れを縮めるために、受信実体で、AK TPDUsは短い間隔以内に繰り返してフロー制御状態(「速い」「再-トランスミッション」(承認の)として知られている手順)の確認を求める要求を運ぶことができます。 AK TPDUがFCCパラメタを運んでいて送付者が応じるなら、速い「再-トランスミッション」は止められます。 FCCパラメタを運ぶどんなAK TPDUも受け取られていないなら、「再-トランスミッション」の最大数に達した後に速いトランスミッションは停止します、そして、ウィンドウタイマはAK TPDUトランスミッションのコントロールを再開します。 FCCが輸送の任意のメカニズムであることに注意されるべきであり、送付者がフロー制御状態の確認を求める要求に反応させている必要はないデータはFCCパラメタを運ぶAK TPDUをwihします。
Some considerations for deciding whether or not to use FCC and fast retransmisson procedures are as follows:
FCCと速いretransmisson手順を用いるかどうか決めるためのいくつかの問題は以下の通りです:
1) likelihood of credit reduction on a given transport connection;
1) 与えられた輸送接続のクレジット減少の見込み。
2) probability of TPDU loss;
2) TPDUの損失の確率。
3) expected window timer period;
3) 予想された窓のタイマの期間。
4) window size; and
4)ウィンドウサイズ。 そして
5) acknowledgement strategy.
5) 承認戦略。
At this time, there is no reported experience with using FCC and fast retransmission. Thus, it is not known whether or not the procedures produce sufficient reduction of resynchronization delay to warrant implementing them.
このとき、FCCと速い「再-トランスミッション」を使用する経験は報告されません。 したがって、手順が再同期遅れのそれらを実行するのを保証できるくらいの減少を起こすかどうかは知られていません。
When implementing fast retransmission, it is suggested that the timer used for the window timer be employed as the fast timer, since the window is disabled during fast retransmission in any case. This will avoid having to manage another timer. The formal description expressed the fast retransmission timer as a separate timer for clarity.
速い「再-トランスミッション」を実行するとき、ウィンドウタイマに使用されるタイマが速いタイマとして使われることが提案されます、窓がどのような場合でも速い「再-トランスミッション」の間、無能にされるので。 これは、別のタイマを管理しなければならないのを避けるでしょう。 形式的記述は明快のための別々のタイマとして速い再送信タイマーを急送しました。
8.2.4.3 Concatenation of acknowledgement and data.
8.2.4.3 承認とデータの連結。
When full duplex communication is being operated by two transport entities, data and acknowledgement TPDUs from each one of the entities travel in the same direction. The transport protocol permits concatenating AK TPDUs in the same NSDU as a DT TPDU. The advantage of using this feaure in an implementation is that fewer NSDUs will be transmitted, and, consequently, fewer total octets will
全二重通信が2つの輸送実体によって操作されているとき、実体のそれぞれからのデータと承認TPDUsは同じ方向に旅行します。 トランスポート・プロトコルは、DT TPDUとして同じNSDUでAK TPDUsを連結することを許可します。 実現にこのfeaureを使用する利点は、より少ないNSDUsが伝えられて、その結果、より少ない総八重奏が伝えられるということです。
McCoy [Page 60] RFC 1008 June 1987
マッコイ[60ページ]RFC1008 1987年6月
be sent, due to the reduced number of network headers transmitted. However, when operating over the IP, this advantage may not necessarily be recognized, due to the possible fragmentation of the NSDU by the IP. A careful analysis of the treatment of the NSDU in internetwork environments should be done to determine whether or not concatenation of TPDUs is of sufficient benefit to justify its use in that situation.
伝えられたネットワークヘッダーの減少している数のため送ってください。 しかしながら、IPの上で作動するとき、この利点は必ず認識されるかもしれないというわけではありません、IPによるNSDUの可能な断片化のため。 TPDUsの連結がその状況における使用を正当化できるくらいの利益のものであるかどうか決定するためにインターネットワーク環境における、NSDUの処理の慎重な分析をするべきです。
8.2.5 Retransmission policies.
8.2.5 Retransmission方針。
There are primarily two retransmission policies that can be employed in a transport implementation. In the first of these, a separate retransmission timer is initiated for each data message sent by the transport entity. At first glance, this approach appears to be simple and straightforward to implement. The deficiency of this scheme is that it is inefficient. This derives from two sources. First, for each data message transmitted, a timer must be initiated and cancelled, which consumes a significant amount of CPU processing time [BRI85]. Second, as the list of outstanding timers grows, management of the list also becomes increasingly expensive. There are techniques which make list management more efficient, such as a list per connection and hashing, but implementing a policy of one retransmission timer per transport connection is a superior choice.
主として、輸送実現で使うことができる2つの「再-トランスミッション」方針があります。 これらの1番目では、別々の再送信タイマーは輸送実体によって送られたそれぞれのデータメッセージのために開始されます。 一見したところでは、このアプローチは実行するために簡単であって、簡単であるように見えます。 この計画の欠乏はそれが効率が悪いということです。 これは2からソースを引き出します。 まず最初に、それぞれのデータメッセージが送られたのでタイマを開始されて、取り消さなければなりません(かなりの量のCPU処理時間[BRI85]を費やします)。 また、2番目に、傑出しているタイマのリストが成長するのに従って、リストの管理はますます高価になります。 より効率的で1接続あたり1つのリストのようにリスト管理を論じ尽くすテクニックは、ありますが、輸送接続あたり1個の再送信タイマーの政策を実施するのは、優れた選択です。
The second retransmission policy, implementing one retransmission timer for each transport conenction, avoids some of the inefficiencies cited above: the list of outstanding timers is shorter by approximately an order of magnitude. However, if the entity receiving the data is generating an acknowledgement for every data message, the timer must still be cancelled and restarted for each data/acknowledgement message pair (this is an additional impetus for implementing an Nth acknowledgement policy with N=2).
それぞれの輸送conenctionあたり1個の再送信タイマーを実行して、2番目の「再-トランスミッション」方針は以下の上で引用されたいくつかの非能率を避けます。 傑出しているタイマのリストはおよそ1桁より少ないです。 しかしながら、データを受信する実体があらゆるデータメッセージのための承認を発生させているなら、それぞれのデータ/確認メッセージ組のためにまだタイマを取り消されて、再開しなければなりません(これはN=2と共にNth承認政策を実施するための追加起動力です)。
The rules governing the single timer per connection scheme are listed below.
接続計画あたりの単一のタイマを治める規則は以下に記載されています。
1) If a data message is transmitted and the
retransmission timer for the connection is not
already running, the timer is started.
1) データメッセージが送られて、接続のための再送信タイマーが既に動いていないなら、タイマは始動されます。
2) If an acknowledgement for previously unacknowledged
data is received, the retransmission timer is restarted.
2) 以前に不承認のデータのための承認が受け取られているなら、再送信タイマーは再開されます。
3) If an acknowledgement message is received for the
last outstanding data message on the connection
then the timer is cancelled.
3) 接続に関する最後の傑出しているデータメッセージのために確認メッセージを受け取るなら、タイマを取り消します。
4) If the retransmission timer expires, one or more
unacknowledged data messages are retransmitted,
beginning with the one sent earliest. (Two
4) 再送信タイマーが期限が切れるなら、最も早くものを送って始まって、1つ以上の不承認のデータメッセージが再送されます。 (2
McCoy [Page 61] RFC 1008 June 1987
マッコイ[61ページ]RFC1008 1987年6月
reports [HEA85, BRI85] suggest that the number
to retransmit is one.)
レポート[HEA85、BRI85] 再送する数が1であると示唆してください。)
8.3 Protocol control.
8.3はコントロールについて議定書の中で述べます。
8.3.1 Retransmission timer values.
8.3.1 再送信タイマー値。
8.3.1.1 Data retransmission timer.
8.3.1.1 データ再送信タイマー。
The value for the reference timer may have a significant impact on the performance of the transport protocol [COL85]. However, determining the proper value to use is sometimes difficult. According to IS 8073, the value for the timer is computed using the transit delays, Erl and Elr, the acknowledgement delay, Ar, and the local TPDU processing time, x:
参照タイマのための値はトランスポート・プロトコル[COL85]の性能に重要な影響を与えるかもしれません。 しかしながら、固有値を使用する決定するのは時々難しいです。 8073、タイマのための値はトランジット遅れ、Erl、Elr、承認遅れ、アルゴン、および地方のTPDU処理時間を費やすことで計算されます、xことです:
T1 = Erl + Elr + Ar + x
T1はErl+Elr+アルゴン+xと等しいです。
The difficulty in arriving at a good retransmission timer value is directly related to the variability of these factors Of the two, Erl and Elr are the most susceptible to variation, and therefore have the most impact on determining a good timer value. The following paragraphs discuss methods for choosing retransmission timer values that are appropriate in several network environments.
良い再送信タイマー値に到着することにおける苦労は直接可変性に関係づけられて、2、Erl、およびElrがこれらの要素Ofでは、変化に最も影響されやすく、したがって、良いタイマ値を決定するとき最も多くの影響力を持っているということです。 以下のパラグラフはいくつかのネットワーク環境で適切な再送信タイマー値を選ぶための方法について議論します。
In a single-hop satellite environment, network delay (Erl or Elr) has small variance because of the constant propagation delay of about 270 ms., which overshadows the other components of network delay. Consequently, a fixed retransmission timer provides good performance. For example, for a 64K bit/sec. link speed and network queue size of four, 650 ms. provides good performance [COL85].
単一のホップ衛星環境では、ネットワーク遅延(ErlかElr)はおよそ270原稿の一定の伝播遅延のために小さい変化を持っています。(原稿はネットワーク遅延の他のコンポーネントを曇らせます)。 その結果、固定再送信タイマーは望ましい市場成果を提供します。 例えば、4、650の64Kのビット/秒のリンク速度とネットワーク待ち行列サイズのために、原稿は望ましい市場成果[COL85]を提供します。
Local area networks also have constant propagation delay. However, propagation delay is a relatively unimportant factor in total network delay for a local area network. Medium access delay and queuing delay are the significant components of network delay, and (Ar + x) also plays a significant role in determining an appropriate retransmission timer. From the discussion presented in Part 3.4.3.2 typical numbers for (Ar + x) are on the order of 5 - 6.5 ms and for Erl or Elr, 5 - 35 ms. Consequently, a reasonable value for the retransmission timer is 100 ms. This value works well for local area networks, according to one cited report [INT85] and simulation work performed at the NBS.
また、ローカル・エリア・ネットワークには、一定の伝播遅延があります。 しかしながら、伝播遅延はローカル・エリア・ネットワークのための総ネットワーク遅延の比較的重要でない要素です。 中型のアクセス遅延と遅れを列に並ばせるのは、ネットワーク遅延の重要なコンポーネントです、そして、また、(アルゴン+x)は適切な再送信タイマーを決定することにおける重要な役割をプレーします。 Part3.4.3で提示された議論から、(アルゴン+x)の.2の典型的な番号が5の注文で来ています--6.5ms、およびErlかElrのための5--35原稿Consequently、再送信タイマーのための適正価値は原稿This価値がローカル・エリア・ネットワークでよく扱う100です、1つの引用されたレポート[INT85]とNBSで行われたシミュレーション仕事に従って。
For better performance in an environment with long propagation delays and significant variance, such as an internetwork an adaptive algorithm is preferred, such as the one suggested value for TCP/IP [ISI81]. As analyzed by Jain [JAI85], the algorithm uses an exponential averaging scheme to derive a round trip delay estimate:
長い伝播遅延がある環境における、より良い性能とインターネットワークなどの重要な変化において、適応型のアルゴリズムは好まれます、TCP/IP[ISI81]のための1つの提案された値などのように。 ジャイナ教の[JAI85]、アルゴリズム用途による指数の平均を分析するように、周遊旅行遅れ見積りを引き出すのを計画してください:
D(i) = b * D(i-1) + (1-b) * S(i)
D(i)はb*D(i-1)+(1-b)*Sと等しいです。(i)
McCoy [Page 62] RFC 1008 June 1987
マッコイ[62ページ]RFC1008 1987年6月
where D(i) is the update of the delay estimate, S(i) is the sample round trip time measured between transmission of a given packet and receipt of its acknowledgement, and b is a weighting factor between 0 and 1, usually 0.5. The retransmission timer is expressed as some multiplier, k, of D. Small values of k cause quick detection of lost packets, but result in a higher number of false timeouts and, therefore, unnecessary retransmissions. In addition, the retransmission timer should be increased arbitrarily for each case of multiple transmissions; an exponential increase is suggested, such that
D(i)が遅れ見積りのアップデートであり、S(i)が承認の与えられたパケットと領収書のトランスミッションの間で測定されたサンプル周遊旅行時間であり、bが0と1の間の重み係数であるところでは、通常、0.5です。 何らかの乗数、kのD.Small値のkが無くなっているパケットの迅速な検出を引き起こすとき、再送信タイマーは急送されますが、誤ったタイムアウトとしたがって、不要な「再-トランスミッション」の、より大きい数をもたらしてください。 さらに、再送信タイマーは複駆動動力伝達装置に関する各ケースのために任意に増加するべきです。 急激な増加は示されて、そのようなものはそれです。
D(i) = c * D(i-1)
D(i)はc*Dと等しいです。(i-1)
where c is a dimensionless parameter greater than one.
cが点のパラメタ1以上であるところ。
The remaining parameter for the adaptive algorithm is the initial delay estimate, D(0). It is preferable to choose a slightly larger value than needed, so that unnecessary retransmissions do not occur at the beginning. One possibility is to measure the round trip delay during connection establishment. In any case, the timer converges except under conditions of sustained congestion.
D(0)、適応型のアルゴリズムのための残っているパラメタは初期の遅れ見積りです。 必要とされるよりわずかに大きい値を選ぶのは望ましいです、不要な「再-トランスミッション」が始めに現れないように。 1つの可能性はコネクション確立の間、周遊旅行遅れを測定することです。 どのような場合でも、持続している混雑の状態を除いて、タイマは一点に集まります。
8.3.1.2 Expedited data retransmission timer.
8.3.1.2 速められたデータ再送信タイマー。
The timer which governs retransmission of expedited data should be set using the normal data retransmission timer value.
速められたデータの「再-トランスミッション」を治めるタイマは正常なデータ再送タイマ価値を使用するように設定されるべきです。
8.3.1.3 Connect-request/confirm retransmission timer.
8.3.1.3 要求を接続している/は再送信タイマーを確認します。
Connect request and confirm messages are subject to Erl + Elr, total network delay, plus processing time at the receiving transport entity, if these values are known. If an accurate estimate of the round trip time is not known, two views can be espoused in choosing the value for this timer. First, since this timer governs connection establishment, it is desirable to minimize delay and so a small value can be chosen, possibly resulting in unnecessary retransmissions. Alternatively, a larger value can be used, reducing the possibility of unnecessary retransmissions, but resulting in longer delay in connection establishment should the connect request or confirm message be lost. The choice between these two views is dictated largely by local requirements.
要求を接続してください、そして、メッセージは受信輸送実体においてErl+Elr、総ネットワーク遅延、および処理時間を受けることがあると確認してください、これらの値が知られているなら。 周遊旅行時間の正確な見積りが知られていないなら、このタイマのために値を選ぶ際に2つの視点を信奉できます。 このタイマがコネクション確立を治めるのでまず最初に遅れを最小にするのが望ましいので、小さい値を選ぶことができます、ことによると不要な「再-トランスミッション」をもたらして。 あるいはまた、より大きい値を使用できます、不要な「再-トランスミッション」の可能性を減少させてコネクション確立の、より長い遅れをもたらすのが確認するべきである、要求を接続するか、またはメッセージが失われていると確認してください。 これらの2つの視点の選択は主に地方の要件によって書き取られます。
8.3.1.4 Disconnect-request retransmission timer.
8.3.1.4 再送信タイマーを分離して要求してください。
The timer which governs retransmission of the disconnect request message should be set from the normal data retransmission timer value.
分離要求メッセージの「再-トランスミッション」を治めるタイマは正常なデータ再送タイマ価値から設定されるべきです。
8.3.1.5 Fast retransmission timer.
8.3.1.5 速い再送信タイマー。
The fast retransmission timer causes critical acknowledgement
速い再送信タイマーは批判的な承認を引き起こします。
McCoy [Page 63] RFC 1008 June 1987
マッコイ[63ページ]RFC1008 1987年6月
messages to be retransmitted avoiding delay in resynchronizing credit. This timer should be set to approximately Erl + Elr.
再送された避けることであるメッセージはクレジットを再連動させる際に延着します。 このタイマはおよそErl+Elrに設定されるべきです。
8.3.2 Maximum number of retransmissions.
8.3.2 「再-トランスミッション」の最大数。
This transport parameter determines the maximum number of times a data message will be retransmitted. A typical value is eight. If monitoring of network service is performed then this value can be adjusted according to observed error rates. As a high error rate implies a high probability of TPDU loss, when it is desirable to continue sending despite the decline in quality of service, the number of TPDU retransmissions (N) should be increased and the retransmission interval (T1) reduced.
この輸送パラメタはデータメッセージが再送されるという回の最大数を測定します。 典型的な値は8です。 ネットワークがモニターされるなら、サービスを実行して、観測された誤り率に応じて、次に、この値を調整できます。 高い誤り率がサービスの質の下落にもかかわらず、発信し続けているのが望ましくTPDUの損失の高い確率に含意するように、TPDU retransmissions(N)の数は増加するべきでした、そして、再送信間隔(T1)は減少しました。
8.4 Selection of maximum Transport Protocol data unit size.
8.4 最大のTransportプロトコルデータ単位サイズの選択。
The choice of maximum size for TPDUs in negotiation proposals depends on the application to be served and the service quality of the supporting network. In general, an application which produces large TSDUs should use as large TPDUs as can be negotiated, to reduce the overhead due to a large number of small TPDUs. An application which produces small TSDUs should not be affected by the choice of a large maximum TPDU size, since a TPDU need not be filled to the maximum size to be sent. Consequently, applications such as file transfers would need larger TPDUs while terminals would not. On a high bandwidth network service, large TPDUs give better channel utilization than do smaller ones. However, when error rates are high, the likelihood for a given TPDU to be damaged is correlated to the size and the frequency of the TPDUs. Thus, smaller TPDU size in the condition of high error rates will yield a smaller probability that any particular TPDU will be lost.
交渉提案におけるTPDUsのための最大サイズのこの選択は役立たれるアプリケーションとサポートネットワークのサービス品質次第です。 一般に、大きいTSDUsを生産するアプリケーションは多くの小さいTPDUsによるオーバーヘッドを下げるために交渉できるのと同じくらい大きいTPDUsを使用するべきです。 小さいTSDUsを生産するアプリケーションは大きい最大のTPDUサイズの選択で影響を受けるべきではありません、TPDUが送られる最大サイズにいっぱいにされる必要はないので。 その結果、ファイル転送などの応用は端末が必要でないだろうという間、より大きいTPDUsを必要とするでしょう。 高帯域ネットワーク・サービスのときに、大きいTPDUsは、より小さいものより良いチャンネル利用を与えます。 しかしながら、誤り率が高いときに、与えられたTPDUが破損する見込みはTPDUsのサイズと頻度に関連します。 したがって、高い誤り率の状態の、より小さいTPDUサイズはどんな特定のTPDUもなくされるというよりわずかな確率をもたらすでしょう。
The implementor must choose whether or not to apply a uniform maximum TPDU size to all connections. If the network service is uniform in service quality, then the selection of a uniform maximum can simplify the implementation. However, if the network quality is not uniform and it is desirable to optimize the service provided to the transport user as much as possible, then it may be better to determine the maximum size on an individual connection basis. This can be done at the time of the network service access if the characteristics of the subnetwork are known.
作成者は、一定の最大のTPDUサイズをすべての接続に適用するかどうかを選ばなければなりません。 ネットワーク・サービスが一定の使用中の品質であるなら、一定の最大の選択は実現を簡素化できます。 しかしながら、ネットワーク品質が一定でなく、輸送ユーザにできるだけ提供されたサービスを最適化するのが望ましいなら、個々接続ベースで最大サイズを測定しているほうがよいかもしれません。 サブネットワークの特性を知っているなら、ネットワーク・サービスアクセス時点で、これができます。
NOTE: The maximum TPDU size is important in the calculation of the flow control credit, which is in numbers of TPDUs offered. If buffer space is granted on an octet base, then credit must be granted as buffer space divided by maximum TPDU size. Use of a smaller TPDU size can be equivalent to optimistic credit allocation and can lead to the expected problems, if proper analysis of the management is not done.
以下に注意してください。 最大のTPDUサイズはフロー制御クレジットの計算で重要です。(提供されたTPDUsの数にはクレジットがあります)。 八重奏ベースの上でバッファ領域を与えるなら、最大のTPDUサイズが割られたバッファ領域としてクレジットを与えなければなりません。 より小さいTPDUサイズの使用は、楽観的なクレジット配分に同等である場合があり、予想された問題を引き起こすことができます、管理の適切な分析が完了していないなら。
McCoy [Page 64] RFC 1008 June 1987
マッコイ[64ページ]RFC1008 1987年6月
9 Special options.
9 特別なオプション。
Special options may be obtained by taking advantage of the manner in which IS 8073 and N3756 have been written. It must be emphasized that these options in no way violate the intentions of the standards bodies that produced the standards. Flexibility was deliberately written into the standards to ensure that they do not constrain applicability to a wide variety of situations.
方法の利点を見て取ることによって、特別なオプションを得るかもしれません、そして、(8073です)N3756を書きました。 これらのオプションが規格を生産した標準化団体の意志に決して違反しないと強調しなければなりません。 柔軟性は、さまざまな状況への適用性を抑制しないのを保証するために故意に規格に書かれました。
9.1 Negotiations.
9.1の交渉。
The negotiation procedures in IS 8073 have deliberate ambiguities in them to permit flexibility of usage within closed groups of communicants (the standard defines explicitly only the behavior among open communicants). A closed group of communicants in an open system is one which, by reason of organization, security or other special needs, carries on certain communication among its members which is not of interest or not accessible to other open system members. Examples of some closed groups within DOD might be: an Air Force Command, such as the SAC; a Navy base or an Army post; a ship; Defense Intelligence; Joint Chiefs of Staff. Use of this characteristic does not constitute standard behavior, but it does not violate conformance to the standard, since the effects of such usage are not visible to non-members of the closed group. Using the procedures in this way permits options not provided by the standard. Such options might permit,for example, carrying special protection codes on protocol data units or for identifying DT TPDUs as carrying a particular kind of message.
交渉手順は8073が封鎖グループの聖餐拝受者の中で用法の柔軟性を可能にするためにそれらに慎重なあいまいさを持っているという(規格はオープンな聖餐拝受者の中で明らかに振舞いだけを定義します)中のことです。 オープンシステムの封鎖グループの聖餐拝受者はメンバーの中の他のオープンシステムメンバーには、興味深くないか、またはアクセス可能でない、あるコミュニケーションで組織、セキュリティまたは他の特別な必要性の理由によって運ばれるものです。 DODの中のいくつかの封鎖グループに関する例は以下の通りです。 SACなどの空軍Command。 海軍ベースか陸軍ポスト。 船。 ディフェンス知性。 統合参謀本部。 この特性の使用は標準の振舞いを構成しませんが、規格に順応に違反しません、封鎖グループの非会員にとって、そのような用法の効果が目に見えないので。 このように手順を用いると、規格によって提供されなかったオプションは可能にします。 そのようなオプションは、例えば、プロトコルデータ単位かDT TPDUsを特定するために特定の種類に関するメッセージを伝えるとして特別な保護コードを運ぶことを許可するかもしれません。
Standard negotiation procedures state that any parameter in a received CR TPDU that is not defined by the standard shall be ignored. This defines only the behavior that is to be exhibited between two open systems. It does not say that an implementation which recognizes such non-standard parameters shall not be operated in networks supporting open systems interconnection. Further, any other type TPDU containing non-standard parameters is to be treated as a protocol error when received. The presumption here is that the non-standard parameter is not recognized, since it has not been defined. Now consider the following example:
標準の交渉手順は、規格によって定義されない容認されたCR TPDUのどんなパラメタも無視されると述べます。 これは2つのオープンシステムの間に示されることになっている振舞いだけを定義します。それは、開放型システム間相互接続を支持するネットワークでそのような標準的でないパラメタを認識する実現を操作しないことを示しません。 さらに、受け取ると、標準的でないパラメタを含むいかなる他のタイプTPDUもプロトコル誤りとして扱うことになっています。 それが定義されていないので標準的でないパラメタが認識されないという推定がここにあります。 今度は、以下の例を考えてください:
Entity A sends Entity B a CR TPDU containing a non-standard parameter.
実体Aは標準的でないパラメタを含むCR TPDUをEntity Bに送ります。
Entity B has been implemented to recognize the non-standard parameter and to interpret its presence to mean that Entity A will be sending DT TPDUs to Entity B with a special protection identifier parameter included.
実体Bは、標準的でないパラメタを認識して、特別な保護識別子パラメタが含まれている状態でEntity AがEntity BにDT TPDUsを送ることを意味するために存在を解釈するために実行されました。
Entity B sends a CC TPDU containing the non-standard parameter to indicate to Entity A that it has received and understood the parameter, and is prepared to receive the specially marked DT TPDUs
実体Bは、それがパラメタを受け取って、理解して、特に著しいDT TPDUsを受け取るように準備されるのをEntity Aに示すために標準的でないパラメタを含むCC TPDUを送ります。
McCoy [Page 65] RFC 1008 June 1987
マッコイ[65ページ]RFC1008 1987年6月
from Entity A. Since Entity A originally sent the non-standard parameter, it recognizes the parameter in the CC TPDU and does not treat it as a protocol error.
Since Entity Aが元々標準的でないパラメタを送ったEntity A.から、それは、CC TPDUのパラメタを認識して、プロトコル誤りとしてそれを扱いません。
Entity A may now send the specially marked DT TPDUs to Entity B and Entity B will not reject them as protocol errors.
実体Aは現在特に著しいDT TPDUsをEntity Bに送るかもしれません、そして、Entity Bはプロトコル誤りとして彼らを拒絶しないでしょう。
Note that Entity B sends a CC TPDU with the non-standard parameter only if it receives a CR TPDU containing the parameter, so that it does not create a protocol error for an initiating entity that does not use the parameter. Note also that if Entity B had not recognized the parameter in the CR TPDU, it would have ignored it and not returned a CC TPDU containing the parameter. This non-standard behavior is clearly invisible and inaccessible to Transport entities outside the closed group that has chosen to implement it, since they are incapable of distinguishing it from errors in protocol.
それがパラメタを含むCR TPDUを受ける場合にだけEntity Bが標準的でないパラメタがあるCC TPDUを送ることに注意してください、パラメタを使用しない開始実体のためのプロトコル誤りを作成しないように。 また、Entity BがCR TPDUのパラメタを認識しなかったなら、それを無視して、パラメタを含むCC TPDUを返さなかったことに注意してください。 この標準的でない振舞いは、それを実行するのを選んだ封鎖グループの外でTransport実体に明確に目に見えなくて、近づきがたいです、彼らがプロトコルにおける誤りとそれを区別できないので。
9.2 Recovery from peer deactivation.
9.2 同輩非活性化からの回復。
Transport does not directly support the recovery of the transport connection from a crashed remote transport entity. A partial recovery is possible, given proper interpretation of the state tables in Annex A to IS 8073 and implementation design. The interpretation of the Class 4 state tables necessary to effect this operation is as follows:
輸送は墜落しているリモート輸送実体から輸送接続の回復を直接支持しません。 部分的な回復は可能です、Annex Aのステートテーブルの適切な解釈を考えて8073と実現はデザインですか? この操作に作用するのに必要なClass4ステートテーブルの解釈は以下の通りです:
Whenever a CR TPDU is received in the state OPEN, the entity is required only to record the new network connection and to reset the inactivity timer. Thus, if the initiator of the original connection is the peer which crashed, it may send a new CR TPDU to the surviving peer, somehow communicating to it the original reference numbers (there are several ways that this can be done).
州のオープンにCR TPDUを受け取るときはいつも、実体が、単に新しいネットワーク接続を記録して、不活発タイマをリセットするのに必要です。 したがって、オリジナルの接続の創始者が同輩であるなら、(クラッシュしました)新しいCR TPDUを生き残っている同輩に送るかもしれません、どうにか元の参照番号をそれに伝えて(これをできるいくつかの道があります)。
Whenever a CC TPDU is received in the
CC TPDUに受け取るときはいつも
state OPEN, the receiver is required only to record the new network connection, reset the inactivity timer and send either an AK, DT or ED TPDU. Thus, if the responder for the original connection is the peer which crashed, it may send a new CC TPDU to the surviving peer, communicating to it the original reference numbers.
州のオープン、受信機は新しいネットワーク接続を記録して、不活発タイマをリセットして、AK、DTまたはED TPDUを送るだけでよいです。 したがって、オリジナルの接続のための応答者が同輩であるなら、(クラッシュしました)新しいCC TPDUを生き残っている同輩に送るかもしれません、元の参照番号をそれに伝えて。
In order for this procedure to operate properly, the situation in a., above, requires a CC TPDU to be sent in response. This could be the original CC TPDU that was sent, except for new reference numbers. The original initiator will have sent a new reference number in the new CR TPDU, so this would go directly into the CC TPDU to be returned. The new reference number for the responder could just be a new assignment, with the old reference number frozen. In the situation in b., the originator could retain its reference number (or
適切に操作するこの手順において整然とします、a.の状況は上でCC TPDUが応答で送られるのを必要とします。 これは新しい参照番号を除いて、送られたオリジナルのCC TPDUであるかもしれません。 オリジナルの創始者が新しいCR TPDUで新しい参照番号を送ってしまうだろうので、これは返すために直接CC TPDUに入るでしょう。 応答者の新しい参照番号はまさしく古い参照番号が凍っている新しい課題であるかもしれません。 またはb.の状況で、創始者が参照番号を保有できた、(。
McCoy [Page 66] RFC 1008 June 1987
マッコイ[66ページ]RFC1008 1987年6月
assign a new one if necessary), since the CC TPDU should carry both old reference numbers and a new one for the responder (see below). In either situation, only the new reference numbers need be extracted from the CR/CC TPDUs, since the options and parameters will have been previously negotiated. This procedure evidently requires that the CR and CC TPDUs of each connection be stored by the peers in nonvolatile memory, plus particulars of the negotiations.
必要なら、新しいものを割り当ててください、)、CC TPDUが応答者のために古い参照番号と新しいものの両方を運ぶはずであるので(以下を見てください)。 どちらの状況でも、新しい参照番号だけがCR/CC TPDUsから抽出されなければなりません、オプションとパラメタが以前に交渉されてしまうだろうので。 この手順は、明らかにそれぞれの接続のCRとCC TPDUsが不揮発性メモリにおける同輩、および交渉の子細によって格納されるのを必要とします。
To transfer the new reference numbers, it is suggested that the a new parameter in the CR and CC TPDU be defined, as in Part 9.1, above. This parameter could also carry the state of data transfer, to aid in resynchronizing, in the following form:
新しい参照番号を移すために、CRとCC TPDUのa新しいパラメタが定義されることが提案されます、上のPart9.1のように。 また、このパラメタは再連動、以下のフォームで支援するためにデータ転送の状態を運ぶかもしれません:
1) the last DT sequence number received by the peer that crashed;
1) 同輩によって受け取られた最後のDT一連番号に、それはクラッシュしました。
2) the last DT sequence number sent by the peer that
crashed;
2) 同輩によって送られた最後のDT一連番号に、それはクラッシュしました。
3) the credit last extended by the peer that crashed;
3) クレジットは最後にクラッシュした同輩で広がりました。
4) the last credit perceived as offered by the surviving peer;
4) 生き残っている同輩によって提供されるように知覚された最後のクレジット。
5) the next DT sequence number the peer that crashed expects to
send (this may not be the same as the last one sent, if the last
one sent was never acknowledged);
5) 次のDT一連番号に、クラッシュした同輩は、発信すると予想します(これは最後のものが発信したのと同じでないかもしれません、1つが送った最終が決して承認されなかったなら)。
6) the sequence number of an unacknowledged ED TPDU, if any;
6) もしあれば不承認のED TPDUの一連番号
7) the normal data sequence number corresponding to the
transmission of an unacknowledged ED TPDU, if any (this is to
ensure the proper ordering of the ED TPDU in the normal data
flow);
7) もしあれば(これは正常なデータフローにおける、ED TPDUの適切な注文を確実にするためのものである)不承認のED TPDUのトランスミッションに対応する標準のデータ一連番号
A number of other considerations must be taken into account when attempting data transfer resynchronization. First, the recovery will be greatly complicated if subsequencing or flow control confirmation is in effect when the crash occurs. Careful analysis should be done to determine whether or not these features provide sufficient benefit to warrant their inclusion in a survivable system. Second, non-volatile storage of TPDUs which are unacknowledged must be used in order that data loss at the time of recovery can be minimized. Third, the values for the retranmsission timers for the communicating peers must allow sufficient time for the recovery to be attempted. This may result in longer delays in retransmitting when TPDUs are lost under normal conditions. One way that this might be achieved is for the peers to exchange in the original CR/CC TPDU exchange, their expected lower bounds for the retransmission timers, following the procedure in Part 9.1. In this manner, the peer that crashed may be determine whether or not a new connection should be attempted. Fourth, while the recovery involves directly only the transport peers when operating over a connectionless network service, recovery when
データ転送再同期を試みるとき、他の多くの問題を考慮に入れなければなりません。 まず最初に、事実上、副配列かフロー制御確認がクラッシュが起こる時であるときに、回復は大いに複雑になるでしょう。 これらの特徴が生存可能なシステムでの彼らの包含を保証できるくらいの利益を提供するかどうか決定するために慎重な分析をするべきです。 2番目に、回復時点のデータの損失を最小にすることができるように認められないTPDUsの非揮発性記憶装置を使用しなければなりません。 3番目に、交信がじっと見るので、retranmsissionタイマのための値は、十分な時間、回復が試みられるのを許容しなければなりません。 これはTPDUsが正常な状況ではなくされているとき再送するより長い遅れをもたらすかもしれません。 1つの方法で、これが達成されるかもしれないのは、オリジナルのCR/CC TPDU交換で交換する同輩のためのものです、再送信タイマーのための彼らの予想された下界、Part9.1で手順に従って。 この様に、墜落するそれが同輩であるかもしれないことは、新しい接続が試みられるべきであるかどうかと決心しています。 コネクションレスなネットワーク・サービスの上で作動するとき、回復が直接輸送だけにかかわりますが、4番目はじっと見て、回復はいつです。
McCoy [Page 67] RFC 1008 June 1987
マッコイ[67ページ]RFC1008 1987年6月
operating over a connection-oriented network service requires some sort of agreement as to when a new network connection is to be established (if necessary) and which peer is responsible for doing it. This is required to ensure that unnecessary network connections are not opened as a result of the recovery. Splitting network connections may help to ameliorate this problem.
(必要なら、)新しいネットワーク接続がいつ確立されることになっているか、そして、どの同輩がそれをするのに責任があるかに関して接続指向のネットワーク・サービスの上で作動するのはある種の協定を必要とします。 これが、不要なネットワーク接続が回復の結果、開かれないのを保証するのに必要です。 ネットワーク接続を分けるのは、この問題を改善するのを助けるかもしれません。
9.3 Selection of transport connection reference numbers.
9.3 輸送接続参照番号の品揃え。
In N3756, when the reference wait period for a connection begins, the resources associated with the connection are released and the reference number is placed in a set of frozen references. A timer associated with this number is started, and when it expires, the number is removed from the set. A function which chooses reference numbers checks this set before assigning the next reference number. If it is desired to provide a much longer period by the use of a large reference number space, this can be met by replacing the implementation dependent function "select_local_ref" (page TPE-17 of N3756) by the following code:
接続のための参照待ちの期間が始まるとき、N3756では、接続に関連しているリソースは発表されます、そして、参照番号は凍っている参照のセットに置かれます。 この数に関連しているタイマを始動します、そして、期限が切れるとき、セットから数を取り除きます。 次の参照番号を割り当てる前に、参照番号を選ぶ機能はこのセットをチェックします。 大きい参照番号スペースの使用ではるかに長い期間を提供するのが必要であるなら、実現に依存する機能「選んだ_地元の_審判」(N3756のページTPE-17)を以下のコードに取り替えることによって、これに会うことができます:
function select_local_ref : reference_type;
機能は_地元の_審判を選びます: 参照_タイプ。
begin
last_ref := (last_ref + 1) mod( N+1 ) + 1;
while last_ref in frozen_ref[class_4] do
last_ref := (last_ref + 1) mod( N+1 ) + 1;
select_local_ref := last_ref;
end;
最後に_審判:=(_審判+1を持続する)モッズ(N+1)+1を始めてください。 凍っている_審判[クラス_4]という最後の_審判である間、最後の_審判:=(最終_審判+1)にモッズ(N+1)+1をしてください。 _地元の_審判の:=最終_審判を選んでください。 終わってください。
where "last_ref" is a new variable to be defined in declarations (pages TPE-10 - TPE-11), used to keep track of the last reference value assigned, and N is the length of the reference number cycle, which cannot exceed 2**16 - 1 since the reference number fields in TPDUs are restricted to 16 bits in length.
「最後の_審判」がどこの値が割り当てた最後の参照の動向をおさえるのに使用される宣言(ページTPE-10--TPE-11)とNで定義されるべき新しい変数であるかは長さが参照番号サイクルから16ビットの長さです。(TPDUsの参照番号分野が制限されるので、サイクルは2**16--1を超えることができません)。
9.4 Obtaining Class 2 operation from a Class 4 implementation.
9.4 Class4実現からClass2操作を得ます。
The operation of Class 4 as described in IS 8073 logically contains that of the Class 2 protocol. The formal description, however, is written assuming Class 4 and Class 2 to be distinct. This was done because the description must reflect the conformance statement of IS 8073, which provides that Class 2 alone may be implemented.
説明されて、中に8073が論理的にあるとき、Class4の操作はClass2プロトコルのものを含んでいます。 しかしながら、Class4とClass2が異なっていると仮定しながら、形式的記述は書かれています。 必須が順応声明を反映する記述が8073であるので、これをして、どれが単独でそのClass2を提供するか実装するかもしれません。
However, Class 2 operation can be obtained from a Class 4 implementation, which would yield the advantages of lower complexity, smaller memory requirements, and lower implementation costs as compared to implementing the classes separately. The implementor will have to make the following provisions in the transport entity and the Class 4 transport machine to realize Class 2 operation.
しかしながら、Class4実装からClass2操作を得ることができます。(別々にクラスを実装すると比べて、それは、下側の複雑さ、より小さいメモリ要件、および低い実装コストの利点をもたらすでしょう)。 作成者は、Class2操作がわかるために輸送実体とClass4輸送マシンで以下の条項を作らなければならないでしょう。
McCoy [Page 68] RFC 1008 June 1987
マッコイ[68ページ]RFC1008 1987年6月
1) Disable all timers. In the formal description, all Class 4
timers except the reference timer are in the Class 4 TPM.
These timers can be designed at the outset to be enabled or
not at the instantiation of the TPM. The reference timer is
in the Transport Entity module (TPE) and is activated by the
TPE recognizing that the TPM has set its "please_kill_me"
variable to "freeze". If the TPM sets this variable instead
to "now", the reference timer for that transport connection is
never started. However, IS 8073 provides that the reference
timer can be used, as a local entity management decision, for
Class 2.
1) すべてのタイマを損傷してください。 形式的記述、参照タイマ以外のすべてのClass4タイマがClass4TPMで中です。 これらのタイマは、最初に、TPMの具体化で可能にされるように設計される場合があります。 参照タイマを、Transport Entityモジュール(TPE)であって、TPMが、「__私を殺してください」という変数に「凍る」ように設定したと認めるTPEは動かせます。 TPMが代わりに「現在に」この変数を設定するなら、その輸送接続のための参照タイマは決して始動されません。 しかしながら、8073が、Class2にaローカル要素経営上の決定として参照タイマを使用できるのを前提とするということです。
The above procedure should be used when negotiating from Class
4 to Class 2. If Class 2 is proposed as the preferred class,
then it is advisable to not disable the inactivity timer, to
avoid the possibility of deadlock during connection
establishment if the peer entity never responds to the CR
TPDU. The inactivity timer should be set when the CR TPDU is
sent and deactivated when the CC TPDU is received.
Class4からClass2まで交渉するとき、上の手順は用いられるべきです。 Class2が都合のよいクラスとして提案されて、同輩実体がCR TPDUに決して応じないなら、コネクション確立の間、行き詰まりの可能性を避けるために不活発タイマを損傷しないのは賢明です。 CC TPDUが受け取られているとき、CR TPDUが送られて、非活性化されるとき、不活発タイマは設定されるべきです。
2) Disable checksums. This can be done simply by ensuring that
the boolean variable "use_checksums" is always set to "false"
whenever Class 2 is to be proposed or negotiated.
2) チェックサムを無効にしてください。単にClass2が提案されることになっているか、または交渉されることになっているときはいつも、ブール変数「使用_チェックサム」がいつも「誤っていること」に設定されるのを確実にすることによって、これができます。
3) Never permit flow control credit reduction. The formal
description makes flow control credit management a function of
the TPE operations and such management is not reflected in the
operation of the TPM. Thus, this provision may be handled by
always making the "credit-granting" mechanism aware of the
class of the TPM being served.
3) フロー制御クレジット減少を決して可能にしないでください。 形式的記述はフロー制御クレジット管理をTPE操作の機能にします、そして、そのような管理はTPMの操作に反映されません。 したがって、この支給は、いつも「信用供与」メカニズムを役立たれているTPMのクラスを意識するようにすることによって、扱われるかもしれません。
4) Include Class 2 reaction to network service events. The Class
4 handling of network service events is more flexible than
that of Class 2 to provide the recovery behavior
characteristic of Class 4. Thus, an option should be provided
on the handling of N_DISCONNECT_indication and
N_RESET_indication for Class 2 operation. This consists of
sending a T_DISCONNECT_indication to the Transport User,
setting "please_kill_me" to "now" (optionally to "freeze"),
and transitioning to the CLOSED state, for both events. (The
Class 4 action in the case of the N_DISCONNECT is to remove
the network connection from the set of those associated with
the transport connection and to attempt to obtain a new
network connection if the set becomes empty. The action on
receipt of the N_RESET is to do nothing, since the TPE has
already issued the N_RESET_response.)
4) ネットワーク・サービスイベントへのClass2反応を含めてください。 Class4の回復挙動の特性を提供することではネットワーク・サービスイベントのClass4取り扱いはClass2のものよりフレキシブルです。 したがって、Class2操作のためのN_DISCONNECT_指示とN_RESET_指示の取り扱いのときにオプションを提供するべきです。 これはT_DISCONNECT_指示をTransport Userに送るのから成ります、「現在に」(任意に「凍る」)「__私を殺してください」を設定して、CLOSED状態に移行して、両方のイベントのために。 (N_DISCONNECTの場合におけるClass4動作は、セットが空になるなら、輸送接続に関連づけられたもののセットからネットワーク接続を外して、新しいネットワーク接続を得るのを試みることです。 RESETが無をすることになっているN_を受け取り次第TPEが既にN_RESET_応答を発行して以来の動作
5) Ensure that TPDU parameters conform to Class 2. This implies
that subsequence numbers should not be used on AK TPDUs, and
no flow control confirmation parameters should ever appear in
an AK TPDU. The checksum parameter is prevented from
5) TPDUパラメタがClass2に従うのを確実にしてください。 これはAK TPDUsで続き番号を使用するべきでなくて、フロー制御確認パラメタが全くAK TPDUに現れるべきでないのを含意します。 パラメタが防がれるチェックサム
McCoy [Page 69] RFC 1008 June 1987
マッコイ[69ページ]RFC1008 1987年6月
appearing by the "false" value of the "use_checksums"
variable. (The acknowledgement time parameter in the CR and
CC TPDUs will not be used, by virtue of the negotiation
procedure. No special assurance for its non-use is
necessary.)
「使用_チェックサム」の「誤った」値で、可変に見えます。 (CRとCC TPDUsの承認時間パラメタは交渉手順によって使用されないでしょう。 非使用のためのどんな特別な保証も必要ではありません。)
The TPE management of network connections should see to it
that splitting is never attempted with Class 4 TPMs running as
Class 2. The handling of multiplexing is the same for both
classes, but it is not good practice to multiplex Class 4 and
Class 2 together on the same network connection.
ネットワーク接続のTPE経営者側は、Class4TPMsがClass2として稼働であっている中に分かれることが決して試みられないように取り計らうべきです。 両方のクラスに、マルチプレクシングの取り扱いは同じですが、同じネットワーク接続のときにClass4とClass2を一緒に多重送信するのは、良い習慣ではありません。
McCoy [Page 70] RFC 1008 June 1987
マッコイ[70ページ]RFC1008 1987年6月
10 References.
10の参照箇所。
[BRI85] Bricker, A., L. Landweber, T. Lebeck, M. Vernon,
"ISO Transport Protocol Experiments," Draft Report
prepared by DLS Associates for the Mitre Corporation,
October 1985.
[BRI85]Bricker、A.、L.Landweber、T.Lebeck、M.ヴァーノン、「ISOはプロトコル実験を輸送します」、Mitre社のためにDLS Associatesによって準備されたDraft Report、1985年10月。
[COL85] Colella, Richard, Marnie Wheatley, Kevin Mills,
"COMSAT/NBS Experiment Plan for Transport Protocol,"
NBS, Report No. NBSIR 85-3141, May l985.
[COL85]Colella(リチャード、Marnieホイートリー、ケビン工場、「トランスポート・プロトコルのためのコミュニケーションサテライトコーポレーション/NBS実験プラン」、NBS)は、いいえと報告します。 NBSIR85-3141、5月のl985。
[CHK85] Chernik, C. Michael, "An NBS Host to Front End
Protocol," NBSIR 85-3236, August 1985.
1985年8月の[CHK85]Chernik、C.マイケル、「フロントエンドプロトコルへのNBSホスト」NBSIR85-3236。
[CHO85] Chong, H.Y., "Software Development and Implementation
of NBS Class 4 Transport Protocol," October 1985
(available from the author).
[CHO85]チョン、H.Y.、「NBSのソフトウェア開発と実装は4トランスポート・プロトコルを分類する」1985(作者から利用可能な)年10月。
[HEA85] Heatley, Sharon, Richard Colella, "Experiment Plan:
ISO Transport Over IEEE 802.3 Local Area Network,"
NBS, Draft Report (available from the authors),
October 1985.
[HEA85] ヒートリー、シャロン、リチャードColella、「プランを実験してください」 「ISO Transport Over IEEE802.3ローカル・エリア・ネットワーク」、NBS、Draft Report(作者から利用可能な)、1985年10月。
[INT85] "Performance Comparison Between 186/51 and 552,"
The Intel Corporation, Reference No. COM,08, January
1985.
[INT85]「パフォーマンス比較186/51〜552」、インテル社、参照No. COM、1985年1月の08。
[ISO84a] IS 8073 Information Processing - Open Systems
Interconnection - Transport Protocol Specification,
available from ISO TC97/SC6 Secretariat, ANSI,
1430 Broadway, New York, NY 10018.
[ISO84a]は8073情報Processingです--オープン・システム・インターコネクション--プロトコルSpecificationを輸送してください、ISO TC97/SC6事務局、ANSI、1430ブロードウェイ(ニューヨーク)、ニューヨーク 10018から、利用可能です。
[ISO84b] IS 7498 Information Processing - Open Systems
Interconnection - Basic Reference Model, available
from ANSI, address above.
[ISO84b]は情報Processing--オープン・システム・インターコネクション--基本的なANSIから利用可能なReference Modelが上で扱う7498です。
[ISO85a] DP 9074 Estelle - A Formal Description Technique
Based on an Extended State Transition Model,
available from ISO TC97/SC21 Secretariat, ANSI,
address above.
9074年の[ISO85a]DPエステル--ISO TC97/SC21事務局から利用可能なExtended州Transition Modelの上のTechnique Based(ANSI)が上で扱うFormal記述。
[ISO85b] N3756 Information Processing - Open Systems
Interconnection - Formal Description of IS 8073
in Estelle. (Working Draft, ISO TC97/SC6)
[ISO85b]N3756情報処理--オープン・システム・インターコネクション--形式的記述、エステルの8073はそうです。 (作業草案、ISO TC97/SC6)
McCoy [Page 71] RFC 1008 June 1987
マッコイ[71ページ]RFC1008 1987年6月
[ISO85c] N3279 Information Processing - Open Systems
Interconnection - DAD1, Draft Addendum to IS 8073
to Provide a Network Connection Management
Service, ISO TC97/SC6 N3279, available from
SC6 Secretariat, ANSI, address above.
[ISO85c]N3279情報Processing--オープン・システム・インターコネクション--DAD1、Draft Addendum、Network Connection Management Service、SC6事務局、ANSIから利用可能なISO TC97/SC6 N3279が上で扱うProvideへの8073はそうです。
[JAI85] Jain, Rajendra K., "CUTE: A Timeout Based Congestion
Control Scheme for Digitial Network Architecture,"
Digital Equipment Corporation (available from the
author), March 1985.
[JAI85]ジャイナ教徒、Rajendra K.、「かわいい:、」 「Digitial Network ArchitectureのためのTimeout Based Congestion Control Scheme」、ディジタルイクイップメント社(作者から利用可能な)、1985年3月。
[LIN85] Linn, R.J., "The Features and Facilities of Estelle,"
Proceedings of the IFIP WG 6.1 Fifth International
Workshop on Protocol Specification, Testing and
Verification, North Holland Publishing, Amsterdam,
June 1985.
[LIN85]リン、R.J.と「エステルの特徴と施設」とプロトコル仕様における第5IFIP WG6.1の国際ワークショップの議事とテストと検証、北のオランダの出版、アムステルダム(1985年6月)
[MIL85a] Mills, Kevin L., Marnie Wheatley, Sharon Heatley,
"Predicting Transport Protocol Performance",
(in preparation).
ケビンL.、Marnieホイートリー、シャロン・ヒートリーが「トランスポート・プロトコルパフォーマンスを予測し」て、[MIL85a]はかけめぐります(準備で)。
[MIL85b] Mills, Kevin L., Jeff Gura, C. Michael Chernik,
"Performance Measurement of OSI Class 4 Transport
Implementations," NBSIR 85-3104, January 1985.
[MIL85b]工場、ケビンL.、ジェフ・グーラ、C.マイケルChernik、「OSIのクラス4輸送実装のパフォーマンス測定」、NBSIR85-3104(1985年1月)。
[NAK85] Nakassis, Anastase, "Fletcher's Error Detection
Algorithm: How to Implement It Efficiently and
How to Avoid the Most Common Pitfalls," NBS,
(in preparation).
[NAK85]Nakassis、Anastase、「のフレッチャー誤り検出アルゴリズム:、」 「Avoid Most Common PitfallsへのImplement It EfficientlyとHowへのどのように」、NBS(準備における)。
[NBS83] "Specification of a Transport Protocol for
Computer Communications, Volume 3: Class 4
Protocol," February 1983 (available from
the National Technical Information Service).
[NBS83] 「輸送の仕様はコンピュータコミュニケーション、第3巻のために議定書を作ります」。 1983(技術情報サービスから利用可能な)年2月の「クラス4プロトコル。」
[NTA84] Hvinden, Oyvind, "NBS Class 4 Transport Protocol,
UNIX 4.2 BSD Implementation and User Interface
Description," Norwegian Telecommunications
Administration Establishment, Technical Report
No. 84-4053, December 1984.
[NTA84]Hvinden、Oyvind、「NBSのクラス4はプロトコル、UNIX4.2BSD実装、およびユーザーインタフェース記述を輸送します」、ノルウェーのテレコミュニケーション政権設立、技術報告書No.84-4053、1984年12月。
[NTI82] "User-Oriented Performance Measurements on the
ARPANET: The Testing of a Proposed Federal
Standard," NTIA Report 82-112 (available from
NTIA, Boulder CO)
[NTI82]、「アルパネットに関する利用者志向パフォーマンス測定:」 「提案された連邦規格のテスト」、NTIAレポート82-112(NTIA、ボウルダーCOから利用可能)です。
[NTI85] "The OSI Network Layer Addressing Scheme, Its
Implications, and Considerations for Implementation",
NTIA Report 85-186, (available from NTIA, Boulder CO)
[NTI85] 「実装のためのOSIネットワーク層アドレシング体系、含意、および問題」と、NTIAは85-186に報告します。(NTIA、ボウルダーCOから利用可能)です。
[RFC85] Mills, David, "Internet Delay Experiments," RFC889,
[RFC85] 工場、デヴィッド、「インターネット遅れ実験」、RFC889
McCoy [Page 72] RFC 1008 June 1987
マッコイ[72ページ]RFC1008 1987年6月
December 1983 (available from the Network Information
Center).
1983(ネットワークインフォメーション・センターから利用可能な)年12月。
[SPI82] Spirn, Jeffery R., "Network Modeling with Bursty
Traffic and Finite Buffer Space," Performance
Evaluation Review, vol. 2, no. 1, April 1982.
[SPI82]Spirn(ジェフェリーR.)は「Burstyトラフィックと有限バッファ領域でモデルをネットワークでつなぎます」、パフォーマンスEvaluation Review、vol.2、No.1、1982年4月。
[SPI84] Spirn, Jeffery R., Jade Chien, William Hawe,
"Bursty Traffic Local Area Network Modeling,"
IEEE Journal on Selected Areas in Communications,
vol. SAC-2, no. 1, January 1984.
[SPI84]Spirn、ジェフェリーR.、ジャドChien、ウィリアムHawe、「Burstyトラフィックローカル・エリア・ネットワークモデル」、CommunicationsのSelected Areasの上のIEEE Journal、vol.SAC-2、いいえ、1、1984年1月。
McCoy [Page 73]
マッコイ[73ページ]
一覧
スポンサーリンク
