RFC1005 日本語訳
1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP). A. Khanna,A.G. Malis. May 1987. (Format: TXT=69957 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Atul Khanna, Andy Malis
Request for Comments: 1005 BBN Communications Corp.
May 1987
ワーキンググループAtul Khannaをネットワークでつないでください、そして、アンディMalisはコメントのために以下を要求します。 1005 BBNコミュニケーション社の1987年5月
The ARPANET AHIP-E Host Access Protocol (Enhanced AHIP)
アルパネットAHIP-Eホストアクセス・プロトコル(高められたAHIP)
1. Status of this Memo
1. このMemoの状態
This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis. Distribution of this memo is unlimited. Comments on this RFC should be sent to the netmail address "ahipe@bbn.com".
このRFCはIPがMilnetやArpanetなどのアルパネットスタイルネットワークにおける使用、およびアルパネットAHIP Host Accessプロトコル(AHIP; 以前、1822として知られている)への増進のために扱うClass Aのコード化のための提案された仕様です。 これらの増進はPSN分野のサイズを増強します、と互いに演説して、ホストからPSNまでサービスのタイプ情報に関するコミュニケーションを考慮して、PSNが接続ベースのホストに混雑フィードバックを提供するのを可能にするのに論理的な名前を使用するアルパネットホストは許します。 このメモの分配は無制限です。 netmailアドレス" ahipe@bbn.com "にこのRFCのコメントを送るべきです。
Khanna & Malis [Page 1] RFC 1005 May 1987
Khanna&Malis[1ページ]RFC1005 1987年5月
Table of Contents
目次
1 INTRODUCTION.......................................... 4
1つの序論… 4
2 IP ISSUES............................................. 6
2.1 Current Interpretation of Class A IP Address
Fields
................................................... 6
2.2 Requirements and Constraints Affecting New
Class A Mapping
................................................... 7
2.3 New Interpretation of IP Address Fields............. 8
2.4 Discussion of the New Mapping.......................10
2.5 Interoperability between Current AHIP and
AHIP-E
...................................................11
2 IP問題… 6 2.1 クラスのIP Addressフィールズの現在の解釈… 6 新しい状態で影響する2.2の要件と規制がマッピングを分類します… 7 2.3 IPアドレス・フィールドの新しい解釈… 8 2.4 新しいマッピングの議論…10 現在のAHIPとAHIP-Eの間の2.5相互運用性…11
3 LOGICAL ADDRESSING................................... 13
3.1 Addresses and Names................................ 13
3.2 Name Translations.................................. 14
3.2.1 Authorization and Effectiveness.................. 15
3.2.2 Translation Policies............................. 16
3.2.3 Reporting Destination Host Downs................. 17
3.3 Establishing Host-PSN Communications............... 18
3.4 Name Server........................................ 19
3 論理的なアドレシング… 13 3.1 扱って、命名します。 13 3.2 翻訳を命名してください… 14 3.2 .1の承認と有効性… 15 3.2 .2 翻訳方針… 16 3.2 .3 あて先ホストを報告するのはダウンします… 17 3.3 ホスト-PSNコミュニケーションを確立します… 18 3.4ネームサーバ… 19
4 OTHER CHANGES........................................ 20
4.1 Type-of-Service Specification...................... 20
4.2 Subnet Congestion Feedback......................... 21
4.3 Precedence Level Information....................... 21
4 他の変化… 20 4.1 サービスのタイプ仕様… 20 4.2 サブネット混雑フィードバック… 21 4.3 先行レベル情報… 21
5 FORMATS FOR NEW AHIP-E MESSAGES...................... 23
5.1 Host-to-PSN AHIP-E Leader Format................... 23
5.2 PSN-to-Host AHIP-E Leader Format................... 27
5 新しいAHIP-Eメッセージのために、フォーマットします。 23 5.1 ホストからPSN AHIP Eへのリーダー形式… 23 5.2 PSNからホストへのAHIP-Eリーダー形式… 27
6 AHIP-E VERSIONS...................................... 33
6 AHIP-Eバージョン… 33
7 REFERENCES........................................... 34
7つの参照箇所… 34
Khanna & Malis [Page 2] RFC 1005 May 1987
Khanna&Malis[2ページ]RFC1005 1987年5月
FIGURES
図
2.1 IP Class A Mapping................................... 6
2.2 New Class A IP Address Interpretation................ 8
2.3 AHIP-E Address and Name.............................. 9
3.1 Current AHIP Address Format......................... 13
3.2 AHIP-E Address Format............................... 14
3.3 Logical Name Format................................. 14
5.1 Host-to-PSN AHIP-E Leader Format.................... 23
5.2 NDM Message Format.................................. 25
5.3 PSN-to-Host AHIP-E Leader Format.................... 27
5.4 Name Server Reply Format............................ 30
2.1IPクラスAマッピング… 2.2の新しいクラスIPあたり6は解釈を扱います… 8 2.3のAHIP-Eアドレスと名… 9 3.1の現在のAHIPアドレス形式… 13 3.2AHIP-Eアドレス形式… 14 3.3 論理的な名前形式… 14 5.1 ホストからPSN AHIP Eへのリーダー形式… 23 5.2 NDMメッセージ・フォーマット… 25 5.3 PSNからホストへのAHIP-Eリーダー形式… 27 5.4 ネームサーバ回答形式… 30
Khanna & Malis [Page 3] RFC 1005 May 1987
Khanna&Malis[3ページ]RFC1005 1987年5月
1 INTRODUCTION
1つの序論
This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the AHIP Protocol (AHIP is the preferred term for what has previously been known as the 1822 protocol). These enhancements and modifications are partially motivated by a need to overcome the current address limitation of 256 PSNs per network and by a desire to allow hosts to take advantage of logical addressing with minimal change to their AHIP software. This enhanced AHIP protocol will be referred to as "AHIP-E". These enhancements will:
このRFCはIPがMilnetやArpanetなどのアルパネットスタイルネットワークにおける使用、およびAHIPプロトコルへの増進のために扱うClass Aのコード化のための提案された仕様(AHIPは以前に1822年のプロトコルとして知られていることのための優先使用語である)です。 これらの増進と変更は1ネットワークあたり256PSNsの現在のアドレスの限界を克服する必要性とホストが彼らのAHIPソフトウェアへの最小量の変化に伴う論理的なアドレシングを利用するのを許容する願望によって部分的に動機づけられています。 この高められたAHIPプロトコルは「AHIP-E」と呼ばれるでしょう。 これらの増進はそうするでしょう:
1. Increase the size of the PSN field to 10 bits.
1. PSN分野のサイズを10ビットまで増強してください。
2. Allow hosts to use logical names (i.e., host names that are
independent of physical location on the network) in addition to
physical port addresses to communicate with each other.
2. ホストに物理的なポートアドレスに加えて論理的な名前(すなわち、ネットワークで物理的な位置から独立しているホスト名)を使用させて、互いにコミュニケートしてください。
3. Enable the host to specify a type-of-service to the PSN.
3. ホストがサービスのタイプをPSNに指定するのを可能にしてください。
4. Provide a mechanism for the PSN to communicate subnetwork
congestion information to the host on a destination host basis.
This will give the host an opportunity to selectively reduce
its congesting flows, thus preventing all of its flows from
being blocked b y the network. Currently, a host has no way of
knowing which of its flows is experiencing congestion;
consequently, it is possible that one congesting flow can
result in the blocking of all the host's flows .
4. メカニズムを提供して、PSNはサブネットワーク混雑情報をあて先ホストベースのホストに伝えてください。 これは流れて、その結果、流れのすべてが妨げられたb yであることを防ぎながら充血を選択的に減少させる機会をホストに与えるでしょう。ネットワーク。 現在、ホストには、流れについて混雑を経験することである知る方法が全くありません。 その結果、流れを充血させるそれがすべてのホストの流れのブロッキングをもたらすことができるのは、可能です。
5. Enable the PSN to inform the host about changes in precedence
cutoff levels and about precedence level violations.
5. PSNが先行締切りのレベルにおける変化の周りと、そして、先行レベル違反の周りに関してホストに知らせるのを可能にしてください。
A host can take advantage of the extended and logical addressing capabilities without making substantial changes to its AHIP implementation. In particular, the specification provides three versions of AHIP-E: version 0 is current AHIP with no changes; version 1 allows use of logical and extended addressing with minimal change to code; version 2 constitutes full-fledged AHIP-E. This is described in further detail in chapter 6.
AHIP実装への大きな変化を作らないで、ホストは広げられて論理的なアドレス指定能力を利用できます。 特に、仕様はAHIP-Eの3つのバージョンを提供します: バージョン0は変化がなければ現在のAHIPです。 バージョン1はコード化する最小量の変化に伴う論理的で拡張しているアドレシングの使用を許します。 バージョン2は完全なAHIP-Eを構成します。 これは第6章の詳細で説明されます。
This RFC's terminology is consistent with that used in BBN Report 1822 [1], and any new terms are defined when they are first used. Familiarity with Report 1822 (section 3 in particular) is assumed. As could be expected, the RFC makes many references to Report 1822. As a result, it uses, as a convenient abbreviation, "see 1822(x)" instead of "please refer to Report 1822, section x, for further details".
このRFCの用語はBBN Report1822[1]で使用されるそれと一致しています、そして、それらが最初に使用されるとき、どんな新学期も定義されます。 Report1822(特にセクション3)への親しみは想定されます。 予想できたように、RFCはReportの多くの参照を1822にします。 その結果、それは便利な略語として「Report1822を参照してください、セクションx、さらに詳しい明細については」の代わりに「1822(x)を見てください」を使用します。
Khanna & Malis [Page 4] RFC 1005 May 1987
Khanna&Malis[4ページ]RFC1005 1987年5月
The rest of this RFC is organized as follows. Chapter 2 describes the new mapping between IP class A addresses and subnetwork hosts. Chapter 3 discusses logical addressing. Chapter 4 describes the enhancements related to type-of-service and reliability specification and to congestion and precedence feedback. Chapter 5 includes a specification of the new message types and their formats. Finally, chapter 6 describes the AHIP-E version numbering scheme.
このRFCの残りは以下の通り組織化されます。 第2章はIPクラスAアドレスとサブネットワークホストの間の新しいマッピングについて説明します。 第3章 論理的なアドレシングについて議論します。 第4章はサービスのタイプと信頼性の仕様と、そして、混雑と先行フィードバックに関係づけられた増進について説明します。 第5章は新しいメッセージタイプと彼らの形式の仕様を含んでいます。 最終的に、第6章はAHIP-Eバージョンナンバリングスキームについて説明します。
Khanna & Malis [Page 5] RFC 1005 May 1987
Khanna&Malis[5ページ]RFC1005 1987年5月
2 IP ISSUES
2 IP問題
This section discusses the changes to the mapping between Class A IP addresses [5] and subnet addresses. These changes are made necessary by:
このセクションはClass A IPアドレス[5]とサブネットアドレスの間のマッピングへの変化について論じます。 以下はこれらの変更を必要にします。
1. The introduction of logical names.
1. 論理的な名前の導入。
2. The expansion of the PSN-number field.
2. PSN-ナンバーフィールドの拡張。
Note that this RFC does not affect Class B and C mappings [5].
このRFCがClass BとCマッピング[5]に影響しないことに注意してください。
2.1 Current Interpretation of Class A IP Address Fields
2.1 クラスのIP Addressフィールズの現在の解釈
Class A IP addresses are 32 bits in length, with 8 bits devoted to network number and 24 to the local address. In particular, they are of the form n.h.l.i, where n,h,l and i are decimal integers less than 256. AHIP addresses are 24 bits in length. The current ARPANET-style class A mapping is as follows (from RFC 796):
クラスA IPアドレスは長さが32ビットです、ネットワーク・ナンバーにささげられた8ビットとローカルアドレスへの24で。 それらは特に、フォームn.h.l.iのものです。そこでは、n、h、l、およびiが256未満の10進整数です。 AHIPアドレスは長さが24ビットです。 現在のアルパネットスタイルクラスAマッピングは以下の通りです(RFC796からの):
0 7 8 15 16 23 24 31
+--------+--------+-------+---------+
| net # | HOST | LH | PSN | IP Address
+--------+--------+-------+---------+
8 8 8 8
0 7 8 15 16 23 24 31 +--------+--------+-------+---------+ | ネット#| ホスト| 左手| PSN| IPアドレス+--------+--------+-------+---------+ 8 8 8 8
8 8 8
+--------+--------+--------+
| HOST | ZERO | PSN | AHIP Physical Address
+--------+--------+--------+
41 48 49 56 57 64
(bit positions in the AHIP leader)
8 8 8 +--------+--------+--------+ | ホスト| ゼロ| PSN| AHIP物理アドレス+--------+--------+--------+ 41 48 49 56 57 64 (AHIPリーダーのビット位置)
IP Class A Mapping
Figure 2.1
マッピングが2.1に計算するIPのクラス
The LH (logical host) field is used by the hosts only and is not passed to the network.
LH(論理的なホスト)野原は、ホストだけによって使用されて、ネットワークに通り過ぎられません。
Khanna & Malis [Page 6] RFC 1005 May 1987
Khanna&Malis[6ページ]RFC1005 1987年5月
2.2 Requirements and Constraints Affecting New Class A Mapping
2.2の要件と規制影響新しいクラスはマッピングです。
This section discusses some of the requirements and constraints that were considered significant in determining the new address mapping.
このセクションは新しいアドレス・マッピングを決定するのにおいて重要であると考えられた要件と規制のいくつかについて論じます。
1. Address Mapping Stability Requirement:
1. マッピングの安定性が要件であると扱ってください:
Any current IP physical address with l (logical host) = 0
should remain unchanged under the new design. For example,
the binary string corresponding to 10.0.0.51 should continue
to refer to sri-nic.arpa (assuming, of course, that sri-nic
continues to reside on psn 51, port 0). This requirement is
motivated by a desire to avoid a network-wide address
switchover.
l(論理的なホスト)があるどんな現在のIP物理アドレスも=0は新案の下において変わりがあるべきではありません。 例えば、バイナリーは10.0との対応を結びます。.0 .51は、様-nic.arpaについて言及し続けるべきです(もちろん様-nicがpsn51にずっと住んでいると仮定するのが0を移植します)。 この要件はネットワーク全体のアドレス転換を避ける願望によって動機づけられています。
2. Existing implementation compatibility:
2. 既存の実装の互換性:
Existing compliant implementations of AHIP should continue to
function for destinations with addresses fitting the
restrictions in 1. In other words, such addresses should
continue to refer to their original destinations, not only
with the AHIP-E implementation (which is the condition in 1),
but also with current ones.
AHIPの存在対応することの実装は、アドレスが1における制限に合っていて目的地に機能し続けるべきです。 言い換えれば、そのようなアドレスは、AHIP-E実装(1で状態である)で言及するだけではなく、現在のものでもそれらの元の目的地について言及し続けるべきです。
3. Compatibility between X.25's IP address to subnet host mapping
and AHIP's IP address to subnet host mapping:
3. サブネットホストマッピングへのX.25のIPアドレスと以下を写像するサブネットホストへのAHIPのIPアドレスとの互換性
The AHIP-E IP to host mapping should be able to co-exist in
some sense with the IP to host mapping specified by the DDN
X.25 Specification [6]. In particular, restricted use of the
revised IP to DDN host mapping should produce addresses that
are consistent with the current X.25 mapping. In other words,
there should be a set that includes "sufficiently many"
logical names and physical addresses, with the property that
each address/name in the set maps onto the same host under
both the AHIP and X.25 mappings.
ホストマッピングへのAHIP-E IPはIPがある何らかの意味でDDN X.25 Specification[6]によって指定されたホストマッピングに共存できるべきです。 特に、DDNホストマッピングへの改訂されたIPの制限された使用は現在のX.25マッピングと一致したアドレスを製作するべきです。 言い換えれば、セットでAHIPとX.25の両方の下の同じホストへの地図をそれぞれマッピングと扱うか、または命名する「十分多く」の論理的な名前と特性がある物理アドレスを含んでいるセットがあるべきです。
4. Maximum number of PSNs that can be supported:
4. サポートすることができるPSNsの最大数:
The new design should support a maximum of more than 256 PSNs
per network.
新案は1ネットワークあたり最大256PSNsをサポートするべきです。
Khanna & Malis [Page 7] RFC 1005 May 1987
Khanna&Malis[7ページ]RFC1005 1987年5月
2.3 New Interpretation of IP Address Fields
2.3 IPアドレス・フィールドの新しい解釈
The following is the new interpretation of the IP address field, in the context of ARPANET-style networks:
↓これはアルパネットスタイルネットワークの文脈で、IPアドレス・フィールドの新しい解釈です:
Proposed IP Address Interpretation
提案されたIPアドレス解釈
8 8 1 5 10
+--------+--------+-+-----+----------+
| net # | HOST |0|XXXXX| PSN | Physical Address
+--------+--------+-+-----+----------+
0 7 8 15 17 21 22 31
8 8 1 5 10 +--------+--------+-+-----+----------+ | ネット#| ホスト|0|XXXXX| PSN| 物理アドレス+--------+--------+-+-----+----------+ 0 7 8 15 17 21 22 31
8 8 2 6 8
+--------+--------+--+------+--------+
| net # | UPPER |11|XXXXXX| LOWER | Logical Name
+--------+--------+--+------+--------+
0 7 8 15 18 23 24 31
8 8 2 6 8 +--------+--------+--+------+--------+ | ネット#| 上側|11|XXXXXX| 下ろしてください。| 論理的な名前+--------+--------+--+------+--------+ 0 7 8 15 18 23 24 31
16 2 14
+-----------------+--+---------------+
| |10| | Reserved Format
+-----------------+--+---------------+
0 15 18 31
16 2 14 +-----------------+--+---------------+ | |10| | 予約された形式+-----------------+--+---------------+ 0 15 18 31
(X = don't care)
(X=は気にかけられません)
New Class A IP Address Interpretation
Figure 2.2
IPが解釈図2.2に演説する新しいクラス
The fields have the following meanings:
分野には、以下の意味があります:
HOST = host-number
HOSTはホスト番号と等しいです。
PSN = 10 bit PSN-number field
PSNは10ビットのPSN-ナンバーフィールドと等しいです。
UPPER = upper 8 bits of the 16-bit logical name
16ビットの論理的な名前の上側の8UPPER=ビット
LOWER = lower 8 bits of the 16-bit logical name
16ビットの論理的な名前の低級8LOWER=ビット
Khanna & Malis [Page 8] RFC 1005 May 1987
Khanna&Malis[8ページ]RFC1005 1987年5月
AHIP-E physical addresses and logical names have the following formats:
AHIP-E物理アドレスと論理的な名前には、以下の形式があります:
8 1 5 10
+--------+-+-----+----------+
| HOST |0|XXXXX| PSN | Physical Address
+--------+-+-----+----------+
41 48 55 64
(bit positions in the AHIP leader)
(X = don't care)
8 1 5 10 +--------+-+-----+----------+ | ホスト|0|XXXXX| PSN| 物理アドレス+--------+-+-----+----------+ 41 48 55 64(AHIPリーダーのビット位置)(X=は気にかけられません)
8 2 6 8
+--------+--+------+--------+
| UPPER |11|XXXXXX| LOWER | Logical Name
+--------+--+------+--------+
41 48 57 64
(bit positions in the AHIP leader)
8 2 6 8 +--------+--+------+--------+ | 上側|11|XXXXXX| 下ろしてください。| 論理的な名前+--------+--+------+--------+ 41 48 57 64 (AHIPリーダーのビット位置)
+--------+--+---------------+
| |10| | Reserved Address Format
+--------+--+---------------+
41 48 51 64
(bit positions in the AHIP leader)
+--------+--+---------------+ | |10| | 予約されたアドレス形式+--------+--+---------------+ 41 48 51 64 (AHIPリーダーのビット位置)
AHIP-E Address and Name
Figure 2.3
AHIP-Eアドレスと名前図2.3
The reserved address format is currently undefined and will be rejected by the PSN, which will return an error message (message type 6, subtype 3) to the host.
予約されたアドレス形式は、現在、未定義であり、PSNによって拒絶されるでしょう。(PSNはエラーメッセージ(メッセージタイプ6、「副-タイプ」3)をホストに返すでしょう)。
-----------------------------------------------------------------
|This design does not require the AHIP-E host to do any processing|
|of the address -- the host need only copy bits 8-31 of the IP |
|address into bits 41-64 of the AHIP leader. The host no longer |
|needs to zero out bits 49-56 of the AHIP leader. The PSN will |
|take care of the AHIP to subnet address conversion. In other |
|words, bits 8-31 of the IP address field should be passed |
|unchanged to the PSN, which interprets them exactly as shown in |
|figure 2.3. |
-----------------------------------------------------------------
----------------------------------------------------------------- |このデザインは、AHIP-Eホストがどんな処理もするのを必要としません。| |アドレス、--ホストがIPのビット8-31をコピーするだけでよい| |AHIPリーダーのビット41-64へのアドレス。 もうホスト| |AHIPリーダーの出ているビット49-56のゼロを合わせるのが必要です。 PSNはそうするでしょう。| |サブネットアドレス変換までAHIPの世話をしてください。 もう一方で| |単語、アドレス・フィールドが通り過ぎられるべきであるIPのビット8-31| |PSNに、変わりがありません。(PSNはちょうど目立つようにそれらを解釈します)。| |図2.3 | -----------------------------------------------------------------
Khanna & Malis [Page 9] RFC 1005 May 1987
Khanna&Malis[9ページ]RFC1005 1987年5月
2.4 Discussion of the New Mapping
2.4 新しいマッピングの議論
This section presents an evaluation of the design in terms of the requirements in section 2.2
このセクションはセクション2.2に要件に関してデザインの評価を提示します。
1. Address mapping stability requirement:
1. マッピングの安定性が要件であると扱ってください:
Current physical IP addresses will not have to be changed, as
long as they have been following the convention of setting LH
= 0. This ensures that bit 16 is set to 0, indicating that
the address is physical, and that the PSN number comes out
right.
現在の物理的なIPアドレスを変える必要はないでしょう、LH=0を設定するコンベンションに続いている限り。 これは、ビット16が0に設定されるのを確実にします、アドレスが物理的であり、PSN番号が外でまっすぐになりに来るのを示して。
2. Existing implementation compatibility:
2. 既存の実装の互換性:
The design meets this requirement, as the address that gets to
the PSN has its second octet = 0, which results in its correct
interpretation as a physical address.
デザインはこの必要条件を満たします、PSNを始めるアドレスが2番目の八重奏=0(物理アドレスとして正しい解釈をもたらす)を持っているとき。
3. Compatibility with the current X.25 IP address to DDN host
mapping:
3. 以下を写像するDDNホストへの現在のX.25 IPアドレスとの互換性
The current X.25 IP to HOST mapping [6] is as follows: If h <
64, the address is considered physical, i.e., it refers to
host h on PSN i. If h >= 64, the address is considered
logical, i.e., it refers to the host whose logical name is h
concatenated with i.
[6]を写像するHOSTへの現在のX.25 IPは以下の通りです: h<64であるなら、アドレスは物理的であると考えられます、すなわち、それはPSN iの上のホストhを呼びます。 h>=64であるなら、アドレスは論理的であると考えられます、すなわち、それは論理的な名前がiで連結されたhであるホストを呼びます。
The design is compatible in a limited sense with the current
X.25 logical addressing implementation, as long as logical
names are assigned such that host-number > 63 (also PSN-number
< 256 which is automatic, given the 16-bit size of the logical
name field) and physical addresses are in the range host-
number < 64 and PSN- number < 256, with the appropriate
setting of bits 16 and 17 of the IP address field. This works
because the X.25 mapping ignores the value of the l field,
i.e., the third IP address octet.
デザインは狭い意味で現在のX.25論理的なアドレシング実装と互換性があります、論理的な名前がホスト番号>63(論理的な名前欄の16ビットのサイズを考えて、自動であるPSN-数の<256も)と物理アドレスが64とPSN No.<256の範囲ホスト数の<にあるように割り当てられる限り、IPアドレス・フィールドのビット16と17の適切な設定で。 X.25マッピングがすなわち、l分野、3番目のIPアドレス八重奏の値を無視するので、これは働いています。
Given the desire to be able to address more than 64 hosts
physically and for PSN numbers > 255, this address assignment
restriction should not be considered permanent, but rather as
an interim compromise until the hosts' X.25 implementations
are revised to incorporate the new mapping between IP and DDN
addresses.
物理的とPSNのために64人以上のホストに演説できる願望を考えて、>255、このアドレス課題制限がそうするべきである数は、永久的であることは考えられませんが、IPとDDNアドレスの間の新しいマッピングを取り入れるためにむしろ当座のホストのX.25実装までの感染として改訂されます。
Khanna & Malis [Page 10] RFC 1005 May 1987
Khanna&Malis[10ページ]RFC1005 1987年5月
4. Maximum number of PSNs that can be supported:
4. サポートすることができるPSNsの最大数:
The design allows addressing of up to 1024 PSNs per network.
デザインは、扱うのを1ネットワークあたり最大1024PSNsを許容します。
2.5 Interoperability between Current AHIP and AHIP-E
2.5 現在のAHIPとAHIP-Eの間の相互運用性
This section discusses the interoperability between hosts using current AHIP and AHIP-E. It also discusses the general issue of current AHIP host operation in the AHIP-E addressing environment.
このセクションは、現在のAHIPとAHIP-Eを使用することでホストの間の相互運用性について論じます。 また、それは環境を扱うAHIP-Eにおける現在のAHIPホスト操作の一般答弁について議論します。
The proposed modifications to AHIP have been designed with backward compatibility in mind. However, note that bits 41-64 of the PSN-to-host leader (see 1822(3.4)) will always contain the physical address of the source host. This means that an error could occur when a host on a PSN numbered greater than 255 attempts to send a message to a host running a current AHIP implementation, which interprets the address of the source host as one with PSN-number < 256.
AHIPへの提案された変更は念頭に後方の互換性で設計されています。 しかしながら、ビット41-64のPSNからホストへのそのリーダーに注意してください。(1822(3.4))がいつも送信元ホストの物理アドレスを含むのを確実にしてください。 これは、PSNの上のホストが現在のAHIP実装を実行するホストにメッセージを送る255以上の試みに付番したとき、誤りが発生できたことを意味します、1としてPSN-数の<256で送信元ホストのアドレスを解釈するどれ。
There are other possibilities for errors, caused by incorrect address translation between IP and current AHIP:
他の可能性がIPと現在のAHIPの間の不正確なアドレス変換で引き起こされた誤りによってあります:
1. A host running current AHIP cannot physically address
any host on a PSN numbered greater than 255 (see Figure
3.1). Consequently, an error will result if the host
attempts to use an address from the NIC host table that
has PSN-number > 255.
1. ホストの実行している現在のAHIPは物理的にPSNの上のどんなホストにも番号付の255以上を扱うことができません(図3.1を見てください)。 その結果、ホストが、PSN-数の>255を持っているNICホストテーブルからのアドレスを使用するのを試みると、誤りは結果として生じるでしょう。
2. If a host running current AHIP attempts to use a
logical name that it might have in its host table, an
error will occur. This is because the logical name flag
bits 16 and 17 of the IP address, bits 49 and 50 of the
AHIP leader. Recal that bits 49 - 56 of the AHIP
leader get set to zero with current AHIP (see figure
2.1).
2. ホストの実行している現在のAHIPが、それがホストテーブルに持っているかもしれない論理的な名前を使用するのを試みると、誤りは発生するでしょう。 これは論理的な名前がIPアドレスのビット16と17に旗を揚げさせるからです、AHIPリーダーのビット49と50。 AHIPリーダーのビット49--56が手に入れるRecalは現在のAHIPと共にゼロにセットしました(2.1が計算するのを確実にしてください)。
Since these errors cannot be detected by the subnetwork, it is essential that all hosts implement at least version 1 AHIP-E (see chapter 6) before PSN numbers over 255 and logical names are assigned.
サブネットワークでこれらの誤りを検出できないので、PSN No.より多くの255と論理的な名前が割り当てられる前に、すべてのホストが、少なくともバージョン1がAHIP-Eであると実装するのは(第6章を見てください)、不可欠です。
Khanna & Malis [Page 11] RFC 1005 May 1987
Khanna&Malis[11ページ]RFC1005 1987年5月
Another aspect of interoperability has to do with the IP LH field, which is currently used by a handful of Arpanet hosts to demultiplex a single host port. The 5 don't-care bits of the physical IP address (bits 17- 21) and the 6 don't-care bits of the IP logical name (bits 18-23) can be used for this purpose -- in particular, the use of these bits is divided between the network and external devices, based on administrative agreement. At the very least, the IP addresses of such hosts will have to change to reflect the changed position of the LH field. However, the preferred way to demultiplex a single host port is via the mechanism of logical names. The only change this involves is to get the port expander implementation to look at the entire IP address, rather than just the LH field.
相互運用性のもう一つの側面はIP LH分野と関係があって、どれが現在一握りのArpanetによって使用されるかが単一のホストポートを「反-マルチプレックス」に接待します。 5、-気にかけてください、物理的なIPのビットが(ビット17- 21)と6を扱う、-気にかけてください、このためにIPの論理的な名(ビット18-23)のビットを使用できます--特に、これらのビットの使用はネットワークと外部のデバイスの間で分割されます、管理協定に基づいて。 少なくとも、そのようなホストのIPアドレスは、LH分野の変えられた位置を反映するために変化しなければならないでしょう。 しかしながら、都合のよい方法で、「反-マルチプレックス」には、単一のホストポートが論理的な名前のメカニズムであります。 これがかかわる唯一の変化で、ポートエキスパンダ実装はまさしくLH分野よりむしろ全体のIPアドレスを見ることになっています。
Khanna & Malis [Page 12] RFC 1005 May 1987
Khanna&Malis[12ページ]RFC1005 1987年5月
3 LOGICAL ADDRESSING
3 論理的なアドレシング
The modifications to AHIP allow a host to use logical addressing to communicate with other hosts on the network. Basically, logical addressing allows hosts to refer to each other using a logical name (see section 3.1) which is independent of a host's physical location in the network. IEN 183 (also published as BBN Report 4473) [2] gives the use of logical addressing considerable justification. Among the advantages it cites are:
AHIPへの変更で、ホストは、ネットワークで他のホストとコミュニケートするのに論理的なアドレシングを使用できます。 基本的に、論理的なアドレシングで、ネットワークにホストの物理的な位置から独立している論理的な名前(セクション3.1を見る)を使用することでホストは互いについて言及できます。 IEN183(また、BBN Report4473として、発行されます)[2]は論理的なアドレシングの使用にかなりの正当化を与えます。 それが引用する有利な立場の中に、以下があります。
o The ability to refer to each host on the network by a name independent of its location in the network (especially important if the host has to move to another physical port).
o ネットワークにおける位置の如何にかかわらず名前のネットワークの各ホストについて言及する能力、(特に重要である、ホストが別の物理的なポートに移行しなければならない、)
o Allowing different hosts to share the same host port on a time-division basis.
o 異なったホストが時間分割ベースで同じホストポートを共有するのを許容します。
o Allowing a host to use multi-homing (where a single host uses more than one port to communicate with the network).
o ホストがマルチホーミング(独身のホストがネットワークとコミュニケートするのに1つ以上のポートを使用するところ)を使用するのを許容します。
o Allowing several hosts that provide the same service to share the same name.
o 同じサービスを提供する数人のホストが同じ名前を共有するのを許容します。
o Allowing a host to provide services that have their own unique names.
o ホストがそれら自身のをユニークにするサービスに名前を提供するのを許容します。
3.1 Addresses and Names
3.1 アドレスと名前
The AHIP-E protocol allows two forms of host specification. The first is a slightly modified version of the form used by the current AHIP protocol, the physical address. The second form is the logical name (the terms "name", "logical name" and "logical address" are used interchangeably in this document).
AHIP-Eプロトコルは2つのフォームのホスト仕様を許容します。 1番目は現在のAHIPプロトコル、物理アドレスによって使用されるフォームのわずかに変更されたバージョンです。 2番目のフォームは論理的な名前(「名前」という用語、「論理的な名前」、および「論理アドレス」は互換性を持って本書では使用される)です。
Current AHIP addresses are the 24-bit host addresses found in AHIP leaders. They have the following format:
現在のAHIPアドレスはAHIPリーダーで見つけられた24ビットのホスト・アドレスです。 彼らには、以下の形式があります:
8 8 8
+-------------+--------+------------+
| host-number |00000000| PSN-number |
+-------------+--------+------------+
41 48 49 56 57 64
(bit positions in the AHIP leader)
8 8 8 +-------------+--------+------------+ | ホスト番号|00000000| PSN-数| +-------------+--------+------------+ 41 48 49 56 57 64 (AHIPリーダーのビット位置)
Current AHIP Address Format
Figure 3.1
現在のAHIPアドレス形式数値3.1
Khanna & Malis [Page 13] RFC 1005 May 1987
Khanna&Malis[13ページ]RFC1005 1987年5月
AHIP-E addresses have the following format:
AHIP-Eアドレスには、以下の形式があります:
8 1 5 10
+--------+-+-----+----------+
| HOST |0|XXXXX| PSN | Physical Address
+--------+-+-----+----------+
41 48 55 64
(bit positions in the AHIP leader)
(X = don't care)
8 1 5 10 +--------+-+-----+----------+ | ホスト|0|XXXXX| PSN| 物理アドレス+--------+-+-----+----------+ 41 48 55 64(AHIPリーダーのビット位置)(X=は気にかけられません)
AHIP-E Address Format
Figure 3.2
AHIP-Eアドレス形式図3.2
Logical names are 16-bit unsigned numbers that serve as a logical identifier for one or more hosts. A logical name is the concatenation of two separate octets in the AHIP leader, bits 41-48 (Upper 8) and 57- 64 (Lower 8) in particular.
論理的な名前は1人以上のホストへの論理的な識別子として機能する16ビットの符号のない数です。 論理的な名前はAHIPリーダー(特にビット41-48(上側の8)と57- 64(下側の8))での2つの別々の八重奏の連結です。
8 2 6 8
+--------+--+------+--------+
| UPPER |11|XXXXXX| LOWER |
+--------+--+------+--------+
41 48 57 64
(bit positions in the AHIP leader)
(X = don't care)
8 2 6 8 +--------+--+------+--------+ | 上側|11|XXXXXX| 下ろしてください。| +--------+--+------+--------+ 41 48 57 64(AHIPリーダーのビット位置)(X=は気にかけられません)
Logical Name Format
Figure 3.3
論理的な名前形式図3.3
3.2 Name Translations
3.2 名前翻訳
There are a number of factors that determine how a logical name is translated by the PSN into a physical address on the network. These factors include which translations are legal; in what order different translations for the same name should be attempted; and which legal translations should not be attempted because a particular host port is down. These issues are discussed in the following sections.
論理的な名前がネットワークでPSNによってどのように物理アドレスに翻訳されるかを決定する多くの要因があります。 これらの要素は、どの翻訳が法的であるかを含んでいます。 同じくらいのための異なった翻訳が命名するすべてのオーダーが試みられるべきであるかで。 そして、特定のホストポートが下がっているので、どの法的な翻訳を試みないべきですか? 以下のセクションでこれらの問題について議論します。
Khanna & Malis [Page 14] RFC 1005 May 1987
Khanna&Malis[14ページ]RFC1005 1987年5月
3.2.1 Authorization and Effectiveness
3.2.1 承認と有効性
Every host on a PSN, regardless of whether it is using the AHIP or AHIP-E protocol to access the network, can have one or more logical names. Hosts using AHIP-E can then use these names to address the hosts in the network independent of their physical locations.
ネットワークにアクセスするのにAHIPかAHIP-Eプロトコルを使用しているかどうかにかかわらず、PSNの上のすべてのホストが1つ以上の論理的な名前を持つことができます。 そして、AHIP-Eを使用しているホストは、彼らの物理的な位置の如何にかかわらずネットワークでホストに演説するのにこれらの名前を使用できます。
At this point, several questions arise: How are these names assigned, how do they become known to the PSNs (so that translations to physical addresses can be made), and how do the PSNs know which host is currently using a shared port? To answer each question in order:
ここに、いくつかの質問が起こります: これらの名前はどのように割り当てられるか、そして、どのようにPSNsにおいて知られるようになるか、そして、(物理アドレスへの翻訳をすることができるように)PSNsはどのホストが現在共有されたポートを使用しているかをどのように知っていますか? それぞれに答えるには、整然とした状態で、質問してください:
Names are assigned by a central network administrator. When each name is created, it is assigned to a host (or a group of hosts) at one or more specific host ports. The host(s) are allowed to reside at those specific host ports, and nowhere else. If a host moves, it will keep the same name, but the administrator has to update the central database to reflect the new host port. Changes to this database are distributed to the PSNs by the Monitoring Center (MC). For a while, the host may be allowed to reside at either of (or both) the new and old ports. Once the correspondence between a name and one or more hosts ports where it may be used has been made official by the administrator, that name is said to be authorized. Physical addresses, which actually refer to physical host ports, are always authorized in this sense.
名前は主要なネットワーク管理者によって割り当てられます。 各名前が作成されるとき、それは1つ以上の特定のホストポートのホスト(または、ホストのグループ)に割り当てられます。 ホストはほかにそれらの特定のホストポートにおいてどこにも住むことができません。 ホストが移行すると、同じ名前を保つでしょうが、管理者は、新しいホストポートを反映するために主要なデータベースをアップデートしなければなりません。 このデータベースへの変化はMonitoringセンター(M.C.)によってPSNsに分配されます。 しばらく、ホストは(ともに)新しくて古いポートのどちらかに住むことができるかもしれません。 それが使用されるかもしれない名前と1人以上のホストポートの間の通信が管理者によっていったん公式にされると、その名前は認可されると言われます。 この意味で、物理アドレス(実際に物理ホストポートについて言及する)はいつも認可されます。
When the PSN detects that a host has come up on one of its ports, it makes effective the default name(s), if any, for that host. This default action is specified in the configuration table for that host, and can be one of the following: Enable All Names, Enable No Names, Enable One Particular Name. In the case of an AHIP-E host, the default name might not be the one that the host desires to be known as (recall that several hosts may share the same port, or one host may prefer to be known by different names at different times). This requires that an AHIP-E host be able to declare its name to the PSN. This function is performed by a new host-to-PSN message, the Name Declaration Message (NDM), which lists the names that the host would like to be known by. The PSN checks its tables to see if each of the names is authorized, and sends an NDM Reply to the host saying which names were actually authorized and can now be used for sending and receiving messages (i.e., which names are effective). A host can also use an NDM message to change its list of effective names (it can add to and delete from the list) at any time. The only constraint on the host is that any names it wishes to use can become effective only if they are authorized.
PSNがそれを検出するとき、ホストはポートの1つに近づいて、デフォルト名(s)を有効にします、もしあれば、そのホストのために。 このデフォルト動作は、構成テーブルでそのホストに指定されて、以下の1つであるかもしれません: すべての名前を可能にしてください、そして、名前を全く可能にしないでください、そして、1つの特定の名を可能にしてください。 AHIP-Eホストの場合では、デフォルト名はホストが知られていることを望んでいるものでないかもしれません(数人のホストが同じポートを共有するかもしれないと思い出してください。さもないと、1人のホストが、いろいろな時間に異なった名前によって知られているのを好むかもしれません)。 これは、AHIP-Eホストが名前をPSNに宣言できるのを必要とします。 この機能はホストからPSNへの新しいメッセージ、ホストを知られたがっている名前を記載するName Declaration Message(NDM)によって実行されます。 PSNはそれぞれの名前が認可されているかどうか確認するためにテーブルをチェックして、どの名前を実際に認可して、現在メッセージの送受信に使用できるか(すなわち、どの名前が有効ですか)を言うホストにNDM Replyを送ります。 また、ホストが有効な名前のリストを変えるNDMメッセージを使用できる、(それが加えて、リストから削除できる、)、いつでも。 ホストにおける唯一の規制はそれらが認可されている場合にだけそれが使用したがっているどんな名前も有効になることができるということです。
If a host is using the current AHIP protocol, it can still receive messages from hosts via its logical name. Of course, it can also receive messages from a current AHIP host via its physical address as well. (Remember, the distinction between logical names and physical
ホストが現在のAHIPプロトコルを使用しているなら、それはホストから論理的な名前でメッセージをまだ受け取ることができます。 もちろん、また、それはまた、物理アドレスを通して現在のAHIPホストからメッセージを受け取ることができます。 (覚えている、論理的な名前で物理的の区別
Khanna & Malis [Page 15] RFC 1005 May 1987
Khanna&Malis[15ページ]RFC1005 1987年5月
addresses is that the addresses correspond to physical locations on the network, while the names are strictly logical identifiers).
アドレスがアドレスがネットワークの物理的な位置に一致しているということですが、名前が厳密に論理的な識別子である、)
The third question above has by now already been answered. An AHIP-E host can use the NDM message to tell the PSN which host it is (which names it is known by). Thus, even if this is a shared port, the PSN knows which host is currently connected.
上の3番目の質問は今ごろ、既に答えられました。 AHIP-EホストはそれがどのホストであるかをPSNに言うNDMメッセージ(それが知られているどの名前)を使用できるか。 したがって、これが共有されたポートであっても、PSNは、どのホストが現在接されるかを知っています。
WHENEVER A HOST GOES DOWN, ITS NAMES AUTOMATICALLY BECOME NON- EFFECTIVE. When it comes back up, the default action (from the host's configuration) is taken. If the host wishes to be known by a name other than the default, it will have to issue a NDM. It will also have to do this upon receipt of reset NOPS from the PSN.
ホストが落ちるときはいつも、名前は自動的に非有効になります。 来て戻るとき、デフォルト行動(ホストの構成からの)を取ります。 ホストが、デフォルト以外の名前に知られていて欲しいなら、それはNDMを発行しなければならないでしょう。 また、それはPSNからのリセットNOPSを受け取り次第これをしなければならないでしょう。
3.2.2 Translation Policies
3.2.2 翻訳方針
Several hosts can share the same logical name. If more than one of these hosts is up at the same time, any messages sent to that logical name will be delivered to just one of the hosts sharing that name, and a RFNM will be returned as usual. However, the sending host will not receive any indication of which host received the message, and subsequent messages to that name are not guaranteed to be sent to the same host. Typically, hosts providing exactly the same service could share the same logical name in this manner.
数人のホストが同じ論理的な名前を共有できます。 これらのホストのより多くのひとりが同時に上がると、その論理的な名前に送られたどんなメッセージもちょうどその名前を共有しているホストのひとりに提供するでしょう、そして、いつものようにRFNMを返すでしょう。 しかしながら、送付ホストはどのホストがメッセージを受け取ったかどんなしるしも受けないでしょう、そして、その名前へのその後のメッセージは、同じホストに送るために保証されません。 通常、まさに同じサービスを提供するホストはこの様に同じ論理的な名前を共有できました。
Similarly, when a host is multi-homed, the same logical name may refer to more than one host port (all connected to the same host). If the host is up on only one of those ports, that port will be used for all messages addressed to the host. However, if the host were up on more than one port, the message would be delivered over just one of those ports, and the subnet would choose which port to use. This port selection could change from message to message. If a host wanted to insure that certain messages were delivered to it on specific ports, these messages could use either the port's physical address or a specific logical name that referred to that port alone.
aであるときに、同様に、ホストがそうである、マルチ、家へ帰り、同じ論理的な名前は1つ以上のホストポートについて言及するかもしれません(すべてが同じホストに接しました)。 ホストが1だけでそれらのポートで起きていると、そのポートはホストに扱われたすべてのメッセージに使用されるでしょう。 しかしながら、ホストが1つ以上のポートで起きているなら、ちょうどそれらのポートの1つ以上はメッセージに提供されるでしょうに、そして、サブネットはどのポートを使用したらよいかを選ぶでしょう。 メッセージによってこのポート選択は変化できました。 ホストが、あるメッセージが特定のポートの上でそれに提供されたのを保障したいなら、これらのメッセージは単独でそのポートについて言及したポートの物理アドレスか特定の論理的な名前のどちらかを使用するかもしれないでしょうに。
Three different address selection policies are available for the name mapping process. When translated, each name uses one of the three policies (the policy is administratively pre-determined on a per-name basis). The three policies are:
3つの異なったアドレス選択方針がマッピング処理という名前に利用可能です。 翻訳されると、各名前は3つの方針の1つを使用します(方針は1名前あたり1個のベースで行政上予定されます)。 3つの方針は以下の通りです。
o Attempt each translation in the order in which the physical addresses are listed in the PSN's translation tables, to find the first reachable physical host address. This list is always searched from the top whenever a new virtual circuit connection has to be created. This is the most commonly used policy.
o 物理アドレスが最初の届いている物理ホストアドレスを見つけるためにPSNの変換テーブルに記載されているオーダーにおける各翻訳を試みてください。 新しい仮想の回路接続が創造されなければならないときはいつも、このリストは先端からいつも捜されます。 これは最も一般的に使用された方針です。
Khanna & Malis [Page 16] RFC 1005 May 1987
Khanna&Malis[16ページ]RFC1005 1987年5月
o Selection of the closest physical address, which uses the PSN's internal routing tables to find the translation to the destination PSN with the least cost path for the particular type-of-service whenever a new virtual circuit connection has to be created.
o 最も近い物理アドレスの選択。(それは、新しい仮想の回路接続が創造されなければならないときはいつも、特定のサービスのタイプに関して最小費用経路がある目的地PSNにおいて翻訳を見つけるのにPSNの内部の経路指定テーブルを使用します)。
o Use load leveling. This is similar to the first policy, but differs in that searching the address list for a valid translation starts at the address following where the previous translation search ended whenever a new virtual circuit connection has to be created. This attempts to spread out the load from any one PSN's hosts to the various host ports associated with a particular name. Note that this is NOT network-wide load leveling, which would require knowledge about flows throughout the network.
o 負荷の平らにすることを使用してください。 これは、最初の方針と同様ですが、有効な翻訳のための住所録を捜すのが新しい仮想の回路接続が創造されなければならないときはいつも、前の翻訳検索が終わったところに従うアドレスで始まるという点において異なります。 これは、どんなPSNのホストから様々な特定の名前に関連しているホストポートまでも負荷を広げるのを試みます。 これが負荷の平らにすることでないことにネットワーク全体の注意してください。(それは、ネットワーク中で流れに関する知識を必要とするでしょう)。
3.2.3 Reporting Destination Host Downs
3.2.3 あて先ホストのダウンズを報告すること。
As is explained in Report 1822, whenever regular messages are sent by a host, the PSN opens a virtual circuit connection to each destination host from the source host. A new connection is opened for each new source-address/destination-name (or address, as the case might be)/handling-type/type-of-service combination. A connection will stay open at least as long as there are any outstanding (un-RFNMed) messages using it and both the source and destination hosts stay up. Connections are also closed after a period of inactivity.
そのままで、Report1822で説明されていて、通常のメッセージがホストによって送られるときはいつも、PSNは仮想の回路接続を送信元ホストから各あて先ホストに公開しています。 新しい接続はそれぞれのサービスの取り扱い目的地新しいソースアドレス/名(ケースとしてのアドレスはそうである)/タイプ/タイプ組み合わせのために開かれます。 どんな傑出している(不-RFNMed)メッセージもある限り、接続はそれを使用することで少なくとも開いた状態で滞在するでしょう、そして、ソースとあて先ホストの両方が引きとめられます。 また、コネクションズは不活発の期間の後に閉じられます。
However, the destination host may go down for some reason during the lifetime of a connection. If the host goes down while there are no outstanding messages to it in the network, then the connection is closed and no other action is taken until the source host submits the next message for that destination. At that time, ONE of the following events will occur:
しかしながら、あて先ホストはある理由で接続の生涯落ちるかもしれません。 ネットワークにはそれへのどんな傑出しているメッセージもありませんが、ホストが落ちるなら、接続は終えます、そして、送信元ホストがその目的地への次のメッセージを提出するまで、他の行動を全く取りません。 その時、以下のイベントのONEは起こるでしょう:
A1. If a physical address is being used to specify the
destination host, then the source host will receive a type
7, subtype 0 (Destination Host Dead) message from the PSN.
A1。 物理アドレスがあて先ホストを指定するのに使用されていると、送信元ホストはタイプ7を受けるでしょう、PSNからの「副-タイプ」0(目的地Host Dead)メッセージ。
A2. If a logical name is being used to specify the
destination host, and the name maps to only one authorized
host port,then a type 7, subtype 0 message will be sent to
the source host.
A2。 論理的な名前があて先ホストを指定するのに使用されていて、1つだけへの名前地図がホストポートを認可したなら、次に、タイプ7であり、「副-タイプ」0メッセージを送信元ホストに送るでしょう。
A3. If a logical name is being used to specify the destination
host, and the name maps to more than one authorized host
port, then the PSN attempts to open a connection to another
authorized and effective host port for that name. If no
such connection can be made, the host will receive a type
A3。 論理的な名前があて先ホストを指定するのに使用されていて、1つ以上への名前地図がホストポートを認可したなら、PSNは、その名前のために別の認可されて有効なホストポートに接続を開くのを試みます。 どんなそのような接続も作ることができないと、ホストはタイプを受けるでしょう。
Khanna & Malis [Page 17] RFC 1005 May 1987
Khanna&Malis[17ページ]RFC1005 1987年5月
15 (AHIP Name or Address Error), subtype 5 (no effective
translations) message (see section 5.2). Note that a type
7 message cannot be returned to the source host, since type
7 messages refer to a particular destination host port, and
the name maps to more than one destination port. However,
in the case of a version 0 or 1 host, a type 7, subtype 0
message will be returned for each outstanding message. See
chapter 6 for further details on version numbers.
15(AHIP NameかAddress Error)、「副-タイプ」5(有効な翻訳がない)メッセージ(セクション5.2を見ます)。 タイプ7メッセージを送信元ホストに返すことができないことに注意してください、タイプ7メッセージが特定のあて先ホストポート、および名前地図を1つ以上の仕向港と呼ぶので。 しかしながら、バージョン0か1ホスト、タイプ7の場合では、それぞれの傑出しているメッセージのために「副-タイプ」0メッセージを返すでしょう。 さらに詳しい明細についてはバージョン番号で第6章を見てください。
Things get a bit more complicated if there are any outstanding messages on the connection when the destination host goes down. The connection will be closed, and one of the following will occur:
あて先ホストが落ちるとき、何か接続に関する傑出しているメッセージがあれば、いろいろなことはもう少し複雑になります。 接続は閉店するでしょう、そして、以下の1つは起こるでしょう:
B1. If a physical address is being used to specify the
destination host, then the source host will receive a type
7 message for each outstanding message.
B1。 物理アドレスがあて先ホストを指定するのに使用されていると、送信元ホストはそれぞれの傑出しているメッセージへのタイプ7メッセージを受け取るでしょう。
B2. If a logical name is being used to specify the
destination host, then the source host will receive a type
9 (Incomplete Transmission), subtype 6 (message lost due to
logically addressed host going down) message for each
outstanding message. The next time the source host
submits another message for that same destination name,
the previous algorithm will be used (either step A2 or
step A3). However,in the case of a version 0 or 1 host, a
type 7,subtype 0 message will be returned for each
outstanding message. See chapter 6 for further details
on version numbers.
B2。 論理的な名前があて先ホストを指定するのに使用されていると、送信元ホストはタイプ9(不完全なTransmission)を受けるでしょう、それぞれの傑出しているメッセージへの「副-タイプ」6(下にメッセージが論理的に扱われたホストの行くため失われていた状態で)メッセージ。 送信元ホストがその同じ目的地名への別のメッセージを提出する次の時、前のアルゴリズムは使用されるでしょう(ステップA2かステップA3のどちらか)。 しかしながら、バージョン0か1ホスト、タイプ7の場合では、それぞれの傑出しているメッセージのために「副-タイプ」0メッセージを返すでしょう。 さらに詳しい明細についてはバージョン番号で第6章を見てください。
3.3 Establishing Host-PSN Communications
3.3 ホスト-PSNコミュニケーションを確立すること。
When a host comes up on a PSN, or after there has been a break in the communications between the host and its PSN (see 1822 (3.2)),the orderly flow of messages between the host and the PSN needs to be properly (re- )established. This allows the PSN and host to recover from almost any failure in the other or in their communications path, including a break in mid-message.
ホストがPSNに近づくときに時かそこの後に、ホストとそのPSNとのコミュニケーションにおける中断があった、(1822(3.2))、ホストとPSNの間のメッセージの流れが必要がある看護兵であると適切に考えてください、(再、)、確立しています。 これで、PSNとホストはもう片方かそれらのコミュニケーション経路でのほとんどどんな失敗からも回復できます、中間のメッセージに中断を含んでいて。
The first messages that a host should send to its PSN are three NOPs. Three messages are required to ensure that at least one message will be properly read by the PSN (the first NOP could be concatenated to a previous message if communications had been broken in mid-stream, and the third provides redundancy for the second). These NOPs serve to synchronize the PSN with the host, to inform the PSN about how much padding the host requires between the message leader and its body and to specify the host's AHIP-E version number to the PSN (see chapter 6).
ホストがPSNに発信するべきであるという最初のメッセージは3NOPsです。 3つのメッセージが、少なくとも1つのメッセージがPSNによって適切に読まれるのを保証するのに必要です(コミュニケーションが中流の中で壊れていたなら、最初のNOPは前のメッセージに連結されるかもしれません、そして、3番目は2番目のための冗長を提供します)。 これらのNOPsはホストにPSNを連動させて、ホストを水増しするのがメッセージリーダーとそのボディーの間で周囲でどのくらい必要とするかをPSNに知らせて、ホストのAHIP-Eバージョン番号をPSNに指定するのに役立ちます(第6章を見てください)。
Similarly, the PSN will send three NOPs to the host when it detects that
それがそれを検出するとき、同様に、PSNは3NOPsをホストに送るでしょう。
Khanna & Malis [Page 18] RFC 1005 May 1987
Khanna&Malis[18ページ]RFC1005 1987年5月
the host has come up. The NOPs will be followed by an Interface Reset message. These NOPs will contain the physical address of the host interface.
ホストは来ました。 Interface ResetメッセージはNOPsのあとに続くでしょう。 これらのNOPsはホスト・インターフェースの物理アドレスを含むでしょう。
Once the PSN and the host have sent each other the above messages, regular communications can commence. See 1822(3.2) for further details concerning the ready line, host tardiness, and other issues.
PSNとホストがいったん上記のメッセージを互いに送ると、通常のコミュニケーションは始まることができます。 さらに詳しい明細については持ち合わせの系列、ホスト緩慢、および他の問題に関して1822(3.2)を見てください。
3.4 Name Server
3.4 ネームサーバ
There may be times when a host wants to perform its own translations, or might need the full list of physical addresses to which a particular name maps. For example, a connection- based host-to-host protocol may require that the same physical host port on a multi-homed host be used for all messages using that host-to-host connection, and the host does not wish to trust the PSN to always deliver messages using a destination name to the same host port.
回がホストはそれ自身の翻訳を実行したいか、または特定の名前が写像するものに物理アドレスに関する完全リストが必要があるかもしれないあるかもしれません。 例えば、a接続ベースのホスト間プロトコルが、同じ身体検査がaのポートを接待するのを必要とするかもしれない、マルチ、家へ帰り、ホスト、ホストからホストとのその接続を使用するのにおいてすべてのメッセージにおいて使用されてください。そうすれば、ホストは、PSNがいつもメッセージを提供すると同じホストポートに目的地名を使用することで信じたがっていません。
In these cases, the host can submit a type 11 (Name Server Request) message to the PSN, which requests the PSN to translate the destination name and return a list of the addresses to which it maps. The PSN will respond with a type 11 (Name Server Reply) message, which contains the selection policy in use for that name, the number of addresses to which the name maps, the addresses themselves, and for each address, whether it is effective and its routing distance (for the particular type-of- service specified in the Name Server Request message) from the PSN. See section 5.2 for a complete description of these messages' contents.
これらの場合では、ホストはタイプ11(名前Server Request)メッセージをPSNに提出できます。(PSNはそれが写像するものに目的地名を翻訳して、アドレスのリストを返すようPSNに要求します)。 -サービスは中で指定しました。PSNがタイプで11(名義のServer Reply)メッセージ、それが有効であるか否かに関係なく、どれがその名前、名前が写像するもの、アドレス自体へのアドレスの数と各アドレスに、使用中の選択方針を含んでいるか、そして、およびそのルーティング距離を反応させる、(特定のタイプ、-、Name Server Requestメッセージ) PSNから。 これらのメッセージのコンテンツの完全な記述に関してセクション5.2を見てください。
Using this information, the source host could make an informed decision on which of the physical host ports corresponding to a logical name to use and then send the messages to that port, rather than to the name.
この情報を使用して、名前にというよりむしろそれへのメッセージが使用して、次に送る論理的な名前に対応する物理ホストポートのどれを移植するかに関して送信元ホストは十分な情報に基づいた判断を下すことができました。
The PSN also supports a different type of name service. A host needs to issue a Name Declaration Message to the PSN in order to change its effective names, but it may not wish to keep its names in some table or file in the host. In this case, it can ask the PSN to tell it which names it is authorized to use.
また、PSNは異なった名前サービスのタイプをサポートします。 ホストは、有効な名前を変えるのにPSNにName Declaration Messageを発行する必要がありますが、それはホストの何らかのテーブルかファイルの名前を保ちたがっていないかもしれません。 この場合、それは、どの名前を使用するのが認可されるかそれに言うようにPSNに頼むことができます。
In this case, the host submits a type 12 (Port List Request) message to the PSN, and the PSN replies with a type 12 (Port List Reply) message. It contains, for the host port over which the PSN received the request and sent the reply, the number of names that map to the port, the list of names, and whether or not each name is effective. The host can then use this information in order to issue the Name Declaration Message. Section 5.2 contains a complete description of the reply's contents.
この場合、ホストはタイプ12(ポートList Reply)メッセージでタイプ12(ポートList Request)メッセージをPSN、およびPSN回答に提出します。 それはPSNが要求を受け取って、ポートへのその地図を回答、名前の数に送ったホストポートに名前であってそれぞれの名前が有効であるかどうかに関するリストを含んでいます。 そして、ホストは、Name Declaration Messageを発行するのにこの情報を使用できます。 セクション5.2は回答のコンテンツの完全な記述を含みます。
Khanna & Malis [Page 19] RFC 1005 May 1987
Khanna&Malis[19ページ]RFC1005 1987年5月
4 OTHER CHANGES
4 他の変化
This section describes the enhancements to the AHIP protocol involving type-of-service specification, subnet congestion feedback and network precedence level feedback. Note that only version 2 hosts will receive the congestion and precedence messages described in this section.
このセクションはサービスのタイプ仕様、サブネット混雑フィードバック、およびネットワーク先行レベルフィードバックにかかわるAHIPプロトコルに増進について説明します。 バージョン2ホストだけがメッセージがこのセクションで説明した混雑と先行を受けることに注意してください。
4.1 Type-of-Service Specification
4.1 サービスのタイプ仕様
Bits 9 and 10 of the AHIP leader, currently unused, will be used by the host to specify desired delay and throughput characteristics to the PSN. Bit 11, also currently unused, will be used to specify reliability. The bits have the following meaning:
AHIPリーダーの現在未使用であることのビット9と10は、必要な遅れとスループットの特性をPSNに指定するのにホストによって使用されるでしょう。 また、現在未使用であることのビット11は、信頼性を指定するのに使用されるでしょう。 ビットには、以下の意味があります:
Bit 9: delay bit
ビット9: 遅れビット
0 -- normal delay
1 -- low delay
0--正常な遅れ1--低い遅れ
Bit 10: throughput bit
ビット10: スループットビット
0 -- normal throughput
1 -- high throughput
0--標準のスループット1--高生産性
Bit 11: reliability bit
ビット11: 信頼性のビット
0 -- normal reliability
1 -- high reliability
0--正常な信頼性1--高信頼性
The values of these bits are consistent with those of IP, and bits 11, 12 and 13 of the IP header can be copied directly into bits 9, 10 and 11 of the AHIP leader.
これらのビットの値はIPのものと一致しています、そして、直接AHIPリーダーのビット9、10、および11にIPヘッダーのビット11、12、および13はコピーできます。
The type-of-service bits should be considered as extensions of the "Handling Type" field (bits 33-40 of the AHIP leader -- see 1822 (3.3)). Messages from host A to host B using the same destination name and of the same handling type and type-of- service will use the same connection, while those that differ in either type-of-service, destination name or handling type will use separate connections. In other words, for a given source host and destination name pair, a new connection will be established whenever a message with a new handling- type/type-of- service combination is received.
サービス・ビットのタイプが「取り扱いタイプ」分野の拡大であるとみなされるべきである、(AHIPリーダーのビット33-40--1822(3.3))を見てください。 -サービスでは、同じ接続を使用するために望んでください、とサービスのタイプにおいて異なるものがゆったり過ごして、目的地名か取り扱いタイプが別々の接続を使用するというホストAから同じ目的地名と同じ取り扱いタイプとタイプのホストB使用までのメッセージ。 言い換えれば、新しい接続は与えられた送信元ホストと目的地名前組における、ことになるでしょう-新しい取り扱いがあるメッセージがタイプするか、またはタイプするときはいつも、設立されて、サービスでは、組み合わせが受け取られているという。
Khanna & Malis [Page 20] RFC 1005 May 1987
Khanna&Malis[20ページ]RFC1005 1987年5月
4.2 Subnet Congestion Feedback
4.2 サブネット混雑フィードバック
This section describes the new messages that are part of the mechanism used by the PSN to communicate subnetwork congestion information to the host. Note that a host will be blocked by the PSN when its share of buffers in the PSN is used up. Thus, this information, which is communicated on a connection basis, will give the host an opportunity to selectively reduce its congesting flows, thus preventing all of its flows from getting blocked. Currently, a host has no way of knowing which of its flows is experiencing congestion; consequently, it is possible that one congesting flow can result in the blocking of all the host's flows.
このセクションはサブネットワーク混雑情報をホストに伝えるのにPSNによって使用されたメカニズムの一部である新しいメッセージについて説明します。 PSNのバッファの株が使いきられるとき、ホストがPSNによって妨げられることに注意してください。 したがって、この情報(接続ベースで伝えられる)は流れを充血させるのを選択的に減少させる機会をホストに与えるでしょう、その結果、流れのすべてが妨げられるのを防ぎます。 現在、ホストには、流れについて混雑を経験することである知る方法が全くありません。 その結果、流れを充血させるそれがすべてのホストの流れのブロッキングをもたらすことができるのは、可能です。
Three new PSN-to-host messages have been created. These messages are:
3つのPSNからホストへの新しいメッセージを作成してあります。 これらのメッセージは以下の通りです。
1. STOP: Blocking Imminent -- Stop Sending on this
Connection (Message type 13)
1. 以下を止めてください。 Imminentを妨げます--このConnectionの上のSendingを止めてください。(メッセージタイプ13)
2. SLOW: Subnet Congestion -- Send at Slow Rate on this
Connection (Message type 14) -- Maintain Window Size of
1, i.e., do not send a new message to this destination
host with this type-of-service and handling type until
all previous messages have been acknowledged by RFNMs.
2. 遅くなります: サブネットCongestion--このConnection(メッセージタイプ14)の上のSlow Rateで発信してください--1のWindow Sizeを維持してください、そして、すなわち、前のすべてのメッセージがRFNMsによって承認されるまで、このサービスのタイプと取り扱いタイプで新しいメッセージをこのあて先ホストに送らないでください。
3. GO: Congestion Subsided -- Send at Regular Rate on this
Connection (Message type 16) -- Maintain Window Size of
8
3. 行きます: 混雑Subsided--このConnection(メッセージタイプ16)の上のRegular Rateで発信してください--8のWindow Sizeを維持してください。
These messages may be sent in any order and correspond to states, not transitions. A participating host should support three states with effective windows of 8, 1 and 0. The format of these messages can be found in section 5.2.
これらのメッセージは、順不同に送られて、変遷ではなく、州に対応するかもしれません。 参加しているホストは8、1、および0の有効な窓がある3つの州をサポートするべきです。 セクション5.2でこれらのメッセージの形式を見つけることができます。
4.3 Precedence Level Information
4.3 先行レベル情報
Two new messages have been created:
2つの新しいメッセージを作成してあります:
1. Network Not Accepting Messages at this Precedence Level
(Message type 9, subtype 7).
1. このPrecedence Level(メッセージタイプ9、「副-タイプ」7)でNot Accepting Messagesをネットワークでつないでください。
2. Network Precedence Level Cutoff Change (Message type
17).
2. Precedence Level Cutoff Change(メッセージタイプ17)をネットワークでつないでください。
The first message will be generated whenever the host attempts to send a message at a precedence level lower than the cutoff. The cutoff represents a precedence level below which no traffic may be submitted
ホストが、締切りより低先行レベルでメッセージを送るのを試みるときはいつも、最初のメッセージは生成されるでしょう。 締切りはトラフィックが全く提出されないかもしれない先行レベルを表します。
Khanna & Malis [Page 21] RFC 1005 May 1987
Khanna&Malis[21ページ]RFC1005 1987年5月
into the subnetwork; note that a cutoff set to the lowest possible precedence level implies that no precedence restrictions are in effect. If the host has chosen not to receive the new AHIP-E messages, then the PSN will send a type 7, sub-type 3 message (communication with the destination host is administratively prohibited) instead. The second message will be generated whenever the network precedence level cutoff changes. Both messages contain the network precedence cutoff value. The format of these messages can be found in section 5.2.
サブネットワークに。 可能な限り低い先行レベルに設定された締切りが、どんな先行制限も有効でないことを含意することに注意してください。 ホストが、新しいAHIP-Eメッセージを受け取らないのを選んだなら、PSNは代わりに、3メッセージ(あて先ホストとのコミュニケーションは行政上禁止されている)をタイプ7、サブタイプに送るでしょう。 ネットワーク先行レベル締切りが変化するときはいつも、2番目のメッセージは生成されるでしょう。 両方のメッセージはネットワーク先行締切りの価値を含んでいます。 セクション5.2でこれらのメッセージの形式を見つけることができます。
Khanna & Malis [Page 22] RFC 1005 May 1987
Khanna&Malis[22ページ]RFC1005 1987年5月
5 FORMATS FOR NEW AHIP-E MESSAGES
新しいAHIP-Eメッセージのための5つの形式
The following sections describe the formats of the leaders that precede messages between an AHIP-E host and its PSN. The formats are almost identical to those of AHIP (see 1822(3.3) and 1822(3.4)). New message types are marked by margin bars (as shown | here).
以下のセクションはAHIP-EホストとそのPSNの間のメッセージに先行するリーダーの形式について説明します。 形式はAHIPのものとほとんど同じです。(1822(3.3)と1822(3.4))を見てください。 新しいメッセージタイプがマージンバーによってマークされる、(示されるように|ここ)
5.1 Host-to-PSN AHIP-E Leader Format
5.1 ホストからPSN AHIP Eへのリーダー形式
1 4 5 8 13 16 17 20 21 22 24 25 32 +---------+--------+-+-+-+-+------+--------+-+------+----------------+ | | FORMAT |D|T|R|U| | |T|LEADER| | | UNUSED | FLAG |E|H|E|N| VERS | UNUSED |R|FLAGS | MESSAGE TYPE | | | (15) |L|R|L|U| | |C| | | +---------+--------+-+-+-+-+------+--------+-+------+----------------+
1 4 5 8 13 16 17 20 21 22 24 25 32 +---------+--------+-+-+-+-+------+--------+-+------+----------------+ | | 形式|D|T|R|U| | |T|リーダー| | | 未使用| 旗|E|H|E|N| VERS| 未使用|R|旗| メッセージタイプ| | | (15) |L|R|L|U| | |C| | | +---------+--------+-+-+-+-+------+--------+-+------+----------------+
33 40 41 64 +----------------------+----------------------------------------------+ | | | | HANDLING TYPE | DESTINATION HOST | | | | +----------------------+----------------------------------------------+
33 40 41 64 +----------------------+----------------------------------------------+ | | | | 取り扱いタイプ| あて先ホスト| | | | +----------------------+----------------------------------------------+
65 76 77 80 81 96 +-------------------------+--------+----------------------------------+ | | | | | MESSAGE ID |SUB-TYPE| UNUSED | | | | | +-------------------------+--------+----------------------------------+
65 76 77 80 81 96 +-------------------------+--------+----------------------------------+ | | | | | メッセージID|サブタイプ| 未使用| | | | | +-------------------------+--------+----------------------------------+
Host-to-PSN AHIP-E Leader Format
Figure 5.1
ホストからPSN AHIP Eへのリーダー形式数値5.1
Bits 1-4: Unused, must be set to zero.
ビット1-4: 未使用である、ゼロに設定しなければなりません。
Bits 5-8: Format Flag
This field is set to decimal 15 (1111 in binary).
ビット5-8: Flag Thisがさばく形式は10進15(バイナリーの1111)に設定されます。
Bits 9-11: Type-of-Service
ビット9-11テロ: サービスのタイプ
Bit 9: Delay Bit:
0 -- normal delay
1 -- low delay
Bit 10: Throughput Bit:
0 -- normal throughput
1 -- high throughput
Bit 11: Reliability Bit:
ビット9: ビットを遅らせてください: 0--正常な遅れ1--低い遅れBit10: スループットビット: 0 --標準のスループット1--高生産性Bit11: 信頼性のビット:
Khanna & Malis [Page 23] RFC 1005 May 1987
Khanna&Malis[23ページ]RFC1005 1987年5月
0 -- normal reliability
1 -- high reliability
0--正常な信頼性1--高信頼性
Bit 12: Unused, must be set to zero.
ビット12: 未使用である、ゼロに設定しなければなりません。
Bits 13-16: AHIP-E Version number
Ignored by the PSN except in the case of a NOP -- see
chapter 6.
ビット13-16: NOPに関するケース以外のPSNによるAHIP-Eバージョン番号Ignored--第6章を見てください。
Bits 17-20: Unused, must be set to zero.
ビット17-20: 未使用である、ゼロに設定しなければなりません。
Bit 21: Trace Bit:
If equal to one, this message is designated for tracing as
it proceeds through the network. See 1822(5.5).
ビット21: ビットをたどってください: 1つと等しいなら、ネットワークを通して続くとき、このメッセージはたどるために指定されます。 1822(5.5)を見てください。
Bits 22-24: Leader Flags:
ビット22-24: リーダー旗:
Bit 22: A flag available for use by the destination host.
See AHIP(3.3) for a description of its use by the
PSN's TTY Fake Host.
Bits 23-24: Reserved for future use, must be zero.
ビット22: あて先ホストによる使用に利用可能な旗。 PSNのTTY Fake Hostによる使用の記述に関してAHIP(3.3)を見てください。 ビット23-24: 今後の使用がゼロであるに違いないので、予約されます。
Bits 25-32: Message Type:
ビット25-32: メッセージタイプ:
Type 0: Regular Message - All host-to-host communication
occurs via regular messages, which have several sub-
types, found in bits 77-80. These sub-types are:
0: Standard - The PSN uses its full message and error
control facilities, and host blocking may occur.
3: Uncontrolled Packet - The PSN will perform no
message-control functions for this type of
message, and network flow and congestion control
may cause loss of the packet. Also see
1822(3.6). 1-2,4-15: Unassigned.
0はタイプします: 通常のMessage--すべてのホスト間通信が通常のメッセージで現れます。(そこには、ビット77-80で見つけられたいくつかのサブタイプがあります)。 これらのサブタイプは以下の通りです。 0: 規格--PSNはその完全なメッセージと誤り制御施設を使用して、ホストブロッキングは起こるかもしれません。 3: 非制御のPacket--PSNはこのタイプに関するメッセージのためにメッセージ制御機能を全く実行しないで、ネットワーク流動と輻輳制御がパケットの損失をもたらすかもしれません。 また、1822(3.6)を見てください。 1-2,4-15: 割り当てられない。
Type 1: Error Without Message ID - See 1822(3.3).
タイプ1: Message IDのない誤り--1822(3.3)を見てください。
Type 2: Host Going Down - see 1822(3.3).
2はタイプします: ホストGoing Down--1822(3.3)を見てください。
Type 3: Name Declaration Message (NDM) - This message is |
used by the host to declare which of its logical names |
is or is not effective (see section 3.2.1), or to make |
all of its names non-effective. The first 16 bits of |
the data portion of the NDM message, following the |
leader and any leader padding, contains the number of |
logical names contained in the message. This is |
followed by the logical name entries, each 32 bits |
3はタイプします: 名前Declaration Message(NDM)--このメッセージはそうです。| 論理的な名前についてどれを宣言するかにホストによって使用されます。| あるか、有効でない(セクション3.2.1を見ます)、または造に| 名前事故者のすべて。 最初の16ビット| 続くNDMメッセージのデータ部| リーダーとどんなリーダー、もそっと歩いて、数を含んでいます。| メッセージに含まれた論理的な名前。 これはそうです。| 論理的な著者記入、各32ビットは支えています。|
Khanna & Malis [Page 24] RFC 1005 May 1987
Khanna&Malis[24ページ]RFC1005 1987年5月
long, of which the first 16 bits is a logical name and |
the second 16 bits contains either of the integers |
zero or one. Zero indicates that the name should not |
be effective, and one indicates that the name should be |
effective. Note that only the names explicitly in the |
NDM will remain enabled after the NDM is processed |
(assuming that they are authorized). The PSN will |
reply with a NDM Reply message (see section 5.2) |
indicating which of the names are now effective and |
which are not. Pictorially, a NDM message has the |
following format including the leader, which is printed |
in hexadecimal, and without any leader padding): |
そして長さ。(最初の16ビットはそれで論理的な名前です)。| 2番目の16ビットは整数のどちらかを含んでいます。| ゼロか1。 ゼロは、名前がそうするべきでないのを示します。| 有効にしてください、そして、人は、名前がそうであるべきであることを示します。| 有効。 それだけに注意してください、明らかに、中では、命名します。| NDMはNDMが処理された後に可能にされたままで残るでしょう。| (それらが認可されていると仮定します。) PSNはそうするでしょう。| NDM Replyメッセージで、返答してください(セクション5.2を見てください)。| そして名前のどれが現在有効であるかを示す。| そうしません。 絵入りで、NDMメッセージは持っています。| 印刷されるリーダーを含む形式に続きます。| 16進、およびどんなリーダー詰め物、も)、: |
1 16 17 32 33 48
+----------------+----------------+----------------+
| | | |
| 0F00 | 0003 | 0000 |
| | | |
+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+
| | | |
| 0000 | 0000 | 0000 |
| | | |
+----------------+----------------+----------------+
97 112 113 128 129 144
+----------------+----------------+----------------+
| | | |
| # of entries | name #1 | 0 or 1 |
| | | |
+----------------+----------------+----------------+
145 160 161 176
+----------------+----------------+
| | |
| name #2 | 0 or 1 | etc.
| | |
+----------------+----------------+
1 16 17 32 33 48 +----------------+----------------+----------------+ | | | | | 0F00| 0003 | 0000 | | | | | +----------------+----------------+----------------+ 49 64 65 80 81 96 +----------------+----------------+----------------+ | | | | | 0000 | 0000 | 0000 | | | | | +----------------+----------------+----------------+ 97 112 113 128 129 144 +----------------+----------------+----------------+ | | | | | # エントリーについて| 名前#1| 0か1| | | | | +----------------+----------------+----------------+ 145 160 161 176 +----------------+----------------+ | | | | 名前#2| 0か1| など | | | +----------------+----------------+
NDM Message Format
Figure 5.2
NDMメッセージ・フォーマット数値5.2
Khanna & Malis [Page 25] RFC 1005 May 1987
Khanna&Malis[25ページ]RFC1005 1987年5月
An NDM with zero entries will cause all current
effective names for the host to become non-effective.
エントリーがないNDMは事故者になるホストのためにすべての現在の有効な名前を引き起こすでしょう。
Type 4: NOP -- see 1822(3.3). Bits 13-16 of the NOP leader |
are used to determine the host's AHIP-E version -- see |
chapter 6. |
4はタイプします: NOP--1822(3.3)を見てください。 NOPリーダーのビット13-16| ホストのAHIP-Eバージョン--見るように決定するには、使用されます。| 第6章。 |
Type 8: Error with Message ID - see 1822(3.3).
8はタイプします: Message IDとの誤り--1822(3.3)を見てください。
Type 11: Name Server Request - This allows the host to use |
the PSN's logical addressing tables as a name server. |
The destination name in the AHIP-E leader is |
translated, and the PSN replies with a Name Server |
Reply message, which lists the physical host addresses |
to which the destination name maps. The type-of- |
service bits (bits 9-11) should be set correctly by |
the host, as the Name Server Reply message contains |
information about characteristics of the subnetwork |
route(s) to that destination, which will depend on the |
type-of-service. |
11はタイプします: 名前Server Request--これは使用するホストを許容します。| ネームサーバとしてのPSNの論理的なアドレシングテーブル。| AHIP-Eリーダーの目的地名はそうです。| 翻訳、PSNはName Serverと共に返答します。| 応答メッセージ。(その応答メッセージは物理ホストアドレスを記載します)。| 目的地は地図を命名します。 タイプ、-、-| サービス・ビット(ビット9-11テロ)は正しく設定されるべきです。| メッセージが含むName Server Replyとしてのホスト| サブネットワークの特性の情報| その目的地に(s)を発送してください。(意志はそれによります)。| サービスのタイプ。 |
Type 12: Port List Request - This allows the physical host |
to request the list of names that map to the host port |
over which this request was received by the PSN. The |
PSN replies with a Port List Reply message, which |
lists the names that map to the port. |
12はタイプします: List Requestを移植してください--これは物理ホストを許容します。| ポートをホストに写像する名前のリストを要求するために| この要求はPSNによって受け取られました。 The| PSNがPort List Replyメッセージで返答する、どれ| それがポートに写像する名前を記載します。 |
Types 5-7,9-10,13-255: Unassigned.
タイプ5-7、9-10、13-255: 割り当てられない。
Bits 33-40: Handling Type:
The top two bits (33 and 34) specify the precedence of the
connection. There are 4 precedence levels, level 3 being
the highest and level 0 the lowest. Bits 35-40 are used to
specify up to 64 separate connections at a particular
precedence level and type-of-service.
ビット33-40: 取り扱いタイプ: トップ2ビットは接続の先行を指定します(33と34)。 最も低い4つの先行レベル、最も高いレベル3、およびレベル0があります。 ビット35-40は、特定の先行レベルとサービスのタイプで最大64の別々の接続を指定するのに使用されます。
Bits 41-64: Destination Host:
This field contains the name or address of the destination
host, as described in figures 3.3 and 3.2 respectively. If
it contains a name, the name will be checked for
effectiveness, with an error message returned to the source
host if the name is not effective.
ビット41-64: あて先ホスト: この分野は3.3と3.2の数字でそれぞれ説明されるようにあて先ホストの名前かアドレスを含んでいます。 名前を含んでいると、名前は有効性がないかどうかチェックされるでしょう、名前が有効でないなら送信元ホストに返されたエラーメッセージで。
Bits 65-76: Message ID:
This is a host-specified identification used in all type 0
and type 8 messages, and is also used in type 2 messages.
When used in type 0 messages, bits 65-72 are also known as
the Link Field, and should contain values specified in
ビット65-76: メッセージID: これは、タイプ0とタイプすべての8つのメッセージで使用される、ホストによって指定された識別であり、また、タイプ2メッセージで使用されます。 タイプ0メッセージで使用されていて、ビット65-72は、いつまた、Link Fieldとして知られていて、指定された値を含むはずですか。
Khanna & Malis [Page 26] RFC 1005 May 1987
Khanna&Malis[26ページ]RFC1005 1987年5月
Assigned Numbers [3] appropriate for the host-to-host
protocol being used.
使用されるホスト間プロトコルに、適切な民数記[3]を割り当てました。
Bits 77-80: Sub-type:
This field is used as a modifier by message types 0, 2, 4,
and 8.
ビット77-80: サブタイプ: この分野は修飾語としてメッセージタイプ0、2、4、および8によって使用されます。
Bits 81-96: Unused
ビット81-96: 未使用
5.2 PSN-to-Host AHIP-E Leader Format
5.2 PSNからホストへのAHIP-Eリーダー形式
1 4 5 8 12 16 17 20 21 22 24 25 32 +--------+--------+-+-+-+--------+--------+-+------+----------------+ | | FORMAT |D|T|R| | |T|LEADER| | | UNUSED | FLAG |E|H|E| UNUSED | UNUSED |R|FLAGS | MESSAGE TYPE | | | (15) |L|R|L| | |C| | | +--------+--------+-+-+-+--------+--------+-+------+----------------+
1 4 5 8 12 16 17 20 21 22 24 25 32 +--------+--------+-+-+-+--------+--------+-+------+----------------+ | | 形式|D|T|R| | |T|リーダー| | | 未使用| 旗|E|H|E| 未使用| 未使用|R|旗| メッセージタイプ| | | (15) |L|R|L| | |C| | | +--------+--------+-+-+-+--------+--------+-+------+----------------+
33 40 41 64 +----------------------+----------------------------------------------+ | | | | HANDLING TYPE | SOURCE HOST | | | | +----------------------+----------------------------------------------+
33 40 41 64 +----------------------+----------------------------------------------+ | | | | 取り扱いタイプ| 送信元ホスト| | | | +----------------------+----------------------------------------------+
65 76 77 80 81 96 +-------------------------+--------+----------------------------------+ | | | | | MESSAGE ID |SUB-TYPE| MESSAGE LENGTH | | | | | +-------------------------+--------+----------------------------------+
65 76 77 80 81 96 +-------------------------+--------+----------------------------------+ | | | | | メッセージID|サブタイプ| メッセージ長| | | | | +-------------------------+--------+----------------------------------+
PSN-to-Host AHIP-E Leader Format
Figure 5.3
PSNからホストへのAHIP-Eリーダー形式数値5.3
Bits 1-4: Unused and set to zero.
ビット1-4: ゼロに合わせるために未使用であって設定しています。
Bits 5-8: Format Flag
This field is set to decimal 15 (1111 in binary).
ビット5-8: Flag Thisがさばく形式は10進15(バイナリーの1111)に設定されます。
Bits 9-11: Type-of-Service
Specified by the source host (see section 5.1).
ビット9-11テロ: 送信元ホスト(セクション5.1を見る)によるサービスのタイプSpecified。
Bits 12-20: Unused, must be set to zero.
ビット12-20: 未使用である、ゼロに設定しなければなりません。
Bit 21: Trace Bit:
ビット21: ビットをたどってください:
Khanna & Malis [Page 27] RFC 1005 May 1987
Khanna&Malis[27ページ]RFC1005 1987年5月
If equal to one, the source host has designated this
message for tracing as it proceeds through the network.
See 1822(5.5).
1つと等しいなら、ネットワークを通して続くとき、送信元ホストはたどることへのこのメッセージを指定しました。 1822(5.5)を見てください。
Bits 22-24: Leader Flags:
ビット22-24: リーダー旗:
Bit 22: Available as a destination host flag.
Bits 23-24: Reserved for future use, set to zero.
ビット22: あて先ホスト旗として、利用可能です。 ビット23-24: 今後の使用のために予約されて、ゼロにセットしてください。
Bits 25-32: Message Type:
ビット25-32: メッセージタイプ:
Type 0: Regular Message - All host-to-host communication
occurs via regular messages, which have several sub-
types. The sub-type field (bits 77-80) is the same as
that sent in the host-to-PSN leader (see section 5.1).
0はタイプします: 通常のMessage--すべてのホスト間通信が通常のメッセージで現れます。(そこには、いくつかのサブタイプがあります)。 サブタイプ分野(ビット77-80)はホストからPSNへのリーダーで送られたそれと同じです(セクション5.1を見てください)。
Type 1: Error in Leader - See 1822(3.4).
タイプ1: リーダーの誤り--1822(3.4)を見てください。
Type 2: PSN Going Down - See 1822(3.4).
2はタイプします: 落ちるPSN--1822(3.4)を見てください。
Type 3: NDM Reply - This is a reply to the NDM host-to-PSN |
message (see section 5.1). It has the same number of |
entries as the NDM message to which it replies, and |
each listed name is accompanied by a zero or a one |
(see figure 5.2). A zero signifies that the name is |
not effective, and a one means that the name is now |
effective. |
3はタイプします: NDM Reply--これはPSNのNDMホストへの回答です。| メッセージ(セクション5.1を見ます)。 それには、同じ数があります。| そしてそれが返答するNDMメッセージとしてのエントリー。| それぞれの記載された名前はゼロか1つによって伴われます。| (5.2が計算するのがわかります。) ゼロは、名前がそうであることを意味します。| 現在名前がそうである有効、そして、a1つの手段でない| 有効。 |
Type 4: NOP - The host should discard this message. It is
used during initialization of the PSN/host
communication. The Destination Host field will
contain the physical address of the host port over
which the NOP is being sent. All other fields are
unused.
4はタイプします: NOP--ホストはこのメッセージを捨てるべきです。 それはPSN/ホストコミュニケーションの初期化の間、使用されます。 Destination Host分野はNOPが送られるホストポートの物理アドレスを含むでしょう。 他のすべての分野が未使用です。
Type 5: Ready for Next Message (RFNM) - See 1822(3.4).
5はタイプします: 次のメッセージには、(RFNM)を準備してください--1822(3.4)を見てください。
Type 6: Dead Host Status - See 1822(3.4).
6はタイプします: 死んでいるホスト状態--1822(3.4)を見てください。
Type 7: Destination Host or PSN Dead (or unknown) - See
1822(3.4).
7はタイプします: 目的地HostかPSN Dead(または、未知)--1822(3.4)を見てください。
Type 8: Error in Data - See 1822(3.4).
8はタイプします: データにおける誤り--1822(3.4)を見てください。
Type 9: Incomplete Transmission - See 1822(3.4). In
addition to its already defined sub-types, this
message has two new sub-types:
6: Logically Addressed Host Went Down - A logically |
9はタイプします: 不完全なトランスミッション--1822(3.4)を見てください。 既に定義されたサブタイプに加えて、このメッセージには、2つの新しいサブタイプがあります: 6: 論理的である、Addressed Host Went Down--、論理的|
Khanna & Malis [Page 28] RFC 1005 May 1987
Khanna&Malis[28ページ]RFC1005 1987年5月
addressed message was lost in the network because |
the destination host to which it was being |
delivered went down. The message should be |
resubmitted by the source host, since there may |
be another effective host port to which the |
message could be delivered (see section 2.2.3). |
7: Network Not Accepting Messages at this Precedence |
Level - bits 33 and 34 encode the minimum |
precedence level currently being accepted by the |
network. See section 4.3.
扱われたメッセージはネットワークで失われました。| それが存在であったあて先ホスト| 配送、落ちました。 メッセージはそうであるべきです。| ソースによって再提出されて、そこからのホストはそうするかもしれません。| 別の有効なホストポートになってください、どれ| メッセージを提供できました(セクション2.2.3を見てください)。 | 7: このPrecedenceのネットワークNot Accepting Messages| レベル--ビット33と34は最小限をコード化します。| 現在受け入れられる先行レベル| ネットワークでつなぎます。 セクション4.3を見てください。
Type 10: Interface Reset - See 1822(3.4).
10はタイプします: インタフェースリセット--1822(3.4)を見てください。
Type 11: Name Server Reply - This reply to the Name Server |
Request host-to-PSN message contains, following the |
leader and any leader padding, a word with the |
selection policy and the number of physical addresses |
to which the destination name maps, followed by five |
octets per physical address: the first three octets |
contain an AHIP-E address, and the last two contain a |
bit signifying whether or not that particular |
translation is effective and the routing distance |
(expected network transmission delay, in 6.4 ms units) |
to the address's PSN for the type-of-service specified |
in the Name Server Request being replied to. This |
type-of-service will be included in the Name Server |
Reply leader. In figure 5.4, which includes the |
leader without any leader padding and has type-of |
-service set to 000, EFF is 1 for effective and 0 |
for non-effective, the destination name is in the format |
of figure 3.3, and POL is a two-bit number indicating |
the selection policy for the name (see section 3.2.2): |
11はタイプします: 名前Server Reply--Name Serverへのこの回答| 続いて、要求ホストからPSNへのメッセージは含んでいます。| リーダーとどんなリーダー詰め物、単語| 選択方針と物理アドレスの数| 5があとに続いていて、目的地名が写像するものに| 1物理アドレスあたりの八重奏: 最初の3つの八重奏| AHIP-Eアドレスを含んでください。そうすれば、最後の2はaを含んでいます。| そんなに特定であるか否かに関係なく、意味しながら、噛み付きます。| 翻訳は、有効であって、ルーティング距離です。| (6.4msユニットの予想されたネットワーク送信遅れ) | サービスのタイプのためのPSNが指定したアドレスのsに| Name Server Requestでは、答えられます。 これ| サービスのタイプはName Serverに含まれるでしょう。| 回答リーダー。 中では、5.4、どのインクルードが計算されるか。| 少しもリーダー詰め物のないリーダー、有、タイプ、-| -サービスが000にセットして、EFFが1歳である、有効である、0| 事故者にとって、形式には目的地名があります。| 3.3図、POLは安っぽい数の表示です。| 名前(セクション3.2.2を見る)のための選択方針: |
0: First reachable.
1: Closest physical address. |
2: Load leveling. |
3: Unused.
0: 最初に、届きます。 1: 最も近い物理アドレス。 | 2: 平らにすることをロードしてください。 | 3: 未使用。
Khanna & Malis [Page 29] RFC 1005 May 1987
Khanna&Malis[29ページ]RFC1005 1987年5月
1 16 17 32 33 40
+----------------+----------------+--------+
| | | |
| 0F00 | 000B | 00 |
| | | |
+----------------+----------------+--------+
1 16 17 32 33 40 +----------------+----------------+--------+ | | | | | 0F00| 000B| 00 | | | | | +----------------+----------------+--------+
41 64 65 80
+------------------------+-----------------+
| | |
| Destination name | 0000 |
| | |
+------------------------+-----------------+
81 96 97 112
+----------------+-+--------------+
| |P| |
| 0000 |O| # of addrs |
| |L| |
+----------------+-+--------------+
41 64 65 80 +------------------------+-----------------+ | | | | 目的地名| 0000 | | | | +------------------------+-----------------+ 81 96 97 112 +----------------+-+--------------+ | |P| | | 0000 |O| # addrsについて| | |L| | +----------------+-+--------------+
113 136 137 152
+--------------------------+-+-------------+
| |E| |
| AHIP-E addr #1 |F| routing dist|
| |F| |
+--------------------------+-+-------------+
113 136 137 152 +--------------------------+-+-------------+ | |E| | | AHIP-E addr#1|F| ルーティングdist| | |F| | +--------------------------+-+-------------+
153 176 177 192
+--------------------------+-+-------------+
| |E| |
| AHIP-E addr #2 |F| routing dist| etc.
| |F| |
+--------------------------+-+-------------+
153 176 177 192 +--------------------------+-+-------------+ | |E| | | AHIP-E addr#2|F| ルーティングdist| など | |F| | +--------------------------+-+-------------+
Name Server Reply Format
Figure 5.4
ネームサーバ回答形式図5.4
Type 12: Port List Reply - This is the reply to the Port |
List Request host-to-PSN message. It contains the |
number of names that map to this physical host port, |
followed by two words per name: the first word |
contains a logical name that maps to this port, and |
the second contains either a zero or a one, |
signifying whether or not that particular translation |
is effective. The format is identical to the type 3 |
NDM Reply message(see figure 5.2). |
12はタイプします: List Replyを移植してください--これはPortへの回答です。| RequestホストからPSNへのメッセージをリストアップしてください。 それは含んでいます。| この物理ホストにポートを写像する名前の数| 1名前あたり2つの単語があとに続いています: 最初の単語| そしてこれへの地図が移植する論理的な名前を含んでいる。| 2番目はゼロか1つのどちらかを含んでいます。| そんなに特定であるか否かに関係なく、意味する、翻訳| 有効。 タイプ3に、形式は同じです。| NDM Replyメッセージ(5.2が計算するのがわかります)。 |
Type 13: STOP -- Stop Sending on this Connection. See |
13はタイプします: STOP--このConnectionの上のSendingを止めてください。 見てください。|
Khanna & Malis [Page 30] RFC 1005 May 1987
Khanna&Malis[30ページ]RFC1005 1987年5月
section 4.2. |
セクション4.2。 |
Type 14: SLOW -- maintain window size of 1 on this |
connection. See section 4.2. |
14はタイプします: SLOW--これで1のウィンドウサイズを維持してください。| 接続。 セクション4.2を見てください。 |
Type 15: Name or Address Error - This message is sent in |
response to a type 0 message from a host that |
contained an erroneous Destination Host field. Its |
sub-types are: |
2: The Destination Host name is not authorized. |
3: The physical host to which this singly-homed |
Destination Host name translated is authorized |
and up, but not effective. If the host was |
actually down, a type 7 message would be |
returned, not a type 15. |
5: The multi-homed Destination Host name is |
authorized but has no available effective |
translations. |
6: A logically-addressed uncontrolled packet was sent |
to a dead or non-effective host port. However, |
if it is resubmitted, there may be another |
effective host port to which the PSN may be able |
to attempt to send the packet. |
7: Logical addressing is not in use. |
The PSN has no table of mappings from logical |
addresses to physical host ports. |
0, 1, 4, 8-15: Unassigned |
15はタイプします: 名前かAddress Error--このメッセージは送られます。| aからのタイプ0メッセージへの応答はそれを接待します。| 誤ったDestination Host分野を含みました。 それ| サブタイプは以下の通りです。 | 2: Destination Host名は認可されていません。 | 3: これが単独で家へ帰った物理ホスト| 翻訳された目的地Host名は認可されています。| 上がりますが、有効ではありません。 ホストがそうであったなら| 実際にダウンしてください、そして、タイプ7メッセージがあるでしょう。| どんなタイプ15でも、返しません。 | 5: マルチ、家へ帰り、Destination Host名はそうです。| 認可しますが、利用可能なノーを有効にします。| 翻訳。 | 6: 論理的に扱われた非制御のパケットを送りました。| 死者か事故者に、ポートを接待してください。 しかしながら| それが再提出されるなら、別のものがあるかもしれません。| PSNができるかもしれない有効なホストポート| 試みるには、パケットを送ってください。 | 7: 論理的なアドレシングは使用中ではありません。 | PSNには、論理的であるのからのマッピングのテーブルが全くありません。| 物理ホストポートに扱います。 | 0, 1, 4, 8-15: 割り当てられません。|
Type 16: GO -- maintain window size of 8 on this |
connection. See section 4.2. |
16はタイプします: GO--これで8のウィンドウサイズを維持してください。| 接続。 セクション4.2を見てください。 |
Type 17: Network Precedence Level Cutoff Change -- bits 33 |
and 34 encode the minimum precedence level currently |
being accepted by the network. See section 4.3.
17はタイプします: ネットワークPrecedence Level Cutoff Change--ビット33| そして、34は現在、最小の先行レベルをコード化します。| ネットワークによって受け入れられます。 セクション4.3を見てください。
Types 18-255: Unassigned.
タイプ18-255: 割り当てられない。
Bits 33-40: Handling Type:
This has the value assigned by the source host (see
1822(3.1)). This field is only used in message types 0, 5-
9, and 13-16.
ビット33-40: 取り扱いタイプ: 送信元ホストはこれで値を割り当てます。(1822(3.1))を見てください。 この分野はメッセージタイプ0、5- 9、および13-16に使用されるだけです。
Bits 41-64: Source Host:
See 1882(3.4). For type 0 messages this contains the
physical address of the source host, in the format detailed
in figure 3.2. For type 4 messages, this contains the
physical address of the local host. For messages of type
5-9, 11 and 13-16 which are responses to messages from the
ビット41-64: 送信元ホスト: 1882(3.4)を見てください。 タイプ0メッセージに関しては、これは図で詳細な形式に3.2に送信元ホストの物理アドレスを含んでいます。 タイプ4メッセージに関しては、これはローカル・ホストの物理アドレスを含んでいます。 タイプ5-9、11、および13-16に関するメッセージのために、どれから、メッセージへの応答は来ているか。
Khanna & Malis [Page 31] RFC 1005 May 1987
Khanna&Malis[31ページ]RFC1005 1987年5月
local host, this contains the destination name as specified
in the message from the local host.
ローカル・ホスト、これはローカル・ホストからのメッセージの指定されるとしての目的地名を含んでいます。
Bits 65-76: Message ID:
For message types 0, 5, 7-9, and 15, this is the value
assigned by the source host to identify the message (see
section 5.1). This field is also used by message types 2
and 6.
ビット65-76: メッセージID: メッセージタイプ0、5、7-9、および15のために、これはメッセージを特定するために送信元ホストによって割り当てられた値(セクション5.1を見る)です。 また、この分野はメッセージタイプ2と6によって使用されます。
Bits 77-80: Sub-type:
This field is used as a modifier by message types 0-2, 5-7,
9, and 15.
ビット77-80: サブタイプ: この分野は修飾語としてメッセージタイプ0-2、5-7、9、および15によって使用されます。
Bits 81-96: Message Length:
This field is contained in type 0 messages only, and is the
actual length in bits of the message (exclusive of leader,
leader padding, and hardware padding) as computed by the
PSN.
ビット81-96: メッセージ長: この分野は、タイプ0メッセージだけに含まれていて、PSNによって計算されるようにメッセージ(リーダー、リーダー詰め物、およびハードウェア詰め物を除いた)のビットの実際の長さです。
Khanna & Malis [Page 32] RFC 1005 May 1987
Khanna&Malis[32ページ]RFC1005 1987年5月
6 AHIP-E VERSIONS
6 AHIP-Eバージョン
This specification provides three versions of AHIP-E and allows a host to specify its version in bits 13-16 of the leader of the NOP. The PSN will set the version of a host based on the value contained in the most recent NOP that it has received from the host. Thus, a host can change the PSN's idea of its version by issuing a NOP containing a different version value. Note that the version field in all other host-to-PSN messages will be ignored by the PSN.
この仕様は、AHIP-Eの3つのバージョンを前提として、ホストがNOPのリーダーのビット13-16のバージョンを指定するのを許容します。 PSNはそれがホストから受けた最新のNOPに含まれた値に基づくホストのバージョンを設定するでしょう。 したがって、ホストはNOPを発行するのによるバージョンが異なった見解値を含むというPSNの考えを変えることができます。 ホストからPSNへの他のすべてのメッセージのバージョン分野がPSNによって無視されることに注意してください。
Version 0:
バージョン0:
A host that doesn't change its current AHIP implementation will presumably have the version bits in the AHIP leader set to zero. Version 0, thus, is nothing but current AHIP.
おそらく、現在のAHIP実装を変えないホストはAHIPリーダーのバージョンビットをゼロにセットさせるでしょう。 その結果、バージョン0はただ現在のAHIPです。
A version 0 host will not receive any of the new AHIP-E messages from the PSN, nor will the PSN expect any of the new host-to-PSN message types from the host. The type-of-service bits will always be set to zero in the PSN-to-host leader.
バージョン0ホストはPSNから新しいAHIP-Eメッセージのいずれも受け取らないでしょう、そして、PSNはホストからホストからPSNへのメッセージ新しいタイプを少しも期待しないでしょう。 サービス・ビットのタイプはPSNからホストへのリーダーでいつもゼロに用意ができるでしょう。
Version 1:
バージョン1:
A version 1 host will be able to use logical names to address other hosts, will be able to use the 10-bit PSN field, will be able to specify desired type-of-service to the PSN, but will not receive any of the new AHIP-E messages from the PSN. The PSN will not expect any of the new host-to-PSN message types from the host either.
バージョン1ホストは、他のホストに演説するのに論理的な名前を使用できますが、10ビットのPSN分野を使用できますが、必要なサービスのタイプをPSNに指定できますが、PSNから新しいAHIP-Eメッセージのいずれも受け取らないでしょう。 PSNはホストからホストからPSNへのメッセージ新しいタイプを少しも期待しないでしょう。
To implement version 1, a host need only make the following changes to its AHIP implementation:
バージョン1を実装するために、ホストはAHIP実装への以下の変更を行うだけでよいです:
1. Set the version number field to 1 when sending type 4
messages (NOPs).
1. 4つのメッセージ(NOPs)をタイプに送るときにはバージョンナンバーフィールドを1に設定してください。
2. When sending type 0 messages, copy IP address bits 8-31
into bits 41-64 of the AHIP leader.
2. 0つのメッセージをタイプに送るときには、AHIPリーダーのビット41-64にIPアドレスビット8-31をコピーしてください。
3. When sending type 0 messages, copy IP header bits 11-13
to AHIP leader bits 9-11.
3. 0つのメッセージをタイプに送るときには、AHIPリーダービット9-11テロにIPヘッダービット11-13をコピーしてください。
Version 2:
バージョン2:
A version 2 host is one that is fully compliant with the AHIP-E protocol as described in this document. In addition to being able to take advantage of the features described under version 1 above, it should be able to send and receive all the new AHIP-E messages described in this document.
バージョン2ホストは本書では説明されるようにAHIP-Eプロトコルで完全に言いなりになっているものです。 バージョン1の下で説明された特徴を利用できることに加えて、それは、本書では説明されたすべての新しいAHIP-Eメッセージを、送って、上では、受け取ることができるべきです。
Khanna & Malis [Page 33] RFC 1005 May 1987
Khanna&Malis[33ページ]RFC1005 1987年5月
7 REFERENCES
7つの参照箇所
[1] "Specifications for the Interconnection of a Host and an
PSN", BBN Report 1822, as found in "DDN Protocol Handbook",
December 1985, vol. 3, section 3.10.
[1] 「ホストとPSNのインタコネクトのための仕様」、BBN Report1822、中で見つけられるように「DDNはハンドブックについて議定書の中で述べます」、1985年12月、vol.3、セクション3.10。
[2] E. C. Rosen et. al., "ARPANET Routing Algorithm
Improvements", Internet Experimenter's Note 183 (also
published as BBN Report 4473, Vol. 1), August 1980, pp. 55-
107.
[2]E.C.ローゼンetアル「アルパネットはアルゴリズム改良を発送すること」でのインターネットExperimenterのNote183(また、BBN Report4473、Vol.1として、発行されます)、1980年8月、ページ 55- 107.
[3] J. Reynolds and J. Postel, "Assigned Numbers", Request For
Comments 990, November 1986.
[3] 「規定番号」というJ.レイノルズとJ.ポステルはコメントのために990、1986年11月を要求します。
[4] J. Postel, ed., "Internet Protocol -- DARPA Internet
Program Protocol Specification", Request for Comments 791,
September 1981.
[4] J.ポステル、教育、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」Comments791、9月1981日のRequest
[5] J. Postel, "Address Mappings", Request for Comments 796,
September 1981, as found in "DDN Protocol Handbook", vol.
3, section 3.4.
[5] J.ポステル、「マッピングを扱ってください」、Comments796のためのRequest、1981年9月、「DDNプロトコルハンドブック」で見つけられるように、vol.3、セクション3.4。
[6] "Defense Data Network X.25 Host Interface Specification",
pp. 497-498, DDN protocol handbook, vol. 1, December 1985.
[6] 「ディフェンスデータ網X.25ホスト・インターフェース仕様」、ページ 497-498 DDNは1985年12月にハンドブック、vol.1について議定書の中で述べます。
Khanna & Malis [Page 34]
Khanna&Malis[34ページ]
一覧
スポンサーリンク
