RFC891 日本語訳
0891 DCN Local-Network Protocols. D.L. Mills. December 1983. (Format: TXT=65340 bytes) (Also STD0044) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D.L. Mills Request for Comments: 891 December 1983
L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 891 1983年12月
DCN Local-Network Protocols
DCN企業内情報通信網プロトコル
This RFC is a description of the protocol used in the DCN local networks to maintain connectivity, routing, and timekeeping information. These procedures may be of interest to designers and implementers of other networks.
このRFCは接続性、ルーティング、および時間保持情報を保守するのにDCN企業内情報通信網に使用されるプロトコルの記述です。 これらの手順は他のネットワークのデザイナーとimplementersに興味があるかもしれません。
1. Introduction
1. 序論
This document describes the local-net architecture and protocols
of the Distributed Computer Network (DCN), a family of local nets
based on Internet technology and an implementation of PDP11-based
software called the Fuzzball. DCN local nets have been in operation
for about three years and now include clones in the USA, UK, Norway
and West Germany. They typically include a number of PDP11 or LSI-11
Fuzzballs, one of which is elected a gateway, and often include other
Internet-compatible hosts as well.
このドキュメントはDistributedコンピュータNetwork(DCN)の地方にネットのアーキテクチャとプロトコル、インターネット技術に基づくローカルのネットのファミリー、およびFuzzballと呼ばれるPDP11ベースのソフトウェアの実装について説明します。 DCNのローカルのネットは、かれこれ3年の間稼働中であり、現在、米国、イギリス、ノルウェー、および西ドイツにクローンを含んでいます。 彼らは、多くのPDP11かLSI-11Fuzzballsを通常含んでいて、しばしばまた、他のインターネットコンパチブルホストを含んでいます。その1つはゲートウェイに選出されます。
The DCN local-net protocols are intended to provide connectivity,
routing and timekeeping functions for a set of randomly connected
personal computers and service hosts. The design philosophy guiding
the Fuzzball implementation is to incorporate complete functionality
in every host, which can serve as a packet switch, gateway and service
host all at the same time. When a set of Fuzzballs are connected
together using a haphazard collection of serial, parallel and
contention-bus interfaces, they organize themselves into a network
with routing based on minimum delay.
DCNの地方にネットのプロトコルが1セットの手当たりしだいに接続されたパーソナルコンピュータとサービス・ホストに接続性、ルーティング、および時間保持機能を供給することを意図します。 Fuzzball実装を誘導する設計理念は完全な機能性をすべてのホストに取り入れることです。(パケット交換機、ゲートウェイ、およびサービスが同時にすべてを接待するとき、そのホストは、勤めることができます)。 Fuzzballsの1セットがシリーズ、平行線、および主張バスインタフェースの行き当たりばったりの収集を使用することで一緒に接続されるとき、それらは最小の遅れに基づくルーティングでネットワークに自分たちを組織化します。
The purpose of this document is to describe the local-net
protocols used by the DCN to maintain connectivity, routing and
timekeeping functions. The document is an extensive revision and
expansion of Section 4.2 of [1] and is divided into two parts, the
first of which is an informal description of the architecture,
together with explanatory remarks. The second part consists of a
semi-formal specification of the entities and protocols used to
determine connectivity, establish routing and maintain clock
synchronization and is designed to aid in the implementation of cohort
systems. The link-level coding is described in the appendix.
このドキュメントの目的は接続性、ルーティング、および時間保持機能を維持するのにDCNによって使用された地方にネットのプロトコルについて説明することです。 ドキュメントは、[1]のセクション4.2の大規模な改正と拡張であり、2つの部品に分割されます、説明している所見と共に。その1番目はアーキテクチャの非公式の記述です。 第二部は、接続性を決定して、ルーティングを確立して、時計同期を維持するのに使用される実体とプロトコルに関する準形式仕様から成って、歩兵隊システムの実装で支援するように設計されています。リンク・レベルコード化は付録で説明されます。
2. Narrative Description
2. 物語の記述
The DCN architecture is designed for local nets of up to 256
hosts and gateways using the Internet Protocol (IP) and client
protocols. It provides adaptive routing and clock synchronization
functions in an arbitrary topology including point-to-point links and
multipoint bus systems. It is intended for use in connecting personal
computers to each other and to service machines, gateways and other
hosts of the Internet community. However, it is not intended for use
in large, complex networks and does not support the sophisticated
routing and control algorithms of, for example, the ARPANET.
DCNアーキテクチャは、最大256ホストと門のローカルのネットのためにインターネットプロトコル(IP)とクライアントプロトコルを使用することで設計されています。 ポイントツーポイント接続と多点バス・システムを含んでいて、それは任意のトポロジーで最適経路指定と時計同期に機能を提供します。互いと、そして、インターネットコミュニティのサービスマシンと、ゲートウェイと他のホストにパーソナルコンピュータを接続することにおける使用のために、意図します。 しかしながら、それは、大きくて、複雑なネットワークにおける使用のために意図しないで、また例えば、アルパネットの高度なルーティングとコントロールアルゴリズムをサポートしません。
A brief description of the process and addressing structure used
in the DCN may be useful in the following. A DCN physical host is a
PDP11-compatible processor which supports a number of cooperating
sequential processes, each of
DCN Local-Network Protocols Page 2
D.L. Mills
DCNで使用されるプロセスとアドレシング構造の簡単な説明は以下で役に立つかもしれません。 2ページ DCN物理ホストは多くの協力が連続したプロセスであるとサポートするPDP11コンパチブルプロセッサであり、それぞれのDCN Local-ネットワークプロトコルはD.L.ミルズです。
which is given a unique 8-bit identifier called its port ID. Every DCN physical host contains one or more internet processes, each of which supports a virtual host given a unique 8-bit identifier called its host ID.
ユニークな8ビットの識別子をどれに与えるかは、ポートをIDと呼びました。 すべてのDCN物理ホストが1つ以上のインターネットプロセスを含みます。ホストIDと呼ばれるユニークな8ビットの識別子を考えて、それはそれぞれ事実上のホストをサポートします。
Each virtual host can support multiple internet protocols,
connections and, in addition, a virtual clock. Each physical host
contains a physical clock which can operate at an arbitrary rate and,
in addition, a 32-bit logical clock which operates at 1000 Hz and is
assumed to be reset each day at 0000 hours UT. Not all physical hosts
implement the full 32-bit precision; however, in such cases the
resolution of the logical clock may be somewhat less.
それぞれの事実上のホストは、複数のインターネットがプロトコルと、接続とさらに、仮想の時計であるとサポートすることができます。 各物理ホストは0000時間のユタに任意のレートで作動できる物理的な時計とさらに、1000Hzで作動して、毎日リセットされると思われる、32ビットの論理的な時計を保管しています。 すべての物理ホストが完全な32ビットの精度を実装するというわけではありません。 しかしながら、そのような場合論理的な時計の解決はいくらか少ないかもしれません。
There is a one-to-one correspondence between Internet addresses
and host IDs. The host ID is formed from a specified octet of the
Internet address to which is added a specified offset. The octet
number and offset are selected at configuration time and must be the
same for all DCN hosts sharing the local net. For class-B and class-C
nets normally the fourth octet is used in this way for routing within
the local net. In the case of class-B nets, the third octet is
considered part of the net number by DCN hosts; therefore, this octet
can be used for routing between DCN local nets. For class-A nets
normally the third octet (ARPANET logical-host field) is used for
routing where necessary.
インターネット・アドレスとホストIDとの1〜1つの通信があります。 ホストIDは形成されて、インターネット・アドレスの指定された八重奏からどれが加えられるかまでaが指定したかに相殺されたということです。 八重奏番号とオフセットは、構成時に選択されて、ローカルのネットを共有しているすべてのDCNホストにとって、同じであるに違いありません。 クラスBとクラスCネットにおいて、通常、4番目の八重奏はルーティングにローカルのネットの中でこのように使用されます。 クラスBネットの場合では、3番目の八重奏はネットの数の一部であるとDCNホストによって考えられます。 したがって、DCNのローカルのネットの間のルーティングにこの八重奏を使用できます。 クラスAネットにおいて、通常、3番目の八重奏(アルパネット論理的なホスト分野)はルーティングに必要であるところで使用されます。
Each DCN physical host is identified by a host ID for the purpose
of detecting loops in routing updates, which establish the
minimum-delay paths between the virtual hosts. By convention, the
physical host ID is assigned as the host ID of one of its virtual
hosts. A link to a neighbor net is associated with a special virtual
host, called a gateway, which is assigned a unique host ID.
それぞれのDCN物理ホストは事実上のホストの間の最小の遅れ経路を確立するルーティングアップデートで輪を検出する目的のためにホストIDによって特定されます。 コンベンションによって、物理ホストIDは事実上のホストのひとりのホストIDとして割り当てられます。 隣人ネットへのリンクはユニークなホストIDが割り当てられるゲートウェイと呼ばれる特別な事実上のホストに関連しています。
The links connecting the various physical hosts together and to
foreign nets can be distributed in arbitrary ways, so long as the net
remains fully connected. If full connectivity is lost, due to a link
or host fault, the virtual hosts in each of the surviving segments can
continue to operate with each other and, once connectivity is
restored, with all of them.
任意の方法で一緒に、そして、外国ネットに様々な物理ホストを接続するリンクは分配できます、ネットの残りが完全に接続した限り。 完全な接続性がリンクかホスト欠点のため失われているなら、それぞれの生き残っているセグメントの事実上のホストは、互いと共に作動し続けることができます、そして、一度、接続性は回復します、それらのすべてで。
Datagram routing is determined entirely by internet address -
there is no local leader as in the ARPANET. Each physical host
contains two tables, the Host Table, which is used to determine the
outgoing link to each other local-net host, and the Net Table, which
is used to determine the outgoing host (gateway) to each other net.
The Host Table contains estimates of roundtrip delay and logical-clock
offset for all virtual hosts in the net and is indexed by host ID.
For the purpose of computing these estimates the delay and offset of
each virtual host relative to the physical host in which it resides is
assumed zero. The single exception to this is a special virtual host
associated with an NBS radio time-code receiver, where the offset is
computed relative to the broadcast time.
データグラムルーティングは完全にインターネットアドレスで決定します--どんな地元のリーダーもアルパネットのようにいません。 各物理ホストは2個のテーブルとHost TableとネットTableを含みます。(Host Tableは、辞職しているリンク互いにローカルのネットのホストを決定するのに使用されます)。(Tableは、ネットで互いの辞職しているホスト(ゲートウェイ)を決定するのに使用されます)。 Host Tableはネットに往復の遅れとすべての事実上のホストのために相殺された論理的な時計の見積りを含んでいて、ホストIDによって索引をつけられます。 これらの見積りを計算する目的のために、それが住んでいる物理ホストに比例したそれぞれの事実上のホストの遅れとオフセットはゼロであると思われます。 これへのただ一つの例外はオフセットが放送時間に比例して計算されるNBSラジオ時間コード受信機に関連している特別な事実上のホストです。
The Net Table contains an entry for every neighbor net that may
be connected to the local net and, in addition, certain other nets
that are not
DCN Local-Network Protocols Page 3
D.L. Mills
ネットTableはローカルのネットに関連づけられるかもしれないあらゆる隣人ネットとさらに、3ページ DCN Local-ネットワークプロトコルD.L.ミルズでない他のあるネットのためのエントリーを含んでいます。
neighbors. Each entry contains the net number, as well as the host ID of the local-net gateway to that net. The routing function simply looks up the net number in the Net Table, finds the host ID of the gateway and retrieves the port ID of the net-output process from the Host Table. Other information is included in the Host Table and Net Table as described below.
隣人。 各エントリーはネットの数、およびそのネットへの地方にネットのゲートウェイのホストIDを含んでいます。 経路選択機能は、Host Tableから単にネットTableのネットの数を見上げて、ホストがゲートウェイのIDであることがわかって、純生産高プロセスのポートIDを検索します。 他の情報は以下で説明されるようにHost TableとネットTableに含まれています。
The delay and offset estimates are updated by HELLO messages
exchanged on the links connecting physical-host neighbors. The HELLO
messages are exchanged frequently, but not so as to materially degrade
the throughput of the link for ordinary data messages. A HELLO
message contains a copy of the delay and offset information from the
Host Table of the sender, as well as information to compute the
roundtrip delay and logical-clock offset of the receiver relative to
the sender.
物理ホストの隣人に接するリンクで交換されたHELLOメッセージは遅れとオフセット見積りをアップデートします。 普通のデータメッセージのために物質的にリンクに関するスループットを下げないように頻繁にHELLOメッセージを交換します。 HELLOメッセージは、情報と同様に送付者に比例して受信機の往復の遅れと論理的な時計オフセットを計算するために遅れのコピーを含んで、送付者のHost Tableからの情報を相殺しました。
The routing algorithm is similar to that (formerly) used in the
ARPANET and other places in that the roundtrip (biased) delay estimate
calculated to a neighbor is added to each of the delay estimates given
in its HELLO message and compared with the corresponding delay
estimates in the Host Table. If a delay computed in this way is less
than the delay already in the Host Table, the routing to the
corresponding virtual host is changed accordingly. The detailed
operation of this algorithm, which includes provisions for host
up-down logic and loop suppression, is summarized in a later section.
隣人に計算された往復(偏っている)の遅れ見積りがHELLOメッセージで与えられたそれぞれの遅れ見積りに追加されるのでアルパネットと他の場所で使用されて、Host Tableで対応する遅れ見積りと比べて、ルーティング・アルゴリズムは(以前、)それと同様です。 このように計算された遅れが既にHost Tableの遅れ以下であるなら、それに従って、対応する事実上のホストへのルーティングを変えます。 このアルゴリズムの詳細な操作は後のセクションでまとめられます。(アルゴリズムはホスト上下論理と輪の抑圧のための条項を含んでいます)。
DCN local nets are self-configuring for all hosts and neighbor
nets; that is, the routing algorithms will find minimum-delay paths
between all hosts and gateways to neighbor nets. In addition,
timekeeping information can be exchanged using special HELLO messages
between neighboring DCN local nets. For routing beyond neighbor nets
additional entries can be configured in the Net Tables as required.
In addition, a special entry can be configured in the Net Tables which
specifies the host ID of the gateway to all nets not explicitly
included in the table.
DCNのローカルのネットはすべてのホストと隣人のために自己にネットを構成しています。 すなわち、ルーティング・アルゴリズムは隣人ネットへのすべてのホストとゲートウェイの間の最小の遅れ経路を見つけるでしょう。 さらに、隣接しているDCNローカルのネットの間の特別なHELLOメッセージを使用することで時間保持情報を交換できます。 隣人ネットを超えたルーティングにおいて、必要に応じてネットTablesで追加エントリーを構成できます。 さらに、テーブルに明らかに含まれていたというわけではないすべてのネットへのゲートウェイのホストIDを指定するネットTablesで特別なエントリーを構成できます。
For routing via the ARPANET and its reachable nets a selected
local-net host is equipped with an IMP interface and configured with a
GGP/EGP Gateway process. This process maintains the Net Table of the
local host, including ARPANET leaders, dynamically as part of the
GGP/EGP protocol interactions with other ARPANET gateways. GGP/EGP
protocol interactions are possibly with non-ARPANET gateways as well.
アルパネットを通したルーティングとその届いているネットにおいて、選択された地方にネットのホストは、IMPインタフェースを備えて、GGP/EGPゲートウェイプロセスによって構成されます。 このプロセスは他のアルパネットゲートウェイとのGGP/EGPプロトコル相互作用の一部としてダイナミックにアルパネットリーダーを含むローカル・ホストのネットTableを維持します。 GGP/EGPプロトコル相互作用がことによるとまた、非アルパネットゲートウェイであります。
The portable virtual-host structure used in the DCN encourages a
rather loose interpretation of addressing. In order to minimize
confusion in the following, the term "host ID" will be applied only to
virtual hosts, while "host number" will be applied to the physical
host, called generically the DCN host.
DCNで使用される携帯用の仮想のホスト構造はアドレシングのかなりゆるい解釈を奨励します。 以下で混乱を最小にするために、「ホスト番号」は物理ホストに適用されるでしょうが、「ホストID」が事実上のホストだけに適用される用語は、DCNホストに一般的に電話をしました。
2.1. Net and Host Tables
2.1. ネットとホストテーブル
There are two tables in every DCN host which control routing of
Internet Protocol (IP) datagrams: the Net Table and the Host Table.
The Net Table is used to determine the host ID of the gateway on the
route to a foreign net,
DCN Local-Network Protocols Page 4
D.L. Mills
すべてのDCNホストのインターネットプロトコル(IP)データグラムのルーティングを制御する2個のテーブルがあります: ネットのテーブルとホストテーブル。 4ページ ネットTableはルートの上でゲートウェイのホストIDを外国ネットに決定するのに使用されて、DCN Local-ネットワークプロトコルはD.L.ミルズです。
while the Host Table is used to determine the link, with respect to the DCN host, on the route to a virtual host. The Host Table is maintained dynamically using updates generated by periodic HELLO messages. The Net Table is fixed at configuration time for all DCN hosts except those that support a GGP/EGP Gateway process. In these cases the Net Table is updated as part of the gateway operations. In addition, entries in either table can be changed by operator commands.
Host Tableはルートの上のDCNホストに関して事実上のホストにリンクを決定するのに使用されますが。 Host Tableは、ダイナミックに周期的なHELLOメッセージによって生成されたアップデートを使用することで維持されます。 ネットTableはGGP/EGPゲートウェイプロセスをサポートするもの以外のすべてのDCNホストのための構成時に修理されています。 これらの場合では、ゲートウェイ操作の一部としてネットTableをアップデートします。 さらに、オペレータコマンドはどちらかのテーブルのエントリーを変えることができます。
The Net Table format is shown in Figure 1.
ネットTable書式は図1に示されます。
1 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net(2) | Net(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Net(3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hops | Gateway ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Leader |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットの名前| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネット(2)| ネット(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インデックス| ネット(3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホップス| ゲートウェイID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ゲートウェイリーダー| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Net Table Entry
図1。 ネットのテーブル項目
The "Net Name" field defines a short (RAD50) name for the net,
while the "Net" fields define the class A/B/C net number. The
"Gateway ID" field contains the host ID of the first gateway to the
net and the "Hops" field the number of hops to it. The remaining
fields are used only by the GGP/EGP Gateway process and include the
"Index" field, which contains an index into the routing matrix. and
the "Gateway Leader" field, which contains the (byte-swapped)
local-net leader for the gateway on a neighbor net.
分野という「ネットの名前」はネットのために短い(RAD50)名を定義します、「ネット」の分野はクラスのA/B/Cのネットの番号を定義しますが。 「Gateway ID」分野はネットへの最初のゲートウェイのホストIDを含んでいます、そして、「ホップス」はホップの数をそれとしてさばきます。 残っているフィールドは、GGP/EGPゲートウェイプロセスだけによって使用されて、「インデックス」分野(ルーティングマトリクスの中にインデックスを含むもの)と「ゲートウェイリーダー」分野を含んでいます。(それは、隣人ネットのゲートウェイへの(バイトと交換される)の地方にネットのリーダーを含みます)。
The Net Table contains an indefinite number of entries and is
terminated by a special entry with all "Net" fields set to zero. If
the "Hops" field of this entry is less than 255, the "Gateway ID"
field of this entry is used for all nets not in the table. If the
"Hops" field is 255 all nets not explicitly mentioned in the table
appear unreachable.
ネットTableは無期数のエントリーを含んでいて、ゼロに設定されたすべての「ネット」の分野で特別なエントリーで終えられます。 このエントリーの「ホップス」分野が255未満であるなら、このエントリーの「Gateway ID」分野はテーブルでないところのすべてのネットに使用されます。 「ホップス」分野が255であるなら、テーブルで明らかに言及されなかったすべてのネットが手が届かなく見えます。
The Host Table format is shown in Figure 2.
DCN Local-Network Protocols Page 5
D.L. Mills
Host Table書式は図2に示されます。 5ページ D.L.が製粉するDCN企業内情報通信網プロトコル
1 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Local Leader |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Update Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 名前| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL| IDを移植してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 相殺されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 地元のリーダー| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + アップデートタイムスタンプ+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Host Table Entry
図2。 ホストテーブルエントリー
The ordinal position of each Host Table entry corresponds to its
host ID. The "Name" field contains a short (RAD50) name for
convenient reference. The "Port ID" field contains the port ID of the
net-output process on the shortest path to this virtual host and the
"Delay" field contains the measured roundtrip delay to it. The
"Offset" field contains the difference between the logical clock of
this host and the logical clock of the local host. The "Local Leader"
field contains information used to construct the local leader of the
outgoing packet, for those nets that require it. The "Update
Timestamp" field contains the logical clock value when the entry was
last updated and the "TTL" field the time (in seconds) remaining until
the virtual host is declared down.
それぞれのHost Tableエントリーの序数の位置はホストIDに対応しています。 「名前」分野は便利な参照のための短い(RAD50)名を含んでいます。 「Port ID」分野は最短パスに純生産高プロセスのポートIDをこの事実上のホストに含んでいます、そして、「遅れ」分野は測定往復の遅れをそれに含んでいます。 「オフセット」の分野はこのホストの論理的な時計とローカル・ホストの論理的な時計の違いを含んでいます。 「地元のリーダー」分野は出発しているパケットの地元のリーダーを組み立てるのに使用される情報を含んでいます、それを必要とするそれらのネットのために。 エントリーをアップデートして、"TTL"が事実上のホストが下がっていると宣言されるまで残りながら時間(秒の)をさばくとき、「アップデートタイムスタンプ」分野は論理的な時計値を含んでいます。
All fields except the "Name" field are filled in as part of the
routing update process, which is initiated upon arrival of a HELLO
message from a neighboring DCN host. This message takes the form of
an IP datagram carrying the reserved protocol number 63 and a data
field as shown in Figure 3.
DCN Local-Network Protocols Page 6
D.L. Mills
分野という「名前」を除いたすべての分野がルーティング更新処理の一部として記入されます。(更新処理は隣接しているDCNホストからのHELLOメッセージの到着のときに着手されます)。 このメッセージは、図3に示されるように予約されたプロトコル番号63とデータ・フィールドを運びながら、IPデータグラムの形を取ります。 6ページ D.L.が製粉するDCN企業内情報通信網プロトコル
1 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fixed | Checksum |
Area +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Date |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Hosts (n) |
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host | Delay Host 0 |
Area +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Host 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Host n-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Host n-1 |
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 --- +++++++++++++++++は修理されました。| チェックサム| 領域+++++++++++++++++| 日付| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +時間+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 相殺されます。| ホスト(n)| --- +++++++++++++++++ホスト| 遅れホスト0| 領域+++++++++++++++++| ホスト0を相殺してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遅れHost n-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host n-1を相殺してください。| --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. HELLO Message Format
図3。 こんにちは、メッセージ・フォーマット
There are two HELLO message formats, depending on the length of
the message. One format, sent by a DCN host to another host on the
same local net, includes both the fixed and host areas shown above.
The second format, sent in all other cases, includes only the fixed
area.
メッセージの長さによって、2つのHELLOメッセージ・フォーマットがあります。 同じローカルのネットの別のホストのDCNホストによって送られた1つの形式が上に示された両方の修理されるのとホスト領域を含んでいます。 他のすべての場合で送られた2番目の形式は固定領域だけを含んでいます。
Note that all word fields shown are byte-swapped with respect to
the ordinary PDP11 representation. The "Checksum" field contains a
checksum covering the fields indicated. The "Date" and "Time" fields
are filled in with the local date and time of origination. The
"Timestamp" field is used in the computation of the roundtrip delay
(see below). The "Offset" field contains the offset of the block af
Internet addresses used by the local net. The "Delay Host n" and
"Offset Host n" fields represent a copy of the corresponding entries
of the Host Table as they exist at the time of origination. The
"Hosts (n)" field contains the number of entries in this table.
示されたすべての単語分野がバイトと普通のPDP11に関して交換された表現であることに注意してください。 「チェックサム」分野は分野が示したチェックサム覆いを含んでいます。 「日付」と「時間」分野は創作の地方の日時で記入されます。 「タイムスタンプ」分野は往復の遅れの計算に使用されます(以下を見てください)。 「オフセット」の分野はafインターネット・アドレスがローカルのネットで使用したブロックのオフセットを含んでいます。 創作時点で存在するとき、「遅れHost n」と「オフセットHost n」分野はHost Tableの対応するエントリーのコピーを表します。 「ホスト(n)」分野はこのテーブルのエントリーの数を含んでいます。
2.2. Roundtrip Delay Calculations
2.2. 往復の遅れ計算
Periodically, each DCN physical host sends a HELLO message to its
neighbor on each of the communication links common to both of them.
For each of these links the sender keeps a set of state variables,
including a copy of the source-address field of the last HELLO message
received.
DCN Local-Network Protocols Page 7
D.L. Mills
定期的に、それぞれのDCN物理ホストはそれぞれの通信リンクでHELLOメッセージを隣人にそれらの両方に共通の状態で送ります。 それぞれのこれらのリンクに関しては、送付者は1セットの州の変数を保ちます、HELLOメッセージが受けた最終ソースアドレス分野のコピーを含んでいて。 7ページ D.L.が製粉するDCN企業内情報通信網プロトコル
When constructing a HELLO message the sender sets the destination-address field to this state variable and the source-address field to its own address. It then fills in the "Date" and "Time" fields from its logical clock and the "Timestamp" field from another state variable. It finally copies the "Delay" and "Offset" values from its Host Table into the message.
HELLOメッセージを構成するとき、送付者はこの州の変数への目的地アドレス・フィールドとそれ自身のアドレスへのソースアドレス分野を設定します。 そして、それは論理的な時計と「タイムスタンプ」分野から別の州の変数から「日付」と「時間」分野に記入します。 それは最終的に「遅れ」と「オフセット」の値をメッセージにHost Tableを回避します。
A host receiving a HELLO message discards it if the format is bad
or the checksum fails. If valid, it initializes a link state variable
to show that the link is up. Each time a HELLO message is transmitted
this state variable is decremented. If it decrements to zero the link
is declared down.
形式が悪いか、またはチェックサムが失敗するなら、HELLOメッセージを受け取るホストはそれを捨てます。 有効であるなら、それは、リンクが上がっているのを示すためにリンク州の変数を初期化します。 HELLOメッセージが送られるたびにこの州の変数は減少します。 それであるなら、ゼロへの減少はダウンしますリンクが申告される。
The host then checks if the source-address field matches the
state variable containing the last address stored. If not, the link
has been switched to a new host, so the state variables are flushed
and the link forced into a recovery state. The host then checks if
the destination-address field matches its own address. If so, the
message has been looped (legal only in the case of a broadcast net)
and the roundtrip delay information is corrected. The host and net
areas are ignored in this case. If not, the host and net areas of the
message are processed to update the Host and Net Tables.
そして、ホストは、ソースアドレス分野が格納された最後のアドレスを含む州の変数に合っているかどうかチェックします。 したがって、州の変数は、そうでなければ、リンクが新しいホストに切り換えられて、紅潮していて回復状態に強制されたリンクです。 そして、ホストは、目的地アドレス・フィールドがそれ自身のアドレスに合っているかどうかチェックします。 そうだとすれば、メッセージは輪にされました、そして、(放送ネットの場合だけで法的な)往復の遅れ情報は直っています。 ホストとネットの領域はこの場合無視されます。 そうでなければ、メッセージのホストとネットの領域は、HostとネットTablesをアップデートするために処理されます。
Roundtrip delay calculations are performed in the following way.
The link input/output processes assigned each link maintain an
internal state variable which is updated as each HELLO message is
received and transmitted. When a HELLO message is received this
variable takes the value of the "Time" field minus the current
time-of-day. When the next HELLO message is transmitted, the value
assigned the "Timestamp" field is computed as the low-order 16-bits of
this variable plus the current time-of-day. The value of this
variable is forced to zero if either the link is down of the system
logical clock has been reset since the last HELLO message was
received.
往復の遅れ計算は以下の方法で実行されます。 各リンクが割り当てられたリンク入力/出力の過程はそれぞれのHELLOメッセージが受け取られて、送られるようにアップデートされる内部の州の変数を維持します。 HELLOメッセージが受信されているとき、この変数は現在の時刻を引いて「時間」分野の値を取ります。 次のHELLOメッセージが送られるとき、「タイムスタンプ」分野が割り当てられた値はこの可変時刻と現在の時刻下位の16ビットとして計算されます。 最後のHELLOメッセージを受け取って以来リンクがあるシステムの論理的な時計のどちらかがリセットされているなら、この変数の値は、ゼロに合わせるために無理矢理であっています。
If a HELLO message is received with zero "Timestamp" field, no
processing other than filling in the internal state variable.
Otherwise, the roundtrip delay is computed as the low-order 16-bits of
the current time-of-day minus the value of this field. In order to
assure the highest accuracy, the calculation is performed only if the
length of the last transmitted HELLO message (in octets) matches the
length of the received HELLO message.
「タイムスタンプ」分野がない、内部の州の変数に記入するのを除いた処理でないのでHELLOメッセージを受け取るなら。 さもなければ、往復の遅れはこの分野の値を引いて現在の時刻下位の16ビットとして計算されます。 最も高い精度を保証するために、最後に伝えられたHELLOメッセージ(八重奏における)の長さが受信されたHELLOメッセージの長さに合っている場合にだけ、計算は実行されます。
The above technique renders the calculation independent of the
clock offsets and intervals between HELLO messages at either host,
protects against errors that might occur due to lost HELLO messages
and works even when a neighbor host simply forwards the HELLO message
back to the originator without modifying it. The latter behavior,
typical of ARPANET IMPs and gateways, as well as broadcast nets, relies
on the loop-detection mechanism so that correct calculations can be
made and, furthermore, that spurious host updates can be avoided.
上のテクニックは、HELLOメッセージの時計オフセットと間隔の如何にかかわらずどちらのホストでも計算をレンダリングして、無くなっているHELLOメッセージのため発生するかもしれない誤りから守って、隣人ホストが単にそれを変更しないでHELLOメッセージを創始者に転送して戻しさえするとき、利きます。 後者のアルパネットIMPs、ゲートウェイ、および放送ネットの典型である振舞いは、正しい計算をすることができて、その上、そんなに偽りのホストアップデートを避けることができるように輪検出メカニズムを当てにします。
DCN Local-Network Protocols Page 8 D.L. Mills
8ページ D.L.が製粉するDCN企業内情報通信網プロトコル
2.3. Host Updates
2.3. ホストアップデート
When a HELLO message arrives which results in a valid roundtrip
delay calculation, a host update process is performed. This consists
of adding the roundtrip delay to each of the "Delay Host n" entries in
the HELLO message in turn and comparing each of these calculated
delays to the "Host Delay" field of the corresponding Host Table
entry. Each entry is then updated according to the following rules:
有効な往復の遅れ計算をもたらすHELLOメッセージが到着するとき、ホスト更新処理は実行されます。 これは順番にHELLOメッセージにおける、それぞれの「遅れHost n」エントリーに往復の遅れを加えて、対応するHost Tableエントリーの「ホスト遅れ」分野にそれぞれのこれらの計算された遅れをたとえるのから成ります。 次に、以下の規則に従って、各エントリーをアップデートします:
1. If the link connects to another DCN host on the same net and the
port ID (PID) of the link output process matches the "Port ID"
field of the entry, then update the entry.
1. リンクが同じネットの別のDCNホストとリンク出力過程マッチのポートID(PID)にエントリーの「Port ID」分野をつなげるなら、エントリーをアップデートしてください。
2. If the link connects to another DCN host on the same net, the PID
of the link output process does not match the "Port ID" field and the
calculated delay is less than the "Host Delay" field by at least a
specified switching threshold (currently 100 milliseconds), then
update the entry.
2. リンクが別のDCNホストに接続するなら、少なくとも指定された切り換え敷居(現在の100ミリセカンド)による「ホスト遅れ」分野以下が「Port ID」分野と計算が遅らせるマッチではなく、同じネット、過程がするリンク出力のPIDに、あって、次に、アップデートはエントリーです。
3. If the link connects to a foreign net and is assigned a host ID
corresponding to the entry, then update the entry. In this case
only, use as the calculated delay the roundtrip delay.
3. リンクが外国ネットに接続して、エントリーに対応するホストIDに割り当てられるなら、エントリーをアップデートしてください。 この場合往復旅行が遅らせる計算された遅れとしての使用だけ。
4. If none of the above conditions are met, or if the virtual host
has been declared down and the "TTL" field contains a nonzero
value, then no update is performed.
4. 上記の状態のいずれも満たされないか、事実上のホストが下がっていると宣言されて、または"TTL"分野が非ゼロ値を含んでいるなら、アップデートは全く実行されません。
The update process consists of replacing the "Delay" field with
the calculated delay, the "Port ID" field with the PID of the link
output process, the "Update Timestamp" field with the current time of
day and the "TTL" field by a specified value (currently 120) in
seconds. If the calculated delay exceeds a specified maximum interval
(currently 30 seconds), the virtual host is declared down by setting
the corresponding "Delay" field to the maximum and the remaining
fields as before. For the purposes of delay calculations values less
than a specified minimum (currently 100 milliseconds) are rounded up
to that minimum.
更新処理は規定値(現在の120)で秒に「遅れ」分野を計算された遅れ、リンク出力の過程のPIDがある「Port ID」分野、現在の時刻がある「アップデートタイムスタンプ」分野、および"TTL"分野に取り替えるのから成ります。 計算された遅れが指定された最大の間隔(現在の30秒)を超えているなら、事実上のホストは、従来と同様最大の分野と残っている分野への対応する「遅れ」分野を設定することによって、宣言されます。 遅れの目的のために、指定された最小限(現在の100ミリセカンド)より少ない計算値はその最小限まで四捨五入されます。
The "Offset" field is also replaced during the update process.
When the HELLO message arrives, The value of the current logical clock
is subtracted from the "Time" field and the difference added to
one-half the roundtrip delay. The resulting sum, which represents the
offset of the local clock to the clock of the sender, is added to the
corresponding "Offset" field of the HELLO message and the sum replaces
the "Offset" field of the Host Table. Thus, the "Offset" field in the
Host Table for a particular virtual host is replaced only if that host
is up and on the minimum-delay path to the DCN host.
また、更新処理の間、「オフセット」の野原を取り替えます。 HELLOメッセージが到着するとき、現在の論理的な時計の値は「時間」分野から引き算されました、そして、違いは半分への往復の遅れを加えました。 結果として起こる合計(地方の時計のオフセットを送付者の時計に表す)はHELLOメッセージの対応する「オフセット」の分野に加えられます、そして、合計はHost Tableの「オフセット」の野原を取り替えます。 したがって、DCNホストにそのホストが経路の上と、そして、最小の遅れ経路の上にいる場合にだけ、特定の事実上のホストのためのHost Tableの「オフセット」の野原を取り替えます。
The purpose of the switching threshold in (2) above and the
minimum delay specification in the update process is to avoid
unnecessary switching between links and transient loops which can
occur due to normal variations in propagation delays. The purpose of
the "TTL" field test in (4) above is to ensure consistency by purging
all paths to a virtual host when that virtual host goes down.
DCN Local-Network Protocols Page 9
D.L. Mills
(2)の上の切り換え敷居の目的と更新処理による最小の遅れ仕様は伝播遅延における正常変動のため現れることができるリンクと一時的な輪の間の不要な切り換えを避けることです。 (4)での上の"TTL"実地試験の目的はその事実上のホストが落ちるとき事実上のホストにすべての経路を掃除することによって一貫性があることを保証することです。 9ページ D.L.が製粉するDCN企業内情報通信網プロトコル
In addition to the updates performed as HELLO messages arrive, each
virtual host in a DCN host also performs a periodic update of its own
Host Table entry. The update procedure is identical to the above,
except that the calculated delay and offset are taken as zero. At
least one of the virtual hosts in a DCN host must have the same host
ID as the host number assigned the DCN host itself and all must be
assigned the same net number. Other than these, there are no
restrictions on the number or addresses of internet processes resident
in a single DCN host.
また、HELLOメッセージが到着するので実行されたアップデートに加えて、DCNホストというそれぞれの事実上のホストはそれ自身のHost Tableエントリーの周期的なアップデートを実行します。 計算された遅れとオフセットがゼロとしてみなされるのを除いて、アップデート手順は上記で同じです。 DCNホスト自身に割り当てられたホスト番号とすべてに同じネットの数を割り当てなければならないとき、少なくともDCNホストの事実上のホストのひとりは同じくらいにIDを接待させなければなりません。 これら以外に、制限が全く独身のDCNホストで居住しているインターネットの過程の数かアドレスにありません。
It should be appreciated that virtual hosts are truly portable
and can migrate about the net, should such a requirement arise. The
host update protocols described here insure that the routing
procedures always converge to the minimum-delay paths via operational
links and DCN hosts. In the case of broadcast nets such as Ethernets,
the procedures are modified slightly as described below. In this case
the HELLO messages are used to determine routing from the various
Ethernet hosts to destinations off the cable, as well as to provide
time synchronization.
事実上のホストが本当に、携帯用であり、ネットに関して移住できるのが理解されるべきです、そのような要件が起こるなら。 ここで説明されたホストアップデートプロトコルは、ルーティング手順が操作上のリンクとDCNホストを通していつも最小の遅れ経路に一点に集まるのを保障します。 Ethernetsなどの放送ネットの場合では、手順はわずかに以下で説明されるように変更されています。 この場合、HELLOメッセージは、ケーブルからルーティングを様々なイーサネットホストから目的地まで決定して、時間同期化を提供するのに使用されます。
2.4. Timeouts
2.4. タイムアウト
The "TTL" field in every Host Table entry is decremented once a
second in normal operation. Thus, if following a host update another
update is not received within an interval corresponding to the value
initialized in that field, it decrements to zero, at which point the
virtual host is declared down and the Host Table entry set as
described above. The 120-second interval used currently provides for
at least four HELLO messages to be generated by every neighbor on
every link during that interval, since the maximum delay between HELLO
messages is 30 seconds on the lowest-speed link (1200 bps). Thus, if
no HELLO messages are lost, the maximum number of links between any
virtual host and any other is four.
あらゆるホストテーブル項目における"TTL"分野は通常の操作で1秒に一度減少します。 したがって、ホストアップデートに続くなら、別のアップデートはその分野で初期化された値に対応する間隔以内に受けられないで、それはゼロ、事実上のホストがどのポイントで下がっていると宣言されるか、そして、および上で説明されるように設定されたHost Tableエントリーへの減少です。 現在費やされている120秒の間隔はその間隔の間、あらゆるリンクの上に少なくとも4つのすべての隣人を発生させるべきHELLOメッセージに備えます、HELLOメッセージの間の最大の遅れが最も低い速度リンク(1200年のビーピーエス)の30秒であるので。 したがって、どんなHELLOメッセージも無くならないなら、どんな事実上のホストといかなる他のリンクの最大数も4です。
The "TTL" field is initialized at 120 seconds when an update
occurs and when the virtual host is declared down. During the
interval this field decrements to zero immediately after being
declared down, updates are ignored. This provides a decent interval
for the bad news to propagate throughout the net and for the Host
Tables in all DCN hosts to reflect the fact. Thus, the formation of
routing loops is prevented.
"TTL"分野はアップデートが起こるときの120秒、事実上のホストが下がっていると宣言されるときに時初期化されます。 下がっていると宣言される直後この分野がゼロまで減少させる間隔の間、アップデートは無視されます。 悪いニュースがネット中で伝播されて、すべてのDCNホストのHost Tablesが事実を反映するように、これはきちんとした間隔を提供します。 したがって、ルーティング輪の構成は防がれます。
The IP datagram forwarding procedures call for decrementing the
"time-to-live" field in the IP header once per second or at each point
where it is forwarded, whichever comes first. The value used
currently for this purpose is 30, so that an IP datagram can live in
the net no longer than that number of seconds. This is thus the
maximum delay allowed on any path between two virtual hosts. If this
maximum delay is exceeded in calculating the roundtrip delay for a
Host Table entry, the corresponding virtual host will be declared
down.
IPデータグラム推進手順は、秒、または、それが進められる各ポイントでIPヘッダーの「生きる時間」分野を一度減少させるように求めます、どれが一番になっても。 現在使用されている値はこのために30です、IPデータグラムがもうその秒数よりネットに生きていることができないように。 これはその結果2人の事実上のホストの間のどんな経路にも許容された最大の遅れです。 この最大の遅れがHost Tableエントリーに往復の遅れについて計算する際に超えられていると、対応する事実上のホストは下がっていると宣言されるでしょう。
DCN Local-Network Protocols Page 10 D.L. Mills
10ページ D.L.が製粉するDCN企業内情報通信網プロトコル
The interval between HELLO messages on any link depends on the
data rate supported by the link. As a general rule, this interval is
set at 16 times the expected roundtrip time for the longest packet to
be sent on that link. For 1200-bps asynchronous transmission and
packet lengths to 256 octets, this corresponds to a maximum HELLO
message interval of about 30 seconds.
どんなリンクに関するHELLOメッセージの間隔もリンクによって支持されたデータ信号速度によります。 概して、この間隔はそのリンクに送られるべき中でパケット最も長い往復の予想された時間の16回のときに設定されます。 256の八重奏への1200ビーピーエスの非同期伝送とパケットの長さのために、これは最大およそ30秒のHELLOメッセージ間隔に対応しています。
Although the roundtrip delay calculation, upon which the routing
process depends, is relatively insensitive to net traffic and
congestion, stochastic variations in the calculated values ordinarily
occur due to coding (bit or character stuffing) and medium
perturbations. In order to suppress loops and needless path changes a
minimum switching threshold is incorporated into the routing mechanism
(see above). The interval used for this threshold, as well as for the
minimum delay on any path, is 100 milliseconds.
往復の遅れ計算(ルーティングの過程を依存する)はネットの交通と混雑に比較的神経が鈍いのですが、通常、計算された値における確率的変動はコード化(ビットかキャラクタ詰め物)と中型の摂動のため起こります。 輪と不必要な経路変化を抑圧するために、最小の切り換え敷居はルーティングメカニズムに組み入れられます(上を見てください)。 この敷居、およびどんな経路の最小の遅れのためにも費やされた間隔は100ミリセカンドです。
3. Formal Specification
3. 形式仕様
The following sections provide a formal framework which describe
the DCN HELLO protocol. This protocol is run between neighboring DCN
hosts that share a common point-to-point link and provides automatic
connectivity determination, routing and timekeeping functions.
以下のセクションは正式な枠組みを提供します(DCN HELLOプロトコルについて説明します)。 このプロトコルは、一般的なポイントツーポイント接続を共有する隣接しているDCNホストの間を走って、自動接続性決断、ルーティング、および時間保持機能を提供します。
The descriptions to follow are organized as follows: First a
summary of data structures describes the global variables and packet
formats. Then three processes which implement the protocol are
described: the CLOCK, HELLO and HOST processes. The description of
these processes is organized into sections that describe (1) the local
variables used by that process, (2) the parameters and constants and
(3) the events that initiate processing together with the procedures
they evoke. In the case of variables a distinction is made between
state variables, which retain their contents between procedure calls,
and temporaries, which have a lifetime extending only while the
process is running. Except as noted below, the initial contents of
state variables are unimportant.
続く記述は以下の通り組織化されます: まず最初に、データ構造の概要は大域変数とパケット・フォーマットについて説明します。 次に、プロトコルを実行する3つの過程が説明されます: CLOCK、HELLO、およびHOSTの過程。 これらの過程の記述は(3) (2) (1) その工程で使用される局所変数、パラメタ、および定数について説明するセクションとそれらが喚起する手順と共に処理を開始する出来事に組織化されます。 変数の場合では、州の変数とtemporariesの間で区別をします。変数は手順呼び出しの間でそれらのコンテンツを保有します。temporariesは、過程が走っているだけである間、広がりながら、生涯を持っています。 以下に述べられるのを除いて、州の変数の初期の内容は重要ではありません。
3.1. Data Structures
3.1. データ構造
3.1.1. Global Variables
3.1.1. 大域変数
ADDRESS
This is a 32-bit bit-string temporary variable used to contain an
Internet address.
ADDRESS Thisはインターネット・アドレスを含むのに使用される32ビットのビット列一時的数値変数です。
CLOCK-HID
This is an eight-bit integer state variable used to contain the
host ID of the local-net host to be used as the master clock. It
is initialized to the appropriate value depending upon the net
configuration.
CLOCK-HID Thisはマスタークロックとして使用されるべき地方にネットのホストのホストIDを含むのにおいて中古の8ビットの整数州の変数です。 それはネットの構成に依存する適切な値に初期化されます。
DATE
This is a 16-bit bit-string state variable used to contain the
date in RT-11 format. Bits 0-4 contain the year, with zero
corresponding to 1972, bits 5-9 contain the day of the month and
DCN Local-Network Protocols Page 11
D.L. Mills
DATE ThisはRT-11形式に日付を含むのに使用される16ビットのビット列州の変数です。 ビット0-4は1年を含んでいます、1972に対応するゼロでビット5-9は11ページ 月とDCN Local-ネットワークプロトコルD.L.ミルズ日を含んでいます。
bits 10-14 contain the month, starting with one for January.
1月のための1つから始まって、ビット10-14は月を含んでいます。
DATE-VALID
This is a one-bit state variable used to indicate whether the
local date and time are synchronized with the master clock. A
value of one indicates the local clock is not synchronized with
the master clock. This variable is set to one initially and when
the local time-of-day rolls over past midnight. It is set to zero
each time a valid date and time update has been received from the
master clock.
DATE-VALID Thisはローカルの期日と時間がマスタークロックと同時にするかどうかを示すのに使用される1ビットの州の変数です。 1の値は、地方の時計がマスタークロックに連動しないのを示します。 この変数は1つへのセットが初めは、日の現地時間であるときに時過去の真夜中の間、回転するということです。 その都度有効な期日のゼロを合わせるようにそれを設定します、そして、マスタークロックから時間アップデートを受けました。
DELAY
This is a 16-bit integer temporary variable which represents the
roundtrip delay in milliseconds to a host.
DELAY Thisはミリセカンドの往復の遅れをホストに表す16ビットの整数一時的数値変数です。
HID
This is an eight-bit integer temporary variable containing the
host ID of some host on the local net.
HID ThisはローカルのネットにホストのホストIDを含む8ビットの整数一時的数値変数です。
There is a one-to-one correspondence between the Internet
addresses of local hosts and their HIDs. The mapping between them
is selected on the basis of the octet number of the Internet
address. For DCN hosts it is the fourth octet, while for hosts
directly connected to a class-A ARPANET IMP or gateway, it is the
third octet (logical-host field). The contents of this octet are
to be added to ADDRESS-OFFSET to form the HID associated
with the address.
ローカル・ホストと彼らのHIDsのインターネット・アドレスの間には、1〜1つの通信があります。 それらの間のマッピングはインターネット・アドレスの八重奏番号に基づいて選択されます。 DCNホストにとって、それは4番目の八重奏です、直接クラスA ARPANET IMPかゲートウェイに接続されたホストにとってそれが3番目の八重奏(論理的なホスト分野)ですが。 この八重奏の内容はアドレスに関連しているHIDを形成するためにADDRESS-OFFSETに加えられることです。
HOLD
This is an eight-bit counter state variable indicating whether
timestamps are valid or not. While HOLD is nonzero, timestamps
should be considered invalid. When set to some nonzero value, the
counter decrements to zero at a 1-Hz rate. Its initial value is
zero.
HOLD Thisはタイムスタンプが有効であるかどうかを示す8ビットのカウンタ州の変数です。 HOLDが非零である間、タイムスタンプは無効であると考えられるべきです。 何らかの非ゼロ値に設定されると、カウンタ1Hzのレートにおけるゼロに減少します。 初期の値はゼロです。
HOST-TABLE
This is a table of NHOSTS entries indexed by host ID (HID). There
is one entry for each host in the local net. Each entry has the
following format:
HOST-TABLE ThisはホストID(HID)によって索引をつけられたNHOSTSエントリーのテーブルです。 ローカルのネットには各ホストあたり1つのエントリーがあります。 各エントリーには、以下の形式があります:
HOST-TABLE.DELAY
This is a 16-bit field containing the computed roundtrip delay
in milliseconds to host HID.
HOST-TABLE.DELAY Thisはミリセカンドの計算された往復の遅れをホストHIDに含む16ビットの分野です。
HOST-TABLE.OFFSET
This is a 16-bit field containing the computed signed offset
in milliseconds which must be added to the local apparent
clock to agree with the apparent clock of host HID.
HOST-TABLE.OFFSET ThisはホストHIDの見かけの時計に同意するために地方の見かけの時計に加えなければならないミリセカンドで計算されたサインされたオフセットを含む16ビットの分野です。
HOST-TABLE.PID
This is an eight-bit field containing the PID of the net-output
process selected by the routing algorithm to forward packets
to host HID.
HOST-TABLE.PID Thisは過程がホストHIDにパケットを送るのをルーティング・アルゴリズムで選択した純生産高のPIDを含む8ビットの分野です。
DCN Local-Network Protocols Page 12 D.L. Mills
12ページ D.L.が製粉するDCN企業内情報通信網プロトコル
HOST-TABLE.TTL
This is an eight-bit field used as a time-to-live indicator.
It is decremented by the HOST process once each second and
initialized to a chosen value when a HELLO message is
received. The table is initialized with the HOST-TABLE.DELAY
field set to MAXDELAY for all entries. The contents of the
other fields are unimportant.
HOST-TABLE.TTL Thisは生きる時間インディケータとして使用される8ビットの分野です。 HELLOメッセージが受信されているとき、それは、HOST工程で1秒に一度減少して、選ばれた値に初期化されます。 テーブルはすべてのエントリーのためにHOST-TABLE.DELAY分野セットでMAXDELAYに初期化されます。 他の分野の内容は重要ではありません。
LOCAL-ADDRESS
This is a 32-bit bit-string state variable used to contain the
local host Internet address.
LOCAL-ADDRESS Thisはローカル・ホストインターネット・アドレスを含むのに使用される32ビットのビット列州の変数です。
NET-TABLE
This is a table of NNETS entries with the following format:
ネット-TABLE Thisは以下の形式があるNNETSエントリーのテーブルです:
NET-TABLE.HID
This is an eight-bit field containing the host ID of the
pseudo-process to forward packets to the NET-TABLE.NET net.
ネット-TABLE.HID Thisはネット-TABLE.NETネットへの前進のパケットに疑似過程のホストIDを含む8ビットの分野です。
NET-TABLE.NET
This is a 24-bit field containing an Internet class-A (eight
bits), class-B (16 bits) or class-C (24 bits) net number.
Note that the actual field width for class-B net numbers is 24
bits in order to provide a subnet capability, in which the
high-order eight bits of the 16-bit host address is
interpreted as the subnet number.
ネット-TABLE.NET ThisはインターネットクラスA(8ビット)(クラスB(16ビット)かクラスC(24ビット)ネットの番号)を含む24ビットの分野です。 サブネット能力(16ビットのホスト・アドレスの高位8ビットはサブネット番号として解釈される)を提供するためにクラスBネットの番号のための実際の欄の幅が24ビットであることに注意してください。
The table is constructed at configuration time and must include an
entry for every net that is a potential neighbor. A neighbor net
is defined as a net containing a host that can be directly
connected to a host on the local net. The entry for such a net is
initialized with NET-TABLE.NET set to the neighbor net number and
NET-TABLE.HID set to an arbitrary vitual-host ID not assigned any
other local-net virtual host.
テーブルは、構成時に組み立てられて、潜在的隣人であるあらゆるネットのためにエントリーを含まなければなりません。 隣人ネットはローカルのネットで直接ホストに接できるホストを含むネットと定義されます。 そのようなネットのためのエントリーはいかなる他の地方にネットの事実上のホストにも割り当てられるのではなく、ネットの数とネット-TABLE.HIDが任意のvitual-ホストIDに設定する隣人に用意ができているネット-TABLE.NETと共に初期化されます。
The remaining entries in NET-TABLE are initialized at initial-boot
time with the NET-TABLE.NET fields set to zero and the
NET-TABLE.HID fields set to a configuration-selected host ID to be
used to forward packets to all nets other than neighbor nets. In
the case where a gateway module is included in the local host
configuration, the GGP and/or EGP protocols will be used to
maintain these entries; while, in the case where no gateway
module is included, only one such entry is required.
ネット-TABLEの残っているエントリーはゼロに設定されたネット-TABLE.NET分野で初期のブート時間で初期化されました、そして、ネット-TABLE.HID分野は、隣人ネット以外のすべてのネットにパケットを送るのに使用されるために構成で選択されたホストIDにセットしました。 ゲートウェイモジュールがローカル・ホスト構成で含まれている場合では、GGP、そして/または、EGPプロトコルはこれらのエントリーを維持するのに使用されるでしょう。 ゲートウェイモジュールがないのが含まれている場合では、そのようなエントリーの1つだけが必要ですが。
OFFSET
This is a 16-bit signed integer temporary variable which
represents the offset in milliseconds to be added to the apparent
clock time to yield the apparent clock time of the neighbor host.
OFFSET Thisは隣人ホストの見かけのクロック・タイムをもたらす見かけのクロック・タイムに加えられるためにミリセカンドでオフセットを表す16ビットのサインされた整数一時的数値変数です。
3.1.2. Parameters
3.1.2. パラメタ
ADDRESS-OFFSET
This is an integer which represents the value of the Internet
address field corresponding to the first host in HOST-TABLE.
DCN Local-Network Protocols Page 13
D.L. Mills
ADDRESS-OFFSET Thisは第1代HOST-TABLEのホストにとって、対応するインターネットアドレス・フィールドの値を表す整数です。 13ページ D.L.が製粉するDCN企業内情報通信網プロトコル
NHOSTS
This is an integer which defines the number of entries in HOST-TABLE.
NHOSTS ThisはHOST-TABLEのエントリーの数を定義する整数です。
NNETS
This is an integer which defines the number of entries in MET-TABLE.
NNETS ThisはMET-TABLEのエントリーの数を定義する整数です。
3.1.3. HELLO Packet Fields
3.1.3. こんにちは、Packetフィールズ
PKT.ADDRESS-OFFSET
This eight-bit is copied from ADDRESS-OFFSET by the sender.
PKT.ADDRESS-OFFSET This、8ビットは送付者によってADDRESS-OFFSETが回避されます。
PKT.DATESTAMP
Bits 0-14 of this 16-bit field are copied from DATE by the sender,
while bit 15 is copied from DATE-VALID.
この16ビットの分野のPKT.DATESTAMP Bits0-14は送付者によってDATEが回避されます、ビット15はDATE-VALIDからコピーされますが。
PKT.DATE-VALID
This one-bit field is bit 15 of PKT.DATESTAMP.
PKT.DATE-VALID Thisの1ビットの分野はPKT.DATESTAMPのビット15です。
PKT.DESTINATION
This 32-bit field is part of the IP header. It is copied from
HLO.NEIGHBOR-ADDRESS by the sender.
PKT.DESTINATION Thisの32ビットの分野はIPヘッダーの一部です。 それは送付者によってHLO.NEIGHBOR-ADDRESSが回避されます。
PKT.HOST-TABLE
This is a table of PKT.NHOSTS entries, each entry of which
consists of two fields. The entries are indexed by host ID and
have the following format:
PKT.HOST-TABLE ThisはPKT.NHOSTSエントリーのテーブルです。その各エントリーは2つの分野から成ります。 エントリーは、ホストIDによって索引をつけられて、以下の形式を持っています:
PKT.HOST-TABLE.DELAY
This 16-bit field is copied from the corresponding HOST-TABLE.DELAY
field by the sender.
PKT.HOST-TABLE.DELAY Thisの16ビットの分野は送付者によって対応するHOST-TABLE.DELAY分野が回避されます。
PKT.HOST-TABLE.OFFSET
This 16-bit field is copied from the corresponding HOST-TABLE.OFFSET
field by the sender.
PKT.HOST-TABLE.OFFSET Thisの16ビットの分野は送付者によって対応するHOST-TABLE.OFFSET分野が回避されます。
PKT.LENGTH
This 16-bit field is part of the IP header. It is set by the sender to
the number of octets in the packet.
PKT.LENGTH Thisの16ビットの分野はIPヘッダーの一部です。 それは送付者によってパケットの八重奏の数に設定されます。
PKT.NHOSTS
This eight-bit field is copied from NHOST by the sender.
PKT.NHOSTS Thisの8ビットの分野は送付者によってNHOSTが回避されます。
PKT.SOURCE
This 16-bit field is part of the IP header. It is copied from
LOCAL-ADDRESS by the sender.
PKT.SOURCE Thisの16ビットの分野はIPヘッダーの一部です。 それは送付者によってLOCAL-ADDRESSが回避されます。
PKT.TIMESTAMP
This 32-bit field contains the apparent time the packet was transmitted
in milliseconds past midnight UT.
PKT.TIMESTAMP Thisの32ビットの分野はパケットが真夜中のユタの先でミリセカンドで伝えられた見かけの時を含んでいます。
DCN Local-Network Protocols Page 14 D.L. Mills
14ページ D.L.が製粉するDCN企業内情報通信網プロトコル
PKT.TSP
This 16-bit field contains a variable used in roundtrip delay
calculations.
PKT.TSP Thisの16ビットの分野は往復の遅れ計算に使用される変数を含んでいます。
3.2 CLOCK Process (CLK)
3.2 時計の過程(CLK)
The timekeeping system maintains three clocks: (1) the physical
clock, which is determined by a hardware oscillator/counter; (2) the
apparent clock, which maintains the time-of-day used by client
processes and (3) the actual clock, which represents the time-of-day
provided by an outside reference. The apparent and actual clocks are
maintained as 48-bit quantities with 32 bits of significance available
to client processes. These clocks run at a rate of 1000 Hz and are
reset at midnight UT.
時間保持システムは3個の時計を維持します: (1) 物理的な時計(それは、ハードウェア振動子/カウンタで断固としています)。 (2) 見かけの時計。(その時計はクライアント工程で使用される時刻と(3)が実際の時計であることを支持します)。(それは、外の参照で提供された時刻を表します)。 意味の32ビットが有効な状態で明らかで実際の時計は48ビットの量としてクライアントの過程に維持されます。 これらの時計は、1000Hzのレートで走って、真夜中にリセットされます。ユタ。
The CLOCK process consists of a set of state variables along with
a set of procedures that are called as the result of hardware
interrupts and client requests. An interval timer is assumed
logically separate from the local clock mechanism, although both could
be derived from the same timing source.
CLOCKの過程は1セットのハードウェアの結果が中断するように呼ばれる1セットの手順に伴う州の変数とクライアント要求から成ります。 インタバルタイマはローカルの時計メカニズムから論理的に別々であると思われます、同じタイミングソースから両方を得ることができましたが。
3.2.1. Local Variables
3.2.1. 局所変数
CLK.CLOCK
This is a 48-bit fixed-point state variable used to represent the
apparent time-of-day. The decimal point is to the right of bit 16
(numbering from the right at bit 0). Bit 16 increments at a rate
equivalent to 1000 Hz independent of the hardware clock. (In the
case of programmable-clock hardware the value of CLK.CLOCK must be
corrected as described below.)
CLK.CLOCK Thisは見かけの時刻を表すのに使用される48ビットの定点州の変数です。 ビット16(ビット0の右から、付番します)の右には小数点があります。 ハードウェアの如何にかかわらず1000Hzに同等なレートにおけるビット16増分は時間を計ります。 (プログラマブル・クロックハードウェアの場合では、以下で説明されるようにCLK.CLOCKの値を修正しなければなりません。)
CLK.COUNT
This is a hardware register that increments at rate R. It can be
represented by a simple line clock, which causes interrupts at the
line-frequency rate, or by a programmable clock, which contains a 16-bit
register that is programmed to count at a 1000-Hz rate and causes an
interrupt on overflow. The register is considered a fixed-point variable
with decimal point to the right of bit 0.
CLK.COUNT ThisはレートR.Itの増分が回線周波数レートでの中断を引き起こす簡単な線時計かプログラマブル・クロックによって表される、1000Hzのレートで数えることができるハードウェアレジスタであり、オーバーフローのときに中断を引き起こします。プログラマブル・クロックはプログラムされる16ビットのレジスタを含みます。 レジスタはビット0の右への小数点がある定点変数であると考えられます。
CLK.DELTA
This is a 48-bit signed fixed-point state variable used to represent the
increment to be added to CLK.CLOCK to yield the actual time-of-day. The
decimal point is to the right of bit 16.
CLK.DELTA Thisは実際の時刻をもたらすためにCLK.CLOCKに加えられるために増分を表すのに使用される48ビットのサインされた定点州の変数です。 ビット16の右には小数点があります。
3.2.3. Parameters
3.2.3. パラメタ
ADJUST-FRACTION
This is an integer which defines the shift count used to compute a
fraction that is used as a multiplier of CLK.DELTA to correct CLK.CLOCK
once each clock-adjust interval. A value of seven is suggested.
ADJUST-FRACTION Thisはそれぞれの時計で適応している間隔の一度CLK.CLOCKを修正するのにCLK.DELTAの乗数として使用される断片を計算するのに使用される桁送り数を定義する整数です。 7の値は示されます。
DCN Local-Network Protocols Page 15 D.L. Mills
15ページ D.L.が製粉するDCN企業内情報通信網プロトコル
ADJUST-INTERVAL
This is an integer which defines the clock-adjust interval in
milliseconds. A value of 500 (one-half second) is suggested for
the line clock and 4000 (four seconds) for the 1000-Hz clock.
ADJUST-INTERVAL Thisはミリセカンドで時計で適応している間隔を定義する整数です。 500の値、(半分、2番目) 1000Hzの時計のための線時計と4000年(4秒)のために、示されます。
CLOCK-TICK
This is a fixed-point integer which defines the increment in
milliseconds to be added to CLK.CLOCK as the result of a clock
tick. The decimal point is to the right of bit 16. In the case
of a line-clock interrupt, the value of CLOCK-TICK should be
16.66666 (60 Hz) or 20.00000 (50 Hz). In the case of a 1000-Hz
programmable-clock overflow, the value should be 65536.00000.
CLOCK-TICK Thisは時計カチカチする音の結果としてCLK.CLOCKに加えられるためにミリセカンドで増分を定義する定点整数です。 ビット16の右には小数点があります。 線時計割込みの場合では、CLOCK-TICKの値は(60Hz)か20.00000(50Hz)に16.66666であるべきです。 1000Hzのプログラマブル・クロックオーバーフローの場合では、値は65536.00000であるべきです。
HOLD-INTERVAL
This is an integer which defines the number of seconds that HOLD will
count down after CLK.CLOCK has been reset. The resulting interval must be
at least as long as the maximum HELLO-INTERVAL used by any HELLO process.
HOLD-INTERVAL ThisはCLK.CLOCKがリセットされた後にHOLDが数える秒数を定義する整数です。 結果として起こる間隔はどんなHELLOによっても使用された最大のHELLO-INTERVALが処理するのと少なくとも同じくらい長いに違いありません。
3.2.3. Events and Procedures
3.2.3. 出来事と手順
INCREMENT-CLOCK Event
This event is evoked as the result of a tick interrupt, in the case of a
line clock, or a counter overflow, in the case of the 1000-Hz clock. It
causes the logical clock to be incremented by the value of CLOCK-TICK.
INCREMENT-CLOCK Event This出来事はカチカチする音中断の結果として喚起されます、線時計の場合、またはカウンタオーバーフローで、1000Hzの時計の場合で。 それで、CLOCK-TICKの値で論理的な時計を増加します。
1. Add the value of CLOCK-TICK to CLK.CLOCK.
1. CLOCK-TICKの価値をCLK.CLOCKに高めてください。
ADJUST-CLOCK Event
This event is evoked once every ADJUST-INTERVAL milliseconds to slew the
apparent clock time to the actual clock time as set by the SET-CLOCK
procedure. This is done by subtracting a fraction of the correction
factor CLK.DELTA from the value of CLK.DELTA and adding the same fraction
to CLK.CLOCK. This continues until either the next SET-CLOCK call or
CLK.DELTA has been reduced to zero.
ADJUST-CLOCK Event This出来事が一度喚起される、あらゆる、どっさりの見かけのクロック・タイムから実際のSET-CLOCK手順で決められるクロック・タイムまでのADJUST-INTERVALミリセカンド。 CLK.DELTAと同じ断片を加える値からCLK.CLOCKまで修正率CLK.DELTAの部分を引き算することによって、これをします。 次のSET-CLOCKが呼ぶか、またはCLK.DELTAがゼロまで減少するまで、これは続きます。
The suggested values for ADJUST-INTERVAL and ADJUST-FRACTION
represent a maximum slew rate of less than +-2 milliseconds per
second, in the case of 1000-Hz clock. The action is to smooth
noisy clock corrections received from neighboring systems to
obtain a high-quality local reference, while insuring the apparent
clock time is always monotonically increasing.
ADJUST-INTERVALとADJUST-FRACTIONのための提案された値は+-2最大のスルー・レートの以下を何1秒あたりのミリセカンドも表します、1000Hzの時計の場合で。 動作は見かけのクロック・タイムが単調にいつも増加しているのを保障している間に高品質なローカルの参照を得るために隣接しているシステムから受けられた騒がしい時計修正を整えることです。
1. Shift the 48-bit value of CLK.DELTA arithmetically ADJUST-FRACTION
bits to the right, discarding bits from the right and saving the
result in a temporary variable F. Assuming the decimal point of F to
be positioned to the right of bit 16 and sign-extending as necessary,
subtract F from CLK.DELTA and add F to CLK.CLOCK.
1. CLK.DELTAの48ビットの値を算術で移動させてください。必要に応じて権利と置かれるために一時的な可変F.Assumingの結果にFの小数点を保存するのからビット16とサイン広がりの権利までビットを捨てて、右へのADJUST-FRACTIONビットは、CLK.DELTAからFを引き算して、CLK.CLOCKにFを加えます。
DCN Local-Network Protocols Page 16 D.L. Mills
16ページ D.L.が製粉するDCN企業内情報通信網プロトコル
DECREMENT-HOLD Event
This event is evoked once per second to decrement the value of HOLD.
DECREMENT-HOLD Event This出来事は、HOLDの値を減少させるために1秒に一度喚起されます。
1. If the value of HOLD is zero, do nothing; otherwise, decrement its
value.
1. HOLDの値がゼロであるなら、何もしないでください。 さもなければ、値を減少させてください。
READ-CLOCK Procedure
時計を読んでいる手順
This procedure is called by a client process. It returns the apparent
time-of-day computed as the integer part of the sum CLK.CLOCK plus
CLK.COUNT. Note that the precision of the value returned is limited to
+-1 millisecond, so that client processes must expect the apparent
time to "run backward" occasionally due to drift corrections. When
this happens the backward step will never be greater than one
millisecond and will never occur more often than twice per second.
この手順はクライアント工程で呼ばれます。 それは合計CLK.CLOCKとCLK.COUNTの整数部として計算された見かけの時刻を返します。 価値の精度が戻ったというメモは+-1ミリセカンドに制限されます、クライアントの過程がドリフト修正のため時折「背走する」見かけの時間を予想しなければならないように。 これが起こると、後方のステップは、決して1ミリセカンド以上でなく、決して起こらないために1秒あたり2倍よりしばしば望むでしょう。
1. In the case of line clocks CLK.COUNT is always zero, while in
the case of programmable clocks the hardware must be
interrogated to extract the value of CLK.COUNT. If following
interrogation a counter-overflow condition is evident, add
CLOCK-TICK to CLK.CLOCK and interrogate the hardware again.
1. 線時計の場合では、いつもCLK.COUNTはゼロです、プログラマブル・クロックの場合では、CLK.COUNTの値を抽出するためにハードウェアについて査問しなければなりませんが。 査問に続いて、カウンタオーバーフロー条件が明白であるなら、CLK.CLOCKにCLOCK-TICKを加えてください、そして、もう一度ハードウェアについて査問してください。
2. When the value of CLK.COUNT has been determined compute the sum
CLK.COUNT + CLK.CLOCK. If this sum exceeds the number of
milliseconds in 24 hours (86,400,000), reduce CLK.CLOCK by
86,400,000, set HOLD-INTERVAL -> HOLD, set CLOCK-VALID (bit 15
of DATE) to one, roll over DATE to the next calendar day and
start over. If not, return the integer part of the sum as the
apparent time-of-day.
2. CLK.COUNTの値が決定しているときには、合計CLK.COUNT+CLK.CLOCKを計算してください。 この合計が24時間(86,400,000)のミリセカンドの数を超えているなら、CLK.CLOCKを8640万減少させてください、そして、HOLD-INTERVAL->HOLDを設定してください、そして、CLOCK-VALID(DATEのビット15)を1つに設定してください、そして、DATEを次のカレンダー日までひっくり返らせてください、そして、やり直してください。そうでなければ、見かけの時刻として合計の整数部を返してください。
The CLOCK-VALID bit is set to insure that a master-clock update is
received at least once per day. Note that, in the case of
uncompensated crystal oscillators of the type commonly used as the
1000-Hz time base, a drift of several parts per million can be
expected, which would result in a time drift of several tenths of a
second per day, if not corrected.
CLOCK-VALIDビットが、マスタークロックアップデートが1日単位で少なくとも一度受けられるのを保障するように設定されます。 1000Hzの時間ベースとして一般的に使用されるタイプの非代償された水晶発振器の場合で数個の100万あたりの部品のドリフト(1日あたり1秒のいくつかの10分の1の時間ドリフトをもたらす)を予想できることに注意してください、修正されないなら。
SET-CLOCK Procedure
This procedure is called by a client process. It sets a time-of-day
correction factor in milliseconds. The argument represents a 32-bit
signed fixed-point quantity with decimal point to the right of bit
0 that is to be added to CLK.CLOCK so that READ-CLOCK subsequently
returns the actual time-of-day.
SET-CLOCK Procedure This手順はクライアント工程で呼ばれます。 それはミリセカンドで時刻修正率を設定します。 議論が小数点でCLK.CLOCKに加えられることになっているビット0の右に32ビットのサインされた定点量を表すので、READ-CLOCKは次に、実際の時刻を返します。
1. If the correction factor is in the range -2**(16-ADJUST-FRACTION) to
+2**(16-ADJUST-FRACTION) - 1 (about +-128 milliseconds with the
suggested value of ADJUST-FRACTION), the value of the argument
replaces CLK.DELTA and the procedure is complete. If not, add the
value of the sign-extended argument to CLK.CLOCK and set CLK.DELTA to
zero. In addition, set HOLD-INTERVAL -> HOLD, since this
represents a relatively large step-change in apparent time.
The value of HOLD represents the remaining number of seconds
in which timestamps should be considered invalid and is used
by the HELLO process to suppress roundtrip delay calculations
which might involve invalid timestamps.
DCN Local-Network Protocols Page 17
D.L. Mills
1. +2**(16-ADJUST-FRACTION)には修正率が範囲2**(16-ADJUST-FRACTION)にあります--1(ADJUST-FRACTIONの提案された値をもっている+-128ミリセカンドに関する)、引数の値がCLK.DELTAを取り替えて、手順が完全であるなら。 そうでなければ、サインで拡張している引数の価値をCLK.CLOCKに高めてください、そして、ゼロにCLK.DELTAを設定してください。 さらに、これが見かけの時間で比較的大きい階段状変化を表すので、HOLD-INTERVAL->HOLDを設定してください。 HOLDの値は、タイムスタンプが無効であると考えられるべきである秒の残っている数を表して、無効のタイムスタンプにかかわるかもしれない往復の遅れ計算を抑圧するのにHELLO工程で使用されます。 17ページ D.L.が製粉するDCN企業内情報通信網プロトコル
3.3. HELLO Process
3.3. こんにちは、過程
The HELLO process maintains clock synchronization with a neighbor
HELLO process using the HELLO protocol. It also participates in the
routing algorithm. There is one HELLO process and one set of local
state variables for each link connecting the host to one of its
neighbors.
HELLOの過程はHELLOプロトコルを使用する隣人HELLOの過程との時計同期を維持します。 また、それはルーティング・アルゴリズムに参加します。 1つのHELLOの過程と1セットの各リンクへの隣人のひとりのホストに接するローカルの州の変数があります。
3.3.1. Local variables
3.3.1. 局所変数
HLO.BROADCAST
This is a one-bit switch state variable. When set to zero a
point-to-point link is assumed. When set to one a broadcast (e.g.
Ethernet) link is assumed.
HLO.BROADCAST Thisは1ビットのスイッチ州の変数です。 ゼロに設定されると、ポイントツーポイント接続は想定されます。 1つに設定されると、放送(例えば、イーサネット)リンクは想定されます。
HLO.KEEP-ALIVE
This is an eight-bit counter state variable used to indicate whether the
link is up. It is initialized with a value of zero.
HLO.KEEP-ALIVE Thisはリンクが上がっているかどうかを示すのに使用される8ビットのカウンタ州の変数です。 それはゼロの値で初期化されます。
HLO.LENGTH
This is a 16-bit integer state variable used to record the length in
octets of the last HELLO message sent.
HLO.LENGTH ThisはHELLOメッセージが送った最終八重奏に長さを記録するのに使用される16ビットの整数州の変数です。
HLO.NEIGHBOR-ADDRESS
This is a 32-bit integer state variable used to contain the neighbor host
Internet address.
HLO.NEIGHBOR-ADDRESS Thisは隣人ホストインターネット・アドレスを含むのに使用される32ビットの整数州の変数です。
HLO.PID
This is an eight-bit integer state variable used to identify the
net-output process associated with this HELLO process. It is initialized
by the kernel when the process is created and remains unchanged
thereafter.
HLO.PID ThisはこのHELLOの過程に関連している純生産高の過程を特定するのにおいて中古の8ビットの整数州の変数です。 過程は作成されて、その後変わりがないとき、それはカーネルによって初期化されます。
HLO.POLL
This is a one-bit switch state variable. When set the HELLO process
spontaneously sends HELLO messages. When not set the HELLO process
responds to HELLO messages, but does not send them spontaneously.
HLO.POLL Thisは1ビットのスイッチ州の変数です。 設定されると、HELLOの過程は自然にメッセージをHELLOに送ります。 設定されない場合、HELLOの過程は、HELLOメッセージに応じますが、自然にそれらを送りません。
HLO.TIMESTAMP
This is a 32-bit integer temporary variable used to record the time of
arrival of a HELLO message.
HLO.TIMESTAMP ThisはHELLOメッセージの到着時刻を記録するのに使用される32ビットの整数一時的数値変数です。
HLO.TSP
This is a 16-bit signed integer state variable used in roundtrip delay
calculations.
HLO.TSP Thisは往復の遅れ計算に使用される16ビットのサインされた整数州の変数です。
DCN Local-Network Protocols Page 18 D.L. Mills
18ページ D.L.が製粉するDCN企業内情報通信網プロトコル
3.3.2. Parameters
3.3.2. パラメタ
HELLO-INTERVAL
This is an integer which defines the interval in seconds between HELLO
messages. It ranges from about eight to a maximum of 30 seconds,
depending on line speed.
HELLO-INTERVAL ThisはHELLOメッセージの間の秒に間隔を定義する整数です。 ライン・スピードによって、それはおよそ8〜最大30秒まで及びます。
HOLD-DOWN-INTERVAL
This is an integer which defines the interval in seconds a host will be
considered up following receipt of a HELLO message indicating that
host is up. A value of 120 is suggested.
HOLD-DOWN-INTERVAL Thisは整数です(ホストが考えられる秒のホストが起きているのを示すHELLOメッセージの領収書に従う間隔を定義します)。 120の値は示されます。
KEEP-ALIVE-INTERVAL
This is an integer which defines the interval, in units of
HELLO-INTERVAL, that a HELLO process will consider the link up. A
value of four is suggested.
KEEP-ALIVE-INTERVAL Thisは間隔を定義する整数です、ユニットのHELLO-INTERVALでそのa HELLOの過程はリンクが上であると考えるでしょう。 4の値は示されます。
MAXDELAY
This is an integer which defines the maximum roundtrip delay in
seconds on a path to any reachable host. A value of 30 is suggested.
MAXDELAY Thisは経路の秒に最大の往復の遅れをどんな届いているホストとも定義する整数です。 30の値は示されます。
MINDELAY
This is an integer which defines the minimum switching threshold in
milliseconds below which routes will not be changed. A value of 100 is
suggested.
MINDELAY Thisはルートが変えられないミリセカンドで最小の切り換え敷居を定義する整数です。 100の値は示されます。
3.3.3. Events and Procedures
3.3.3. 出来事と手順
INPUT-PACKET Event
When a packet arrives the net-input process first sets HLO.TIMESTAMP to
the value returned by the READ-CLOCK procedure, then checks the
packet for valid local leader, IP header format and checksum. If
the protocol field in the IP header indicates a HELLO message, the
packet is passed to the HELLO process. If any errors are found
the packet is dropped.
INPUT-PACKET Event When aパケットは到着します。READ-CLOCK手順で返された値へのネットの入力処理第一セットHLO.TIMESTAMP、有効な地元のリーダー、IPヘッダー形式、およびチェックサムのためのパケットはその時、チェックします。 IPヘッダーのプロトコル分野がHELLOメッセージを示すなら、パケットはHELLOの過程に通過されます。 何か誤りが見つけられるなら、パケットは落とされます。
The HELLO process first checks the packet for valid HELLO header format
and checksum. If any errors are found the packet is dropped. Otherwise,
it proceeds as follows:
HELLOの過程は最初に、有効なHELLOヘッダー形式とチェックサムがないかどうかパケットをチェックします。 何か誤りが見つけられるなら、パケットは落とされます。 さもなければ、以下の通り、続きます:
1. If PKT.SOURCE is equal to LOCAL-ADDRESS, then the line to the
neighbor host is looped. If this is a broadcast link
(HLO.BROADCAST is set to one), then ignore this nicety; if
not, this is considered an error and further processing is
abandoned. Note that, in special configurations involving
other systems (e.g. ARPANET IMPs and gateways) it may be
useful to use looped HELLO to monitor connectivity. The DCN
implementation provides this feature, but is not described here.
1. PKT.SOURCEがLOCAL-ADDRESSと等しいなら、隣人ホストへの線は輪にされます。 これが放送リンク(HLO.BROADCASTは1つに用意ができている)であるなら、この正確さを無視してください。 そうでなければ、これは誤りであると考えられます、そして、さらなる処理は捨てられます。 接続性をモニターするのに輪にされたHELLOを使用するために役に立った状態でそれが他のシステムであるかもしれないこと(例えば、アルパネットIMPsとゲートウェイ)にかかわる特別な構成でそれに注意してください。 DCN実現は、この特徴を提供しますが、ここで説明されません。
2. Set KEEP-ALIVE-INTERVAL -> HLO.KEEP-ALIVE. This indicates the
maximum number of HELLO intervals the HLO.TSP field is
considered valid.
2. 間隔を生かしている生きている->HLO.KEEPを設定してください。 これは、HLO.TSPがさばくHELLO間隔の最大数が有効であると考えられるのを示します。
DCN Local-Network Protocols Page 19 D.L. Mills
19ページ D.L.が製粉するDCN企業内情報通信網プロトコル
3. Set PKT.TIMESTAMP - HLO.TIMESTAMP -> HLO.TSP. This is part of the
roundtrip delay calculation. The value of HLO.TSP will be
updated and returned to the neighbor in the next HELLO message
transmitted. Next, compute the raw roundtrip delay and offset:
HLO.TIMESTAMP - PKT.TSP -> DELAY and HLO.TSP + DELAY/2 -> OFFSET.
Note: in the case of a broadcast link (HLO.BROADCAST set to one) set
DELAY to zero.
3. PKT.TIMESTAMPを設定してください--HLO.TIMESTAMP->HLO.TSP。 これは往復の遅れ計算の一部です。 送られた次のHELLOメッセージの隣人にHLO.TSPの値をアップデートして、返すでしょう。 次に、生の往復の遅れを計算してください、そして、相殺してください: HLO.TIMESTAMP--PKT.TSP->遅れとHLO.TSP+遅れ/2->は相殺されます。 以下に注意してください。 放送リンク(HLO.BROADCASTは1つにセットした)の場合では、ゼロにDELAYを設定してください。
4. Perform this step only in the case of non-broadcast links
(HLO.BROADCAST set to zero). If PKT.SOURCE is not equal to
HLO.NEIGHBOR-ADDRESS, then a new neighbor has appeared on this
link. Set PKT.SOURCE -> HLO.NEIGHBOR ADDRESS, MAXDELAY ->
DELAY and proceed to the next step. This will force the line
to be declared down and result in a hold-down cycle.
Otherwise, if either PKT.TSP is zero or HOLD is nonzero, then
the DELAY calculation is invalid and further processing is
abandoned. Note that a hold-down cycle is forced in any
case if a new neighbor is recognized.
4. 非放送リンクの場合だけでこのステップを実行してください(HLO.BROADCASTはゼロにセットします)。 PKT.SOURCEがHLO.NEIGHBOR-ADDRESSと等しくないなら、新しい隣人はこのリンクの上に現れました。 PKT.SOURCE->HLO.NEIGHBOR ADDRESS、MAXDELAY->DELAYを設定してください、そして、次のステップに進んでください。 これは、申告される線を押し込んで、抑制サイクルで結果として生じるでしょう。 さもなければ、DELAY計算はPKT.TSPがゼロであるかHOLDが非零であるなら無効です、そして、さらなる処理は捨てられます。 新しい隣人が見分けられるならどのような場合でも、抑制サイクルが強制されることに注意してください。
5. If processing reaches this point the DELAY and OFFSET
variables can be assumed valid as well as the remaining data
in the packet. First, if DELAY < MINDELAY, set MINDELAY ->
DELAY. This avoids needless path switching when the
difference in delays is not significant and has the effect
that on low-delay links the routing algorithm degenerates to
min-hop rather than min-delay. Then set HLO.PID -> PID. There are
two cases:
5. 処理がこのポイントのDELAYとOFFSETに達するなら、パケットの残っているデータと同様に有効であると変数を思うことができます。 まず最初に、DELAY<MINDELAYであるならMINDELAY->DELAYを設定してください。 これは、分遅れよりむしろ、遅れの違いが重要でないときに、不必要な経路の切り換えを避けて、低い遅れリンクの上では、ルーティング・アルゴリズムが分ホップに退化しているという効果を持っています。 その時、HLO.PID->PIDはセットしました。 2つのケースがあります:
Case 1: PKT.NHOSTS is zero.
This will be the case when the neighbor host has just come up or
is on a different net or subnet. Set NEIGHBOR-ADDRESS -> ADDRESS
and call the ROUTE procedure, which will return the host
ID. Then call the UPDATE procedure. In the case of
errors, do nothing but return.
ケース1: PKT.NHOSTSはゼロです。 これは、隣人ホストがちょうど来たところなときのケースであるか異なったネットかサブネットにあります。 NEIGHBOR-ADDRESS->ADDRESSを設定してください、そして、ROUTE手順に電話をしてください。(それは、ホストIDを返すでしょう)。 そして、UPDATE手順に電話をしてください。 誤りの場合では、単に戻ってください。
Case 2: PKT.NHOSTS is nonzero.
This is the case when the neighbor host is on the same net or
subnet. First, save the values of DELAY and OFFSET in temporary
variables F and G. Then, for each value of HID from zero to
NHOSTS-1 consider the corresponding PKT.HOSTS-TABLE entry and do
the following: Set F + PKT.HOST-TABLE.DELAY -> DELAY and
G + PKT.HOST-TABLE.OFFSET -> OFFSET and call the UPDATE procedure.
This completes processing.
ケース2: PKT.NHOSTSは非零です。 隣人ホストが同じネットかサブネットにいるとき、これはそうです。 まず最初に、一時的数値変数FとG.ThenでDELAYとOFFSETの値を節約してください、そして、ゼロ〜NHOSTS-1までのHIDの各値のために、対応するPKT.HOSTS-TABLEエントリーを考えてください、そして、以下をしてください: F+PKT.HOST-TABLE.DELAY->DELAYとG+PKT.HOST-TABLE.OFFSET->OFFSETを設定してください、そして、UPDATE手順に電話をしてください。 これは、処理するのを完了します。
ROUTE Procedure
This procedure returns the host ID in HID of the host represented
by the global variable ADDRESS.
ROUTE Procedure This手順は大域変数ADDRESSによって代理をされたホストのHIDでホストIDを返します。
1. First, determine if the host represented by ADDRESS is on the same
local net as LOCAL-ADDRESS. For the purposes of this
comparison bits 0-7 and 16-31 are compared for class-A nets
and bits 8-31 are compared for class-B and class-C nets. This
provides for a subnet capability, where the bits 0-7 and 16-23
(class-A) or 8-15 (class-B) are used as a subnet number.
DCN Local-Network Protocols Page 20
D.L. Mills
1. まず最初に、ADDRESSによって代理をされたホストがLOCAL-ADDRESSと同じローカルのネットにいるか決定してください。 この比較ビット0-7と16-31の目的がクラスAネットのために比較されて、ビット8-31がクラスBとクラスCネットのために比べるので。 または、これがビット0-7と16-23をサブネット能力、どこに提供するか、(クラスa)、8-15(クラスB) サブネット番号として、使用されます。 20ページ D.L.が製粉するDCN企業内情報通信網プロトコル
Case 1: The host is on the same net or subnet.
Extract the address field of ADDRESS, subtract ADDRESS-OFFSET and
store the result in HID. If 0 <= HID < NHOSTS, the procedure
completes normally; otherwise it terminates in an error
condition.
ケース1: ホストは同じネットかサブネットにいます。 ADDRESSのアドレス・フィールドを抽出してください、そして、ADDRESS-OFFSETを引き算してください、そして、HIDに結果を格納してください。 0<がHID<NHOSTS、手順と等しい、通常、完成します。 さもなければ、それはエラー条件で終わります。
Case 2: The host is not on the same net or subnet.
Search the NET-TABLE for a match of the net fields of
LOCAL-ADDRESS and NET-TABLE.NET. If found set
NET-TABLE.HID -> HID and return normally. If the NET-TABLE.NET
field is zero, indicating the last entry in the table, set
HET-TABLE.HID -> HID and return normally. Note that, in the case
of hosts including GGP/EGP gateway modules, if no match is found
the procedure terminates in an error condition.
ケース2: ホストは同じネットかサブネットにいません。 LOCAL-ADDRESSとネット-TABLE.NETのネットの分野のマッチのためにネット-TABLEを捜してください。 見つけられるなら、通常、ネット-TABLE.HID->HIDとリターンを設定してください。 テーブルにおける最後のエントリーを示して、ネット-TABLE.NET分野がゼロであるなら、通常、HET-TABLE.HID->HIDとリターンを設定してください。 マッチが全く見つけられないなら手順がGGP/EGPゲートウェイモジュールを含むホストの場合でエラー条件で終わることに注意してください。
UPDATE Procedure
This procedure updates the entry of HOST-TABLE indicated by HID using
three global variables: DELAY, OFFSET and PID. Its purpose is to update
the HOST-TABLE entry corresponding to host ID HID. In the following all
references are to this entry.
UPDATE Procedure This手順は3つの大域変数を使用することでHIDによって示されたHOST-TABLEのエントリーをアップデートします: オフセットとPID、延着してください。 目的はホストID HIDにおいて、対応するHOST-TABLEエントリーをアップデートすることです。 このエントリーには以下でのすべての参照があります。
1. If PID is not equal to HOST-TABLE.PID, the route to host HID is not
via the net-output process associated with this HELLO process. In
this case, if DELAY + MINDELAY > HOST-TABLE.DELAY, the path is longer
than one already in HOST-TABLE, so the procedure does nothing.
1. PIDがHOST-TABLE.PIDと等しくないなら、ホストHIDへのルートはこのHELLOの過程に関連している純生産高の過程を使用しません。 この場合、経路がDELAY+MINDELAY>HOST-TABLE.DELAYであるなら、1より長い間既にHOST-TABLEにあるので、手順は何もしません。
2. This step is reached only if either the route to host HID is via the
net-output process associated with this HELLO process or the newly
reported path to this host is shorter by at least MINDELAY.
There are two cases:
2. ホストHIDへのルートがこのHELLOの過程に関連している純生産高の過程を使用するか、またはこのホストへの新たに報告された経路が少なくともMINDELAYで、より短い場合にだけ、このステップに達しています。 2つのケースがあります:
Case 1: HOST-TABLE.DELAY < MAXDELAY.
The existing path to host HID is up and this is a point-to-point
link (HLO.BROADCAST is set to zero). If DELAY < MAXDELAY the
newly reported path is also up. Proceed to the next step.
Otherwise, initiate a hold-down cycle by setting
MAXDELAY -> HOST-TABLE.DELAY and
HOLD-DOWN-INTERVAL -> HOST-TABLE.TTL and return.
ケース1: ホスト-TABLE.DELAY<MAXDELAY。 ホストHIDへの既存の経路は上がっています、そして、これはポイントツーポイント接続(HLO.BROADCASTはゼロに用意ができている)です。 また、DELAY<MAXDELAYであるなら、新たに報告された経路も上がっています。 次のステップに進んでください。 さもなければ、MAXDELAY->HOST-TABLE.DELAY、HOLD-DOWN-INTERVAL->HOST-TABLE.TTL、およびリターンを設定することによって、抑制サイクルを開始してください。
Case 2: HOST-TABLE.DELAY >= MAXDELAY.
The existing path to host HID is down. If DELAY < MAXDELAY and
HOST-TABLE.TTL is zero, the hold-down period has expired and the
newly reported path has just come up. Proceed to the next step.
Otherwise simply return.
ケース2: ホスト-TABLE.DELAY>はMAXDELAYと等しいです。 ホストHIDへの既存の経路は下がっています。 DELAY<MAXDELAYとHOST-TABLE.TTLがゼロであるなら、抑制の期間は期限が切れました、そして、新たに報告された経路はちょうど来たところです。 次のステップに進んでください。 さもなければ、単に戻ってください。
3. In this step the HOST-DELAY entry is updated. Set
DELAY -> HOST-TABLE.DELAY, HOLD-DOWN-INTERVAL -> HOST-TABLE.TTL and
HLO.PID -> HOST-TABLE.PID.
3. このステップでは、HOST-DELAYエントリーをアップデートします。 遅れ->ホスト-TABLE.DELAY、間隔の下側への保持->ホスト-TABLE.TTL、およびHLO.PID->ホスト-TABLE.PIDを設定してください。
DCN Local-Network Protocols Page 21 D.L. Mills
21ページ D.L.が製粉するDCN企業内情報通信網プロトコル
4. For precise timekeeping, the offset can be considered valid only if
the length of the last HELLO packet transmitted is equal to
the length of the last one received. Thus, if HLO.LENGTH
equal to PKT.LENGTH, set OFFSET -> HOST-TABLE.OFFSET;
otherwise, leave this field alone. Finally, if HID is equal to
CLOCK-HID and bit 15 (the DATE-VALID bit)
of DATE is zero, set PKT.DATESTAMP -> DATE and call the SET-CLOCK
procedure of the CLOCK process with argument HLO.TIMESTAMP.
4. 正確な時間保持において、伝えられた最後のHELLOパケットの長さが、あるものが受けた最終長さと等しい場合にだけ、有効であるとオフセットを考えることができます。 したがって、PKT.LENGTHと等しいHLO.LENGTHであるなら、OFFSET->HOST-TABLE.OFFSETを設定してください。 さもなければ、この分野を放っておいてください。 HIDがCLOCK-HIDと等しく、DATEのビット15(DATE-VALIDビット)がゼロであるなら最終的にPKT.DATESTAMP->DATEを設定してください、そして、HLO.TIMESTAMPに議論があるCLOCKの過程のSET-CLOCK手順に電話をしてください。
OUTPUT-PACKET Event
This event is evoked once every HELLO-INTERVAL seconds. It determines if
a HELLO message is to be transmitted, transmits it and updates state
variables.
OUTPUT-PACKET Event This出来事は一度喚起されます。あらゆるHELLO-INTERVALが後援します。 それは、HELLOメッセージが伝えられるためにあって、それを伝えて、州の変数をアップデートするかどうか決定します。
1. If HLO.KEEP-ALIVE is nonzero decrement its value.
1. HLO.KEEP-ALIVEが非零であるなら、値を減少させてください。
2. If HLO.POLL is zero and HLO.KEEP-ALIVE is zero, do not send a HELLO
message. If either is nonzero initialize the packet fields as
follows: LOCAL-ADDRESS -> PKT.SOURCE,
HLO.NEIGHBOR-ADDRESS -> PKT.DESTINATION and DATE -> PKT.DATESTAMP.
Note: PKT.DESTINATION is set to zero if this is a broadcast link
(HLO.BROADCAST set to one). Also, note that bit 15 of DATE is the
DATE-VALID bit. If this bit is one the receiver will not update its
master clock from the information in the transmitted packet.
This is significant only if the sending host is on the
least-delay path to the master clock. Set PKT.TIMESTAMP to
the value returned from the READ-CLOCK procedure. If
HLO.KEEP-ALIVE is zero or HOLD is nonzero, set PKT.TSP to
zero; otherwise, set PKT.TIMESTAMP + HLO.TSP -> PKT.TSP.
2. HLO.POLLがゼロであり、HLO.KEEP-ALIVEがゼロであるなら、HELLOメッセージを送らないでください。 どちらかが非零であるなら、以下のパケット分野を初期化してください: HLO.NEIGHBOR-アドレスのローカルアドレス->PKT.SOURCE、->PKT.DESTINATION、および日付->PKT.DATESTAMP。 以下に注意してください。 PKT.DESTINATIONはこれが放送リンク(HLO.BROADCASTは1つにセットした)であるならゼロに用意ができています。 また、DATEのビット15がDATE-VALIDビットであることに注意してください。 このビットが1であるなら、受信機は伝えられたパケットの情報からマスタークロックをアップデートしないでしょう。 マスタークロックに送付ホストが最少の遅れ経路にいる場合にだけ、これは重要です。 値へのセットPKT.TIMESTAMPはREAD-CLOCK手順から戻りました。 HLO.KEEP-ALIVEがゼロであるかHOLDが非零であるなら、ゼロにPKT.TSPを設定してください。 さもなければ、PKT.TIMESTAMP+HLO.TSP->PKT.TSPを設定してください。
3. Determine if the neighbor is on the same net or subnet. If the
neighbor is on a different net set PKT.NHOSTS to zero and
proceed with the next step. Otherwise, set NHOSTS ->
PKT.NHOSTS and for each value of HID from zero to PKT.HOSTS-1
copy the HOST-TABLE.DELAY and HOST-TABLE.OFFSET fields of the
corresponding HOST-TABLE entry in order into the packet. For
each entry copied test if the HOST-TABLE.PID field matches the
HLO.PID of the HELLO process. If so, a potential routing loop
is possible. In this case use MAXDELAY for the delay field in
the packet instead.
3. 隣人が同じネットかサブネットにいるか決定してください。 隣人が異なったネットにいるなら、PKT.NHOSTSに次のステップをゼロに合わせて、続けるように設定してください。 さもなければ、NHOSTS->PKT.NHOSTSを設定してください、そして、ゼロ〜PKT.HOSTS-1までのHIDの各値のために、パケットに整然としている対応するHOST-TABLEエントリーのHOST-TABLE.DELAYとHOST-TABLE.OFFSET分野をコピーしてください。 それぞれに関しては、HOST-TABLE.PID分野がHELLOの過程のHLO.PIDに合っているなら、エントリーはテストをコピーしました。 そうだとすれば、潜在的ルーティング輪は可能です。 この場合、パケットの遅れ分野に代わりにMAXDELAYを使用してください。
4. Finally, set HLO.LENGTH to the number of octets in the packet
and send the packet.
4. 最終的に、パケットの八重奏の数にHLO.LENGTHを設定してください、そして、パケットを送ってください。
3.4. HOST Process (HOS)
3.4. ホストの過程(HOS)
This process maintains the routing tables. It is activated once per
second to scan HOST-TABLE and decrement the HOST-TABLE.TTL field of each
entry. It also performs housekeeping functions.
この過程は経路指定テーブルを維持します。 それは、HOST-TABLEをスキャンして、それぞれのエントリーのHOST-TABLE.TTL分野を減少させるために1秒に一度動かされます。 また、それはハウスキーピング機能を実行します。
DCN Local-Network Protocols Page 22 D.L. Mills
22ページ D.L.が製粉するDCN企業内情報通信網プロトコル
3.4.1. Local variables
3.4.1. 局所変数
HOS.PID
This is an eight-bit integer used to identify the HOST process. It is
initialized by the kernel when the process is created and remains
unchanged thereafter.
HOS.PID ThisはHOSTの過程を特定するのに使用される8ビットの整数です。 過程は作成されて、その後変わりがないとき、それはカーネルによって初期化されます。
HOS.HID
This is an eight-bit temporary variable.
HOS.HID Thisは8ビットの一時的数値変数です。
3.4.2. Events and Procedures
3.4.2. 出来事と手順
SCAN Event
This event is evoked once each second to scan the HOST-TABLE and perform
housekeeping functions.
SCAN Event This出来事は、HOST-TABLEをスキャンして、ハウスキーピング機能を実行するために1秒に一度喚起されます。
1. For each value of a temporary variable F from zero to NHOSTS-1 do the
following: Set LOCAL-ADDRESS -> ADDRESS and call the ROUTE
procedure, which will return the host ID HID. If F is equal
to HID, then set both DELAY and OFFSET to zero, HOS.PID -> PID
and call the UPDATE procedure. This will cause all packets
received with the local address to be routed to this process.
1. ゼロ〜NHOSTS-1までの一時的数値変数Fの各値には、以下をしてください: LOCAL-ADDRESS->ADDRESSを設定してください、そして、ROUTE手順に電話をしてください。(それは、ホストID HIDを返すでしょう)。 FがDELAYとゼロへのOFFSET、HOS.PID->PIDの両方がHID、当時のセットと等しく、UPDATE手順を呼ぶことであるなら。 これで、ローカルアドレスで受け取られたすべてのパケットをこの過程に発送するでしょう。
If HOST-TABLE.TTL is zero skip this step. Otherwise, decrement
HOST-TABLE.TTL by one. If the result is nonzero skip the
remainder of this step. Otherwise, If HOST-TABLE.DELAY <MAXDELAY set
HOLDOFF-INTERVAL -> HOST-TABLE.TTL and MAXDELAY -> HOST-TABLE.DELAY.
The effect of this step is to declare a hold-down cycle when a host
goes down.
HOST-TABLE.TTLがゼロであるなら、このステップをサボってください。 さもなければ、HOST-TABLE.TTLを1つ減少させてください。 結果が非零であるなら、このステップの残りをスキップしてください。 さもなければ、If HOST-TABLE.DELAY<MAXDELAYはHOLDOFF-INTERVAL->HOST-TABLE.TTLとMAXDELAY->HOST-TABLE.DELAYを設定します。 このステップの効果はホストが落ちる抑制サイクルを宣言することです。
4. References
4. 参照
1. Mills, D.L. Final Report on Internet Research, ARPA Packet Switching
Program. Technical Report TSLAB 82-7, COMSAT Laboratories,
December 1982.
DCN Local-Network Protocols Page 23
D.L. Mills
1. 工場、インターネット研究、アルパパケット交換プログラムに関するD.L.最終報告書。 1982年12月の技術報告書TSLAB82-7、コムサット研究所。 23ページ D.L.が製粉するDCN企業内情報通信網プロトコル
Appendix A. Link-Level Packet Formats
付録A.リンク・レベルパケット・フォーマット
A.1. Serial Links Using Program-Interrupt Interfaces
A.1。 プログラム割込みインタフェースを使用する連続のリンク
Following is a description of the frame format used on
asynchronous and synchronous serial links with program-interrupt
interfaces such as the DEC DLV11 and DPV11. This format provides
transparency coding for all messages, including HELLO messages, but
does not provide error detection or retransmission functions. It is
designed to be easily implemented and compatible as far as possible
with standard industry protocols.
以下に、DEC DLV11やDPV11などのプログラム割込みインタフェースとの非同期で同期の連続のリンクの上に使用されるフレーム形式の記述があります。 この形式は、HELLOメッセージを含むすべてのメッセージのための透明コード化を提供しますが、誤り検出か「再-トランスミッション」機能は提供しません。 それは、標準の産業プロトコルとできるだけ容易に実行されていて互換性があるように設計されています。
The protocol is serial-by-bit, with the same interpretation on
the order of transmission as standard asynchronous and synchronous
interface devices; that is, the low-order bit of each octet is
transmitted first. The data portion of the frame consists of one
Internet datagram encoded according to a "character-stuffing"
transparency convention:
ビットに従って、プロトコルはトランスミッションの注文のときに標準の非同期で同期のインタフェース機器として同じ解釈で連続しています。 すなわち、それぞれの八重奏の下位のビットは最初に、伝えられます。 フレームのデータ部は「キャラクタを詰めるのである」透明コンベンションによると、コード化された1個のインターネットデータグラムから成ります:
一覧
スポンサーリンク
