RFC995 日本語訳
0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473. International Organization forStandardization. April 1 1986. (Format: TXT=94069 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group ANSI X3S3.3 86-118
Request for Comments: 995 ISO TC97/SC6/N 4053
April 1986
コメントを求めるワーキンググループANSI X3S3.3 86-118要求をネットワークでつないでください: 995 N4053 1986年ISO TC97/SC6/4月
I S O
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
ORGANISATION INTERNATIONALE DE NORMALISATION
I S O国際標準化機構機構インターナショナルDE正常化
______________________________________________________________________
| |
| ISO/TC 97/SC 6 |
| TELECOMMUNICATIONS AND INFORMATION |
| EXCHANGE BETWEEN SYSTEMS |
| Secretariat: USA (ANSI) |
| |
| |
|_____________________________________________________________________|
______________________________________________________________________ | | | ISO/Tc97/サウスカロライナ6| | テレコミュニケーションと情報| | システムの間の交換| | 事務局: 米国(ANSI)| | | | | |_____________________________________________________________________|
Title: End System to Intermediate System Routing Exchange Protocol
for use in conjunction with ISO 8473
タイトル: ISO8473に関連した使用のためのIntermediate Systemルート設定Exchangeプロトコルへの終わりのSystem
Source: SC6/WG2
Project 97.6.41
ソース: SC6/WG2プロジェクト97.6.41
___________________________________________________________________________ |This document is a progression of SC6/N3862, edited to incorporate member | |body comments and discussion at the Florence meeting of SC6/WG2. Pursuant | |to Recommendation 5 of that meeting, comments from member bodies on this | |revision text are requested for discussion at the Tokyo meeting of SC6 | |and WGs. | |__________________________________________________________________________|
___________________________________________________________________________ |このドキュメントはメンバーを取り入れるために編集されたSC6/N3862の進行です。| |SC6/WG2のフィレンツェミーティングにおけるボディーコメントと議論。 準ずる| |メンバーボディーからのそのミーティングのRecommendation5、このコメントに| |改正テキストは議論のためにSC6の東京のミーティングで要求されています。| |そして、WGs。 | |__________________________________________________________________________|
ISO N4053 [Page 1] RFC 995 December 1986
ISO N4053[1ページ]RFC995 1986年12月
Contents
コンテンツ
1 Introduction 5
1 序論5
2 Scope and Field of Application 6
2 アプリケーション6の範囲と分野
3 References 7
3つの参照箇所7
SECTION ONE. GENERAL 9
セクション1。 一般的な9
4 Definitions 9
4.1 Reference Model Definitions . . . . . . . . . . . . . . . . . 9
4.2 Network Layer Architecture Definitions . . . . . . . . . . . 9
4.3 Network Layer Addressing Definitions . . . . . . . . . . . . 9
4.4 Local Area Network Definitions . . . . . . . . . . . . . . . 10
4.5 Additional Definitions . . . . . . . . . . . . . . . . . . . . 10
4つの定義9 4.1の規範モデル定義. . . . . . . . . . . . . . . . . 9 4.2ネットワーク層構造定義. . . . . . . . . . . 9 4.3ネットワーク層アドレシング定義. . . . . . . . . . . . 9 4.4ローカル・エリア・ネットワーク定義. . . . . . . . . . . . . . . 10 4.5の追加定義. . . . . . . . . . . . . . . . . . . . 10
5 Symbols and Abbreviations 10
5.1 Data Units . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 10
5.3 Protocol Data Unit Fields . . . . . . . . . . . . . . . . . . 10
5.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 11
5つのシンボルと略語10 5.1データ単位. . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2のプロトコルデータ単位. . . . . . . . . . . . . . . . . . . . . 10 5.3プロトコルデータ単位分野. . . . . . . . . . . . . . . . . . 10 5.4パラメタ. . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5その他. . . . . . . . . . . . . . . . . . . . . . . . 11
6 Overview of the Protocol 11
6.1 Information Provided by the Protocol . . . . . . . . . . . . . 11
6.2 Subsets of the Protocol. . . . . . . . . . . . . . . . . . . . 12
6.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4 Underlying Service Assumed by the Protocol . . . . . . . . . 12
6.4.1 Subnetwork Addresses . . . . . . . . . . . . . . . . . 12
6.4.2 Subnetwork User Data . . . . . . . . . . . . . . . . . 13
6.5 Service Assumed from Local Environment . . . . . . . . . . . . 13
6.6 Subnetwork Types . . . . . . . . . . . . . . . . . . . . . . . 14
6.6.1 Point-to-Point Subnetworks . . . . . . . . . . . . . . 15
6.6.2 Broadcast Subnetworks . . . . . . . . . . . . . . . . 15
6.6.3 General Topology Subnetworks . . . . . . . . . . . . . 16
情報がプロトコル. . . . . . . . . . . . . 11 6.2でプロトコルの部分集合を提供したプロトコル11 6.1のものの6概観。 . . . . . . . . . . . . . . . . . . . 12 6.3 サービスの基礎となるアドレシング. . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4は、プロトコル. . . . . . . . . 12 6.4.1のサブネットワークアドレス. . . . . . . . . . . . . . . . . 12 6.4で.2のサブネットワーク利用者データ. . . . . . . . . . . . . . . . . 13 6.5が地方の環境から想定されたサービスであると仮定しました; .136.6サブネットワークは.146.6に.1の二地点間サブネットワーク. . . . . . . . . . . . . . 15 6.6.2の放送サブネットワーク. . . . . . . . . . . . . . . . 15 6.6.3の一般トポロジーサブネットワーク. . . . . . . . . . . . . 16をタイプします。
SECTION TWO. SPECIFICATION OF THE PROTOCOL 18
セクションTWO。 プロトコル18の仕様
7 Protocol Functions 18
7.1 Protocol Timers . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.1 Configuration Timer . . . . . . . . . . . . . . . . . 18
7.1.2 Holding Timer . . . . . . . . . . . . . . . . . . . . 18
7.2 Report Configuration Function . . . . . . . . . . . . . . . . 18
7.2.1 Report Configuration by End Systems . . . . . . . . . 19
7.2.2 Report Configuration by Intermediate Systems . . . . . 19
7.3 Record Configuration Function . . . . . . . . . . . . . . . . 20
7.4 Flush Old Configuration Function . . . . . . . . . . . . . . 20
7.5 Query Configuration Function . . . . . . . . . . . . . . . . . 20
タイマ. . . . . . . . . . . . . . . . . . . . 18 7.2を持っている7つのプロトコル機能18 7.1個のプロトコルタイマ. . . . . . . . . . . . . . . . . . . . . . . 18 7.1.1構成タイマ. . . . . . . . . . . . . . . . . 18 7.1.2が構成機能. . . . . . . . . . . . . . . . 18 7.2を報告します; 中間システム. . . . . 19 7.3の記録的な構成機能. . . . . . . . . . . . . . . . 20 7.4の豊富な古い構成機能. . . . . . . . . . . . . . 20 7.5質問構成機能. . . . . . . . . . . . . . . . . 20によるエンドシステム. . . . . . . . . 19 7.2.2レポート構成による1つのレポート構成
ISO N4053 [Page 2] RFC 995 December 1986
ISO N4053[2ページ]RFC995 1986年12月
7.6 Configuration Response Function . . . . . . . . . . . . . . . 21
7.7 Request Redirect Function. . . . . . . . . . . . . . . . . . . 22
7.8 Record Redirect Function . . . . . . . . . . . . . . . . . . . 23
7.9 Refresh Redirect Function . . . . . . . . . . . . . . . . . . 23
7.10 Flush Old Redirect Function . . . . . . . . . . . . . . . . . 24
7.11 PDU Header Error Detection . . . . . . . . . . . . . . . . . 24
7.12 Classification of Functions . . . . . . . . . . . . . . . . . 25
7.6 構成レスポンス関数. . . . . . . . . . . . . . . 21 7.7は再直接の機能を要求します。 . . . . . . . . . . . . . . . . . . 22 7.8の記録的な再直接の機能. . . . . . . . . . . . . . . . . . . 23 7.9は機能. . . . . . . . . . . . . . . . . 25の再直接の機能. . . . . . . . . . . . . . . . . . 23 7.10の豊富な古い再直接の機能. . . . . . . . . . . . . . . . . 24 7.11PDUヘッダー誤り検出.24 7.12分類をリフレッシュします。
8 Structure and Encoding of PDUs 25
8.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2 Fixed Part . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2.1 General . . . . . . . . . . . . . . . . . . . . . . . 26
8.2.2 Network Layer Protocol Identifier . . . . . . . . . . 27
8.2.3 Length Indicator . . . . . . . . . . . . . . . . . . . 27
8.2.4 Version/Protocol Identifier Extension . . . . . . . . 27
8.2.5 Type Code . . . . . . . . . . . . . . . . . . . . . . 28
8.2.6 Holding Time . . . . . . . . . . . . . . . . . . . . . 28
8.2.7 PDU Checksum . . . . . . . . . . . . . . . . . . . . . 28
8.3 Network Address Part . . . . . . . . . . . . . . . . . . . . . 28
8.3.1 General . . . . . . . . . . . . . . . . . . . . . . . 28
8.3.2 NPAI (Network Protocol Address Information) En-
coding . . . . . . . . . . . . . . . . . . . . . . . . 28
8.3.3 Source Address Parameter for ESH PDU . . . . . . . . 29
8.3.4 Network Entity Title Parameter for ISH PDU . . . . . . 29
8.3.5 Destination Address Parameter for RD PDU . . . . . . . 30
8.4 Subnetwork Address Part . . . . . . . . . . . . . . . . . . . 30
8.4.1 Subnetwork Address Parameter for RD PDU . . . . . . . 31
8.5 Options Part . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.5.1 General . . . . . . . . . . . . . . . . . . . . . . . 31
8.5.2 Security . . . . . . . . . . . . . . . . . . . . . . . 32
8.5.3 Quality of Service Maintenance . . . . . . . . . . . . 33
8.5.4 Priority . . . . . . . . . . . . . . . . . . . . . . . 33
8.6 End System Hello (ESH) PDU . . . . . . . . . . . . . . . . . . 34
8.6.1 Structure . . . . . . . . . . . . . . . . . . . . . . 34
8.7 Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 35
8.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . 35
8.8 Redirect (RD) PDU. . . . . . . . . . . . . . . . . . . . . . . 36
8.8.1 Structure . . . . . . . . . . . . . . . . . . . . . . 36
8 PDUs25 8.1構造. . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2固定パート. . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2.1の一般.268.2.2ネットワーク層プロトコル識別子. . . . . . . . . . 27 8.2.3長さのインディケータ. . . . . . . . . . . . . . . . . . . 27 8.2.4バージョン/プロトコル識別子拡張子. . . . . . . . 27 8.2.5の構造とコード化はコード. . . . . . . . . . . . . . . . . . . . . . 28 8.2.6把持時間をタイプします; . . . . . . . . . . . . . . . . . . . . 28 8.2.7 PDU Checksum. . . . . . . . . . . . . . . . . . . . . 28 8.3Network Address Part. . . . . . . . . . . . . . . . . . . . . 28 8.3.1、一般.288.3.2NPAI(ネットワークプロトコルAddress情報)アンコード化、.288.3、.3Source Address Parameter、ESH PDU、.298.3、.4Network Entity Title Parameter、ISH PDU. . . . . . 29 8.3.5Destination Address Parametえー、RD PDU. . . . . . . 30 8.4Subnetwork Address Partのために.308.4、.1Subnetwork Address Parameter、RD PDU. . . . . . . 31 8.5Options Part. . . . . . . . . . . . . . . . . . . . . . . . . 31 8.5.1一般、.318.5、.2Security、.328.5、.3Quality、Service Maintenanceについて; . . . . . . . . . . . 33 8.5.4 優先権、こんにちは、PDU. . . . . . . . . . . . . . . . . . 34 8.6.1がPDU. . . . . . . . . . . . . 35 8.7.1構造. . . . . . . . . . . . . . . . . . . . . . 35 8.8再直接でこんにちは、.348.7中間システム(ISH)を構造化する.338.6終わりのシステム(ESH)、(RD) PDU。 . . . . . . . . . . . . . . . . . . . . . . 36 8.8.1構造. . . . . . . . . . . . . . . . . . . . . . 36
9 Formal Description 37
9 形式的記述37
10 Conformance 37
10 順応37
ANNEX A. SUPPORTING TECHNICAL MATERIAL 38
A.1 Use of Timers . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1.1 Example of Holding Time for Route Redirection . . . . 38
A.1.2 Example of Holding Timer for Configuration Informa-
tion . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2 Refresh and timeout of Redirection information . . . . . . . . 39
A.3 System Initialization Considerations . . . . . . . . . . . . . 40
A.4 Optimizations for Flushing Redirects . . . . . . . . . . . . 41
Configuration Informa- tion. . . . . . . . . . . . . . . . . . . . . . . . . 39A.2 RefreshのためのHolding TimerのRoute Redirection.38A.1.2 ExampleとRedirection情報. . . . . . . . 39A.3 System初期設定ConsiderationsのタイムアウトのためのHolding TimeのTimers.38A.1.1 ExampleのANNEX A. SUPPORTING TECHNICAL MATERIAL38A.1 Use、Flushing Redirects. . . . . . . . . . . . 41のための.40A.4 Optimizations
ISO N4053 [Page 3] RFC 995 December 1986
ISO N4053[3ページ]RFC995 1986年12月
List of Tables
テーブルのリスト
1 Service Primitives for Underlying Service . . . . . . . . . . 12
2 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . 14
3 Categories of Protocol Functions . . . . . . . . . . . . . . . 25
4 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . 28
1 有効なPDUが.28にタイプするプロトコル機能. . . . . . . . . . . . . . . 25 4の基本的なサービス. . . . . . . . . . 12 2タイマ基関数. . . . . . . . . . . . . . . . . . . . . . . 14 3カテゴリのためのサービス基関数
List of Figures
数字のリスト
1 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . 27
2 Address Parameters . . . . . . . . . . . . . . . . . . . . . 29
3 ESH PDU - Network Address Part . . . . . . . . . . . . . . . 29
4 ISH PDU - Network Address Part . . . . . . . . . . . . . . . . 30
5 RD PDU - Network Address Part . . . . . . . . . . . . . . . . 30
6 ESH PDU - Address Part . . . . . . . . . . . . . . . . . . . 31
7 All PDUs - Options Part . . . . . . . . . . . . . . . . . . . 31
8 Encoding of Option Parameters . . . . . . . . . . . . . . . . 32
9 ESH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 34
10 ISH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 35
11 RD PDU Format when Redirect is to an IS . . . . . . . . . . . 36
12 RD PDU Format when Redirect is to an ES . . . . . . . . . . . 37
1個のPDUヘッダー; .293ESH PDU(ネットワーク・アドレスパート.294ISH PDU)がネットワークでつなぐ固定パート. . . . . . . . . . . . . . . . . . . 27 2アドレスパラメタは.305の第パートPDU--ネットワーク・アドレスパート.306ESH PDU--アドレス部を記述します…; 31 7 すべてのPDUs--、Redirectがオプションであるときに、Option Parameters. . . . . . . . . . . . . . . . 32 9ESH PDU Format. . . . . . . . . . . . . . . . . . . . . . . . 34 10ISH PDU Format.35 11RD PDU FormatのPart.318Encodingにゆだねる、ES. . . . . . . . . . . 37にはRedirectがあるときの.36 12RD PDU Formatです。
ISO N4053 [Page 4] RFC 995 December 1986
ISO N4053[4ページ]RFC995 1986年12月
1 Introduction
1つの序論
This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such intercon- nection.
このプロトコルはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなintercon- nectionを達成するのが必要です。
This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open System Inter- connection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This protocol permits End Systems and Intermediate Systems to exchange configuration and routing informa- tion to facilitate the operation of the routing and relaying func- tions of the Network Layer.
オープンSystem Inter接続のためにReference Modelで定義された層(ISO7498)とNetwork LayerのInternal Organizationで定義された構造(DIS8648)によってこのプロトコルは他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 このプロトコルは、End SystemsとIntermediate SystemsがルーティングとNetwork Layerのfunc- tionsをリレーする操作を容易にするために構成とルーティングinforma- tionを交換することを許可します。
The aspects of Network Layer routing that are concerned with communi- cation between end systems and intermediate systems on the same sub- network are to a great extent separable from the aspects that are concerned with communication among the intermediate systems that con- nect multiple subnetworks. This protocol addresses only the former aspects. It will be significantly enhanced by the cooperative opera- tion of an additional protocol that provides for the exchange of routing information among intermediate systems, but is useful whether or not such an additional protocol is available.
それを発送するNetwork Layerの局面はnectをだます中間システムの中にエンドシステムの間には、communi陽イオンがあって、中間システムが同じサブネットワークにある状態で、複数のサブネットワークがコミュニケーションに関する局面から分離できる大きい程度まであることを心配しています。 このプロトコルは前の局面だけを記述します。 それは中間システムの中にルーティング情報の交換に備えていますが、そのような追加議定書が利用可能であるか否かに関係なく、役に立つ追加議定書の協力的なオペラtionによってかなり高められるでしょう。
This protocol provides solutions for the following practical problems:
このプロトコルは以下の実用的な問題の解決法を提供します:
1. How do end systems discover the existence and reachability of
intermediate systems that can route NPDUs to destinations on
subnetworks other than the one(s) to which the end system is
directly connected?
1. エンドシステムはどのようにエンドシステムが直接接続されるもの(s)以外のサブネットワークの上でNPDUsを目的地に発送できる中間システムの存在と可到達性を発見しますか?
2. How do end systems discover the existence and reachability of
other end systems on the same subnetwork (when direct
examination of the destination NSAP address does not provide
information about the destination subnetwork)?
2. エンドシステムは同じサブネットワークの上でどのように他のエンドシステムの存在と可到達性を発見しますか?(送付先NSAPアドレスの主尋問が目的地サブネットワークの情報を提供しないと)
3. How do intermediate systems discover the existence and
reachability of end systems on each of the subnetworks to
which they are directly connected?
3. 中間システムはそれらが直接接続されるそれぞれのサブネットワークの上でどのようにエンドシステムの存在と可到達性を発見しますか?
4. How do end systems decide which intermediate system to use
to forward NPDUs to a particular destination when more than one
intermediate system is accessible?
4. エンドシステムは、1個以上の中間システムがアクセスしやすいときに、特定の目的地にNPDUsを送るのにどの中間システムを使用したらよいかをどのように決めますか?
The protocol assumes that:
プロトコルは、以下のことと仮定します。
1. Routing to a specified subnetwork point of attachment address
(SNPA) on the same subnetwork is carried out satisfactorily by
the subnetwork itself.
1. 同じサブネットワークに関する付属アドレス(SNPA)の指定されたサブネットワークポイントへのルート設定がサブネットワーク自体によって満足に行われます。
ISO N4053 [Page 5] RFC 995 December 1986
ISO N4053[5ページ]RFC995 1986年12月
2. The subnetwork is not, however, capable of routing on a global
basis using the NSAP address alone to achieve communication
with a requested destination.
2. しかしながら、ルーティングはサブネットワークが地球規模で要求された目的地とのコミュニケーションを達成するために単独のNSAPアドレスを使用できません。
Note:
Consequently, it is not possible to use Application Layer
communication to carry out the functions of this protocol.
以下に注意してください。 その結果、このプロトコルの機能を行うのにApplication Layerコミュニケーションを使用するのは可能ではありません。
The protocol is connectionless, and is designed to:
プロトコルは、コネクションレスであり、以下のことのために設計されています。
1. minimize the amount of a priori state information needed by
end systems before they can begin to communicate with other
end systems;
1. 彼らが他のエンドシステムとコミュニケートし始めることができる前にエンドシステムによって必要とされた先験的な州の情報の量を最小にしてください。
2. minimize the amount of memory needed to store routing
information in end systems; and
2. エンドシステムにルーティング情報を格納するのに必要であるメモリー容量を最小にしてください。 そして
3. minimize the computational complexity of end system routing
algorithms.
3. 終わりのシステムルーティング・アルゴリズムの計算量を最小にしてください。
The protocol is also designed to operate in close conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473). Since routing styles are usually closely related to communication styles, the information that this protocol provides to end systems and intermediate systems may or may not be appropriate information for supporting routing functions when a Network Layer protocol other than ISO 8473 is used.
また、プロトコルは、Connectionless-モードNetwork Service(ISO8473)のProvisionのためにプロトコルで近い接続詞で作動するように設計されています。 ルーティングスタイルが通常密接にコミュニケーションの方法に関連するので、このプロトコルがシステムと中間システムを終わらせるために提供されるという情報はISO8473以外のNetwork Layerプロトコルが使用されているとき経路選択機能を支持するための適切な情報であるかもしれません。
2 Scope and Field of Application
2 範囲と応用分野
This International Standard specifies a protocol which is used by Network Layer entities operating ISO 8473 in End Systems and Inter- mediate Systems (referred to herein as ES and IS respectively) to maintain routing information. The Protocol herein described relies upon the provision of a connectionless-mode underlying service.
この国際規格がEnd SystemsとInterの仲介のSystemsでISO8473を操作するNetwork Layer実体によって使用されるプロトコルを指定する、(ここにESに言及されて、それぞれ言及される、)、ルーティング情報を保守するために。 ここに説明されたプロトコルは基本的にコネクションレスなモードサービスの支給を当てにします。
This Standard specifies:
このStandardは指定します:
a) procedures for the transmission of configuration and routing
information between network entities residing in End Systems
and network entities residing in Intermediate Systems;
a) 構成の送信のための手順とEnd Systemsにあるネットワーク実体とIntermediate Systemsにあるネットワーク実体の間のルーティング情報。
b) the encoding of the protocol data units used for the transmission
of the configuration and routing information;
b) プロトコルデータ単位のコード化は構成とルーティングの送信に情報を使用しました。
c) procedures for the correct interpretation of protocol control
information; and
プロトコル制御情報の正しい解釈のためのc)手順。 そして
d) the functional requirements for implementations claiming
conformance to this Standard.
d) このStandardに順応を要求する実装のための機能条件書。
ISO N4053 [Page 6] RFC 995 December 1986
ISO N4053[6ページ]RFC995 1986年12月
The procedures are defined in terms of:
手順は以下に関して定義されます。
a) the interactions between End System and Intermediate System
network entities through the exchange of protocol data units;
and
a) End SystemとIntermediate Systemとの相互作用はプロトコルデータ単位の交換を通して実体をネットワークでつなぎます。 そして
b) the interactions between a network entity and an underlying
service provider through the exchange of subnetwork service
primitives.
b) サブネットワークサービス基関数の交換によるネットワーク実体と基本的なサービスプロバイダーとの相互作用。
This protocol does not specify any protocol elements or algorithms for facilitating routing and relaying among Intermediate Systems. Such functions are intentionally beyond the scope of this protocol.
このプロトコルは掘るのを容易にするためのどんなプロトコル要素やアルゴリズムも指定しません、そして、リレーして、このプロトコルの範囲が故意に向こうにIntermediate Systemsそのような機能の中に、あります。
3 References
3つの参照箇所
ISO 7498 Information Processing Systems --- Open Systems Intercon-
nection - Basic Reference Model
ISO7498情報処理システム--- 開いているSystems Intercon- nection--基本的なReference Model
DIS 7498/DAD1 Information Processing Systems --- Open Systems Intercon-
nection - Addendum to ISO 7498 Covering Connectionless-
mode Transmission
7498/DAD1情報処理システムをけなしてください。--- 開いているSystems Intercon- nection--ISO7498Covering ConnectionlessモードTransmissionへの付加物
ISO 8348 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Network Service
Definition
ISO8348情報処理システム--- システムの間のテレコミュニケーションと情報交換--ネットワーク・サービス定義
ISO 8348/AD1 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Addendum to the
Network Service Definition Covering Connectionless-mode
Transmission
ISO8348/AD1情報処理システム--- システムの間のテレコミュニケーションと情報交換--コネクションレス型伝送をカバーするネットワーク・サービス定義への付加物
ISO 8348/AD2 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Addendum to the
Network Service Definition Covering Network Layer Address-
ing
ISO8348/AD2情報処理システム--- システムの間のテレコミュニケーションと情報交換--ネットワーク層アドレスingをカバーするネットワーク・サービス定義への付加物
ISO 8473 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Protocol for Pro-
viding the Connectionless Network Service
ISO8473情報処理システム--- Systemsの間のテレコミュニケーションと情報Exchange--Connectionless Network Serviceを参照するProのためのプロトコル
DIS 8648 Information Processing Systems --- Telecommunications and
Information Exchange between Systems - Internal Organiza-
tion of the Network Layer
8648個の情報処理システムをけなしてください。--- システムの間のテレコミュニケーションと情報交換--ネットワーク層の内部のOrganiza- tion
ISO N4053 [Page 7] RFC 995 December 1986
ISO N4053[7ページ]RFC995 1986年12月
SC21/N965 OSI Management Framework --- Seventh Working Draft
SC21/N965 OSI管理フレームワーク--- 第7作業草案
DIS 8802 Local Area Networks
8802のローカル・エリア・ネットワークをけなしてください。
ISO N4053 [Page 8] RFC 995 December 1986
ISO N4053[8ページ]RFC995 1986年12月
SECTION ONE. GENERAL
セクション1。 一般
4 Definitions
4つの定義
4.1 Reference Model Definitions
4.1 規範モデル定義
This document makes use of the following concepts defined in ISO 7498:
このドキュメントはISO7498で定義された以下の概念を利用します:
(a) Network layer
(a) ネットワーク層
(b) Network service access point
(b) ネットワークサービスアクセスポイント
(c) Network service access point address
(c) ネットワーク・サービスアクセスポイントアドレス
(d) Network entity
(d) ネットワーク実体
(e) Routing
(e) ルート設定
(f) Network protocol
(f) ネットワーク・プロトコル
(g) Network relay
(g)ネットワークリレー
(h) Network protocol data unit
(h) ネットワーク・プロトコルデータ単位
4.2 Network Layer Architecture Definitions
4.2 ネットワーク層アーキテクチャ定義
This document makes use of the following concepts from DIS 8648, Internal Organization of the Network Layer:
このドキュメントはDIS8648、Network LayerのInternal Organizationからの以下の概念を利用します:
(a) Subnetwork
(a) サブネットワーク
(b) End System
(b) エンドシステム
(c) Intermediate System
(c) 中間システム
(d) Subnetwork Service
(d) サブネットワークサービス
(e) Subnetwork Access Protocol
(e) サブネットワークアクセス・プロトコル
(f) Subnetwork Independent Convergence Protocol
(f) サブネットワークの独立している集合プロトコル
4.3 Network Layer Addressing Definitions
4.3 ネットワーク層アドレシング定義
This document makes use of the following concepts from DIS 8348/DAD2, Addendum to the Network Service Definition Covering Network Layer Ad- dressing:
このドキュメントはDIS8348/DAD2からの以下の概念を利用します、Network Service Definition Covering Network Layer AdドレッシングへのAddendum:
(a) Subnetwork address
(a) サブネットワークアドレス
(b) Subnetwork point of attachment
(b) サブネットワーク接着点
ISO N4053 [Page 9] RFC 995 December 1986
ISO N4053[9ページ]RFC995 1986年12月
4.4 Local Area Network Definitions
4.4 ローカル・エリア・ネットワーク定義
This document makes use of the following concepts from DIS 8802, Local Area Networks:
このドキュメントはDIS8802、ローカル・エリア・ネットワークからの以下の概念を利用します:
(a) multicast address
(a) マルチキャストアドレス
(b) broadcast medium
(b) 放送媒体
4.5 Additional Definitions
4.5 追加定義
For the purposes of this document, the following definitions apply:
このドキュメントの目的のために、以下の定義は申し込まれます:
Configuration: The collection of End and Intermediate Systems
attached to a single subnetwork, defined in terms of the
system types, NSAP addresses present, Network Entities
present, and the correspondence between systems and SNPA
addresses.
構成: EndとIntermediate Systemsの収集はシステムとSNPAアドレスとのシステムタイプ、アドレスが寄贈するNSAP、Network Entitiesプレゼント、および通信で定義された単一のサブネットワークに付きました。
Network Entity Title: An identifier for a network entity which
has the same abstract syntax as an NSAP address, and which
can be used to unambiguously identify a network entity in
an End or Intermediate System.
実体タイトルをネットワークでつないでください: NSAPアドレスと同じ抽象構文を持って、EndかIntermediate Systemで明白にネットワーク実体を特定するのに使用できるネットワーク実体のための識別子。
5 Symbols and Abbreviations
5つのシンボルと略語
5.1 Data Units
PDU Protocol Data Unit
SNSDU Subnetwork Service Data Unit
5.1データ単位のPDUはデータ単位SNSDUサブネットワークサービスデータ単位について議定書の中で述べます。
5.2 Protocol Data Units
5.2 プロトコルデータ単位
ESH PDU End System Hello Protocol Data Unit
ISH PDU Intermediate System Hello Protocol Data Unit
RD PDU Redirect Protocol Data Unit
こんにちは、こんにちは、プロトコルデータ単位ISH PDU中間システムプロトコルデータ単位第PDUが向け直すESH PDUエンドシステムはデータ単位について議定書の中で述べます。
5.3 Protocol Data Unit Fields
5.3 プロトコルデータ単位分野
NPID Network Layer Protocol Identifier
LI Length Indicator
V/P Version/Protocol Identifier Extension
TP Type
CS Checksum
NETL Network entity Title Length
NET Network entity Title
DAL Destination Address Length
DA Destination Address
SAL Source Address Length
SA Source Address
BSNPAL SN Address Length of better route to destination
BSNPA SN Address of better route to destination
目的地への、より良いルートの目的地BSNPA SN Addressへの、より良いルートのNPID Network LayerプロトコルIdentifier LI Length Indicator V/Pバージョン/プロトコルIdentifier Extension TP Type CS Checksum NETL Network実体Title Length NET Network実体Title DAL Destination Address Length DA Destination Address SAL Source Address Length SA Source Address BSNPAL SN Address Length
ISO N4053 [Page 10] RFC 995 December 1986
ISO N4053[10ページ]RFC995 1986年12月
HT Holding timer
HT Holdingタイマ
5.4 Parameters
CT Configuration Timer
RT Redirect Timer
5.4に、パラメタコネチカット構成タイマRTはタイマを向け直します。
5.5 Miscellaneous
5.5 その他
ES End System
IS Intermediate System
SN Subnetwork
SNACP Subnetwork Access Protocol
SNICP Subnetwork Independent Convergence Protocol
ESエンドシステムは中間システムのアクセス・プロトコルのSNICPのサブネットワークの独立している集合SNサブネットワークSNACPサブネットワークプロトコルです。
6 Overview of the Protocol
プロトコルの6概要
6.1 Information Provided by the Protocol
6.1 プロトコルによって提供された情報
This Protocol provides two types of information to Network entities which support its operation:
このプロトコルは操作をサポートするNetwork実体に2つのタイプの情報を提供します:
a) Configuration Information, and
a) そして設定情報。
b) Route Redirection Information
b) ルートリダイレクション情報
Configuration Information permits End Systems to discover the ex- istence and reachability of Intermediate Systems and permits Inter- mediate Systems to discover the existence and reachability of End Systems. This information allows ESs and ISs attached to the same subnetwork to dynamically discover each other's existence and availa- bility, thus eliminating the need for manual intervention at ESs and ISs to establish the identity of Network entities that can be used to route NPDUs.
構成情報は、End SystemsがIntermediate Systemsの元のistenceと可到達性を発見することを許可して、Interの仲介のSystemsがEnd Systemsの存在と可到達性を発見することを許可します。同じサブネットワークに取り付けられたESsとISsはこの情報でダイナミックに互いの存在とavaila- bilityを発見できます、その結果、ESsとISsでの手動の介入がNPDUsを発送するのに使用できるNetwork実体のアイデンティティを確立する必要性を排除します。
Configuration Information also permits End Systems to obtain informa- tion about each other in the absence of an available Intermediate System.
また、構成情報は、End Systemsが利用可能なIntermediate Systemが不在のとき互いに関してinforma- tionを入手することを許可します。
Note:
The term "configuration information" is not intended in the broad
sense of configuration as used in the context of OSI system
management. Rather, only the functions specifically defined herein
are intended.
以下に注意してください。 「設定情報」という用語はOSIシステム管理の文脈で使用されるように構成の広い意味で意図しません。 明確に定義された機能だけがここに意図します。
Route Redirection Information allows Intermediate Systems to inform End Systems of (potentially) better paths to use when forwarding NPDUs to a particular destination. A better path could either be another IS on the same subnetwork as the ES, or the destination ES itself, if it on the same subnetwork as the source ES. Allowing the ISs to inform the ESs of routes minimizes the complexity of routing decisions in End Systems and improves performance because the ESs may
ルートRedirection情報で、Intermediate Systemsは特定の目的地にNPDUsを送るとき使用する(潜在的に)より良い経路についてEnd Systemsに知らせることができます。 より良い経路はソースESと同じサブネットワークの上にES、または目的地ES自身と同じサブネットワークの上に別のものがそれであるならあるということであるかもしれません。 ISsがルートについてESsに知らせるのを許容するのが、End Systemsのルーティング決定の複雑さを最小にして、ESsが向上するので、性能を向上させます。
ISO N4053 [Page 11] RFC 995 December 1986
ISO N4053[11ページ]RFC995 1986年12月
make use of the better IS or local subnetwork access for subsequent transmissions.
より良いことの造の使用はそうであるか地方のサブネットワークがその後のトランスミッションのためのアクセスです。
6.2 Subsets of the Protocol
6.2 プロトコルの部分集合
A Network Entity may choose to support either the Configuration In- formation, the Route Redirection Information, neither, or both. If the Configuration Information is supported, it is not required that it be employed over all subnetworks to which the Network entity is attached.
Network Entityは、Configuration In構成か、Route Redirection情報も、両方もサポートしないのを選ぶかもしれません。 Configuration情報がサポートされるなら、それがNetwork実体が付けているすべてのサブネットワークの上で使われるのが必要ではありません。
6.3 Addressing
6.3 アドレシング
The Source Address and Destination Address parameters referred to in this International Standard are OSI Network Service Access Point Ad- dresses. The syntax and semantics of an OSI Network Service Access Point Address are described in a separate document, ISO 8348/DAD2, Addendum to the Network Service Definition covering Network Layer Ad- dressing.
パラメタがこの国際規格で言及したSource AddressとDestination AddressはOSI Network Service Access Point Adドレスです。 OSI Network Service Access Point Addressの構文と意味論は別々のドキュメントで説明されます、ISO8348/DAD2、Network Layer AdドレッシングをカバーするNetwork Service DefinitionへのAddendum。
6.4 Underlying Service Assumed by the Protocol
6.4 プロトコルによって想定された基本的なサービス
The underlying service required to support this protocol is defined by the primitives in Table 1.
このプロトコルをサポートするのに必要である基本的なサービスはTable1の基関数によって定義されます。
_________________________________________________________________
| SN_UNITDATA .Request | SN_Destination_Address, |
| .Indication | SN_Source_Address, |
| | SN_Quality_of_Service, |
| | SN_Userdata |
|_____________________________________|_________________________|
_________________________________________________________________ | SN_UNITDATA .Request| SN_送付先_アドレス| | .Indication| SN_ソース_アドレス| | | _サービスのSN_品質_| | | SN_Userdata| |_____________________________________|_________________________|
Table 1: Service Primitives for Underlying Service
テーブル1: 基本的なサービスのためのサービス基関数
Note:
These service primitives are used to describe the abstract interface
which exists between the protocol machine and an underlying real
subnetwork or a Subnetwork Dependent Convergence Function which
operates over a real subnetwork or real data link to provide the
required underlying service.
以下に注意してください。 これらのサービス基関数は、プロトコルマシンと基本的な本当のサブネットワークの間に存在する抽象的なインタフェースか必要な基本的なサービスを提供するために本当のサブネットワークか本当のデータ・リンクの上で作動するSubnetwork Dependent Convergence Functionについて説明するのに使用されます。
6.4.1 Subnetwork Addresses
6.4.1 サブネットワークアドレス
The source and destination addresses specify the points of attachment to a public or private subnetwork(s) involved in the transmission (known as Subnetwork Points of Attachment, or SNPAs).Subnetwork ad- dresses are defined in the Service Definition of each individual sub- network. This protocol is designed to take advantage of subnetworks which support broadcast, multicast, or other forms of multi-
情報筋と送付先アドレスが公衆への愛着のポイントを指定するか、または.Subnetwork広告が服を着せるトランスミッション(Subnetwork Pointsとして、Attachment、またはSNPAsが知られている)にかかわる個人的なサブネットワークはそれぞれの個々のサブネットワークのService Definitionで定義されます。 このプロトコルがサポート放送、マルチキャスト、またはもう一方が形成するサブネットワークを利用するように設計されている、マルチ
ISO N4053 [Page 12] RFC 995 December 1986
ISO N4053[12ページ]RFC995 1986年12月
destination addressing for n-way transmission. It is assumed that the SN_Destination_Address parameter may take on one of the following multi-destination addresses in addition to a normal single destina- tion address:
n-道の送信のための目的地アドレシング。 SN_Destination_Addressパラメタが正常なただ一つのdestina- tionアドレスに加えて以下のマルチ送付先アドレスの1つを帯びるかもしれないと思われます:
All End System Network entities
すべてのEnd System Network実体
All Intermediate System Network entities
すべてのIntermediate System Network実体
Where a real subnetwork does not inherently support broadcast or oth- er forms of transmission to multi-destination addresses, a conver- gence function may be used to provide n-way transmission to these multi-destination addresses.
えー、本当のサブネットワークが本来放送かothをサポートしないところでは、マルチ送付先アドレスへのトランスミッションのフォーム、conver- gence機能が、n-道の送信をこれらのマルチ送付先アドレスに提供するのに使用されるかもしれません。
When the SN_Destination_Address on the SN_UNITDATA.Request is a multi-destination address, the SN_Destination_Address parameter in the corresponding SN_UNITDATA.Indication shall be the same multi- destination address.
SN_Destination_であるときに、SN_UNITDATA.Requestの上のAddressがマルチ送付先アドレスである、対応するSN_UNITDATA.IndicationのSN_Destination_Addressパラメタは同じマルチ送付先アドレスになるでしょう。
The syntax and semantics of subnetwork addresses, except for the pro- perties described above, are not defined in this Protocol Standard.
上で説明された親perties以外に、サブネットワークアドレスの構文と意味論はこのプロトコルStandardで定義されません。
6.4.2 Subnetwork User Data
6.4.2 サブネットワーク利用者データ
The SN_Userdata is an ordered multiple of octets, and is transferred transparently between the specified subnetwork points of attachment.
SN_Userdataを八重奏の命令された倍数であり、透過的に付属の指定されたサブネットワークポイントの間に移します。
The underlying service is required to support a service data unit size of at least that required to operate the Protocol for Providing the Connectionless Network Service (ISO 8473).
基本的なサービスが、少なくともProviding Connectionless Network Service(ISO8473)のためにプロトコルを操作するのに必要であるそのサービスデータ単位サイズをサポートするのに必要です。
6.5 Service Assumed from Local Environment
6.5 地方の環境から想定されたサービス
A timer service must be provided to allow the protocol entity to schedule events.
プロトコル実体がイベントの計画をするのを許容するためにタイマー・サービスを提供しなければなりません。
There are three primitives associated with the S-TIMER service:
S-TIMERサービスに関連している3つの基関数があります:
1. the S--TIMER Request,
2. the S--TIMER Response, and
3. the S--TIMER Cancel.
1. S--2 S--3 タイマ要求、タイマ応答、およびS--タイマキャンセル。
The S--TIMER Request primitive indicates to the local environment that it should initiate a timer of the specified name and subscript and maintain it for the duration specified by the time parameter.
S--TIMER Request基関数は指定された名前と添字のタイマを開始して、パラメタによって指定された持続時間のためにそれを維持するべきであるのを地方の環境に示します。
The S--TIMER Response primitive is initiated by the local environment to indicate that the delay requested by the corresponding S-TIMER Re- quest primitive has elapsed.
S--TIMER Response基関数は地方の環境によって開始されて、対応するS-TIMER Re探索で原始的に要求された遅れが経過したのを示します。
The S--TIMER Cancel primitive is an indication to the local environ-
S--TIMERキャンセル原始的であるのは、地方への指示に取り巻かれるということです。
ISO N4053 [Page 13] RFC 995 December 1986
ISO N4053[13ページ]RFC995 1986年12月
ment that the specified timer(s) should be canceled.If the subscript parameter is not specified, then all timers with the specified name are canceled; otherwise, the timer of the given name and subscript is cancelled. If no timers correspond to the parameters specified, the local environment takes no action.
指定されたタイマがcanceled.Ifが添字パラメタであるならそうするmentは指定されません、次に、指定された名前があるすべてのタイマが取り消されます。 さもなければ、名と添字のタイマは取り消されます。 タイマが全く指定されたパラメタに対応していないなら、地方の環境は行動を全く取りません。
The parameters of the S--TIMER service primitives are specified in Table 2.
Sのパラメタ--TIMERサービス基関数はTable2で指定されます。
___________________________________________
| | |
| S--TIMER .Request | S-Time, |
| | S-Name, |
| | S-Subscript |
| | |
| .Response | S-Name, |
| | S-Subscript |
|__________________________|_______________|
___________________________________________ | | | | S--タイマ.Request| S-時間| | | S-名前| | | S-添字| | | | | .Response| S-名前| | | S-添字| |__________________________|_______________|
Table 2: Timer Primitives
テーブル2: タイマ基関数
The time parameter indicates the time duration of the specified ti- mer. An identifiying label is associated with a timer by means of the name parameter.The subscript parameter specifies a value to dis- tinguish timers with the same name. The name and subscript taken to- gether constitute a unique reference to the timer.
時間パラメタは指定されたti- merの時間持続時間を示します。 関連づけられたidentifiyingラベルは、同じ名前でtinguishタイマをけなすために名前parameter.The添字パラメタによるタイマで値を指定します。 取られた名前と添字、-、より多くのgetherにタイマのユニークな参照を構成してください。
Timers used in association with a specific protocol funtion are de- fined under that protocol function.
特定のプロトコルfuntionと関連して使用されるタイマはそのプロトコル機能の下で反-罰金を課されます。
Note:
This International Standard does not define specific values for the
timers.Any derivations described in this Standard are not mandatory.
Timer values should be chosen so that the requested Quality of
Service can be provided, given the known characteristics of the
underlying service.
以下に注意してください。 このStandardで説明されたtimers.Any派生が義務的でないので、この国際規格は特定の値を定義しません。 タイマ値はServiceの要求されたQualityを提供できるように選ばれるべきです、知られている基本的にサービスの特性を考えて。
6.6 Subnetwork Types
6.6 サブネットワークタイプ
In order to evaluate the applicability of this protocol in particular configurations of End Systems, Intermediate Systems and subnetworks, three generic types of subnetwork are identified. These are:
End Systems、Intermediate Systems、およびサブネットワークの特定の構成でこのプロトコルの適用性を評価するために、サブネットワークの3つのジェネリックタイプが特定されます。 これらは以下の通りです。
1. the point-to-point subnetwork,
1. 二地点間サブネットワーク
2. the broadcast subnetwork, and
そして2. 放送サブネットワーク。
3. the general topology subnetwork
3. 一般的なトポロジーサブネットワーク
These subnetwork types are discussed in the following clauses.
以下の節でこれらのサブネットワークタイプについて議論します。
ISO N4053 [Page 14] RFC 995 December 1986
ISO N4053[14ページ]RFC995 1986年12月
6.6.1 Point-to-Point Subnetworks
6.6.1 二地点間サブネットワーク
A point-to-point subnetwork supports exactly two systems. The two systems may be either two End Systems, or an End System and a single Intermediate System. A single point-to-point data link connecting two Network Entities is an example of a point-to-point subnetwork.
二地点間サブネットワークはまさに2台のシステムをサポートします。2台のシステムが、End Systemと2End Systemsか独身のIntermediate Systemのどちらかであるかもしれません。 2Network Entitiesを接続する単一の二地点間データ・リンクは二地点間サブネットワークに関する例です。
Configuration Information on a point-to-point Subnetwork.On a point- to-point subnetwork the Configuration Information of this protocol informs the communicating Network entities of the following:
a二地点間Subnetwork.On aポイントポイントへのこのプロトコルに関するConfiguration情報が以下の交信しているNetwork実体を知らせるサブネットワークに関する構成情報:
1. Whether the topology consists only of two End Systems, or
1. またはトポロジーが2End Systemsだけから成るかどうか。
2. One of the two systems is a Intermediate System.
2. 2台のシステムの1つはIntermediate Systemです。
Note:
On a point-to-point subnetwork, if both systems are Intermediate Systems,
then this protocol is inapplicable to the situation, since a IS-to-IS
protocol should be employed instead. However, there is no reason why
the configuration information could not be employed in a IS-to-IS
environment to ascertain the topology and initiate operation of a
IS-to-IS protocol.
以下に注意してください。 二地点間サブネットワークでは、このプロトコルは両方のシステムがIntermediate Systemsであるなら状況に不適当です、a以来ある、プロトコルが代わりに使われるべきです。 しかしながら、aで設定情報を使うことができなかった理由が全くない、ある、トポロジーを確かめて、aの操作を開始する環境、ある、議定書を作ってください。
The Intermediate System is informed of the NSAP address(es) supported by the Network entity in the End System. This permits reachability information and routing metrics concerning these NSAPs to be dissem- inated to other Intermediate Systems for the purpose of calculating routes to/from this End System.
Intermediate SystemはEnd SystemのNetwork実体によってサポートされたNSAPアドレス(es)において知識があります。 これは、これらのNSAPsに関する可到達性情報とルーティング測定基準がこのEnd Systemからの/にルートを計算する目的のための他のIntermediate Systemsへのdissem- inatedであることを許可します。
Route Redirection Information on a point-to-point Subnetwork. Route Redirection Information is not employed on point-to-point subnetworks because there are never any alternate routes.
二地点間Subnetworkに関するRedirection情報を発送してください。 どんな代替経路も決してないので、ルートRedirection情報は二地点間サブネットワークの上で使われません。
6.6.2 Broadcast Subnetworks
6.6.2 放送サブネットワーク
A Broadcast subnetwork supports an arbitrary number of End Systems and Intermediate Systems, and additionally is capable of transmitting a single SNPDU to all or a subset of these systems in response to a single SN_UNITDATA.Request.An example of a broadcast subnetwork is a LAN (local area network) conforming to DIS8802/2, type 1 operation.
Broadcastサブネットワークは、End SystemsとIntermediate Systemsの特殊活字の数字を支持して、さらに、独身のSNPDUをすべてに伝えることができますか、放送サブネットワークのただ一つのSN_UNITDATA.Request.Anの例に対応したこれらのシステムの部分集合はDIS8802/2(タイプ1操作)に従うLAN(ローカル・エリア・ネットワーク)です。
Configuration Information on a broadcast Subnetwork.On a broadcast subnetwork the Configuration Information of this protocol is employed to inform the communicating Network entities of the following:
このプロトコルに関するConfiguration情報が使われる放送Subnetwork.On a放送サブネットワークに関する構成情報は以下の交信しているNetwork実体を知らせます:
1. End Systems are informed of the reachability, Network entity Title,
and SNPA address(es) of each active Intermediate System on the
subnetwork.
1. 終わりのSystemsはサブネットワークの上のそれぞれのアクティブなIntermediate Systemの可到達性、Network実体Title、およびSNPAアドレス(es)において知識があります。
ISO N4053 [Page 15] RFC 995 December 1986
ISO N4053[15ページ]RFC995 1986年12月
2. Intermediate Systems are informed of the NSAP addresses supported
by each End System and the Subnetwork address of the ES. Once the
Intermediate System obtains this information, reachability
information and routing metrics concerning these NSAPs may be
disseminated to other ISs for the purpose of calculating routes
to/from each ES on the subnetwork.
2. 中間的Systemsは各End SystemによってサポートされたNSAPアドレスとESのSubnetworkアドレスにおいて知識があります。 Intermediate Systemがいったんこの情報を得ると、これらのNSAPsに関する可到達性情報とルーティング測定基準は各ESからの/にルートを計算する目的のためにサブネットワークの上で他のISsに広められるかもしれません。
3. In the absence of an available Intermediate System, End Systems may
query over a broadcast subnetwork to discover whether a particular
NSAP is reachable on the subnetwork, and if so, what SNPA address
to use to reach that NSAP.
3. 利用可能なIntermediate Systemが不在のとき、End Systemsは発見する放送サブネットワークの上で特定のNSAPがサブネットワークで届いているかどうかと、そうだとすれば、そのNSAPに達するのにどんなSNPAアドレスを使用したらよいかを質問するかもしれません。
Route Redirection Information on broadcast Subnetworks.Route Redirec- tion Information may be employed on broadcast subnetworks to permit Intermediate Systems to inform End Systems of superior routes to a destination NSAP. The superior route might be another IS on the same subnetwork as the ES, or it might be the destination ES itself, if it is directly reachable on the same subnetwork as the source ES.
放送Subnetworks.Route Redirec- tion情報に関するルートRedirection情報は、Intermediate Systemsが目的地NSAPへの優れたルートについてEnd Systemsに知らせることを許可するのに放送サブネットワークの上で使われるかもしれません。 優れたルートはESと同じサブネットワークの上に別のものがあるか、それが目的地ES自身であるかもしれません、それにソースESと同じサブネットワークで直接届くならことであるかもしれません。
6.6.3 General Topology Subnetworks
6.6.3 一般トポロジーサブネットワーク
A general topology subnetwork supports an arbitrary number of End Systems and Intermediate Systems, but does not support a convenient multidestination connectionless transmission facility as does a broadcast subnetwork.An example of a general topology subnetwork is a subnetwork employing X.25 or ISO 8208.
便利な「マルチ-目的地」を支持しないのを除いて、一般的なトポロジーサブネットワークはEnd SystemsとIntermediate Systemsの特殊活字の数字を支持します。一般的なトポロジーサブネットワークに関する放送subnetwork.Anの例のようなコネクションレスな通信施設はX.25かISO8208を使うサブネットワークです。
Note:
The crucial distinguishing characteristic between the broadcast
subnetwork and the general topology subnetwork is the "cost" of an
n-way transmission to a potentially large subset of the systems on
the subnetwork. On a general topology subnetwork, the cost is assumed
to be close to the cost of sending an individual PDU to each SNPA on
the subnetwork. Conversely, on a broadcast subnetwork the cost is
assumed to be close to the cost of sending a single PDU to one SNPA
on the subnetwork. Intermediate situations between these extremes
are of course possible. In such cases it would be possible to treat the
subnetwork as either in the broadcast or general topology categories.
以下に注意してください。 放送サブネットワークと一般的なトポロジーサブネットワークの間の重要な区別の特性はシステムの潜在的に大きい部分集合へのn-道の送信のサブネットワークの「費用」です。 一般的なトポロジーサブネットワークの上では、サブネットワークで個々のPDUを各SNPAに送る費用の近くに費用があると思われます。 逆に、放送サブネットワークの上では、サブネットワークで独身のPDUを1SNPAに送る費用の近くに費用があると思われます。 これらの極端の間の中間的状況はもちろん可能です。 そのような場合、サブネットワークを扱うのは放送や一般的なトポロジーカテゴリのように可能でしょう。
Configuration Information on a general topology Subnetwork. On a general topology subnetwork the Configuration Information is general- ly not employed because this protocol can be very costly in the util- ization (and charging for) subnetwork resources.
一般的なトポロジーSubnetworkに関する構成情報。 Configuration情報が一般的なトポロジーサブネットワークの上では、このプロトコルがutil- izationで非常に高価である場合があるので使われなかった一般的なlyである、(課金、)、サブネットワークリソース。
Route Redirection Information on a general topology Subnetwork. Route Redirection Information may be employed on general topology subnetworks to permit Intermediate Systems to inform End Systems of superior routes to a destination NSAP. The superior route might be another IS on the same subnetwork as the ES, or it might be the des- tination ES itself, if it is directly reachable on the same subnet-
一般的なトポロジーSubnetworkに関するRedirection情報を発送してください。 ルートRedirection情報は、Intermediate Systemsが目的地NSAPへの優れたルートについてEnd Systemsに知らせることを許可するのに一般的なトポロジーサブネットワークの上で使われるかもしれません。 優れたルートはESと同じサブネットワークの上に別のものがあるか、それがdes- tination ES自身であるかもしれません、それに同じサブネットで直接届くならことであるかもしれません。
ISO N4053 [Page 16] RFC 995 December 1986
ISO N4053[16ページ]RFC995 1986年12月
work as the source ES.
ソースESとして、働いてください。
ISO N4053 [Page 17] RFC 995 December 1986
ISO N4053[17ページ]RFC995 1986年12月
SECTION TWO. SPECIFICATION OF THE PROTOCOL
セクションTWO。 プロトコルの仕様
7 Protocol Functions
7 プロトコル機能
This section describes the functions performed as part of the Proto- col. Not all of the functions must be performed by every implementa- tion. Clause 7.12 specifies which functions may be omitted and the correct behavior where requested functions are not implemented.
このセクションはプロトあん部の一部として実行された機能について説明します。 あらゆるimplementa- tionが機能のすべてを実行しなければならないというわけではありません。 要求された機能が実行されないところで第7.12節はどの機能が省略されるかもしれないか、そして、正しい振舞いを指定します。
7.1 Protocol Timers
7.1 プロトコルタイマ
Many of the protocol functions are timer based. This means that they are executed upon expiration of a timer rather than upon receipt of a PDU or invocation of a service primitive. The two major types of ti- mers employed by the protocol are the Configuration Timer (CT) and the Holding Timer (HT).
プロトコル機能の多くが基づくタイマです。 これは、それらがPDUを受け取り次第というよりむしろタイマの満了かサービスの実施で原始的に実行されることを意味します。 プロトコルによって使われたti- mersの2つの主要なタイプが、Configuration Timer(コネチカット)とHolding Timer(HT)です。
7.1.1 Configuration Timer
7.1.1 構成タイマ
The Configuration Timer is a local timer (i.e. maintained indepen- dently by each system) which performs the Report Configuration func- tion (see section 7.2). The timer determines how often a system re- ports its availability to the other systems on the same subnetwork. The shorter the Configuration Timer, the more quickly other systems on the subnetwork will become aware when the reporting system becomes available or unavailable. The increased responsiveness must be traded off against increased use of resources in the subnetwork and in the recipient systems.
Configuration TimerはReport Configuration func- tionを実行する地方のタイマ(すなわち、各システムがindepen- dentlyであることが支持されます)(セクション7.2を見る)です。 タイマは、システムが同じサブネットワークでどれくらいの頻度で他のシステムに有用性を再移植するかを決定します。 Configuration Timerが短ければ短いほど、リポーティングシステムが利用可能であるか入手できなくなると、サブネットワークの上の他のシステムは、より急速に意識するようになるでしょう。 サブネットワークと受取人システムにおけるリソースの増加する使用に対して増加する反応性を交換しなければなりません。
7.1.2 Holding Timer
7.1.2 タイマを持っていること。
The Holding Timer applies to both Configuration Information and Route Redirection Information. The value of the Holding Timer is set by the source of the information and transmitted in the appropriate PDU. The recipient of the information is expected to retain the information no longer than the Holding Timer. Old Configuration or Route Redirection information must be discarded after the Holding Timer expires to en- sure the correct operation of the protocol.
Holding TimerはConfiguration情報とRoute Redirection情報の両方に適用します。 Holding Timerの値は、情報の情報筋によって設定されて、適切なPDUで送られます。 Holding Timerより情報の受取人がもう情報を保有しないと予想されます。 Holding Timerがアン確実にプロトコルの正しい操作するのに期限が切れた後に古いConfigurationかRoute Redirection情報を捨てなければなりません。
Further discussion of the rationale for these timers and guidelines for their use may be found in annex 10.
これらのタイマのための原理と彼らの使用のためのガイドラインのさらなる議論は別館10で見つけられるかもしれません。
7.2 Report Configuration Function
7.2 レポート構成機能
The Report Configuration Function is used by End Systems and Inter- mediate Systems to inform each other of their reachability and current subnetwork address. This function is invoked every time the local Configuration Timer (CT) expires in an ES or IS. It is also in- voked upon receipt of a Query Configuration PDU from another End Sys- tem.
Report Configuration Functionは、彼らの可到達性と現在のサブネットワークアドレスについて互いに知らせるのにEnd SystemsとInterの仲介のSystemsによって使用されます。 地方のConfiguration Timer(コネチカット)はESで期限が切れるか、またはあるときはいつも、この機能が呼び出されます。 また、それは別のEnd Sys- temからのQuery Configuration PDUを受け取り次第vokedされたコネです。
ISO N4053 [Page 18] RFC 995 December 1986
ISO N4053[18ページ]RFC995 1986年12月
7.2.1 Report Configuration by End Systems
7.2.1 エンドシステムによるレポート構成
An End System constructs and transmits one ESH PDU (ESH stands for "End System Hello") for each NSAP it serves, and issues one SN_UNITDATA.- Request with the ESH PDU as the SNSDU on each subnet- work to which it is attached.
End Systemが1ESH PDUを組み立てて、伝える、(ESHが表す、「エンドシステム、こんにちは、」、)、各NSAPに関しては、それは、付けるそれぞれのサブネット仕事のときにSNSDUとしてESH PDUとの1つのSN_UNITDATA.-要求に役立って、出します。
Note:
The necessity to transmit a separate ESH PDU for each NSAP served by
the Network entity arises from the lack of a formalized relationship
between Network Entity Titles and NSAP addresses. If this relationship
could be constrained to require that all NSAP addresses be assigned as
leaf subdomains of a domain represented by the local Network entity's
Network entity Title, then a single ESH PDU could be transmitted
containing the ESs Network entity Title.The Network entity Title
would then imply which NSAPs might be present at that End system.
以下に注意してください。 Network実体によって役立たれる各NSAPのために別々のESH PDUを伝える必要性はNetwork Entity TitlesとNSAPアドレスとの正式にされた関係の不足から起こります。 この関係を抑制できるなら、すべてのNSAPアドレスが地方のNetwork実体のNetwork実体Titleによって表されたドメインに関する葉のサブドメインとして割り当てられて、次に、独身のESH PDUが伝えられた含有であるかもしれないことが必要であるように、ESs Network実体Title.The Network実体TitleはおまけにプレゼントがEndシステムであるかもしれないならどのNSAPsを含意するか。
The Holding Timer (HT) field is set to approximately twice the ESs Configuration Timer (CT) parameter. This variable is set to a value large enough so that even if every other ESH PDU is discarded (due to lack of resources), or otherwise lost in the subnetwork, the confi- guration information will still be maintained. The value must be set small enough so that Intermediate Systems can respond in a timely fashion to End Systems becoming available or unavailable.
Holding Timer(HT)分野はESs Configuration Timer(コネチカット)パラメタのおよそ2倍に設定されます。 この変数が十分大きい値に設定されるので、それでも、他のあらゆるESH PDUが捨てられる(財源不足のため)、または別の方法でサブネットワークでなくされても、confi- guration情報は保守されるでしょう。 Intermediate Systemsが直ちに利用可能であるか入手できなくなるEnd Systemsに応じることができるように、十分小さく値を設定しなければなりません。
The SN_Destination_Address parameter is set to the group address that indicates "All Intermediate System Network Entities". This ensures that a single transmission on a broadcast subnetwork will reach all of the active Intermediate Systems.
SN_Destination_Addressパラメタは「すべての中間システムネットワーク実体」を示すグループアドレスに設定されます。 これは、放送サブネットワークにおけるただ一つのトランスミッションがアクティブなIntermediate Systemsのすべてに達するのを確実にします。
Note:
The actual value of the SN_Destination_Address used to mean "All
Intermediate System Network Entities" is subnetwork dependent and will
most likely vary from subnetwork to subnetwork. It would of course be
desirable that on widely-used subnetwork types (such as those based
on DIS 8802) that this value and the value of the "All End System
Network Entities" group address, be standardized.
以下に注意してください。 Addressが「すべての中間システムネットワーク実体」を意味するのに使用したSN_Destination_の実価は、サブネットワークに依存していて、サブネットワークによってたぶん異なるでしょう。 広く使用されたサブネットワークのそれが「すべてが体系網実体を終わる」というグループのこの値と値が記述する(DIS8802に基づくものとしてのそのようなもの)をタイプするのが、もちろん望ましいだろう、標準化されてください。
7.2.2 Report Configuration by Intermediate Systems
7.2.2 中間システムによるレポート構成
An Intermediate System constructs a single ISH PDU (ISH stands for "Intermediate System Hello") containing the ISs Network Entity Title and issues one SN_UNITDATA.Request with the ISH PDU as the SNSDU on each subnetwork to which it is attached.
Intermediate Systemが独身のISH PDUを組み立てる、(ISHが表す、「中間システム、こんにちは、」、)、それが付けている各サブネットワークの上のSNSDUとしてISH PDUとISs Network Entity Titleと問題1SN_UNITDATA.Requestを含んでいます。
The Holding Timer (HT) field is set to approximately twice the Inter- mediate System's Configuration Timer (CT) parameter. This variable is set to a value large enough so that even if every other ISH PDU is discarded (due to lack of resources), or otherwise lost in the sub- network, the configuration information will still be maintained.The value must be set small enough so that End Systems will quickly cease
Holding Timer(HT)分野はInter仲介のSystemのConfiguration Timer(コネチカット)パラメタのおよそ2倍に設定されます。 この変数が十分大きい値に設定されるので、他のあらゆるISH PDUが捨てられる(財源不足のため)、または別の方法でサブネットワークでなくされても、設定情報はまだEnd Systemsがすぐにやむように十分小さくmaintained.The値を設定しなければならないということでしょう。
ISO N4053 [Page 19] RFC 995 December 1986
ISO N4053[19ページ]RFC995 1986年12月
to use ISs that have failed, thus preventing "black holes" in the Network.
失敗する、その結果、Networkで「ブラックホール」を防いだISsを使用するために。
The SN_Destination_Address parameter is set to the group address that indicates "All End System Network Entities".This ensures that a sin- gle transmission on a broadcast subnetwork will reach all of the ac- tive End Systems.
SN_Destination_Addressパラメタは「すべての終わりの体系網実体」.Thisが、放送サブネットワークにおける罪のgle送信がac- tive End Systemsのすべてに達するのを確実にするのを示すグループアドレスに設定されます。
7.3 Record Configuration Function
7.3 記録的な構成機能
The Record Configuration function receives ESH or ISH PDUs, extracts the configuration information, and adds or replaces the corresponding configuration information in the local Network entity's Routing In- formation base. If insufficient space is available to store new con- figuration information, the PDU is discarded. No Error Report is gen- erated.
Record Configuration機能は、構成が基礎づける地方のNetwork実体のルート設定Inで対応する設定情報をESHかISH PDUsを受けるか、設定情報を抜粋して、加えるか、または置き換えます。 不十分なスペースが新しいまやかし形づけ情報を格納するために利用可能であるなら、PDUは捨てられます。 どんなError Reportもeratedされていた状態で情報を得ることではありません。
Note:
The protocol is described such that End Systems receive and record
only ISH PDUs and Intermediate Systems receive and process only
ESH PDUs. If an ES so desires however, it may decide to process ESH
PDUs as well (on a broadcast network this is easily done by enabling
the appropriate group address). There is potentially some performance
improvement to be gained by doing this, at the expense of extra memory,
and possibly extra processing cycles in the End System.The
ES, by recording other ESs' Configuration information, may be able
to route NPDUs directly to ESs on the local subnetwork without first
being redirected by a Intermediate System.
以下に注意してください。 プロトコルが説明されるので、End SystemsがISH PDUsだけを受けて、記録して、Intermediate SystemsはESH PDUsだけを受けて、処理します。 しかしながら、ESがそう望んでいるなら、それは、また、ESH PDUsを処理すると決めるかもしれません(放送網では、適切なグループアドレスを可能にすることによって、容易にこれをします)。 そうすれば余分なメモリーを犠牲にして獲得される何らかの性能改良が潜在的にあります、そして、他のESsのConfiguration情報を記録することによって、最初にIntermediate Systemによって向け直されないで、End System.The ESのことによると余分な加工サイクルは地方のサブネットワークの上で直接ESsにNPDUsを発送できるかもしれません。
Similarly, Intermediate Systems may choose to receive the ISH PDUs
of other ISs, allowing this protocol to be used as the initialization and
topology maintenance portion of a full IS-to-IS routing protocol.
Both of these possibilities are for further study.
同様に、Intermediate Systemsは、他のISsのISH PDUsを受け取るのを選ぶかもしれません、このプロトコルが満の初期化とトポロジーの維持部分として使用されるのを許容してある、ルーティング・プロトコル。 さらなる研究にはこれらの可能性の両方があります。
7.4 Flush Old Configuration Function
7.4 豊富な古い構成機能
The Flush Old Configuration Function is executed to remove Configura- tion entries in the routing information base whose Holding Timer has expired. When the Holding Time for an ES or IS expires, this func- tion removes the corresponding entry from the routing information base of the local Network Entity.
Flush Old Configuration Functionは、Holding Timerが期限が切れたルーティング情報ベースの中でConfigura- tionエントリーを取り除くために実行されます。 ESのためのHolding Timeである、存在、期限が切れる、このfunc- tionは地方のNetwork Entityのルーティング情報ベースから対応するエントリーを取り除きます。
7.5 Query Configuration Function
7.5 質問構成機能
The Query Configuration Function is performed under the following circumstances:
Query Configuration Functionは以下の状況で実行されます:
1. The End System is attached to a broadcast subnetwork,
1. End Systemは放送サブネットワークに取り付けられます。
2. There is no Intermediate System currently reachable on the
subnetwork (i.e. no ISH PDUs have been received since the last
2. 現在サブネットワークで届いているどんなIntermediate Systemもない、(最終以来すなわち、ISH PDUsを全く受け取っていません。
ISO N4053 [Page 20] RFC 995 December 1986
ISO N4053[20ページ]RFC995 1986年12月
information was flushed by the Flush Old Configuration Function),
情報がFlush Old Configuration Functionによって洗い流された、)
3. The Network Layer's Route PDU Function needs to obtain the SNPA
address to which to forward a PDU destined for a certain NSAP, and
3. そしてNetwork LayerのRoute PDU Functionが、あるNSAPのために運命づけられたPDUを送るSNPAアドレスを得る必要がある。
4. The SNPA address cannot be obtained either by a local transformation
or a local table lookup.
4. 局所変形か地方の索表はSNPAアドレスを得ることができません。
Note:
Despite appearances, this is actually a quite common case, since it
is likely that there will be numerous isolated Local Area Networks
without Intermediate Systems to rely upon for obtaining routing
information (e.g.via the Request Redirect Function of this protocol).
Further, if the Intermediate System(s) are temporarily unavailable,
without this capability communication on the local subnetwork would
suffer unless manually-entered tables were present in each End System
or all NSAPs of the subnetwork had the subnetwork SNPA address
embedded in them.
以下に注意してください。 外観にもかかわらず、多数の孤立しているローカル・エリア・ネットワークがIntermediate Systemsなしでありそうであって以来、これは実際にルーティング情報(例えば、このプロトコルのRequest Redirect Functionを通した)を得るために当てにする全く一般的なそうです。 さらに、この能力がなければ、Intermediate System(s)が一時入手できなく、手動で入られたテーブルが各End Systemに存在していたか、またはサブネットワークのすべてのNSAPsがサブネットワークSNPAアドレスを彼らに埋め込ませない場合、地方のサブネットワークに関するコミュニケーションに苦しむでしょうに。
The End System, when needing to route an NPDU to a destination NSAP whose SNPA is unknown issues an SN_UNITDATA.Request with the NPDU as the SN_Userdata.The SN_Destination_Address parameter is set to the group address that indicates "All End System Network Entities".
End System、NPDUを目的地に発送するのが必要であるときに、SN_Userdata.The SN_Destination_Addressパラメタが「すべての終わりの体系網実体」を示すグループアドレスに設定されるとき、SNPAが未知であるNSAPはNPDUと共にSN_UNITDATA.Requestを発行します。
Subsequently an ESH PDU may be received containing the NSAP address along with the corresponding SNPA address (see clause 7.6). In such a case the End System executes the Record Configuration function for the NSAP, and therefore will be able to route subsequent PDUs to that destination using the specified SNPA. If no ESH PDU is received, the End System may declare the destination NSAP is not reachable. The length of time to wait for a response before indicating a failure or the possibility of repeating the process some number of times before returning a failure are local matters and are not specified in this standard.
次に、対応するSNPAアドレスに伴うNSAPアドレスを含んでいて、ESH PDUを受け取るかもしれません(7.6番目の節を見てください)。 このような場合にはEnd Systemは、NSAPのためにRecord Configuration機能を実行して、したがって、指定されたSNPAを使用することでその後のPDUsをその目的地に発送できるでしょう。 どんなESH PDUも受け取られていないなら、End Systemは、目的地NSAPに届いていないと宣言するかもしれません。 失敗を示す前に応答を待つ時間の長さか失敗を返す前の何らかの数の回過程を繰り返す可能性が、地域にかかわる事柄であり、この規格で指定されません。
7.6 Configuration Response Function
7.6 構成レスポンス関数
The Configuration Response function is performed when an End System attached to a broadcast subnetwork receives an NPDU addressed to one of its NSAPs, with the SN_Destination_Address from the SN_UNITDATA.Indication set to the group address "All End System Netowrk Entities". This occurs as a result of another ES having per- formed the Query Configuration function described in clause 7.5.
放送サブネットワークに取り付けられたEnd SystemがNSAPsの1つまで記述されたNPDUを受けるとき、Configuration Response機能は実行されます、SN_UNITDATA.IndicationからのAddressがグループアドレス「すべての終わりのシステムNetowrk実体」に設定するSN_Destination_で。 これが別のES有の結果、起こる、-、7.5番目の節で説明されたQuery Configuration機能を形成します。
The End System constructs an ESH PDU identical in content to the ESH PDU constructed by the Report Configuration function (see clause 7.2.1) for the NSAP to which the received NPDU was addressed.It then transmits the ESH PDU to the source of the original NPDU by issuing an SN_UNITDATA.Request with the SN_Destination_Address set to the value of the SN_Source_Address received in the SN_UNITDATA.Indication with the original NPDU.
End Systemが内容がReport Configuration機能によって組み立てられたESH PDUと同じESH PDUを組み立てる、(節を見てください、7.2、.1、)、その時容認されたNPDUがaddressed.ItであったNSAPがAddressがAddressがオリジナルのNPDUと共にSN_UNITDATA.Indicationで受けたSN_Source_の値に設定するSN_Destination_でSN_UNITDATA.Requestを発行することによってオリジナルのNPDUの源にESH PDUを伝えるので。
ISO N4053 [Page 21] RFC 995 December 1986
ISO N4053[21ページ]RFC995 1986年12月
7.7 Request Redirect Function
7.7 要求の再直接の機能
The Request Redirect Function is present only in Intermediate Systems and is closely coupled with the Routing and Relaying Functions of In- termediate Systems. The Request Redirect Function is coupled with the "Route PDU Function" described in clause 6.5 of ISO 8473. The Request Redirect Function is performed after the Route PDU function has cal- culated the next hop of the Data PDU's path.
Request Redirect FunctionはIntermediate Systemsだけに存在していて、密接にIn- termediate Systemsのルート設定とRelaying Functionsに結びつけられます。Request Redirect FunctionはISO8473の6.5番目の節で説明された「ルートPDU機能」に結びつけられます。 Request Redirect Functionは機能が持っているRoute PDUの後に実行されます。calはData PDUの経路の次のホップをculatedしました。
When an NPDU is to be forwarded by a Intermediate System, the Request Redirect Function first examines the SN_Source_Address associated with the SN_UNITDATA.Indication which received the SNSDU (containing this NPDU). If the SN_Source_Address is not from an End System on the local subnetwork (determined by examining the Configuration informa- tion obtained through the Record Configuration Function), then this function does no further processing of the NPDU.
NPDUがIntermediate Systemによって進められることになっているとき、Request Redirect Functionは最初に、AddressがSNSDUを受けたSN_UNITDATA.Indicationに関連づけたSN_Source_を調べます(このNPDUを含んでいて)。 SN_Source_Addressが地方のサブネットワーク(Record Configuration Functionを通して入手されたConfiguration informa- tionを調べることによって断固とした)の上のEnd Systemから来ていないなら、この機能はこれ以上NPDUの処理をしません。
If the NPDU was received directly from an ES the output of the ISs Routing and Relaying function for this NPDU is examined. This output will contain, among other things, the following pieces of informa- tion:
直接ESからNPDUを受け取ったなら、このNPDUのためのISsルート設定とRelaying機能の出力を調べます。 この出力は特にinforma- tionの以下の断片を含むでしょう:
1. a local identifier for the subnetwork over which to forward the NPDU,
plus either
1. NPDU、およびどちらかを送るサブネットワークのためのローカルの識別子
2. the Network entity title and subnetwork address of the IS to which to
forward the NPDU, or
または2. Network実体タイトルとサブネットワークアドレス、NPDUを送る。
3. the subnetwork address of the destination End System.
3. 目的地End Systemのサブネットワークアドレス。
The Request Redirect function must now determine if the source ES could have sent the NPDU directly to the Network entity the Inter- mediate System is about to forward the PDU to. If any of the follow- ing conditions hold, the source ESshould be informed of the "better" path (by sending an RD PDU to the originating ES):
Request Redirect機能は、現在、ソースESが直接Interの仲介のSystemがPDUを送ろうとしているNetwork実体にNPDUを送ったかもしれないかどうか決定しなければなりません。 尾行のどれかがingされるなら、状態は成立します、ソースESshould。「より良い」経路(由来しているESにRD PDUを送るのによる)では、知識があってください:
1. The next hop is to the destination system, and the destination is
directly reachable (at subnetwork address BSNPA) on the source ESs
subnetwork, or
1. または目的地システムには次のホップがあって、目的地がソースESsサブネットワークで直接届いている、(サブネットワークアドレスBSNPAの)。
2. The next hop is to a Intermediate System which is connected to the
same subnetwork as the ES.
2. ESと同じサブネットワークに接続されるIntermediate Systemには次のホップがあります。
If the better path exists, the IS first completes normal processing of the received NPDU and forwards it.It then constructs a Redirect PDU (RD PDU) containing the Destination Address of the original NPDU, the subnetwork address of the better next hop (BSNPA), the Network Entity Title of the IS to which the ES is being redirected (unless the redirect is to the destination ES), a Holding Time (HT), QoS Maintenance, Priority, and Security options that were present in the Data NPDU (these are simply copied from the Data PDU). The HT is set
より良い経路が存在しているなら進める、1番目が容認されたNPDUの正常処理を終了するということであり、それを進めます; 次に、オリジナルのNPDUのDestination Addressを含んでいて、それはRedirect PDU(RD PDU)を組み立てます、より良い次のアドレスが(BSNPA)、Network Entity Titleを飛び越すサブネットワーク、Data NPDU(これらはData PDUから単にコピーされる)に存在しているESがどれであるかに向け直される(目的地ESには再直接がない場合)、a Holding Time(HT)、QoS Maintenance、Priority、およびSecurityオプションはそうです。 HTは用意ができています。
ISO N4053 [Page 22] RFC 995 December 1986
ISO N4053[22ページ]RFC995 1986年12月
to the value of the local Redirect Timer (RT). See Annex A for a dis- cussion of how to choose the value of RT. If there are insufficient resources to both forward the original NPDU and to generate and send an RD PDU, the original NPDU must be given preference. The Inter- mediate System (assuming it has sufficient resources) then sends the RD PDU to the source End System using the SN_Source_Address of the received NPDU as the SN_Destination_Address for the SN_UNITDATA.- Reqeust.
地方のRedirect Timer(RT)の値に。 どうRTの値を選ぶかに関する不-cussionに関してAnnex Aを見てください。 RD PDUをオリジナルのNPDUを進めて、発生して、送るために不十分なリソースがあれば、オリジナルのNPDUに優先を与えなければなりません。 そしてInterの仲介のSystem(それには十分なリソースがあると仮定する)は、SN_UNITDATA.- ReqeustにSN_Destination_Addressとして容認されたNPDUについてSN_Source_Addressを使用することでソースEnd SystemにRD PDUを送ります。
7.8 Record Redirect Function
7.8 記録的な再直接の機能
The Record Redirect Function is present only in End Systems. This function is invoked whenever an RD PDU is received. It extracts the redirect information and adds or replaces the corresponding redirec- tion information in the local Network entity's Routing Information base. The essential information is the redirection mapping from a Destination Address to a subnetwork address, along with the Priority, Security, and QoS Maintenance options and the Holding Time for which this mapping is to be considered valid. If the Redirect was to anoth- er Intermediate System, the Network Entity Title of the IS is record- ed as well.
Record Redirect FunctionはEnd Systemsだけに存在しています。RD PDUが受け取られているときはいつも、この機能は呼び出されます。 それは、地方のNetwork実体の経路情報ベースの中で対応するredirec- tion情報を再直接の情報を抜粋して、加えるか、または置き換えます。 不可欠の情報は、Priority、Security、およびQoS Maintenanceオプションに伴うDestination Addressからサブネットワークアドレスまでのリダイレクションマッピングと有効であると考えられるこのマッピングがことであるHolding Timeです。 anothえー、Intermediate System、Network Entity TitleにRedirectがいた、また、記録教育はそうです。
Note:
If insufficient memory is available to store new redirection information,
the RD PDU may be safely discarded since the original Intermediate
System will continue to forward PDUs on behalf of this Network entity
anyway.
以下に注意してください。 不十分な記憶が新しいリダイレクション情報を格納するために利用可能であるなら、オリジナルのIntermediate Systemが、とにかくこのNetwork実体を代表してPDUsを進め続けるので、RD PDUは安全に捨てられるかもしれません。
7.9 Refresh Redirect Function
7.9は再直接の機能をリフレッシュします。
The Refresh Redirect Function is present only in End Systems. This function is invoked whenever an NPDU is received by a destination ES. It is closely coupled with the function that processes received NPDUs at a destination Network Entity.This is the "PDU Decomposition" func- tion in ISO 8473. The purpose of this function is to increase the longevity of a redirection without allowing an incorrect route to persist indefinitely. The Source Address (SA), Priority, Security, and QoS options are extracted and compared to any Destination Address and QoS parameters being maintained in the Routing Information base (such information would have been stored by the Record Redirect Func- tion). If a corresponding entry is found, the previous hop of the PDU is obtained from the SN_Source_Address parameter of the SN_Unitdata.Indication primitive by which it was received. If this address matches the next hop address stored with the redirection in- formation, the remaining holding time for the redirection is reset to the original holding timer that was obtained from the RD PDU.
Refresh Redirect FunctionはEnd Systemsだけに存在しています。NPDUが目的地ESによって受け取られるときはいつも、この機能は呼び出されます。 密接に、目的地で容認されたNPDUsを処理する機能に結びつけられたNetwork Entity.ThisがISO8473の「PDU分解」func- tionであるということです。 この機能の目的は不正確なルートが無期限に持続するのを許容しないリダイレクションの寿命を増加させることです。 Source Address(SA)、Priority、Security、およびQoSオプションは、経路情報ベースの中で維持されるどんなDestination AddressとQoSパラメタにも、抜粋されて、たとえられます(そのような情報はRecord Redirect Func- tionによって格納されたでしょう)。 対応するエントリーを見つけるなら、それがどれであったかによる原始のSN_Unitdata.IndicationのSN_Source_Addressパラメタから受け取られていた状態でPDUの前のホップを得ます。 このアドレスが合っているなら、次のホップアドレスはリダイレクションでコネ構成を格納して、リダイレクションのための残っている把持時間はRD PDUから入手されたオリジナルの把持タイマにリセットされます。
Note:
The purpose of this function is to avoid timing out redirection entries
when the Network entity is receiving return traffic from the destination
via the same path over which it is currently sending traffic.This is
以下に注意してください。 この機能の目的はNetwork実体がそれが現在traffic.Thisを送る同じ経路を通して目的地からのリターン交通を受けているとき、出かけているリダイレクションエントリーを調節するのを避けるのがあるということです。
ISO N4053 [Page 23] RFC 995 December 1986
ISO N4053[23ページ]RFC995 1986年12月
particularly useful when the destination system is on the same subnetwork
as the source, since after one redirect no IS need be involved in
the ES-to-ES traffic.
ソースと同じサブネットワークの上に目的地システムがあると、特に役に立ちます、1つの再直接のノーが必要性になった後以来、ESからESへの交通にかかわってください。
This function must operate in a very conservative fashion however,
to prevent the formation of black holes. The remaining holding time
should be refreshed only under the exact conditions specified above.
For a discussion of the issues surrounding the refresh of redirection
information, see Annex 10.
しかしながら、この機能は、ブラックホールの構成を防ぐために非常に保守的なやり方で作動しなければなりません。 残っている把持時間は上で指定された正確な条件だけのもとでリフレッシュされるべきです。 問題周辺のa議論、リダイレクション情報をリフレッシュしてください、そして、Annex10を見てください。
7.10 Flush Old Redirect Function
7.10 豊富な古い再直接の機能
The Flush Old Redirect Function is executed to remove Configuration entries in the routing information base whose Holding Timer has ex- pired. When the Holding Time for an ES or IS expires, this function removes the corresponding entry from the routing information base of the local Network Entity.
Flush Old Redirect Functionは、Holding Timerが元の連れ合いをpiredさせるルーティング情報ベースの中でConfigurationエントリーを取り除くために実行されます。 ESのためのHolding Timeである、存在、期限が切れる、この機能は地方のNetwork Entityのルーティング情報ベースから対応するエントリーを取り除きます。
7.11 PDU Header Error Detection
7.11 PDUヘッダー誤り検出
The PDU Header Error Detection function protects against failure of Intermediate or End System Network entities due to the processing of erroneous information in the PDU header.The function is realized by a checksum computed on the entire PDU header. The checksum is verified at each point at which the PDU is processed. If the checksum calcula- tion fails, the PDU must be discarded.
PDU Header Error Detection機能がIntermediateの失敗から守るか、またはEnd System Network実体支払われるべきものは全体のPDUヘッダーの上に計算されたチェックサムによってPDU header.The機能における、間違った情報の処理に実感されます。 チェックサムはPDUが処理される各ポイントで確かめられます。 チェックサムcalcula- tionが失敗するなら、PDUを捨てなければなりません。
The use of the Header Error Detection function is optional and is selected by the originating Network Entity. If the function is not used, the checksum field of the PDU header is set to zero.
Header Error Detection機能の使用は、任意であり、由来しているNetwork Entityによって選択されます。 機能が使用されていないなら、PDUヘッダーのチェックサム分野はゼロに設定されます。
If the function is selected by the originating Network Entity, the value of the checksum field causes the following formulf to be satis- fied:
機能が由来しているNetwork Entityによって選択されるなら、チェックサム分野の値は、以下のformulfがsatis- fiedであることを引き起こします:
(The Sum from i=1 to L of a(i)) (mod 255) = 0
(i=1からa(i))(モッズ風の255)=0のLまでのSum
(The Sum from i=1 to L of (L - i + 1) * a(i)) (mod 255) = 0
(i=1から(L--i+1)*a(i))(モッズ風の255)=0のLまでのSum
where L = the number of octets in the PDU header, and a(i) = the value of the octet at position i. The first octet in the PDU header is considered to occupy position i = 0.
位置のiの八重奏のLがどこでPDUヘッダーの八重奏の数と等しいか、そして、a(i)=値。 PDUヘッダーにおける最初の八重奏が位置のi=0を占領すると考えられます。
When the function is in use, neither octet of the checksum field may be set to zero.
機能が使用中であるときに、チェックサム分野のどちらの八重奏もゼロに設定されないかもしれません。
ISO N4053 [Page 24] RFC 995 December 1986
ISO N4053[24ページ]RFC995 1986年12月
7.12 Classification of Functions
7.12 機能の分類
Implementations do not have to support all of the functions described in clause 7. Functions are divided into four categories:
実現は7番目の節で説明された機能のすべてを支持する必要はありません。 機能は4つのカテゴリに分割されます:
Type A: These functions must be supported in all cases.
A:をタイプしてください。 すべての場合でこれらの機能をサポートしなければなりません。
Type B: These functions must be supported by Systems which implement
the Configuration Information.
タイプB: Configuration情報を実行するSystemsはこれらの機能をサポートしなければなりません。
Type C: These functions must be supported by Systems which implement
the Redirect Information.
タイプC: Redirect情報を実行するSystemsはこれらの機能をサポートしなければなりません。
Type D: These functions are optional.
タイプD: これらの機能は任意です。
If a PDU is received which invokes an optional function that is not implemented, that PDU is discarded.
PDUが受け取られているなら、(実行されない任意の機能を呼び出します)そのPDUは捨てられます。
Table 3 shows how the functions are divided into these four categories, and to which type of system (ES, IS, or both) they apply.
テーブル3が機能がどうこれらの4つのカテゴリに分割されるかを示していて、どのタイプのシステムにそうするか、(ES、両方) 彼らは適用します。
______________________________________________________________
| Function | Category | System Type |
|_______________________________|____________|_______________|
| Report Configuration | B | ES,IS |
| Record Configuration | B | ES,IS |
| Configuration Response | A | ES |
| Flush Old Configuration | B | ES,IS |
| Request Redirect | C | IS |
| Query Configuration | B | ES |
| Record Redirect | C | ES |
| Refresh Redirect | D | ES |
| Flush Old Redirect | C | ES |
| PDU Header Error Detection | A | ES,IS |
|_______________________________|____________|_______________|
______________________________________________________________ | 機能| カテゴリ| システムタイプ| |_______________________________|____________|_______________| | レポート構成| B| ES、存在| | 構成を記録してください。| B| ES、存在| | 構成応答| A| ES| | 豊富な古い構成| B| ES、存在| | 要求再直接です。| C| あります。| | 質問構成| B| ES| | 再直接で、記録してください。| C| ES| | 再直接で、リフレッシュしてください。| D| ES| | 再直接で老人を洗い流してください。| C| ES| | PDUヘッダー誤り検出| A| ES、存在| |_______________________________|____________|_______________|
Table 3: Categories of Protocol Functions
テーブル3: プロトコル機能のカテゴリ
8 Structure and Encoding of PDUs
8 PDUsの構造とコード化
Note:
The encoding of the PDUs for this protocol is compatible with that
used in ISO 8473.
以下に注意してください。 このプロトコルのためのPDUsのコード化はISO8473で使用されるそれと互換性があります。
Temporary Note:
The method employed for describing the encoding of PDUs is provisional.
Member bodies are requested to comment on whether another
method (such as ASN.1 with an appropriate concrete syntax) would
be preferable.
一時的な注意: PDUsのコード化について説明するのに使われた方法は暫定的です。 別の方法(適切な具象構文があるASN.1などの)が望ましいだろうかどうかに関してメンバーボディーがコメントするよう要求されています。
ISO N4053 [Page 25] RFC 995 December 1986
ISO N4053[25ページ]RFC995 1986年12月
8.1 Structure
8.1 構造
All Protocol Data Units shall contain an integral number of octets.The octets in a PDU are numbered starting from one (1) and in- creasing in the order in which they are put into an SNSDU. The bits in an octet are numbered from one (1) to eight (8), where bit one (1) is the low-order bit. When consecutive octets are used to represent a binary number, the lower octet number has the most significant value.
それらがSNSDUに入れられるオーダーでしわになりながら1つ(1)とコネから始めて、すべてのプロトコルData Unitsが付番されたPDUに整数のoctets.The八重奏を含むものとします。 八重奏におけるビットは1つ(1)〜8(8)まで付番されます。そこでは、噛み付いているもの(1)は下位のビットです。 連続した八重奏が2進の数を表すのに使用されるとき、下側の八重奏番号には、最も重要な値があります。
Any subnetwork supporting this protocol is required to state in its specification the way octets are transferred, using the terms "most significant bit" and "least significant bit". The PDUs of this proto- col are defined using the terms "most significant bit" and "least significant bit".
このプロトコルをサポートするサブネットワークが八重奏がわたっている方法、「最上位ビット」という用語を使用して、および「最下位ビット」という仕様による状態に必要です。 このprotoあん部のPDUsは、用語「最上位ビット」と「最下位ビット」を使用することで定義されます。
Note:
When the encoding of a PDU is represented using a diagram in this
section, the following representation is used:
以下に注意してください。 PDUのコード化がこのセクションのダイヤグラムを使用することで表されるとき、以下の表現は使用されています:
a) octets are shown with the lowest numbered octet to the left,
higher number octets being further to the right;
b) within an octet, bits are shown with bit eight (8) to the left and
bit one (1) to the right.
a) 八重奏は右に加えている左の、そして、より高い数の八重奏への最も低い番号付の八重奏で示されます。 八重奏の中のb)、ビットはビットeight(8)で右への左の、そして、噛み付いているもの(1)に見せられます。
PDUs shall contain, in the following order:
PDUsは以下のオーダーに以下を含むものとします。
1. the fixed part;
1. 固定部分。
2. the Network address part;
2. Networkアドレス部。
3. the Subnetwork address part, if present; and
3. Subnetworkアドレス部存在しているなら そして
4. the Options part, if present.
4. 存在しているなら、Optionsは離れています。
8.2 Fixed Part
8.2 固定部分
8.2.1 General
8.2.1 一般
The fixed part contains frequently occurring parameters including the type code (ESH, ISH, or RD) of the protocol data unit.The length and the structure of the fixed part are defined by the PDU code.
固定部分はプロトコルdata unit.Theの長さのタイプコード(ESH、ISH、またはRD)を含む頻繁に起こっているパラメタを含んでいます、そして、固定部分の構造はPDUコードによって定義されます。
ISO N4053 [Page 26] RFC 995 December 1986
ISO N4053[26ページ]RFC995 1986年12月
The fixed part has the following format:
固定部分には、以下の形式があります:
Octet
________________________________________
| Network Layer Protocol Identifier | 1
|______________________________________|
| Length Indicator | 2
|______________________________________|
| Version/Protocol Id Extension | 3
|______________________________________|
| reserved (must be zero) | 4
|______________________________________|
| 0 |0 |0 | Type | 5
|___|__|__|____________________________|
| Holding Time | 6,7
|______________________________________|
| Checksum | 8,9
|______________________________________|
八重奏________________________________________ | ネットワーク層プロトコル識別子| 1 |______________________________________| | 長さのインディケータ| 2 |______________________________________| | バージョン/プロトコルイド拡大| 3 |______________________________________| | 予約されます(ゼロでなければなりません)。| 4 |______________________________________| | 0 |0 |0 | タイプ| 5 |___|__|__|____________________________| | 把持時間| 6,7 |______________________________________| | チェックサム| 8,9 |______________________________________|
Figure 1: PDU Header -- Fixed Part
図1: PDUヘッダー--固定部分
8.2.2 Network Layer Protocol Identifier
8.2.2 ネットワーク層プロトコル識別子
The value of this field shall be 1000 0010.
この分野の値は1000 0010になるでしょう。
Temporary Note:
The value 1000 0010 is provisional, pending resolution of the NLPID
issue in SC6.
一時的な注意: 値1000 0010はSC6でのNLPID問題の暫定的で、未定の解決です。
This field identifies this Network Layer Protocol as ISO SC6/N4053, End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473.
この分野は、このNetwork LayerプロトコルがISO SC6/N4053(ISO8473に関連した使用のためのIntermediate Systemルート設定ExchangeプロトコルへのEnd System)であると認識します。
8.2.3 Length Indicator
8.2.3 長さのインディケータ
The length is indicated by a binary number, with a maximum value of 254 (1111 1110).The length indicated is the length of the entire PDU (which consists entirely of header, since this protocol does not car- ry user data) in octets, as described in clause 8.1. The value 255 (1111 1111) is reserved for possible future extensions.
長さは2進の数によって示されて、254(1111 1110).Theの長さの最大値で示されているのは、八重奏で、全体のPDU(このプロトコルがどんな車のryにも利用者データをしないので、ヘッダーから完全に成る)の長さです、8.1番目の節で説明されるように。 値255の(1111 1111)は可能な今後の拡大のために予約されます。
8.2.4 Version/Protocol Identifier Extension
8.2.4 バージョン/プロトコル識別子拡張子
The value of this field is binary 0000 0001. This identifies a stan- dard version of ISO xxxx, End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473.
この分野の値は2進の0000 0001です。 これはISO xxxx(ISO8473に関連した使用のためのIntermediate Systemルート設定ExchangeプロトコルへのEnd System)のstan- dardバージョンを特定します。
ISO N4053 [Page 27] RFC 995 December 1986
ISO N4053[27ページ]RFC995 1986年12月
8.2.5 Type Code
8.2.5 コードをタイプしてください。
The Type code field identifies the type of the protocol data unit. Allowed values are given in table 4.
Typeコード分野はプロトコルデータ単位のタイプを特定します。 テーブル4で許容値を与えます。
_____________________________________________________ | | Bits 5 4 3 2 1 | |____________|______________________________________| |____________|______________________________________| |ESH PDU | 0 0 0 1 0 | |____________|______________________________________| |ISH PDU | 0 0 1 0 0 | |____________|______________________________________| |RD PDU | 0 0 1 1 0 | |____________|______________________________________|
_____________________________________________________ | | ビット5 4 3 2 1| |____________|______________________________________| |____________|______________________________________| |ESH PDU| 0 0 0 1 0 | |____________|______________________________________| |ISH PDU| 0 0 1 0 0 | |____________|______________________________________| |第PDU| 0 0 1 1 0 | |____________|______________________________________|
Table 4: Valid PDU Types
テーブル4: 有効なPDUはタイプします。
All other PDU type values are reserved.
他のすべてのPDUタイプ値が予約されています。
8.2.6 Holding Time
8.2.6把持時間
The Holding Time field specifies for how long the receiving Network entity should retain the configuration/routing information contained in this PDU. The receiving Network entity should discard any infor- mation obtained from this PDU from its internal state when the hold- ing time expires. The Holding time field is encoded as an integral number of micro-fortnights.
Holding Time分野は受信Network実体がどれくらい長い間このPDUに含まれた構成/ルーティング情報を保有するべきであるかに指定します。 受信Network実体は保持ing時間が期限が切れるときこのPDUから内部の状態から入手されたどんなinfor- mationも捨てるべきです。 Holding時間分野は整数のマイクロ2週間としてコード化されます。
8.2.7 PDU Checksum
8.2.7 PDUチェックサム
The checksum is computed on the entire PDU header. A checksum value of zero is reserved to indicate that the checksum is to be ignored. The operation of the PDU Header Error Detection function (Clause 7.11) ensures that the value zero does not represent a valid check- sum. A non-zero value indicates that the checksum must be processed. If the checksum calculation fails, the PDU must be discarded.
チェックサムは全体のPDUヘッダーの上に計算されます。 ゼロのチェックサム値は、チェックサムが無視されることであることを示すために予約されます。 PDU Header Error Detection機能(第7.11節)の操作は、値ゼロが有効なチェック合計を表さないのを確実にします。 非ゼロ値は、チェックサムを処理しなければならないのを示します。 チェックサム計算が失敗するなら、PDUを捨てなければなりません。
8.3 Network Address Part
8.3 ネットワーク・アドレス一部
8.3.1 General
8.3.1 一般
Address parameters are distinguished by their location. The different PDU types carry different address parameters however.The ESH PDU car- ries a Source NSAP address (SA); the ISH PDU carries a Intermediate System Network entity Title (NET); and the RD PDU carries a Destina- tion NSAP address (DA), and possibly a Network Entity Title (NET).
アドレスパラメタはそれらの位置によって区別されます。 異なったPDUタイプは異なったアドレスパラメタhowever.The ESH PDU車Source NSAPが扱うries(SA)を運びます。 ISH PDUはIntermediate System Network実体Title(NET)を運びます。 そして、RD PDUはDestina- tion NSAPアドレス(DA)、およびことによるとNetwork Entity Title(NET)を運びます。
8.3.2 NPAI (Network Protocol Address Information) Encoding
8.3.2 NPAI(ネットワーク・プロトコルアドレス情報)コード化
The Destination and Source Addresses are Network Service Access Point
DestinationとSource AddressesはNetwork Service Access Pointです。
ISO N4053 [Page 28] RFC 995 December 1986
ISO N4053[28ページ]RFC995 1986年12月
addresses as defined in ISO 8348/AD2, Addendum to the Network Service Definition Covering Network Layer addressing.The Network Entity Title address parameter is defined in clause 4.5. The Destination Address, Source Address, and Network Entity Title are encoded as NPAI using the binary syntax defined in clause 8.3.1 of ISO 8348/AD2.
ISO8348/AD2で定義されるアドレス、Network Service Definition Covering Network Layer addressing.The Network Entity TitleアドレスパラメタへのAddendumは4.5番目の節で定義されます。 Destination Address、Source Address、およびNetwork Entity TitleがNPAIとして節で定義された2進の構文を使用することでコード化される、8.3、.1、ISO8348/AD2について。
The address information is of variable length. Each address parameter is encoded as follows:
アドレス情報は可変長のものです。 それぞれのアドレスパラメタは以下の通りコード化されます:
_______________________________________________
| Octet | Address parameter Length Indicator |
| n | (e.g., 'm') |
|________|____________________________________|
| Octets | |
| n + 1 | Address Parameter Value |
| thru | |
| n + m | |
|________|____________________________________|
_______________________________________________ | 八重奏| アドレスパラメタLength Indicator| | n| '、(例えば、'、) | |________|____________________________________| | 八重奏| | | n+1| アドレスパラメタ価値| | 徹底的に| | | n+m| | |________|____________________________________|
Figure 2: Address Parameters
8.3.3 Source Address Parameter for ESH PDU
図2: ESH PDUのためのアドレスパラメタ8.3.3ソースアドレスパラメタ
The Source Address is the NSAP address of an NSAP served by the Net- work entity sending the ESH PDU. It is encoded in the ESH PDU as fol- lows:
Source AddressはESH PDUを送るネット仕事実体によって役立たれるNSAPのNSAPアドレスです。 それはfol安値としてESH PDUでコード化されます:
Octet
________________________________________
|Source Address Length Indicator (SAL) | 10
|______________________________________|
| | 11
: Source Address (SA) :
| | m - 1
|______________________________________|
八重奏________________________________________ |ソースアドレス長さのインディケータ(サラソウジュ)| 10 |______________________________________| | | 11 : ソースアドレス(SA): | | m--1|______________________________________|
Figure 3: ESH PDU - Network Address Part
図3: ESH PDU--ネットワーク・アドレス一部
8.3.4 Network Entity Title Parameter for ISH PDU
8.3.4 ISH PDUのためのネットワーク実体タイトルパラメタ
The Network entity Title parameter is the Network Entity Title of the Intermediate System sending the ISH PDU. It is encoded in the ISH PDU as follows:
Network実体TitleパラメタはISH PDUを送るIntermediate SystemのNetwork Entity Titleです。 それは以下のISH PDUでコード化されます:
ISO N4053 [Page 29] RFC 995 December 1986
ISO N4053[29ページ]RFC995 1986年12月
Octet
_______________________________________________
|Network Entity Title Length Indicator (NETL) | 10
|_____________________________________________|
| | 11
: Network Entity Title (NET) :
| | m - 1
|_____________________________________________|
八重奏_______________________________________________ |ネットワーク実体タイトル長さのインディケータ(NETL)| 10 |_____________________________________________| | | 11 : 実体タイトル(ネットの)をネットワークでつないでください: | | m--1|_____________________________________________|
Figure 4: ISH PDU - Network Address Part
図4: ISH PDU--ネットワーク・アドレス一部
8.3.5 Destination Address Parameter for RD PDU
8.3.5 第PDUのための目的地アドレスパラメタ
The Destination Address is the NSAP address of a destination associ- ated with some NPDU being forwarded by the Intermediate System send- ing the RD PDU. It is encoded in the RD PDU as follows:
Destination AddressによるいくらかのNPDUがIntermediate Systemによって進められている目的地associ- atedのNSAPアドレスがRD PDUをingに送るということです。 それは以下のRD PDUでコード化されます:
Octet
_____________________________________________
|Destination Address Length Indicator (DAL) | 10
|___________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|___________________________________________|
八重奏_____________________________________________ |目的地アドレス長さのインディケータ(DAL)| 10 |___________________________________________| | | 11 : 送付先アドレス(DA): | | m--1|___________________________________________|
Figure 5: RD PDU - Network Address Part
図5: PDU--アドレスの一部を第ネットワークでつないでください。
8.4 Subnetwork Address Part
8.4 サブネットワークアドレス部
The Subnetwork Address Part is present only in RD PDUs.It is used to indicate the subnetwork address of another Network entity on the same subnetwork as the End System (and Intermediate System) which may be a better path to the destination specified in the Network Address Part. The Subnetwork Address parameter is encoded in the same manner as the Network Address parameters.
Subnetwork Address PartによるRD PDUs.Itだけでのプレゼントが、より良い経路であるかもしれないEnd System(そして、Intermediate System)と同じサブネットワークの上に別のNetwork実体のサブネットワークアドレスをNetwork Address Partで指定された目的地に示すのに使用されるということです。 Subnetwork AddressパラメタはNetwork Addressパラメタと同じ方法でコード化されます。
ISO N4053 [Page 30] RFC 995 December 1986
ISO N4053[30ページ]RFC995 1986年12月
8.4.1 Subnetwork Address Parameter for RD PDU
8.4.1 第PDUのためのサブネットワークアドレスパラメタ
The Subnetwork Address Parameter is encoded in the RD PDU as fol-
lows:
Subnetwork Address Parameterはfol安値としてRD PDUでコード化されます:
Octet
_______________________________________________
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (BSNPA) :
| | n - 1
|_____________________________________________|
八重奏_______________________________________________ |サブネットワークアドレス長さのインディケータ(BSNPAL)| m|_____________________________________________| | | m+1: サブネットワークアドレス(BSNPA): | | n--1|_____________________________________________|
Figure 6: ESH PDU - Address Part
図6: ESH PDU--アドレス部
8.5 Options Part
8.5のオプションが離れています。
8.5.1 General
8.5.1 一般
The options part is used to convey optional parameters. The options
part
of the PDU header is illustrated below:
オプション一部が、任意のパラメタを伝えるのに使用されます。 PDUヘッダーのオプション一部が以下で例証されます:
Octet
___________________________________________________
| | p
: Options :
| | q
|__________________________________________________|
八重奏___________________________________________________ | | p: オプション: | | q|__________________________________________________|
Figure 7: All PDUs - Options Part
図7: すべてのPDUs--オプション一部
If the options part is present, it may contain one or more parame- ters. The number of parameters that may be contained in the options part is constrained by the length of the options part, which is determined by the following formula:
オプション一部が存在しているなら、それは1parame- tersを含むかもしれません。 オプション一部に保管されるかもしれないパラメタの数は以下の公式によって測定されるオプション一部の長さによって抑制されます:
PDU Header Length - (length of fixed part + length of address
part + length of segmentation part),
PDU Header Length--(固定部分+長さの分割部分のアドレス部+長さの長さ)
and by the length of the individual optional parameters.
そして、個々の任意のパラメタの長さに従って。
Parameters defined in the options part may appear in any order. Du- plication of options is not permitted.Receipt of a PDU with an option duplicated must be treated as a protocol error.
オプション一部で定義されたパラメタは順不同に現れるかもしれません。 オプションのDuひだ形成によるオプションがコピーされているPDUのpermitted.Receiptをプロトコル誤りとして扱わなければならないということではありません。
ISO N4053 [Page 31] RFC 995 December 1986
ISO N4053[31ページ]RFC995 1986年12月
The encoding of parameters contained within the options part of the PDU header is illustrated below in figure 8.
PDUヘッダーのオプション一部の中に含まれたパラメタのコード化はエイト環で以下で例証されます。
Octets
_________________________________
| n | Parameter Code |
|____________|__________________|
| n + 1 | Parameter Length |
|____________|__________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|__________________|
八重奏_________________________________ | n| パラメタコード| |____________|__________________| | n+1| パラメタの長さ| |____________|__________________| | n+2| | | to| パラメタ値| | n+m+1| | |____________|__________________|
Figure 8: Encoding of Option Parameters
エイト環: オプションパラメタのコード化
The parameter code field is coded in binary and, without extensions, provides a maximum of 255 different parameters. No parameter codes use bits 8 and 7 with the value 00, so the actual maximum number of parameters is lower. A parameter code of 255 (binary 1111 1111) is reserved for possible future extensions.
パラメタコード分野は、バイナリーでコード化されて、拡大なしで最大255の異なったパラメタを提供します。 どんなパラメタコードも値00に従ったビット8と7を使用しないので、実際の最大数のパラメタは低いです。 255(2進の1111 1111)のパラメタコードは可能な今後の拡大のために予約されます。
The parameter length field indicates the length, in octets, of the parameter value field.The length is indicated by a positive binary number, m, with a theoretical maximum value of 254. the practical maximum value of m is lower. For example, in the case of a single parameter contained within the options part, two octets are required for the parameter code and the parameter length indicators. Thus, the value of m is limited to:
パラメタ長さの分野は長さを示します、八重奏でパラメタ価値では、field.Theの長さは正の2進の数によって示されます、m、254の理論上の最大値で。mの実用的な最大値は低いです。 例えば、オプション一部の中に保管されていたただ一つのパラメタの場合では、2つの八重奏がパラメタコードとパラメタ長さのインディケータに必要です。 したがって、mの値は以下のことのために制限されます。
m = 252-(length of fixed part +length of address part
+length of segmentation part )
m=252(固定部分+長さの分割部分のアドレス部+長さの長さ)
For each succeeding parameter the maximum value of m decreases. The parameter value field contains the value of the parameter identified in the parameter code field.
続く各パラメタに関しては、mの最大値は減少します。 パラメタ値の分野はパラメタコード分野で特定されたパラメタの値を含んでいます。
The following parameters are permitted in the options part.
以下のパラメタはオプション一部で受入れられます。
8.5.2 Security
8.5.2 セキュリティ
The Security parameter conveys information about the security re- quested in the Data PDU that caused the containing RD PDU to be gen- erated. This parameter has the same encoding and semantics as the Security parameter in ISO 8473.
Securityパラメタはセキュリティに関して含んでいるRD PDUがeratedされていた状態で情報を得ることであることを引き起こしたData PDUで再探索していた状態で情報を伝達します。 このパラメタには、ISO8473のSecurityパラメタとして同じコード化と意味論があります。
Parameter Code: 1100 0101
パラメタコード: 1100 0101
Parameter Length: variable
パラメタの長さ: 変数
Parameter Value: See Section 7.5.3 of ISO 8473
パラメタ値: .3セクション7.5ISO8473を見てください。
ISO N4053 [Page 32] RFC 995 December 1986
ISO N4053[32ページ]RFC995 1986年12月
8.5.3 Quality of Service Maintenance
8.5.3 サービスの質メインテナンス
The Quality of Service parameter conveys information about the quali- ty of service requested in the Data PDU that caused the containing RD PDU to be generated.
ServiceパラメタのQualityは含んでいるRD PDUを生成させたData PDUで要求されたサービスのquali- tyの周りで情報を伝達します。
This parameter has the same encoding and semantics as the QoS Mainte- nance parameter in ISO 8473.
このパラメタには、ISO8473のQoS Mainte- nanceパラメタとして同じコード化と意味論があります。
Parameter Code: 1100 0011
パラメタコード: 1100 0011
Parameter Length: variable
パラメタの長さ: 変数
Parameter Value: See Section 7.5.6 of ISO 8473
パラメタ値: .6セクション7.5ISO8473を見てください。
8.5.4 Priority
8.5.4 優先権
The Priority parameter conveys information about the priority re- quested in the Data PDU that caused the containing RD PDU to be gen- erated.
Priorityパラメタは優先権に関して含んでいるRD PDUがeratedされていた状態で情報を得ることであることを引き起こしたData PDUで再探索していた状態で情報を伝達します。
This parameter has the same encoding and semantics as the Priority parameter in ISO 8473.
このパラメタには、ISO8473のPriorityパラメタとして同じコード化と意味論があります。
Parameter Code: 1100 1101
パラメタコード: 1100 1101
Parameter Length: one octet
パラメタの長さ: 1つの八重奏
Parameter Value: See Section 7.5.7 of ISO 8473
パラメタ値: .7セクション7.5ISO8473を見てください。
ISO N4053 [Page 33] RFC 995 December 1986
ISO N4053[33ページ]RFC995 1986年12月
8.6 End System Hello (ESH) PDU
8.6 こんにちは、エンドシステム(ESH)PDU
8.6.1 Structure
8.6.1 構造
The ESH PDU has the following format:
ESH PDUには、以下の形式があります:
Octet
____________________________________________
| Network Layer Protocol Identifier | 1
|__________________________________________|
| Length Indicator | 2
|__________________________________________|
| Version/Protocol Id Extension | 3
|__________________________________________|
| reserved (must be zero) | 4
|__________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|_________________________________|
| Holding Time | 6,7
|__________________________________________|
| Checksum | 8,9
|__________________________________________|
| Source Address Length Indicator (SAL) | 10
|__________________________________________|
| | 11
: Source Address (SA) :
| | m - 1
|__________________________________________|
| | m
: Options :
| | p - 1
|__________________________________________|
八重奏____________________________________________ | ネットワーク層プロトコル識別子| 1 |__________________________________________| | 長さのインディケータ| 2 |__________________________________________| | バージョン/プロトコルイド拡大| 3 |__________________________________________| | 予約されます(ゼロでなければなりません)。| 4 |__________________________________________| |0 |0 |0 | タイプ| 5 |__|__|__|_________________________________| | 把持時間| 6,7 |__________________________________________| | チェックサム| 8,9 |__________________________________________| | ソースアドレス長さのインディケータ(サラソウジュ)| 10 |__________________________________________| | | 11 : ソースアドレス(SA): | | m--1|__________________________________________| | | m: オプション: | | p--1|__________________________________________|
Figure 9: ESH PDU Format
図9: ESH PDU形式
ISO N4053 [Page 34] RFC 995 December 1986
ISO N4053[34ページ]RFC995 1986年12月
8.7 Intermediate System Hello (ISH) PDU
8.7 こんにちは、中間システム(ISH)PDU
8.7.1 Structure
8.7.1 構造
The ISH PDU has the following format:
ISH PDUには、以下の形式があります:
Octet
_______________________________________________
| Network Layer Protocol Identifier | 1
|_____________________________________________|
| Length Indicator | 2
|_____________________________________________|
| Version/Protocol Id Extension | 3
|_____________________________________________|
| reserved (must be zero) | 4
|_____________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|____________________________________|
| Holding Time | 6,7
|_____________________________________________|
| Checksum | 8,9
|_____________________________________________|
|Network Entity Title Length Indicator (NETL) | 10
|_____________________________________________|
| | 11
: Network Entity Title (NET) :
| | m - 1
|_____________________________________________|
| | m
: Options :
| | p - 1
|_____________________________________________|
八重奏_______________________________________________ | ネットワーク層プロトコル識別子| 1 |_____________________________________________| | 長さのインディケータ| 2 |_____________________________________________| | バージョン/プロトコルイド拡大| 3 |_____________________________________________| | 予約されます(ゼロでなければなりません)。| 4 |_____________________________________________| |0 |0 |0 | タイプ| 5 |__|__|__|____________________________________| | 把持時間| 6,7 |_____________________________________________| | チェックサム| 8,9 |_____________________________________________| |ネットワーク実体タイトル長さのインディケータ(NETL)| 10 |_____________________________________________| | | 11 : 実体タイトル(ネットの)をネットワークでつないでください: | | m--1|_____________________________________________| | | m: オプション: | | p--1|_____________________________________________|
Figure 10: ISH PDU Format
図10: ISH PDU形式
ISO N4053 [Page 35] RFC 995 December 1986
ISO N4053[35ページ]RFC995 1986年12月
8.8 Redirect (RD) PDU
8.8 再直接の(RD) PDU
8.8.1 Structure
8.8.1 構造
The RD PDU has the following format:
RD PDUには、以下の形式があります:
Octet
______________________________________________
| Network Layer Protocol Identifier | 1
|_____________________________________________|
| Length Indicator | 2
|_____________________________________________|
| Version/Protocol Id Extension | 3
|_____________________________________________|
| reserved (must be zero) | 4
|_____________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|____________________________________|
| Holding Time | 6,7
|_____________________________________________|
| Checksum | 8,9
|_____________________________________________|
| Destination Address Length Indicator (DAL)| 10
|_____________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|_____________________________________________|
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (DBSNPA) :
| | n - 1
|_____________________________________________|
|Network Entity Title Length Indicator (NETL) | n
|_____________________________________________|
| | n + 1
: Network Entity Title (NET) :
| | p - 1
|_____________________________________________|
| | p
: Options :
| | q - 1
|_____________________________________________|
八重奏______________________________________________ | ネットワーク層プロトコル識別子| 1 |_____________________________________________| | 長さのインディケータ| 2 |_____________________________________________| | バージョン/プロトコルイド拡大| 3 |_____________________________________________| | 予約されます(ゼロでなければなりません)。| 4 |_____________________________________________| |0 |0 |0 | タイプ| 5 |__|__|__|____________________________________| | 把持時間| 6,7 |_____________________________________________| | チェックサム| 8,9 |_____________________________________________| | 目的地アドレス長さのインディケータ(DAL)| 10 |_____________________________________________| | | 11 : 送付先アドレス(DA): | | m--1|_____________________________________________| |サブネットワークアドレス長さのインディケータ(BSNPAL)| m|_____________________________________________| | | m+1: サブネットワークアドレス(DBSNPA): | | n--1|_____________________________________________| |ネットワーク実体タイトル長さのインディケータ(NETL)| n|_____________________________________________| | | n+1: 実体タイトル(ネットの)をネットワークでつないでください: | | p--1|_____________________________________________| | | p: オプション: | | q--1|_____________________________________________|
Figure 11: RD PDU Format when Redirect is to an IS
図11: RD PDU Format、いつまでRedirectがあるか。
ISO N4053 [Page 36] RFC 995 December 1986
ISO N4053[36ページ]RFC995 1986年12月
Octet
______________________________________________
| Network Layer Protocol Identifier | 1
|_____________________________________________|
| Length Indicator | 2
|_____________________________________________|
| Version/Protocol Id Extension | 3
|_____________________________________________|
| reserved (must be zero) | 4
|_____________________________________________|
|0 |0 |0 | Type | 5
|__|__|__|____________________________________|
| Holding Time | 6,7
|_____________________________________________|
| Checksum | 8,9
|_____________________________________________|
| Destination Address Length Indicator (DAL)| 10
|_____________________________________________|
| | 11
: Destination Address (DA) :
| | m - 1
|_____________________________________________|
|Subnetwork Address Length Indicator (BSNPAL) | m
|_____________________________________________|
| | m + 1
: Subnetwork Address (DBSNPA) :
| | n - 1
|_____________________________________________|
| NETL = 0 | n
|_____________________________________________|
| | n + 1
: Options :
| | p - 1
|_____________________________________________|
| Quality of Service | n + 1
|_____________________________________________|
八重奏______________________________________________ | ネットワーク層プロトコル識別子| 1 |_____________________________________________| | 長さのインディケータ| 2 |_____________________________________________| | バージョン/プロトコルイド拡大| 3 |_____________________________________________| | 予約されます(ゼロでなければなりません)。| 4 |_____________________________________________| |0 |0 |0 | タイプ| 5 |__|__|__|____________________________________| | 把持時間| 6,7 |_____________________________________________| | チェックサム| 8,9 |_____________________________________________| | 目的地アドレス長さのインディケータ(DAL)| 10 |_____________________________________________| | | 11 : 送付先アドレス(DA): | | m--1|_____________________________________________| |サブネットワークアドレス長さのインディケータ(BSNPAL)| m|_____________________________________________| | | m+1: サブネットワークアドレス(DBSNPA): | | n--1|_____________________________________________| | NETL=0| n|_____________________________________________| | | n+1: オプション: | | p--1|_____________________________________________| | サービスの質| n+1|_____________________________________________|
Figure 12: RD PDU Format when Redirect is to an ES
図12: Redirectであるときに、ESにはRD PDU Formatがあります。
9 Formal Description
9 形式的記述
{Maybe next pass...}
多分次のパス…
10 Conformance
10 順応
See Clause 6.2.
第6.2節を見てください。
ISO N4053 [Page 37] RFC 995 December 1986
ISO N4053[37ページ]RFC995 1986年12月
ANNEX A. SUPPORTING TECHNICAL MATERIAL
技工物を支えて、A.を付加してください。
A.1 Use of Timers
タイマのA.1使用
This protocol makes extensive use of timers to ensure the timeliness and accuracy of information disseminated using the Configuration and Route Redirection functions.This section discusses the rationale for using these timers and provides some background for how they operate.
このプロトコルは、ConfigurationとRoute Redirection functions.This部を使用する情報播種性ののタイムリーさであるのと精度がこれらのタイマを使用するために原理について議論して、それらがどう作動するかに何らかのバックグラウンドを提供するのを保証するためにタイマの大規模な使用をします。
Systems using this protocol learn about other systems exclusively by receiving PDUs sent by those systems. In a connectionless environ- ment, a system must periodically receive updated information to en- sure that the information it previously received is still correct. For example, if a system on a subnetwork becomes unavailable (either it has ceased operating, or its SNPA becomes inoperative) the only way another system can detect this fact is by the absence of transmissions from that system. If information were retained in the absence of new PDUs being received, configuration and/or routing in- formation would inevitably become incorrect. The Holding Timers specified by this protocol guarantee that old information will not be retained indefinitely.
このプロトコルを使用するシステムが、他のシステムに関して排他的にそれらのシステムによって送られたPDUsを受けることによって、学びます。aコネクションレスでは、mentを取り巻いてください、そして、システムは定期的に確実に、それが以前に受け取った情報がまだ正しいというアンへのアップデートされた情報を受け取らなければなりません。 例えば、サブネットワークの上のシステムが入手できなくなるなら(作動するのをやめたか、またはSNPAは効力がなくなります)、別のシステムがこの事実を検出できる唯一の方法はそのシステムからのトランスミッションについて欠如します。 情報が受け取られる新しいPDUsが不在のとき保有されるなら、構成、そして/または、構成を中に発送するのは必然的に不正確になるでしょうに。 旧情報が無期限に保有されないというこのプロトコル保証でHolding Timersは指定しました。
A useful way of thinking of the configuration and route redirection information is as a cache maintained by each system. The cache is periodically flushed to ensure that only up-to-date information is stored.Unlike most caches, however, the time to retain information is not a purely local matter. Rather, information is held for a period of time specified by the source of the information. Some examples will help clarify this operation.
各システムによって維持されたキャッシュとして構成とルートリダイレクション情報を考える役に立つ方法があります。 キャッシュは、しかしながら、stored.Unlikeがほとんどのキャッシュであり、情報を保有する時間が純粋にローカルの問題でないというその唯一の最新情報を確実にするために定期的に洗い流されます。 むしろ、情報はしばらく情報の源によって指定されるままにされます。 いくつかの例が、この操作をはっきりさせるのを助けるでしょう。
A.1.1 Example of Holding Time for Route Redirection
ルートリダイレクションのための把持時間のA.1.1の例
Route Redirection Information is obtained by an End System through the Request Redirect function (see clause 7.7).It is quite possible that a Intermediate System might redirect an End System to another IS which has recently become unavailable (this might happen if the IS- to-IS routing algorithm is still converging following a configuration change). If the Holding Timer were not present, or was set very long by the sending IS, an End System would have been redirected into a Black Hole from which none of its Data PDUs would ever emerge. The length of the Holding Timer on Redirects specifies, in essence, the length of time black holes are permitted to exist.
ルートRedirection情報がEnd Systemによって通じて得られて、Request Redirect機能(7.7番目の節を見る).ItがIntermediate Systemが別のものにEnd Systemを向け直すかもしれないのがかなり可能であるのが、どれが最近入手できなくなったかということであるということであるということである、(これが起こるかもしれない、存在、-、構成変更に続いて、アルゴリズムがまだ一点に集めているルーティング) 存在していなかったか、またはHolding Timerによる発信で設定まさしくその長さはそうです、End Systemということでした。Data PDUsのいずれも現れないBlack Holeに向け直されたでしょう。 Redirectsの上のHolding Timerの長さは指定します、本質で時間ブラックホールの長さが存在することが許可されています。
On the other hand, setting the Holding Timer on Route Redirects very short to minimize the effect of black holes has other undesirable consequences.First, for each PDU that causes a redirect, an addition- al PDU beside the original Data PDU must be composed and transmitted; this increases overhead. Second, each time a "working" redirect's Holding Timer expires, the redirected End System will revert to a poorer route for at least one PDU.
他方では、ブラックホールの効果を最小にするために非常に短いRoute RedirectsにHolding Timerをけしかけるのにおいて他の望ましくないconsequences.Firstがあります、再直接でaを引き起こす各PDUのためにオリジナルのData PDUの横の添加アルPDUを構成されて、伝えなければなりません。 これはオーバーヘッドを上げます。 2番目に、再直接で「働き」であるのによるHolding Timerである各回は期限が切れて、向け直されたEnd Systemは少なくとも1PDUのために、より貧しいルートに戻るでしょう。
ISO N4053 [Page 38] RFC 995 December 1986
ISO N4053[38ページ]RFC995 1986年12月
A.1.2 Example of Holding Timer for Configuration Information
設定情報のための把持タイマに関するA.1.2の例
A similar type of problem can occur with respect to Configuration in- formation. If the Holding Time of a ISH PDU (see clause 7.2.2) is set very long, and the only Intermediate System (which has been sending this Configuration Information) on the subnetwork becomes unavail- able, a subnetwork-wide black hole can form. During this time, End Systems on the subnetwork may not be able to communicate with each other because they presume that a Intermediate System is operating which will forward their Data PDUs to destination ESs on the local subnetwork and return RD PDUs.Once the Holding Time expires, the ESs will realize that no IS is available and will take their only recourse, which is to send their traffic directly on the local sub- network.
同様のタイプの問題は中にConfigurationに関して起こることができます。構成。 ISH PDUのHolding Timeである、(節を見てください、7.2、.2、)、セットは非常に長く、サブネットワークの上の唯一のIntermediate System(このConfiguration情報を送った)がunavailにできるようになって、サブネットワーク全体のブラックホールは形成できます。 彼らが、Intermediate Systemが地方のサブネットワークの上で彼らのData PDUsを目的地ESsに送る操作とRD PDUs.Once Holding Timeが吐き出すリターンであると推定するのでこの間にサブネットワークの上のEnd Systemsが互いにコミュニケートできないかもしれない、ESsはいいえが利用可能であり、ローカルのサブネットワーク直接における彼らの交通を送ることである彼らの唯一の償還請求を取るということであるとわかるでしょう。
Given the types of problems that can occur, it is important that responsibility for incorrect information can be unambiguously as- signed to the source of the information. For this reason all Holding Timers are calculated by the source of the Configuration or Route Redirection information and communicated explicitly to each recipient in the appropriate PDU.
起こることができる問題のタイプを考えて、不正確な情報への責任が明白にそうであることができることが重要である、-、情報の源までサインされます。 この理由で、すべてのHolding Timersが適切なPDUでConfigurationかRoute Redirection情報の情報筋によって計算されて、明らかに各受取人に伝えられます。
A.2 Refresh and timeout of Redirection information
A.2がリフレッシュする、Redirection情報のタイムアウト
The protocol allows End Systems to refresh redirection information without first allowing the holding time to expire and being redirect- ed by a Intermediate System for a second (or subsequent) time. Such schemes are prevalent in connectionless subnetworks and are often called "reverse path information", "previous hop cache" or something similar.
プロトコルで、End Systemsは2番目の、そして、(その後)の時間、最初に、期限が切れる把持時間を許容して、Intermediate Systemによる再直接の教育であるのなしでリダイレクション情報をリフレッシュできます。 そのような計画は、コネクションレスなサブネットワークで一般的であり、しばしば呼ばれた「逆の経路情報」、「前のホップキャッシュ」または何か同様のものです。
Refreshing the redirection information has obvious performance bene- fits, but can be dangerous if not handled in a very conservative fashion. In order for a redirection to be safely refreshed, all of the following conditions must hold:
リダイレクション情報をリフレッシュするのは、嘆願が合う明白な性能を持っていますが、非常に保守的なやり方で扱われないなら、危険である場合があります。 リダイレクションが安全にリフレッシュされるために、以下の条件のすべてが成立しなければなりません:
1. The source address of the received PDU must be exactly the same
as the destination address specified in a prior RD PDU (this
defines a "match" on the redirection information). Making
assumptions about the equivalence of abbreviated addresses,
group addresses, or similar "special" addresses is dangerous
since routing for these addresses cannot be assumed to be
the same.
1. 容認されたPDUのソースアドレスはまさに送付先アドレスが先のRD PDUで指定したのと同じでなければなりません(これはリダイレクション情報で「マッチ」を定義します)。 これらのアドレスのためのルーティングが同じであると思うことができないで、短縮アドレス、グループアドレス、または同様の「特別な」アドレスの等価性に関する仮定をするのは危険です。
2. The Quality of Service parameters of the received PDU must be
exactly the same as the QoS parameters specified in the matching
(by destination address) redirection entry.Again, there is no
guarantee that PDUs with different QoS parameters will be routed
the same way. It is quite possible that the redirected path is
even a black hole for certain values of the QoS parameters (the
security field is a good example).
2. 容認されたPDUのServiceパラメタのQualityがまさにQoSパラメタが合っている(送付先アドレスによる)リダイレクションentry.Againで指定したのと同じでなければならない、異なったQoSパラメタがあるPDUsが同じ道に発送されるという保証が全くありません。 向け直された経路がQoSパラメタのある値のためのブラックホール(セキュリティ分野は好例である)でさえあるかなり可能です。
ISO N4053 [Page 39] RFC 995 December 1986
ISO N4053[39ページ]RFC995 1986年12月
3. The "previous hop" of the received Data PDU must match the "next
hop" stored in the redirection information. Specifically, the
SN_Source_Address of the SN_UNITDATA.Indication which received the
PDU must match exactly the SN_Destination_Address specified in the
redirect to be used for sending traffic via the SN_UNITDATA.Request
primitive. This comparison ensures that redirects are refreshed only
when the reverse traffic is being received from the same IS (or
destination ES) as the forward traffic is being sent through (or
to). This check make certain that redirects are not refreshed for
just on the basis of traffic being received from the destination.
It is quite possible that the traffic is simply indicating that the
forward path in use is not working!
3. 容認されたData PDUの「前のホップ」はリダイレクション情報に格納された「次のホップ」に合わなければなりません。 明確に、_PDUを受けたSN_UNITDATA.IndicationのAddressがそうしなければならないSN_SourceはちょうどDestination_Addressが送付交通にSN_UNITDATA.Requestを通して原始的に使用されるために再直接で指定したSN_に合っています。 この比較は、それが向け直すのを確実にします。前進の交通は逆の交通が同じくらいから受け取るのがあるという(または、目的地ES)ことである場合にだけ壮快ですが、あります。 このチェックがそれを確実にする、向け直す、すぐ交通に基づいて目的地から受け取るために、リフレッシュされません。 交通が、使用中のフォワードパスが働いていないのを単に示しているのは、かなり可能です!
Note that these conditions still allow refresh in the most useful and common cases where either the destination is another ES on the same subnetwork as the source ES, or the redirection is to a IS which is passing traffic to/from the destination in both directions (i.e. the path is symmetric).
スチール写真が許容するこれらの状態が目的地がソースESと同じサブネットワークの上の別のESであるかaにはリダイレクションがある最も役に立って一般的な場合でリフレッシュするというメモはどれが目的地からの/への両方の指示の交通であるかということ(すなわち、経路は左右対称である)です。
A.3 System Initialization Considerations
A.3システム初期化問題
This protocol is designed to make the exchange of information as free as possible from dependencies between the two types of systems. therefore, it is not possible for an End System to request all Inter- mediate Systems on a subnetwork to report their configuration, nor is it possible for an Intermediate System to request all End Systems on a subnetwork to report their configuration.
このプロトコルは、情報交換をできるだけ2つのタイプのシステムの間の依存から自由にするように設計されています。したがって、End Systemが、彼らの構成を報告するようサブネットワークの上のすべてのInterの仲介のSystemsに要求するのは、可能ではありません、そして、Intermediate Systemが、彼らの構成を報告するようサブネットワークの上のすべてのEnd Systemsに要求するのにおいてそれは可能ではありません。
In certain operating environments a constraint may be imposed than an ES, upon becoming operational, must discover the existence of an IS as soon as possible.The converse relationship also holds if it is necessary for an IS to discover the existence of End Systems as soon as possible. In both cases the availability of this information is normally determined by the Configuration Timer of the system for which the knowledge is desired. there is therefore a tradeoff between the overhead associated with performing the Report and Record Confi- guration functions and the timely availability of the configuration information. Decreasing the Configuration Timer increases the availa- bility at the expense of an increase in overhead.
ある操作環境では、規制がESが操作上になるとき存在を発見しなければならないより課されるかもしれない、また、それが必要であるならas soon as possible.The逆関係が船倉である、できるだけ早く、End Systemsの存在を発見することになっています。 どちらの場合も、通常、この情報の有用性は知識が望まれているシステムのConfiguration Timerによって決定されます。したがって、設定情報のReportを実行すると関連しているオーバーヘッドと、Record Confi- guration機能とタイムリーな有用性の間には、見返りがあります。 Configuration Timerを減少させると、availa- bilityはオーバーヘッドの増加を犠牲にして増加します。
The following solution is recommended for addressing the constraint described above. When the Record Configuration function is invoked in either an End System or an Intermediate System, the function will determine if the received configuration information was previously unknown.If this is the case, then the Report Configuration function may be invoked before the expiration of the system's Configuration Timer. The Hello PDU generated by the Report Configuration function is then sent only to the Network Entity whose configuration was pre- viously unknown. Thus when an ES or IS first becomes operational it immediately reports its configuration. As soon as systems of the oth- er type discover the new network entity, they will make their own
以下の解決策は、上で説明された規制を記述するために推薦されます。 Record Configurationが機能するとき、受信された設定情報が以前に決定したならEnd SystemかIntermediate System、機能が決定する呼び出されたコネはunknown.Ifです。これがそうである、次に、Report Configuration機能はシステムのConfiguration Timerの満了の前に呼び出されるかもしれません。 そして、構成がプレviouslyに未知であったNetwork EntityだけにReport Configuration機能で発生するHello PDUを送ります。 1番目は操作上になります。このようにして、ESである、存在、それはすぐに、構成を報告します。 えー、タイプが発見するothのシステムの次第、新しいネットワーク実体であり、それらはそれら自身のを作るでしょう。
ISO N4053 [Page 40] RFC 995 December 1986
ISO N4053[40ページ]RFC995 1986年12月
configuration known to this entity.
この実体に知られている構成。
The additional overhead incurred by this solution is minimal. Also, since the discovery of new configurations is made timely by this ap- proach the Configuration Timer period can be increased in order to decrease the overhead of the configuration functions, provided that other factors not discussed here are accounted for by the longer time period.One caveat is that the first Hello PDU generated by a system may be lost during transmission. To solve this problem one or more additional PDUs may be transmitted at short time intervals during this initialization period.
この解決策によって被られた追加オーバーヘッドは最小限です。 また、新しい構成の発見がタイムリーにこのap- proachによってされるので、Configuration Timerの期間は構成機能のオーバーヘッドを下げるために増加できて、ここで議論しなかった他の要素が、より長いtime period.Oneによって説明されれば、警告はシステムで発生する最初のHello PDUがトランスミッションの間なくされるかもしれないということです。 この問題を解決するために、1追加PDUsがこの初期化の期間、短い時間間隔で、伝えられるかもしれません。
Note that this solution may be implemented in ISs only, in ESs only, or in both Intermediate and End Systems.This decision is purely a lo- cal matter and may be alterable through System Management.
この解決策がIntermediateとEnd Systems.This決定の両方で純粋に最低気温calが重要であるということであり、ISsだけ、ESsだけで実行されるかもしれないか、またはSystem Managementを通して可変であるかもしれないことに注意してください。
A.4 Optimizations for Flushing Redirects
洗い流すためのA.4最適化は向け直します。
An ES will attempt to forward NPDUs through an IS to which it has been redirected until the Holding Timer specified in the RD PDU has expired, even if that IS is no longer reachable. Under certain cir- cumstances, it is possible to do better and recognize the existence of a black hole sooner. In particular, if the ES expects to hear ISH PDUs from the IS to which it has been redirected, and the Holding Ti- mer for that IS expires, all knowledge of the IS may be forgotten by the ES. This includes any redirects, which may be flushed (see the Flush Old Redirect function) even though their timeouts have not ex- pired.
NPDUsを進める、ESが、試みる中のRD PDUがそれがそうであっても吐き出した指定されたHolding Timerがもう届かないまで、それがどれであるかに向け直されます。 あるcir- cumstancesの下では、より早くブラックホールの存在をより上手にして、認識するのは可能です。 ESが、ISH PDUsを聞くと特に予想する、どれに関するそれが向け直されて、それがいるのでHolding Ti- merが期限が切れて、すべてが知識であるかにはある、ESによって忘れられるかもしれません。 いずれも向け直すこのインクルードであり、それらのタイムアウトには元の連れ合いがいませんが、どれが洗い流されるかもしれないかは(Flush Old Redirect機能を見ます)piredされました。
ISO N4053 [Page 41]
ISO N4053[41ページ]
一覧
スポンサーリンク
