RFC907 日本語訳
0907 Host Access Protocol specification. Bolt Beranek and NewmanLaboratories. July 1984. (Format: TXT=129985 bytes) (Updated by RFC1221) (Also STD0040) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC 907
RFC907
HOST ACCESS PROTOCOL SPECIFICATION
ホストアクセスプロトコル仕様
July 1984
1984年7月
prepared for
用意をします。
Defense Advanced Research Projects Agency
1400 Wilson Boulevard
Arlington, Virginia 22209
国防高等研究計画庁1400ウィルソン・Boulevardアーリントン、ヴァージニア 22209
by
by
Bolt Beranek and Newman Laboratories
10 Moulton Street
Cambridge, Massachusetts 02238
ボルトBeranekとニューマン研究所10モールトン・通りケンブリッジ、マサチューセッツ 02238
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Preface (Status of this Memo)
序文(このMemoの状態)
This document specifies the Host Access Protocol (HAP).
Although HAP was originally designed as the network-access level
protocol for the DARPA/DCA sponsored Wideband Packet Satellite
Network, it is intended that it evolve into a standard interface
between hosts and packet-switched satellite networks such as
SATNET and TACNET (aka MATNET) as well as the Wideband Network.
The HAP specification presented here is a minor revision of, and
supercedes, the specification presented in Chapter 4 of BBN
Report No. 4469, the "PSAT Technical Report". As such, the
details of the current specification are still most closely
matched to the characteristics if the Wideband Satellite Network.
Revisions to the specification in the "PSAT Technical Report"
include the definition of three new control message types
(Loopback Request, Link Going Down, and NOP), a "Reason" field in
Restart Request control messages, new Unnumbered Response codes,
and new values for the setup codes used to manage streams and
groups.
このドキュメントはHost Accessプロトコル(HAP)を指定します。 DARPA/DCAのためのネットワークアクセスの平らなプロトコルがWideband Packet Satellite Networkを後援したとき、HAPは元々設計されましたが、それがWideband Networkと同様にSATNETやTACNET(通称MATNET)などのホストとパケットで切り換えられた衛星ネットワークの間の標準インターフェースに発展することを意図します。 ここに提示されたHAP仕様が小さい方の改正である、supercedes、BBN Report No.4469の第4章に提示された仕様、「PSAT技術報告書」 そういうものとして、現在の仕様の細目はWideband Satellite Networkであるならまだ最も密接に特性に合わせられています。 「PSAT技術報告書」の仕様への改正はストリームとグループを経営するのに使用されるセットアップコードのための3つの新しいコントロールメッセージタイプ(ループバックRequest、Link Going Down、およびNOP)、Restart Requestコントロールメッセージの「理由」分野、新しいUnnumbered Responseコード、および新しい値の定義を含んでいます。
HAP is an experimental protocol, and will undergo further
revision as new capabilities are added and/or different satellite
networks are supported. Implementations of HAP should be
performed in coordination with satellite network development and
operations personnel.
HAPは実験プロトコルであり、新しい能力が加えられるとき、さらなる改正を受けるでしょう、そして、異なった衛星ネットワークはサポートされます。 HAPの実装は衛星ネットワーク開発と業務職員と共にコーディネートで実行されるべきです。
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Table of Contents
目次
1 Introduction.......................................... 1
2 Overview.............................................. 3
3 Datagram Messages..................................... 8
4 Stream Messages...................................... 14
5 Flow Control Messages................................ 17
6 Setup Level Messages................................. 24
6.1 Stream Setup Messages.............................. 32
6.2 Group Setup Messages............................... 44
7 Link Monitoring...................................... 58
8 Initialization....................................... 62
9 Loopback Control..................................... 68
10 Other Control Messages.............................. 72
1つの序論… 1 2概要… 3 3のデータグラムメッセージ… 8 4はメッセージを流します… 14 5 フロー制御メッセージ… 17 6 平らなメッセージをセットアップしてください… 24 6.1 セットアップメッセージを流してください… 32 6.2 セットアップメッセージを分類してください… 44 7 モニターをリンクしてください… 58 8初期設定… 62 9 ループバックコントロール… 他の68 10のコントロールメッセージ… 72
i
i
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
FIGURES
図
DATAGRAM MESSAGE.......................................... 9
STREAM MESSAGE........................................... 15
ACCEPTANCE/REFUSAL WORD.................................. 19
ACCEPTANCE/REFUSAL MESSAGE............................... 21
UNNUMBERED RESPONSE...................................... 22
SETUP MESSAGE HEADER..................................... 26
NOTIFICATION MESSAGE..................................... 29
SETUP ACKNOWLEDGMENT..................................... 31
STREAM EXAMPLE........................................... 33
CREATE STREAM REQUEST.................................... 35
CREATE STREAM REPLY...................................... 37
CHANGE STREAM PARAMETERS REQUEST......................... 39
CHANGE STREAM PARAMETERS REPLY........................... 41
DELETE STREAM REQUEST.................................... 42
DELETE STREAM REPLY...................................... 43
GROUP EXAMPLE............................................ 45
CREATE GROUP REQUEST..................................... 47
CREATE GROUP REPLY....................................... 48
JOIN GROUP REQUEST....................................... 50
JOIN GROUP REPLY......................................... 52
LEAVE GROUP REQUEST...................................... 53
LEAVE GROUP REPLY........................................ 55
DELETE GROUP REQUEST..................................... 56
DELETE GROUP REPLY....................................... 57
STATUS MESSAGE........................................... 59
HAP LINK RESTART STATE DIAGRAM........................... 64
RESTART REQUEST.......................................... 65
RESTART COMPLETE......................................... 67
LOOPBACK REQUEST......................................... 71
LINK GOING DOWN.......................................... 73
NO OPERATION (NOP)....................................... 75
データグラムメッセージ… 9 メッセージを流してください… 15 承認/拒否Word… 19承認/拒否メッセージ… 21 無数の応答… 22 メッセージヘッダーをセットアップしてください… 26通知メッセージ… 29 承認をセットアップしてください… 31 例を流してください… 33 ストリーム要求を作成してください… 35 ストリーム回答を作成してください… 37 パラメタが要求するストリームを変えてください… 39 変化ストリームパラメタは返答します… 41 ストリーム要求を削除してください… 42 ストリーム回答を削除してください… 43 例を分類してください… 45 グループ要求を作成してください… 47 グループ回答を作成してください… 48 グループ要求に参加してください… 50 グループ回答に参加してください… 52 グループ要求を残してください… 53 グループ回答を残してください… 55 グループ要求を削除してください… 56 グループ回答を削除してください… 57ステータスメッセージ… 59機会リンク再開州のダイヤグラム… 64 要求を再開してください… 65 完全な状態で、再開してください… 67ループバック要求… 71 落ちて、リンクしてください… 73 操作がありません(NOP)… 75
ii
ii
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
1 Introduction
1つの序論
The Host Access Protocol (HAP) specifies the network-access
level communication between an arbitrary computer, called a host,
and a packet-switched satellite network. The satellite network
provides message delivery services for geographically separated
hosts: Messages containing data which are meaningful to the hosts
are submitted to the network by an originating (source) host, and
are passed transparently through the network to an indicated
destination host. To utilize such services, a host interfaces to
the satellite network via an access link to a dedicated packet-
switching computer, known as a Satellite Interface Message
Processor (Satellite IMP or SIMP). HAP defines the different
types of control messages and (host-to-host) data messages that
may be exchanged over the access link connecting a host and a
SIMP. The protocol establishes formats for these messages, and
describes procedures for determining when each type of message
should be transmitted and what it means when one is received.
Host Accessプロトコル(HAP)はホストと呼ばれる、任意のコンピュータと、パケットで切り換えられた衛星ネットワークとのネットワークアクセスの平らなコミュニケーションを指定します。 衛星ネットワークは地理的に切り離されたホストのためのメッセージデリバリ・サービスを提供します: ホストにとって、重要なデータを含むメッセージが、起因している(ソース)ホストによってネットワークに提出されて、透過的に示されたあて先ホストへのネットワークに通り抜けます。 そのようなサービスを利用するために、ホストはSatellite Interface Message Processor(衛星IMPかSIMP)として知られている専用パケット切り換えコンピュータへのアクセスリンクを通して衛星ネットワークに連結します。 HAPはホストとSIMPに接しながらアクセスリンクの上と交換されるかもしれない異なったタイプに関するコントロールメッセージと(ホストからホスト)データメッセージを定義します。 プロトコルは、これらのメッセージのために形式を確立して、それぞれのタイプに関するメッセージがいつ送られるべきであるか、そして、1つが受け取られているときそれが何を意味するかを決定するために手順について説明します。
The term "Interface Message Processor" originates in the
ARPANET, where it refers to the ARPANET's packet-switching nodes.
SIMPs differ from ARPANET IMPs in that SIMPs form a network via
connections to a common multiaccess/broadcast satellite channel,
whereas ARPANET IMPs are interconnected by dedicated point-to-
point terrestrial communications lines. This fundamental
difference between satellite-based and ARPANET-style networks
results in different mechanisms for the delivery of messages from
source to destination hosts and for internal network
coordination. Additionally, satellite networks tend to offer
different type of service options to their connected hosts than
do ARPANET-style networks. These options are included in the
Host Access Protocol presented here.
アルパネットのパケット交換ノードを参照するところに「インタフェース・メッセージ・プロセッサ」という用語はアルパネットで起こります。 SIMPsはSIMPsが一般的な多重処理/放送衛星チャンネルとの接続でネットワークを形成するという点においてアルパネットIMPsと異なっていますが、アルパネットIMPsは専用ポイントからポイントへのコミュニケーション地球の線によってインタコネクトされます。 衛星ベースのこの基本的な違いとアルパネットスタイルはメッセージのソースからあて先ホストまでの配送と内部のネットワークコーディネートのために異なったメカニズムの結果をネットワークでつなぎます。 さらに、衛星ネットワークは、アルパネットスタイルネットワークより彼らの接続ホストへの異なったタイプのサービスオプションを提供する傾向があります。 これらのオプションはここに提示されたHost Accessプロトコルに含まれています。
Several types of Satellite IMPs have been developed on a
variety of processors for the support of three different packet-
switched satellite networks. The original SIMP was employed in
the Atlantic Packet Satellite Network (SATNET). It was developed
from one of the models of ARPANET IMP, and was implemented on a
Honeywell 316 minicomputer. The 316 SIMPs were succeeded in
SATNET by SIMPs based on BBN C/30 Communications Processor
hardware. The C/30 SIMPs have also been employed in the Mobile
Satellite IMPsのいくつかのタイプが3つの異なったパケット切り換えられた衛星ネットワークのサポートのためのさまざまなプロセッサの上に発生しました。 オリジナルのSIMPは大西洋Packet Satellite Network(SATNET)で使われました。 それは、ARPANET IMPのモデルのひとりから開発されて、ハネウェル316ミニコンピュータの上で実装されました。 316SIMPsがSATNETでBBN C/30Communications Processorハードウェアに基づくSIMPsによって引き継がれました。 また、C/30SIMPsがモバイルで使われました。
1
1
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Access Terminal Network (MATNET). The SATNET and MATNET SIMPs
implement a network-access level protocol known as Host/SATNET
Protocol. Host/SATNET Protocol is the precursor to HAP and is
documented in Internet Experiment Note (IEN) No. 192. The
Wideband Satellite Network, like SATNET, has undergone an
evolution in the development of its SIMP hardware and software.
The original Wideband Network SIMP is known as the Pluribus
Satellite IMP, or PSAT, having been implemented on the BBN
Pluribus Multiprocessor. Its successor, the BSAT, is based on
the BBN Butterfly Multiprocessor. Both the PSAT and the BSAT
communicate with their connected network hosts via HAP.
端末のネットワーク(MATNET)にアクセスしてください。 SATNETとMATNET SIMPsはHost/SATNETプロトコルとして知られているネットワークアクセスの平らなプロトコルを実装します。 ホスト/SATNETプロトコルは、HAPへの先駆であり、インターネットExperiment Note(IEN)No.192に記録されます。 SATNETのように、Wideband Satellite NetworkはそのSIMPハードウェアとソフトウェアの開発における発展を受けました。 オリジナルのWideband Network SIMPはPluribus Satellite IMP、またはPSATとして知られています、BBN Pluribus Multiprocessorで実装されて。 後継者(BSAT)はBBN Butterfly Multiprocessorに基づいています。 PSATとBSATの両方がHAPを通して彼らの接続ネットワークホストとコミュニケートします。
Section 2 presents an overview of HAP. Details of HAP
formats and message exchange procedures are contained in Sections
3 through 10. Further explanation of many of the topics
addressed in this HAP specification can be found in BBN Report
No. 4469, the "PSAT Technical Report".
セクション2はHAPの概要を提示します。 HAP形式と交換処理手順の詳細はセクション3〜10に含まれています。 BBN Report No.4469、「PSAT技術報告書」でこのHAP仕様で扱われた話題の多くに関する詳細な説明を見つけることができます。
The protocol used to provide sufficiently reliable message
exchange over the host-SIMP link is assumed to be transparent to
the network-access protocol defined in this document. Examples
of such link-level protocols are ARPANET 1822 local and distant
host, ARPANET VDH protocol, and HDLC.
ホスト-SIMPリンクの上に十分信頼できる交換処理を供給するのにおいて中古のプロトコルが本書では定義されたネットワークアクセス・プロトコルに透明であると思われます。 そのようなリンク・レベルプロトコルに関する例は、アルパネットの1822年の地方の、そして、冷ややかなホストと、ARPANET VDHプロトコルと、HDLCです。
2
2
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
2 Overview
2概要
HAP can be characterized as a full duplex nonreliable
protocol with an optional flow control mechanism. HAP messages
flow simultaneously in both directions between the SIMP and the
host. Transmission is nonreliable in the sense that the protocol
does not provide any guarantee of error-free sequenced delivery.
To the extent that this functionality is required on the access
link (e.g., non-collocated SIMP and host operating over a
communication circuit), it must be supported by the link-level
protocol below HAP. The flow control mechanism operates
independently in each direction except that enabling or disabling
the mechanism applies to both sides of the interface.
全二重「非-信頼でき」プロトコルとして任意のフロー制御メカニズムでHAPを特徴付けることができます。 HAPメッセージは同時に、SIMPとホストの間の両方の方向に流れます。 トランスミッションはプロトコルがエラーのない配列された配送のどんな保証も提供しないという意味で「非-信頼でき」です。 この機能性がアクセスリンク(コミュニケーション回路の上の例えば、非並べたSIMPとホスト操作)の上に必要であるという範囲に、HAPの下でリンク・レベルプロトコルでそれをサポートしなければなりません。 メカニズムを可能にするか、または無効にするのがインタフェースの両側に適用されるのを除いて、フロー制御メカニズムは独自に各方向に動作します。
HAP supports host-to-host communication in two modes
corresponding to the two types of HAP data messages, datagram
messages and stream messages. Each type of message can be up to
approximately 16K bits in length. Datagram messages provide the
basic transmission service in the satellite network. Datagram
messages transmitted by a host experience a nominal two satellite
hop end-to-end network delay. (Note that this delay, of about 0.6
sec excluding access link delay, is associated with datagram
transmission between hosts on different SIMPs. The transmission
delay between hosts on the same SIMP will be much smaller
assuming the destination is not a group address. See Section 3
and 6.2.) A datagram control header, passed to the SIMP by the
host along with message text, determines the processing of the
message within the satellite network independent of any previous
exchanges.
HAPは2つのタイプに関するHAPデータメッセージ、データグラムメッセージ、およびストリームメッセージに対応する2つのモードによるホスト間通信をサポートします。 それぞれのタイプに関するメッセージは長さでおよそ16Kのビットまで達することができます。 データグラムメッセージは基本的なトランスミッションサービスを衛星ネットワークに提供します。 ホストによって送られたデータグラムメッセージは2衛星ホップ終わりから終わりへの名目上のネットワーク遅延になります。 (アクセスリンク遅れを除いたおよそ0.6秒のこの遅れが異なったSIMPsでホストの間のデータグラムトランスミッションに関連していることに注意してください。 目的地がグループアドレスでないと仮定しながら、同じSIMPの上のホストの間のトランスミッション遅れははるかに小さくなるでしょう。 セクション3と6.2を見てください。) メッセージ・テキストに伴うホストによってSIMPに渡されたデータグラムコントロールヘッダーはどんな前の交換の如何にかかわらず衛星ネットワークの中でメッセージの処理を決定します。
Stream messages provide a one satellite hop delay
(approximately 0.3 sec) for volatile traffic, such as speech,
which cannot tolerate the delay associated with datagram
transmission. Hosts may also use streams to support high duty
cycle applications which require guaranteed channel bandwidth.
Host streams are established by a setup message exchange between
the host and the network prior to the commencement of data flow.
Although established host streams can have their characteristics
modified by subsequent setup messages while they are in use, the
fixed allocation properties of streams relative to datagrams
impose rather strict requirements on the source of the traffic
ストリームメッセージは1つの衛星ホップ遅れ(およそ0.3秒)を揮発性のトラフィックに提供します、スピーチなどのように。(それは、データグラムトランスミッションに関連している遅れを許容できません)。 また、ホストは、保証されたチャンネル帯域幅を必要とする高いデューティサイクルアプリケーションをサポートするのにストリームを使用するかもしれません。 ホストストリームはデータフローの始めの前にホストとネットワークの間のセットアップ交換処理で確立されます。 それらが使用中である間その後のセットアップメッセージでそれらの特性を変更できますが、確立したホストストリームでデータグラムに比例したストリームの固定配分の特性はかなり厳しい要件をトラフィックの源に課します。
3
3
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
using the stream. Stream traffic arrivals must match the stream
allocation both in interarrival time and message size if
reasonable efficiency is to be achieved. The characteristics and
use of datagrams and streams are described in detail in Sections
3 and 4 of this document.
ストリームを使用します。 ストリームトラフィック到着は妥当な効率が達成されることであるならinterarrival時間とメッセージサイズにおけるストリーム配分に合わなければなりません。 データグラムとストリームの特性と使用はこのドキュメントのセクション3と4で詳細に説明されます。
Both datagram and stream transmission in the satellite
network use logical addressing. Each host on the network is
assigned a permanent 16-bit logical address which is independent
of the physical port on the SIMP to which it is attached. These
16-bit logical addresses are provided in all Host-to-SIMP and
SIMP-to-Host data messages.
衛星ネットワークにおける、データグラムと流れ転送の両方が論理的なアドレシングを使用します。 ネットワークの各ホストは物理的なポートから独立している16ビットの永久的な論理アドレスをそれが付けているSIMPに割り当てられます。 HostからSIMPとSIMPからホストへのデータすべてのメッセージにこれらの16ビットの論理アドレスを提供します。
Hosts may also be members of groups. Group addressing is
provided primarily to support the multi-destination delivery
required for conferencing applications. Like streams, group
addresses are dynamically created and deleted by the use of setup
messages exchanged between a host and the network. Membership in
a group may consist of an arbitrary subset of all the permanent
network hosts. A message addressed to a group address is
delivered to all hosts that are members of that group.
また、ホストはグループのメンバーであるかもしれません。 主としてマルチの目的地が会議アプリケーションに必要である配送であるとサポートするためにグループ・アドレッシングを提供します。 ストリームのように、グループアドレスは、ホストとネットワークの間で交換されたセットアップメッセージの使用でダイナミックに作成されて、削除されます。 グループにおける会員資格はすべての永久的なネットワークホストの任意の部分集合から成るかもしれません。 グループアドレスに扱われたメッセージはそのグループのメンバーであるすべてのホストに提供されます。
Although HAP does not guarantee error-free delivery, error
control is an important aspect of the protocol design. HAP error
control is concerned with both local transfers between a host and
its local SIMP and transfers from SIMP-to-SIMP over the satellite
channel. The SIMP offers users a choice of network error
protection options based on the network's ability to selectively
send messages over the satellite channel at different coding
rates. These forward error correction (FEC) options are referred
to as reliability levels. Three reliability levels (low, medium,
and high) are available to the host.
HAPはエラーのない配送を保証しませんが、誤り制御はプロトコルデザインの重要な一面です。 HAP誤り制御はホストとその地方のSIMPの間の両方の地方の転送とSIMPからSIMPからの衛星チャンネルの上の転送に関係があります。 SIMPは異なったコード化レートで選択的に衛星チャンネルの上にメッセージを送るネットワークの能力に基づくネットワーク誤り保護オプションの選択をユーザに提供します。 これらの前進型誤信号訂正(FEC)オプションは信頼性レベルと呼ばれます。 ホストにとって、3つの信頼性レベル(低くて、中型の、そして、高い)が利用可能です。
In addition to forward error correction, a number of
checksum mechanisms are employed in the satellite network to add
an error detection capability. A host has an opportunity when
sending a message to indicate whether the message should be
delivered to its destination or discarded if a data error is
detected by the network. Each message received by a host from
the network will have a flag indicating whether or not an error
was detected in that particular message. A host can decide on a
前進型誤信号訂正に加えて、多くのチェックサムメカニズムが、誤り検出能力を加えるのに衛星ネットワークで使われます。 データ誤りがネットワークによって検出されるなら、メッセージが送付先に提供されるべきであるか、または捨てられるべきであるかを示すメッセージを送るとき、ホストは機会があります。 ホストによってネットワークから受け取られた各メッセージで、旗は、誤りがその特定のメッセージに検出されたかどうかを示すでしょう。 ホストはaを決めることができます。
4
4
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
per-message basis whether or not it wants to accept or discard
transmissions containing data errors.
1メッセージあたりの基礎、それは、データ誤りを含むトランスミッションを、受け入れたいですか、捨てるのでありたがっているかどうか
For connection of a host and SIMP in close proximity, error
rates due to external noise or hardware failures on the access
circuit may reasonably be expected to be much smaller than the
best satellite channel error rate. Thus for this case, little is
gained by using error detection and retransmission on the access
circuit. A 16-bit header checksum is provided, however, to
insure that SIMPs do not act on incorrect control information.
For relatively long distances or noisy connections,
retransmissions over the access circuit may be required to
optimize performance for both low and high reliability traffic.
It is expected that link-level error control procedures (such as
HDLC) will be used for this purpose.
近接性におけるホストとSIMPの接続において、外部の雑音による誤り率かアクセス回路の上のハードウェアの故障が最も良い衛星チャンネル誤り率よりはるかに小さいと合理的に予想されるかもしれません。 したがって、このような場合、アクセス回路の上の誤り検出と「再-トランスミッション」を使用することによって、少ししか獲得されません。 しかしながら、SIMPsが不正確な制御情報に影響しないのを保障するために16ビットのヘッダーチェックサムを提供します。 比較的長い距離か騒がしい接続において、アクセス回路の上の「再-トランスミッション」は低いものと同様に高い信頼性のトラフィックのために性能を最適化しなければならないかもしれません。 リンク・レベル誤り制御手順(HDLCなどの)がこのために用いられると予想されます。
Datagram and stream messages being presented to the network
by a host may not be accepted for a number of reasons: priority
too low, destination dead, lack of buffers in the source SIMP,
etc. The host faces a similar situation with respect to handling
messages from the SIMP. To permit the receiver of a message to
inform the sender of the local disposition of its message, an
acceptance/refusal (A/R) mechanism is implemented. The mechanism
is the external manifestation of the SIMP's (or host's) internal
flow and congestion control algorithm. If A/Rs are enabled, an
explicit or implicit acceptance or refusal for each message is
returned to the host by the SIMP (and conversely). This allows
the host (or SIMP) to retry refused messages at its discretion
and can provide information useful for optimizing the sending of
subsequent messages if the reason for refusals is also provided.
The A/R mechanism can be disabled to provide a "pure discard"
interface.
ホストによってネットワークに提示されるデータグラムとストリームメッセージは様々な意味で受け入れられないかもしれません: 低過ぎる優先権目的地死者、ソースSIMPのバッファの不足など ホストはSIMPからの取り扱いメッセージに関して同様の状況に直面しています。 メッセージの地方の気質について送付者に知らせるメッセージの受信機を可能にするために、承認/拒否(/R)メカニズムは実装されます。 メカニズムはSIMP(または、ホストのもの)の内部の流れと輻輳制御アルゴリズムの外的発現です。 A/Rsが有効にされるなら、各メッセージのための明白であるか暗黙の承認か拒否がSIMP(逆に)によってホストに返されます。 これは、ホスト(または、SIMP)が自己判断で拒否されたメッセージを再試行するのを許容して、また、拒否の理由を提供するならその後のメッセージの発信を最適化することの役に立つ情報を前提とすることができます。 A/Rメカニズムは「純粋な破棄」を提供する身体障害者が連結するということであるかもしれません。
Each message submitted to the SIMP by a host is marked as
being in one of four priority classes, from priority 3 (highest)
through priority 0 (lowest). The priority class is used by the
SIMP for arbitrating contention for scarce network resources
(e.g., channel time). That is, if the network cannot deliver all
of the offered messages, high priority messages will be delivered
in preference to low priority messages. In the case of
datagrams, priority level is used by the SIMP for ordering
ホストによってSIMPに提出された各メッセージは4つの優先権のクラスの1つにはあるとしてマークされます、優先権3(最も高い)から優先権0(最も低い)まで。 優先権のクラスは、不十分なネットワーク資源(例えば、チャンネル時間)のための主張を仲裁するのにSIMPによって使用されます。 すなわち、ネットワークが提供されたメッセージのすべてを提供できないと、高い至急メッセージは少ない至急メッセージに優先して提供されるでしょう。 データグラムの場合では、優先順位は、注文するのにSIMPによって使用されます。
5
5
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
satellite channel reservation requests at the source SIMP and
message delivery at the destination SIMP. In the case of
streams, priority is associated with the ability of one stream to
preempt another stream of lower priority at setup time.
目的地SIMPでのソースSIMPとメッセージ配送における衛星チャンネル予約の要請。 ストリームの場合では、優先権は1つのストリームが準備時間に低優先度の別のストリームを先取りする能力に関連しています。
While the A/R mechanism allows control of individual message
transfers, it does not facilitate regulation of priority flows.
Such regulation is handled by passing advisory status information
(GOPRI) across the Host-SIMP interface indicating which
priorities are currently being accepted. As long as this
information, relative to the change in priority status, is passed
frequently, the sender can avoid originating messages which are
sure to be refused.
A/Rメカニズムが個々のメッセージ転送のコントロールを許している間、それは優先権流れの規則を容易にしません。 そのような規則は、現在プライオリティがどれであるかを示すHost-SIMPインタフェースの向こう側の受け入れられる顧問状態情報(GOPRI)を通過することによって、扱われます。 この情報が頻繁に優先権状態の変化に比例して通過される限り、送付者は、確実に拒否されるメッセージを溯源するのを避けることができます。
HAP defines both data messages (datagram messages and stream
messages) and control messages. Data messages are used to send
information between network hosts. Control messages are
exchanged between a host and the network to manage the local
access link. HAP can also be viewed in terms of two distinct
protocol layers, the message layer and the setup layer. The
message layer is associated with the transmission of individual
datagram messages and stream messages. The setup layer protocol
is associated with the establishment, modification, and deletion
of streams and groups. Setup layer exchanges are actually
implemented as datagrams transmitted between the user host and an
internal SIMP "service host."
HAPはデータメッセージ(データグラムメッセージとストリームメッセージ)とコントロールメッセージの両方を定義します。 データメッセージは、ネットワークホストの間に情報を送るのに使用されます。 地方のアクセスリンクを管理するためにホストとネットワークの間でコントロールメッセージを交換します。 また、2個の異なったプロトコル層、メッセージ層、およびセットアップ層でHAPを見ることができます。 メッセージ層は個々のデータグラムメッセージとストリームメッセージの伝達に関連しています。 セットアップ層のプロトコルはストリームとグループの設立、変更、および削除に関連しています。 データグラムがユーザー・ホストと内部のSIMP「サービス・ホスト」の間で送られたようにセットアップ層の交換は実際に実装されます。
Every HAP message consists of an integral number of 16-bit
words. The first several words of the message always contain
control information and are referred to as the message header.
The first word of the message header identifies the type of
message which follows. The second word of the message header is
a checksum which covers all header information. Any message
whose received header checksum does not match the checksum
computed on the received header information must be discarded.
The format of the rest of the header depends on the specific
message type.
あらゆるHAPメッセージが整数の16ビットの単語から成ります。 メッセージのいくつかの最初の言葉が、いつも制御情報を含んでいて、メッセージヘッダーと呼ばれます。 メッセージヘッダーの最初の単語は従うメッセージのタイプを特定します。 メッセージヘッダーの2番目の単語はすべてのヘッダー情報をカバーするチェックサムです。 容認されたヘッダーチェックサムが受信されたヘッダー情報で計算されたチェックサムに合っていないどんなメッセージも捨てなければなりません。 ヘッダーの残りの形式は特定のメッセージタイプに頼っています。
The formats and use of the individual message types are
detailed in the following sections. A common format description
is used for this purpose. Words in a message are numbered
独特のメッセージタイプの形式と使用は以下のセクションで詳細です。 一般的な書式の記述はこのために使用されます。 メッセージのワーズは番号付です。
6
6
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
starting at zero (i.e., zero is the first word of a message
header). Bits within a word are numbered from zero (least
significant) to fifteen (most significant). The notation used to
identify a particular field location is:
ゼロから出発します(すなわち、ゼロはメッセージヘッダーの最初の単語です)。 単語の中のビットはゼロ(最も重要でない)から15(最も重要な)に付番されます。 特定の分野の位置を特定するのに使用される記法は以下の通りです。
<WORD#>{-<WORD#>} [ <BIT#>{-<BIT#>} ] <description>
-<が#>を言い表すという<単語#>、[<が#>に噛み付いた、-<が#>に噛み付いた、]、<記述>。
where optional elements in {} are used to specify the (inclusive)
upper limit of a range. The reader should refer to these field
identifiers for precise field size specifications. Fields which
are common to several message types are defined in the first
section which uses them. Only the name of the field will usually
appear in the descriptions in subsequent sections.
どこ、中の随意的な要素、1つの範囲の(包括的)の上限を指定するために、使用されるか。 読者は正確な分野サイズ仕様のためのこれらの分野識別子を参照するべきです。 いくつかのメッセージタイプに、一般的な分野は彼らを使用する最初のセクションで定義されます。 通常、分野の名前だけがその後のセクションに記述に現れるでしょう。
Link-level protocols used to support HAP can differ in the
order in which they transmit the bits constituting HAP messages.
For HDLC and ARPANET VDH, each word of a HAP message is
transmitted starting with the least significant bit (bit 0) and
ending with the most significant bit (bit 15). The words of the
message are transmitted from word 0 to word N. For ARPANET 1822
local and distant host interfaces, the order of bit transmission
within each word is the reverse of that for HDLC and VDH, i.e.,
the transmission is from bit 15 to bit 0.
HAPをサポートするのに使用されるリンク・レベルプロトコルは彼らがHAPメッセージを構成するビットを伝えるオーダーにおいて異なることができます。 HDLCとARPANET VDHに関しては、最も重要なビット(ビット15)で最下位ビット(ビット0)と結末から始まって、HAPメッセージの各言葉は伝えられます。 メッセージの言葉はWord0から地方の、そして、遠方の単語N.Forアルパネット1822ホスト・インターフェースまで伝えられます、各単語の中のビット伝送の注文がHDLCとVDHのためのその逆である、すなわち、トランスミッションはビット15からビット0に来ています。
7
7
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
3 Datagram Messages
3 データグラムメッセージ
Datagram messages are one of the two types of message level
data messages used to support host-to-host communication. Each
datagram can contain up to 16,384 bits of user data. Datagram
messages transmitted by a host to a host on a remote SIMP
experience a nominal two satellite hop end-to-end network delay
(about 0.6 sec), excluding delay on the access links. This
network delay is due to the reservation per message scheduling
procedure for datagrams which only allocates channel time to the
message for the duration of the actual transfer. Since datagram
transfers between permanent hosts on the same SIMP do not require
satellite channel scheduling prior to data transmission, the
network delay in this case will be much smaller and is determined
strictly by SIMP processing time. Datagrams sent to group
addresses are treated as if they were addressed to remote hosts
and are always sent over the satellite channel. It is expected
that datagram messages will be used to support the majority of
computer-to-computer and terminal-to-computer traffic which is
bursty in nature.
データグラムメッセージはホスト間通信をサポートするのに使用される2つのタイプに関するメッセージレベルデータメッセージの1つです。 各データグラムは最大1万6384ビットの利用者データを含むことができます。 リモートSIMPでホストのホストによって送られたデータグラムメッセージは2衛星ホップ終わりから終わりへの名目上のネットワーク遅延(およそ0.6秒)になります、アクセスリンクの上に遅れを除いて。 このネットワーク遅延は実際の転送の持続時間へのメッセージへの時間をチャンネルに割り当てるだけであるデータグラムのメッセージ・スケジューリング手順あたりの予約のためです。 同じSIMPの上の永久的なホストの間のデータグラム転送がデータ伝送の前に衛星チャンネルスケジューリングを必要としないので、この場合、ネットワーク遅延は、はるかに小さく、SIMP処理時間で厳密に決定しています。 アドレスを分類するために送られたデータグラムはまるでそれらをリモートホストに扱って、いつも衛星チャンネルの上に送るかのように扱われます。 データグラムメッセージがコンピュータからコンピュータと端末からコンピュータへの現実にburstyであるトラフィックの大部分をサポートするのに使用されると予想されます。
The format of datagram messages and the purpose of each of
the header control fields is described in Figure 1.
データグラムメッセージの形式とそれぞれのヘッダー制御フィールドの目的は図1で説明されます。
8
8
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | F| MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 0|IL| D| E| TTL | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 0|lb|GOPRI| XXXX| F| メッセージ番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | /R| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 0|IL| D| E| TTL| PRI| RLY| RLEN| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4 | あて先ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5 | 送信元ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6-N| データ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1 . DATAGRAM MESSAGE
図1 データグラムメッセージ
0[15] Message Class. This bit identifies the message as a
data message or a control message.
0[15]メッセージのクラス。 このビットは、メッセージがデータメッセージかコントロールメッセージであると認識します。
0 = Data Message
1 = Control Message
0 =データメッセージ1=コントロールメッセージ
0[14] Loopback Bit. This bit allows the sender of a message
to determine if its own messages are being looped back.
The host and the SIMP each use different settings of
this bit for their transmissions. If a message arrives
with the loopback bit set equal to its outgoing value,
then the message has been looped.
0[14]ループバックビット。 このビットはそれ自身のメッセージが輪にし返されているかどうか決定するメッセージの送付者を許容します。 ホストとSIMPは彼らのトランスミッションにそれぞれこのビットの異なった設定を使用します。 メッセージが外向的な値と等しいループバック噛み付いているセットと共に到着するなら、メッセージは輪にされました。
0 = Sent by Host
1 = Sent by SIMP
0 SIMPによって送られたホスト1=によって送られた=
9
9
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
0[12-13] Go-Priority. In SIMP-to-Host messages, this field
provides advisory information concerning the lowest
priority currently being accepted by the SIMP. The
host may optionally choose to provide similar priority
information to the SIMP.
0[12-13]碁優先権。 SIMPからホストへのメッセージに、この分野は現在SIMPによって受け入れられる中で最も低い優先度に関して顧問情報を提供します。 ホストは、同様の優先権情報をSIMPに供給するのを任意に選ぶかもしれません。
0 = Low Priority
1 = Medium-Low Priority
2 = Medium-High Priority
3 = High Priority
0 = 媒体高い媒体低い低い優先度1=優先度2=優先度3は高い優先度と等しいです。
0[9-11] Reserved.
0 [9-11テロ] 予約されています。
0[8] Force Channel Transmission Flag. This flag can be set
by the source host to force the SIMP to transmit the
message over the satellite channel even if the message
contains permanent destination and source host
addresses corresponding to hosts which are physically
connected to the same SIMP.
0[8]力のチャンネルトランスミッション旗。 メッセージがホストにとって、対応する永久的な目的地とソースホスト・アドレスを含んでも、送信元ホストは、SIMPに衛星チャンネルの上にメッセージを送らせるようにこの旗を設定できます(物理的に同じSIMPに接続されます)。
0 = Normal operation
1 = Force channel transmission
0 = 通常操作1は力のチャンネルトランスミッションと等しいです。
0[0-7] Message Number. This field contains the identification
of the message used by the acceptance/refusal (A/R)
mechanism (when enabled). If the message number is
zero, A/R is disabled for this specific message. See
Section 5 for a detailed description of the A/R
mechanism.
0[0-7]メッセージ番号。 この分野は承認/拒否(/R)メカニズムによって使用されるメッセージの識別を含んでいます(可能にされると)。 メッセージ番号がゼロであるなら、A/Rはこの特定のメッセージのために無効にされます。 A/Rメカニズムの詳述に関してセクション5を見てください。
1[0-15] Header Checksum. This field contains a checksum which
covers words 0-5. It is computed as the negation of
the 2's-complement sum of words 0-5 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 この分野は単語0-5をカバーするチェックサムを含んでいます。 それは単語0-5(チェックサム単語自体を除いた)の2の補数合計の否定として計算されます。
2[0-15] Piggybacked A/R. This field may contain an
acceptance/refusal word providing A/R status on traffic
flowing in the opposite direction. Its inclusion may
eliminate the need for a separate A/R control message
(see Section 5). A value of zero for this word is used
to indicate that no piggybacked A/R information is
2[0-15]は/Rを背負いました。 この分野は、逆方向に流れながら、トラフィックに承認/拒否単語提供A/R状態を含むかもしれません。 包含は別々のA/Rコントロールメッセージの必要性を排除するかもしれません(セクション5を見てください)。 この単語のためのゼロの値は、どんな便乗しているA/R情報もそうでないことを示すのに使用されます。
10
10
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
present.
存在。
3[15] Data Message Type. This bit identifies whether the
message is a datagram message or a stream message.
3[15]データメッセージタイプ。 このビットは、メッセージがデータグラムメッセージかそれともストリームメッセージであるかを特定します。
0 = Datagram Message
1 = Stream Message
0 =データグラムメッセージ1=ストリームメッセージ
3[14] Internet/Local Flag. This flag is set by a source host
to specify to a destination host whether the data
portion of the message contains a standard DoD Internet
header. This field is passed transparently by the
source and destination SIMPs for traffic between
external satellite network hosts. This field is
examined by internal SIMP hosts (e.g., the network
service host) in order to support Internet operation.
3[14]インターネット/ローカルの旗。 メッセージのデータ部が標準のDoDインターネット・ヘッダーを含むか否かに関係なく、この旗はあて先ホストに指定する送信元ホストによって設定されます。 この野原はトラフィックのために外部の衛星ネットワークホストの間をソースと目的地SIMPsによって透過的に通り過ぎられます。 この分野は、インターネットが操作であるとサポートするために内部のSIMPホスト(例えば、ネットワークサービス・ホスト)によって調べられます。
0 = Internet
1 = Local
0はインターネット1と=地方であることで等しいです。
3[13] Discard Flag. This flag allows a source host to
instruct the satellite network (including the
destination host) what to do with the message when data
errors are detected (assuming the header checksum is
correct).
3[13]は旗を捨てます。 データ誤りが検出されるとき(ヘッダーチェックサムを仮定するのは正しいです)、この旗で、送信元ホストは、メッセージで何をするよう衛星ネットワーク(あて先ホストを含んでいる)に命令できます。
0 = Discard message if data errors detected.
1 = Don't discard message if data errors detected.
0 = 検出されて、データ誤りであるならメッセージを捨ててください。 1 = 検出されて、データ誤りであるならメッセージを捨てないでください。
The value of this flag, set by the source host, is
passed on to the destination host.
送信元ホストによって設定されたこの旗の値はあて先ホストに渡されます。
3[12] Data Error Flag. This flag is used in conjunction with
the Discard Flag to indicate to the destination host
whether any data errors have been detected in the
message prior to transmission over the SIMP-to-Host
access link. It is used only if Discard Flag = 1. It
should be set to zero by the source host.
3[12]データ誤りは弛みます。 この旗は、何かデータ誤りがSIMPからホストへのアクセスリンクの上のトランスミッションの前にメッセージに検出されたかどうかをあて先ホストに示すのにDiscard Flagに関連して使用されます。 Discard Flag=1である場合にだけ使用されています。 それは送信元ホストによるゼロに設定されるべきです。
11
11
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
0 = No Data Errors Detected
1 = Data Errors Detected
0 検出された1=データ誤りが検出した=いいえデータ誤り
3[10-11] Time-to-Live Designator. The source host uses this
field to specify the maximum time that a message
should be allowed to exist within the satellite network
before being deleted. Messages may be discarded by the
network prior to this maximum elapsed time.
3[10-11]生きる時間指示子。 送信元ホストは削除される前のメッセージが衛星ネットワークの中に存在できるべきである最大の時に指定するこの分野を使用します。 メッセージはこの最大の経過時間の前にネットワークによって捨てられるかもしれません。
0 = 1 seconds
1 = 2 seconds
2 = 5 seconds
3 = 10 seconds
0 = 1秒1 = 2秒2 = 5秒3 = 10秒
The Time-to-Live field is undefined in messages sent
from a SIMP to a host.
生きるTime分野はSIMPからホストに送られたメッセージで未定義です。
3[8-9] Priority. The source host uses this field to specify
the priority with which the message should be handled
within the network.
3[8-9]優先権。 送信元ホストは、メッセージがネットワークの中で扱われるべきである優先権を指定するのにこの分野を使用します。
0 = Low Priority
1 = Medium-Low Priority
2 = Medium-High Priority
3 = High Priority
0 = 媒体高い媒体低い低い優先度1=優先度2=優先度3は高い優先度と等しいです。
The priority of each message is passed to the
destination host by the destination SIMP.
それぞれのメッセージの優先権は目的地SIMPによってあて先ホストに渡されます。
3[6-7] Reliability. The source host uses this field to
specify the basic bit error rate requirement for the
data portion of this message. The source SIMP uses
this field to determine the satellite channel
transmission parameters required to provide that bit
error rate.
3[6-7]の信頼性。 送信元ホストは、このメッセージのデータ部のための基本のビット誤り率要件を指定するのにこの分野を使用します。 ソースSIMPは、衛星チャンネルトランスミッションパラメタがそのビット誤り率を提供するのが必要であることを決定するのにこの分野を使用します。
0 = Low Reliability
1 = Medium Reliability
0 = 低信頼性1は中くらいの信頼性と等しいです。
12
12
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
2 = High Reliability
3 = Reserved
2 高信頼性3=が予約した=
The Reliability field is undefined in messages sent
from a SIMP to a host.
Reliability分野はSIMPからホストに送られたメッセージで未定義です。
3[0-5] Reliability Length. This source host uses this field
to specify a portion of the user data which should be
transmitted at the highest reliability level (lowest
bit error rate). Both the six message header words and
the first Reliability Length words of user data will be
transmitted at Reliability=2 while the remainder of the
user data will be transmitted at whatever reliability
level is specified in field 3[6-7]. The reliability
length mechanism gives the user the ability to transmit
private header information (e.g., IP and TCP headers)
at a higher reliability level than the remainder of the
data. The Reliability Length field is undefined in
messages sent from a SIMP to a host.
3[0-5]信頼性の長さ。 この送信元ホストは、最も高い信頼性レベル(最も低いビット誤り率)で伝えられるべきである利用者データの部分を指定するのにこの分野を使用します。 利用者データの残りが分野3[6-7]で指定されるどんな信頼性レベルでも伝えられている間、6つのメッセージヘッダー単語と利用者データの最初のReliability Length単語の両方がReliability=2で伝えられるでしょう。 信頼性の長さのメカニズムはデータの残りより高い信頼性レベルで個人的なヘッダー情報(例えば、IPとTCPヘッダー)を伝える能力をユーザに与えます。 Reliability Length分野はSIMPからホストに送られたメッセージで未定義です。
4[0-15] Destination Host Address. This field contains the
satellite network logical address of the destination
host.
4[0-15]目的地ホスト・アドレス。 この分野はあて先ホストの衛星ネットワーク論理アドレスを含んでいます。
5[0-15] Source Host Address. This field contains the satellite
network logical address of the source host.
5[0-15]ソースホスト・アドレス。 この分野は送信元ホストの衛星ネットワーク論理アドレスを含んでいます。
6-N Data. This field contains up to 16,384 bits (1024 16-
bit words) of user data.
6-Nデータ。 この分野は最大1万6384ビット(16ビットが言い表す1024)の利用者データを含んでいます。
13
13
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
4 Stream Messages
4 ストリームメッセージ
Stream messages are the second type of message level data
messages. As noted in Section 2, streams exist primarily to
provide a one satellite hop delay for volatile traffic such as
speech. Hosts may also use streams to support high duty cycle
applications which require guaranteed channel bandwidth.
ストリームメッセージは2番目のタイプに関するメッセージレベルデータメッセージです。 セクション2に述べられるように、ストリームは主として1つの衛星ホップ遅れをスピーチなどの揮発性のトラフィックに提供するために存在しています。 また、ホストは、保証されたチャンネル帯域幅を必要とする高いデューティサイクルアプリケーションをサポートするのにストリームを使用するかもしれません。
Streams must be created before stream messages can flow from
host to host. The protocol to accomplish stream creation is
described in Section 6.1. Once established, a stream is
associated with a recurring channel allocation within the
satellite network. This fixed allocation imposes rather strict
requirements on the host using the stream if efficient channel
utilization is to be achieved. In particular, stream messages
must match the stream allocation both in terms of message size
and message interarrival time.
ストリームメッセージが接待するホストから流れることができる前にストリームを作成しなければなりません。 ストリーム作成を達成するプロトコルはセクション6.1で説明されます。 いったん設立されると、ストリームは衛星ネットワークの中で再発チャンネル配分に関連しています。 この固定配分は、効率的なチャンネル利用が達成されることであるならストリームを使用することでかなり厳しい要件をホストに課します。 特に、ストリームメッセージはメッセージサイズとメッセージinterarrival時間に関してストリーム配分に合わなければなりません。
Within the bounds of its stream allocation, a host is
permitted considerable flexibility in how it may use a stream.
Although the priority, reliability, and reliability length of
each stream message is fixed at stream creation time, the
destination logical address can vary from stream message to
stream message. A host can, therefore, multiplex a variety of
logical flows onto a single host stream. The format of stream
messages is described in Figure 2.
ストリーム配分の領域の中では、それがどうストリームを使用するかもしれないかでかなりの柔軟性がホストに受入れられます。 それぞれのストリームメッセージの優先権、信頼性、および信頼性の長さはストリーム作成時間に固定されていますが、目的地論理アドレスはメッセージを流すストリームメッセージと異なることができます。 したがって、ホストはさまざまな論理的な流れをただ一つのホストストリームに多重送信できます。 ストリームメッセージの形式は図2で説明されます。
14
14
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 1|IL| D| E| TTL | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 0|lb|GOPRI| XXXX| メッセージ番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | /R| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 1|IL| D| E| TTL| ホストSTREAM ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4 | あて先ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5 | 送信元ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6-N| データ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2 . STREAM MESSAGE
図2 ストリームメッセージ
0[15] Message Class = 0 (Data Message).
0[15]メッセージのクラス=0(データメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[12-13] Go-Priority.
0[12-13]碁優先権。
0[8-11] Reserved.
予約された0[8-11]。
0[0-7] Message Number. This field serves the same purpose as
the message number field in the datagram message.
Moreover, a single message number sequence is used for
both datagram and stream messages (see Section 5).
0[0-7]メッセージ番号。 この分野はデータグラムメッセージのメッセージナンバーフィールドと同じ目的に役立ちます。 そのうえ、ただ一つのメッセージ数順はデータグラムとストリームメッセージの両方に使用されます(セクション5を見てください)。
1[0-15] Header Checksum. Covers Words 0-5.
1[0-15]ヘッダーチェックサム。 ワーズ0-5をカバーしています。
2[0-15] Piggybacked A/R.
2[0-15]は/Rを背負いました。
15
15
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
3[15] Data Message Type = 1 (Stream).
3[15]データメッセージは=1(ストリーム)をタイプします。
3[14] Internet/Local Flag.
3[14]インターネット/ローカルの旗。
3[13] Discard Flag.
3[13]は旗を捨てます。
3[12] Data Error Flag.
3[12]データ誤りは弛みます。
3[10-11] Time-to-live Designator.
3[10-11]生きる時間指示子。
0 = Reserved
1 = 1 second
2 = Reserved
3 = Reserved
0 =は=が予約した予約された1 = 1 2番目の2=3を予約しました。
3[0-9] Host Stream ID. The service host uses this field to
identify the host stream over which the message is to
be sent by the SIMP. Host stream IDs are established
at stream creation time via host exchanges with their
network service host (see Section 6.1).
3[0-9]ホストStream ID。 サービス・ホストは、SIMPによって送られるメッセージがことであるホストストリームを特定するのにこの分野を使用します。 ホストストリームIDはストリーム作成時間に彼らのネットワークサービス・ホストとのホスト交換で確立されます(セクション6.1を見てください)。
4[0-15] Destination Host Address.
4[0-15]目的地ホスト・アドレス。
5[0-15] Source Host Address.
5[0-15]ソースホスト・アドレス。
6-N Data. This field contains up to 16,000 bits of user
data (multiple of 16-bits).
6-Nデータ。 この分野は最大1万6000ビットの利用者データ(16ビットの倍数)を含んでいます。
16
16
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
5 Flow Control Messages
5 フロー制御メッセージ
The SIMP supports an acceptance/refusal (A/R) mechanism in
each direction on the host access link. The A/R mechanism is
enabled for the link by the host by setting a bit in the Restart
Complete control message (see Section 8). Each datagram and
stream message contains an 8-bit message number used to identify
the message for flow control purposes. Both the host and the
SIMP increment this number modulo 256 in successive messages they
transmit. Up to 127 messages may be outstanding in each
direction at any time. If the receiver of a message is unable to
accept the message, a refusal indication containing the message
number of the refused message and the reason for the refusal is
returned. The refusal indication may be piggybacked on data
messages in the opposite direction over the link or may be sent
in a separate control message in the absence of reverse traffic.
SIMPは承認/拒否(/R)メカニズムをホストアクセスリンクの各方向にサポートします。 A/Rメカニズムは、ホストによってRestart Completeコントロールメッセージに少しセットすることによって、リンクに可能にされます(セクション8を見てください)。 それぞれのデータグラムとストリームメッセージはフロー制御目的へのメッセージを特定するのに使用される8ビットのメッセージ番号を含んでいます。 ホストとSIMPの両方が彼らが送る連続したメッセージのこの数の法256を増加します。 最大127のメッセージがいつでも、各方向に傑出しているかもしれません。 メッセージの受信機がメッセージを受け入れることができないなら、拒否されたメッセージと拒否の理由のメッセージ番号を含む拒否指示を返します。 拒否指示をデータメッセージでリンクの上の逆方向に便乗するか、または逆のトラフィックがないとき別々のコントロールメッセージで送るかもしれません。
Acceptance indications are returned in a similar manner,
either piggybacked on data messages or in a separate control
message. An acceptance is returned by the receiver to indicate
that the identified message was not refused. Acceptance
indications returned by the SIMP do not, however, imply a
guarantee of delivery or even any assurance that the message will
not be intentionally discarded by the network at a later time.
They are sent primarily to facilitate buffer management in the
host.
データメッセージで背負われるか、別々のコントロールメッセージのどちらかで同じように承認指摘を返します。 受信機で承認を返して、特定されたメッセージが拒否されなかったのを示します。 しかしながら、SIMPによって返された承認指摘はメッセージが故意に後でネットワークによって捨てられないという受渡保証かどんな保証さえも含意しません。 主としてホストでバッファ管理を容易にするためにそれらを送ります。
To reduce the number of A/R messages exchanged, a single A/R
indication can be returned for multiple (lower numbered)
previously unacknowledged messages. Explicit acceptance of
message number N implies implicit acceptance of outstanding
messages with numbers N-1, N-2, etc., according to the
definition of acceptance outlined above. (Note that explicit
acceptance of message number N does not imply that all of the
unacknowledged outstanding messages have been received.) An
analogous interpretation of refusal message number allows the
receiver of a group of messages to reject them as a group
assuming that they all are being refused for the same reason. As
a further efficiency measure, HAP permits a block of A/R
indications to be aggregated into a single A/R control message.
Such a message might be used, for example, to reject a group of
メッセージが交換したA/Rの数を減少させるために、複数の(番号付で、下ろします)以前に不承認のメッセージのためにただ一つのA/R指示を返すことができます。 メッセージ番号Nの明白な承認は数のN-1、N-2などがある傑出しているメッセージの暗黙の承認を含意します、上に概説された承認の定義に従って。 (メッセージ番号Nの明白な承認が、不承認の傑出しているメッセージのすべてが受け取られたのを含意しないことに注意してください。) 拒否メッセージ番号の類似の解釈はそれらが皆、同じくらいのために拒否されていると仮定するグループが推論するようにそれらを拒絶するメッセージのグループの受信機を許容します。 さらなる効率測定として、HAPは、1ブロックのA/Rしるしがただ一つのA/Rコントロールメッセージに集められるのを可能にします。 例えば、そのようなメッセージはグループを拒絶するのにおいて使用されているかもしれません。
17
17
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
messages where the refusal code on each is different.
それぞれの拒否コードが異なっているメッセージ。
In some circumstances the overhead associated with
processing A/R messages may prove unattractive. For these cases,
it is possible to disable the A/R mechanism and operate the HAP
interface in a purely discard mode. The ability to effect this
on a link basis has already been noted (see Sections 2 and 8).
In addition, messages with sequence number zero are taken as
messages for which the A/R mechanism is selectively disabled. To
permit critical feedback, even when operating in discard mode,
HAP defines an "Unnumbered Response" control message.
いくつかの事情では、処理A/Rメッセージに関連しているオーバーヘッドはつまらないと判明するかもしれません。 これらのケースにおいて、A/Rメカニズムを無効にして、中でHAPインタフェースを操作するために、aが純粋にモードを捨てるのは、可能です。 リンクベースでこれに作用する能力は既に注意されました(セクション2と8を見てください)。 さらに、一連番号ゼロがある伝言はA/Rメカニズムが選択的に無効にされるメッセージとしてみなされます。 破棄で作動さえするとき、重要なフィードバックを可能にするために、モード、HAPは「無数の応答」コントロールメッセージを定義します。
The format shown in Figure 3 is used both for piggybacking
A/R indications on data messages (word 2), and for providing A/R
information in separate control messages. When separate control
messages are used to transmit A/R indications, the format shown
in Figure 4 applies. Flow control information and other
information which cannot be sent as an A/R indication is sent in
an Unnumbered Response control message. The format of this type
of message is illustrated in Figure 5.
図3に示された書式は、データメッセージ(Word2)でA/R指摘を背負って、A/R情報を別々のコントロールメッセージに提供するのに使用されます。 別々のコントロールメッセージがA/R指摘を伝えるのに使用されるとき、図4に示された書式は適用されます。 Unnumbered ResponseコントロールメッセージでA/R指示として送ることができないフロー制御情報と他の情報を送ります。 このタイプに関するメッセージの形式は図5で例証されます。
18
18
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AR| REFUSAL CODE | A/R MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |アルゴン| 拒否コード| /Rメッセージ番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3 . ACCEPTANCE/REFUSAL WORD
図3 承認/拒否Word
[15] Acceptance/Refusal Type. This field identifies whether
A/R information is an acceptance or a refusal.
[15] 承認/拒否タイプ。 この分野は、A/R情報が承認かそれとも拒否であるかを特定します。
0 = Acceptance
1 = Refusal
0 =承認1=拒否
[8-14] Refusal Code. When the Acceptance/Refusal Type = 1,
this field gives the Refusal Code.
[8-14] 拒否コード。 Acceptance/拒否Type=1であるときに、この分野はRefusal Codeに与えます。
0 = Priority not being accepted
1 = Source SIMP congestion
2 = Destination SIMP congestion
3 = Destination host dead
4 = Destination SIMP dead
5 = Illegal destination host address
6 = Destination host access not allowed
7 = Illegal source host address
8 = Message lost in access link
9 = Nonexistent stream ID
10 = Illegal source host for stream ID
11 = Message length too long
12 = Stream message too early
13 = Illegal control message type
14 = Illegal refusal code in A/R
15 = Illegal reliability value
16 = Destination host congestion
0 = あて先ホスト不法な目的地SIMPの死んでいる5=ホスト・アドレス6=アクセスが不法なソースホスト・アドレス8=7=メッセージを許容しなかったあて先ホスト死んでいる4=目的地SIMPソースSIMP受け入れられた1でない優先権=混雑2=混雑3=目的地は損をしました; ストリーム長過ぎる12のストリームID11=メッセージ長=メッセージのための不法な実在しないストリームアクセスリンク9=ID10=送信元ホストでは、不法なコントロールメッセージ早め過ぎる13=タイプ14はあて先ホスト不法なA/R15=信頼度数値16=混雑における不法な拒否コードと等しいです。
[0-7] A/R Message Number. This field contains the number of
[0-7] /Rメッセージ番号。 この分野は数を含んでいます。
19
19
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
the message to which this acceptance/refusal refers.
It also applies to all outstanding messages with
earlier numbers. Note that this field can never be
zero since a message number of zero implies that the
A/R mechanism is disabled.
この承認/拒否が参照されるメッセージ。 また、それは以前の数ですべての傑出しているメッセージに適用されます。 ゼロのメッセージ番号が、A/Rメカニズムは障害があるのを含意するのでこの分野がゼロであるはずがないことに注意してください。
20
20
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXX | LENGTH | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . ... .
. . ... .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| XXXX| 長さ| 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | /R| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ . . ... . . . ... . +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ N| /R| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4 . ACCEPTANCE/REFUSAL MESSAGE
図4 承認/拒否メッセージ
0[15] Message Class = 1 (Control Message).
0[15]メッセージのクラス=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[12-13] Go-Priority.
0[12-13]碁優先権。
0[8-11] Reserved.
予約された0[8-11]。
0[4-7] Message Length. This field contains the total length
of this message in words (N+1).
0[4-7]メッセージ長。 この分野は単語(N+1)によるこのメッセージの全長を含んでいます。
0[0-3] Control Message Type = 1 (Acceptance/Refusal).
0[0-3]コントロールメッセージタイプは1(承認/拒否)と等しいです。
1[0-15] Header Checksum. The checksum covers words 0-N.
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-Nをカバーしています。
2[0-15] Acceptance/Refusal Word.
2[0-15]承認/拒否Word。
3-N Additional Acceptance/Refusal Words (optional).
3-Nの追加承認/拒否ワーズ(任意の)。
21
21
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXX | RES-CODE | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| XXXX| RES-コード| 5 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 応答インフォメーション| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 応答インフォメーション| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5 . UNNUMBERED RESPONSE
図5 無数の応答
0[15] Message Class = 1 (Control Message).
0[15]メッセージのクラス=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[12-13] Go-Priority.
0[12-13]碁優先権。
0[8-11] Reserved.
予約された0[8-11]。
0[4-7] Response Code.
0[4-7]応答コード。
3 = Destination unreachable
5 = Illegal destination host address
7 = Illegal source host address
9 = Nonexistent stream ID
10 = Illegal stream ID
13 = Protocol violation
15 = Can't implement loop
3 = 不法なストリーム実在しないストリーム不法なソース目的地手の届かない=不法な目的地5ホスト・アドレス7=ホスト・アドレス9=ID10=ID13は15=が輪を実装することができないプロトコル違反と等しいです。
0[0-3] Control Message Type = 5 (Unnumbered Response).
0[0-3]コントロールメッセージタイプ=5(無数の応答)。
1[0-15] Header Checksum. Covers words 0-3.
1[0-15]ヘッダーチェックサム。 単語0-3をカバーしています。
22
22
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
2[0-15] Response Information. If Response Code is:
2[0-15]応答情報。 Response Codeがそうなら:
3, Destination Host Address
5, Destination Host Address
7, Source Host Address
9, Stream ID (right justified)
10, Stream ID (right justified)
13, Word 0 of offending message
15, Word 0 of Loopback Request message
3、Destination Host Address5、Destination Host Address7、Source Host Address9、(まさしく正当)の10のStream ID Stream ID(まさしく正当な)13、腹立たしいメッセージ15のWord0、Loopback RequestメッセージのWord0
3[0-15] Response Information. If Response Code is:
3[0-15]応答情報。 Response Codeがそうなら:
3,5,7, or 9. Undefined
10, Source Host Address
13, Word 3 of offending message, or zero if
no word 3
15, Word 2 of Loopback Request message
3、5、7、または9。 未定義の10、Source Host Address13、単語でないならメッセージ、またはゼロを怒らせるWord3、3、15、Loopback RequestメッセージのWord2
23
23
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
6 Setup Level Messages
6 セットアップの平らなメッセージ
Setup level protocol is provided to support the
establishment, modification, and deletion of groups and streams
in the packet satellite network. A host wishing to perform one
of these generic operations interacts with the network service
host (logical address zero). The service host causes the
requested action to be carried out and serves as the intermediary
between the user and the rest of the network. In the process of
implementing the requested action, various network data bases are
updated to reflect the current state of the referenced group or
stream.
平らなプロトコルがパケット衛星ネットワークでグループとストリームの設立、変更、および削除をサポートするために提供されるセットアップ。 これらのジェネリック操作の1つを実行したがっているホストはネットワークサービス・ホスト(論理アドレスゼロ)と対話します。 サービス・ホストは、要求された動作が行われることを引き起こして、ユーザとネットワークの残りの間の仲介者として役目を果たします。 要求された動作を実装することの途中に、参照をつけられたグループかストリームの現状を反映するために様々なネットワークデータベースをアップデートします。
The communication between the host and the service host is
implemented via special-purpose datagrams called setup messages.
Each interaction initiated by a host involves a 3-way exchange
where: (1) the user host sends a Request to the service host, (2)
the service host returns a Reply to the user host, and (3) the
user host returns a Reply Acknowledgment to the service host.
This procedure is used to insure reliable transmission of
requests and replies. In order to allow more than one setup
request message from a host to be outstanding, each request is
assigned a unique Request ID. The associated Reply and
subsequent Reply Acknowledgment are identified by the Request ID
that they contain. Hosts should generally expect a minimum delay
of about two satellite round-trip times between the transmission
of a setup Request to the SIMP and the receipt of the associated
Reply. (Note that the Join Group Request and the Leave Group
Request require only local communication between a host and its
SIMP. The response time for these requests, therefore, is
dependent solely on SIMP processing time and should be
considerably shorter than two round-trip times.) This delay
establishes a maximum rate at which changes can be processed by
the SIMP. The user should receive a reply to a setup request
requiring global communication within 2 seconds and to a setup
request requiring local communication within 1 second. The host
should respond to a SIMP Reply with a Reply Acknowledgment within
1 second.
ホストとサービス・ホストとのコミュニケーションはセットアップメッセージと呼ばれる専用データグラムを通して実装されます。 ホストによって起こされた各相互作用は3ウェイを伴います。どこを交換してくださいか: (1) (3) ユーザー・ホストはRequestをサービス・ホストに送ります、そして、(2) サービス・ホストはReplyをユーザー・ホストに返します、そして、ユーザー・ホストはReply Acknowledgmentをサービス・ホストに返します。 この手順は、要求と回答の信頼できる送信を保障するのに用いられます。 傑出しているためにホストからの1つ以上のセットアップ要求メッセージを許容するために、ユニークなRequest IDは各要求に割り当てられます。 関連Replyとその後のReply Acknowledgmentはそれらが含むRequest IDによって特定されます。 一般に、ホストはSIMPへのセットアップRequestのトランスミッションと受領の間で最低往復のおよそ2衛星回の遅れを関連Replyに予想するべきです。 (Join Group RequestとLeave Group RequestがホストとそのSIMPとのローカルのコミュニケーションだけを必要とすることに注意してください。 これらの要求のための応答時間は、したがって、唯一SIMP処理時間に依存していて、往復の2回よりかなり短いはずです。) この遅れはSIMPが変化を処理できる最高率を確立します。 ユーザは2秒以内にグローバルコミュニケーションを必要とするセットアップ要求と、そして、1秒以内にローカルのコミュニケーションを必要とするセットアップ要求に回答を受け取るべきです。 ホストは1秒以内にReply Acknowledgmentと共にSIMP Replyに応じるべきです。
24
24
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Setup exchanges can also be initiated by the SIMP. SIMP-
initiated setup messages are used to notify a host of changes in
the status of an associated group or stream. Each notification
involves a 2-way exchange where: (1) the service host sends a
Notification to the user host, and (2) the user host returns a
Notification Acknowledgment to the service host. In order to
allow more than one Notification to be outstanding, each is
assigned a unique Notification ID. The Notification
Acknowledgment returned by the user host to the service host must
contain the Notification ID.
また、SIMPはセットアップ交換を起こすことができます。 SIMPの開始しているセットアップメッセージは、関連グループかストリームの状態の多くの変化に通知するのに使用されます。 各通知は2ウェイを伴います。どこを交換してくださいか: (1) (2) サービス・ホストはユーザー・ホストに通知書を送ります、そして、ユーザー・ホストはNotification Acknowledgmentをサービス・ホストに返します。 1Notificationが傑出しているのを許容するために、ユニークなNotification IDはそれぞれに割り当てられます。 サービス・ホストのユーザー・ホストによって返されたNotification AcknowledgmentはNotification IDを含まなければなりません。
The general format of every setup message is:
あらゆるセットアップメッセージの一般形式は以下の通りです。
<DATAGRAM MESSAGE HEADER>
<OPTIONAL INTERNET HEADER>
<SETUP MESSAGE HEADER>
<SETUP MESSAGE BODY>
任意の<のヘッダー><セットアップメッセージデータグラムメッセージヘッダー><インターネットヘッダー><セットアップメッセージボディー>。
The service host accepts setup requests in either Internet or
non-Internet format. Replies from the service host will be in
the same form as the request, that is, Internet requests get
Internet replies, and non-Internet requests get non-Internet
replies.
サービス・ホストはインターネットか非インターネット形式のどちらかにおけるセットアップ要求を受け入れます。 サービス・ホストからの回答が要求と同じフォームにあるでしょう、そして、すなわち、インターネット要求はインターネット回答を得ます、そして、非インターネット要求は非インターネット回答を得ます。
The format of the combined datagram message header and setup
message header is illustrated in Figure 6. The body of the setup
messages depends on the particular setup message type. Stream
request and reply messages are described in Section 6.1. Group
request and reply messages are described in Section 6.2. To
simplify the presentation in both of these sections, the setup
messages are assumed to be exchanged between a local host and
SIMP even though Internet group and stream setups are supported
(see Figure 6). The format of notifications, which consists of
only a single word beyond the basic setup header, is shown in
Figure 7. Since the SIMP does not retain the optional Internet
header information that can be included in setup requests,
Internet notifications are not supported. The format of
acknowledgment messages associated with request/reply and
notification setups is illustrated in Figure 8.
結合したデータグラムメッセージヘッダーとセットアップメッセージヘッダーの形式は図6で例証されます。 セットアップメッセージのボディーは特定のセットアップメッセージタイプに頼ります。 ストリーム要求と応答メッセージはセクション6.1で説明されます。 グループ要求と応答メッセージはセクション6.2で説明されます。 これらのセクションの両方でプレゼンテーションを簡素化するために、インターネットグループとストリームセットアップがサポートされますが(図6を見てください)、ローカル・ホストとSIMPの間でセットアップメッセージが交換されると思われます。 通知の書式(基本的なセットアップヘッダーで一語だけから成る)は図7に示されます。 SIMPがセットアップ要求に含むことができる任意のインターネットヘッダー情報を保有しないので、インターネット通知はサポートされません。 要求/回答と通知セットアップに関連している承認メッセージの形式は図8で例証されます。
25
25
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | <OPTIONAL INTERNET HEADER> |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+1 | SETUP TYPE | SETUP CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+2 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+3 | SETUP ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6-N| <の任意のインターネットヘッダー>。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ N+1| セットアップタイプ| セットアップコード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ N+2| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ N+3| セットアップID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 6 . SETUP MESSAGE HEADER
図6 セットアップメッセージヘッダー
0-5 Datagram Message Header. Each setup message begins
with the six word datagram message header (see Section
3).
0-5 データグラムメッセージヘッダー。 それぞれのセットアップメッセージは6単語データグラムメッセージヘッダーと共に始まります(セクション3を見てください)。
6-N Internet Header (Optional). These fields, when
present, conform to the DoD Standard Internet Protocol
(IP). The Internet header size is a minimum of 10
words but can be longer depending on the use of
optional IP facilities. (Internet notification
messages are not supported.)
6-Nインターネットヘッダー(任意の)。 存在しているとき、これらの分野はDoD Standardインターネットプロトコル(IP)に従います。 任意のIP施設の使用によって、インターネット・ヘッダーサイズは、最低10の単語ですが、より長い場合があります。 (インターネット通知メッセージはサポートされません。)
N+1[8-15] Setup Type. This field determines the type of setup
message.
N+1[8-15]はタイプをセットアップします。 この分野はセットアップメッセージのタイプを決定します。
0 = Acknowledgment
1 = Request
2 = Reply
3 = Notification
0 = 承認1=要求2=回答3は通知と等しいです。
N+1[0-7] Setup Code. For requests, this field identifies the
N+1[0-7]はコードをセットアップします。 要求、この分野、特定
26
26
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Request Type.
タイプを要求してください。
1 = Create group address
2 = Delete group address
3 = Join group
4 = Leave group
5 = Create stream
6 = Delete stream
7 = Change stream parameters
8 = Reserved
=が作成する1、グループアドレス2=がアドレス3=が加わるグループを削除する、グループ5=が作成するグループ4=休暇はストリーム7=変化ストリームパラメタ8=予約されていた状態で=が削除する6を流します。
For Replies, this field provides the Reply Code. Some
of the Reply Codes can be returned to any setup
request and others are request specific.
Repliesのために、この分野はReply Codeを提供します。 どんなセットアップ要求にもいくつかのReply Codesを返すことができます、そして、他のものは要求特有です。
0 = Group or stream created
1 = Group or stream deleted
2 = Group joined
3 = Group left
4 = Stream changed
5 = Reserved
6 = Bad request type
7 = Reserved
8 = Network trouble
9 = Bad key
10 = Group address/stream ID nonexistent
11 = Not member of group/creator of stream
12 = Stream priority not being accepted
13 = Reserved
14 = Reserved
15 = Illegal interval
16 = Reserved
17 = Insufficient network resources
18 = Requested bandwidth too large
19 = Reserved
20 = Reserved
21 = Maximum messages per slot not consistent with
slot size
22 = Reply lost in network
23 = Illegal reliability value
不十分なネットワーク資源18予約された不法な予約された予約された13=14=15=間隔16=17==がネットワーク23で失われているスロットサイズ22=回答と一致していないスロットあたりの最大の予約された予約された帯域幅大き過ぎる19=20=21=メッセージに要求した受け入れるのは不法な信頼度数値と等しいです。
27
27
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
For Notifications, this field contains the
Notification Type.
Notificationsに関しては、この分野はNotification Typeを含んでいます。
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by host
4 = Group deleted by SIMP
5 = All streams deleted
6 = All groups deleted
0 = 削除された3=グループがSIMP5によって削除されたホスト4=グループで削除した再開している2=ストリーム=すべてが流す1つのストリーム吊した=ストリームがグループが削除した6=すべてを削除しました。
For Acknowledgments, this field contains the
Acknowledgment Type.
Acknowledgmentsに関しては、この分野はAcknowledgment Typeを含んでいます。
0 = Reply acknowledgment
1 = Notification acknowledgment
0 = 回答承認1は通知承認と等しいです。
N+2[0-15] Setup Checksum. The checksum covers the three setup
message header words and the setup message body data
words. Setups received with bad checksums must be
discarded.
N+2[0-15]はチェックサムをセットアップします。 チェックサムは3つのセットアップメッセージヘッダー単語とセットアップメッセージボディーデータ・ワードを含んでいます。 悪いチェックサムで受けられたセットアップを捨てなければなりません。
N+3[0-15] Setup ID. This field is assigned by the host to
uniquely identify outstanding requests (Request ID)
and by the service host to uniquely identify
outstanding notifications (Notification ID).
N+3[0-15]はIDをセットアップします。 この分野は、唯一、傑出している通知(Notification ID)を特定するために唯一、傑出している要求(IDを要求する)を特定するホストとサービス・ホストによって割り当てられます。
28
28
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 3 | NOTIFICATION TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | NOTIFICATION ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | NOTIFICATION INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 3 | 通知タイプ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | 通知ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | 通知インフォメーション| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 7 . NOTIFICATION MESSAGE
図7 通知メッセージ
0-5 Datagram Message Header (see Section 3).
0-5 データグラムメッセージヘッダー(セクション3を見ます)。
6[8-15] Setup Type = 3 (Notification).
6[8-15]セットアップタイプは3(通知)と等しいです。
6[0-7] Notification Type.
6[0-7]通知タイプ。
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by host
4 = Group deleted by SIMP
5 = All streams deleted
6 = All groups deleted
0 = 削除された3=グループがSIMP5によって削除されたホスト4=グループで削除した再開している2=ストリーム=すべてが流す1つのストリーム吊した=ストリームがグループが削除した6=すべてを削除しました。
7[0-15] Setup Checksum. Covers words 6-9.
7[0-15]セットアップチェックサム。 単語6-9をカバーしています。
8[0-15] Notification ID.
8[0-15]Notification ID。
9[0-15] Notification Information. This field contains the
16-bit group address in the case of a group
9[0-15]通知情報。 この分野はグループの場合に16ビットのグループアドレスを含んでいます。
29
29
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
notification (types 3 and 4) and the 10-bit host
stream ID (right justified) in the case of a stream
notification (types 0-2). This field is zero for
Notification Types 5 and 6, which pertain to ALL
streams and groups, respectively.
通知(3と4をタイプする)と10ビットのホストはストリーム通知(0-2に、タイプする)の場合でID(まさしく正当な)を流します。 この分野は、Notification Types5と6のためのゼロであり、それぞれ分類されます。(Notification Typesはすべてのストリームに関係します)。
30
30
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 0 | ACK TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | SETUP ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 0 | ACKはタイプします。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | セットアップID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 8 . SETUP ACKNOWLEDGMENT
エイト環セットアップ承認
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 0 (Acknowledgment).
6[8-15]セットアップタイプは0(承認)と等しいです。
6[0-7] Acknowledgment Type.
6[0-7]承認タイプ。
0 = Reply acknowledgment
1 = Notification acknowledgment
0 = 回答承認1は通知承認と等しいです。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Setup ID. This is either a Request ID or a
Notification ID.
8[0-15]Setup ID。 これは、Request IDかNotification IDのどちらかです。
31
31
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
6.1 Stream Setup Messages
6.1 ストリームセットアップメッセージ
Hosts use streams to support high duty cycle applications
and applications requiring a one satellite hop network
transmission delay. Host streams must be set up before stream
data messages can flow. The stream setup messages defined by HAP
are Create Stream Request, Create Stream Reply, Delete Stream
Request, Delete Stream Reply, Change Stream Parameters Request,
and Change Stream Parameters Reply. The use of these messages is
illustrated in the scenario of exchanges between a host and its
local SIMP shown in Figure 9 where the host establishes a stream,
sends some data, modifies the stream characteristics, sends some
more data, and finally closes down the stream.
ホストは、高いデューティサイクルアプリケーションと1つの衛星ホップネットワーク送信遅れを必要とするアプリケーションをサポートするのにストリームを使用します。 ストリームデータメッセージが流れることができる前にホストストリームをセットアップしなければなりません。 HAPによって定義されたストリームセットアップメッセージは、Create Stream Requestと、Create Stream Replyと、Delete Stream Requestと、Delete Stream Replyと、Change Stream Parameters Requestと、Change Stream Parameters Replyです。 これらのメッセージの使用は、図9にホストがどこでストリームを確立するかが示されたホストとその地方のSIMPの間の交換のシナリオで例証されて、いくつかのデータを送って、ストリームの特性を変更して、それ以上のデータを送って、最終的にストリームを閉鎖します。
It is worthwhile noting that the setup exchanges in Figure 9
are completely between the host originating the stream and its
local SIMP. Other SIMPs and hosts are essentially unaware of the
existence of the stream. Stream messages received by a
destination host are, therefore, processed identically to
datagram messages. (All SIMPs must, of course, be aware of the
channel allocation associated with a host stream in order to
perform satellite channel scheduling.) Not illustrated, but
implicit in this scenario, are the optional A/R indications
associated with each of the stream setup messages.
完全ストリームを溯源するホストとその地方のSIMPの間には、図9におけるセットアップ交換があることに注意する価値があります。 他のSIMPsとホストはストリームの存在に本質的には気づきません。 したがって、あて先ホストによって受け取られたストリームメッセージは同様にデータグラムメッセージに処理されます。 (すべてのSIMPsが衛星チャンネルスケジューリングを実行するためにもちろんホストストリームに関連しているチャンネル配分を意識していなければなりません。) このシナリオでイラスト入りではありませんが、暗黙であることは、それぞれに関するストリームセットアップメッセージに関連している任意のA/R指摘です。
32
32
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Host SIMP
ホストSIMP
Create Stream Request ------>
Create Stream Reply <------
Reply Acknowledgment ------>
Stream Message ------>
.
.
Stream Message ------>
Change Stream Parameters Request ------>
Change Stream Parameters Reply <------
Reply Acknowledgment ------>
Stream Message ------>
.
.
Stream Message ------>
Delete Stream Request ------>
Delete Stream Reply <------
Reply Acknowledgment ------>
ストリーム要求を作成してください。------>はストリーム回答<を作成します。------ 回答承認------>ストリームメッセージ------>ストリームメッセージ------変化ストリームパラメタが要求する>。------>変化ストリームパラメタ回答<。------ 回答承認------>ストリームメッセージ------>ストリームメッセージ------>はストリーム要求を削除します。------>はストリーム回答<を削除します。------ 回答承認------>。
Figure 9 . STREAM EXAMPLE
図9 ストリームの例
Host streams have six characteristic properties which are
selected at stream setup time. These properties, which apply to
every message transmitted in the stream, are: (1) slot size, (2)
interval, (3) reliability, (4) reliability length, (5) priority,
and (6) maximum messages per slot. To establish a stream, the
host sends the Create Stream Request message illustrated in
Figure 10 to the SIMP. After the satellite network has processed
the Create Stream Request, the SIMP will respond to the host with
a Create Stream Reply message formatted as shown in Figure 11.
Assuming that the reply code in the Create Stream Reply is zero
indicating that the stream has been created successfully, the
host may proceed to transmit stream data messages after sending a
ホストストリームには、ストリーム準備時間に選択される6つの独特の特性があります。 これらの特性(ストリームで送られたあらゆるメッセージに適用される)は以下の通りです。 (1) サイズ、(2)間隔、(3)の信頼性、(4)信頼性の長さ、(5)優先権、および1スロットあたりの(6)の最大のメッセージに溝をつけてください。 ストリームを証明するために、ホストは図10でSIMPに例証されたCreate Stream Requestメッセージを送ります。 衛星ネットワークがCreate Stream Requestを処理した後に、Create Stream Replyメッセージがフォーマットされている状態で、SIMPは図11に示されるようにホストに応じるでしょう。 Create Stream Replyの回答コードが首尾よくストリームを作成してあるのを示さないことであると仮定する場合、aを送った後に、ホストはストリームデータメッセージを送るかもしれなくしかけます。
33
33
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Reply Acknowledgment.
回答承認。
During the lifetime of a stream, the host which created it
may decide that some of its six characteristic properties should
be modified. All of the properties except the stream interval
can be modified using the Change Stream Parameters Request
message. The format of this command is illustrated in Figure 12.
After the network has processed the Change Stream Parameters
Request, the SIMP will respond by sending a Change Stream
Parameters Reply to the host with the format shown in Figure 13.
A host requesting a reduced channel allocation should decrease
its sending rate immediately without waiting for receipt of the
Change Stream Parameters Reply. A host requesting an increased
allocation should not proceed to transmit according to the new
set of parameters without first having received a Reply Code of 4
indicating that the requested change has taken effect.
ストリームの生涯、それを作成したホストは、6つの独特の特性のいくつかが変更されるべきであると決めるかもしれません。 Change Stream Parameters Requestメッセージを使用することでストリーム間隔以外の特性のすべてを変更できます。 このコマンドの形式は図12で例証されます。 ネットワークがChange Stream Parameters Requestを処理した後に、SIMPは、Change Stream Parameters Replyをホストに図13に示される書式で送ることによって、応じるでしょう。 すぐChange Stream Parameters Replyの領収書を待たないで、減少しているチャンネル配分を要求するホストは送付レートを減少させるべきです。 最初に要求された変化が効いたのを示す4のReply Codeを受けていなくて、新しいセットのパラメタによると、増強された配分を要求するホストは伝わりかけるべきではありません。
When the host which created the host stream determines that
the stream is no longer needed and the associated satellite
channel allocation can be freed up, the host sends its local SIMP
a Delete Stream Request message formatted as indicated in Figure
14. After the network has processed the Delete Stream Request,
the SIMP will respond by sending a Delete Stream Reply to the
host with the format shown in Figure 15.
ホストであるときに、どれがホストストリームを作成したかがもうストリームを必要としないで、関連衛星チャンネル配分を開けることができることを決定して、ホストは図14にみられるようにフォーマットされたDelete Stream Requestメッセージを地方のSIMPに送ります。 ネットワークがDelete Stream Requestを処理した後に、SIMPは、Delete Stream Replyをホストに図15に示される書式で送ることによって、応じるでしょう。
34
34
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | MAX MES | INT | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | SLOT SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 5 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | マックスMES| INT| PRI| RLY| RLEN| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | スロットサイズ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 10 . CREATE STREAM REQUEST
図10 ストリーム要求を作成してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 5 (Create Stream).
6[0-7]要求タイプ=5(ストリームを作成します)。
7[0-15] Setup Checksum. Covers words 6-10.
7[0-15]セットアップチェックサム。 単語6-10をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
9[12-15] Maximum Messages Per Slot. This field specifies the
the maximum number of stream messages that will ever
be delivered to the SIMP by the host for transmission
in one stream slot.
1スロットあたりの9[12-15]の最大のメッセージ。 この分野は今までに1つのストリームスロットのトランスミッションのためにホストによってSIMPに提供されるストリームメッセージの最大数を指定します。
9[10-11] Interval. This field specifies the interval, in
number of 21.2 ms frames, between stream slots.
9[10-11]間隔。 この分野はストリームスロットの間の21.2個のmsフレームの数で間隔を指定します。
35
35
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
0 = 1 frame
1 = 2 frames
2 = 4 frames
3 = 8 frames
0 = 1 フレーム1 = 2は2 = 4 フレーム3 = 8フレームを縁どっています。
As an example, an interval of 4 frames corresponds to
an allocation of Slot Size words every 85 ms.
例、フレームが配分に対応する4の間隔として、Slot Sizeはあらゆる85原稿を言い表します。
9[8-9] Priority. This field specifies the priority at which
all messages in the host stream should be handled.
9[8-9]優先権。 この分野はホストストリームにおけるすべてのメッセージが扱われるべきである優先権を指定します。
0 = Low priority
1 = Medium Low Priority
2 = Medium High Priority
3 = High Priority
0 = 低い優先度1は中型のLow Priority2=媒体の高いHigh Priority3=Priorityと等しいです。
9[6-7] Reliability. This field specifies the basic bit-
error rate requirement for the data portion of all
messages in the host stream.
9[6-7]の信頼性。 この分野はホストストリームにおけるすべてのメッセージのデータ部のための基本のビット誤り率要件を指定します。
0 = Low Reliability
1 = Medium Reliability
2 = High Reliability
3 = Reserved
0 = 低信頼性1は=が予約した中くらいの信頼性2=高信頼性3と等しいです。
9[0-5] Reliability Length. This field specifies how many
words beyond the stream message header should be
transmitted at maximum reliability for all messages
in the host stream.
9[0-5]信頼性の長さ。 この分野は、ストリームメッセージヘッダーを超えたいくつの言葉がホストストリームにおけるすべてのメッセージのために最大の信頼性で伝えられるべきであるかを指定します。
10[0-15] Slot Size. This field specifies the slot size in
16-bit words of stream message text. Stream message
header words are excluded from this count. The host
can partition this allocation on a slot-by-slot basis
among a variable number of messages as long as the
maximum number of messages per slot does not exceed
MAX MES.
10[0-15]スロットサイズ。 この分野はストリームメッセージ・テキストの16ビットの単語によるスロットサイズを指定します。 ストリームメッセージヘッダー単語はこのカウントから除かれます。 1スロットあたりのメッセージの最大数がMAX MESを超えていない限り、ホストはスロットごとの可変数のメッセージの中のベースにこの配分を仕切ることができます。
36
36
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | XXXXX| ホストSTREAM ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 11 . CREATE STREAM REPLY
図11 ストリーム回答を作成してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
0 = Stream created
8 = Network trouble
12 = Stream priority not being accepted
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Maximum messages per slot not consistent
with slot size
22 = Reply lost in network
23 = Illegal reliability value
0 = ストリームは不法なネットワーク23=信頼度数値で失われているスロットサイズ22=回答と一致していないスロットあたりの最大の21=メッセージに大き過ぎる状態で要求された17個の受け入れられた=不十分なネットワーク資源18=帯域幅でないストリーム8=ネットワーク問題12=優先権を作成しました。
7[0-15] Setup Checksum. Covers words 6-9.
7[0-15]セットアップチェックサム。 単語6-9をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
37
37
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
9[10-15] Reserved.
予約された9[10-15]。
9[0-9] Host Stream ID. This field contains a host stream
ID assigned by the network. It must be included in
all stream data messages sent by the host to allow
the SIMP to associate the message with stored stream
characteristics and the reserved satellite channel
time.
9[0-9]ホストStream ID。 この分野はIDがネットワークで割り当てたホストストリームを含んでいます。 SIMPが保存されたストリームの特性と予約された衛星チャンネル時間にメッセージを関連づけるのを許容するためにホストによって送られたすべてのストリームデータメッセージにそれを含まなければなりません。
38
38
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | MAX MES | INT | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | SLOT SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 7 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | XXXXX| ホストSTREAM ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | マックスMES| INT| PRI| RLY| RLEN| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 11 | スロットサイズ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 12 . CHANGE STREAM PARAMETERS REQUEST
変化ストリームパラメタが要求する図12
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 7 (Change Stream Parameters).
6[0-7]要求タイプ=7(変化ストリームパラメタ)。
7[0-15] Setup Checksum. Covers words 6-11.
7[0-15]セットアップチェックサム。 単語6-11をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
9[10-15] Reserved.
予約された9[10-15]。
9[0-9] Host Stream ID.
9[0-9]ホストStream ID。
10[12-15] New Maximum Messages Per Slot.
1スロットあたりの10[12-15]の新しい最大のメッセージ。
39
39
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
10[10-11] Interval. This field must specifiy the same
interval as was specified in the Create Stream
Request message for this stream.
10[10-11]間隔。 この分野はこのストリームへのCreate Stream Requestメッセージで指定されたのと同じ間隔をspecifiyしなければなりません。
10[8-9] New Priority.
10[8-9]の新しい優先権。
10[6-7] New Reliability.
10[6-7]の新しい信頼性。
10[0-5] New Reliability Length.
10[0-5]の新しい信頼性の長さ。
11[0-15] New Slot Size.
11[0-15]の新しいスロットサイズ。
40
40
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 13 . CHANGE STREAM PARAMETERS REPLY
図13変化ストリームパラメタ回答
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
4 = Stream changed
8 = Network trouble
10 = Stream ID nonexistent
11 = Not creator of stream
12 = Stream priority not being accepted
15 = Illegal interval
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Maximum messages per slot not consistent with
slot size
22 = Reply lost in network
23 = Illegal reliability value
4 = 不十分なネットワーク資源18受け入れられた=不法な15間隔17==でないストリームストリーム12の変えられたストリームネットワーク問題10=8=ストリームIDの実在しない11=クリエイターでない=優先権は不法なネットワーク23=信頼度数値で失われているスロットサイズ22=回答と一致していないスロットあたりの最大の大き過ぎる21=メッセージに帯域幅を要求しました。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
41
41
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 6 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | XXXXX| ホストSTREAM ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 14 . DELETE STREAM REQUEST
図14 ストリーム要求を削除してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 6 (Delete Stream).
6[0-7]要求タイプ=6(ストリームを削除します)。
7[0-15] Setup Checksum. Covers words 6-9.
7[0-15]セットアップチェックサム。 単語6-9をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
9[10-15] Reserved.
予約された9[10-15]。
9[0-9] Host Stream ID.
9[0-9]ホストStream ID。
42
42
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 15 . DELETE STREAM REPLY
図15 ストリーム回答を削除してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
1 = Stream deleted
8 = Network trouble
10 = Stream ID nonexistent
11 = Not creator of stream
17 = Insufficient network resources
22 = Reply lost in network
1 = ストリームは不十分なネットワーク資源22=ストリーム17のIDの実在しない11=クリエイターでない=回答がネットワークで失った8=ネットワーク問題10=ストリームを削除しました。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
43
43
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
6.2 Group Setup Messages
6.2 グループセットアップメッセージ
Group addressing allows hosts to take advantage of the
broadcast capability of the satellite network and is primarily
provided to support the multi-destination delivery required for
conferencing applications. Group addresses are dynamically
created and deleted via setup messages exchanged between hosts
and the network. Membership in a group may consist of an
arbitrary subset of all the permanent network hosts. A datagram
message or stream message addressed to a group is always sent
over the satellite channel and delivered to all hosts that are
members of that group. The group setup messages are Create Group
Request, Create Group Reply, Delete Group Request, Delete Group
Reply, Join Group Request, Join Group Reply, Leave Group Request,
and Leave Group Reply.
グループ・アドレッシングをホストが衛星ネットワークの放送能力を利用するのを許容して、マルチの目的地が会議アプリケーションに必要である配送であるとサポートするために主として前提とします。 グループアドレスは、ホストとネットワークの間で交換されたセットアップメッセージで、ダイナミックに作成されて、削除されます。 グループにおける会員資格はすべての永久的なネットワークホストの任意の部分集合から成るかもしれません。 グループに扱われたデータグラムメッセージかストリームメッセージが、いつも衛星チャンネルの上に送られて、そのグループのメンバーであるすべてのホストに提供されます。 グループセットアップメッセージは、Create Group Requestと、Create Group Replyと、Delete Group Requestと、Delete Group Replyと、Join Group Requestと、Join Group Replyと、Leave Group Requestと、Leave Group Replyです。
The use of group setup messages is shown in Figure 16. The
figure illustrates a scenario of exchanges between two hosts and
their local SIMPs. In the scenario one host, Host A, creates a
group which is joined by a second host, Host B. After the two
hosts have exchanged some data mesages addressed to the group,
Host B decides to leave the group and Host A decides to delete
the group. As in the scenario in Section 6.1, A/R indications
have been omitted for clarity.
グループセットアップメッセージの使用は図16に示されます。 図は2人のホストと地元のSIMPsの間の交換のシナリオを例証します。 シナリオでは、1人のホスト(Host A)が2番目のホストによって加わられるグループを創設します、そして、2人のホストのHost B.Afterはグループに扱われたいくらかのデータmesagesを交換しました、そして、Host Bは、仲間から抜けると決めます、そして、Host Aはグループを削除すると決めます。 セクション6.1のシナリオのように、A/R指摘は明快ために省略されました。
Part of the group creation procedure involves the service
host returning a 48-bit key along with a 16-bit group address to
the host creating the group. The creating host must pass the key
along with the group address to the other hosts which it wants as
group members. These other hosts must supply the key along with
the group address in their Join Group Requests. The key is used
by the network to authenticate these operations and thereby
minimize the probability that unwanted hosts will deliberately or
inadvertently become members of the group. The procedure used by
a host to distribute the group address and key is not within the
scope of HAP.
グループ作成手順の一部が16ビットのグループアドレスに伴う48ビットのキーをグループを創設するホストに返すサービス・ホストにかかわります。 作成しているホストは他のホストへのそれがグループのメンバーとして欲しいグループアドレスに伴うキーを渡さなければなりません。 これらの他のホストは彼らのJoin Group Requestsのグループアドレスに伴うキーを供給しなければなりません。 キーは、これらの操作を認証して、その結果、求められていないホストが故意にかうっかりグループのメンバーになるという確率を最小にするのにネットワークによって使用されます。 HAPの範囲の中にグループアドレスとキーを配布するのにホストによって用いられた手順がありません。
44
44
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
Host SIMP SIMP Host
A A B B
ホストSIMP SIMPはA B Bを接待します。
Create Group Request ------>
Create Group Reply <------
Reply Acknowledgment ------>
.
.
>>Group Address,Key>>
.
.
Join Group Request <------
Join Group Reply ------>
Reply Acknowledgment <------
グループ要求を作成してください。------>はグループ回答<を作成します。------ 回答承認------>>はアドレス、主要な>>を分類します。>グループ要求<を接合してください。------ グループ回答に参加してください。------>回答承認<。------
Data Message 1 ------>
Data Message 1 <------ ------>
Data Message 2 <------
Data Message 2 <------ ------>
Leave Group Request <------
Leave Group Reply ------>
Reply Acknowledgment <------
Delete Group Request ------>
Delete Group Reply <------
Reply Acknowledgment ------>
データメッセージ1------>データメッセージ1<。------ ------>データメッセージ2<。------ データメッセージ2<。------ ------>はグループ要求<を残します。------ グループ回答を残してください。------>回答承認<。------ グループ要求を削除してください。------>はグループ回答<を削除します。------ 回答承認------>。
Figure 16 . GROUP EXAMPLE
図16 グループの例
Any host no longer wishing to participate in a group may
choose to drop out. This can be accomplished by either a Leave
or a Delete. Both Leave and Delete operations are authenticated
using the 48-bit key. Leave is a local operation between a host
and its SIMP which removes the requesting host from the group
membership list but does not alter the global existence of the
もうグループに参加したがっていないどんなホストも、落ちるのを選ぶかもしれません。 LeaveかDeleteのどちらかがこれを達成できます。 LeaveとDelete操作の両方が、48ビットのキーを使用することで認証されます。 休暇はホストとそのSIMPの間の記載しますが、会員資格がグローバルな存在を変更しないグループから要求ホストを免職するa地方の操作です。
45
45
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
group. A Delete, on the other hand, expunges all knowledge of
the group from every SIMP in the network. HAP will permit any
member of a group to delete the group at any time. Thus, group
addresses can be deleted even if the host which originally
created the group has left the group or has crashed. Moreover,
groups may exist for which there are currently no members because
each member has executed a Leave while none has executed a
Delete. It is the responsibility of the hosts to coordinate and
manage the use of groups.
分類してください。 他方では、DeleteはネットワークにおけるあらゆるSIMPからのグループに関するすべての知識を梢消します。 HAPは、グループのどんなメンバーもいつでもグループを削除するのを可能にするでしょう。 したがって、元々グループを創設したホストが仲間から抜けた、またはダウンしたとしても、グループアドレスを削除できます。 そのうえ、なにもDeleteを実行していませんが、各メンバーがLeaveを実行したので現在、メンバーが全くいないグループは存在するかもしれません。 グループの使用を調整して、管理するのは、ホストの責任です。
The Create Group Request message sent to the service host to
establish a group address is illustrated in Figure 17. After the
network has processed the Create Group Request, the service host
will respond by sending a Create Group Reply to the host as
illustrated in Figure 18.
グループアドレスを証明するためにサービス・ホストに送られたCreate Group Requestメッセージは図17で例証されます。 ネットワークがCreate Group Requestを処理した後に、サービス・ホストは、図18で例証されるようにCreate Group Replyをホストに送ることによって、応じるでしょう。
A host may become a member of a group once it knows the
address and key associated with the group by sending the service
host the Join Group Request message shown in Figure 19. The
service host will respond to the Join Group Request with a Join
Group Reply formatted as indicated in Figure 20. The host which
creates a group automatically becomes a member of that group
without any need for an explicit Join Group Request.
いったん図19に示されたJoin Group Requestメッセージをサービス・ホストに送ることによってグループに関連しているアドレスとキーを知っていると、ホストはグループのメンバーになるかもしれません。 サービス・ホストはJoin Group RequestにJoin Group Replyが図20にみられるようにフォーマットにされるので応じるでしょう。 自動的にグループを創設するホストは明白なJoin Group Requestの少しも必要性なしでそのグループのメンバーになります。
At any time after becoming a member of a group, a host may
choose to drop out of the group. To effect this the host sends
the service host a Leave Group Request formatted as shown in
Figure 21. The service host will respond to the Leave Group
Request with a Leave Group Reply formatted as shown in Figure 22.
グループのメンバーになった後にいつでも、ホストは、グループを落第するのを選ぶかもしれません。 これに作用するように、ホストは図21に示されるようにフォーマットされたLeave Group Requestをサービス・ホストに送ります。 Leave Group Replyがフォーマットされている状態で、サービス・ホストは図22に示されるようにLeave Group Requestに応じるでしょう。
Any member of a group can request that the service host
delete an existing group via a Delete Group Request. The format
of the Delete Group Request setup message is illustrated in
Figure 23. After the network has processed the Delete Group
Request, the service host will respond to the host with a Delete
Group Reply formatted as illustrated in Figure 24.
グループのどんなメンバーも、サービス・ホストがDelete Group Requestを通して既存のグループを削除するよう要求できます。 Delete Group Requestセットアップメッセージの形式は図23で例証されます。 ネットワークがDelete Group Requestを処理した後に、サービス・ホストは図24で例証されるようにフォーマットされるDelete Group Replyのホストに応じるでしょう。
46
46
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 17 . CREATE GROUP REQUEST
図17 グループ要求を作成してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 1 (Create Group).
6[0-7]要求タイプ=1(グループを創設します)。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
47
47
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 11 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 12 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 18 . CREATE GROUP REPLY
図18 グループ回答を作成してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
0 = Group created
8 = Network trouble
17 = Insufficient network resources
22 = Reply lost in network
0 = グループはネットワークで失われた不十分なネットワーク資源22=8=ネットワーク問題17=回答を作成しました。
7[0-15] Setup Checksum. Covers words 6-12.
7[0-15]セットアップチェックサム。 単語6-12をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
48
48
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
9[0-15] Group Address. This field contains a 16-bit logical
address assigned by the network which may be used by
the host as a group address.
9[0-15]グループアドレス。 この分野はグループアドレスとしてホストによって使用されるかもしれないネットワークによって割り当てられた16ビットの論理アドレスを含んでいます。
10-12 Key. This field contains a 48-bit key assigned by the
network which is associated with the group address.
It must be provided for subsequent Join, Leave, and
Delete requests which reference the group address.
10-12 主要です。 この分野はグループアドレスに関連しているネットワークによって割り当てられた48ビットのキーを含んでいます。 グループがそれの参照を扱うその後のJoin、Leave、およびDelete要求にそれを提供しなければなりません。
49
49
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 3 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 11 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 12 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 19 . JOIN GROUP REQUEST
図19 グループ要求に参加してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 3 (Join Group).
6[0-7]要求タイプ=3(グループに加わります)。
7[0-15] Setup Checksum. Covers words 6-12.
7[0-15]セットアップチェックサム。 単語6-12をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
9[0-15] Group Address. This is the logical address of the
group that the host wishes to join.
9[0-15]グループアドレス。 これはホストが加わりたがっているグループの論理アドレスです。
10-12 Key. This is the key associated with the group
10-12 主要です。 これはグループに関連しているキーです。
50
50
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
address.
アドレス。
51
51
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 20 . JOIN GROUP REPLY
図20 グループ回答に参加してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
2 = Group joined
9 = Bad key
10 = Group address nonexistent
17 = Insufficient network resources
2 = グループは不十分な悪い主要な10=グループ9=アドレス実在しない17=ネットワーク資源に合流しました。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
52
52
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 4 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 11 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 12 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 21 . LEAVE GROUP REQUEST
図21 グループ要求を残してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 4 (Leave Group).
6[0-7]要求タイプ=4(グループを出ます)。
7[0-15] Setup Checksum. Covers words 6-12.
7[0-15]セットアップチェックサム。 単語6-12をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
9[0-15] Group Address. This is the logical address of the
group that the host wishes to leave.
9[0-15]グループアドレス。 これはホストが出たがっているグループの論理アドレスです。
10-12 Key. This is the key associated with the group
10-12 主要です。 これはグループに関連しているキーです。
53
53
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
address.
アドレス。
54
54
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 22 . LEAVE GROUP REPLY
図22 グループ回答を残してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
3 = Group left
9 = Bad key
10 = Group address nonexistent
11 = Not member of group
17 = Insufficient network resources
3 = グループは不十分なグループ17=ネットワーク資源のどんな実在しない11=メンバーにもグループ悪い主要な9=10=アドレスを残しませんでした。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
55
55
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 1 | 2 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 11 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 12 | キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 23 . DELETE GROUP REQUEST
図23 グループ要求を削除してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 1 (Request).
6[8-15]セットアップタイプ=1(要求します)。
6[0-7] Request Type = 2 (Delete Group).
6[0-7]要求タイプ=2(グループを削除します)。
7[0-15] Setup Checksum. Covers words 6-12.
7[0-15]セットアップチェックサム。 単語6-12をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
9[0-15] Group Address.
9[0-15]グループアドレス。
10-12 Key.
10-12 主要です。
56
56
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0-5 | データグラムメッセージヘッダー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 24 . DELETE GROUP REPLY
図24 グループ回答を削除してください。
0-5 Datagram Message Header.
0-5 データグラムメッセージヘッダー。
6[8-15] Setup Type = 2 (Reply).
6[8-15]セットアップタイプは2(回答)と等しいです。
6[0-7] Reply Code.
6[0-7]回答コード。
1 = Group deleted
8 = Network trouble
9 = Bad key
10 = Group address nonexistent
11 = Not member of group
17 = Insufficient network resources
22 = Reply lost in network
1 = グループは不十分なネットワーク資源22=グループ17の実在しない11=メンバーでない=回答がネットワークで失ったグループ悪い主要な8=ネットワーク問題9=10=アドレスを削除しました。
7[0-15] Setup Checksum. Covers words 6-8.
7[0-15]セットアップチェックサム。 単語6-8をカバーしています。
8[0-15] Request ID.
8[0-15]Request ID。
57
57
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
7 Link Monitoring
7 リンクモニター
While the access link is operating, statistics on traffic
load and error rate are maintained by the host and SIMP. The
host and SIMP must exchange status messages once a second.
Periodic exchange of status messages permits both ends of the
link to monitor flows in both directions. Status messages are
required to support monitoring by the Network Operations Center
(NOC).
アクセスリンクが作動している間、トラヒック負荷と誤り率における統計はホストとSIMPによって維持されます。 ホストとSIMPは1秒に一度ステータスメッセージを交換しなければなりません。 ステータスメッセージの周期的な交換は、リンクの両端が両方の方向の流れをモニターすることを許可します。 ステータスメッセージが、ネットワーク運営センター(NOC)によるモニターをサポートするのに必要です。
The link restart procedure (see Section 8) initializes all
internal SIMP counts and statistics for that link to zero. As
data and control messages are processed, counts are updated to
reflect the total number of messages sent, messages received
correctly, and messages received with different classes of errors
since the last link restart. Whenever a status message arrives,
a snapshot is taken of the local SIMP counts. The local receive
counts, in conjunction with a sent count contained in the
received status message, permits the computation of traffic
statistics in the one second update interval assuming that the
set of counts at the time of the previous monitoring report have
been saved. By including in the status message sent (in the
opposite direction) the receive counts and the received sent
count that was used with them, the transmitting end of the access
link as well as the receiving end can determine the link
performance from sender to receiver. The format of the Status
control message is illustrated in Figure 25.
リンク再開手順(セクション8を見る)はすべての内部のSIMPカウントを初期化します、そして、それのための統計はゼロにリンクされます。 データとコントロールメッセージを処理するとき、送られたメッセージの総数を反映するためにカウントをアップデートしました、そして、メッセージは正しく受信されました、そして、最後のリンク再開以来メッセージは異なったクラスの誤りで受信されました。 ステータスメッセージが到着するときはいつも、地方のSIMPカウントについてスナップを取ります。 地方は受信されたステータスメッセージに含まれた送られたカウントに関連してカウントを受けて、許可証は前のモニタリング報告書時点のカウントのセットが節約されたと仮定するアップデートの2分の1つの間隔でのトラフィック統計の計算です。 カウントとそれらと共に使用された、容認された送られたカウント、アクセスリンクの送信側を犠牲者が送付者から受信機までのリンク性能を決定できるのと同じくらいよく得てください。ステータスメッセージが包含することによって発信する、(逆方向に)Statusコントロールメッセージの形式は図25で例証されます。
58
58
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | MOST RECENT A/R SENT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | STREAM CAPACITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | TIMESTAMP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SBU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | STU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | RNE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | RWE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | BHC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | HEI |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| XXXXX| 0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 最新のA/Rは発信しました。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | ストリーム容量| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4 | タイムスタンプ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5 | SBU| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | スチュー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | RNE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | RWE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | BHC| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | HEI| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 25 . STATUS MESSAGE
図25 ステータスメッセージ
0[15] Message Class = 1 (Control Message).
0[15]メッセージのクラス=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[12-13] Go-Priority.
0[12-13]碁優先権。
0[4-11] Reserved.
予約された0[4-11]。
59
59
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
0[0-3] Control Message Type = 0 (Status).
0[0-3]コントロールメッセージタイプは0(状態)と等しいです。
1[0-15] Header Checksum. Covers words 0-10.
1[0-15]ヘッダーチェックサム。 単語0-10をカバーしています。
2[0-15] Most Recent A/R Sent. This field is a duplicate of the
most recent acceptance/refusal word. It is included in
the periodic status message in case previous
transmissions containing A/R information were lost.
2[0-15]の最新のA/Rは発信しました。 この分野は最新の承認/拒否単語の写しです。 A/R情報を含む前のトランスミッションが失われるといけなかったので、それは周期的なステータスメッセージに含まれています。
3[0-15] Stream Capacity. When sent by the SIMP, this field
indicates how much stream capacity is unused, in units
of data bits per frame. Since available capacity
depends directly on a variety of parameters that can be
selected by the user, the value of this field is the
maximum capacity that could be achieved if existing
host streams were expanded at low reliability. This
field is undefined in messages sent from the host to
the SIMP.
3[0-15]ストリーム容量。 SIMPによって送られると、この分野は、どのくらいのストリーム容量が未使用であるかを示します、1フレームあたりのユニットのデータ・ビットで。 有効な容量が直接ユーザが選択できるさまざまなパラメタによるので、この分野の値は既存のホストストリームが低信頼性で広げられるなら達成できる最大能力です。 この分野はホストからSIMPに送られたメッセージで未定義です。
4[0-15] Timestamp. This field indicates the time that the
status message was generated. When sent by a SIMP, the
time is in units of seconds since the last link
restart. The host should also timestamp its messages
in units of seconds.
4[0-15]タイムスタンプ。 この分野はステータスメッセージが生成された時間を示します。 SIMPによって送られると、ユニットの秒に、最後のリンク再開以来時間があります。 また、ホストがそうするべきである、タイムスタンプ、ユニットの秒のそのメッセージ。
5[0-15] Sent By Us. Count of messages sent by us since the last
link restart (not including this one).
5[0-15]は私たちで発信しました。 最後のリンク再開(これを含んでいない)以来私たちによって送られたメッセージのカウント。
6[0-15] Sent To Us. Count of messages sent to us since the
last link restart. This is the count from word 5 of
the last status message received.
6[0-15]は私たちに発信しました。 最後のリンク再開以来メッセージのカウントは私たちに発信しました。 これは最後の5つのステータスメッセージが受け取った言葉からのカウントです。
7[0-15] Received, No Errors. This is the count of messages
received without errors (since the last link restart)
at the time that the last status message was received.
受け取られていている7[0-15]いいえ誤り。 これは最後のステータスメッセージを受け取ったという当時誤り(最後のリンク再開以来の)なしで受け取られたメッセージのカウントです。
8[0-15] Received With Errors. This is the count of messages
received with errors (since the last link restart) at
the time the last status message was received.
8[0-15]は誤りで受信されました。 これは最後のステータスメッセージを受け取ったとき誤り(最後のリンク再開以来の)で受け取るメッセージのカウントです。
9[0-15] Bad Header Checksums. This is the count of messages
9[0-15]の悪いHeader Checksumsこれはメッセージのカウントです。
60
60
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
received with bad header checksums (since the last link
restart) at the time the last status message was
received.
悪いヘッダーチェックサム(最後のリンク再開以来の)で、最後のステータスメッセージを受け取ったとき、受信しました。
10[0-15] Hardware Error Indication. This is the count of
messages received with hardware CRC errors or hardware
interface error indications (since the last link
restart) at the time the last status message was
received.
10[0-15]ハードウェア誤り表示。 これは最後のステータスメッセージを受け取ったときハードウェアCRC誤りかハードウェア・インタフェース誤り指摘(最後のリンク再開以来の)で受け取るメッセージのカウントです。
61
61
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
8 Initialization
8 初期設定
The Host Access Protocol uses a number of state variables
that must be initialized in order to function properly. These
variables are associated with the send and receive message
numbers used by the acceptance/refusal mechanism and the
statistics maintained to support link monitoring. Link
initialization should be carried out when a machine is initially
powered up, when it does a system restart, when the ON state (see
below) times out, when a loopback condition times out (see
Section 9), or whenever the link transitions from non-operational
to operational status.
Host Accessプロトコルは適切に機能するように初期化しなければならない多くの州の変数を使用します。 これらの変数が関連している、承認/拒否メカニズムによって使用されるメッセージ番号とリンクモニターをサポートするために維持された統計を、送って、受け取ってください。 マシンが初めは上に動かされるとき、リンク初期化が行われるべきです、システムリスタートをすると、ループバック状態回のアウト(セクション9を見る)であるときに、ONが外に回を述べるか(以下を見ます)、リンクが非操作上から操作上の状態に移行するときはいつも。
Initialization is accomplished by the exchange of Restart
Request (RR) and Restart Complete (RC) messages between a host
and a SIMP. The state diagram in Figure 26 shows the sequence of
events during initialization. Both SIMP and host must implement
this state diagram if deadlocks and oscillations are to be
avoided. This particular initialization sequence requires both
sides to send and receive the Restart Complete message. Because
this message is a reply (to a Restart Request or Restart
Complete), its receipt guarantees that the physical link is
operating in both directions. Five states are identified in the
state diagram:
初期設定はホストとSIMPの間のRestart Request(RR)とRestart Complete(RC)メッセージの交換で実行されます。 図26の州のダイヤグラムは初期化の間、イベントの系列を示しています。 SIMPとホストの両方が行き詰まりと振動が避けられることであるならこの州のダイヤグラムを実装しなければなりません。 この特定の初期化系列は、Restart Completeメッセージを送って、受け取るために両側を必要とします。 このメッセージが回答(Restart RequestかRestart Completeへの)であるので、領収書は、物理的なリンクが両方の方向に作動しているのを保証します。 5つの州が州のダイヤグラムで特定されます:
OFF Entered upon recognition of a requirement to
restart. The device can recognize this
requirement itself or be forced to restart by
receipt of an RR message from the other end while
in the ON state.
再開するという要件の認識でのOFF Entered。 ON状態にある間、デバイスは、この要件自体を認めるか、またはもう一方の端からのRRメッセージの領収書でやむを得ず再開できます。
INIT Local state variables have been initialized and
local counters have been zeroed but no restart
control messages have yet been sent or received.
INIT Local州の変数が初期化されて、地方のカウンタのゼロが合わせられましたが、まだ再開コントロールメッセージを全く送りもしませんし、受け取ってもいません。
RR-SNT A request to reinitialize (RR) has been sent to
the other end but no restart control messages have
yet been received.
再初期化するというRR-シンニッタンのA要求(RR)をもう一方の端に送りましたが、まだ再開コントロールメッセージを全く受け取っていません。
RC-SNT A reply (RC) has been sent to the other end in
response to a received reinitialization request
受信された再初期化要求に対応してRC-シンニッタンのA回答(RC)をもう一方の端に送りました。
62
62
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
(RR). The device is waiting for a reply (RC).
(RR。) デバイスは回答(RC)を待っています。
ON Reply (RC) messages have been both sent and
received. Data and control messages can now be
exchanged between the SIMP and host.
ON Reply(RC)メッセージを送って、受け取りました。 現在、SIMPとホストの間でデータとコントロールメッセージを交換できます。
All states have 10-second timeouts (not illustrated) which
return the protocol to the OFF state. The occurrence of any
events other than those indicated in the diagram are ignored.
すべての州には、OFF状態にプロトコルを返す10秒のタイムアウト(例証されない)があります。 ダイヤグラムで、無視されますそれら以外のどんなイベントの発生も、示した。
The Restart Request control message illustrated in Figure 27
is sent by either a host or a SIMP when it wishes to restart a
link. The Restart Request causes all the monitoring statistics
to be reset to zero and stops all traffic on the link in both
directions. The Restart Complete message illustrated in Figure
28 is sent in response to a received Restart Request or Restart
Complete to complete link initialization. The Restart Complete
carries a field used by the host to enable or disable the
acceptance/refusal mechanism for the link being restarted (see
Section 5). After the Restart Complete is processed, traffic may
flow on the link.
それがリンクを再開したがっているとき、図27で例証されたRestart RequestコントロールメッセージはホストかSIMPのどちらかによって送られます。 Restart Requestはすべてのモニターしている統計がゼロにリセットされることを引き起こして、リンクにおけるすべての通行を両方の方向に止めます。 リンク初期化を終了するために容認されたRestart RequestかRestart Completeに対応して図28で例証されたRestart Completeメッセージを送ります。 Restart Completeは再開されるリンクへの承認/拒否メカニズムを可能にするか、または無効にするのにホストによって使用された野原を運びます(セクション5を見てください)。 Restart Completeが処理された後に、トラフィックはリンクの上に流れるかもしれません。
63
63
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
-------
Any Timeout or ----->| OFF |<-----------------------------
Device Down ------- |
| |
| Device Up |
| Initialize Variables |
| |
V |
--------- |
| INIT | |
--------- |
| | |
Rcv RR | | Snd RR |
Snd RC | | |
| | |
-------------- -------------- |
| | |
| | |
V Rcv RR V |
---------- Snd RC ---------- |
| RC-SNT |<--------------------| RR-SNT | |
---------- ---------- |
| | |
Rcv RC | | Rcv RC |
| | Snd RC |
V V |
------------------------------- |
| |
| |
V |
------- |
Rcv Any ------>| ON |------------------------------
Other | ------- Rcv RR
----------|
------- またはどんなタイムアウト、も。----->| オフ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- デバイスはダウンします。------- | | | | デバイスは上昇します。| | 変数を初期化してください。| | | V| --------- | | イニット| | --------- | | | | Rcv RR| | Snd RR| Snd RC| | | | | | -------------- -------------- | | | | | | | V Rcv RR V| ---------- Snd RC---------- | | RC-シンニッタン| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| RR-シンニッタン| | ---------- ---------- | | | | Rcv RC| | Rcv RC| | | Snd RC| V V| ------------------------------- | | | | | V| ------- | Rcvいずれも------>| オン|------------------------------ 他| ------- Rcv RR----------|
Figure 26 . HAP LINK RESTART STATE DIAGRAM
図26機会リンク再開州のダイヤグラム
64
64
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXXXX | REASON | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS / SITE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb| XXXXXXX| 理由| 3 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | ホスト・アドレス/サイト番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | リンク番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 27 . RESTART REQUEST
図27再開要求
0[15] Message Type = 1 (Control Message).
0[15]メッセージタイプ=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[8-13] Reserved.
予約された0[8-13]。
0[4-7] Reason. This field is used by the SIMP or the host to
indicate the reason for the restart as follows:
0[4-7]理由。 この分野は以下の再開の理由を示すのにSIMPかホストによって使用されます:
0 = power up
1 = system restart
2 = link restart
3 = link timeout
4 = loopback timeout
0 = 1つのパワーアップ=システムリスタート2=リンク再開3がループバックリンクタイムアウト4=タイムアウトと等しいです。
0[0-3] Control Message Type = 3 (Restart Request).
0[0-3]コントロールメッセージタイプ=3(再開要求)。
1[0-15] Header Checksum. Covers words 0-3.
1[0-15]ヘッダーチェックサム。 単語0-3をカバーしています。
2[0-15] Host Address / Site Number. The host inserts its
satellite network address in this field. The SIMP
validates that the host address is correct for the port
2[0-15]ホスト・アドレス/サイト番号。 ホストは衛星ネットワーク・アドレスをこの分野に挿入します。 SIMPが有効にする、ポートに、ホスト・アドレスは正しいです。
65
65
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
being used. When sent by the SIMP, this field will
contain the SIMP site number.
使用されること。 SIMPによって送られると、この分野はSIMPサイト番号を含むでしょう。
3[0-15] Link Number. This field contains the sender's
identification of the physical link being used. This
information is used to identify the link when reporting
errors to the Network Operations Center (NOC).
3[0-15]リンク番号。 この分野は送付者の使用される物理的なリンクの識別を含んでいます。 この情報は、ネットワーク運営センター(NOC)に誤りを報告するとき、リンクを特定するのに使用されます。
66
66
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXXX |AR| 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS / SITE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb| XXXXXX|アルゴン| 4 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | ホスト・アドレス/サイト番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | リンク番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 28 . RESTART COMPLETE
図28 完全な状態で、再開してください。
0[15] Message Type = 1 (Control Message).
0[15]メッセージタイプ=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[5-13] Reserved.
予約された0[5-13]。
0[4] Acceptance/Refusal Control. This bit is used by the
host to enable or disable the acceptance/refusal
mechanism for all traffic on the link.
0[4]承認/拒否コントロール。 このビットは、リンクの上のすべてのトラフィックのために承認/拒否メカニズムを可能にするか、または無効にするのにホストによって使用されます。
0 = Disable acceptance/refusal
1 = Enable acceptance/refusal
=が承認/拒否1=を無効にする0は承認/拒否を可能にします。
0[0-3] Control Message Type = 4 (Restart Complete).
0[0-3]コントロールメッセージタイプ=4(完全な状態で、再開します)。
1[0-15] Header Checksum. Covers words 0-3.
1[0-15]ヘッダーチェックサム。 単語0-3をカバーしています。
2[0-15] Host Address / Site Number.
2[0-15]ホスト・アドレス/サイト番号。
3[0-15] Link Number.
3[0-15]リンク番号。
67
67
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
9 Loopback Control
9 ループバックコントロール
The Host Access Protocol provides a Loopback Request control
message which can be used by a SIMP or a host to request the
remote loopback of its HAP messages. Such requests are usually
the result of operator intervention for purposes of system fault
diagnosis. For clarity in the following discussion, the unit
(SIMP or host) requesting the remote loopback is referred to as
the "transmitter" and the unit implementing (or rejecting) the
loopback is referred to as the "receiver". The format of a
Loopback Request control message is illustrated in Figure 29.
Host AccessプロトコルはSIMPかホストがHAPメッセージのリモートループバックを要求するのに使用できるLoopback Requestコントロールメッセージを提供します。 通常、そのような要求はシステム欠点診断の目的のためのオペレータ介入の結果です。 以下の議論における明快において、リモートループバックを要求するユニット(SIMPかホスト)は「送信機」と呼ばれます、そして、ループバックを実装する(または、拒絶)ユニットは「受信機」と呼ばれます。 Loopback Requestコントロールメッセージの形式は図29で例証されます。
When a transmitter is remotely looped, all of its HAP
messages will be returned, unmodified, over the access link by
the receiver. The receiver will not send any of its own messages
to the transmitter while it is implementing the loop. SIMP-
generated messages are distinguished from host-generated messages
by means of the Loopback Bit that is in every HAP message header.
送信機を離れて輪にするとき、HAPメッセージのすべてを返すでしょう、変更されていません、受信機によるアクセスリンクの上に。受信機で、輪を実装している間、それ自身のメッセージのいずれも送信機に行かないでしょう。 メッセージであると生成されたSIMPはすべてのHAPメッセージヘッダーにあるLoopback Bitによってホストが発生しているメッセージと区別されます。
Two types of remote loopback may be requested: loopback at
the receiver's interface hardware and loopback at the receiver's
I/O driver software. HAP does not specify the manner in which
the receiver should implement these loops; additionally, some
receivers may use interface hardware which is incapable of
looping the transmitter's messages, only allowing the receiver to
provide software loops. A receiver may not be able to interpret
the transmitter's messages as it is looping them back. If such
interpretation is possible, however, the receiver will not act on
any of the transmitter's messages other than requests to
reinitialize the SIMP-host link (Restart Request (RR) control
messages; see Section 8.)
2つのタイプのリモートループバックは要求されているかもしれません: 受信機のインタフェースハードウェアのループバックと受信機の入出力ドライバソフトウェアにおけるループバック。 HAPは受信機がこれらの輪を実装するはずである方法を指定しません。 さらに、いくつかの受信機が送信機のメッセージを輪にすることができないインタフェースハードウェアを使用するかもしれません、受信機がソフトウェア輪を提供するのを許容するだけであって。 それらを輪にし返しているとき、受信機は送信機のメッセージを解釈できないかもしれません。 しかしながら、そのような解釈が受信機がSIMP-ホストリンクを再初期化するという要求以外の送信機のメッセージのいずれにも影響しないのが可能であるなら(Request(RR)コントロールメッセージを再開してください; セクション8を見てください。)
When a receiver initiates a loopback condition in response
to a loopback request, it makes an implicit promise to maintain
the condition for the duration specified in the Loopback Request
message. However, if an unanticipated condition such as a system
restart occurs in either the transmitter or the receiver, the
affected unit will try to reinitialize the SIMP-host link by
sending an RR message to the other unit. If the RR message is
recognized by the other unit a link initialization sequence can
be completed. This will restore the link to an unlooped
受信機がループバック要求に対応してループバック状態を開始するとき、それはLoopback Requestメッセージで指定された持続時間のための状態を維持する暗黙の約束をします。 しかしながら、システムリスタートなどの思いがけない状態が送信機か受信機のどちらかに現れると、影響を受けるユニットは、RRメッセージをもう片方のユニットに送ることによって、SIMP-ホストリンクを再初期化しようとするでしょう。 RRメッセージがもう片方のユニットによって認識されるなら、リンク初期化系列は完了できます。 これがリンクを返す、非輪にする。
68
68
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
condition even if the specified loop duration has not yet
expired. If a receiver cannot interpret a transmitter's RR
messages, and in the absence of operator intervention at the
receiver, the loop will remain in place for its duration.
指定された輪の持続時間がまだ期限が切れないでも、条件とします。 受信機が送信機のRRメッセージを解釈できないで、輪が受信機のオペレータ介入がないとき持続時間のために適所に残るなら。
HAP does not specify the characteristics of any loopback
conditions that may be locally implemented by a given unit. An
example of such a condition is that obtained when a SIMP commands
its host interface to loop back its own messages. If such local
loop conditions also cause the reflection of messages received
from the remote unit, the remote unit will detect the condition
via the HAP header Loopback Bit.
HAPは与えられたユニットによって局所的に満たされるどんなループバック条件の特性も指定しません。 SIMPが、ホスト・インターフェースがそれ自身のメッセージを輪にし返すと命令するとき、そのような状態の例はそんなに得られます。 また、そのような回線折返し状態がリモート単位から受け取られたメッセージの反映を引き起こすと、リモート単位はHAPヘッダーLoopback Bitを通して状態を検出するでしょう。
A specific sequence must be followed for setting up a remote
loopback condition. It begins after the HAP link has been
initialized and a decision is made to request a remote loop. The
transmitter then sends a Loopback Request message to the receiver
and waits for either (1) a 10-second timer to expire, (2) a
"Can't implement loop" Unnumbered Response message from the
receiver, or (3) one of its own reflected messages. If event (1)
or (2) occurs the request has failed and the transmitter may, at
its option, try again with a new Loopback Request message. If
event (3) occurs, the remote loopback condition has been
established. While waiting for one of these events, messages
from the receiver are processed normally. Note that RR messages
arriving from the receiver during this time will terminate the
loopback request.
リモートループバック状態をセットアップするために特定の順序に従わなければなりません。 HAPリンクを初期化して、リモート折返しを要求するのを決定をした後にそれは始まります。 送信機は、次に、Loopback Requestメッセージを受信機に送って、(2) 受信機からの(1) 吐き出す10秒のタイマ、「道具は輪にすることができない」Unnumbered Responseメッセージか(3) それ自身の反射したメッセージの1つのどちらかを待っています。 イベント(1)か(2)が起こるなら、要求は失敗しました、そして、送信機は新しいLoopback Requestメッセージで任意に再試行するかもしれません。 イベント(3)が起こるなら、リモートループバック状態は確立されました。 これらのイベントの1つを待っている間、通常、受信機からのメッセージは処理されます。 この間に受信機から到着するRRメッセージがループバック要求を終えることに注意してください。
When a receiver gets a Loopback Request message, it either
implements the requested loop for the specified duration, or
returns a "Can't implement loop" response without changing the
state of the link. The latter response would be returned, for
example, if a receiver is incapable of implementing a requested
hardware loop. A receiver should initiate reinitialization of
the link with an RR message(s) whenever a loopback condition
times out.
受信機がLoopback Requestメッセージを得るとき、リンクの状態を変えないで、それは、指定された持続時間のために要求された輪を実装するか、または「道具は輪にすることができない」という応答を返します。 例えば、受信機が要求されたハードウェア輪を実装することができないなら、後者の応答を返すでしょう。 ループバックが外で回を条件とさせるときはいつも、受信機はRRメッセージとのリンクの再初期化を開始するはずです。
There is one asymmetry that is required in the above
sequence to resolve the (unlikely) case where both SIMP and host
request a remote loopback at the same time. If a SIMP receives a
Loopback Request message from a host while it is itself waiting
(ありそうもない)のケースを決議するのに上の系列で必要である1つの非対称がSIMPとホストの両方が同時にリモートループバックを要求するところにあります。 SIMPが待っている間、ホストからLoopback Requestメッセージを受け取るなら
69
69
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
for an event of type (1)-(3), it will return a "Can't implement
loop" response to the host and will continue to wait. A host in
the converse situation, however, will abort its loopback request
and will instead act on the SIMP's loopback request.
タイプ(1)のイベント--(3) それは、ホストへの「道具は輪にすることができない」という応答を返して、待ち続けるでしょう。 逆状況におけるホストは、しかしながら、ループバック要求を中止して、代わりにSIMPのループバック要求に影響するでしょう。
70
70
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | LOOP TYPE | 8 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | LOOP DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| XXXXX| 輪のタイプ| 8 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 輪の持続時間| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 29 . LOOPBACK REQUEST
図29ループバック要求
0[15] Message Type = 1 (Control Message).
0[15]メッセージタイプ=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[12-13] Go-Priority.
0[12-13]碁優先権。
0[8-11] Reserved.
予約された0[8-11]。
0[4-7] Loop Type. This field indicates the type of loop that
is being requested as follows:
0[4-7]輪のタイプ。 この分野は以下の通り要求されている輪のタイプを示します:
0 = Undefined
1 = Loop at interface (hardware loop)
2 = Loop at driver (software loop)
3-15 = Undefined
0 = 未定義の1はドライバー(ソフトウェア輪)3-15=のインタフェース(ハードウェア輪)2=輪で輪と未定義の状態で等しいです。
0[0-3] Control Message Type = 8 (Loopback Request).
0[0-3]コントロールメッセージタイプ=8(ループバック要求)。
1[0-15] Header Checksum. Covers words 0-2.
1[0-15]ヘッダーチェックサム。 単語0-2をカバーしています。
2[0-15] Loop Duration. The transmitter of a Loopback
Request message uses this field to specify the number
of seconds that the loop is to be maintained by the
receiver.
2[0-15]輪の持続時間。 Loopback Requestメッセージの送信機は、受信機によって維持される輪がことである秒の数を指定するのにこの分野を使用します。
71
71
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
10 Other Control Messages
10 他のコントロールメッセージ
Before a SIMP or a host voluntarily disables a SIMP-host
link, it should send at least one Link Going Down control message
over that link. The format of such a message is illustrated in
Figure 30. HAP does not define the action(s) that should be
taken by a SIMP or a host when such a message is received;
informing the Network Operations Center (NOC) and/or the network
users of the impending event is a typical course of action. Note
that each Link Going Down message only pertains to the SIMP-host
link that it is sent over; if a host and a SIMP are connected by
multiple links, these links may be selectively disabled.
SIMPかホストが自発的にSIMP-ホストリンクを無効にする前に、それは少なくとも1つのLink Going Downコントロールメッセージをそのリンクの上に送るべきです。 そのようなメッセージの形式は図30で例証されます。 HAPはそのようなメッセージが受信されているときSIMPかホストによって取られるべきである行動を定義しません。 差し迫っているイベントについてネットワーク運営センター(NOC)、そして/または、ネットワーク利用者に知らせるのは、典型的な行動です。 それぞれのLink Going Downメッセージがそれが送られるSIMP-ホストリンクに関係するだけであることに注意してください。 ホストとSIMPが複数のリンクによって接されるなら、これらのリンクは選択的に無効にされるかもしれません。
A No Operation (NOP) control message may be sent at any time
by a SIMP or a host. The format of such a message is illustrated
in Figure 31. A NOP message contains up to 32 words of arbitrary
data which are undefined by HAP. NOP messages may be required in
some cases to clear the state of the SIMP-host link hardware.
いいえOperation(NOP)コントロールメッセージはいつでも、SIMPかホストによって送られるかもしれません。 そのようなメッセージの形式は図31で例証されます。 NOPメッセージはHAPで未定義の任意のデータの最大32の単語を含んでいます。 NOPメッセージが、いくつかの場合、SIMP-ホストリンクハードウェアを状態から取り除くのに必要であるかもしれません。
72
72
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | REASON | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | TIME UNTIL DOWN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | DOWN DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| XXXXX| 理由| 7 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 下にへの時間| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 持続時間の下側に| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 30 . LINK GOING DOWN
図30 落ちて、リンクしてください。
0[15] Message Type = 1 (Control Message).
0[15]メッセージタイプ=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[12-13] Go-Priority.
0[12-13]碁優先権。
0[8-11] Reserved.
予約された0[8-11]。
0[4-7] Reason. This field is used by the SIMP or the host
to indicate the reason for disabling this SIMP-host
link as follows:
0[4-7]理由。 この分野は以下のこのSIMP-ホストリンクを無効にする理由を示すのにSIMPかホストによって使用されます:
0 = NOT going down: Cancel previous Link
Going Down message
1 = Unspecified reason
2 = Scheduled PM
3 = Scheduled hardware work
4 = Scheduled software work
5 = Emergency restart
6 = Power outage
7 = Software breakpoint
8 = Hardware failure
0は落ちないのと等しいです: 予定されているハードウェア仕事4予定されている2=PM3==がハードウェアのソフトウェア仕事5=非常時再開6=パワー供給停止7=ソフトウェア区切り点8=故障の計画をした不特定の前のLink Going Downメッセージ1=理由を取り消してください。
73
73
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
9 = Not scheduled up
10 = Last warning: The SIMP or host is disabling
the link in 10 seconds
11-15 = Undefined
9 10に予定されていなかった=は最後の警告と等しいです: SIMPかホストが10秒以降、11-15 =未定義の状態でリンクを無効にします。
0[0-3] Control Message Type = 7 (Link Going Down).
0[0-3]コントロールメッセージタイプ=7(落ちて、リンクします)。
1[0-15] Header Checksum. Covers words 0-3.
1[0-15]ヘッダーチェックサム。 単語0-3をカバーしています。
2[0-15] Time Until Down. This field specifies the amount of
time remaining until the SIMP or host disables the
link (in minutes). An entry of zero indicates that
there is less than a minute remaining.
下にへの2[0-15]時間。 この分野は、SIMPかホストがリンク(数分間の)を無効にするまで残りながら、時間を指定します。 ゼロのエントリーは、残っている1分未満があるのを示します。
3[0-15] Down Duration. This field specifies the amount of
time that the SIMP-host link will be down (in
minutes). An entry of zero indicates that the down
duration will be less than a minute. An entry of -1
(all bits set) indicates an indefinite down duration.
持続時間の下側への3[0-15]。 この分野はSIMP-ホストリンクが下がる(数分間の)時間を指定します。 ゼロのエントリーは、下に持続時間が1分未満になるのを示します。 -1(すべてのビットがセットした)のエントリーは無期下に持続時間を示します。
74
74
RFC 907 Host Access Protocol
July 1984 Specification
RFC907ホストアクセス・プロトコル1984年7月の仕様
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXX | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2-N | ARBITRARY DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb| XXXXX| 6 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2-N| 任意のデータ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 31 . NO OPERATION (NOP)
図31 操作がありません。(NOP)
0[15] Message Type = 1 (Control Message).
0[15]メッセージタイプ=1(コントロールメッセージ)。
0[14] Loopback Bit.
0[14]ループバックビット。
0[4-13] Reserved.
予約された0[4-13]。
0[0-3] Control Message Type = 6 (NOP).
0[0-3]コントロールメッセージタイプ=6(NOP)。
1[0-15] Header Checksum. Covers words 0-N.
1[0-15]ヘッダーチェックサム。 カバーは0-Nを言い表します。
2-N Arbitrary Data. Up to 32 words of data may be sent.
The data are undefined by HAP.
2-Nの任意のデータ。 データに関する最大32の知らせを送るかもしれません。 データはHAPで未定義です。
75
75
一覧
スポンサーリンク
