RFC979 日本語訳
0979 PSN End-to-End functional specification. A.G. Malis. March 1986. (Format: TXT=39472 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Andrew G. Malis
Request for Comments: 979 BBN Communications Corp.
March 1986
Malisがコメントのために要求するワーキンググループアンドリューG.をネットワークでつないでください: 979 1986年のBBNコミュニケーション社の行進
PSN END-TO-END FUNCTIONAL SPECIFICATION
PSN終わりから終わりへの機能的な仕様
Status of this Memo
このMemoの状態
This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification". It has been updated to reflect changes since that report was written, and is being distributed in this form to provide information to the ARPA-Internet community about this work. The changes described in this memo will affect AHIP (1822 LH/DH/HDH) and X.25 hosts directly connected to BBNCC PSNs. Information concerning the schedule for deployment of this version of the PSN software (Release 7.0) in the ARPANET and the MILNET can be obtained from DCA. Distribution of this memo is unlimited.
このメモはBBN Report5775のアップデートされたバージョン、「終わりから終わりへの機能的な仕様」です。 それをそのレポートが書かれたので変化を反映するためにアップデートして、この仕事に関してARPA-インターネットコミュニティに情報を提供するためにこのフォームで分配しています。 このメモで説明された変化はAHIP(1822LH/DH/HDH)と直接BBNCC PSNsに接続されたX.25ホストに影響するでしょう。 DCAからアルパネットとMILNETでのPSNソフトウェア(リリース7.0)のこのバージョンの展開のためのスケジュールに関する情報を得ることができます。 このメモの分配は無制限です。
1 Introduction
1つの序論
This memo contains the functional specification for the new BBNCC PSN End-to-End (EE) protocol and module (PSN stands for Packet Switch node, and has previously been known as the IMP). The EE module is that portion of the PSN code which is responsible for maintaining EE connections that reliably deliver data across the network, and for handling the packet level (level 3) interactions with the hosts. The EE protocol is the peer protocol used between EE modules to create, maintain, and close connections. The new EE is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the PSN to support its current and anticipated host population.
このメモは新しいBBNCC PSN Endから終わり(EE)へのプロトコルとモジュールのための機能的な仕様を含んでいます(PSNはPacket Switchノードを表して、以前に、IMPとして知られています)。 EEモジュールはホストとのパケット・レベル(レベル3)相互作用をネットワーク、および取り扱いのためのデータに確かに提供するEE接続を維持するのに原因となるPSNコードのその部分です。 EEプロトコルは接続を創造して、維持して、終えるのにEEモジュールの間で使用される同輩プロトコルです。 新しいEEは、性能と総合的なスループットを向上させて、現在の、そして、予期されたホスト人口をサポートするためにPSNをよりよく備えるために古いEEの多くの欠乏を修正するために開発されています。
The initial version of the new EE is being fielded in PSN Release 7.0. Both the old and new EEs are resident in the PSN code, and each PSN may run either the old or the new EE (but not both) at any time, under the control of the Network Operations Center (NOC). The NOC has facilities for switching individual PSNs or the entire network between the old and new EEs. When the old EE is running, PSN 7.0's functionality is equivalent to that provided by PSN 6.0, and the differences listed in this memo do not apply. Hosts on PSNs running the old EE cannot interoperate with hosts on PSNs running the new EE.
新しいEEの初期のバージョンはPSN Release7.0でさばかれています。 両方の古くて新しいEEsはPSNコードで居住しています、そして、各PSNはいつでも古いEEか新しいEE(ともにない)を実行するかもしれません、ネットワーク運営センター(NOC)のコントロールの下で。 NOCは古くて新しいEEsの間に切り換えの個々のPSNsか全体のネットワークのための施設を持っています。 古いEEが稼働する予定であるとき、PSN7.0の機能性はPSN6.0によって提供されたそれに同等です、そして、このメモに記載された違いは適用されません。 PSNsの上のホストが新しいEEを実行している状態で、古いEEを実行するPSNsの上のホストは共同利用できません。
There are two additional sections following this introduction. Section two describes the motivation and goals driving the new EE project.
この序論に続く2つの追加セクションがあります。 セクションtwoは新しいEEプロジェクトを追い立てる動機と目標について説明します。
Section three contains the new EE's functional specification. It describes the services provided to the various types of hosts that
セクションthreeは新しいEEの機能的な仕様を含みます。 それが様々なタイプのホストに提供されたサービスについて説明する、それ
Malis [Page 1]
Malis[1ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
are supported by the PSN, the addressing capabilities that it makes available, the functionality required for the peer protocol, and the performance goals for the new EE.
PSN、それが利用可能にするアドレス指定能力、同輩プロトコルに必要である機能性、および新しいEEの性能目標で、サポートされます。
Two notes concerning terminology are required. Throughout this document, the units of information sent from one host to another are referred to as "messages", and the units into which these messages are fragmented for transmission through the subnetwork are referred to as "subnet packets" or just "packets". This differs from X.25's terminology; X.25 "packets" are actually messages. Also, in this report the term "AHIP" is used to refer to the ARPANET Host-IMP Protocol described in BBN Report 1822, "Specifications for the Interconnection of a Host and an IMP".
用語に関する2つの注が必要です。 このドキュメント中では、1人のホストから別のものに送られた情報のユニットは「メッセージ」と呼ばれます、そして、これらのメッセージがサブネットワークを通したトランスミッションのために断片化されるユニットは「サブネットパケット」かまさしく「パケット」と呼ばれます。 これはX.25の用語と異なっています。 X.25「パケット」は実際にメッセージです。 また、このレポートでは、"AHIP"という用語は、プロトコルがBBNレポート1822で説明したアルパネットホスト悪童と、「ホストのインタコネクトのための仕様と悪童」について言及するのに使用されます。
2 Motivation
2 動機
The old EE was developed almost a decade ago, in the early days of packet-switching technology. This part of the PSN has remained stable for eight years, while the environment within which the technology operates has changed dramatically. At the time the old EE was developed, it was used in only one network, the ARPANET. There are now many PSN-based networks, some of which are grouped into internets. Originally, AHIP was the only host interface protocol, with NCP above it. The use of X.25 is now rapidly increasing, and TCP/IP has replaced NCP.
古いEEはおよそ10年前にパケット交換技術の初期で開発されました。 PSNのこの部分は8年間安定した状態を保っています、技術が作動する環境が劇的に変化しましたが。 古いEEが開発されたとき、それは1つのネットワークだけ、アルパネットに使用されました。 現在、多くのPSNを拠点とするネットワークがあります。その或るものはインターネットに分類されます。 元々、AHIPはそれの上にNCPがある唯一のホスト・インターフェースプロトコルでした。 X.25の使用は今急速に増加しています、そして、TCP/IPはNCPを置き換えました。
This section describes the needs for more flexibility and increases in some of the limits of the old EE, and lists the goals which this new design should meet.
このセクションは、より多くの柔軟性の必要性について説明して、古いEEの限界のいくつかを増やして、この新案が達成するべきである目標を記載します。
2.1 Benefits of a New EE
2.1 新しいEEの利益
Network growth and the changing network environment make improved
performance, in terms of increasing the PSN's throughput, an
important goal for the new EE. The new EE reduces protocol
traffic overhead, thereby making more efficient use of network
line bandwidth and transit PSN processing power.
ネットワークの成長と変化しているネットワーク環境は向上した性能をします、PSNのスループットを増強することに関して、新しいEEの重要な目標。 新しいEEはプロトコルトラフィックオーバーヘッドを下げます、その結果、ネットワーク系列帯域幅とトランジットPSN処理能力の、より効率的な使用をします。
The new EE provides a set of network transport services which are
appropriate for both the AHIP and X.25 host interfaces, unlike the
old EE, which is highly optimized for and tightly tied to the AHIP
host interface.
新しいEEは1セットのAHIPとX.25ホスト・インターフェースの両方に、適切なネットワーク輸送サービスを提供します、古いEEと異なって。EEはAHIPに非常に最適化されて、しっかり結ばれたホスト・インターフェースです。
The new EE has an adjustable window facility instead of the old
EE's fixed window of eight outstanding messages between any host
pair. The old EE applies this limit to all traffic between a pair
of hosts; it has no notion of multiple independent channels or
新しいEEはどんなホスト組の間にも古いEEの8つの傑出しているメッセージのはめ殺し窓の代わりに調整可能なウィンドウ施設を持っています。 古いEEは1組のホストの間のすべてのトラフィックへのこの限界を適用します。 またはそれには複数の独立しているチャンネルの考えが全くない。
Malis [Page 2]
Malis[2ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
connections between two hosts, which the new EE allows. A network
with satellite trunking, and consequently long delays, is an
example of where the new window facility increases the EE
throughput that can be attained. TACs and gateways provide
another example where the old EE's fixed window limits throughput;
all of the traffic between a host and a TAC or a gateway currently
uses the same EE connection and is subject to the limit of eight
outstanding messages, even if more than one user's traffic flows
are involved. With the new EE, this restriction no longer
applies.
2人のホストの間の接続。新しいEEはそのホストを許容します。 衛星中継方式があるネットワーク、およびその結果長時間の遅延は新しいウィンドウ施設が得ることができるEEスループットを増強するところに関する例です。 TACsとゲートウェイは古いEEが修理された別の例に窓の限界スループットを提供します。 ホストとTACかゲートウェイの間のトラフィックのすべてが、現在、同じEE接続を使用して、8つの傑出しているメッセージの限界を受けることがあります、1人以上のユーザの交通の流れがかかわっても。 新しいEEと共に、この制限はもう適用されません。
Supportability also motivates rewriting the EE software. The new
EE can be written using more modern techniques of programming
practice, such as layering and modularity, which were not as well
understood when the old EE was first designed, and which will make
the EE easier to support and to enhance.
また、サポートのしやすさは、EEソフトウェアを書き直しながら、動機づけます。 古いEEが最初に、設計されて、EEをサポートして、高めるのをより簡単にするまた、理解されていなかったレイヤリングやモジュール方式などの習慣をプログラムするより現代のテクニックを使用することで新しいEEを書くことができます。
Finally, the new EE includes a number of new features that improve
the PSN's ability to provide services which are more closely
optimized to what our customers need for their applications.
These include new addressing capabilities, precedence levels,
end-to-end data integrity checks, and monitoring and control
capabilities.
最終的に、新しいEEは、より密接に私たちの顧客が彼らのアプリケーションに必要とするものに最適化されるサービスを提供するPSNの性能を改良する多くの新機能を含んでいます。 これらは新しいアドレス指定能力、先行レベル、終わりから終わりへのデータ保全チェック、モニター、およびコントロール能力を含んでいます。
2.2 Goals for the New EE
2.2 新しいEEの目標
The new EE's X.25 support is greatly improved over that provided
by the old EE. One element of this improvement is at least
halving the amount of per-message EE protocol overhead. Another
element is the unification of the different storage allocation
mechanisms used by the old EE and X.25 modules, where data
transferred between the old EE and X.25 must be copied from one
type of structure to the other.
新しいEEのX.25サポートは古いEEによって提供されたそれの上で大いに改良されます。 この改良のある要素が1メッセージあたりのEEプロトコルオーバーヘッドの量を少なくとも半分にしています。 別の要素は古いEEによって使用された異なった記憶領域の割当てメカニズムとX.25モジュールの統一です。そこでは、1つのタイプの構造からもう片方まで古いEEとX.25の間に移されたデータをコピーしなければなりません。
The new EE presents, as much as possible, a non-blocking interface
to the hosts. If a host overwhelms the PSN with traffic, the PSN
ultimately has to block it, but this should happen less frequently
than at present.
新しいEEは非ブロッキングインタフェースをホストにできるだけ提示します。 ホストがトラフィックでPSNを圧倒するなら、PSNは結局、それを妨げなければなりませんが、これは現在のところよりどんな頻繁にも起こるべきではありません。
In the old EE, all of the hosts contend for the same pool of
resources. In the new EE, fairness is enforced in resource
allocation among different hosts through per-host minimum
allocations for buffers and connection blocks as part of a general
buffer management system. This insures that no host can be
completely "shut out" of service by the actions of another host at
its PSN.
古いEEでは、ホストは皆、リソースの同じプールを競争します。 新しいEEでは、公正は一般的なバッファ管理システムの一部として異なったホストの中で資源配分でバッファと接続ブロックのための1ホストあたりの最小の配分で励行されます。 これは、PSNでサービスについて別のホストの動作で完全にホスト全く「入らないようにすることができるというわけではないこと」を保障します。
Malis [Page 3]
Malis[3ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
The EE supports four precedence levels and optional (on a per-
network basis) preemption features.
EEが先行レベルで任意の状態で4をサポートする、(a、-、基礎) 先取り機能をネットワークでつないでください。
Addressing capabilities have been extended to include hunt groups.
狩りグループを含むようにアドレス指定能力を広げてあります。
Instead of a fixed window of eight outstanding messages between
any host pair, the maximum window size on an EE connection is
configurable to a maximum of 127. The EE allows host pairs to set
up multiple connections, each with an independent window.
8つの傑出しているメッセージのはめ殺し窓の代わりに、ホスト組、いずれも間でEE接続での最大のウィンドウサイズは最大127に構成可能です。 EEはホスト組にそれぞれ独立している窓との複数の接続をセットアップさせます。
A result of the old EE's reliance on destination buffer
reservation is that subnet packets can be lost if an intermediate
node goes down. The new EE uses source buffering with
retransmission in order to provide more reliable service.
目的地バッファの予約への古いEEの信用の結果は中間的ノードが落ちるならサブネットパケットが失われる場合があるということです。 新しいEEは、より信頼できるサービスを提供するのに「再-トランスミッション」とのソースバッファリングを使用します。
The new EE has a duplex peer protocol, allowing acknowledgments to
be piggybacked on reverse traffic to reduce protocol overhead.
When reverse traffic is not available, acknowledgments are
aggregated and sent together.
新しいEEには、承認がプロトコルオーバーヘッドを下げるために逆のトラフィックで背負われるのを許容して、重複の同輩プロトコルがあります。 逆のトラフィックが利用可能でないときに、承認を一緒に集めて、送ります。
The result of this development will be end-to-end software with
greater performance, supportability, and functionality.
この開発の結果は、より大きい性能、サポートのしやすさ、および機能性をもって終わりからエンドへのソフトウェアになるでしょう。
3 End-to-End Functionality
3 終わりから終わりへの機能性
This section contains the new EE's functional specification. It describes the services provided to the various types of hosts that are supported by the new EE, the addressing capabilities that it makes available, the functionality required for the peer protocol, the performance goals for the new EE, the EE's network management specification, and provisions for testing and debugging.
このセクションは新しいEEの機能的な仕様を含みます。 それは新しいEEによってサポートされる、様々なタイプのホスト、それが利用可能にするアドレス指定能力、同輩プロトコルに必要である機能性、新しいEEの性能目標、EEのネットワークマネージメント仕様、およびテストとデバッグのための条項に提供されたサービスについて説明します。
3.1 Network Layer Services
3.1 ネットワーク層サービス
The most important part of designing any new system is determining
its external functionality. In the case of the new EE, this is
the network layer services and interfaces presented to the hosts.
どんな新しいシステムも設計する最も重要な部分は外部の機能性を決定しています。 新しいEEの場合では、これは、ホストに提示されたネットワーク層サービスとインタフェースです。
3.1.1 Common Functionality
3.1.1 一般的な機能性
The following three sections list details concerning the new
EE's support for the X.25, AHIP and Interoperable network layer
services. In the interest of brevity, however, additional
functionality available to all three services is listed herein:
以下の3つのセクションが新しいEEのX.25、AHIP、およびInteroperableネットワーク層サービスのサポートに関して詳細をリストアップします。 しかしながら、簡略にするため、すべての3つのサービスに利用可能な追加機能性はここにリストアップされています:
o In order to check data integrity as packets cross through
the network, the old EE relies on a trunk-level,
o パケットがネットワークを通して交差するときデータ保全をチェックするために、古いEEはトランクレベルを当てにします。
Malis [Page 4]
Malis[4ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
hardware/ firmware-generated, per-packet CRC code (which
is either 16 or 24 bits in size, depending on the PSN-PSN
trunk protocol in use) and a software-generated
per-packet 16-bit checksum. Neither of these are
end-to-end checks, only PSN-to-PSN checks. For the new
EE, the software checksum has been extended to be an
optional 32-bit end-to-end checksum, and the per-packet
software checksum has been reduced to a parity bit.
1パケットあたりのファームウェアでハードウェア/発生しているCRCコード(PSN-PSNトランクプロトコルに使用中によって、サイズにおいて16ビットか24ビットである)と1パケットあたり1つのソフトウェアで発生している16ビットのチェックサム。 どちらも、終わりから終わりへのチェック、PSNから唯一のPSNはこれらの、チェックではありません。 新しいEEに関しては、終わりから終わりへの任意の32ビットのチェックサムになるようにソフトウェアチェックサムを広げてあります、そして、1パケットあたりのソフトウェアチェックサムはパリティビットに減少しました。
The network administration now has a choice as to which
is most important, efficient utilization of network
trunks (due to the reduced size of the per-packet
headers), or strong checks on data integrity.
ネットワーク管理には、現在、どれが大部分かに関して重要な選択、ネットワークトランクス(パケットのヘッダーの減少しているサイズによる)の効率的な利用、またはデータ保全の強いチェックがあります。
Those hosts that require strong data integrity checking
can request, in their configuration, that all messages
originating from this host include a 32-bit per-message
end-to-end checksum. This checksum is computed in the
source PSN, is ignored by tandem PSNs along the path, and
is checked in the destination PSN. If the checksum does
not check, the EE's regular source retransmission
facilities are used to have the message resent.
強いデータ保全の照合を必要とするそれらのホストは、彼らの構成でこのホストから発するすべてのメッセージが1メッセージあたりの終わりから終わりへの32ビットのチェックサムを含んでいるよう要求できます。 このチェックサムは、ソースPSNで計算されて、経路に沿って2人乗り自転車PSNsによって無視されて、目的地PSNでチェックされます。 チェックサムがチェックしないなら、EEの通常のソース「再-トランスミッション」施設は、メッセージを再送させるのに使用されます。
o The old EE's access control mechanism allows 15 separate
communities of interest to be defined, and uses an
unnecessarily complicated algorithm to define which
communities can intercommunicate. This mechanism is
being expanded to allow 32 communities of interest,
rather than the previous limit of 15. The feature that
allowed hosts to communicate with a community without
actually being a member of that community has been
removed because it was never utilized.
o 古いEEのアクセス管理機構は、興味がある別々の15の共同体が定義されるのを許容して、どの共同体が通信し合われることができるかを定義するのに不必要に複雑なアルゴリズムを使用します。 このメカニズムは、15の前の限界よりむしろ興味がある32の共同体を許容するために広げられています。 それが決して利用されなかったので、ホストが実際にその共同体のメンバーであるのなしで共同体とコミュニケートできた特徴を取り除いてあります。
o The addressing capabilities of the PSN have been improved
by the new EE. In addition to continuing to support the
old EE's logical addressing facility, hunt groups (for
both AHIP and X.25 hosts) have been added. These are
described further in Section 3.2.
o PSNのアドレス指定能力は新しいEEによって改良されました。 古いEEの論理的なアドレシング施設をサポートし続けていることに加えて、狩りグループ(AHIPとX.25ホストの両方のための)は加えられます。 これらはセクション3.2で、より詳しく説明されます。
o Connection block preemption is supported on a
configurable per-network basis. If a network is
configured to use connection block preemption, then
lower-precedence connections can be closed by the PSN,
if necessary, in order to maintain configured
reserves of PSN resources for higher-precedence
connections.
o 接続ブロック先取りは1ネットワークあたり1個の構成可能ベースでサポートされます。 ネットワークが接続ブロック先取りを使用するために構成されるなら、必要なら、PSNは、より高い先行接続のためにPSNリソースの構成された蓄えを維持するために下側の先行接続を閉店させることができます。
Malis [Page 5]
Malis[5ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
o The new EE supports congestion control and improved
resource allocation policies which ensure fairness and
graceful degradation of service under extreme load.
Certain resources can be prereserved to each host port,
and each port can also be limited in its use of shared
resources. This ensures that no host can be totally shut
out from PSN resources by the actions of other hosts at
the same PSN. In addition, each PSN is sensitive to
congestion in both of the PSNs at the endpoints of each
connection, and it can exert backpressure (flow control)
on hosts, as necessary, to prevent congestion.
o 新しいEEは、輻輳制御と改良された資源配分が極端な負荷での下サービスの公正と優雅な退行を確実にする方針であると、サポートします。 それぞれのホストポートに、あるリソースを前予約できます、そして、また、共用資源を使用で各ポートを制限できます。 これは、同じPSNでPSNリソースから他のホストの動作でホスト全く完全に入らないようにすることができるというわけではないのを確実にします。 さらに、それぞれのPSNはそれぞれの接続の終点でPSNsの両方での混雑に敏感です、そして、それは混雑を防ぐために必要に応じて背圧(フロー制御)をホストに加えることができます。
3.1.2 X.25
3.1.2 X.25
The new EE's X.25 service represents an improvement over the
X.25 service available from the old EE. The following
paragraphs summarize the X.25 support in the new EE:
新しいEEのX.25サービスは古いEEから利用可能なX.25サービスの上の改良を表します。 以下のパラグラフは新しいEEにX.25サポートをまとめます:
o The new EE provides both DDN Standard and Basic X.25
service, as described in BBN Reports 5476, "DDN X.25 Host
Interface Specification," and 5500, "C/30 PSN X.25
Interface Specification," respectively. In addition, the
description of DDN Standard Service, Version 2, is found
in Section 3.1.4 of this document.
o 新しいEEはDDN StandardとBasic X.25サービスの両方を提供します、BBN Reports5476、「DDN X.25ホスト・インターフェース仕様」と5500、「C/30PSN X.25インターフェース仕様」でそれぞれ説明されるように。 さらに、DDN Standard Serviceの記述(バージョン2)はこの.4通のセクション3.1ドキュメントで見つけられます。
o All data packets and call requests are source-buffered in
the source PSN to provide a better level of reliability
for network traffic. This should keep the network from
issuing a reset on an open connection as a result of a
lost packet in the subnet or any other occasional
subnetwork failure. Except in cases of extreme network
or node congestion, recovery from lost subnet packets is
automatic and transparent to the end user or host.
o すべてのデータ・パケットと発呼要求は、より良いレベルの信頼性をネットワークトラフィックに提供するソースでソースによってバッファリングされたPSNです。 これは、ネットワークがオープンな接続のときにサブネットにおける無くなっているパケットかいかなる他の時々のサブネットワーク失敗の結果、リセットを発行するのを妨げるべきです。 極端なネットワークかノード混雑に関するケースを除いて、エンドユーザかホストにとって、無くなっているサブネットパケットからの回復は、自動であって、透明です。
o Both local and end-to-end significance for host window
advancement (based upon the D bit from the host) are
planned, but only end-to-end significance is included in
the initial release (the old EE did not include local
significance). The D bit is passed through the network
transparently.
o ホスト窓の前進(ホストからDビットに基づいている)のための地方の、そして、かつ終わるために終わっている意味は計画されていますが、終わりから終わりへの意味だけが初期のリリースに含まれています(古いEEはローカルの意味を含んでいませんでした)。 Dビットは透過的にネットワークに通り抜けます。
3.1.3 AHIP
3.1.3 AHIP
Another service provided by the new EE is defined in BBN Report
1822, "Specifications for the Interconnection of a Host and an
IMP", as amended by Report 5506, "The ARPANET 1822L Host Access
Protocol". This ARPANET Host-IMP Protocol (AHIP) service is
新しいEEによって提供された別のサービスはBBN Report1822と、「ホストのインタコネクトのための仕様と悪童」で定義されます、Report5506、「アルパネット1822Lホストアクセス・プロトコル」によって修正されるように。 このアルパネットHost-IMPプロトコル(AHIP)サービスはそうです。
Malis [Page 6]
Malis[6ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
supported in a backwards-compatible manner by the new EE; since
this is a BBNCC-private protocol, the new EE can improve the
service to better match its current uses (the AHIP protocol was
first designed over twelve years ago). The main changes to
AHIP are to remove the absolute eight-message-in-flight
restriction for connection-based traffic, and to improve the
PSN's "datagram" support for non-connection-based traffic.
後方にコンパチブル方法で、新しいEEによってサポートされます。 これがBBNCC個人的なプロトコルであるので、新しいEEは、より一層現在の用途を合わせるためにサービスを改良できます(AHIPプロトコルは12年以上前に最初に、設計されました)。 AHIPへの主な変化が絶対を取り除くことになっている、8メッセージ機内、接続ベースのトラフィック、PSNの非接続ベースのトラフィックの「データグラム」サポートを改良する制限。
For this new support, datagram service is planned (for PSN
Release 8.0) to include fragmentation and reassembly by the
network, but without requiring the network overhead used by
connections, and without the reliability, message sequencing,
and duplicate detection that connections provide. However,
"destination dead" indications will be provided to the source
host where possible and appropriate.
この新しいサポートのために、データグラムサービスは、断片化を含んで、ネットワークで再アセンブリするように計画されていますが(PSN Release8.0のために)、ネットワークオーバーヘッドを必要とするメッセージ配列であることと、そして、接続が提供する接続と、信頼性と、写し検出なしで使用されます。 しかしながら、可能であって、適切であるところで「目的地死者」指摘を送信元ホストに提供するでしょう。
With the new EE, hosts are also able to create multiple
connections between host pairs by using the 8-bit "handling
type" field to specify up to 256 different connections. The
field is divided into high-order bits that specify the
connection's precedence, and low-order bits that distinguish
between multiple connections at the same precedence level.
Since the new EE is using four precedence levels, the handling
type field is used to specify 64 different connections at each
of the four precedence levels.
また、新しいEEと共に、ホストは、最大256の異なった接続を指定するのに8ビットの「取り扱いタイプ」分野を使用することによって、ホスト組の間の複数の接続を創造できます。 分野は接続の先行を指定する高位のビット、および同じ先行レベルで複数の接続を見分ける下位のビットに分割されます。 新しいEEが4つの先行レベルを使用しているので、取り扱いタイプ分野はそれぞれの4つの先行レベルで64の異なった接続を指定するのに使用されます。
AHIP connections will continue to be implicitly created and
automatically torn down after a configurable period (nominally
three minutes) of inactivity, or because of connection block
contention.
AHIP接続がそれとなく作成されて、構成可能な期間の後に自動的に取りこわされ続ける、(名目上は、3分) 不活発、または接続ブロック主張のために。
To summarize the new end-to-end's AHIP support:
新しい終わりから終わりのAHIPをまとめるために、以下をサポートしてください。
o The old EE's AHIP services are supported in a
backwards-compatible manner (except where listed below).
o 後方にコンパチブル方法(以下に記載されているのを除いた)で古いEEのAHIPサービスはサポートされます。
o The old EE's uncontrolled (subtype 3) message service
will be replaced, in PSN Release 8.0, by the datagram
service mentioned above. This service will provide
fragmentation and reassembly, so that there is no special
restriction on the size of datagrams; will not insure
that messages are delivered in order or unduplicated, or
provide a delivery confirmation; will notify the source
host if the destination host or PSN is dead; will not
require the connection block overhead associated with
connections; and may lose messages in the subnet, without
notification to the source host, in the event of subnet
o 古いEEの非制御(「副-タイプ」3)のメッセージサービスを取り替えるでしょう、PSN Release8.0で、前記のようにデータグラムサービスで。 このサービスが断片化を提供して、再アセンブリされるので、どんな特別な制限もデータグラムのサイズにありません。 配送確認をメッセージが整然とした状態で提供されるのを保障しないか、非コピーしなかったか、または前提としないでしょう。 目的地のホストかPSNが死んでいると、送信元ホストに通知するでしょう。 接続に関連している接続ブロックオーバーヘッドを必要としないでしょう。 そして、サブネットの場合、通知なしでサブネットにおけるメッセージを送信元ホストに失うかもしれません。
Malis [Page 7]
Malis[7ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
congestion or component failures. This service could be
useful for applications that do not need the absolute
reliability or sequentiality of connections and therefore
wish to avoid their associated overhead.
混雑かコンポーネント故障。 このサービスはしたがって彼らの関連オーバーヘッドを避けたがっていない接続の絶対の信頼性かsequentialityが必要があって、アプリケーションに、役に立つかもしれません。
Datagrams are not supported by the new EE in PSN Release
7.0.
データグラムはPSN Release7.0で新しいEEによってサポートされません。
o Connections no longer have the old EE's "eight messages
in flight" restriction, and a pair of hosts can be
connected with up to 256 simultaneous implicit
connections. In addition, multiple precedence levels are
supported.
o コネクションズには、古いEEの「飛行での8つのメッセージ」制限がもうありません、そして、最大256人の同時の暗黙接続に1組のホストは接続できます。 さらに、複数の先行レベルがサポートされます。
o The new EE supports interoperability between AHIP and
X.25 hosts (see Section 3.1.4 for further details).
o 新しいEEはAHIPとX.25の間の相互運用性にホストをサポートします(さらに詳しい明細についてはセクション3.1.4を見てください)。
o AHIP local, distant, and HDH (both message and packet
mode) hosts are supported. The new EE does not support
VDH hosts. VHA and 32-bit leaders are supported.
o 冷ややかなAHIPローカルとHDH(メッセージとパケット形態の両方)ホストはサポートされます。 新しいEEはVDHホストをサポートしません。 VHAと32ビットのリーダーは支えられます。
o Packet-mode HDH has been extended to allow longer packet
data frames (see BBN Report 1822, Appendix J, for a
description of the HDH protocol). Middle packet frames
can now contain up to 128 octets of data, rather than the
previous 126 (although there must still be an even number
of octets per frame). Last packet frames can now contain
up to 127 octets of data, rather than the previous 125,
and the number of octets need not be even. However, the
maximum total message size is still 1007 data octets. The
PSN uses these new packet frame size limits when sending
packet frames to packet-mode HDH hosts unless the host is
configured to allow only 126-octet frames. In addition,
there are restrictions on packet-mode HDH when
interoperating with DDN Standard X.25 hosts; these
restrictions are discussed in Section 3.1.4.
o パケット形態HDHは、より長いパケットデータフレームを許容するために広げられました(BBN Report1822を見てください、Appendix J、HDHプロトコルの記述のために)。 中央パケットフレームは現在、前の126よりむしろデータの最大128の八重奏を含むことができます(1フレームあたりの八重奏の偶数がまだあるに違いありませんが)。 最後のパケットフレームは現在前の125よりむしろデータの最大127の八重奏を含むことができます、そして、八重奏の数は偶数である必要はありません。 しかしながら、それでも、最大の総メッセージサイズは1007のデータ八重奏です。 ホストが126八重奏のフレームだけを許容するために構成されない場合パケット形態HDHホストにパケットフレームを送るとき、PSNはこれらの新しいパケットフレーム・サイズ限界を使用します。 DDN Standard X.25ホストと共に共同利用するとき、さらに、制限がパケット形態HDHにあります。 セクション3.1.4でこれらの制限について議論します。
3.1.4 Interoperability (DDN Standard X.25)
3.1.4 相互運用性(DDNの標準のX.25)
One of the main goals of the new EE is to provide
interoperability between AHIP and X.25 hosts. On the surface,
this may appear difficult, since the two host access protocols
have little in common: X.25 presents a connection-oriented
interface with explicit windowing, while AHIP presents a
reliable datagram-oriented interface with implicit flow
control. However, they both have the same underlying
新しいEEの第一目的の1つはAHIPとX.25ホストの間に相互運用性を供給することになっています。 表面では、2つのホストアクセス・プロトコルが少ししか共通でないので、これが難しく見えるかもしれません: X.25は明白なウインドーとの接続指向のインタフェースを提示しますが、AHIPは暗黙のフロー制御との信頼できるデータグラム指向のインタフェースを提示します。 しかしながら、それらの両方で、同じくらいは基礎となるようになります。
Malis [Page 8]
Malis[8ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
functionality: they allow the hosts to submit and receive
messages, and they both provide a reliable and sequenced
delivery service.
機能性: 彼らは、ホストにメッセージを提出して、受け取らせます、そして、それらの両方が信頼できて配列されたデリバリ・サービスを前提とします。
The key to interoperability is the fact that in the new EE,
both X.25 and AHIP connections use the same underlying
protocols and constructs. The new EE has AHIP and X.25 Level 3
modules that translate between the specific host protocols and
the EE mechanisms. Since these Level 3 host modules share a
common interface with the EE, the fact that the two hosts on
either side of an EE connection are not using the same access
protocol is largely hidden.
相互運用性のキーは新しいEEでは、X.25とAHIP接続の両方が同じ基本的なプロトコルと構造物を使用するという事実です。 新しいEEには、特定のホストプロトコルとEEメカニズムの間で翻訳されるAHIPとX.25 Level3モジュールがあります。これらのLevel3ホストモジュールがEEとの一般的なインタフェースを共有するので、EE接続の両方の側面の上の2人のホストが同じアクセス・プロトコルを使用していないという事実は主に隠されます。
As a result, the new EE supports basic interoperability.
However, there are some special cases that need to be mapped
from one protocol to the other, or just not supported because
no mapping exists. For example, AHIP has no analogue of X.25's
Interrupt packet, while X.25 does not support an unreliable
datagram service such as AHIP's subtype 3 messages. For each
of these cases, the recommendations of BBN Report 5476, "DDN
X.25 Host Interface Specification," have been followed.
その結果、新しいEEは基本的な相互運用性をサポートします。 しかしながら、他、または1つのプロトコルから写像でないのが存在しているのでただサポートされないまで、写像される必要があるいくつかの特別なケースがあります。 例えば、AHIPには、X.25のInterruptパケットのアナログが全くありません、X.25はAHIPの「副-タイプ」3メッセージとして頼り無いデータグラムサービスにそのようなものをサポートしませんが。 それぞれに関するこれらのケースにおいて、「DDN X.25ホスト・インターフェース仕様」というBBN Report5476の推薦は続かれました。
The interoperable service provided by the new EE is called DDN
Standard Service, Version 2. Standard Service, Version 1, is
defined in BBN Reports 5760, "Preliminary Interoperable
Software Design," and 5900 Revision 1, "Supplement to BBN
Report Nos. 5476 and 5760".
新しいEEによって提供された共同利用できるサービスはDDN Standard Service、バージョン2と呼ばれます。 標準のService(バージョン1)は5760(「予備の共同利用できるソフトウェアデザイン」、および5900Revision1)が「BBNレポートNo.5476と5760に補う」BBN Reportsで定義されます。
The major differences between Versions 1 and 2 are:
バージョン1と2の主要な違いは以下の通りです。
o Version 2 offers improved performance over Version 1.
o バージョン2申し出はバージョン1の上の性能を向上させました。
o The EE now provides four precedence levels. Therefore,
the four precedence levels allowed in the DDN-private
Call Precedence Negotiation are mapped directly to subnet
precedence levels, instead of being collapsed into two
subnet precedence levels as in Version 1.
o EEは現在、4つの先行レベルを提供します。 したがって、DDN個人的なCall Precedence Negotiationに許容された4つの先行レベルが直接サブネット先行レベルに写像されます、バージョン1のように2つのサブネット先行レベルまで潰されることの代わりに。
o On an interoperable connection, the X.25 protocol ID in
an X.25-originated message is translated to an AHIP link
number (the upper eight bits of the message-ID field)
using a lookup table. Version 1 supports only the IP
protocol ID and corresponding link number of 155
(decimal). Version 2 allows new values to be added to
the lookup table. At present, IP is the only protocol
supported. In addition, the AHIP link number is also
used to distinguish one connection from another. This
o 共同利用できる接続のときに、X.25によって溯源されたメッセージのX.25プロトコルIDは、ルックアップ表を使用することでAHIPリンク番号(メッセージID分野の上側の8ビット)に翻訳されます。 バージョン1は、唯一のIPプロトコルがIDと対応するリンク番号の155(10進)であるとサポートします。 バージョン2で、新しい値はルックアップ表に加えます。 現在のところ、IPはサポートされた唯一のプロトコルです。 また、さらに、AHIPリンク番号は、別のものと1つの接続を区別するのに使用されます。 これ
Malis [Page 9]
Malis[9ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
guarantees that when an AHIP host is sending messages to
an X.25 host, messages using different link numbers come
into the X.25 host on different X.25 connections.
AHIPホストが異なったX.25接続のときにX.25ホストにメッセージを送るとき、異なったリンク番号を使用するメッセージがX.25ホストに入るという保証。
o Since a "translation module" is no longer necessary in
the PSN, interoperable connections now have end-to-end
significance, with a direct correspondence between X.25
RRs and AHIP RFNMs. This preserves the meaning of the
RFNM as defined in Report 1822. Although Release 7.0
only offers end-to-end significance, the D bit is passed
transparently on Standard Service connections between two
X.25 hosts.
o 「翻訳モジュール」はもうPSNで必要でないので、現在、共同利用できる接続にはX.25 RRsとAHIP RFNMsとのダイレクト通信がある終わりから終わりへの意味があります。これはReport1822で定義されるようにRFNMの意味を保存します。 Release7.0は終わりから終わりへの意味を提供するだけですが、Dビットは2人のX.25ホストの間の透過的に進んだStandard Service接続です。
o Up to 256 simultaneous connections are supported between
host pairs that are using the same addresses and
precedence levels. Version 1 only supported one such
connection.
o 最大256の同時接続が同じアドレスと先行レベルを使用しているホスト組の間でサポートされます。 バージョン1はそのような接続のひとりしかサポートしませんでした。
The following Version 1 services are not offered by Version 2:
以下のバージョン1サービスはバージョン2によって提供されません:
o Permanent Virtual Circuits.
o 相手固定接続。
o X.25 protocol bypass (a BBN-private service).
o X.25は迂回(BBN-密葬)について議定書の中で述べます。
A number of items in Report 5760 were the subject of some
discussion, and three of them need to be specifically mentioned
here. First, for DDN Standard Service, Version 1,
acknowledgments have local significance only, and the D bit
must be set to 0 in the call request. In DDN Standard Service,
Version 2, only end-to-end significance is being provided, as
was mentioned above. For backwards compatibility with Version
1, the D bit can be set to 0 or 1 in a call, but hosts are
advised that only end-to-end significance is provided in
Version 2.
Report5760の多くの項目が何らかの議論の対象でした、そして、それら3人は明確にここに言及される必要があります。 まず最初に、承認には、DDN Standard Service、バージョン1のために、ローカルの意味しかありません、そして、発呼要求における0にDビットを設定しなければなりません。 DDN Standard Service、バージョン2に、上に言及されたように終わりから終わりへの意味だけを提供しています。 バージョン1との遅れている互換性において、呼び出しで0か1にDビットを設定できますが、ホストは終わりから終わりへの意味だけがバージョン2に提供されると忠告されます。
Second, non-standard Default Precedence is not supported by
either Standard Service Version 1 or Version 2. Support for
this facility in Version 1 was withdrawn at the request of DCA.
2番目に、標準的でないDefault PrecedenceはStandard Serviceバージョン1かバージョン2のどちらかによってサポートされません。 バージョン1のこの能力のサポートはDCAの依頼で引き下がりました。
Third, although DTEs are allowed to request maximum packet
sizes of 16, 32, and 64 octets, the DCE always negotiates up to
128 octets, as per Section 6.12 ("Flow Control Parameter
Negotiation") of the CCITT 1984 X.25 Recommendation. This is
true of both Version 1 and Version 2. Since IP and TCP are
required when Standard Service is in use, this is a reasonable
restriction (due to the length of IP and TCP headers).
3番目、DTEsは16、32の最大のパケットサイズ、および64の八重奏を要求できますが、DCEはいつも最大128の八重奏を交渉します、CCITT1984X.25 Recommendationのセクション6.12(「フロー制御パラメタ交渉」)に従って。 これはバージョン1とバージョン2の両方に関して本当です。 Standard Serviceが使用中であるときに、IPとTCPが必要であるので、これは合理的な制限(IPとTCPヘッダーの長さによる)です。
Malis [Page 10]
Malis[10ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
One issue must be raised concerning interoperability between
X.25 and packet-mode HDH hosts. In order to efficiently
interoperate, packet-mode HDH hosts should completely fill
their middle packet frames with 128 octets of data.
Packet-mode HDH hosts that send or require receiving middle
packet frames with less than 128 octets of data can still
interoperate with X.25 hosts, but at a greater expense of PSN
CPU resources per message.
X.25とパケット形態HDHホストの間の相互運用性に関して1冊を提起しなければなりません。 効率的に共同利用するために、パケット形態HDHホストはデータの128の八重奏で彼らの中央パケットフレームを完全に満たすべきです。 発信するか、またはデータの128未満の八重奏で中央パケットフレームを受けるのを必要とするパケット形態HDHホストはX.25ホストが、1メッセージあたりのPSN CPUリソースの、より大きい費用においてまだ共同利用できます。
3.2 Addressing
3.2 アドレシング
The old EE supports, for both AHIP and X.25 hosts, two forms of
host addressing, physical and logical.
古いEEはAHIPとX.25ホストの両方のために扱って、物理的であって、論理的に2つのフォームのホストをサポートします。
Physical addressing consists of identifying a host port by the
combination of its PSN number and the port number on that PSN.
Logical addressing allows an arbitrary 16-bit "name" to refer to a
list of one or more host ports. The EE tries to open a connection
to one of the ports in the list according to the criterion chosen
for that name: first reachable in the ordered list, closest port
(in terms of routing delay), or round-robin load sharing.
物理的なアドレシングはそのPSNでPSN番号とポートナンバーの組み合わせでホストポートを特定するのから成ります。 論理的なアドレシングで、任意の16ビットの「名前」は1つ以上のホストポートのリストを示すことができます。 その名前に選ばれた評価基準に従って、EEはリストのポートの1つに接続を開こうとします: 最初に、規則正しいリスト、最も近いポート(ルーティング遅れに関する)、または連続負荷分割法で届きます。
For the new EE, logical addressing is supported on an explicit
per-connection basis: all logical-to-physical address translations
take place in the source PSN when a connection is established.
Once this translation has occurred, all data messages on the
connection are sent to the same physical address.
新しいEEに関しては、論理的なアドレシングは1接続あたり1個の明白ベースでサポートされます: 接続が確立されるとき、物理アドレスに論理的なすべての翻訳がソースPSNで行われます。 この翻訳がいったん現れると、接続に関するすべてのデータメッセージを同じ物理アドレスに送ります。
In addition, hunt groups are also now supported for both X.25 and
AHIP hosts. This new capability allows host ports on a
destination PSN to be combined into a "hunt group". The ports
share the same group identifier, and incoming connections are
evenly spread over the ports in the group. This differs from
logical addressing's load sharing, where all name translations
take place in the source PSN, the different ports can be on any
number of PSNs, and the load sharing is on a per-source-PSN basis.
By contrast, all of the host ports in a hunt group are on the same
PSN, the group-to-port resolution takes place in the destination
PSN, and the load sharing of incoming connections can be
guaranteed over the ports by the destination PSN. For X.25, hunt
groups comply with Section 6.24 of the 1984 X.25 Recommendation.
Note that Called Line Address Modification is not supported.
また、さらに、狩りグループは現在、X.25とAHIPホストの両方のために支持されます。 この新しい能力で、目的地PSNの上のホストポートは「狩りグループ」に結合します。 ポートは同じグループ識別子を共有します、そして、接続要求は均等にグループのポートの上に広げられます。 これは論理的なアドレシングの負荷分割法と異なっていて、異なったポートによる基礎がaにいろいろなPSNs、および負荷分割法に、ソースPSN単位であるということであることができます。(そこでは、すべての名前翻訳がソースPSNで行われます)。 対照的に、狩りグループのホストポートのすべてが同じPSNにあります、そして、グループからポートへの解決は目的地PSNで行われます、そして、目的地PSNはポートの上で接続要求の負荷分割法を保証できます。 X.25に関しては、狩りグループは1984X.25 Recommendationのセクション6.24に従います。 Called線Address Modificationが支持されないことに注意してください。
Malis [Page 11]
Malis[11ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
3.3 Protocol Functionality
3.3 プロトコルの機能性
The EE peer protocol runs between EE modules in PSNs on either end
of an EE connection. This protocol and its mechanisms have to
perform the following functions:
EE同輩プロトコルはEE接続のどちらかの終わりのPSNsのEEモジュールの間を走ります。 このプロトコルとそのメカニズムは以下の機能を実行しなければなりません:
o Provide full duplex connections (the old EE provides simplex
connections, and any two-way traffic, such as that generated
by TCP, requires two subnet connections).
o 全二重接続を提供してください(古いEEはシンプレクス接続を提供します、そして、TCPによって発生したそれなどのどんな両面交通も2つのサブネット接続を必要とします)。
o Open a connection and optionally send a full message's worth
of data as a part of the open request (the old EE requires a
separate opening sequence in each direction before data can
flow).
o 接続を開いてください、そして、開いている要求の一部として任意に完全なメッセージのデータの価値を送ってください(データが流れることができる前に古いEEは別々の初めのシーケンスを各方向に必要とします)。
o Reliably send connection-oriented messages, properly
fragmented/reassembled and sequenced.
o 適切に断片化されるか、または組み立て直されて、配列された接続指向のメッセージを確かに送ってください。
o Close (clear) a connection (normally, or in a "clean-up"
mode after a host or PSN dies).
o 接続を終えてください、(クリアします)(通常、ホストかPSNの後の「クリーンアップ」モードで死ぬ、)
o Reset a connection (like the X.25 reset procedure).
o 接続(X.25リセット手順のような)をリセットしてください。
o Be able to send a limited amount of out-of-band traffic
associated with a connection (like the X.25 interrupt).
o バンドの外の接続(X.25中断のような)に関連している交通を数量限定に送ることができてください。
o Use source buffering with message retransmission (after a
timeout) to insure delivery (the old EE depends on
destination buffer preallocation, which adds protocol
overhead and cannot recover from lost packets in the
subnet).
o メッセージの再送(タイムアウトの後の)があるソースバッファリングを使用します(古いEEは目的地バッファ前配分によって、無くなっているパケットからサブネットで回復できません)。配送を保障してください、そして、前配分はプロトコルオーバーヘッドを加えます。
o Use an internal connection window of up to 127 messages.
o 最大127のメッセージの内部の接続ウィンドウを使用してください。
o Support two types of ACKs, Internal ACKs (IACKs) and
External ACKs (EACKs), which are further described following
this list
o このリストに従って、ACKs、Internal ACKs(IACKs)、およびExternal ACKs(EACKs)の2つのタイプを支持してください。(External ACKsはさらに説明されます)。
o Have an inactivity timer for each connection. For AHIP and
Standard X.25, the connection is closed if the timer fires.
For Basic X.25, the EE uses an internal Hello/I-Heard-You
sequence with the PSN on the other end of the connection to
check if the other end's host or PSN is still alive. If
not, then the connection is closed.
o 各接続のための不活発タイマを持ってください。 AHIPとStandard X.25に関しては、タイマが撃たれるなら、接続は閉じられます。 Basic X.25に関しては、EEは、もう一方の端のホストかPSNがまだ生きているかどうかチェックするのに接続のもう一方の端のPSNと共に私があなたの声を内部のHello/聞いている系列を使用します。 そうでなければ、そして、接続は閉じられます。
o Be able to gracefully handle resource shortages and avoid
reassembly lockup problems.
o 優雅にリソース不足を扱って、再アセンブリ留置所問題を避けることができてください。
Malis [Page 12]
Malis[12ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
As mentioned above, the protocol supports two types of
acknowledgments, IACKs and EACKs. Both types of ACKs apply to
messages only; individual packets are not acknowledged. Since
windowing is being used, an individual ACK can be used to
acknowledge more than one message.
以上のように、プロトコルは2つのタイプの承認、IACKs、およびEACKsを支持します。 ACKsの両方のタイプはメッセージだけに当てはまります。 個々のパケットは承認されません。 ウインドーが使用されているので、1つ以上のメッセージを承認するのに個々のACKを使用できます。
IACKs are used to cancel the retransmission timer and free source
buffering, and are sent when a message has been completely
reassembled and delivered from the EE to either the AHIP or X.25
level 3 module. This allows the EE to avoid unnecessary message
retransmissions, and speeds up the process of freeing source
buffering when destination hosts are slow to accept messages or,
in the case of X.25, slow to advance the PSN's window to the
destination (X.25 does not specify any time limit for a host to
acknowledge that it received a message).
IACKsを再送信タイマーと自由なソースバッファリングを取り消すのに使用して、メッセージを完全に組み立て直したとき、送って、EEからAHIPかX.25レベル3モジュールまで届けます。 これで、EEは、あて先ホストはメッセージを受け入れるのが遅いときに、ソースバッファリングを解放する過程として不要なメッセージ「再-トランスミッション」、および速度を避けるか、またはPSNの窓を目的地に進めるためにX.25の場合で遅くなります(ホストが、メッセージを受け取ったと認めるように、X.25はどんなタイムリミットも指定しません)。
EACKs are used to advance the end-to-end window and to cause one
or more end-to-end X.25 RRs or AHIP RFNMs to be sent to the source
host. An EACK is sent when an X.25 host acknowledges a message or
when an AHIP host actually receives it.
EACKsは、1終わりから終わりへのX.25 RRsかAHIP RFNMsが送信元ホストに送られることを終わりから妻窓を進めて、引き起こすのに使用されます。 X.25ホストがメッセージを承認するか、またはAHIPホストが実際にそれを受けるとき、EACKを送ります。
Both types of ACKs are piggybacked, if possible, on reverse
traffic to the source PSN (for any connection). Whenever a packet
is sent to another PSN, it is filled to the maximum allowed
subnetwork packet size with any outstanding ACKs that may be
waiting to be sent to that PSN. After a configurable period, all
outstanding ACKs for the same PSN are aggregated together and
sent. In addition, succeeding ACKs for the same connection can be
combined into one, and EACKs can be used to imply that a message
is being IACKed as well (if the destination host is speedy enough
when receiving or acknowledging messages to allow IACKs and EACKs
to be combined).
できれば、ACKsの両方のタイプはソースPSN(どんな接続のためのも)への逆の交通のときに背負われます。 別のPSNにパケットを送るときはいつも、それはサブネットワークパケットサイズが許容された最大にそのPSNに送られるのを待っているかもしれないどんな傑出しているACKsでもいっぱいにされます。 構成可能な期間の後に、同じPSNのためのすべての傑出しているACKsを一緒に集めて、送ります。 さらに、同じ接続のための続くACKsを1つに結合できます、そして、メッセージがまた、IACKedであることを含意するのにEACKsを使用できます(IACKsとEACKsが結合されるのを許容するメッセージを受け取るか、または承認するとき、あて先ホストが十分迅速であるなら)。
This ACK aggregation timer interacts with the source buffering
retransmission timer in the following manner: whenever a message
is sent from a host on one PSN to a host on a second PSN, an IACK
is sent back to the first PSN when the message has been completely
reassembled by the destination EE, and an EACK is sent when it has
been delivered (and perhaps ACKed) by the destination host. The
IACK must make it back to the source PSN within the limits of the
retransmission timer, or unnecessary retransmissions could be sent
across the network. This limits the ACK aggregation timer to
being shorter than the source buffering retransmission timer.
このACK集合タイマは以下の方法で再送信タイマーをバッファリングするソースと対話します: 目的地EEがメッセージを完全に組み立て直したとき、第2のPSNで1PSNの上のホストからホストにメッセージを送るときはいつも、最初のPSNをIACKに送り返します、そして、あて先ホストがそれを届けたとき(そして、恐らくACKed)、EACKを送ります。 IACKが再送信タイマーの限界の中でそれをソースPSNまで作らなければならない、さもなければ、ネットワークの向こう側に不要な「再-トランスミッション」を送ることができました。 これはACK集合タイマを再送信タイマーをバッファリングするソースより短い存在に制限します。
If the destination host is quick enough when accepting traffic
from its PSN (with respect to the ACK aggregation timer), then the
EACK can be combined with the IACK, and only the EACK would be
PSN(ACK集合タイマに関する)からの交通を受け入れるとき、あて先ホストが十分迅速であるなら、EACKをIACKに結合できます、そして、唯一のEACKは結合されるでしょう。
Malis [Page 13]
Malis[13ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
sent. If the destination host is even quicker, multiple IACKs and
EACKs could be combined into one EACK. In the best case, if there
is a steady stream of traffic going between the two PSNs in both
directions (but not necessarily over the same connection or even
between the same pairs of hosts in each direction), then all of
the IACKs and EACKs could be piggybacked on data packets and cause
no additional network packets other than the data packets already
required to send the data messages across the network. In the
worst case, however, such as when there is only a one-way flow
from a source PSN to a destination PSN and the destination host is
very slow to accept the messages from the network, then each data
message could result in separate IACKs and EACKs being sent back
to the source PSN in individual packets. However, even though the
IACKs may cause additional packets to cross the network, they are
still less expensive than the source retransmissions that they are
used to prevent, and they also serve to free up valuable source
buffering space.
送る。 あて先ホストがさらに迅速であるなら、複数のIACKsとEACKsは1EACKに結合されるかもしれません。 最も良い場合では、両方の方向(しかし、必ず同じ接続か各方向へのホストのどんな同じ組の間でさえもそうしない)に2PSNsを取り持つ交通の一定の流れがあれば、IACKsとEACKsのすべてがデータ・パケット以外のどんな追加ネットワークパケットもネットワークの向こう側にデータメッセージを送るのを既に必要としなかったデータ・パケットと原因で背負われるかもしれません。 あて先ホストはネットワークからメッセージを受け入れるのが非常に遅い、しかしながら、最悪では、片道ソースPSNから目的地までの流れしかない時のように、PSNをケースに入れてください。そうすれば、次に、それぞれのデータメッセージは個々のパケットでソースPSNに送り返される別々のIACKsとEACKsをもたらすかもしれません。 しかしながら、IACKsは追加パケットにネットワークを越えさせるかもしれませんが、それらは防ぐのに使用されるソース「再-トランスミッション」よりなお高価ではありません、そして、また、スペースをバッファリングする貴重なソースを開けるのに役立ちます。
3.4 Performance and Capacity Goals
3.4 パフォーマンスと容量目標
Performance and capacity goals for the new EE include:
新しいEEのパフォーマンスと容量目標は:
o Throughput: The AHIP host-host and host-trunk maximum
throughput (in packets/second) will be at least as good as
at present, and should improve for those situations that
currently entail traffic limitations based upon the old EE's
underlying protocol. The current X.25 intrasite host-host
and host-trunk throughput will each improve by at least 50%.
The store-and-forward throughput for the new EE's X.25-based
traffic will improve by at least 100%.
o スループット: AHIPホスト兼ホストとホスト胴体の最大のスループット(パケット/秒の)は、プレゼントと少なくとも同じくらい良く、現在古いEEの基本的なプロトコルに基づく交通制限を伴うそれらの状況のために向上するべきです。 現在のX.25 intrasiteホスト兼ホストとホスト胴体スループットはそれぞれ少なくとも50%向上するでしょう。 新しいEEのX.25ベースの交通のための店とフォワードスループットは少なくとも100%向上するでしょう。
o Connections: The new EE will support at least 500
simultaneous connections per PSN, and will be able to handle
at least 50% more call setups per second than at present.
o コネクションズ: 新しいEEは1PSNあたり少なくとも500の同時接続を支持して、プレゼントより少なくとも50%多くの1秒あたりの呼び出しセットアップを扱うことができるでしょう。
o Buffering: The EE will have at least 400 packet buffers
available to source-buffer and/or reassemble messages.
o バッファリングします: EEはソースバッファに利用可能な少なくとも400のパケットバッファを持っている、そして/または、メッセージを組み立て直すでしょう。
o Network size: The EE protocol and module will use data
structure and message field sizes sufficient to support at
least up to 255 hosts per PSN and 1023 PSNs per network
(however, other PSN protocols and modules presently
constrain these figures to 63 hosts per PSN and 253 PSNs per
network).
o サイズをネットワークでつないでください: EEプロトコルとモジュールはデータ構造と1PSNあたり最大少なくとも255人のホストと1ネットワークあたり1023PSNsを支持できるくらいのメッセージ分野サイズを使用するでしょう(しかしながら、他のPSNプロトコルとモジュールは現在、1PSNあたり63人のホストと1ネットワークあたり253PSNsにこれらの数字を抑制します)。
o Other: The EE will support four message precedence levels
o 他: EEは4つのメッセージ先行レベルを支持するでしょう。
Malis [Page 14]
Malis[14ページ]
RFC 979 March 1986 PSN End-to-End Functional Specification
RFC979 1986年3月のPSN終わりから終わりへの機能的な仕様
and a maximum message length of 1024 bytes. For logical
addressing, the EE will support at least 1024 logical names
and at least 2048 address mappings per network.
そして、最大1024バイトのメッセージ長。 論理的なアドレシングのために、EEは1ネットワークあたり少なくとも1024の論理的な名前と少なくとも2048のアドレス・マッピングをサポートするでしょう。
Malis [Page 15]
Malis[15ページ]
一覧
スポンサーリンク
