RFC994 日本語訳
0994 Final text of DIS 8473, Protocol for Providing theConnectionless-mode Network Service. International Organization forStandardization. March 1986. (Format: TXT=129006 bytes) (Obsoletes RFC0926) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group ANSI X3S3.3 86-80
Request for Comments: 994 ISO TC97/SC6/N 3998
March 1986
コメントを求めるワーキンググループANSI X3S3.3 86-80要求をネットワークでつないでください: 994 1986年のN3998ISO TC97/SC6/行進
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: Final Text of DIS 8473, Protocol for Providing the Connectionless-
mode Network Service
タイトル: DIS8473の最終的なText、Providing ConnectionlessモードNetwork Serviceのためのプロトコル
Source: DIS 8473 Editor
ソース: 8473年のエディタをけなしてください。
ISO 8473 [Page 1] RFC 994 December 1986
ISO8473[1ページ]RFC994 1986年12月
Contents
コンテンツ
1 Scope and Field of Application 6
アプリケーション6の1つの範囲と分野
2 References 7
2つの参照箇所7
SECTION ONE. GENERAL 9
セクション1。 一般的な9
3 Definitions 9
3.1 Reference Model Definitions . . . . . . . . . . . . . . . . . 9
3.2 Service Conventions Definitions . . . . . . . . . . . . . . . 9
3.3 Network Layer Architecture Definitions . . . . . . . . . . . . 9
3.4 Network Layer Addressing Definitions . . . . . . . . . . . . . 10
3.5 Additional Definitions . . . . . . . . . . . . . . . . . . . . 10
3つの定義9 3.1の規範モデル定義. . . . . . . . . . . . . . . . . 9 3.2がコンベンションにサービスを提供する、定義. . . . . . . . . . . . . 10 3.5の追加定義. . . . . . . . . . . . . . . . . . . . 10を記述する定義. . . . . . . . . . . . . . . 9 3.3ネットワーク層構造定義. . . . . . . . . . . . 9 3.4ネットワーク層
4 Symbols and Abbreviations 11
4.1 Data Units . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 11
4.3 Protocol Data Unit Fields . . . . . . . . . . . . . . . . . . 11
4.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 11
4つのシンボルと略語11 4.1データ単位. . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2のプロトコルデータ単位. . . . . . . . . . . . . . . . . . . . . 11 4.3プロトコルデータ単位分野. . . . . . . . . . . . . . . . . . 11 4.4パラメタ. . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5その他. . . . . . . . . . . . . . . . . . . . . . . . 11
5 Overview of the Protocol 12
5.1 Internal Organization of the Network Layer . . . . . . . . . . 12
5.2 Subsets of the Protocol . . . . . . . . . . . . . . . . . . . 12
5.3 Addresses and Titles . . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Addresses . . . . . . . . . . . . . . . . . . . . . . 13
5.3.2 Network-entity Titles . . . . . . . . . . . . . . . . 13
5.4 Service Provided by the Network Layer . . . . . . . . . . . . 14
5.5 Underlying Service Assumed by the Protocol . . . . . . . . . . 14
5.5.1 Subnetwork Points of Attachment . . . . . . . . . . . 15
5.5.2 Subnetwork Quality of Service . . . . . . . . . . . . 15
5.5.3 Subnetwork User Data . . . . . . . . . . . . . . . . 16
5.5.4 Subnetwork Dependent Convergence Functions . . . . . . 16
5.6 Service Assumed from Local Environment . . . . . . . . . . . . 16
プロトコルの5概観、12、5.1の内部の組織、ネットワーク層によって…提供されたプロトコル. . . . . . . . . . . . . . . . . . . 12 5.3の.125.2の部分集合が記述するネットワーク層と.2のネットワーク実体タイトル. . . . . . . . . . . . . . . . 13 5.4が修理するタイトル. . . . . . . . . . . . . . . . . . . . . 13 5.3.1のアドレス. . . . . . . . . . . . . . . . . . . . . . 13 5.3; .145.5 基本的なサービスは、プロトコル. . . . . . . . . . 14 5.5.1サブネットワークポイントの付属. . . . . . . . . . . 15 5.5で.2サブネットワークサービスの質. . . . . . . . . . . . 15 5.5.3のサブネットワーク利用者データ. . . . . . . . . . . . . . . . 16 5.5.4のサブネットワークの依存する集合機能. . . . . . 16 5.6が地方の環境. . . . . . . . . . . . 16から想定されたサービスであると仮定しました。
SECTION TWO. SPECIFICATION OF THE PROTOCOL 18
セクションTWO。 プロトコル18の仕様
6 Protocol Functions 18
6.1 PDU Composition Function . . . . . . . . . . . . . . . . . . . 18
6.2 PDU Decomposition Function . . . . . . . . . . . . . . . . . . 19
6.3 Header Format Analysis Function . . . . . . . . . . . . . . . 19
6つのプロトコル機能18 6.1PDU構成機能. . . . . . . . . . . . . . . . . . . 18 6.2PDU分解機能. . . . . . . . . . . . . . . . . . 19 6.3ヘッダー形式分析機能. . . . . . . . . . . . . . . 19
ISO 8473 [Page 2] RFC 994 December 1986
ISO8473[2ページ]RFC994 1986年12月
6.4 PDU Lifetime Control Function . . . . . . . . . . . . . . . . 20
6.5 Route PDU Function . . . . . . . . . . . . . . . . . . . . . . 20
6.6 Forward PDU Function . . . . . . . . . . . . . . . . . . . . . 21
6.7 Segmentation Function . . . . . . . . . . . . . . . . . . . . 21
6.8 Reassembly Function . . . . . . . . . . . . . . . . . . . . . 22
6.9 Discard PDU Function . . . . . . . . . . . . . . . . . . . . . 23
6.10 Error Reporting Function . . . . . . . . . . . . . . . . . . . 24
6.10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 24
6.10.2 Requirements . . . . . . . . . . . . . . . . . . . . . 25
6.10.3 Processing of Error Reports . . . . . . . . . . . . . 25
6.10.4 Relationship of Data PDU Options to Error Reports . . 26
6.11 PDU Header Error Detection . . . . . . . . . . . . . . . . . . 27
6.12 Padding Function . . . . . . . . . . . . . . . . . . . . . . . 28
6.13 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.14 Source Routing Function . . . . . . . . . . . . . . . . . . . 28
6.15 Record Route Function . . . . . . . . . . . . . . . . . . . . 29
6.16 Quality of Service Maintenance Function . . . . . . . . . . . 30
6.17 Priority Function . . . . . . . . . . . . . . . . . . . . . . 31
6.18 Congestion Notification Function . . . . . . . . . . . . . . . 31
6.19 Classification of Functions . . . . . . . . . . . . . . . . . 31
6.4 PDU生涯コントロール機能. . . . . . . . . . . . . . . . 20 6.5ルートPDU機能. . . . . . . . . . . . . . . . . . . . . . 20 6.6前進のPDU機能. . . . . . . . . . . . . . . . . . . . . 21 6.7分割機能. . . . . . . . . . . . . . . . . . . . 21 6.8Reassembly機能. . . . . . . . . . . . . . . . . . . . . 22 6.9はPDU機能. . . . . . . . . . . . . . . . . . . . . 23 6.10誤り報告機能. . . . . . . . . . . . . . . . . . . 24 6.10.1概観を捨てます…; . . . . . . . . . . . . . . . . . . . . 24 6.10.2 誤りの要件. . . . . . . . . . . . . . . . . . . . . 25 6.10.3処理が報告する、.25 6.10、.4関係、エラー・レポート. . 26 6.11へのデータPDUオプションでは、機能. . . . . . . . . . . . . . . . . . . . . . . 28 6.13セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.14ソースルート設定を水増しするPDUヘッダー誤り検出. . . . . . . . . . . . . . . . . . 27 6.12が機能します…. . . 28 6.15 機能. . . . . . . . . . . . . . . . . 31のサービス維持機能. . . . . . . . . . . 30 6.17優先権機能. . . . . . . . . . . . . . . . . . . . . . 31 6.18混雑通知機能.31 6.19分類の記録的なルート機能.29 6.16品質
7 Structure and Encoding of PDUs 33
7.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Fixed Part . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.1 General . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.2 Network Layer Protocol Identifier . . . . . . . . . . 34
7.2.3 Length Indicator . . . . . . . . . . . . . . . . . . 35
7.2.4 Version/Protocol Identifier Extension . . . . . . . . 35
7.2.5 PDU Lifetime . . . . . . . . . . . . . . . . . . . . 35
7.2.6 Flags . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2.6.1 Segmentation Permitted . . . . . . . . . . . 35
7.2.6.2 More Segments . . . . . . . . . . . . . . . 35
7.2.6.3 Error Report . . . . . . . . . . . . . . . 36
7.2.7 Type Code . . . . . . . . . . . . . . . . . . . . . . 36
7.2.8 PDU Segment Length . . . . . . . . . . . . . . . . . 36
7.2.9 PDU Checksum . . . . . . . . . . . . . . . . . . . . 36
7.3 Address Part . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.1 General . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.1.1 Destination and Source Addresses . . . . . . 37
7.4 Segmentation Part . . . . . . . . . . . . . . . . . . . . . . 38
7.4.1 Data Unit Identifier . . . . . . . . . . . . . . . . . 38
7.4.2 Segment Offset . . . . . . . . . . . . . . . . . . . . 38
7.4.3 PDU Total Length . . . . . . . . . . . . . . . . . . . 39
7.5 Options Part . . . . . . . . . . . . . . . . . . . . . . . . 39
7.5.1 General . . . . . . . . . . . . . . . . . . . . . . . 39
7.5.2 Padding . . . . . . . . . . . . . . . . . . . . . . . 40
7.5.3 Security . . . . . . . . . . . . . . . . . . . . . . . 40
7.5.3.1 Source Address Specific . . . . . . . . . . 41
7.5.3.2 Destination Address Specific . . . . . . . . 41
7.5.3.3 Globally Unique Security . . . . . . . . . . 41
7.5.4 Source Routing . . . . . . . . . . . . . . . . . . . 41
7 PDUs33 7.1構造. . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.2の構造とコード化は.347.2.2ネットワーク層プロトコル識別子. . . . . . . . . . 34 7.2.3長さのインディケータ. . . . . . . . . . . . . . . . . . 35 7.2.4バージョン/プロトコル識別子拡張子. . . . . . . . 35 7.2.5PDU生涯. . . . . . . . . . . . . . . . . . . . 35 7.2.6個の旗をパート. . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.2.1一般に固定しました…; . . . . . . . . . . . . . . . . . . 35 7.2.6.1 分割は.357.2.6もう.2のセグメント. . . . . . . . . . . . . . . 35 7.2.6.3エラー・レポート. . . . . . . . . . . . . . . 36 7.2.7タイプコード. . . . . . . . . . . . . . . . . . . . . . 36 7.2.8PDUセグメントの長さ. . . . . . . . . . . . . . . . . 36 7.2の.9PDUチェックサム. . . . . . . . . . . . . . . . . . . . 36 7.3アドレス部. . . . . . . . . . . . . . . . . . . . . . . . 37 7.3.1一般を可能にしました…. . . . 全長. . . . . . . . . . . . . . . . . . . 39 7.5がゆだねる37の7.3の.1の.1の目的地とソースアドレス. . . . . . 37 7.4の分割パート. . . . . . . . . . . . . . . . . . . . . . 38 7.4.1データ単位の識別子. . . . . . . . . . . . . . . . . 38 7.4.2セグメントオフセット. . . . . . . . . . . . . . . . . . . . 38 7.4.3PDUが離れている、.397.5、.1一般; . . . . . . . . . . . . . . . . . . . . . . 39 7.5.2 詰め物. . . . . . . . . . . . . . . . . . . . . . . 40 7.5.3セキュリティ. . . . . . . . . . . . . . . . . . . . . . . 40 7.5.3.1ソースアドレス特定の. . . . . . . . . . 41 7.5.3.2送付先アドレス特有である、.417.5、.3、.3、.41を発送するグローバルにユニークなセキュリティ. . . . . . . . . . 41 7.5.4ソース
ISO 8473 [Page 3] RFC 994 December 1986
ISO8473[3ページ]RFC994 1986年12月
7.5.5 Recording of Route . . . . . . . . . . . . . . . . . . 42
7.5.6 Quality of Service Maintenance . . . . . . . . . . . . 43
7.5.6.1 Source Address Specific . . . . . . . . . . 43
7.5.6.2 Destination Address Specific . . . . . . . . 43
7.5.6.3 Globally Unique QoS . . . . . . . . . . . . 43
7.5.7 Priority . . . . . . . . . . . . . . . . . . . . . . 44
7.6 Data Part . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.7 Data (DT) PDU . . . . . . . . . . . . . . . . . . . . . . . . 46
7.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . 46
7.7.1.1 Fixed Part . . . . . . . . . . . . . . . . . . . . . 47
7.7.1.2 Addresses . . . . . . . . . . . . . . . . . . . . . 47
7.7.1.3 Segmentation . . . . . . . . . . . . . . . . . . . . 47
7.7.1.4 Options . . . . . . . . . . . . . . . . . . . . . . 47
7.7.1.5 Data . . . . . . . . . . . . . . . . . . . . . . . 47
7.8 Inactive Network Layer Protocol . . . . . . . . . . . . . . . 47
7.8.1 Network Layer Protocol Id . . . . . . . . . . . . . . 47
7.8.2 Data Field . . . . . . . . . . . . . . . . . . . . . 47
7.9 Error Report PDU (ER) . . . . . . . . . . . . . . . . . . . . 48
7.9.1 Structure . . . . . . . . . . . . . . . . . . . . . . 48
7.9.1.1 Fixed Part . . . . . . . . . . . . . . . . . 49
7.9.1.2 Addresses . . . . . . . . . . . . . . . . . 49
7.9.1.3 Options . . . . . . . . . . . . . . . . . . 49
7.9.1.4 Reason for Discard . . . . . . . . . . . . . 50
7.9.1.5 Error Report Data Field . . . . . . . . . . 51
7.5.5 サービス維持. . . . . . . . . . . . 43 7.5.6.1ソースアドレス特定の. . . . . . . . . . 43 7.5.6.2送付先アドレス特有のルート.427.5.6品質の録音、.437.5、.6、.3、グローバルにユニークなQoS. . . . . . . . . . . . 43 7.5.7優先権. . . . . . . . . . . . . . . . . . . . . . 44 7.6データパート. . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.7データ(DT)PDU.467.7.1構造; . . . . . . . . . . . . . . . . . . . . . 46 7.7.1.1 固定パート. . . . . . . . . . . . . . . . . . . . . 47 7.7.1.2のアドレス. . . . . . . . . . . . . . . . . . . . . 47 7.7.1.3分割. . . . . . . . . . . . . . . . . . . . 47 7.7.1.4のオプション. . . . . . . . . . . . . . . . . . . . . . 47 7.7.1不活発な.5のデータ. . . . . . . . . . . . . . . . . . . . . . . 47 7.8のネットワーク層プロトコル. . . . . . . . . . . . . . . 47 7.8.1ネットワーク層プロトコルイド. . . . . . . . . . . . . . 47 7.8.2データField.477.9誤りReport PDU(ER). . . . . . . . . . . . . . . . . . . . 48 7.9.1Structure. . . . . . . . . . . . . . . . . . . . . . 48 7.9.1.1Fixed Part. . . . . . . . . . . . . . . . . 49 7.9.1.2Addresses. . . . . . . . . . . . . . . . . 49 7.9.1.3Options.497.9、.1、Discard. . . . . . . . . . . . . 50 7.9.1.5Error Report Data Field. . . . . . . . . . 51のための.4Reason
8 Conformance 51
8.1 Provision of Functions for Conformance . . . . . . . . . . . . 51
8 順応. . . . . . . . . . . . 51のための機能の順応51 8.1支給
List of Tables
テーブルのリスト
1 Service Primitives for Underlying Service . . . . . . . . . . . . 14 2 Service Primitives for Underlying Service . . . . . . . . . . . . 14 3 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Categorization of Protocol Functions . . . . . . . . . . . . . . . 32 5 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . . . 36 6 Encoding of Option Parameters . . . . . . . . . . . . . . . . . . 39 7 Reason for Discard . . . . . . . . . . . . . . . . . . . . . . . . 50 8 Categorization of Functions . . . . . . . . . . . . . . . . . . . 52
1 .143のサービスタイマ基関数の基礎となって、プロトコルの.144分類が機能するので、基本的なサービス. . . . . . . . . . . . 14 2サービス基関数のための基関数を修理してください…; 32 パラメタ. . . . . . . . . . . . . . . . . . 39 7が推論するオプションをコード化する5つの有効なPDUタイプ. . . . . . . . . . . . . . . . . . . . . . . . . 36 6が機能. . . . . . . . . . . . . . . . . . . 52の.508分類を捨てます。
List of Figures
数字のリスト
1 Interrelationship of Standards . . . . . . . . . . . . . . . . . 6 2 PDU Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . . . 34 4 PDU Header -- Address Part . . . . . . . . . . . . . . . . . . . 37 5 Address Parameters . . . . . . . . . . . . . . . . . . . . . . . . 38 6 PDU Header -- Segmentation Part . . . . . . . . . . . . . . . . . 38 7 PDU Header -- Options Part . . . . . . . . . . . . . . . . . . . . 39 8 PDU Header -- Data Field . . . . . . . . . . . . . . . . . . . . 45
1 規格. . . . . . . . . . . . . . . . . 6 2PDU構造. . . . . . . . . . . . . . . . . . . . . . . . . . 34 3PDUヘッダーの相互関係--固定パート. . . . . . . . . . . . . . . . . . . . . 34 4PDUヘッダー; アドレス部. . . . . . . . . . . . . . . . . . . 37 5アドレスパラメタ. . . . . . . . . . . . . . . . . . . . . . . . 38 6PDUヘッダー--分割パート. . . . . . . . . . . . . . . . . 38 7PDUヘッダー--オプションは.398PDUヘッダーを分けます--データは.45をさばきます。
ISO 8473 [Page 4] RFC 994 December 1986
ISO8473[4ページ]RFC994 1986年12月
9 DT PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10 Inactive Network Layer Protocol . . . . . . . . . . . . . . . . . 47 11 Error Report PDU . . . . . . . . . . . . . . . . . . . . . . . . . 48
夏時間9のPDU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10の不活発なネットワーク層プロトコル. . . . . . . . . . . . . . . . . 47 11エラー・レポートPDU. . . . . . . . . . . . . . . . . . . . . . . . . 48
ISO 8473 [Page 5] RFC 994 December 1986
ISO8473[5ページ]RFC994 1986年12月
0 Introduction
0序論
This Protocol Standard 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 interconnection.
このプロトコルStandardはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなインタコネクトを達成するのが必要です。
This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Sys- tems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It pro- vides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).
このプロトコルStandardはオープンSys- tems Interconnection(ISO7498)のためにReference Modelで定義された層のそばに他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 このプロトコルはエンドシステムかNetwork Layerリレー方式のネットワーク実体(ともに)の間で使用されるかもしれません。 それ、親、参照、Addendum1でNetwork Service Definition Covering Connectionless-モードと定義されるConnectionless-モードNetwork Service Transmission(ISO8348/AD1)。
The interrelationship of these standards is illustrated in Figure 1 below:
これらの規格の相互関係は以下の図1で例証されます:
--------------------+--- ISO NETWORK SERVICE PROVIDER -----^-----------------
| |
| |
| |
PROTOCOL | REFERENCE TO AIMS -----------------+
|
SPECIFICATION | REFERENCE TO ASSUMPTIONS -----------+
| |
| |
| |
--------------------+---SUBNETWORK SERVICE DEFINITION(S)---v-----------------
--------------------+--- ISOネットワークサービスプロバイダー-----^----------------- | | | | | | プロトコル| 目的の参照-----------------+ | 仕様| 仮定の参照-----------+ | | | | | | --------------------+---サブネットワークサービス定義(S)---v-----------------
Figure 1: Interrelationship of Standards
図1: 規格の相互関係
1 Scope and Field of Application
1 範囲と応用分野
This International Standard specifies a protocol which is used to provide the Connectionless-mode Network Service as described in Ad- dendum 1 to the Network Service Definition Covering Connectionless- mode Transmission. The protocol relies upon the provision of an underlying connectionless-mode service by real subnetworks and/or data links. The underlying connectionless-mode service assumed by the protocol may be obtained either directly, from a connectionless-mode real subnetwork, or indirectly, through the operation of an appropri- ate Subnetwork Dependent Convergence Function (SNDCF) or Protocol (SNDCP) over a connection-mode real subnetwork as described in ISO 8648, Internal Organization of the Network Layer.
この国際規格はAd- dendum1でNetwork Service Definition Covering ConnectionlessモードTransmissionに説明されるようにConnectionless-モードNetwork Serviceを提供するのに使用されるプロトコルを指定します。 プロトコルは本当のサブネットワーク、そして/または、データ・リンクのそばで基本的にコネクションレスなモードサービスの支給を当てにします。 プロトコルによって想定された基本的なコネクションレスなモードサービスは、コネクションレスなモードの本当のサブネットワークから直接入手したかもしれないか、またはISO8648(Network LayerのInternal Organization)で説明されるように接続モードの本当のサブネットワークの上で間接的にappropriの操作でSubnetwork Dependent Convergence Function(SNDCF)かプロトコル(SNDCP)を食べました。
ISO 8473 [Page 6] RFC 994 December 1986
ISO8473[6ページ]RFC994 1986年12月
This Standard specifies:
このStandardは指定します:
a) procedures for the connectionless transmission of data and
control information from one network-entity to a peer
network-entity;
a) データのコネクションレスな伝達のための手順と1つのネットワーク実体から同輩ネットワーク実体までの制御情報。
b) the encoding of the protocol data units (PDUs) used for the
transmission of data and control information, comprising a
variable-length protocol header format;
b) プロトコルデータ単位(PDUs)のコード化はデータとコントロールのトランスミッションに情報を使用しました、可変長のプロトコルヘッダー形式を包括して。
c) procedures for the correct interpretation of protocol control
information; and
プロトコル制御情報の正しい解釈のためのc)手順。 そして
d) the functional requirements for implementations claiming
conformance to the Standard.
d) Standardに順応を要求する実装のための機能条件書。
The procedures are defined in terms of:
手順は以下に関して定義されます。
a) the interactions among peer network-entities through the
exchange of protocol data units;
a) プロトコルデータ単位の交換による同輩ネットワーク実体の中の相互作用。
b) the interactions between a network-entity and a Network Service
user through the exchange of Network Service primitives; and
b) ネットワーク実体とNetwork Service基関数の交換によるNetwork Serviceユーザとの相互作用。 そして
c) the interactions between a network-entity and an underlying
service provider through the exchange of service primitives.
c) ネットワーク実体とサービス基関数の交換による基本的なサービスプロバイダーとの相互作用。
2 References
2つの参照箇所
ISO 7498, Information Processing Systems --- Open Systems Intercon- nection --- Basic Reference Model
ISO7498、情報処理システム--- 開いているSystems Intercon- nection--- 基本参照モデル
DIS 7498/AD1, Information Processing Systems --- Open Systems In- terconnection --- Addendum to ISO 7498 Covering Connectionless-mode Transmission
7498/AD1、情報処理システムをけなしてください。--- 開いているSystems In- terconnection--- コネクションレス型伝送をカバーするISO7498への付加物
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 Net- work Service Definition Covering Connectionless-mode Transmission
ISO8348/AD1、情報処理システム--- システムの間のテレコミュニケーションと情報交換--- ネット仕事Service Definition Covering Connectionless-モードTransmissionへの付加物
ISO 8348/AD2, Information Processing Systems --- Telecommunications and Information Exchange between Systems --- Addendum to the Net- work Service Definition Covering Network Layer Addressing*
ISO8348/AD2、情報処理システム--- システムの間のテレコミュニケーションと情報交換--- ネット仕事Service Definition Covering Network Layer Addressing*への付加物
DIS 8648, Information Processing Systems --- Telecommunications and Information Exchange between Systems --- Internal Organization of the Network Layer
8648、情報処理システムをけなしてください。--- システムの間のテレコミュニケーションと情報交換--- ネットワーク層の内部の組織
ISO 8473 [Page 7] RFC 994 December 1986
ISO8473[7ページ]RFC994 1986年12月
ISO 8509, Technical Report --- OSI Service Conventions
ISO8509、技術報告書--- OSIサービスコンベンション
ISO 9074, A Formal Description Technique based on an Extended State
Transition Model
________________________________
*At present, at the stage of Draft; publication anticipated in
due course.
ISO9074、Extended州Transition Modelに基づくA Formal記述Technique________________________________ *プレゼント、Draftの台で。 公表は、支払われるべきもので勢いよく流れるように予期しました。
ISO 8473 [Page 8] RFC 994 December 1986
ISO8473[8ページ]RFC994 1986年12月
SECTION ONE. GENERAL
セクション1。 一般
3 Definitions
3つの定義
3.1 Reference Model Definitions
3.1 規範モデル定義
This document makes use of the following concepts defined in ISO 7498:
このドキュメントはISO7498で定義された以下の概念を利用します:
(a) End system
(a) エンドシステム
(b) Network entity
(b) ネットワーク実体
(c) Network layer
(c) ネットワーク層
(d) Network protocol
(d) ネットワーク・プロトコル
(e) Network protocol data unit
(e) ネットワーク・プロトコルデータ単位
(f) Network relay
(f)ネットワークリレー
(g) Network service
(g) ネットワーク・サービス
(h) Network service access point
(h) ネットワークサービスアクセスポイント
(i) Network service access point address
(i) ネットワーク・サービスアクセスポイントアドレス
(j) Routing
(j) ルート設定
(k) Service
(k) サービス
(l) Service data unit
(l) サービスデータ単位
3.2 Service Conventions Definitions
3.2 サービスコンベンション定義
This Protocol Standard makes use of the following terms from the OSI Service Conventions Technical Report (ISO TR 8509):
このプロトコルStandardはOSI Service Conventions Technical Report(ISO TR8509)からの次の用語を利用します:
(a) Service provider
(a) サービスプロバイダー
(b) Service user
(b) サービス利用者
3.3 Network Layer Architecture Definitions
3.3 ネットワーク層アーキテクチャ定義
This Protocol Standard makes use of the following terms from the Internal Organization of the Network Layer (ISO 8648):
このプロトコルStandardはNetwork Layer(ISO8648)のInternal Organizationからの次の用語を利用します:
(a) Intermediate system
(a) 中間システム
(b) Relay system
(b) リレー方式
(c) Subnetwork
(c) サブネットワーク
ISO 8473 [Page 9] RFC 994 December 1986
ISO8473[9ページ]RFC994 1986年12月
3.4 Network Layer Addressing Definitions
3.4 ネットワーク層アドレシング定義
This Protocol Standard makes use of the following terms from ISO 8348/AD2, Addendum to the Network Service Definition Covering Network Layer addressing:
このプロトコルStandardはISO8348/AD2からの次の用語を利用します、Network Service Definition Covering Network LayerアドレシングへのAddendum:
(a) Network addressing domain
(a) ネットワークアドレス指定領域
(b) Network protocol address information
(b) ネットワーク・プロトコルアドレス情報
(c) Subnetwork point of attachment
(c) サブネットワーク接着点
3.5 Additional Definitions
3.5 追加定義
For the purposes of this Protocol Standard, the following definitions apply:
このプロトコルStandardの目的のために、以下の定義は申し込まれます:
(a) derived PDU --- a protocol data unit whose fields are identical
to those of an initial PDU, except that it carries only a segment
of the user data from an N-UNITDATA request.
(a) 派生しているPDU--- N-UNITDATA要求から利用者データのセグメントだけを運ぶのを除いて、分野が初期のPDUのものと同じであるプロトコルデータ単位。
(b) initial PDU --- a protocol data unit carrying the whole of the
userq data from an N-UNITDATA request.
(b) 初期のPDU--- N-UNITDATAからのデータが要求するuserqの全体を運ぶプロトコルデータ単位。
(c) local matter --- a decision made by a system concerning its
behavior in the Network Layer that is not prescribed or
constrained by this Protocol Standard.
(c) 地域にかかわる事柄--- このプロトコルStandardによって処方されないか、または抑制されないNetwork Layerでシステムによって振舞いに関してされた決定。
(d) 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.
(d) ネットワーク実体タイトル--- NSAPアドレスと同じ抽象構文を持って、終わりか中間システムで明白にネットワーク実体を特定するのに使用できるネットワーク実体のための識別子。
(e) reassembly --- the act of regenerating an initial PDU from two
or more derived PDUs.
(e) 再アセンブリ--- 2以上から初期のPDUを作り直す行為はPDUsを引き出しました。
(f) segment --- a distinct unit of data consisting of part or all
of the user data provided in the N-UNITDATA request and delivered
in the N-UNITDATA indication.
(f) セグメント--- 部分から成るデータの異なったユニットかN-UNITDATAに提供された利用者データのすべてが、N-UNITDATA指示で要求して、配送されました。
(g) segmentation --- the act of generating two or more derived PDUs
from an initial or derived PDU. The derived PDUs together carry
the entire user data of the initial or derived PDU from which they
were generated.
(g) 分割--- 初期の、または、派生しているPDUから2かさらに派生しているPDUsを生成する行為。 一緒に派生しているPDUsはそれらが生成された初期の、または、派生しているPDUの全体の利用者データを運びます。
Note:
It is possible that such an initial PDU will never actually be
generated for a particular N-UNITDATA request, owing to the
immediate application of segmentation.
以下に注意してください。 そのような初期のPDUが特定のN-UNITDATA要求のために実際に決して生成されないのは、可能です、分割の即座のアプリケーションのために。
ISO 8473 [Page 10] RFC 994 December 1986
ISO8473[10ページ]RFC994 1986年12月
4 Symbols and Abbreviations
4つのシンボルと略語
4.1 Data Units
4.1 データユニット
NSDU Network Service Data Unit
PDU Protocol Data Unit
SNSDU Subnetwork Service Data Unit
NSDUネットワーク・サービスデータ単位PDUプロトコルデータ単位SNSDUサブネットワークサービスデータ単位
4.2 Protocol Data Units
DT PDU Data Protocol Data Unit
ER PDU Error Report Protocol Data Unit
4.2プロトコルデータ単位、DT PDUデータがえー、エラー・レポートが議定書の中で述べるデータ単位PDUについて議定書の中で述べる、データ単位
4.3 Protocol Data Unit Fields
4.3 プロトコルデータ単位分野
CS Checksum
DA Destination Address
DAL Destination Address Length
DUID Data Unit Identifier
E/R Error Report Flag
LI Length Indicator
LT Lifetime
MS More Segments Flag
NLPID Network Layer Protocol Identifier
SA Source Address
SAL Source Address Length
SL Segment Length
SO Segment Offset
SP Segmentation Permitted Flag
TL Total Lengt
TP Type
V/P Version/Protocol Identifier Extension
CsチェックサムDA目的地アドレスDAL目的地アドレス長さのDUIDデータ単位識別子E/Rエラー・レポート旗のLI長さのインディケータLT生涯MSより多くのセグメント旗のNLPIDネットワーク層プロトコル識別子SAで、セグメントがSP分割を相殺して、ソースアドレスサラソウジュソースアドレス長さのSLセグメントの長さは旗のTl合計Lengt TPタイプV/Pバージョン/プロトコル識別子拡張子を可能にしました。
4.4 Parameters
4.4 パラメタ
DA Destination Address
QOS Quality of Service
SA Source Address
DA目的地アドレスQOSサービスの質SAソースアドレス
4.5 Miscellaneous
4.5 その他
CLNP Connectionless-mode Network Protocol
NS Network Service
NPAI Network Protocol Address Information
NSAP Network Service Access Point
SDU Service Data Uni
SN Subnetwork
SNDCF Subnetwork Dependent Convergence Function
SNDCP Subnetwork Dependent Convergence Protocol
SNICP Subnetwork Independent Convergence Protocol
SNPA Subnetwork Point of Attachment
CLNPコネクションレスなモードネットワーク・プロトコルナノ秒ネットワーク・サービスNPAIネットワーク・プロトコルアドレス情報NSAPネットワーク・サービスアクセスポイントSDUは依存する依存するデータ独立している集合プロトコルSNPAサブネットワークUni SNサブネットワークSNDCFサブネットワーク集合機能SNDCPサブネットワーク集合プロトコルSNICPサブネットワーク接着点を調整します。
ISO 8473 [Page 11] RFC 994 December 1986
ISO8473[11ページ]RFC994 1986年12月
5 Overview of the Protocol
プロトコルの5概要
5.1 Internal Organization of the Network Layer
5.1 ネットワーク層の内部の組織
The architectural organization of the Network Layer is described in a separate document, Internal Organization of the Network Layer (ISO 8648). ISO 8648 identifies and categorizes the way in which functions can be performed within the Network Layer by Network Layer protocols, thus providing a uniform framework for describing how protocols operating either individually or cooperatively in the Network Layer can be used to provide the OSI Network Service. This protocol is designed to be used in the context of the internetworking protocol approach to the provision of the Connectionless-mode Network Service defined in that Standard.
Network Layerの建築組織は別々のドキュメント(Network Layer(ISO8648)のInternal Organization)で説明されます。 ISO8648はNetwork Layerの中でNetwork Layerプロトコルで機能を実行できる方法を特定して、分類します、その結果、OSI Network Serviceを提供するのにどうNetwork Layerで個別か協力して作動するプロトコルは使用できるかを説明するのに一定のフレームワークを提供します。 このプロトコルは、Network ServiceがそのStandardで定義したConnectionless-モードの支給へのインターネットワーキングプロトコルアプローチの文脈で使用されるように設計されています。
This protocol is intended for use in the Subnetwork Independent Con- vergence Protocol (SNICP) role. A protocol which fulfills the SNICP role operates to construct the OSI Network Service over a defined set of underlying services, performing functions which are necessary to support the uniform appearance of the OSI Connectionless-mode Network Service over a homogeneous or heterogeneous set of interconnected subnetworks. This protocol is defined to accommodate variability where Subnetwork Dependent Convergence Protocols and/or Subnetwork Access Protocols do not provide all of the functions necessary to support the Connectionless-mode Network Service over all or part of the path from one NSAP to another.
このプロトコルはSubnetwork無党派Con両眼転導プロトコル(SNICP)の役割における使用のために意図します。 SNICPの役割を実現させるプロトコルは定義されたセットの基本的なサービスの上でOSI Network Serviceを組み立てるために作動します、均質の、または、種々雑多なセットのインタコネクトされたサブネットワークの上でOSI Connectionless-モードNetwork Serviceの一定の外観をサポートするのに必要な機能を実行して。 このプロトコルは、Subnetwork Dependent Convergenceプロトコル、そして/または、Subnetwork AccessプロトコルがConnectionless-モードがNetwork Serviceであると1NSAPから別のNSAPまで経路のすべてか一部の上サポートするのに必要な機能のすべてを提供しないところに可変性を収容するために定義されます。
As described in ISO 8648, a protocol at the Network Layer may fulfill different roles in different configurations. Although this protocol is designed particularly to be suitable for a SNICP role in the con- text of the internetworking protocol approach to the provision of the Connectionless-mode Network Service, it may also be used to fulfill other roles and may therefore be used in the context of other ap- proaches to subnetwork interconnection.
ISO8648で説明されるように、Network Layerのプロトコルは異なった構成における異なる役割を実現させるかもしれません。 このプロトコルはConnectionless-モードNetwork Serviceの設備へのインターネットワーキングプロトコルアプローチのまやかしテキストにおけるSNICPの役割に適するように特に設計されていますが、それは、また、他の役割を実現させるのに使用されて、したがって、サブネットワークインタコネクトへの他のap- proachesの文脈で使用されるかもしれません。
The specification of this protocol begins with a definition of the underlying service which it assumes. This service is made available by the operation of other Network Layer protocols or through provi- sion of the Data Link Service. The underlying service assumed by this protocol is described in Clause 5.5.
このプロトコルの仕様は基本的にそれが仮定するサービスの定義で始まります。 このサービスを他のNetwork Layerプロトコルの操作かData Link Serviceのprovi- sionを通して利用可能にします。 このプロトコルによって想定された基本的なサービスはClause5.5で説明されます。
5.2 Subsets of the Protocol
5.2 プロトコルの部分集合
Two proper subsets of the full protocol are defined which permit the use of known subnetwork characteristics and are therefore not subnet- work independent.
完全なプロトコルの2つの真部分集合が定義されます(知られているサブネットワークの特性の使用を可能にして、したがって、サブネット仕事独立者ではありません)。
The Inactive Network Layer protocol subset is a null-function subset which can be used when it is known that the source and destination end-systems are connected by a single subnetwork, and when none of the functions performed by the full protocol is required to provide
Inactive Network Layerプロトコル部分集合はソースと目的地エンドシステムに単一のサブネットワークで接されるのを知られていて、完全なプロトコルで実行された機能のいずれも提供するのに必要でないときに使用できるヌル機能部分集合です。
ISO 8473 [Page 12] RFC 994 December 1986
ISO8473[12ページ]RFC994 1986年12月
the Connectionless-mode Network Service between any pair of end- systems.
どんな組のエンドシステムの間のConnectionless-モードNetwork Service。
The Non-segmenting protocol subset permits simplification of the header where it is known that the source and destination end-systems are connected by subnetworks whose service data unit sizes are greater than or equal to a known bound which is large enough so that segmentation is not required. This subset is selected by setting the Segmentation Permitted flag to zero.
Non-区分プロトコル部分集合がユニットが大きさで分けるサービスデータがこと以上であるソースと目的地エンドシステムにサブネットワークで接されるのを知られているヘッダーの簡素化に十分大きい知られているバウンドを可能にするので、分割は必要ではありません。 この部分集合は、Segmentation Permitted旗をゼロに設定することによって、選択されます。
5.3 Addresses and Titles
5.3 アドレスとタイトル
The following Clauses describe the addresses and titles used by this Protocol.
以下のClausesはこのプロトコルによって使用されるアドレスとタイトルについて説明します。
5.3.1 Addresses
5.3.1 アドレス
The Source Address and Destination Address parameters referred to in Clause 7.3 of this International Standard are OSI Network Service Ac- cess Point Addresses. The syntax and semantics of an OSI Network Service Access Point Address are described in a separate document, ISO 8348/AD2, Addendum to the Network Service Definition Covering Network Layer Addressing.
パラメタがこの国際規格のClause7.3で言及したSource AddressとDestination AddressはOSI Network Service Ac課税Point Addressesです。 OSI Network Service Access Point Addressの構文と意味論は別々のドキュメントで説明されます、ISO8348/AD2、Network Service Definition Covering Network Layer AddressingへのAddendum。
The encoding used by this protocol to convey NSAP Addresses shall be the preferred binary encoding specified in ISO 8348/AD2; the entire NSAP address, taken as a whole, is represented explicitly as a string of binary octets. This string is conveyed in its entirety in the ad- dress fields described in Clause 7.3. The rules governing the genera- tion of the preferred binary encoding are described in ISO 8348/AD2.
このプロトコルによって使用される、NSAP Addressesを運ぶコード化はISO8348/AD2で指定された都合のよい2進のコード化になるでしょう。 全体で取られた全体のNSAPアドレスは一連の2進の八重奏として明らかに表されます。 このストリングはClause7.3で説明された広告ドレス分野を全体として運ばれます。 都合のよい2進のコード化の類概念tionを治める規則はISO8348/AD2で説明されます。
5.3.2 Network-entity Titles
5.3.2 ネットワーク実体タイトル
A network-entity title is an identifier for a network-entity in an endsystem or intermediate-system. Network-entity titles are allocated from the same name space as NSAP addresses, and the determination of whether an address is an NSAP address or a network-entity title depends on the context in which the address is interpreted. The en- tries in the Source Routing and Recording of Route parameters defined in Clauses 7.5.4 and 7.5.5 are network-entity titles. The Source Ad- dress and Destination Address parameters in the Error Report PDU de- fined in Clause 7.9.1.2 are also network-entity titles.
ネットワーク実体タイトルはendsystemか中間システムのネットワーク実体のための識別子です。 NSAPアドレスと同じ名前スペースからネットワーク実体タイトルを割り当てます、そして、アドレスがNSAPアドレスであるかどうかに関する決断かネットワーク実体タイトルがアドレスが解釈される文脈によります。 アンはRouteパラメタのルート設定とRecordingがClauses7.5.4で定義したSourceで試みます、そして、7.5に、.5はネットワーク実体タイトルです。 Clauseで反-罰金を課されたError Report PDUのSource AdドレスとDestination Addressパラメタ、7.9、.1、.2、ネットワーク実体タイトルもそうです。
The encoding used by this protocol to convey network-entity titles shall also be the preferred binary encoding; again, the entire network-entity title, taken as a whole, is represented explicitly as a string of binary octets. This string is conveyed in its entirety in the fields described in Clauses 7.5.4, 7.5.5, and 7.9.1.2.
また、このプロトコルによって使用される、ネットワーク実体タイトルを伝えるコード化は都合のよい2進のコード化でしょう。 一方、全体で取られた全体のネットワーク実体タイトルは一連の2進の八重奏として明らかに表されます。 そして、このストリングがClausesで説明された分野を全体として運ばれる、7.5、.4、7.5 .5、7.9 .1 .2。
ISO 8473 [Page 13] RFC 994 December 1986
ISO8473[13ページ]RFC994 1986年12月
5.4 Service Provided by the Network Layer
5.4 ネットワーク層によって提供されたサービス
The service provided by this protocol is the Connectionless-mode Net- work Service described in ISO 8348/AD1, Addendum to the Network Ser- vice Definition Covering Connectionless-mode Transmission. The Net- work Service primitives provided are summarized in Table 1:
このプロトコルによって提供されたサービスはISO8348/AD1(Network Ser副のDefinition Covering Connectionless-モードTransmissionへのAddendum)で説明されたConnectionless-モードネット仕事Serviceです。 基関数が提供したネット仕事ServiceはTable1にまとめられます:
_____________________________________________________________
| PRIMITIVES PARAMETERS |
|____________________________________________________________ |
| N_UNITDATA .Request | N_Source_Address, |
| .Indication | N_Destination_Address, |
| | N_Quality_of_Service, |
| | N_Userdata |
|_________________________________|___________________________|
_____________________________________________________________ | 基関数パラメタ| |____________________________________________________________ | | N_UNITDATA .Request| N_ソース_アドレス| | .Indication| N_送付先_アドレス| | | _サービスのN_品質_| | | N_Userdata| |_________________________________|___________________________|
Table 1: Service Primitives for Underlying Service
テーブル1: 基本的なサービスのためのサービス基関数
The Addendum to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1) states that the max- imum size of a connectionless-mode Network-service-data-unit (NSDU) is limited to 64512 octets.
Network Service Definition Covering Connectionless-モードTransmission(ISO8348/AD1)へのAddendumは、コネクションレスなモードNetworkサービスデータ単位(NSDU)の最大imumサイズが64512の八重奏に制限されると述べます。
5.5 Underlying Service Assumed by the Protocol
5.5 プロトコルによって想定された基本的なサービス
The underlying service required to support this protocol is defined by the following primitives:
このプロトコルをサポートするのに必要である基本的なサービスは以下の基関数によって定義されます:
_____________________________________________________________
| PRIMITIVES PARAMETERS |
|____________________________________________________________ |
| SN_UNITDATA .Request | SN_Source_Address, |
| .Indication | SN_Destination_Address, |
| | SN_Quality_of_Service, |
| | SN_Userdata |
|_________________________________|___________________________|
_____________________________________________________________ | 基関数パラメタ| |____________________________________________________________ | | SN_UNITDATA .Request| SN_ソース_アドレス| | .Indication| SN_送付先_アドレス| | | _サービスのSN_品質_| | | SN_Userdata| |_________________________________|___________________________|
Table 2: Service Primitives for Underlying Service
テーブル2: 基本的なサービスのためのサービス基関数
Note:
These service primitives are used to describe the abstract interface
which exists between the ISO 8473 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.
以下に注意してください。 これらのサービス基関数は、ISO8473プロトコルマシンと基本的な本当のサブネットワークの間に存在する抽象的なインタフェースか必要な基本的なサービスを提供するために本当のサブネットワークか本当のデータ・リンクの上で作動するSubnetwork Dependent Convergence Functionについて説明するのに使用されます。
ISO 8473 [Page 14] RFC 994 December 1986
ISO8473[14ページ]RFC994 1986年12月
5.5.1 Subnetwork Points of Attachment
5.5.1 サブネットワークポイントの付属
The source and destination addresses specify the points of attachment to a public or private subnetwork(s) involved in the transmission. Subnetwork Point of Attachment addresses (SNPAs) are defined by each individual subnetwork authority.
ソースと送付先アドレスはトランスミッションにかかわる公共の、または、個人的なサブネットワークへの付属のポイントを指定します。 Attachmentアドレス(SNPAs)のサブネットワークPointはそれぞれの個々のサブネットワーク権威によって定義されます。
The syntax and semantics of SNPAs are not defined in this Standard.
SNPAsの構文と意味論はこのStandardで定義されません。
5.5.2 Subnetwork Quality of Service
5.5.2 サブネットワークサービスの質
Subnetwork Quality of Service describes aspects of an underlying connectionless-mode service which are attributable solely to the underlying service.
ServiceのサブネットワークQualityは唯一基本的なサービスに起因する基本的にコネクションレスなモードサービスの局面について説明します。
Associated with each connectionless-mode transmission, certain meas- ures of Quality of Service are requested when the primitive action is initiated. These requested measures (or parameter values and op- tions) are based on a priori knowledge of the service(s) made avail- able to it by the subnetwork. Knowledge of the nature and type of service available is typically obtained prior to an invocation of the underlying connectionless-mode service.
原始の動きが開始されるとき、各コネクションレス型伝送に関連していて、ServiceのQualityのあるmeas- uresは要求されます。 これらは、測定(または、パラメタ値とオプアートtions)が(s)がサブネットワークでそれにできる利益をしたサービスに関する先験的な知識に基づいているよう要求しました。 基本的にコネクションレスなモードサービスの実施の前に手があいているサービスの自然とタイプに関する知識を通常得ます。
The Quality of Service parameters identified for the underlying connectionless-mode service may in some circumstances be directly derivable from or mappable onto those identified in the Connectionless-mode Network Service. The following parameters as de- fined in ISO 8348/AD1, Addendum to the Network Service Definition Covering Connectionlessmode Transmission, may be employed:
基本的なコネクションレスなモードサービスのために特定されたServiceパラメタのQualityはそれらに直接誘導できるかmappableな特定されたコネがConnectionless-モードNetwork Serviceであったならいくつかの事情でそうするかもしれません。 ISO8348/AD1で反-罰金を課される以下のパラメタ(Network Service Definition Covering Connectionlessmode TransmissionへのAddendum)は使われるかもしれません:
(a) transit delay;
(a) トランジット遅れ。
(b) protection against unauthorized access;
不正アクセスに対する(b)保護。
(c) cost determinants;
(c) 決定因かかってください。
(d) priority; and
(d)優先権。 そして
(e) residual error probability.
(e)残差エラー確率。
Note:
For those subnetworks which do not inherently provide Quality of
Service as a parameter when the primitive action is initiated, it
is a local matter as to how the semantics of the service requested
might be preserved. In particular, there may be instances in which
the Quality of Service requested cannot be maintained. In such
circumstances, an attempt shall be made to deliver the protocol
data unit at whatever Quality of Service is available.
以下に注意してください。 原始の動きが本来開始されるときパラメタとしてServiceのQualityを提供しないそれらのサブネットワークに関しては、要求されたサービスの意味論がどう保存されるかもしれないかに関してそれは地域にかかわる事柄です。 特に、要求されたServiceのQualityを維持できない例があるかもしれません。 そのような事情では、試みはプロトコルデータ単位が何でも届けさせられて、ServiceのQualityが利用可能であるということでしょう。
ISO 8473 [Page 15] RFC 994 December 1986
ISO8473[15ページ]RFC994 1986年12月
5.5.3 Subnetwork User Data
5.5.3 サブネットワーク利用者データ
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 assumed by the CLNP is required to support a service data unit size of at least 512 octets.
CLNPによって想定された基本的なサービスが、少なくとも512の八重奏のサービスデータ単位サイズを支持するのに必要です。
If the minimum service data unit sizes supported by all of the sub- networks involved in the transmission of a particular PDU are known to be large enough that segmentation is not required, then the Non- segmenting protocol subset may be used.
サイズが特定のPDUのトランスミッションにかかわるサブネットワークのすべてで支持した最小のサービスデータ単位が分割は必要でないほど大きいのが知られているなら、Non区分プロトコル部分集合が使用されるかもしれません。
5.5.4 Subnetwork Dependent Convergence Functions
5.5.4 サブネットワークの依存する集合機能
Subnetwork Dependent Convergence Functions may be performed to pro- vide an underlying connectionless-mode service in the case where a real subnetwork does not inherently provide the connectionless-mode service assumed by the protocol. If a subnetwork inherently provides a connection-mode service, a Subnetwork Dependent Convergence Func- tion provides a mapping into the required underlying service. Sub- network Dependent Convergence Functions may also be required in those cases where functions assumed from the underlying service are not performed. In some cases, this may require the operation of an ex- plicit protocol (i.e., a protocol involving explicit exchanges of protocol control information between peer network-entities) in the Subnetwork Dependent Convergence Protocol (SNDCP) role. However, there may also be cases where the functionality required to fulfill the SNDCP role consists simply of a set of rules for manipulating the underlying service.
サブネットワークDependent Convergence Functionsが実行されるかもしれない、親、参照、本当のサブネットワークが本来プロトコルによって想定されたコネクションレスなモードサービスを提供しない場合における基本的なコネクションレスなモードサービス。 サブネットワークが本来接続モードサービスを提供するなら、Subnetwork Dependent Convergence Func- tionは必要な基本的なサービスにマッピングを提供します。 また、サブネットワークDependent Convergence Functionsが基本的なサービスから想定された機能が実行されないそれらの場合で必要であるかもしれません。 いくつかの場合、これはSubnetwork Dependent Convergenceプロトコル(SNDCP)の役割における、元のplicitプロトコル(すなわち、同輩ネットワーク実体の間のプロトコル制御情報の明白な交換にかかわるプロトコル)の操作を必要とするかもしれません。 しかしながら、また、ケースがSNDCPの役割を実現させるのに必要である機能性が基本的なサービスを操るための単に1セットの規則から成るところにあるかもしれません。
5.6 Service Assumed from Local Environment
5.6 地方の環境から想定されたサービス
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探索で原始的に要求された遅れが経過したのを示します。
ISO 8473 [Page 16] RFC 994 December 1986
ISO8473[16ページ]RFC994 1986年12月
The S--TIMER Cancel primitive is an indication to the local environ- 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.
S--TIMERキャンセル原始的であるのは、地方への指示が取り消された状態で指定されたタイマがそうであるべきであるmentを取り巻くということです。 添字パラメタが指定されないなら、指定された名前があるすべてのタイマが取り消されます。 さもなければ、名と添字のタイマは取り消されます。 タイマが全く指定されたパラメタに対応していないなら、地方の環境は行動を全く取りません。
The parameters of the S--TIMER service primitives are specified in Table 3.
Sのパラメタ--TIMERサービス基関数はTable3で指定されます。
__________________________________________________
| PRIMITIVES PARAMETERS |
|_________________________________________________|
| S--TIMER .Request | S-Time, |
| | S-Name, |
| | S-Subscript |
| | |
| .Response | S-Name, |
| | S-Subscript |
|___________________________|_____________________|
__________________________________________________ | 基関数パラメタ| |_________________________________________________| | S--タイマ.Request| S-時間| | | S-名前| | | S-添字| | | | | .Response| S-名前| | | S-添字| |___________________________|_____________________|
Table 3: Timer Primitives
テーブル3: タイマ基関数
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タイマをけなすために値を指定します。 取られた名前と添字、-、より多くの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で説明されたどんな派生も義務的ではありません。 タイマ値はServiceの要求されたQualityを提供できるように選ばれるべきです、知られている基本的にサービスの特性を考えて。
ISO 8473 [Page 17] RFC 994 December 1986
ISO8473[17ページ]RFC994 1986年12月
SECTION TWO. SPECIFICATION OF THE PROTOCOL
セクションTWO。 プロトコルの仕様
6 Protocol Functions
6 プロトコル機能
This Clause describes the functions performed as part of the Proto- col.
このClauseはプロトあん部の一部として実行された機能について説明します。
Not all of the functions must be performed by every implementation. Clause 6.17 specifies which functions may be omitted, and the correct behavior when requested functions are not implemented.
あらゆる実現で機能のすべてを実行しなければならないというわけではありません。 第6.17節はどの機能が省略されるかもしれないか、そして、要求された機能が実行されないときの正しい振舞いを指定します。
6.1 PDU Composition Function
6.1 PDU構成機能
This function is responsible for the construction of a protocol data unit according to the rules governing the encoding of PDUs given in Clause 7. Protocol Control Information required for delivering the data unit to its destination is determined from current state and lo- cal information and from the parameters associated with the N- UNITDATA Request.
Clause7で与えられているPDUsのコード化を治める規則に従って、この機能はプロトコルデータ単位の工事に原因となります。 データ単位を送付先に届けるのに必要であるプロトコルControl情報は情報とN UNITDATA Requestに関連しているパラメタからの現状と最低気温calから決定しています。
Network Protocol Address Information (NPAI) for the Source Address and Destination Address fields of the PDU header is derived from the NS-Source-Address and NS-Destination-Address parameters. The NS- Destination-Address and NS-Quality-of-Service parameters, together with current state and local information, are used to determine which optional functions are to be selected. User data passed from the Net- work Service User (NS-Userdata) forms the Data field of the protocol data unit.
NSソースアドレスとNS送付先アドレスパラメタからPDUヘッダーのSource AddressとDestination Address分野のためのネットワークプロトコルAddress情報(NPAI)を得ます。 NS送付先アドレスとサービスのNS品質パラメタは、選択されるために任意の機能がどれであるかを決定するのに現状とローカルの情報と共に使用されます。 ネット仕事Service User(NS-Userdata)から通過された利用者データはプロトコルデータ単位のData分野を形成します。
During the composition of the protocol data unit, a Data Unit Iden- tifier is assigned to distinguish this request to transmit NS- Userdata to a particular destination NS User from other such re- quests. The originator of the PDU must choose the Data Unit Identif- ier so that it remains unique (for this Source and Destination ad- dress pair) for the maximum lifetime of the Initial PDU in the net- work; this rule applies for any PDUs derived from the Initial PDU as a result of the application of the Segmentation Function (see Clause 6.7). Derived PDUs are considered to correspond to the same Initial PDU, and hence the same N-UNITDATA Request, if they have the same Source Address, Destination Address, and Data Unit Identifier.
プロトコルデータ単位の構成の間、Data Unit Iden- tifierは、NS- Userdataを他のそのような再探索から特定の目的地NS Userに伝えるというこの要求を区別するために割り当てられます。 PDUの創始者がData Unit Identif- ierを選ばなければならないので、Initial PDUの最大の生涯、ユニークな(このSourceとDestination広告が組に服を着せるので)ネットの仕事でままです。 この規則はSegmentation Functionのアプリケーションの結果、Initial PDUから得られたどんなPDUsにも申し込みます(Clause6.7を見てください)。 派生しているPDUsが同じInitial PDU、およびしたがって、同じN-UNITDATA Requestに相当すると考えられます、彼らが同じSource Address、Destination Address、およびData Unit Identifierを持っているなら。
The Data Unit Identifier is also available for ancillary functions such as error reporting (see Clause 6.10).
また、Data Unit Identifierも誤り報告などの補助的機能に利用可能です(Clause6.10を見てください)。
The total length of the PDU in octets is determined by the originator and placed in the Total Length field of the PDU header. This field is not changed in any Derived PDU for the lifetime of the protocol data unit.
八重奏における、PDUの全長は、創始者によって決定されて、PDUヘッダーのTotal Length分野に置かれます。 この分野はプロトコルデータ単位の生涯のためのどんなDerived PDUでも変えられません。
ISO 8473 [Page 18] RFC 994 December 1986
ISO8473[18ページ]RFC994 1986年12月
When the Non-segmenting protocol subset is employed, neither the To- tal Length field nor the Data Unit Identifier field is present. The rules governing the PDU composition function are modified in this case as follows. During the composition of the protocol data unit, the total length of the PDU in octets is determined by the originator and placed in the Segment Length field of the PDU header. This field is not changed for the lifetime of the PDU. No Data Unit Identifica- tion is provided.
Non-区分プロトコル部分集合が採用しているとき、To- tal Length分野もData Unit Identifier分野も存在していません。 PDU構成機能を決定する規則はこの場合以下の通り変更されます。 プロトコルデータ単位の構成の間、八重奏における、PDUの全長は、創始者によって決定されて、PDUヘッダーのSegment Length分野に置かれます。 この分野はPDUの生涯に変わりません。 Data Unit Identifica- tionを全く提供しません。
6.2 PDU Decomposition Function
6.2 PDU分解機能
This function is responsible for removing the Protocol Control Infor- mation from the protocol data unit. During this process, information pertinent to the generation of the N-UNITDATA Indication is deter- mined as follows. The NS-Source-Address and NS-Destination-Address parameters of the N-UNITDATA Indication are recovered from the NPAI in the Source and Destination Address fields of the PDU header. The data field of the PDU received is reserved until all segments of the original service data unit have been received; collectively, these form the NS-Userdata parameter of the N-UNITDATA Indication. Infor- mation relating to the Quality of Service provided during the transmission of the PDU is determined from the Quality of Service and other information contained in the Options Part of the PDU header. This information constitutes the NS-Quality-of-Service parameter of the N-UNITDATA Indication.
この機能はプロトコルデータ単位からプロトコルControl Infor- mationを取り外すのに原因となります。 この過程の間、N-UNITDATA Indicationの世代に適切な情報はそうです。以下の通り採掘されて、思いとどまらせます。 PDUヘッダーのSourceとDestination Address分野でN-UNITDATA IndicationのNSソースアドレスとNS送付先アドレスパラメタからNPAIを取り戻します。 PDUの分野が受け取ったデータはオリジナルのサービスデータ単位のすべてのセグメントを受け取るまで予約されています。 これらはN-UNITDATA IndicationのNS-Userdataパラメタをまとめて、形成します。 PDUのトランスミッションの間に提供されたServiceのQualityに関連するInfor- mationはPDUヘッダーのOptions Partに含まれたServiceと他の情報のQualityから断固としています。 この情報はN-UNITDATA IndicationのサービスのNS品質パラメタを構成します。
6.3 Header Format Analysis Function
6.3 ヘッダー形式分析機能
This function determines whether the full protocol described in this Standard is employed, or one of the defined proper subsets thereof. If the protocol data unit has a Network Layer Protocol Identifier in- dicating that this is a standard version of the Protocol, this func- tion determines whether a received PDU has reached its destination, using the Destination Address provided in the PDU. If the Destination Address provided in the PDU identifies an NSAP served by this network-entity, then the PDU has reached its destination; if not, it must be forwarded.
この機能はこのStandardで説明された完全なプロトコルが採用しているか、そして、それの定義された真部分集合の1つを決定します。 プロトコルデータ単位がそれをdicatingしながら中にNetwork LayerプロトコルIdentifierを持っているなら、これはプロトコルの標準版です、と容認されたPDUが目的地に到着したか否かに関係なく、このfunc- tionが決定します、PDUに提供されたDestination Addressを使用して。 PDUに提供されたDestination Addressがこのネットワーク実体によって役立たれるNSAPを特定するなら、PDUは目的地に到着しました。 そうでなければ、それを進めなければなりません。
If the protocol data unit has a Network Layer Protocol Identifier in- dicating that the Inactive Network Layer Protocol subset is in use, then no further analysis of the PDU header is required. The network- entity in this case determines that either the Subnetwork Point of Attachment address encoded as network protocol address information in the supporting subnetwork protocol corresponds directly to an NSAP address serviced by this network-entity or that an error has oc- curred. If the subnetwork protocol data unit has been delivered correctly, then the PDU may be decomposed according to the procedures described for that particular subnetwork protocol.
プロトコルデータ単位がそれをdicatingしながら中にNetwork LayerプロトコルIdentifierを持っているならInactive Network Layerプロトコル部分集合が使用中である、そして、PDUヘッダーのさらなる分析は全く必要ではありません。 ネットワーク実体はこの場合サブネットワークプロトコルが直接このネットワーク実体によって修理されたNSAPアドレスに対応しているか、または誤りにはoc- curredがあるという支持におけるネットワーク・プロトコルアドレス情報としてコード化されたAttachmentアドレスのSubnetwork Pointを決定そんなにのどちらか。 正しくサブネットワークプロトコルデータ単位を届けたなら、その特定のサブネットワークプロトコルのために説明された手順によると、PDUを分解するかもしれません。
ISO 8473 [Page 19] RFC 994 December 1986
ISO8473[19ページ]RFC994 1986年12月
6.4 PDU Lifetime Control Function
6.4 PDU生涯コントロール機能
This function is used to enforce the maximum PDU lifetime. It is closely associated with the Header Format Analysis function. This function determines whether a PDU received may be forwarded or wheth- er its assigned lifetime has expired, in which case it must be dis- carded.
この機能は、最大のPDU生涯を実施するのに使用されます。 それは密接にHeader Format Analysis機能に関連づけられます。 この機能が受け取られたPDUを進めるかもしれないか、そして、whethを決定する、えー、割り当てられた寿命は期限が切れて、その場合、不-それをcardedしなければなりません。
The operation of the PDU Lifetime Control function depends upon the Lifetime field in the PDU header. This field contains, at any time, the remaining lifetime of the PDU (represented in units of 500 mil- liseconds). The Lifetime of the Initial PDU is determined by the ori- ginating network-entity, and placed in the Lifetime field of the PDU. When the Segmentation function is applied to a PDU, the value of the Lifetime field of the Initial PDU is copied into all of the Derived PDUs.
PDU Lifetime Control機能の操作はPDUヘッダーのLifetime分野に依存します。 この分野はいつでも、PDU(ユニットの500ミルlisecondsでは、表される)の残っている生涯を含みます。 Initial PDUのLifetimeはori- ginatingネットワーク実体で決定して、PDUのLifetime分野に置かれます。 Segmentation機能がPDUに適用されるとき、Initial PDUのLifetime分野の値はDerived PDUsのすべてにコピーされます。
The Lifetime of the PDU is decremented by every network-entity which processes the PDU. When a network-entity processes a PDU, it decre- ments the PDU Lifetime by at least one. The value of the PDU Life- time field shall be decremented by more than one if the sum of:
PDUのLifetimeはPDUを処理するあらゆるネットワーク実体で減少します。 aであるときに、ネットワーク実体はPDUを処理して、それはdecre- mentsです。少なくとも1のPDU Lifetime。 合計であるなら、PDU Life時間分野の値は1つ以上以上減少するものとします:
1. the transit delay in the underlying service from which the PDU
was received; and
1. PDUが受け取られた基本的なサービスのトランジット遅れ。 そして
2. the delay within the system processing the PDU
2. PDUを処理するシステムの中の遅れ
exceeds or is estimated to exceed 500 milliseconds. In this case, the lifetime field should be decremented by one for each additional 500 milliseconds of delay. The determination of delay need not be precise, but where a precise value cannot be ascertained, the value used shall be an overestimate, not an underestimate.
超えているか、または500人のミリセカンドを超えるために見積もられています。 この場合、生涯分野は各追加500人のミリセカンドの遅れあたり1つ減少するべきです。 遅れの決断は正確である必要はありませんが、正確な値を確かめることができないところでは、使用される値は過小ではなく、過大評価でしょう。
If the Lifetime field reaches a value of zero before the PDU is delivered to the destination, the PDU must be discarded. The Error Reporting function shall be invoked as described in Clause 6.10, Er- ror Reporting Function, and may result in the generation of an Error Report PDU. It is a local matter whether the destination network- entity performs the Lifetime Control function.
PDUを送付先に届ける前にLifetime分野がゼロの値に達するなら、PDUを捨てなければなりません。 Error Reporting機能は、Clause6.10、Er- ror Reporting Functionで説明されるように呼び出されて、Error Report PDUの世代で結果として生じるかもしれません。 目的地が実体をネットワークでつなぐかどうかがLifetime Control機能を実行するのは、地域にかかわる事柄です。
6.5 Route PDU Function
6.5 ルートPDUは機能します。
This function determines the network-entity to which a protocol data unit should be forwarded and the underlying service that must be used to reach that network-entity, using the Destination Address and the total length of the PDU. Where segmentation is required, the Route PDU function further determines over which underlying service Derived PDUs/segments must be sent in order to reach that network-entity. The results of the Route PDU function are passed to the Forward PDU func- tion (along with the PDU itself) for further processing. Selection of the underlying service that must be used to reach the "next" sys-
この機能は、プロトコルデータ単位が送られるべきであるネットワーク実体と利用しなければならない基本的なサービスがそのネットワーク実体に達することを決定します、PDUのDestination Addressと全長を使用して。 Route PDU機能が、どの基本的なサービスの上で分割が必要であることをさらに決定するところに、そのネットワーク実体に達するようにDerived PDUs/セグメントを送らなければなりません。 Route PDU機能の結果はさらなる処理のためにForward PDU func- tion(PDU自身に伴う)に通過されます。 基本的に「次」のsysに達するのに利用しなければならないサービスの選択
ISO 8473 [Page 20] RFC 994 December 1986
ISO8473[20ページ]RFC994 1986年12月
tem in the route is initially influenced by the NS-Quality-of- Ser- vice parameter of the N-UNITDATA Request, which specifies the QoS re- quested by the sending NS User. Whether this QoS is to be provided directly by the CLNP, through the selection of the Quality of Service Maintenance parameter and other optional parameters, or through the QoS facilities offered by each of the underlying services is deter- mined prior to invocation of the Forward PDU function. Route selec- tion by intermediate systems may subsequently be influenced by the values of the Quality of Service Maintenance parameter (if present), and other optional parameters (if present).
-N-UNITDATA RequestのSer副のパラメタ、QoSを指定するものが再探索されました。ルートによるtemが初めはNS-品質によって影響を及ぼされる、-、送付NS User。 このQoSが直接CLNPによって提供されることになっているか否かに関係なく、Service Maintenanceパラメタと他の任意のパラメタのQualityの選択を通して、または、それぞれの基本的さで提供されたQoS施設を通して、サービスは提供されることになっています。Forward PDU機能の実施の前に採掘されて、思いとどまらせます。 中間システムによるルートselec- tionは次に、Service Maintenanceパラメタ(存在しているなら)、および他の任意のパラメタのQualityの値によって影響を及ぼされるかもしれません(存在しているなら)。
6.6 Forward PDU Function
6.6 前方に、PDUは機能します。
This function issues an SN-UNITDATA Request primitive (see Clause 5.5), supplying the subnetwork or SNDCF identified by the Route PDU function with the protocol data unit as user data to be transmitted, the address information required by that subnetwork or SNDCF to iden- tify the "next" system within the subnetwork-specific addressing domain (this may be an intermediate-system or the destination end- system), and Quality of Service constraints (if any) to be considered in the processing of the user data.
この機能は原始的にSN-UNITDATA Requestを発行します(Clause5.5を見てください)、とサブネットワークを供給するか、SNDCFが伝えられるために利用者データとしてプロトコルデータ単位があるRoute PDU機能で特定しました、サブネットワーク特有のアドレス指定領域(これは中間システムであるかもしれませんか目的地終わりはシステムである)の中の「次」のシステム、およびService規制(もしあれば)のQualityが考えられる情報がそのサブネットワークかSNDCFで利用者データの処理でiden- tifyに必要であったアドレス。
When the PDU to be forwarded is longer than the maximum service data user size provided by the underlying service, the Segmentation func- tion is applied (See Clause 6.7, which follows).
進められるべきPDUが基本的なサービスで提供された最大のサービスデータユーザサイズより長いときに、Segmentation func- tionは適用されています(続くClause6.7を見てください)。
6.7 Segmentation Function
6.7 分割機能
Segmentation is performed when the size of the protocol data unit is greater than the maximum service data unit size supported by the underlying service to be used to transmit the PDU.
プロトコルデータ単位のサイズがサイズがPDUを伝えるのに使用されるために基本的なサービスで支持した最大のサービスデータ単位より大きいときに、分割は実行されます。
Segmentation consists of composing two or more new PDUs (Derived PDUs) from the PDU received. The PDU received may be the Initial PDU, or it may be a Derived PDU. All of the header information from the PDU to be segmented, with the exception of the segment length and checksum fields of the fixed part, and the segment offset of the seg- mentation part, is duplicated in each Derived PDU, including all of the address part, the data unit identifier and total length of the segmentation part, and the options part (if present).
分割はPDUからの2新しいPDUs(PDUsを引き出す)が受けた構成から成ります。 受け取られたPDUはInitial PDUであるかもしれませんかそれがDerived PDUであるかもしれません。 固定部分のセグメントの長さとチェックサム分野、およびseg精神作用部分のセグメントオフセットを除いて、区分されるべきPDUからのヘッダー情報のすべてが各Derived PDUにコピーされます、アドレス部、データ単位識別子、分割部分の全長、およびオプション一部のすべてを含んでいて(存在しているなら)。
Note:
The rules for forwarding and segmentation guarantee that the
header length is the same for all segments (Derived PDUs) of
the Initial PDU, and is the same as the header length of the
Initial PDU. The size of a PDU header will not change due to
operation of any protocol function.
以下に注意してください。 推進と分割のための規則はヘッダ長がInitial PDUのすべてのセグメント(PDUsを引き出す)に同じであり、Initial PDUのヘッダ長と同じであることを保証します。 PDUヘッダーのサイズはどんなプロトコル機能の操作のためも変化しないでしょう。
The user data encapsulated within the PDU received are divided such that the Derived PDUs satisfy the size requirements of the user data parameter field of the primitive used to access the underlying ser-
受け取られたPDUの中で要約された利用者データが分割されているので、Derived PDUsは基本的なserにアクセスするのに使用される原始の利用者データパラメタ分野のサイズ要件を満たします。
ISO 8473 [Page 21] RFC 994 December 1986
ISO8473[21ページ]RFC994 1986年12月
vice.
悪。
Derived PDUs are identified as being from the same Initial PDU by means of
による派生しているPDUsが同じInitial PDUからあるとして特定される。
(a) the source address,
(a) ソースアドレス
(b) the destination address, and
そして(b) 送付先アドレス。
(c) the data unit identifier.
(c) データ単位識別子。
Segmentation shall not result in the generation of a Derived PDU con- taining less than eight (8) octets of user data.
分割は、利用者データの8つ未満の(8)八重奏をtainingしながら、Derived PDUまやかしの世代で結果として生じないものとします。
The following fields of the PDU header are used in conjunction with the Segmentation function:
PDUヘッダーの以下の分野はSegmentation機能に関連して使用されます:
(a) Segment Offset --- identifies, with respect to the start
of the Initial PDU, the octet at which the segment begins;
(a)セグメントオフセット--- Initial PDUの始まり、セグメントが始まる八重奏に関して、特定します。
(b) Segment Length --- specifies the number of octets in the
Derived PDU, including both header and data;
(b) セグメントの長さ--- ヘッダーとデータの両方を含むDerived PDUの八重奏の数を指定します。
(c) More Segments Flag --- is set to one if this Derived PDU
does not contain, as its final octet of user data, the final
octet of the Initial PDU; and
(c) より多くのセグメント旗--- このDerived PDUが利用者データの最終的な八重奏としてInitial PDUの最終的な八重奏を含んでいないなら、1つに設定されます。 そして
(d) Total Length --- specifies the entire length of the Initial
PDU, including both header and data.
(d) 全長--- ヘッダーとデータの両方を含むInitial PDUの全長を指定します。
Derived PDUs may be further segmented without constraining the rout- ing of the individual Derived PDUs. The Segmentation Permitted flag is set to one to indicate that segmentation is permitted. If the Ini- tial PDU is not to be segmented at any point during its lifetime in the network, the flag is set to zero by the source network-entity. The setting of the Segmentation Permitted flag cannot be changed by any other network-entity for the lifetime of the Initial PDU and any Derived PDUs.
個々のDerived PDUsの総崩れするingを抑制しないで、派生しているPDUsはさらに区分されるかもしれません。 1つにSegmentation Permitted旗が、分割が受入れられるのを示すように設定されます。 生涯、Ini- tial PDUが任意な点でネットワークで区分されないつもりであるなら、旗はソースネットワーク実体によってゼロに設定されます。 Initial PDUの生涯、どんなDerived PDUsのためにもいかなる他のネットワーク実体でもSegmentation Permitted旗の設定を変えることができません。
6.8 Reassembly Function
6.8 Reassemblyは機能します。
The Reassembly function reconstructs the Initial PDU from the Derived PDUs generated by the operation of the Segmentation Function on the Initial PDU (and, recursively, on subsequent Derived PDUs). A bound on the time during which segments (Derived PDUs) of an Initial PDU will be held at a reassembly point before being discarded is provid- ed, so that reassembly resources may be released when it is no longer expected that any outstanding segments of the Initial PDU will arrive at the reassembly point. Upon reception of a Derived PDU, a reassem- bly timer is initiated with a value which indicates the amount of
Reassembly機能がInitial PDUにおけるSegmentation Functionの操作で発生するDerived PDUsからInitial PDUを再建する、(再帰的なその後のDerived PDUs、) 捨てられる前にInitial PDUのセグメント(PDUsを引き出す)が再アセンブリポイントで維持される時のバウンドはprovid教育です、もうInitial PDUのどんな傑出しているセグメントも再アセンブリポイントに到着しないと予想されるとき、再アセンブリリソースを発表できるように。 Derived PDUのレセプションでは、reassem- blyタイマは量を示す値で開始されます。
ISO 8473 [Page 22] RFC 994 December 1986
ISO8473[22ページ]RFC994 1986年12月
time which must elapse before any outstanding segments of the Initial PDU shall be assumed to be lost. When this timer expires, all seg- ments (Derived PDUs) of the Initial PDU held at the reassembly point are discarded, the resources allocated for those segments are freed, and if selected, an Error Report is generated (see Clause 6.10). While the exact relationship between reassembly lifetime and PDU lifetime is a local matter, the Reassembly Function must preserve the intent of the PDU lifetime. Consequently, the reassembly function must discard PDUs whose lifetime would otherwise have expired had they not been under the control of the reassembly function.
Initial PDUのどんな傑出しているセグメントの前にも経過しなければならない時間が失われると思われるものとします。 このタイマが期限が切れるとき、再アセンブリポイントで持たれていたInitial PDUのすべてのseg- ments(PDUsを引き出す)が捨てられます、そして、それらのセグメントのために割り当てられたリソースは解放されます、そして、選択されるなら、Error Reportは発生します(Clause6.10を見てください)。 再アセンブリ生涯とPDU生涯との正確な関係は地域にかかわる事柄ですが、Reassembly FunctionはPDU生涯の意図を保存しなければなりません。 その結果、再アセンブリ機能はそうでなければ彼らが再アセンブリ機能のコントロールの下にいなかったなら寿命が期限が切れたPDUsを捨てなければなりません。
Note:
以下に注意してください。
1. Methods of bounding reassembly lifetime are discussed in
Annex B.
1. Annex Bで制限の再アセンブリ生涯の方法について議論します。
2. The Segmentation and Reassembly functions are intended to
be used in such a way that the fewest possible segments are
generated at each segmentation point and reassembly takes
place at the final destination of a PDU. However, other
schemes which
2. SegmentationとReassembly機能によって最もわずかな可能なセグメントしかそれぞれの分割ポイントで発生しないような方法で使用されることを意図して、再アセンブリはPDUの最終的な目的地で行われます。 しかしながら、他はどれを計画するか。
(a) interact with the routing algorithm to favor paths on
which fewer segments are generated;
(a) ルーティング・アルゴリズムと対話して、より少ないセグメントが発生する経路を支持してください。
(b) generate more segments than absolutely required in
order to avoid additional segmentation at some subsequent
point; or
(b) 何らかのその後のポイントで追加分割を避けるために絶対に必要とされるより多くのセグメントを発生させてください。 または
(c) allow partial or full reassembly at some intermediate
point along the route
(c) ルートに沿った何らかの中間的ポイントに部分的であるか完全な再アセンブリを許容してください。
are not precluded. The information necessary to enable the
use of one of these alternative strategies may be made
available through the operation of a Network Layer Management
function or by other means.
排除されません。 Network Layer Management機能の操作を通して、または、他の手段でこれらの代替の戦略の1つの使用を可能にするのに必要な情報を利用可能にするかもしれません。
3. The originator of the Initial PDU determines the value of the
Segmentation Permitted flag in the Initial PDU and all Derived
PDUs (if any). Partial or full reassembly in an intermediate
system (Note 2 (c) above) cannot change this value in the
Initial PDU or any PDU derived from it, and cannot therefore
add or remove the segmentation part of the header.
3. Initial PDUの創始者はInitial PDUとすべてのDerived PDUs(もしあれば)のSegmentation Permitted旗の値を決定します。 したがって、中間システム(上の2(c)に注意する)の部分的であるか完全な再アセンブリはヘッダーの分割一部をそれから得られたInitial PDUかどんなPDUでもこの値を変えることができないで、加えることができませんし、取り除くことができません。
6.9 Discard PDU Function
6.9はPDU機能を捨てます。
This function performs all of the actions necessary to free the resources reserved by the network-entity when any of the following situations is encountered (Note: the list is not exhaustive):
この機能は以下の状況のどれかが遭遇するとき(注意: リストは徹底的ではありません)ネットワーク実体によって予約されたリソースを解放するのに必要な動作のすべてを実行します:
(a) A violation of protocol procedure has occurred.
(a) プロトコル手順の違反は起こりました。
ISO 8473 [Page 23] RFC 994 December 1986
ISO8473[23ページ]RFC994 1986年12月
(b) A PDU is received whose checksum is inconsistent with its
contents.
(b) 受け取られたチェックサムがコンテンツに反しているPDU。
(c) A PDU is received, but due to local congestion, it cannot be
processed.
(c) PDUは受け取られていますが、地方の混雑のため、それを処理できません。
(d) A PDU is received whose header cannot be analyzed.
(d) 受け取られたヘッダーを分析できないPDU。
(e) A PDU is received which cannot be segmented and cannot be
forwarded because its length exceeds the maximum service data
unit size supported by any underlying service available for
transmission of the PDU to the next network-entity on the
chosen route.
(e) PDUは受け取られています(長さがサイズがPDUのトランスミッションに利用可能などんな基本的なサービスでも選ばれたルートの上の次のネットワーク実体に支持した最大のサービスデータ単位を超えているので、区分できないで、進めることができません)。
(f) A PDU is received whose destination address is unreachable or
unknown.
(f) 受け取られた送付先アドレスが手が届かないか、または未知であるPDU。
(g) Incorrect or invalid source routing was specified. This may
include a syntax error in the source routing field, an unknown
or unreachable address in the source routing field, or a path
which is not acceptable for other reasons.
(g) 不正確であるか無効のソースルーティングは指定されました。 これはソースルーティング分野、ソースルーティング分野の未知の、または、手の届かないアドレス、または他の理由で許容できない経路に構文エラーを含むかもしれません。
(h) A PDU is received whose PDU lifetime has expired or whose
lifetime expires during reassembly.
(h) 受け取られたPDU寿命が期限が切れたか、または寿命が再アセンブリの間に期限が切れるPDU。
(i) A PDU is received which contains an unsupported option.
(i) PDUは受け取られています(非サポート・オプションを含んでいます)。
6.10 Error Reporting Function
6.10 誤り報告機能
6.10.1 Overview
6.10.1 概観
This function causes an attempt to return an Error Report PDU to the source network-entity when a protocol data unit is discarded in ac- cordance with Clause 6.9.
この機能はプロトコルデータ単位がClause6.9と共にac- cordanceで捨てられるときソースネットワーク実体にError Report PDUを返す試みを引き起こします。
The Error Report PDU identifies the discarded PDU, specifies the type of error detected, and identifies the location in the header of the discarded PDU at which the error was detected. At least the entire header of the Discarded PDU (and, at the discretion of the originator of the Error Report PDU none, all, or part of the data field) is placed in the data field of the Error Report PDU.
Error Report PDUは誤りが検出された捨てられたPDUのヘッダーで捨てられたPDUを特定して、検出された誤りのタイプを指定して、位置を特定します。 少なくともDiscarded PDU(そしてデータのなにも、すべて、または一部がさばくError Report PDUの創始者の裁量で)の全体のヘッダーはError Report PDUのデータ・フィールドに置かれます。
The originator of a Data PDU may control the generation of Error Re- port PDUs. An Error Report flag in the original PDU is set by the source network-entity to indicate that an Error Report PDU is to be returned if the Initial PDU or any PDUs derived from it are discard- ed; if the flag is not set, Error Reports are to be suppressed.
Data PDUの創始者はError ReポートPDUsの世代を制御するかもしれません。 ソースネットワーク実体で、オリジナルのPDUのError Report旗が、Error Report PDUがそれから得られたInitial PDUかどれかPDUsが破棄教育であるなら返されることになっているのを示すように設定されます。 旗が設定されないなら、Error Reportsは抑圧されることになっています。
Note:
以下に注意してください。
1. The suppression of Error Report PDUs is controlled by the
1. Error Report PDUsの抑圧は制御されます。
ISO 8473 [Page 24] RFC 994 December 1986
ISO8473[24ページ]RFC994 1986年12月
originating network-entity and not by the NS User. Care
should be exercised by the originator with regard to
suppressing ER PDUs so that error reporting is not suppressed
for every PDU generated.
ネットワーク実体といずれのNS Userでも、由来しません。 注意がER PDUsを抑圧することに関して創始者によって行われるべきであるので、誤り報告は発生するあらゆるPDUのために抑圧されるというわけではありません。
2. Non-receipt of an Error Report PDU does not imply correct
delivery of a PDU issued by a source network-entity.
2. Error Report PDUの非領収書はソースネットワーク実体によって発行されたPDUの正しい配送を含意しません。
6.10.2 Requirements
6.10.2 要件
An Error Report PDU shall not be generated to report the discard of an Error Report PDU.
Error Report PDUの破棄を報告するためにError Report PDUを発生させないものとします。
An Error Report PDU shall not be generated to report the discard of a Data PDU unless that PDU has the Error Report flag set to allow Error Reports.
そのPDUがError Report旗がError Reportsを許容するように設定させない場合、Data PDUの破棄を報告するためにError Report PDUを発生させないものとします。
If a Data PDU is discarded, and the Error Report flag has been set to allow Error Reports, an Error Report PDU shall be generated if the reason for discard is one of the reasons for discard enumerated in Clause 6.9, subject to the conditions described in Clause 6.10.4.
Data PDUが捨てられて、Error Report旗がError Reportsを許容するように設定されたなら、Error Report PDUが破棄の理由がClause6.9でClauseで説明された状態を条件として列挙された破棄の理由の1つであるなら発生するものとする、6.10、.4
Note:
If a Data PDU with the E/R flag set to allow Error Reports is
discarded for any other reason, an ER PDU may be generated (as
an implementation option).
以下に注意してください。 Error Reportsを許容するように設定されたE/R旗があるData PDUがいかなる他の理由でも捨てられるなら、ER PDUは発生するかもしれません(実現オプションとして)。
6.10.3 Processing of Error Reports
6.10.3 エラー・レポートの処理
An Error Report PDU is composed from information contained in the header of the discarded Data PDU to which the Error Report refers. The contents of the Source Address field of the discarded Data PDU are used as the Destination Address of the Error Report PDU. This value, which in the context of the Data PDU was used as an NSAP Ad- dress, is used in the context of the Error Report PDU as the network-entity title of the network-entity that originated the Data PDU. The network- entity title of the originator of the Error Report PDU is conveyed in the Source Address field of the header of the Er- ror Report PDU. The value of the Lifetime field is determined in ac- cordance with Clause 6.4. Optional parameters are selected in accor- dance with Clause 6.10.4.
Error Report PDUはError Reportが参照する捨てられたData PDUのヘッダーに含まれた情報から構成されます。 捨てられたData PDUのSource Address分野の内容はError Report PDUのDestination Addressとして使用されます。 この値(Data PDUの文脈ではNSAP Adドレスとして使用された)はData PDUを溯源したネットワーク実体のネットワーク実体タイトルとしてError Report PDUの文脈で使用されます。 Error Report PDUの創始者のネットワーク実体タイトルはEr- ror Report PDUのヘッダーのSource Address分野で伝えられます。 Lifetime分野の値はClause6.4とac- cordanceで決定しています。 任意のパラメタはClause6.10.4とのaccorダンスで選択されます。
Segmentation of Error Report PDUs is not permitted; hence, no Segmen- tation Part is present. The total length of the ER PDU in octets is placed in the Segment Length field of the ER PDU header. This field is not changed during the lifetime of the ER PDU. If the originator of the ER PDU determines that the size of the ER PDU exceeds the max- imum service data unit size of the underlying service, the ER PDU shall be truncated to the maximum service data unit size (see Clause 5.5.3) and forwarded with no other change. Error Report PDUs are routed and forwarded by intermediate-system network-entities in the
Error Report PDUsの分割は受入れられません。 したがって、どんなSegmen- tation Partも存在していません。 八重奏における、ER PDUの全長はER PDUヘッダーのSegment Length分野に置かれます。 この分野はER PDUの生涯変えられません。 ER PDUの創始者が、ER PDUのサイズが基本的にサービスの最大imumサービスデータ単位サイズを超えていると決心しているなら、ER PDUが最大のサービスデータ単位サイズに先端を切られるものとする、(Clauseを見てください、5.5、.3、)、そして、他の変化なしで進めます。 中間システムネットワーク実体で誤りReport PDUsを中に発送して、送ります。
ISO 8473 [Page 25] RFC 994 December 1986
ISO8473[25ページ]RFC994 1986年12月
same way as Data PDUs.
Data PDUsと同じ道。
Note:
The requirement that the underlying service assumed by the CLNP
must be capable of supporting a service data unit size of at least
512 octets guarantees that the entire header of the discarded Data
PDU can be conveyed in the data field of any ER PDU.
以下に注意してください。 CLNPによって想定された基本的なサービスが少なくとも512の八重奏のサービスデータ単位サイズを支持できなければならないという要件は、どんなER PDUのデータ・フィールドも捨てられたData PDUの全体のヘッダーを運ぶことができるのを保証します。
When an ER PDU is decomposed upon reaching its destination, informa- tion that may be used to interpret and act upon the Error Report is obtained as follows. The network-entity title recovered from the NPAI in the Source Address field of the ER PDU header is used to identify the network-entity which generated the Error Report. The reason for generating the Error Report is extracted from the Options Part of the PDU header. The entire header of the discarded Data PDU (and part or all of the original user data) is extracted from the data field of the ER PDU to assist in determining the nature of the error.
目的地に到着するときER PDUを分解するとき、以下の通りError Reportを解釈して、作用するのに使用されるかもしれないinforma- tionを入手します。 NPAIがER PDUヘッダーのSource Address分野で取り戻されたネットワーク実体タイトルは、Error Reportを発生させたネットワーク実体を特定するのに使用されます。 Error Reportを発生させる理由はPDUヘッダーのOptions Partから抜粋されます。 捨てられたData PDU(そして、オリジナルの利用者データの部分かすべて)の全体のヘッダーは、誤りの本質を決定するのを助けるためにER PDUのデータ・フィールドから抽出されます。
6.10.4 Relationship of Data PDU Options to Error Reports
6.10.4 エラー・レポートへのデータPDUオプションの関係
The generation of an Error Report is affected by options that are present in the corresponding Data PDU. The presence of options in the original Data PDU that are not supported by the system which has dis- carded that PDU may cause the suppression of an Error Report even if the original Data PDU indicated that an Error Report should be gen- erated in the event of a discard.
Error Reportの世代は対応するData PDUに存在しているオプションで影響を受けます。 オリジナルのData PDUが、Error Reportが情報を得ることであるべきであることを示したとしても、不-cardedされたシステムによって支持されないオリジナルのData PDUでのPDUがError Reportの抑圧を引き起こすかもしれないオプションの存在は破棄の場合、eratedしました。
The processing of an Error Report is also affected by options which are present in the corresponding Data PDU. In particular, options selected for the original Data PDU affect which options are included in the corresponding Error Report PDU. The selection of options for an Error Report PDU is governed by the following requirements:
また、Error Reportの処理は対応するData PDUに存在しているオプションで影響を受けます。 特に、オリジナルのData PDUのために選択されたオプションは、どのオプションが対応するError Report PDUに含まれているかに影響します。 Error Report PDUのためのオプションの品揃えは以下の要件によって治められます:
(a) If the Priority Option or the QoS Maintenance Option is selected
in the original Data PDU, and the system generating the Error
Report PDU supports the option, then the Error Report PDU shall
specify the option.
(a) Priority OptionかQoS Maintenance OptionがオリジナルのData PDUで選択されて、Error Report PDUを発生させるシステムがオプションをサポートするなら、Error Report PDUはオプションを指定するものとします。
(b) If the Security Option is selected in the Data PDU, and the system
generating the Error Report supports this option, then the Error
Report PDU shall specify the option using the value that was
specified in the original Data PDU. If the system does not support
the Security Option, an Error Report must not be generated for
a Data PDU that selects the Security Option.
(b) Security OptionがData PDUで選択されて、Error Reportを発生させるシステムがこのオプションをサポートするなら、Error Report PDUは、オリジナルのData PDUで指定された値を使用することでオプションを指定するものとします。 システムがSecurity Optionを支持しないなら、Error ReportはSecurity Optionを選択するData PDUのために発生してはいけません。
(c) If the Complete Source Route Option is selected in the original
Data PDU, and the system generating the Error Report PDU supports
this option, then the error Report shall specify the Complete Source
Route option. The Source Route parameter value is obtained by
extracting from the original Data PDU that portion of the complete
source route that has already been traversed, and reversing the
(c) Complete Source Route OptionがオリジナルのData PDUで選択されて、Error Report PDUを発生させるシステムがこのオプションをサポートするなら、誤りReportはComplete Source Routeオプションを指定するものとします。 オリジナルのData PDUから既に横断された完全な送信元経路のその一部を抽出して、逆になることによって、Source Routeパラメタ価値を得ます。
ISO 8473 [Page 26] RFC 994 December 1986
ISO8473[26ページ]RFC994 1986年12月
order of network-entity titles which comprise the list.
If the system does not support the Complete Source Route Option,
an Error Report must not be generated for a Data PDU that selects
the Complete Source Route option.
リストを包括するネットワーク実体タイトルの注文。 システムがComplete Source Route Optionを支持しないなら、Error ReportはComplete Source Routeオプションを選択するData PDUのために発生してはいけません。
(d) The Padding, Partial Source Routing, and Record Route Options,
if supported, may be specified in the Error Report PDU.
(d) Padding、Partial Sourceルート設定、支持されるなら、Record Route OptionsはError Report PDUで指定されるかもしれません。
Note:
The values of the optional parameters in (d) above may be
derived as a local matter, or they may be based upon the
corresponding values in the original Data PDU.
以下に注意してください。 (d)の任意のパラメタの上の値が地域にかかわる事柄として引き出されるかもしれませんか、または彼らはオリジナルのData PDUの換算値に基づくかもしれません。
6.11 PDU Header Error Detection
6.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 veri- fied at each point at which the PDU header is processed. If the checksum calculation fails, the PDU must be discarded. If PDU header fields are modified (for example, due to operation of the lifetime function), then the checksum is modified so that the checksum remains valid.
PDU Header Error Detection機能はPDUヘッダーでの間違った情報の処理のため中間介在物か終わりの体系網実体の失敗から守ります。 機能は全体のPDUヘッダーの上に計算されたチェックサムによって実現されます。 チェックサムはPDUヘッダーが処理される各ポイントのveri- fiedです。 チェックサム計算が失敗するなら、PDUを捨てなければなりません。 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機能の使用は、任意であり、由来しているネットワーク実体によって選択されます。 機能が使用されていないなら、PDUヘッダーのチェックサム分野はゼロに設定されます。
If the function is selected by the originating network-entity, the value of the checksum field causes the following formulae to be sa- tisfied:
機能が由来しているネットワーク実体によって選択されるなら、チェックサム分野の値は、以下の公式がsa- tisfiedであることを引き起こします:
(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.
機能が使用中であるときに、チェックサム分野のどちらの八重奏もゼロに設定されないかもしれません。
Note:
以下に注意してください。
1. To ensure that inadvertent modification of a header while a
PDU is being processed by an intermediate system (for
example, due to a memory fault) may still be detected by the
PDU Header Error function, an intermediate system network-
1. 中間システム(例えばメモリー障害のため)によってPDUが処理されている間、ヘッダーのその不注意な変更を確実にするのはPDU Header Error機能によってまだ検出されているかもしれません、中間システムネットワーク
ISO 8473 [Page 27] RFC 994 December 1986
ISO8473[27ページ]RFC994 1986年12月
entity must not recompute the checksum for the entire header,
even if fields are modified.
分野が変更されていても、実体は全体のヘッダーのためにチェックサムを再計算してはいけません。
2. Annex C contains descriptions of algorithms which may be
used to calculate the correct value of the checksum field
when the PDU is created, and to update the value of the
checksum field when the header is modified.
2. 別館Cはヘッダーが変更されているときのPDUが作成されるとき、チェックサム分野の正しい値について計算して、チェックサム分野の値をアップデートするのに使用されるかもしれないアルゴリズムの記述を含んでいます。
6.12 Padding Function
6.12 機能を水増しすること。
The padding function is provided to allow space to be reserved in the PDU header which is not used to support any other function. Octet alignment must be maintained.
いかなる他の機能もサポートするのに使用されないPDUヘッダーで予約されるために紙面を割くために詰め物機能を提供します。 八重奏整列を維持しなければなりません。
Note:
An example of the use of this function is to cause the data field
of a PDU to begin on a convenient boundary for the originating
network-entity, such as a computer word boundary.
以下に注意してください。 この機能の使用に関する例はPDUのデータ・フィールドが由来しているネットワーク実体のために便利な境界で始まることを引き起こすことです、コンピュータ語境界のように。
6.13 Security
6.13 セキュリティ
The provision of protection services (e.g., data origin authentica- tion, data confidentiality, and data integrity of a single connectionless-mode NSDU) is performed by the Security Function.
保護サービス(独身のコネクションレスなモードNSDUの例えば、データの起源authentica- tion、データの機密性、およびデータ保全)の支給はSecurity Functionによって実行されます。
The Security Function is related to the Protection from Unauthorized Access Quality of Service parameter described in ISO 8348/AD1, Adden- dum to the Network Service Definition Covering Connectionless-mode Transmission. The function is realized through selection of the secu- rity parameter in the options part of the PDU header.
Security FunctionはISO8348/AD1(Network Service Definition Covering Connectionless-モードTransmissionへのAdden- dum)で説明されたServiceパラメタのUnauthorized Access QualityからProtectionに関連します。 機能はPDUヘッダーのオプション一部でのsecu- rityパラメタの選択で実現されます。
This Standard does not specify the way in which protection services are to be provided; it only provides for the encoding of security in- formation in the PDU header. To facilitate interoperation between end-systems and network relay-systems by avoiding different interpre- tations of the same encoding, a means to distinguish user-defined security encodings from standardized security encodings is described in Clause 7.5.3.
このStandardは提供される保護サービスがことである方法を指定しません。 それはセキュリティのコード化に中に備えるだけです。PDUヘッダーの構成。 エンドシステムとネットワークリレー方式の間で同じコード化の異なったinterpre- tationsを避けることによってinteroperationを容易にするために、標準化されたセキュリティencodingsとユーザによって定義されたセキュリティencodingsを区別する手段がClauseで説明される、7.5、.3
Note:
As an implementation consideration, data origin authentication
may be provided through the use of a cryptographically generated
or enciphered checksum (unique from the PDU Header Error Detection
mechanism); data confidentiality and data integrity may be
provided via route control mechanisms.
以下に注意してください。 実現の考慮として、暗号で発生しているか、または暗号化されたチェックサム(PDU Header Error Detectionメカニズムからユニークな)の使用でデータ起源認証を提供するかもしれません。 ルート制御機構でデータの機密性とデータ保全を提供するかもしれません。
6.14 Source Routing Function
6.14 ソース経路選択機能
The Source Routing function allows the originator to specify the path a generated PDU must take. Source routing may only be selected by the
Sourceルート設定機能で、創始者は発生しているPDUが取らなければならない経路を指定できます。 ソースルーティングは選択されるだけであるかもしれません。
ISO 8473 [Page 28] RFC 994 December 1986
ISO8473[28ページ]RFC994 1986年12月
originator of a PDU. Source Routing is accomplished using a list of network-entity titles held in a parameter within the options part of the PDU header. The length of this parameter is determined by the originating network-entity, and does not change as the PDU traverses the network.
PDUの創始者。 ソースルート設定はPDUヘッダーのオプション一部の中にパラメタに保持されたネットワーク実体タイトルのリストを使用するのに優れています。 このパラメタの長さは、由来しているネットワーク実体によって測定されて、PDUがネットワークを横断するのに応じて、変化しません。
The Source Route parameter includes information used by the originat- ing end-system when determining the initial route of the PDU. Only the titles of intermediate system network-entities are included in the list; the network-entity title of the destination of the PDU is not included in the list.
Source RouteパラメタはPDUの初期のルートを決定するときoriginat- ingエンドシステムによって使用される情報を含んでいます。 中間システムネットワーク実体のタイトルだけがリストに含まれています。 PDUの目的地のネットワーク実体タイトルはリストに含まれていません。
Associated with the list of network-entity titles is an indicator which identifies the next entry in the list to be used; this indica- tor is advanced by the receiver of the PDU when the next title in the list matches its own. The indicator is updated as the PDU is forward- ed so as to identify the appropriate entry at each stage of relaying.
ネットワーク実体タイトルのリストに関連づけられているのは、使用されるためにリストにおける次のエントリーを特定するインディケータです。 リストの次のタイトルがそれ自身のものに合っていると、このindica- torはPDUの受信機によって進められます。 PDUがそれぞれのステージのリレーで適切なエントリーを特定する前進の教育であるので、インディケータをアップデートします。
Two forms of the Source Routing function are provided. The first form, referred to as Complete Source Routing, requires that the specified path must be taken; that is, only those systems identified in the list may be visited by the PDU while en route to the destina- tion, and each system must be visited in the order specified. If the specified path cannot be taken, the PDU must be discarded. Clause 6.10 describes the circumstances in which an attempt shall be made to inform the originator of the discard using the Error Reporting func- tion.
Sourceルート設定機能の2つのフォームを提供します。 Complete Sourceルート設定と呼ばれた最初の書式は、指定された経路を取らなければならないのを必要とします。 PDUはdestina- tionに途中であるすなわち、リストで特定されたそれらのシステムだけを訪問してもよいです、そして、指定されたオーダーで各システムを訪問しなければなりません。 指定された経路を取ることができないなら、PDUを捨てなければなりません。 第6.10節は試みが破棄について創始者に知らせるのがError Reporting func- tionを使用することでされるものとする事情について説明します。
The second form is referred to as Partial Source Routing. Again, each system identified in the list must be visited in the order specified while en route to the destination. However, with this form of source routing the PDU may take any path necessary to arrive at the next in- termediate system in the list, which may include visiting intermedi- ate systems that are not identified in the list. The PDU will not be discarded (for source routing related reasons) unless one of the sys- tems specified cannot be reached by any available route.
2番目の書式はPartial Sourceルート設定と呼ばれます。 一方、目的地に途中である指定されたオーダーでリストで特定された各システムを訪問しなければなりません。 しかしながら、このフォームのソースルーティングで、PDUはリストの次のコネtermediateシステムに到着するのに必要などんな経路も取るかもしれなくて、どれが、intermediを訪問するのを含むかもしれないかがリストで特定されないシステムを食べました。 どんな利用可能なルートでも指定されたsys- temsの1つに達することができると、PDUは捨てられないでしょう(ソースルーティングが理由について話したので)。
6.15 Record Route Function
6.15 記録的なルート機能
The Record Route function records the path(s) taken by a PDU as it traverses a series of intermediate systems. A recorded route consists of a list of network-entity titles held in a parameter within the op- tions part of the PDU header. The length of this parameter is deter- mined by the originating network-entity, and does not change as the PDU traverses the network.
Record Route機能は一連の中間システムを横断するのに従ってPDUによって取られた経路を記録します。記録されたルートはPDUヘッダーのオプアートtions一部の中にパラメタに保持されたネットワーク実体タイトルのリストから成ります。 このパラメタの長さがそう、由来しているネットワーク実体によって採掘されて、思いとどまらせて、PDUがネットワークを横断するのに従って、変えません。
The list is constructed as the PDU is forwarded along a path towards its destination. Only the titles of intermediate system network- entities are included in the recorded route. The network-entity title of the originator of the PDU is not recorded in the list.
経路に沿って目的地に向かってPDUを送るとき、リストを構成します。 実体が含まれている記録が発送する中間システムネットワークのタイトルだけ。 PDUの創始者のネットワーク実体タイトルはリストに記録されません。
ISO 8473 [Page 29] RFC 994 December 1986
ISO8473[29ページ]RFC994 1986年12月
When an intermediate system network-entity processes a PDU containing the Record Route parameter, the system adds its own networkentity ti- tle at the end of the list of recorded network-entity titles. An in- dicator is maintained to identify the next available octet to be used for recording of route. This indicator is updated as entries are ad- ded to the list as follows. The length of the entry to be added to the list is added to the value of the next available octet indicator, and this sum is compared with the length of the Record Route parame- ter. If the addition of the entry to the list would exceed the size of the parameter, the next available octet indicator is set to indi- cate that route recording has been terminated. The network-entity ti- tle is not added to the list. The PDU may still be forwarded to its final destination, without further addition of network-entity titles.
中間システムネットワーク実体がRecord Routeパラメタを含むPDUを処理するとき、システムは記録されたネットワーク実体タイトルのリストの終わりでそれ自身のnetworkentity ti- tleを加えます。 コネdicatorは、ルートの録音に使用されるために次の利用可能な八重奏を特定するために維持されます。 エントリーが以下のリストへの広告dedであるので、このインディケータをアップデートします。 リストに追加されるべきエントリーの長さは次の利用可能な八重奏インディケータの値に加えられます、そして、この合計はRecord Route parame- terの長さにたとえられます。 リストへのエントリーの追加がパラメタのサイズを超えているなら、次の利用可能な八重奏インディケータは終えられる、ルートが記録したindi美味に設定されます。 ネットワーク実体ti- tleはリストに追加されません。 ネットワーク実体タイトルのさらなる添加なしで最終的な目的地にPDUをまだ送っているかもしれません。
If the addition of the entry would not exceed the size of the Record Route parameter, the next available octet indicator is updated with the new value, and the network-entity title is added to the head of the list after the other entries have been moved.
エントリーの添加がRecord Routeパラメタのサイズを超えていないなら、新しい値で次の利用可能な八重奏インディケータをアップデートします、そして、他のエントリーを動かした後にネットワーク実体タイトルをリストのヘッドに加えます。
Two forms of the Record Route function are provided. The first form is referred to as Complete Route Recording. It requires that the list of network-entity titles be a complete and accurate record of all intermediate systems visited by a PDU (including Derived PDUs), except when a shortage of space in the record route option field causes termination of recording of route, as described above. When Complete Route Recording is selected, PDU reassembly at intermediate systems is performed only when the Derived PDUs that are reassembled all took the same route; otherwise, the PDU is discarded, and if selected, an Error Report is generated (see Clause 6.10).
Record Route機能の2つのフォームを提供します。 最初の書式はComplete Route Recordingと呼ばれます。 それは、ネットワーク実体タイトルのリストがPDUによって訪問されたすべての中間システムの完全で正確な記録であることを必要とします(Derived PDUsを含んでいて)、記録的なルートオプション・フィールドのスペースの不足がルートの録音の終了を引き起こす時を除いて、上で説明されるように。 Complete Route Recordingが選択されるとき、組み立て直されるDerived PDUsがすべて、同じルートを取ったときだけ、中間システムのPDU reassemblyは実行されます。 さもなければ、PDUは捨てられます、そして、選択されるなら、Error Reportは発生します(Clause6.10を見てください)。
The second form is referred to as Partial Route Recording. It also requires a record of intermediate systems visited by a PDU. When Par- tial Route Recording is selected, PDU reassembly at intermediate sys- tems is always permitted. When reassembly is performed at an inter- mediate system, the route recorded in any of the Derived PDUs may be placed in the PDU resulting from the reassembly.
2番目の書式はPartial Route Recordingと呼ばれます。 また、それはPDUによって訪問された中間システムに関する記録を必要とします。 Par- tial Route Recordingが選択されるとき、中間的sys- temsのPDU reassemblyはいつも受入れられます。 再アセンブリが相互仲介のシステムで実行されるとき、Derived PDUsのいずれにも記録されたルートは再アセンブリから生じるPDUに置かれるかもしれません。
Note:
The Record Route function is intended to be used in the diagnosis
of subnetwork problems and/or to provide a return path that could
be used as a source route in a subsequent PDU.
以下に注意してください。 Record Route機能は、その後のPDUの送信元経路として使用できたリターンパスをサブネットワーク問題の診断に使用されて、提供することを意図します。
6.16 Quality of Service Maintenance Function
6.16 サービスの質維持機能
The Quality of Service Maintenance function provides information to network-entities in intermediate systems which may be used to make routing decisions where such decisions affect the overall QoS provid- ed to NS users. This information is conveyed to intermediate system network- entities in a parameter in the options part of the PDU header.
Service Maintenance機能のQualityはルーティングをそのような決定がどこで総合的なQoS provid教育にNSユーザに影響するかという決定にするのに使用されるかもしれない中間システムのネットワーク実体に情報を提供します。 この情報はオプションにおけるパラメタの実体が分けるPDUヘッダーの中間システムネットワークに伝えられます。
ISO 8473 [Page 30] RFC 994 December 1986
ISO8473[30ページ]RFC994 1986年12月
In those instances where the QoS requested cannot be maintained, in- termediate system network-entities shall attempt to deliver the PDU at a QoS different from the QoS requested. Intermediate system network-entities do not necessarily provide a notification of failure to meet the requested Quality of Service.
要求されたQoSを維持できないそれらの例では、コネtermediateシステムネットワーク実体は、要求されたQoSと異なったQoSでPDUを届けるのを試みるものとします。 中間システムネットワーク実体は必ずServiceの要求されたQualityに会わないことの通知を提供するというわけではありません。
6.17 Priority Function
6.17 優先権機能
The Priority function allows a PDU with a numerically higher priority value to be processed preferentially with respect to other PDUs with numerically lower priority values. The function is realized through selection of a parameter in the options part of the PDU header.
Priority機能は、数の上でより高い優先順位の値があるPDUが数の上で下側の優先順位の値で他のPDUsに関して優先的に処理されるのを許容します。 機能はPDUヘッダーのオプション一部でのパラメタの選択で実現されます。
The lowest priority value is zero; a source network-entity that does not support the Priority function must set the Priority value to zero. The Priority function provides a means whereby the resources of end and intermediate system network-entities, such as outgoing transmission queues and buffers, can be used preferentially to pro- cess higher-priority PDUs ahead of lower-priority PDUs. The specific action taken by an individual network-entity to support the Priority function is a local matter.
最も低い優先順位の値はゼロです。 Priority機能をサポートしないソースネットワーク実体はPriority値をゼロに設定しなければなりません。 Priority機能は優先的に終わりに関するリソースと外向的なトランスミッション待ち行列やバッファなどの中間システムネットワーク実体を低優先度PDUsの前の親課税より高い優先度PDUsに使用できる手段を提供します。 個々のネットワーク実体によって取られた、Priority機能をサポートした特定の行動は地域にかかわる事柄です。
6.18 Congestion Notification Function
6.18 混雑通知機能
To allow NS Users to take appropriate action when congestion is ex- perienced within the NS provider, intermediate systems may inform the destination network-entity of congestion through the use of a flag in the QoS Maintenance parameter in the options part of the PDU header. The value of this flag is initially set to zero (0) by the originator of the PDU and may be set to one (1) by any intermediate system which processes the PDU to indicate that it is experiencing congestion. The criteria for determining when this action is to be taken are a local matter.
混雑がNSの中でperiencedされた元の連れ合いプロバイダーであるときに、NS Usersが適切な行動を取るのを許容するために、中間システムはPDUヘッダーのオプション一部のQoS Maintenanceパラメタにおける旗の使用で混雑の目的地ネットワーク実体を知らせるかもしれません。 この旗の値は、初めは、PDUの創始者で(0)のゼロを合わせるように設定されて、混雑を経験しているのを示すためにPDUを処理するどんな中間システムによる1つ(1)にも設定されるかもしれません。 この動作がいつ取られるかことであることを決定する評価基準は地域にかかわる事柄です。
Note:
Congestion typically corresponds to inavailability of buffer space
to maintain output queues. An appropriate policy for indicating
congestion may be based upon the depth of the output queue selected
for a PDU (according to its destination address or other routing
information). When the depth of a particular output queue exceeds
a certain proportion of the depth of that queue, an intermediate
system will start to discard PDUs. The intermediate system will set
the Congestion Experienced flag in the next PDU to be forwarded
and may continue to do so until the condition is alleviated.
以下に注意してください。 混雑は、出力キューを維持するためにバッファ領域の「不-有用性」に通常対応しています。 混雑を示すための適切な方針はPDU(その送付先アドレスか他のルーティング情報によると)のために選択された出力キューの深さに基づくかもしれません。 特定の出力キューの深さがその待ち行列の深さのある割合を超えていると、中間システムはPDUsを捨て始めるでしょう。 中間システムは、次のPDUのCongestion Experienced旗に進められるように設定して、状態が軽減されるまでそうし続けるかもしれません。
6.19 Classification of Functions
6.19 機能の分類
Implementations are not required to support all of the functions described in Clauses 6.1 through 6.18. Functions are divided into three categories:
実装は、Clauses6.1〜6.18で説明された機能のすべてをサポートするのに必要ではありません。 機能は3つのカテゴリに分割されます:
ISO 8473 [Page 31] RFC 994 December 1986
ISO8473[31ページ]RFC994 1986年12月
Type 1: These functions must be supported.
タイプ1: これらの機能をサポートしなければなりません。
Type 2: These functions may or may not be supported.
If an implementation does not support a Type 2 function, and the
function is selected in a PDU, then that PDU must be discarded,
and an Error Report PDU must be generated and forwarded to the
originating network-entity, providing that the Error Report flag is
set and the conditions of Clause 6.10.4 are satisfied.
2はタイプします: これらの機能はサポートされるかもしれません。 実装がType2機能をサポートしないで、機能がPDUで選択されるならそのPDUを捨てなければならなくて、起因するネットワーク実体にError Report PDUを生成して、送らなければなりません、Error Report旗がClauseのセットと状態であるなら6.10、.4、満たされています。
Type 3: These functions may or may not be supported.
If an implementation does not support a Type 3 function, and the
function is selected in a PDU, then the function is not performed,
and the PDU is processed exactly as though the function had not
been selected. The protocol data unit shall not be discarded for
this reason.
3はタイプします: これらの機能はサポートされるかもしれません。 実装がType3機能をサポートしないで、機能がPDUで選択されるなら、機能は実行されません、そして、まるでちょうど機能が選択されていないかのようにPDUは処理されます。 この理由でプロトコルデータ単位を捨てないものとします。
Table 4 shows how the functions are divided into these three categories:
テーブル4は機能がどうこれらの3つのカテゴリに分割されるかを示しています:
_____________________________________________________________________________ | | FULL | NON | INACTIVE | | FUNCTION | PROTOCOL | SEGMENTING | SUBSET | | | | SUBSET | | |________________________________|_____________|_________________|____________| |PDU Composition | 1 | 1 | 1 | |PDU Composition | 1 | 1 | 1 | |Header Format Analysis | 1 | 1 | 1 | |PDU Lifetime Control | 1 | 1 | N/A | |Route PDU | 1 | 1 | N/A | |Forward PDU | 1 | 1 | N/A | |Segment PDU | 1 | N/A | N/A | |Reassemble PDU | 1 | N/A | N/A | |Discard PDU | 1 | 1 | N/A | |Error Reporting (Note 1) | 1 | 1 | N/A | |Header Error Detection (Note 1) | 1 | 1 | N/A | |Security | 1 | 2 | N/A | |Complete Source Routing | 1 | 2 | N/A | |Complete Route Recording | 2 | 2 | N/A | |Partial Source Routing | 3 | 3 | N/A | |Partial Route Recording | 3 | 3 | N/A | |Priority | 3 | 3 | N/A | |QoS Maintenance | 3 | 3 | N/A | |Congestion Notification | 3 | 3 | N/A | |Padding | 3 | 3 | N/A | |________________________________|_____________|_________________|____________|
_____________________________________________________________________________ | | 完全| 非| 不活発| | 機能| プロトコル| 区分| 部分集合| | | | 部分集合| | |________________________________|_____________|_________________|____________| |PDU構成| 1 | 1 | 1 | |PDU構成| 1 | 1 | 1 | |ヘッダー形式分析| 1 | 1 | 1 | |PDU生涯コントロール| 1 | 1 | なし| |ルートPDU| 1 | 1 | なし| |前進のPDU| 1 | 1 | なし| |セグメントPDU| 1 | なし| なし| |PDUを組み立て直してください。| 1 | なし| なし| |PDUを捨ててください。| 1 | 1 | なし| |誤り報告(注意1)| 1 | 1 | なし| |ヘッダー誤り検出(注意1)| 1 | 1 | なし| |セキュリティ| 1 | 2 | なし| |完全なソースルート設定| 1 | 2 | なし| |完全なルート録音| 2 | 2 | なし| |部分的なソースルート設定| 3 | 3 | なし| |部分的なルート録音| 3 | 3 | なし| |優先権| 3 | 3 | なし| |QoSメインテナンス| 3 | 3 | なし| |混雑通知| 3 | 3 | なし| |詰め物| 3 | 3 | なし| |________________________________|_____________|_________________|____________|
Table 4: Categorization of Protocol Functions
テーブル4: プロトコル機能の分類
ISO 8473 [Page 32] RFC 994 December 1986
ISO8473[32ページ]RFC994 1986年12月
Note:
以下に注意してください。
1. While the Error Reporting and Header Error Detection functions
must be provided, they are provided only when selected
by the sending Network Service user.
1. Error ReportingとHeader Error Detection機能を提供しなければなりませんが、送付Network Serviceユーザが選択する場合にだけ、それらを提供します。
2. The rationale for the inclusion of type 3 functions is that in
the case of some functions it is more important to forward
the PDUs between intermediate systems or deliver them to
an end-system than it is to support the functions. Type 3
functions should be used in those cases where they are of an
advisory nature; they cannot cause a PDU to be discarded
when they are not supported.
2. タイプ3機能の包含のための原理はいくつかの機能の場合では、それが中間システムの間にPDUsを送るか、またはエンドシステムにそれらを提供するために機能をサポートすることになっているより重要であるということです。 タイプ3機能はそれらが顧問に自然であるそれらの場合に使用されるべきです。 それらがサポートされないとき、彼らはPDUを捨てさせることができません。
7 Structure and Encoding of PDUs
7 PDUsの構造とコード化
7.1 Structure
7.1 構造
All Protocol Data Units shall contain an integral number of octets. The octets in a PDU are numbered starting from one (1) and increasing in the order in which they are submitted to the underlying service. The bits in an octet are numbered from one (1) to eight (8), where bit one (1) is the low-order (least significant) bit.
すべてのプロトコルData Unitsが整数の八重奏を含むものとします。 PDUの八重奏は、1つ(1)から始めて、それらが基本的なサービスに提出されるオーダーを増やしながら、番号付です。 八重奏におけるビットは1つ(1)〜8(8)まで付番されます。そこでは、噛み付いているもの(1)は下位(最も重要でない)のビットです。
When consecutive octets are used to represent a binary number, the lower octet number has the most significant value.
連続した八重奏が2進の数を表すのに使用されるとき、下側の八重奏番号には、最も重要な値があります。
Any implementation supporting this protocol is required to state in its specification the way in which octets are transferred, using the terms "most significant bit" and "least significant bit". The PDUs of this protocol are defined using the terms "most significant bit" and "least significant bit".
このプロトコルをサポートする実装が八重奏がわたっている方法、「最上位ビット」という用語を使用して、および「最下位ビット」という仕様による状態に必要です。 このプロトコルのPDUsは、用語「最上位ビット」と「最下位ビット」を使用することで定義されます。
Note:
When the encoding of a PDU is represented using a diagram in this
Clause the following representation is used:
以下に注意してください。 PDUのコード化がこのClauseのダイヤグラムを使用することで表されるとき、以下の表現は使用されています:
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;
2. the address part;
3. the segmentation part, if present;
4. the Options part, if present;
1. 固定部分。 2. アドレス部。 3. 分割部分存在しているなら 4. 存在しているなら、Optionsは離れています。
and the data field, if present. This structure is illustrated in Figure 2:
そして、データ・フィールド存在しているなら。 この構造は図2で例証されます:
ISO 8473 [Page 33] RFC 994 December 1986
ISO8473[33ページ]RFC994 1986年12月
7.2 Fixed Part
7.2 固定部分
7.2.1 General
7.2.1 一般
The fixed part of the PDU header contains frequently occurring param- eters including the type code (DT or ER) of the protocol data unit. The length and the structure of the fixed part are defined by the PDU code.
PDUヘッダーの固定一部がプロトコルデータ単位のタイプコード(DTかER)を含む頻繁に起こっているparam- etersを含みます。 固定部分の長さと構造はPDUコードによって定義されます。
The fixed part has the following format:
固定部分には、以下の形式があります:
Part Described in
___________________________________
| Fixed Part | Section 7.2
|_________________________________|
| Address Part | Section 7.3
|_________________________________|
| Segmentation Part | Section 7.4
|_________________________________|
| Options Part | Section 7.5
|_________________________________|
| Data | Section 7.6
|_________________________________|
中で説明された部分___________________________________ | 固定部分| セクション7.2|_________________________________| | アドレス部| セクション7.3|_________________________________| | 分割部分| セクション7.4|_________________________________| | オプション一部| セクション7.5|_________________________________| | データ| セクション7.6|_________________________________|
Figure 2: PDU Structure
図2: PDU構造
Octet
________________________________________
| Network Layer Protocol Identifier | 1
|______________________________________|
| Length Indicator | 2
|______________________________________|
| Version/Protocol Id Extension | 3
|______________________________________|
| Lifetime | 4
|______________________________________|
| SP vline M S vline e/R | Type | 5
|______________________________________|
| Segment Length | 6,7
|______________________________________|
| Checksum | 8,9
|______________________________________|
八重奏________________________________________ | ネットワーク層プロトコル識別子| 1 |______________________________________| | 長さのインディケータ| 2 |______________________________________| | バージョン/プロトコルイド拡大| 3 |______________________________________| | 生涯| 4 |______________________________________| | SP vline M S vline e/R| タイプ| 5 |______________________________________| | セグメントの長さ| 6,7 |______________________________________| | チェックサム| 8,9 |______________________________________|
Figure 3: PDU Header -- Fixed Part
図3: PDUヘッダー--固定部分
7.2.2 Network Layer Protocol Identifier
7.2.2 ネットワーク層プロトコル識別子
The value of this field is set to binary 1000 0001 to identify this Network Layer protocol as ISO 8473, Protocol for Providing the Connectionless- mode Network Service. The value of this field is set
2進の1000 0001にこの分野の値が、このNetwork LayerプロトコルがISO8473である(Providing ConnectionlessモードNetwork Serviceのためのプロトコル)と認識するように設定されます。 この分野の値は設定されます。
ISO 8473 [Page 34] RFC 994 December 1986
ISO8473[34ページ]RFC994 1986年12月
to binary 0000 0000 to identify the Inactive Network Layer protocol subset.
特定する2進の0000 0000に、Inactive Network Layerは部分集合について議定書の中で述べます。
7.2.3 Length Indicator
7.2.3 長さのインディケータ
The length is indicated by a binary number, with a maximum value of 254 (1111 1110). The length indicated is the length in octets of the header, as described in Clause 7.1. The value 255 (1111 1111) is reserved for possible future extensions.
長さは254(1111 1110)の最大値がある2進の数によって示されます。 示された長さはClause7.1で説明されるようにヘッダーの八重奏で長さです。 値255の(1111 1111)は可能な今後の拡大のために予約されます。
Note:
The rules for forwarding and segmentation guarantee that the header
length is the same for all segments (Derived PDUs) of the Initial
PDU, and is the same as the header length of the Initial PDU.
The size of a PDU header will not change due to operation of any
protocol function.
以下に注意してください。 推進と分割のための規則はヘッダ長がInitial PDUのすべてのセグメント(PDUsを引き出す)に同じであり、Initial PDUのヘッダ長と同じであることを保証します。 PDUヘッダーのサイズはどんなプロトコル機能の操作のためも変化しないでしょう。
7.2.4 Version/Protocol Identifier Extension
7.2.4 バージョン/プロトコル識別子拡張子
The value of this field is binary 0000 0001, which identifies the standard Version 1 of ISO 8473, Protocol for Providing the Connectionless-mode Network Service.
この分野の値は2進の0000 0001です(ISO8473の標準のバージョン1を特定します)、Providing Connectionless-モードNetwork Serviceのためのプロトコル。
7.2.5 PDU Lifetime
7.2.5 PDU生涯
The PDU Lifetime field is encoded as a binary number representing the remaining lifetime of the PDU, in units of 500 milliseconds.
PDU Lifetime分野はPDUの残っている生涯を表す2進の数としてコード化されます、500ミリセカンドのユニットで。
7.2.6 Flags
7.2.6 旗
7.2.6.1 Segmentation Permitted
7.2.6.1 分割は可能にしました。
The Segmentation Permitted flag indicates whether segmentation is permitted. Its value is determined by the originator of the PDU and cannot be changed by any other network-entity for the lifetime of the Initial PDU and any Derived PDUs.
Segmentation Permitted旗は、分割が受入れられるかどうかを示します。 値をPDUの創始者が決定して、Initial PDUの生涯、どんなDerived PDUsのためにもいかなる他のネットワーク実体でも変えることができません。
A value of one (1) indicates that segmentation is permitted. A value of zero (0) indicates that the non-segmenting protocol subset is em- ployed. When the value of zero is selected, the segmentation part of the PDU header is not present, and the Segment Length field serves as the Total Length field (see Clause 7.2.8).
1つ(1)の値は、分割が受入れられるのを示します。 (0)がない値は、非区分プロトコル部分集合がem- ployedであることを示します。 ゼロの値が選択されるとき、PDUヘッダーの分割一部が存在していなくて、Segment Length分野がTotal Length分野として機能する、(Clauseを見てください、7.2、.8、)
7.2.6.2 More Segments
7.2.6.2 より多くのセグメント
The More Segments flag indicates whether the data segment in this PDU contains (as its last octet) the last octet of the User Data in the NSDU. When the More Segments flag is set to one (1), segmentation has taken place and the last octet of the NSDU is not contained in this PDU. The More Segments flag cannot be set to one (1) if the Seg- mentation Permitted flag is not set to one (1).
More Segments旗は、このPDUのデータ・セグメントがNSDUにおける、User Dataの最後の八重奏を含むかどうかを(最後の八重奏として)示します。 More Segments旗が1つ(1)に設定されるとき、分割は行われました、そして、NSDUの最後の八重奏はこのPDUに含まれていません。 Seg精神作用Permitted旗が1つ(1)に設定されないなら、1つ(1)にMore Segments旗を設定できません。
ISO 8473 [Page 35] RFC 994 December 1986
ISO8473[35ページ]RFC994 1986年12月
When the More Segments flag is set to zero (0), the last octet of the Data Part of the PDU is the last octet of the NSDU.
More Segments旗が(0)のゼロに合うように設定されるとき、PDUのData Partの最後の八重奏はNSDUの最後の八重奏です。
7.2.6.3 Error Report
7.2.6.3 エラー・レポート
When the Error Report flag is set to one, the rules in Clause 6.10 are used to determine whether to generate an Error Report PDU if it is necessary to discard this Data PDU.
Error Report旗が1つに設定されるとき、このData PDUを捨てるのが必要であるなら、Clause6.10の規則は、Error Report PDUを生成するかどうか決定するのに使用されます。
When the Error Report flag is set to zero, discard of the Data PDU will not cause the generation of an Error Report PDU.
Error Report旗がゼロに設定されるとき、Data PDUの破棄はError Report PDUの世代を引き起こさないでしょう。
7.2.7 Type Code
7.2.7 コードをタイプしてください。
The Type code field identifies the type of the protocol data unit. Allowed values are given in Table 5:
Typeコード分野はプロトコルデータ単位のタイプを特定します。 Table5で許容値を与えます:
__________________________________________________
| | Bits 5 4 3 2 1 |
|_________|______________________________________|
| DT PDU | 1 1 1 0 0 |
|_________|______________________________________|
| ER PDU | 0 0 0 0 1 |
|_________|______________________________________|
__________________________________________________ | | ビット5 4 3 2 1| |_________|______________________________________| | DT PDU| 1 1 1 0 0 | |_________|______________________________________| | えー、PDU| 0 0 0 0 1 | |_________|______________________________________|
Table 5: Valid PDU Types
テーブル5: 有効なPDUはタイプします。
7.2.8 PDU Segment Length
7.2.8 PDUセグメントの長さ
The Segment Length field specifies the entire length, in octets, of the Derived PDU, including both header and data (if present). When the full protocol is employed and a PDU is not segmented, the value of this field is identical to the value of the Total Length field lo- cated in the Segmentation Part of the header.
Segment Length分野は全長を指定します、Derived PDUの八重奏で、ヘッダーとデータの両方を含んでいて(存在しているなら)。 完全なプロトコルが採用していて、PDUが区分されないとき、この分野の値はヘッダーのSegmentation PartでcatedされたTotal Length分野最低気温の値と同じです。
When the non-segmenting protocol subset is employed, no segmentation part is present in the header. In this subset, the Segment Length field specifies the entire length of the Initial PDU, including both header and data (if present). The Segment Length field is not changed for the lifetime of the PDU.
非区分プロトコル部分集合が採用しているとき、どんな分割部分もヘッダーに存在していません。 この部分集合では、Segment Length分野はInitial PDUの全長を指定します、ヘッダーとデータの両方を含んでいて(存在しているなら)。 Segment Length分野はPDUの生涯に変わりません。
7.2.9 PDU Checksum
7.2.9 PDUチェックサム
The checksum is computed on the entire PDU header. For the Data PDU, this includes the segmentation and options parts (if present). For the Error Report PDU, this includes the reason for discard field as well.
チェックサムは全体のPDUヘッダーの上に計算されます。 Data PDUに関しては、これは分割とオプション一部を含んでいます(存在しているなら)。 Error Report PDU、また、破棄の理由がさばくこのインクルードのために。
A checksum value of zero is reserved to indicate that the checksum is to be ignored. The operation of the PDU Header Error Detection func- tion (Clause 6.11) ensures that the value zero does not represent a
ゼロのチェックサム値は、チェックサムが無視されることであることを示すために予約されます。 PDU Header Error Detection func- tion(第6.11節)の操作は、値ゼロがaを表さないのを確実にします。
ISO 8473 [Page 36] RFC 994 December 1986
ISO8473[36ページ]RFC994 1986年12月
valid checksum. A non-zero value indicates that the checksum must be processed. If the checksum calculation fails, the PDU must be dis- carded.
有効なチェックサム。 非ゼロ値は、チェックサムを処理しなければならないのを示します。 チェックサム計算が失敗するなら、不-PDUをcardedしなければなりません。
7.3 Address Part
7.3 アドレス部
7.3.1 General
7.3.1 一般
Address parameters are distinguished by their location, immediately following the fixed part of the PDU header. The address part is il- lustrated Figure 4:
すぐにPDUヘッダーの固定一部に続いて、アドレスパラメタはそれらの位置によって区別されます。 アドレス部は不-lustratedされた図4です:
Octet
____________________________________________
| Destination Address Length Indicator | 10
|___________________________________________|
| | 11
: Destination Address :
| | m - 1
|___________________________________________|
| Source Address Length Indicator | m
|___________________________________________|
| | m + 1
: Source Address :
| | n - 1
|___________________________________________|
八重奏____________________________________________ | 目的地アドレス長さのインディケータ| 10 |___________________________________________| | | 11 : 送付先アドレス: | | m--1|___________________________________________| | ソースアドレス長さのインディケータ| m|___________________________________________| | | m+1: ソースアドレス: | | n--1|___________________________________________|
Figure 4: PDU Header -- Address Part
図4: PDUヘッダー--アドレス部
7.3.1.1 Destination and Source Addresses
7.3.1.1 目的地とソースアドレス
The Destination and Source addresses used by this protocol are Net- work Service Access Point addresses as defined in ISO 8348/AD2, Ad- dendum to the Network Service Definition Covering Network Layer Ad- dressing.
アドレスがこのプロトコルで使用したDestinationとSourceはISO8348/AD2(Network Service Definition Covering Network Layer AdドレッシングへのAd- dendum)で定義されるようにネット仕事Service Access Pointアドレスです。
The Destination and Source Addresses are variable length. The Desti- nation and Source Address fields are encoded as Network Protocol Ad- dress Information using the Preferred Binary Encoding defined in Clause 8.3.1 of ISO 8348/AD2.
DestinationとSource Addressesは可変長です。 Clauseで定義されたPreferred Binary Encodingを使用することでNetworkプロトコルAdが情報に服を着せるときDesti国とSource Address分野がコード化される、8.3、.1、ISO8348/AD2について。
The Destination Address Length Indicator field specifies the length of the Destination Address in octets. The Destination Address field follows the Destination Address Length Indicator field.
Destination Address Length Indicator分野は八重奏における、Destination Addressの長さを指定します。 Destination Address分野はDestination Address Length Indicator野原に続きます。
The Source Address Length Indicator field specifies the length of the Source Address in octets. The Source Address Length Indicator field follows the Destination Address field. The Source Address field fol- lows the Source Address Length Indicator field.
Source Address Length Indicator分野は八重奏における、Source Addressの長さを指定します。 Source Address Length Indicator分野はDestination Address野原に続きます。 Source AddressはSource Address Length Indicatorがさばくfol安値をさばきます。
ISO 8473 [Page 37] RFC 994 December 1986
ISO8473[37ページ]RFC994 1986年12月
Each address parameter is encoded as illustrated in Table 5:
それぞれのアドレスパラメタはTable5で例証されるようにコード化されます:
______________________________________________
| 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 5: Address Parameters
図5: アドレスパラメタ
7.4 Segmentation Part
7.4 分割部分
If the Segmentation Permitted Flag in the Fixed Part of the PDU Header (Octet 4, Bit 8) is set to one, the segmentation part of the header, illustrated in Figure 6, must be present:
PDU Header(八重奏4、Bit8)のFixed PartのSegmentation Permitted Flagが1つに用意ができているなら、図6で例証されたヘッダーの分割一部が存在していなければなりません:
If the Segmentation Permitted flag is set to zero, the non-segmenting protocol subset is in use.
Segmentation Permitted旗がゼロに設定されるなら、非区分プロトコル部分集合は使用中です。
Octet
________________________
| Data Unit Identifier | n, n + 1
|______________________|
| Segment Offset | n + 2, n + 3
|______________________|
| Total Length | n + 4, n + 5
|______________________|
八重奏________________________ | データ単位識別子| n、n+1|______________________| | セグメントオフセット| n+2、n+3|______________________| | 全長| n+4、n+5|______________________|
Figure 6: PDU Header -- Segmentation Part
図6: PDUヘッダー--分割部分
7.4.1 Data Unit Identifier
7.4.1 データ単位識別子
The Data Unit Identifier identifies an Initial PDU (and hence, its Derived PDUs) so that a segmented data unit may be correctly reassem- bled. The Data Unit Identifier size is two octets.
区分されたデータ単位が正確に言えば、reassemが出血したということであることができるように、Data Unit IdentifierはInitial PDU(そして、したがって、Derived PDUs)を特定します。 Data Unit Identifierサイズは2つの八重奏です。
7.4.2 Segment Offset
7.4.2 セグメントは相殺されました。
For each Derived PDU, the Segment Offset field specifies the relative position of the segment contained in the data field of the Derived PDU with respect to the start of the data field of the Initial PDU. The offset is measured in units of octets. The offset of the first segment (and hence, the Initial PDU) is zero; an unsegmented (Initial PDU) has a segment offset value of zero (0). The value of this field shall be a multiple of eight 8).
各Derived PDUとして、Segment Offset分野はDerived PDUのデータ・フィールドにInitial PDUのデータ・フィールドの始まりに関して保管されていたセグメントの相対的な位置を指定します。 オフセットはユニットの八重奏で測定されます。 最初のセグメント(そして、したがって、Initial PDU)のオフセットはゼロです。 非区分されて、(初期のPDU)はセグメントに(0)がない値を相殺させます。 この分野の値は8の倍数が8であったなら)そうするでしょう。
ISO 8473 [Page 38] RFC 994 December 1986
ISO8473[38ページ]RFC994 1986年12月
7.4.3 PDU Total Length
7.4.3 PDU、全長
The Total Length field specifies the entire length of the Initial PDU, including both the header and data. This field is not changed for the lifetime of the Initial PDU (and hence, its Derived PDUs).
Total Length分野はヘッダーとデータの両方を含むInitial PDUの全長を指定します。 この分野はInitial PDU(そして、したがって、Derived PDUs)の生涯に変わりません。
7.5 Options Part
7.5のオプションが離れています。
7.5.1 General
7.5.1 一般
The options part is used to convey optional parameters. The options part of the PDU header is illustrated below:
オプション一部が、任意のパラメタを伝えるのに使用されます。 PDUヘッダーのオプション一部が以下で例証されます:
Octet
___________________________________________________
| | n + 6
: Options :
| | p
|__________________________________________________|
八重奏___________________________________________________ | | n+6: オプション: | | p|__________________________________________________|
Figure 7: PDU Header -- Options Part
図7: PDUヘッダー--オプション一部
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ヘッダ長、-(固定部分+長さの分割部分のアドレス部+長さの長さ)
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 Protocol Data Unit with an option duplicated should be treated as a protocol error. The rules governing the treatment of protocol errors are described in Clause 6.10, Error Reporting Function.
オプション一部で定義されたパラメタは順不同に現れるかもしれません。 オプションのDuひだ形成は受入れられません。 オプションがコピーされているプロトコルData Unitの領収書はプロトコル誤りとして扱われるべきです。 Error Reporting Function、プロトコル誤りの処理を治める規則はClause6.10で説明されます。
The encoding of parameters contained within the options part of the PDU header is illustrated in Table 6:
PDUヘッダーのオプション一部の中に含まれたパラメタのコード化はTable6で例証されます:
Octets
___________________________________________
| n | Parameter Code |
|____________|____________________________|
| n + 1 | Parameter Length (e.g.m) |
|____________|____________________________|
| n + 2 | |
| to | Parameter Value |
| n + m + 1 | |
|____________|____________________________|
八重奏___________________________________________ | n| パラメタコード| |____________|____________________________| | n+1| パラメタの長さ(例えば、m)| |____________|____________________________| | n+2| | | to| パラメタ値| | n+m+1| | |____________|____________________________|
ISO 8473 [Page 39] RFC 994 December 1986
ISO8473[39ページ]RFC994 1986年12月
Table 6: Encoding of Parameters
テーブル6: パラメタのコード化
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:
パラメタ長さの分野はパラメタ値の分野の八重奏における長さを示します。 長さは正の2進の数、254の理論上の最大値があるmによって示されます。 mの実用的な最大値は低いです。 例えば、オプション一部の中に保管されていたただ一つのパラメタの場合では、2つの八重奏がパラメタコードとパラメタ長さのインディケータに必要です。 したがって、mの値は以下のことのために制限されます。
m = 252-(length of fixed part +length of address part +length of seg- mentation part)
m=252(固定部分+長さのseg精神作用部分のアドレス部+長さの長さ)
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.
以下のパラメタはオプション一部で受入れられます。
7.5.2 Padding
7.5.2 詰め物
The padding parameter is used to lengthen the PDU header to a con- venient size (See Clause 6.12).
詰め物パラメタは、まやかしvenientサイズにPDUヘッダーを伸すのに使用されます(Clause6.12を見てください)。
Parameter Code: 1100 1100
パラメタコード: 1100 1100
Parameter Length: variable
パラメタの長さ: 変数
Parameter Value: any value is allowed
パラメタ値: どんな値も許容されています。
7.5.3 Security
7.5.3 セキュリティ
This parameter allows a unique and unambiguous security level to be assigned to a protocol data unit.
このパラメタは、ユニークで明白なセキュリティー・レベルがプロトコルデータ単位に割り当てられるのを許容します。
Parameter Code: 1100 0101
パラメタコード: 1100 0101
Parameter Length: variable
パラメタの長さ: 変数
Parameter Value: The high order two bits of the first octet
specify the Security Format Code, where:
パラメタ値: 最初の八重奏の高位2ビットはSecurity Format Code、どこかを指定します:
Security Type of Security Field:
Format Code
セキュリティのセキュリティタイプは以下をさばきます。 書式記号
ISO 8473 [Page 40] RFC 994 December 1986
ISO8473[40ページ]RFC994 1986年12月
00 Reserved
01 Source Address Specific
10 Destination Address Specific
11 Globally Unique
00が01のソースアドレスの特定の10送付先アドレス特定の11をグローバルに予約した、ユニーク
The rest of the first octet is reserved and must be zero. The
remainder of the Parameter Value field specifies the security
level as described in the following Clauses.
7.5.3.1 Source Address Specific
最初の八重奏の残りは、予約されていて、ゼロであるに違いありません。 Parameter Value分野の残りは以下のClausesで説明されるようにセキュリティー・レベルを指定します。 7.5.3.1 ソースアドレス特有です。
The Security Format Code value of binary "01" indicates that the remaining octets of the parameter value field specify a security lev- el which is unique and unambiguous in the context of the security classification system employed by the authority responsible for as- signing the source NSAP Address.
バイナリーのSecurity Format Code値、「1インチが、パラメタ値の分野の残っている八重奏がセキュリティを指定するのを示す、原因となる権威によって使われたセキュリティ分類システムの文脈でユニークで明白なレフ高架鉄道、-、ソースNSAPアドレスに調印する、」
7.5.3.2 Destination Address Specific
7.5.3.2 送付先アドレス特有です。
The Security Format Code value of binary "10" indicates that the remaining octets of the parameter value field specify a security lev- el which is unique and unambiguous in the context of the security classification system employed by the authority responsible for as- signing the destination NSAP Address.
バイナリーのSecurity Format Code値、「10インチが、パラメタ値の分野の残っている八重奏がセキュリティを指定するのを示す、原因となる権威によって使われたセキュリティ分類システムの文脈でユニークで明白なレフ高架鉄道、-、目的地がNSAPアドレスであると署名する、」
7.5.3.3 Globally Unique Security
7.5.3.3 グローバルにユニークなセキュリティ
The Security Format Code value of binary "11" indicates that the remaining octets of the parameter value field specify a globally unique and unambiguous security level. This security classification system is not specified in this Standard.
Security Format Codeが評価する、バイナリーでは、「11インチは、パラメタ値の分野の残っている八重奏がグローバルにユニークで明白なセキュリティー・レベルを指定するのを示します」。 このセキュリティ分類システムはこのStandardで指定されません。
7.5.4 Source Routing
7.5.4 ソースルート設定
The source routing parameter specifies, either completely or partial- ly, the route to be taken from Source Network Address to Destination Network Address.
ソースルーティングパラメタが完全に指定する、部分的なly(Source Network AddressからDestination Network Addressまで取られるべきルート)
Parameter Code: 1100 0101
パラメタコード: 1100 0101
Parameter Length: variable
パラメタの長さ: 変数
Parameter Value: 2 octets of control information succeeded by a
concatenation of ordered network-entity title entries (ordered
from source to destination)
パラメタ値: 命令されたネットワーク実体タイトルの入力の連結で引き継がれた制御情報の2つの八重奏(ソースから目的地まで注文します)
The first octet of the parameter value is the type code, and has the following significance:
パラメタ価値の最初の八重奏は、タイプコードであり、以下の意味を持っています:
0000 0000 partial source routing
0000 0001 complete source routing
<all other values reserved>
0000 0001の完全なソースルーティング<のために他のすべての値を発送する0000 0000の部分的なソースが>を予約しました。
ISO 8473 [Page 41] RFC 994 December 1986
ISO8473[41ページ]RFC994 1986年12月
The second octet indicates the octet offset of the next network- entity title entry to be processed in the list. It is relative to the start of the parameter, such that a value of three (3) indicates that the next network-entity title entry begins immediately after this control octet. Successive octets are indicated by corresponding- ly larger values of this indicator.
2番目の八重奏は、リストで処理されるために次のネットワーク実体タイトルの入力の八重奏オフセットを示します。 それはパラメタの始まりに比例しています、3(3)の値が、次のネットワーク実体タイトルの入力がこのコントロール八重奏直後始まるのを示すように。 連続した八重奏はこのインディケータの対応するlyにより大きい値によって示されます。
The third octet begins the network-entity title list. The list con- sists of variable length network-entity title entries. The first oc- tet of entry identifies the length of the network-entity title which comprises the re- mainder of the entry.
3番目の八重奏はネットワーク実体タイトルリストを始めます。 可変長ネットワーク実体タイトルの入力のリストまやかしsists。 エントリーの最初のoc- tetはエントリーの再mainderを包括するネットワーク実体タイトルの長さを特定します。
7.5.5 Recording of Route
7.5.5 ルートの録音
The recording of route parameter identifies the route of intermediate systems traversed by the PDU.
ルートパラメタの録音はPDUによって横断された中間システムのルートを特定します。
Parameter Code: 1100 1011
パラメタコード: 1100 1011
Parameter Length: variable
パラメタの長さ: 変数
Parameter Value: 2 octets of control information succeeded by a
con catenation of ordered network-entity title entries (ordered
from destination to source)
パラメタ値: 命令されたネットワーク実体タイトルの入力のまやかし染色体の連結によって引き継がれた制御情報の2つの八重奏(目的地からソースまで注文します)
The first octet of the parameter value is the type code, and has the following significance:
パラメタ価値の最初の八重奏は、タイプコードであり、以下の意味を持っています:
0000 0000 Partial Recording of Route in progress
0000 0001 Complete Recording of Route in progress
<all other values reserved>
進歩<のすべて他のRouteのComplete Recordingが評価するRouteの進行中の0000 0001の0000 0000の部分的なRecordingは>を予約しました。
The second octet identifies the first octet not currently used for a recorded network-entity title, and therefore also the end of the list. It is encoded relative to the start of the parameter value, such that a value of three (3) indicates that no network-entity ti- tles have yet been recorded. A value of all ones is used to indicate that route recording has been terminated.
2番目の八重奏は、現在記録されたネットワーク実体タイトルに使用されていない最初の八重奏を特定して、したがって、リストの終わりも特定します。 それはパラメタ価値の始まりに比例してコード化されます、3(3)の値が、ネットワーク実体ti- tlesが全くまだ記録されていないのを示すように。 すべてのものの値は、ルート録音が終えられたのを示すのに使用されます。
The third octet begins the network-entity title list. The list con- sists of variable length network-entity title entries. The first oc- tet of each entry specifies the length of the network-entity title comprising the remainder of the entry. Network-entity title entries are always added to the beginning of the list; that is, the most re- cently added entry will begin in the third octet of the parameter value.
3番目の八重奏はネットワーク実体タイトルリストを始めます。 可変長ネットワーク実体タイトルの入力のリストまやかしsists。 それぞれのエントリーの最初のoc- tetはエントリーの残りを包括するネットワーク実体タイトルの長さを指定します。 ネットワーク実体タイトルの入力はいつもリストの始まりに加えられます。 すなわち、最も再セントの副出記入はパラメタ価値の3番目の八重奏で始まるでしょう。
Note:
The length of the Record Route parameter is determined by the
originator of the PDU and is not changed during the lifetime of
the PDU; hence, the operation of the Record Route function does
以下に注意してください。 Record Routeパラメタの長さは、PDUの創始者によって測定されて、PDUの生涯変えられません。 したがって、Record Route機能の操作はそうします。
ISO 8473 [Page 42] RFC 994 December 1986
ISO8473[42ページ]RFC994 1986年12月
not affect the length of the header.
ヘッダーの長さに影響してください。
7.5.6 Quality of Service Maintenance
7.5.6 サービスの質メインテナンス
The Quality of Service parameter conveys information about the quali- ty of service requested by the originating Network Service user. Network-entities in intermediate systems may (but are not required to) make use of this information as an aid in selecting a route when more than one route satisfying other routing criteria is available and the available routes are known to differ with respect to Quality of Service see Clause 6.16).
ServiceパラメタのQualityは起因しているNetwork Serviceユーザによって要求されたサービスのquali- tyの周りで情報を伝達します。 他のルーティング評価基準を満たす1つ以上のルートが利用可能であり、利用可能なルートがServiceのQualityに関して異なるのが知られているとルートを選択することにおける援助がClause6.16を見るようなこの情報の中の中間システムがそうするネットワーク実体(しかし、必要でない)造の使用)
Parameter Code: 1100 0011
Parameter Length: variable
Parameter Value: The high order two bits of the first octet
specify the QoS Format Code, where:
パラメタコード: 1100 0011パラメタの長さ: 可変Parameter Value: 最初の八重奏の高位2ビットはQoS Format Code、どこかを指定します:
QoS Format Type of QoS
Code Field
00 Reserved
01 Source Address Specific
10 Destination Address Specific
11 Globally Unique
QoSコード分野00のQoS形式タイプが01のソースアドレスの特定の10送付先アドレス特定の11をグローバルに予約した、ユニーク
The rest of the first octet is reserved and must be zero. The remainder of the Parameter Value field specifies the QoS as described in the following Clauses.
最初の八重奏の残りは、予約されていて、ゼロであるに違いありません。 Parameter Value分野の残りは以下のClausesで説明されるようにQoSを指定します。
7.5.6.1 Source Address Specific
7.5.6.1 ソースアドレス特有です。
The QoS Format Code value of binary "01" indicates that the remaining octets of the parameter value field specify a QoS which is unique and unambiguous in the context of the QoS Maintenance system employed by the authority responsible for assigning the source NSAP Address.
QoS Format Codeが評価する、バイナリーでは、「1インチは、パラメタ値の分野の残っている八重奏がソースNSAPアドレスを割り当てるのに原因となる権威によって使われたQoSメインテナンスシステムの文脈でユニークで明白なQoSを指定するのを示します」。
7.5.6.2 Destination Address Specific
7.5.6.2 送付先アドレス特有です。
The QoS Format Code value of binary "10" indicates that the remaining octets of the parameter value field specify a QoS which is unique and unambiguous in the context of the QoS Maintenance system employed by the authority responsible for assigning the destination NSAP Address.
QoS Format Codeが評価する、バイナリーでは、「10インチは、パラメタ値の分野の残っている八重奏が送付先NSAPアドレスを割り当てるのに原因となる権威によって使われたQoSメインテナンスシステムの文脈でユニークで明白なQoSを指定するのを示します」。
7.5.6.3 Globally Unique QoS
7.5.6.3 グローバルにユニークなQoS
The QoS Format Code value of binary "11" indicates that the remainder of the parameter value field specifies a globally unique QoS Mainte- nance field. When the globally unique QoS Maintenance function is em- ployed, the parameter value field must have a total length of one oc- tet, which is assigned the following values:
QoS Format Codeが評価する、バイナリーでは、「11インチは、パラメタ値の分野の残りがグローバルにユニークなQoS Mainte- nance分野を指定するのを示します」。 グローバルにユニークなQoS Maintenance機能がem- ployedであるときに、パラメタ値の分野には、以下の値が割り当てられる1oc- tetの全長がなければなりません:
Bits 8 and 7: QoS Format Code of binary "11"
ビット8と7: 2進の「11インチ」のQoS Format Code
ISO 8473 [Page 43] RFC 994 December 1986
ISO8473[43ページ]RFC994 1986年12月
Bit 6: Reserved
Bit 5: sequencing vs. transit delay
Bit 4: congestion experienced
Bit 3: transit delay vs. cost
Bit 2: residual error probability vs. transit delay
Bit 1: residual error probability vs. cost
ビット6: 予約されたビット5: トランジットに対して配列して、Bit4を遅らせてください: 混雑はBit3になりました: トランジット遅れ対費用Bit2: 見逃し誤り確率対トランジット遅れBit1: 見逃し誤り確率対費用
Bit 5 is set to one to indicate that, where possible, routing deci- sions should favor sending all PDUs to the specified destination NSAP address over a single path (in order to maintain sequence) over minimizing transit delay. A value of zero (0) indicates that, where possible, routing decisions should favor low transit delay over se- quence preservation.
1つにビット5がそれを示すように設定されて、可能であるところでは、ルーティングデシsionsは、トランジット遅れを最小にする上のただ一つの経路(系列を維持するために)にわたる指定された送付先NSAPアドレスにすべてのPDUsを送るのを支持するはずです。 (0)がない値は、可能であるところに決定を発送すると低いトランジット遅れがse- quence保存より好まれるべきであるのを示します。
Bit 4 is set to zero by the network-entity which originates the pro- tocol data unit. It is set to one by an intermiediate system to indi- cate that this PDU has visited a congested intermediate system, and appropriate action should be taken by the destination network-entity. Once the congestion experienced bit is set by an intermediate system, it may not be reset by any intermediate system traversed by the PDU further along the path towards the destination.
ビット4は親tocolデータ単位を溯源するネットワーク実体によってゼロに設定されます。 目的地ネットワーク実体でこのPDUが混雑している中間システムを訪問して、動作を当てるのをさせるindi美味へのintermiediateシステムによる1つへのセットを取るべきであるということです。 混雑経験豊富なビットが中間システムによっていったん設定されると、それはPDUによって目的地に向かって経路に沿って、より遠くに横断されたどんな中間システムによってもリセットされないかもしれません。
Bit 3 is set to one to indicate that, where possible, routing deci- sions should favor low transit delay over low cost. A value of 0 in- dicates that routing decisions should favor low cost over low transit delay.
1つにビット3が、可能であるところでは、ルーティングデシsionsが低価格より低いトランジット遅れを好むはずであるのを示すように設定されます。 決定を発送して、低いトランジット遅れより低価格を好むはずである0コネdicatesの値。
Bit 2 set to one to indicate that, where possible, routing decisions should favor low residual error probability over low transit delay. A value of zero indicates that routing decisions should favor low transit delay over low residual error probability.
1つにそれを示すように設定されたビット2、可能であるところでは、ルーティング決定が低いトランジット遅れより低見逃し誤り確率を好むべきです。 ゼロの値は、ルーティング決定が低見逃し誤り確率より低いトランジット遅れを好むべきであるのを示します。
Bit 1 is set to one to indicate that, where possible, routing deci- sions should favor low residual error probability over low cost. A value of 0 indicates that routing decisions should favor low cost over low residual error probability.
1つにビット1が、可能であるところでは、ルーティングデシsionsが低価格より低見逃し誤り確率を好むはずであるのを示すように設定されます。 0の値は、ルーティング決定が低見逃し誤り確率より低価格を好むべきであるのを示します。
7.5.7 Priority
7.5.7 優先権
The value of the Priority parameter indicates the relative priority of the protocol data unit. Intermediate systems that support this option shall make use of this information in routing and in ordering PDUs for transmission.
Priorityパラメタの値はプロトコルデータ単位の相対的な優先権を示します。 このオプションをサポートする中間システムはトランスミッションにルーティングとPDUsを注文する際にこの情報を利用するものとします。
Parameter Code: 1100 1101
パラメタコード: 1100 1101
Parameter Length: one octet
パラメタの長さ: 1つの八重奏
Parameter Value: 0000 0000 - Normal (Default) through
0000 1110 - Highest
<all other values reserved>
パラメタ値: 0000 0000--0000 1110を通した標準(デフォルト)--最も高い<は他のすべての値の予約された>です。
ISO 8473 [Page 44] RFC 994 December 1986
ISO8473[44ページ]RFC994 1986年12月
The values 0000 0001 through 0000 1110 are to be used for higher priority protocol data units. If an intermediate system does not sup- port this option, all PDUs shall be treated as if the field had the value 0000 0000.
値0000 0001〜0000 1110は、より高い優先権プロトコルデータ単位に使用されることです。 中間システムがポートをすすらないなら、このオプションであり、まるで分野には値0000 0000があるかのようにすべてのPDUsが扱われるものとします。
7.6 Data Part
7.6 データ部分
The Data part of the PDU is structured as an ordered multiple of oc- tets, which is identical to the same ordered multiple of octets specified for the NS-Userdata parameter of the N-UNITDATA Request and Indication primitives. The data field is illustrated in Figure 8:
PDUのData部分はoc- tetsの命令された倍数として構造化されます。(oc- tetsはN-UNITDATA RequestのNS-Userdataパラメタに指定された八重奏とIndication基関数の同じ命令された倍数と同じです)。 データ・フィールドは図8で例証されます:
Octet
___________________________________________________
| | p + 1
: Data :
| | z
|__________________________________________________|
八重奏___________________________________________________ | | p+1: データ: | | z|__________________________________________________|
Figure 8: PDU Header -- Data Field
エイト環: PDUヘッダー--データ・フィールド
ISO 8473 [Page 45] RFC 994 December 1986
ISO8473[45ページ]RFC994 1986年12月
7.7 Data (DT) PDU
7.7 データ(DT)PDU
7.7.1 Structure
7.7.1 構造
The DT PDU has the following format:
DT PDUには、以下の形式があります:
__________________________________________
| Network Layer Protocol Identifier | 1
|________________________________________|
| Length Indicator | 2
|________________________________________|
| Version/Protocol Id Extension | 3
|________________________________________|
| Lifetime | 4
|________________________________________|
| S P vline M S vline e/R | Type | 5
|____________________________|___________|
| Segment Length | 6,7
|________________________________________|
| Checksum | 8,9
|________________________________________|
| Destination Address Length Indicator | 10
|________________________________________|
| | 11
: Destination Address :
|________________________________________| m - 1
| Source Address Length Indicator | m
|________________________________________|
| | m + 1
: Source Address :
| | n - 1
|________________________________________|
| Data Unit Identifier | n, n + 1
|________________________________________|
| Segment Offset | n + 2, n + 3
|________________________________________|
| Total Length | n + 4, n + 5
|________________________________________|
| | n + 6
| Options |
| | p
|________________________________________|
| | p + 1
| Data |
| | z
|________________________________________|
__________________________________________ | ネットワーク層プロトコル識別子| 1 |________________________________________| | 長さのインディケータ| 2 |________________________________________| | バージョン/プロトコルイド拡大| 3 |________________________________________| | 生涯| 4 |________________________________________| | S P vline M S vline e/R| タイプ| 5 |____________________________|___________| | セグメントの長さ| 6,7 |________________________________________| | チェックサム| 8,9 |________________________________________| | 目的地アドレス長さのインディケータ| 10 |________________________________________| | | 11 : 送付先アドレス: |________________________________________| m--1| ソースアドレス長さのインディケータ| m|________________________________________| | | m+1: ソースアドレス: | | n--1|________________________________________| | データ単位識別子| n、n+1|________________________________________| | セグメントオフセット| n+2、n+3|________________________________________| | 全長| n+4、n+5|________________________________________| | | n+6| オプション| | | p|________________________________________| | | p+1| データ| | | z|________________________________________|
Figure 9: DT PDU
図9: DT PDU
ISO 8473 [Page 46] RFC 994 December 1986
ISO8473[46ページ]RFC994 1986年12月
7.7.1.1 Fixed Part
7.7.1.1 固定部分
1) Network Layer Protocol Identifier See Clause 7.2.2 2) Length Indicator See Clause 7.2.3 3) Version/Protocol Id Extension See Clause 7.2.4 4) Lifetime See Clause 7.2.5 5) SP, MS, E/R See Clause 7.2.6 6) Type Code See Clause 7.2.7 7) Segment Length See Clause 7.2.8 8) Checksum See Clause 7.2.9
1) ネットワーク層プロトコル識別子が第7.2.2 2節を見る、) 長さのインディケータが第7.2.3 3節を見る、) バージョン/プロトコルイド拡大が第7.2.4 4節を見る、) 寿命が第7.2.5 5節を見る、) SP、MS E/Rが第7.2.6 6節を見る、) タイプコードが第7.2.7 7節を見る、) セグメントの長さが第7.2.8 8節を見る、) チェックサムは第7.2節.9を見ます。
7.7.1.2 Addresses
7.7.1.2 アドレス
See Clause 7.3.
第7.3節を見てください。
7.7.1.3 Segmentation
7.7.1.3 分割
See Clause 7.4.
第7.4節を見てください。
7.7.1.4 Options
7.7.1.4 オプション
See Clause 7.5.
第7.5節を見てください。
7.7.1.5 Data
7.7.1.5 データ
See Clause 7.7.
第7.7節を見てください。
7.8 Inactive Network Layer Protocol
7.8 不活発なネットワーク層プロトコル
Octet
____________________________________
|Network Layer Protocol Identifier | 1
|__________________________________|
| | 2
| Data |
| | 2 - n
|__________________________________|
八重奏____________________________________ |ネットワーク層プロトコル識別子| 1 |__________________________________| | | 2 | データ| | | 2--n|__________________________________|
Figure 10: Inactive Network Layer Protocol
図10: 不活発なネットワーク層プロトコル
7.8.1 Network Layer Protocol Id
7.8.1 ネットワーク層プロトコルイド
The value of the Network Layer Protocol Identifier field is binary zero (0000 0000).
Network LayerプロトコルIdentifier分野の値はバイナリーが(0000 0000)のゼロに合っているということです。
7.8.2 Data Field
7.8.2 データ・フィールド
The length of the NS-Userdata parameter is constrained to be less than or equal to the value of the length of the SN-Userdata parameter minus one (see Clause 7.7).
NS-Userdataパラメタの長さは1を引いたSN-Userdataパラメタの長さの、より値であることが抑制されます(Clause7.7を見てください)。
ISO 8473 [Page 47] RFC 994 December 1986
ISO8473[47ページ]RFC994 1986年12月
7.9 Error Report PDU (ER)
7.9 エラー・レポートPDU(えー)
7.9.1 Structure
7.9.1 構造
The ER PDU has the following format:
ER PDUには、以下の形式があります:
Octet
______________________________________________
| Network Layer Protocol Identifier | 1
|____________________________________________|
| Length Indicator | 2
|____________________________________________|
| Version/Protocol Id Extension | 3
|____________________________________________|
| Lifetime | 4
|____________________________________________|
| SP= 0 vline MS= 0 vline Reserved | Type | 5
|_____________________________________|______|
| Segment Length | 6,7
|____________________________________________|
| Checksum | 8,9
|____________________________________________|
| Destination Address Length Indicator | 10
|____________________________________________|
| | 11
: Destination Address :
| | m - 1
|____________________________________________|
| Source Address Length Indicator | m
|____________________________________________|
| | m + 1
: Source Address :
| | n - 1
|____________________________________________|
| | n
| Options |
| | p - 1
|____________________________________________|
| | p
| Reason for Discard |
| | q - 1
|____________________________________________|
| | q
| Error Report Data Field |
| | z
|____________________________________________|
八重奏______________________________________________ | ネットワーク層プロトコル識別子| 1 |____________________________________________| | 長さのインディケータ| 2 |____________________________________________| | バージョン/プロトコルイド拡大| 3 |____________________________________________| | 生涯| 4 |____________________________________________| | SP=0vline MS=0vline Reserved| タイプ| 5 |_____________________________________|______| | セグメントの長さ| 6,7 |____________________________________________| | チェックサム| 8,9 |____________________________________________| | 目的地アドレス長さのインディケータ| 10 |____________________________________________| | | 11 : 送付先アドレス: | | m--1|____________________________________________| | ソースアドレス長さのインディケータ| m|____________________________________________| | | m+1: ソースアドレス: | | n--1|____________________________________________| | | n| オプション| | | p--1|____________________________________________| | | p| 破棄の理由| | | q--1|____________________________________________| | | q| エラー・レポートデータ・フィールド| | | z|____________________________________________|
Figure 11: Error Report PDU
図11: エラー・レポートPDU
ISO 8473 [Page 48] RFC 994 December 1986
ISO8473[48ページ]RFC994 1986年12月
7.9.1.1 Fixed Part
7.9.1.1 固定部分
The fixed part of the Error Report Protocol Data Unit is composed in the same way as a new (Initial) Data PDU. References are provided to previous Clauses describing the encoding of the fields comprising the fixed part:
新しい(初期の)データPDUと同様に、Error ReportプロトコルData Unitの固定部分は構成されます。 固定部分を包括する分野のコード化について説明する前のClausesに参照を提供します:
1) Network Layer Protocol Identifier See Clause 7.2.2
2) Length Indicator See Clause 7.2.3
3) Version/Protocol Id Extension See Clause 7.2.4
4) Lifetime See Clause 7.2.5
5) SP, MS, E/R Always set to zero,
(See Clause 6.10)
6) Type Code See Clause 7.2.7
7) Segment Length See Clause 7.2.8
8) Checksum See Clause 7.2.9
1) ネットワーク層プロトコル識別子が第7.2.2 2節を見る、) 長さのインディケータが第7.2.3 3節を見る、) バージョン/プロトコルイド拡大が第7.2.4 4節を見る、) 寿命が第7.2.5 5節を見る、) SP、MS、ゼロに用意ができているE/R Always(Clause6.10を見ます) 6) タイプコードが第7.2.7 7節を見る、) セグメントの長さが第7.2.8 8節を見る、) チェックサムは第7.2節.9を見ます。
7.9.1.2 Addresses
7.9.1.2 アドレス
See Clause 7.3.
第7.3節を見てください。
The Destination Address specifies the network-entity title of the origi- nator of the discarded PDU. The Source Address specifies the title of the intermediate-system or end-system network-entity initiating the Error Report PDU.
Destination Addressは捨てられたPDUのorigi- natorのネットワーク実体タイトルを指定します。 Source Addressは、Error Report PDUを開始しながら、中間システムか終わりの体系網実体のタイトルを指定します。
7.9.1.3 Options
7.9.1.3 オプション
See Clause 7.5.
第7.5節を見てください。
ISO 8473 [Page 49] RFC 994 December 1986
ISO8473[49ページ]RFC994 1986年12月
7.9.1.4 Reason for Discard
7.9.1.4 破棄の理由
This parameter is valid only for the Error Report PDU.
Error Report PDUだけに、このパラメタは有効です。
Parameter Code: 1100 0001
Parameter Length: two octets
Parameter Value: type of error encoded in binary. Values are listed
in Table 7:
_______________________________________________________________________________
| Parameter Value | Class of | Meaning |
| Octet 1 Octet 2| Error | |
|__________________|_____________|_____________________________________________|
| 0000 0000 | | Reason not specified |
| 0001 | | Protocol Procedure Error |
| 0010 | | Incorrect Checksum |
| 0011 | General | PDU Discarded due to Congestion |
| 0100 | | Header Syntax Error (cannot be parsed) |
| 0101 | | Segmentation needed but not permitted |
| 0110 | | Incomplete PDU Received |
| 0111 | | Duplicate Option |
|__________________|_____________|_____________________________________________|
| 1000 0000 | Address | Destination Address Unreachable |
| 0001 | | Destination Address Unknown |
|__________________|_____________|_____________________________________________|
| 1001 0000 | | Unspecified Source Routing Error |
| 0001 | Source | Syntax Error in Source Routing Field |
| 0010 | Routing | Unknown Address in Source Routing Field |
| 0011 | | Path not Acceptable |
|__________________|_____________|_____________________________________________|
| 1010 0000 | Lifetime | Lifetime Expired while Data Unit in Transit |
| 0001 | | Lifetime Expired during Reassembly |
|__________________|_____________|_____________________________________________|
| 1011 0000 | | Unsupported Option not Specified |
| 0001 | PDU | Unsupported Protocol Version |
| 0010 | Discarded | Unsupported Security Option |
| 0011 | | Unsupported Source Routing Option |
| 0100 | | Unsupported Recording of Route Option |
|__________________|_____________|_____________________________________________|
| 1100 0000 | Reassembly | Reassembly interference |
|__________________|_____________|_____________________________________________|
パラメタコード: 1100 0001パラメタの長さ: 2八重奏Parameter Value: バイナリーでコード化された誤りのタイプ。 値はTable7に記載されています: _______________________________________________________________________________ | パラメタ値| 属します。| 意味| | 八重奏1八重奏2| 誤り| | |__________________|_____________|_____________________________________________| | 0000 0000 | | 理由は指定しませんでした。| | 0001 | | プロトコル手順誤り| | 0010 | | 不正確なチェックサム| | 0011 | 一般| CongestionによるPDU Discarded| | 0100 | | ヘッダーSyntax Error(分析できません)| | 0101 | | 分割は、必要でしたが、可能にしませんでした。| | 0110 | | 不完全なPDUは受信しました。| | 0111 | | オプションをコピーしてください。| |__________________|_____________|_____________________________________________| | 1000 0000 | アドレス| 送付先アドレス手が届きません。| | 0001 | | 目的地住所不明| |__________________|_____________|_____________________________________________| | 1001 0000 | | 不特定のソースルート設定誤り| | 0001 | ソース| ソースルート設定分野の構文エラー| | 0010 | ルート設定| ソースルート設定分野の未知のアドレス| | 0011 | | 許容できない経路| |__________________|_____________|_____________________________________________| | 1010 0000 | 生涯| 寿命はトランジットにおけるデータ単位である間、期限が切れました。| | 0001 | | 寿命はReassemblyの間、期限が切れました。| |__________________|_____________|_____________________________________________| | 1011 0000 | | 非サポート・オプションは指定しませんでした。| | 0001 | PDU| サポートされないプロトコルバージョン| | 0010 | 捨てられます。| サポートされないセキュリティオプション| | 0011 | | サポートされないソースルート設定オプション| | 0100 | | ルートオプションのサポートされない録音| |__________________|_____________|_____________________________________________| | 1100 0000 | Reassembly| Reassembly干渉| |__________________|_____________|_____________________________________________|
Table 7: Reasons for Discard
テーブル7: 破棄の理由
The first octet of the parameter value contains an error type code. If the error in the discarded Data PDU can be localized to a particu- lar field, the number of the first octet of that field is stored in the second octet of the reason for discard parameter field. If the error cannot be localized to a particular field, or if the error is a checksum error, then the value zero is stored in the second octet of the reason for discard parameter field.
パラメタ価値の最初の八重奏は誤りタイプコードを含んでいます。 捨てられたData PDUの誤りをparticu- lar分野にローカライズすることができるなら、その分野の最初の八重奏の数はパラメタがさばく破棄の理由の2番目の八重奏で保存されます。 特定の分野に誤りをローカライズすることができないか、または誤りがチェックサム誤りであるなら、値ゼロはパラメタがさばく破棄の理由の2番目の八重奏で保存されます。
ISO 8473 [Page 50] RFC 994 December 1986
ISO8473[50ページ]RFC994 1986年12月
7.9.1.5 Error Report Data Field
7.9.1.5 エラー・レポートデータ・フィールド
This field contains the entire header of the discarded Data PDU, and may contain some or all of the data field of the discarded PDU.
この分野は、捨てられたData PDUの全体のヘッダーを含んでいて、捨てられたPDUのデータ・フィールドのいくつかかすべてを含むかもしれません。
8 Conformance
8 順応
For conformance to this International Standard, the ability to ori- ginate, manipulate, and receive PDUs in accordance with the full pro- tocol (as opposed to the non-segmenting or Inactive Network Layer Protocol subsets) is required.
これへの順応において、国際Standard(ori- ginateへの能力)がPDUsを操作して、受ける完全な親tocol(非区分かInactive Network Layerプロトコル部分集合と対照的に)が必要です。
Additionally, conformance to the Standard requires provision of the protocol functions described in Clause 6. Provision of the optional functions described in Clause 6.18 and enumerated in Table 9-1 must meet the requirements described therein. Exceptions to this require- ment are described in Clause 8.1 below.
さらに、Standardへの順応はClause6で説明されたプロトコル機能の支給を必要とします。 Clause6.18で説明されて、Table9-1で列挙された任意の機能の支給はそこに説明された必要条件を満たさなければなりません。 以下のClause8.1でmentに説明されますこれへの例外が、必要である。
Additionally, conformance to the Standard requires adherence to the structure and encoding of PDUs of Clause 7.
さらに、Standardへの順応はClause7のPDUsの構造とコード化に固守を必要とします。
If and only if the above requirements are met is there conformance to this International Standard.
そして、上記の必要条件が満たされる場合にだけ、この国際規格への順応がありますか?
8.1 Provision of Functions for Conformance
8.1 順応のための機能の支給
The following table categorizes the functions in Clause 6 with respect to the type of system providing the function:
以下のテーブルは機能を提供しながら、Clause6でシステムのタイプに関して機能を分類します:
Note:
以下に注意してください。
1. The support of the PDU Composition and Forward PDU functions
is necessary for the generation of Error Report PDUs.
1. PDU CompositionとForward PDU機能のサポートがError Report PDUsの世代に必要です。
2. The Segment PDU function is in general mandatory for an
intermediate system. However, a system which is to be
connected only to subnetworks all offering the same maximum
SDU size (such as identical Local Area Networks) will not
need to perform this function and therefore does not need to
implement it.
2. 一般に、Segment PDU機能はそうです。中間システムに、義務的です。 しかしながら、同じ最大のSDUサイズ(同じローカル・エリア・ネットワークなどの)を提供するサブネットワークだけにすべて、接続されることであるシステムは、この機能を実行する必要はなくて、したがって、それを実装する必要はありません。
If this function is not implemented, this shall be stated
as part of the specification of the implementation.
この機能が実装されないなら、これは実装の仕様の一部として述べられるものとします。
3. The correct treatment of the padding function requires no
processing. A conforming implementation shall support the
function, to the extent of ignoring this parameter wherever
it may appear.
3. 詰め物機能の正しい処理は、処理するのを必要としません。 従う実装はどこに見えてもこのパラメタを無視する範囲に機能をサポートするものとします。
4. This function may or may not be supported. If an
implementation does not support this function, and the
4. この機能はサポートされるかもしれません。 そして実装がこの機能をサポートしないなら。
ISO 8473 [Page 51] RFC 994 December 1986
ISO8473[51ページ]RFC994 1986年12月
function is selected in a PDU, then the PDU shall be discarded,
and an ER PDU shall be generated and forwarded to the
originating network-entity if the Error Report flag is set
and the conditions of Clause 6.10.4 are satisfied.
機能がPDUで選択されて、次に、PDUが捨てられるものとして、Error Report旗がClauseのセットと状態であるなら起因するネットワーク実体にER PDUを生成して、送るものとする、6.10、.4、満たされています。
5. This function may or may not be supported. If an implementation
does not support this function, and the function is selected
in a PDU, then the function is not performed and the PDU is
processed exactly as though the function had not been
selected. The PDU shall not be discarded for this reason.
5. この機能はサポートされるかもしれません。 実装がこの機能をサポートしないで、機能がPDUで選択されるなら、機能は実行されません、そして、まるでちょうど機能が選択されていないかのようにPDUは処理されます。 この理由でPDUを捨てないものとします。
___________________________________________________________________
| Function | Send | Forward | Receive |
|____________________________|____________|___________|___________|
| PDU Composition | M | (Note 1) | (Note 1) |
| PDU Decomposition | M | - | M |
| Header Format Analysis | - | M | M |
| PDU Lifetime Control | | M | I |
| Route PDU | - | M | - |
| Forward PDU | M | M | (Note 1) |
| Segment PDU | M | (Note 2) | - |
| Reassemble PDU | - | I | M |
| Discard PDU | - | M | M |
| Error Reporting | M | M | M |
| Header Error Detection | (Note 3) | M | M |
| | | | |
| Security | - | (Note 3) | (Note 4) |
| Complete Source Routing | - | (Note 4) | - |
| Complete Route Recording | - | (Note 4) | - |
| Partial Source Routing | - | (Note 5) | - |
| Partial Route Recording | - | (Note 5) | - |
| Priority | - | (Note 5) | - |
| QoS Maintenance | - | (Note 5) | - |
| Congestion Notification | - | (Note 5) | - |
| Padding | - | (Note 5) | (Note 3) |
|____________________________|____________|___________|___________|
___________________________________________________________________ | 機能| 発信してください。| 転送| 受信してください。| |____________________________|____________|___________|___________| | PDU構成| M| (注意1) | (注意1) | | PDU分解| M| - | M| | ヘッダー形式分析| - | M| M| | PDU生涯コントロール| | M| I| | ルートPDU| - | M| - | | 前進のPDU| M| M| (注意1) | | セグメントPDU| M| (注意2) | - | | PDUを組み立て直してください。| - | I| M| | PDUを捨ててください。| - | M| M| | 誤り報告| M| M| M| | ヘッダー誤り検出| (注意3) | M| M| | | | | | | セキュリティ| - | (注意3) | (注意4) | | 完全なソースルート設定| - | (注意4) | - | | 完全なルート録音| - | (注意4) | - | | 部分的なソースルート設定| - | (注意5) | - | | 部分的なルート録音| - | (注意5) | - | | 優先権| - | (注意5) | - | | QoSメインテナンス| - | (注意5) | - | | 混雑通知| - | (注意5) | - | | 詰め物| - | (注意5) | (注意3) | |____________________________|____________|___________|___________|
Table 8: Categorization of Functions
Key:
テーブル8: 機能キーの分類:
M: Mandatory Function; this function must be implemented.
M: 義務的な機能。 この機能を実装しなければなりません。
-: Not applicable.
-: 適切でない。
I: Implementation option, as described in the text.
私: テキストで説明されるような実装オプション。
NOTE: See notes above
以下に注意してください。 上記を注意見てください。
ISO 8473 [Page 52]
ISO8473[52ページ]
一覧
スポンサーリンク
