RFC926 日本語訳

0926 Protocol for providing the connectionless mode network services.International Organization for Standardization. December 1984. (Format: TXT=165895 bytes) (Obsoleted by RFC0994) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                                ISO
Request for Comments: 926                                  December 1984

ネットワークワーキンググループISOはコメントのために以下を要求します。 926 1984年12月

    Protocol for Providing the Connectionless-Mode Network Services

コネクションレスなモードネットワーク・サービスを提供するためのプロトコル

                         (Informally - ISO IP)

(非公式に--、ISO IP)

                              ISO DIS 8473

ISOは8473をけなします。

Status of this Memo:

このMemoの状態:

 This document is distributed as an RFC for information only.  It does
 not specify a standard for the ARPA-Internet.  Distribution of this
 memo is unlimited.

このドキュメントは情報だけのためのRFCとして配布されます。 それはARPA-インターネットの規格を指定しません。 このメモの分配は無制限です。

Note:

以下に注意してください。

 This document has been prepared by retyping the text of ISO DIS 8473 of
 May 1984, which is currently undergoing voting within ISO as a Draft
 International Standard (DIS).  Although this RFC has been reviewed
 after typing, and is believed to be substantially correct, it is
 possible that typographic errors not present in the ISO document have
 been overlooked.

このドキュメントは、1984年5月のISO DIS8473のテキストを再びタイプで打つことによって、準備されました。5月は現在、国際規格案(DIS)としてISOの中の票を受けています。 このRFCはタイプした後に見直されて、実質的に正しいと信じられていますが、ISOドキュメントの現在でない誤植が見落とされたのは、可能です。

 Alex McKenzie
 BBN


アレックスマッケンジーBBN

RFC 926                                                    December 1984


RFC926 1984年12月

RFC 926                                                    December 1984

RFC926 1984年12月

                           TABLE OF CONTENTS

目次

 1   SCOPE AND FIELD OF APPLICATION........................ 2

1 AND応用分野を見てください… 2

 2   REFERENCES............................................ 3

2つの参照箇所… 3

 3   DEFINITIONS........................................... 4
 3.1   Reference Model Definitions......................... 4
 3.2   Service Conventions Definitions..................... 4
 3.3   Network Layer Architecture Definitions.............. 4
 3.4   Network Layer Addressing Definitions................ 5
 3.5   Additional Definitions.............................. 5

3つの定義… 4 3.1 規範モデル定義… 4 3.2 コンベンション定義を修理してください… 4 3.3 ネットワーク層アーキテクチャ定義… 4 3.4 ネットワーク層アドレシング定義… 5 3.5 追加定義… 5

 4   SYMBOLS AND ABBREVIATIONS............................. 7
 4.1   Data Units.......................................... 7
 4.2   Protocol Data Units................................. 7
 4.3   Protocol Data Unit Fields........................... 7
 4.4   Parameters.......................................... 8
 4.5   Miscellaneous....................................... 8

4 AND略語を象徴します… 7 4.1 データユニット… 7 4.2 データ単位について議定書の中で述べてください… 7 4.3 データ単位分野について議定書の中で述べてください… 7 4.4のパラメタ… 8 4.5その他… 8

 5   OVERVIEW OF THE PROTOCOL.............................. 9
 5.1   Internal Organization of the Network Layer.......... 9
 5.2   Subsets of the Protocol............................. 9
 5.3   Addressing......................................... 10
 5.4   Service Provided by the Network Layer.............. 10
 5.5   Service Assumed from the Subnetwork Service
    Provider.............................................. 11
 5.5.1   Subnetwork Addresses............................. 12
 5.5.2   Subnetwork Quality of Service.................... 12
 5.5.3   Subnetwork User Data............................. 13
 5.5.4   Subnetwork Dependent Convergence Functions....... 13
 5.6   Service Assumed from Local Evironment.............. 14

プロトコルの5概要… 9 5.1 ネットワーク層の内部の組織… 9 プロトコルの5.2の部分集合… 9 5.3 扱います。 10 5.4 ネットワーク層によって提供されたサービス… 10 5.5 サブネットワークサービスプロバイダーから想定されたサービス… 11 5.5 .1 サブネットワークアドレス… 12 5.5 .2 サブネットワークサービスの質… 12 5.5 .3 サブネットワーク利用者データ… 13 5.5 .4 サブネットワークの依存する集合は機能します… 13 5.6 サービスは地方からEvironmentを仮定しました… 14

 6   PROTOCOL FUNCTIONS................................... 16
 6.1   PDU Composition Function........................... 16
 6.2   PDU Decomposition Function......................... 17
 6.3   Header Format Analysis Function.................... 17
 6.4   PDU Lifetime Control Function...................... 18
 6.5   Route PDU Function................................. 18
 6.6   Forward PDU Function............................... 19
 6.7   Segmentation Function.............................. 19
 6.8   Reassembly Function................................ 20
 6.9   Discard PDU Function............................... 21

6 機能について議定書の中で述べてください… 16 6.1PDU構成機能… 16 6.2PDU分解機能… 17 6.3ヘッダー形式分析機能… 17 6.4PDU生涯コントロール機能… 18 6.5 ルートPDUは機能します… 18 6.6 前方に、PDUは機能します… 19 6.7分割機能… 19 6.8 Reassemblyは機能します… 20 6.9 PDU機能を捨ててください… 21

ISO DIS 8473 (May 1984)                                         [Page i]


ISOは8473(1984年5月)をけなします。[ページi]

RFC 926                                                    December 1984

RFC926 1984年12月

 6.10   Error Reporting Function.......................... 22
 6.10.1   Overview........................................ 22
 6.10.2   Requirements.................................... 23
 6.10.3   Processing of Error Reports..................... 24
 6.11   PDU Header Error Detection........................ 25
 6.12   Padding Function.................................. 26
 6.13   Security.......................................... 26
 6.14   Source Routing Function........................... 27
 6.15   Record Route Function............................. 28
 6.16   Quality of Service Maintenance Function........... 29
 6.17   Classification of Functions....................... 29

6.10誤り報告機能… 22 6.10.1 概要… 22 6.10.2 要件… 23 6.10.3 誤りの処理は報告します… 24 6.11 PDUヘッダー誤り検出… 25 6.12 機能を水増しします… 26 6.13セキュリティ… 26 6.14 ソース経路選択機能… 27 6.15 ルート機能を記録してください… 28 6.16サービスの質メインテナンス機能… 29 6.17 機能の分類… 29

 7   STRUCTURE AND ENCODING OF PDUS....................... 32
 7.1   Structure.......................................... 32
 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............................................ 36
 7.2.6.1   Segmentation Permitted and More Segments Flags. 36
 7.2.6.2   Error Report Flag.............................. 37
 7.2.7   Type Code........................................ 37
 7.2.8   PDU Segment Length............................... 37
 7.2.9   PDUChecksum...................................... 38
 7.3   Address Part....................................... 38
 7.3.1   General.......................................... 38
 7.3.1.1     Destination and Source Address Information... 39

7 PDUSのANDコード化を構造化してください… 32 7.1 構造… 32 7.2 部分を固定します… 34 7.2 .1一般… 34 7.2 .2 ネットワーク層プロトコル識別子… 34 7.2 .3長さのインディケータ… 35 7.2 .4 バージョン/プロトコル識別子拡張子… 35 7.2 .5PDU生涯… 35 7.2 .6 弛みます… 36 7.2 .6 .1 受入れられた分割と、より多くのセグメント旗。 36 7.2 .6 .2エラー・レポート旗… 37 7.2 .7 コードをタイプしてください… 37 7.2 .8 PDUセグメントの長さ… 37 7.2 .9PDUChecksum… 38 7.3アドレス部… 38 7.3 .1一般… 38 7.3 .1 .1の目的地とソースは情報を扱います… 39

 7.4   Segmentation Part.................................. 40
 7.4.1   Data Unit Identifier............................. 41
 7.4.2   Segment Offset................................... 41
 7.4.3   PDU Total Length................................. 41
 7.5   Options Part....................................... 41
 7.5.1   General.......................................... 41
 7.5.2   Padding.......................................... 43
 7.5.3   Security......................................... 43
 7.5.4   Source Routing................................... 44
 7.5.5   Recording of Route............................... 45
 7.5.6   Quality of Service Maintenance................... 46
 7.6   Priority........................................... 47

7.4 分割部分… 40 7.4 .1データユニット識別子… 41 7.4 .2セグメントは相殺されました… 41 7.4 .3PDU、全長… 41 7.5のオプションが離れています… 41 7.5 .1一般… 41 7.5 .2 そっと歩きます… 43 7.5 .3セキュリティ… 43 7.5 .4 ソースルート設定… 44 7.5 .5 ルートの録音… 45 7.5 .6 サービスの質メインテナンス… 46 7.6優先権… 47

ISO DIS 8473 (May 1984)                                        [Page ii]


ISOは8473(1984年5月)をけなします。[ページii]

RFC 926                                                    December 1984

RFC926 1984年12月

 7.7   Data Part.......................................... 47
 7.8   Data (DT) PDU...................................... 49
 7.8.1   Structure........................................ 49
 7.8.1.1   Fixed Part..................................... 50
 7.8.1.2   Addresses...................................... 50
 7.8.1.3   Segmentation................................... 50
 7.8.1.4   Options........................................ 50
 7.8.1.5   Data........................................... 50
 7.9   Inactive Network Layer Protocol.................... 51
 7.9.1   Network Layer Protocol Id........................ 51
 7.9.2   Data Field....................................... 51
 7.10   Error Report PDU (ER)............................. 52
 7.10.1   Structure....................................... 52
 7.10.1.1   Fixed Part.................................... 53
 7.10.1.2   Addresses..................................... 53
 7.10.1.3   Segmentation.................................. 53
 7.10.1.4   Options....................................... 54
 7.10.1.5   Reason for Discard............................ 54
 7.10.1.6   Error Report Data Field....................... 55

7.7のデータが離れています… 47 7.8 データ(DT)PDU… 49 7.8 .1 構造… 49 7.8 .1 .1 部分を固定します… 50 7.8 .1 .2 扱います。 50 7.8 .1 .3分割… 50 7.8 .1 .4のオプション… 50 7.8 .1 .5のデータ… 50 7.9 不活発なネットワーク層プロトコル… 51 7.9 .1 ネットワーク層プロトコルアイダホ州… 51 7.9 .2データ・フィールド… 51 7.10 エラー・レポートPDU(えー)… 52 7.10.1 構造… 52 7.10.1.1 固定部分… 53 7.10.1.2 アドレス… 53 7.10.1.3 分割… 53 7.10.1.4 オプション… 54 7.10.1.5 破棄には、推論してください… 54 7.10.1.6 エラー・レポートデータ・フィールド… 55

 8   FORMAL DESCRIPTION................................... 56
 8.1   Values of the State Variable....................... 57
 8.2   Atomic Events...................................... 57
 8.2.1   N.UNITDATA_request and N.UNITDATA_indication..... 57
 8.2.2   SN.UNITDATA_request and SN.UNITDATA_indication... 58
 8.2.3   TIMER Atomic Events.............................. 59
 8.3   Operation of the Finite State Automation........... 59
 8.3.1   Type and Constant Definitions.................... 61
 8.3.2   Interface Definitions............................ 65
 8.3.3   Formal Machine Definition........................ 67

8 正式な記述… 56 州の変数の8.1の値… 57 8.2の原子イベント… 57 8.2 N.UNITDATA_が要求する.1とN.UNITDATA_指示… 57 8.2 .2SN.UNITDATA_要求とSN.UNITDATA_指示… 58 8.2 .3 タイマの原子イベント… 59 8.3 有限州のオートメーションの操作… 59 8.3 .1 タイプと一定の定義… 61 8.3 .2 定義を連結してください… 65 8.3 .3 正式なマシン定義… 67

 9   CONFORMANCE.......................................... 84
 9.1   Provision of Functions for Conformance............. 84

9順応… 84 9.1 順応のための機能の支給… 84

ISO DIS 8473 (May 1984)                                       [Page iii]


ISOは8473(1984年5月)をけなします。[ページiii]

RFC 926                                                    December 1984

RFC926 1984年12月

ISO DIS 8473 (May 1984)                                        [Page iv]


ISOは8473(1984年5月)をけなします。[ページiv]

RFC 926                                                    December 1984

RFC926 1984年12月

INTRODUCTION

序論

 This Protocol is one of a set of International Standards produced to
 facilitate the interconnection of open systems. The set of standards
 covers the services and protocols required to achieve such
 interconnection.

このプロトコルはオープンシステムのインタコネクトを容易にするために生産された国際Standardsの1セットの1つです。規格のセットはサービスをカバーしています、そして、プロトコルがそのようなインタコネクトを達成するのが必要です。

 This Protocol Standard is positioned with respect to other related
 standards by the layers defined in the Reference Model for Open Systems
 Interconnection (ISO 7498). In particular, it is a protocol of the
 Network Layer. The Protocol herein described is a Subnetwork
 Independent Convergence Protocol combined with relay and routing
 functions as described in the Internal Organization of the Network
 Layer (ISO iiii). This Protocol provides the connectionless-mode
 Network Service as defined in ISO 8348/DAD1, Addendum to the Network
 Service Definition Covering Connectionless-mode Transmission, between
 Network Service users and/or Network Layer relay systems.

このプロトコルStandardはオープン・システム・インターコネクション(ISO7498)のためにReference Modelで定義された層のそばに他の関連する規格に関して置かれます。 それは特に、Network Layerのプロトコルです。 ここに説明されたプロトコルはNetwork Layer(ISO iiii)のInternal Organizationで説明されるようにリレーと経路選択機能に結合されたSubnetwork無党派Convergenceプロトコルです。 このプロトコルはISO8348/DAD1で定義されるようにコネクションレスなモードNetwork Serviceを提供します、Network Service Definition Covering Connectionless-モードTransmissionへのAddendum、Network Serviceユーザ、そして/または、Network Layerリレー方式の間で。

 The interrelationship of these standards is illustrated in Figure 0-1
 below:

これらの規格の相互関係は以下の図0-1で例証されます:

      ______________OSI Network Service Definition______________  
                    |                             ^               
                                                  |               
                    |                             |               
         Protocol     Reference to aims __________|               
                    |

______________OSIネットワーク・サービス定義______________ | ^ | | | 目的へのプロトコルReference__________| |

      Specification | Reference to assumptions ___                
                                                  |               
                    |                             |               
                                                  |               
                    |                             |               
                                                  |               
                    |                             v               
      ______________Subnetwork Service Definition(s) ___________

仕様| 仮定の参照___ | | | | | | | | v______________サブネットワークサービス定義___________

              Figure 0-1.  Interrelationship of Standards

図0-1。 規格の相互関係

ISO DIS 8473 (May 1984)                                         [Page 1]

ISOは8473(1984年5月)をけなします。[1ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

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 ISO
 8348/DAD1, Addendum to the Network Service Definition Covering
 Connectionless-mode Transmission. The protocol herein described relies
 upon the provision of a connectionless-mode subnetwork service.

この国際規格はConnectionless-モードNetwork Serviceを提供するのにISO8348/DAD1(Network Service Definition Covering Connectionless-モードTransmissionへのAddendum)で説明されるように使用されるプロトコルを指定します。 ここに説明されたプロトコルはコネクションレスなモードサブネットワークサービスの支給を当てにします。

 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 used for the transmission
      of data and control information, comprising a variable-length
      protocol header format;

b) プロトコルデータ単位のコード化はデータとコントロールのトランスミッションに情報を使用しました、可変長のプロトコルヘッダー形式を包括して。

  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 a subnetwork service
      provider through the exchange of subnetwork service primitives.

c) ネットワーク実体とサブネットワークサービス基関数の交換によるサブネットワークサービスプロバイダーとの相互作用。

ISO DIS 8473 (May 1984)                                         [Page 2]

ISOは8473(1984年5月)をけなします。[2ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

2  REFERENCES

2つの参照箇所

 ISO 7498       Information Processing Systems - Open Systems
                Interconnection - Basic Reference Model

ISO7498情報処理システム--オープン・システム・インターコネクション--基本参照モデル

 DP 8524        Information Processing Systems - Open Systems
                Interconnection - Addendum to ISO 7498 Covering
                Connectionless-Mode Transmission

DP8524情報処理システム--オープン・システム・インターコネクション--コネクションレス型伝送をカバーするISO7498への付加物

 DIS 8348       Information Processing Systems - Data Communications -
                Network Service Definition

8348個の情報処理システム--データ通信--ネットワーク・サービス定義をけなしてください。

 ISO 8348/DAD1  Information Processing Systems - Data Communications -
                Addendum to the Network Service Definition Covering
                Connectionless-Mode Transmission

ISO8348/DAD1情報処理システム--データ通信--コネクションレス型伝送をカバーするネットワーク・サービス定義への付加物

 ISO 8348/DAD2  Information Processing Systems - Data Communications -
                Addendum to the Network Service Definition Covering
                Network Layer Addressing

ISO8348/DAD2情報処理システム--データ通信--ネットワーク層アドレシングをカバーするネットワーク・サービス定義への付加物

 DP iiii        Information Processing Systems - Data Communications -
                Internal Organization of the Network Layer

DP iiii情報Processing Systems--データCommunications--Network Layerの内部のOrganization

 DP 8509        Information Processing Systems - Open Systems
                Interconnection - Service Conventions

DP8509情報処理システム--オープン・システム・インターコネクション--サービスコンベンション

 ISO TC97/SC16  A Formal Description Technique based on an N1825
                Extended State Transition Model

N1825 Extended州Transition Modelに基づくISO TC97/SC16A Formal記述Technique

ISO DIS 8473 (May 1984)                                         [Page 3]

ISOは8473(1984年5月)をけなします。[3ページ]

RFC 926                                                    December 1984

RFC926 1984年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) Network layer
   b) Network service
   c) Network service access point
   d) network service access point address
   e) Network entity
   f) Routing
   f) Service
   h) Network protocol
   i) Network relay
   j) Network protocol data unit
   k) End system

a) ネットワーク層b) ネットワーク・サービスc) ネットワーク・サービスアクセスポイントd)ネットワーク・サービスアクセスポイントアドレスe) ネットワーク実体f) ルート設定f) サービスh) ネットワーク・プロトコルi) ネットワークリレーj) ネットワーク・プロトコルデータ単位k) エンドシステム

 3.2  Service Conventions Definitions

3.2 サービスコンベンション定義

  This document makes use of the following concepts from the OSI Service
  Conventions (ISO 8509):

このドキュメントはOSI Service Conventions(ISO8509)からの以下の概念を利用します:

   l) Service user
   m) Service provider

l) サービス利用者m) サービスプロバイダー

 3.3  Network Layer Architecture Definitions

3.3 ネットワーク層アーキテクチャ定義

  This document makes use of the following concepts from the Internal
  Organization of the Network Layer (ISO iiii):

このドキュメントはNetwork Layer(ISO iiii)のInternal Organizationからの以下の概念を利用します:

   n) Subnetwork

n) サブネットワーク

ISO DIS 8473 (May 1984)                                         [Page 4]

ISOは8473(1984年5月)をけなします。[4ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   o) Relay system
   p) Intermediate system
   q) Subnetwork service

o) リレー方式p) 中間システムq) サブネットワークサービス

 3.4  Network Layer Addressing Definitions

3.4 ネットワーク層アドレシング定義

  This document makes use of the following concepts from DIS 8348/DAD2,
  Addendum to the Network Service Definition Covering Network layer
  addressing:

このドキュメントはDIS8348/DAD2からの以下の概念を利用します、Network Service Definition Covering Network層のアドレシングへのAddendum:

   r) Network entity title
   s) Network protocol address information
   t) Subnetwork address
   u) Domain

r) ネットワーク実体タイトルs) ネットワーク・プロトコルアドレス情報t) サブネットワークアドレスu) ドメイン

 3.5  Additional Definitions

3.5 追加定義

  For the purposes of this document, the following definitions apply:

このドキュメントの目的のために、以下の定義は申し込まれます:

   a) automaton    -  a machine designed to follow automatically a
                      predetermined sequence of operations or to respond
                      to encoded instructions.

a) オートマトン--自動的に操作の予定された順序に従うか、またはコード化された指示に応じるように設計されたマシン。

   b) local matter -  a decision made by a system concerning its
                      behavior in the Network Layer that is not subject
                      to the requirements of this Protocol.

b)地域にかかわる事柄--このプロトコルの要件を受けることがないNetwork Layerでシステムによって振舞いに関してされた決定。

   c) segment      -  part of the user data provided in the N_UNITDATA
                      request and delivered in the N_UNITDATA
                      indication.

c)セグメント--利用者データの一部が、UNITDATAが要求するN_に供給して、N_UNITDATA指示で配送されました。

   d) initial PDU  -  a protocol data unit carrying the whole of the
                      user data from an N_UNITDATA request.

d) PDUに頭文字をつけてください--UNITDATAが要求するN_から利用者データの全体を運ぶプロトコルデータ単位。

   e) 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.

e)はPDUを引き出しました--UNITDATAが要求するN_から利用者データのセグメントだけを運ぶのを除いて、分野が初期のPDUのものと同じであるプロトコルデータ単位。

ISO DIS 8473 (May 1984)                                         [Page 5]

ISOは8473(1984年5月)をけなします。[5ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   f) 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.
                      [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.]

f)分割--初期の、または、派生しているPDUから2かさらに派生しているPDUSを生成する行為。 一緒に派生しているPDUsはそれらが生成された初期の、または、派生しているPDUの全体の利用者データを運びます。 [注意: そのような初期のPDUがUNITDATAが要求する特定のN_のために実際に決して生成されないのは、可能です、分割の即座のアプリケーションのために。]

   g) reassembly   -  the act of regenerating an initial PDU (in order
                      to issue an N_UNITDATA indication) from two or
                      more derived PDUs produced by segmentation.

g)再アセンブリ--2以上から初期のPDU(N_UNITDATA指示を発行するために)を作り直す行為は分割によって生産されたPDUsを引き出しました。

ISO DIS 8473 (May 1984)                                         [Page 6]

ISOは8473(1984年5月)をけなします。[6ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

4  SYMBOLS AND ABBREVIATIONS

4つのシンボルと略語

 4.1  Data Units

4.1 データユニット

  PDU          Protocol Data Unit
  NSDU         Network Service Data Unit
  SNSDU        Subnetwork Service Data Unit

PDUプロトコルデータ単位NSDUネットワーク・サービスデータ単位SNSDUサブネットワークサービスデータ単位

 4.2  Protocol Data Units

4.2 プロトコルデータ単位

  DT PDU       Data Protocol Data Unit
  ER PDU       Error Report Protocol Data Unit

DT PDUデータがえー、エラー・レポートが議定書の中で述べるデータ単位PDUについて議定書の中で述べる、データ単位

 4.3  Protocol Data Unit Fields

4.3 プロトコルデータ単位分野

  NPID         Network Layer Protocol Identifier
  LI           Length Indicator
  V/P          Version/protocol Identifier Extension
  LT           Lifetime
  SP           Segmentation Permitted Flag
  MS           More Segments Flag
  E/R          Error Report Flag
  TP           Type
  SL           Segment Length
  CS           Checksum
  DAL          Destination Address Length
  DA           Destination Address
  SAL          Source Address Length
  SA           Source Address
  DUID         Data Unit Identifier
  SO           Segment Offset
  TL           Total Length

NPIDネットワーク層プロトコル識別子LI長さのインディケータV/Pバージョン/プロトコル識別子拡大LT生涯SP分割がFlag MSより多くのセグメント旗のE/Rエラー・レポート旗のTPでタイプSLセグメント長さのCsチェックサムDAL目的地アドレス長さのDAに目的地アドレスサラソウジュソースアドレス長さのSAソースアドレスDUIDデータ単位識別子を可能にしたので、セグメントはTl全長を相殺しました。

ISO DIS 8473 (May 1984)                                         [Page 7]

ISOは8473(1984年5月)をけなします。[7ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 4.4  Parameters

4.4 パラメタ

  DA           Destination Address
  SA           Source Address
  QOS          Quality of Service

DA目的地アドレスSAソースアドレスQOSサービスの質

 4.5  Miscellaneous

4.5 その他

  SNICP        Subnetwork Independent Convergence Protocol
  SNDCP        Subnetwork Dependent Convergence Protocol
  SNAcP        Subnetwork Access Protocol
  SN           Subnetwork
  P            Protocol
  NSAP         Network Service Access Point
  SNSAP        Subnetwork Service Access Point
  NPAI         Network Protocol Address Information
  NS           Network Service

独立している依存するSNICPのアクセスポイントSNSAPサブネットワークサービスアクセスポイントNPAIサブネットワーク集合プロトコルSNDCPサブネットワーク集合プロトコルSNAcPサブネットワークアクセス・プロトコルSNサブネットワークPプロトコルNSAPネットワーク・サービスネットワーク・プロトコルは、情報ナノ秒がネットワーク・サービスであると扱います。

ISO DIS 8473 (May 1984)                                         [Page 8]

ISOは8473(1984年5月)をけなします。[8ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

5  OVERVIEW OF THE PROTOCOL

プロトコルの5概要

 5.1  Internal Organization of the Network Layer

5.1 ネットワーク層の内部の組織

  The architecture of the Network Layer is described in a separate
  document, Internal Organization of the Network Layer (ISO iiii), in
  which an OSI Network Layer structure is defined, and a structure to
  classify protocols as an aid to the progression toward that structure
  is presented. This protocol is designed to be used in the context of
  the internetworking protocol approach defined in that document,
  between Network Service users and/or Network Layer relay systems. As
  described in the Internal Organization of the Network Layer, the
  protocol herein described is a Subnetwork Independent Convergence
  Protocol combined with relay and routing functions designed to allow
  the incorporation of existing network standards within the OSI
  framework.

Network Layerのアーキテクチャは、その構造に向かった進行への援助が提示されるときプロトコルを分類するために別々のドキュメント、Network LayerのInternal Organization(ISO iiii)、および構造で説明されます。(そこでは、OSI Network Layer構造が定義されます)。 このプロトコルはそのドキュメントで定義されたインターネットワーキングプロトコルアプローチの文脈で使用されるように設計されています、Network Serviceユーザ、そして/または、Network Layerリレー方式の間で。Network LayerのInternal Organizationで説明されるように、ここに説明されたプロトコルはOSIフレームワークの中で既存のネットワーク規格の編入を許すように設計されているリレーと経路選択機能に結合されたSubnetwork無党派Convergenceプロトコルです。

  A Subnetwork Independent Convergence Protocol is one which can be
  defined on a subnetwork independent basis and which is necessary to
  support the uniform appearance of the OSI Connectionless-mode Network
  Service between Network Service users and/or Network Layer relay
  systems over a set of interconnected homogeneous or heterogeneous
  subnetworks. This protocol is defined in just such a subnetwork
  independent way so as to minimize variability where subnetwork
  dependent and/or subnetwork access protocols do not provide the OSI
  Network Service.

Subnetwork無党派Convergenceプロトコルは1セットのインタコネクトされた均質の、または、異種のサブネットワークの上のNetwork Serviceユーザ、そして/または、Network Layerリレー方式の間のサブネットワークの独立ベースで定義できる、OSI Connectionless-モードNetwork Serviceの一定の外観をサポートするのに必要なものです。 このプロトコルはサブネットワークに依存しているところで可変性を最小にするためにまさしくそのようなサブネットワークの独立している方法で定義されます、そして、サブネットワークアクセス・プロトコルはOSI Network Serviceを提供しません。

  The subnetwork service required from the lower sublayers by the
  protocol described herein is identified in Section 5.5.

ここに説明されたプロトコルによって下側の副層から必要とされたサブネットワークサービスはセクション5.5で特定されます。

 5.2  Subsets of the Protocol

5.2 プロトコルの部分集合

  Two proper subsets of the full protocol are also defined which permit
  the use of known subnetwork characteristics, and are therefore not
  subnetwork independent.

また、完全なプロトコルの2つの真部分集合が定義されます(知られているサブネットワークの特性の使用を可能にして、したがって、サブネットワーク独立者ではありません)。

  One protocol subset is for use where it is known that the source and
  destination end-systems are connected by a single subnetwork. This is
  known as the "Inactive Network Layer Protocol" subset. A second subset
  permits simplification of the header where it is known that the source
  and destination end-systems are connected by subnetworks whose
  subnetwork service data unit (SNSDU) sizes are greater than or equal
  to a known bound large enough for segmentation not to be required.
  This subset, selected by setting the "segmentation permitted" flag to
  zero, is known as the "non-segmenting" protocol subset.

1つのプロトコル部分集合が使用のためにソースと目的地エンドシステムが単一のサブネットワークによって接されるのが知られているところにあります。 これは「不活発なネットワーク層プロトコル」部分集合として知られています。 2番目の部分集合はソースと目的地エンドシステムがサブネットワークサービスデータ単位(SNSDU)サイズが分割は大きい知られているバウンドが、より必要であるということであるサブネットワークによって接されるのが知られているヘッダーの簡素化を可能にします。 「分割は可能にした」という旗をゼロに設定することによって選択されたこの部分集合が「非区分」プロトコル部分集合として知られています。

ISO DIS 8473 (May 1984)                                         [Page 9]

ISOは8473(1984年5月)をけなします。[9ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 5.3  Addressing

5.3 アドレシング

  The Source Address and Destination Address parameters referred to in
  Section 7.3 of this International Standard are OSI Network Service
  Access Point Addresses. The syntax and semantics of an OSI Network
  Service Access Point Address, the syntax and encoding of the Network
  Protocol Address Information employed by this Protocol, and the
  relationship between the NSAP and the NPAI is described in a separate
  document, ISO 8348/DAD2, Addendum to the Network Service Definition
  covering Network Layer Addressing.

パラメタがこの国際規格のセクション7.3で言及したSource AddressとDestination AddressはOSI Network Service Access Point Addressesです。 構文、OSI Network Service Access Point Addressの意味論、構文、このプロトコルによって使われたNetworkプロトコルAddress情報のコード化、およびNSAPとNPAIとの関係は別々のドキュメントで説明されます、ISO8348/DAD2、Network Layer AddressingをカバーするNetwork Service DefinitionへのAddendum。

  The syntax and semantics of the titles and addresses used for relaying
  and routing are also described in ISO 8348/DAD2.

また、リレーとルーティングに使用されるタイトルとアドレスの構文と意味論はISO8348/DAD2で説明されます。

 5.4  Service Provided by the Network Layer

5.4 ネットワーク層によって提供されたサービス

  The service provided by the protocol herein described is a
  connectionless-mode Network Service. The connectionless-mode Network
  Service is described in document ISO 8348/DAD1, Addendum to the
  Network Service Definition Covering Connectionless-mode Transmission.
  The Network Service primitives provided are summarized below:

ここに説明されたプロトコルによって提供されたサービスはコネクションレスなモードNetwork Serviceです。 コネクションレスなモードNetwork ServiceはドキュメントISO8348/DAD1、Network Service Definition Covering Connectionless-モードTransmissionへのAddendumで説明されます。 基関数が提供したNetwork Serviceは以下へまとめられます:

ISO DIS 8473 (May 1984)                                        [Page 10]

ISOは8473(1984年5月)をけなします。[10ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

                 Primitives                Parameters          
      +--------------------------------------------------------+ 
      |                           |                            | 
      | N_UNITDATA Request        | NS_Destination_Address,    | 
      |            Indication     | NS_Source_Address,         | 
      |                           | NS_Quality_of_Service,     | 
      |                           | NS_Userdata                | 
      +--------------------------------------------------------+

基関数パラメタ+--------------------------------------------------------+ | | | | UNITDATAが要求するN_| ナノ秒_送付先_アドレス| | 指示| ナノ秒_ソース_アドレス| | | _サービスのナノ秒_品質_| | | ナノ秒_Userdata| +--------------------------------------------------------+

                 Table 5-1.  Network Service Primitives

5-1をテーブルの上に置いてください。 ネットワーク・サービス基関数

  The Addendum to the Network Service Definition Covering
  Connectionless-mode Transmission (ISO 8348/DAD1) states that the
  maximum size of a connectionless-mode Network-service-data-unit is
  limited to 64512 octets.

Network Service Definition Covering Connectionless-モードTransmission(ISO8348/DAD1)へのAddendumは、コネクションレスなモードNetworkサービスデータ単位の最大サイズが64512の八重奏に制限されると述べます。

 5.5  Service Assumed from the Subnetwork Service provider

5.5 Subnetwork ServiceプロバイダーからのサービスAssumed

  The subnetwork service required to support this protocol is defined as
  comprising the following primitives:

サービスがこのプロトコルをサポートするのを必要としたサブネットワークは以下の基関数を包括すると定義されます:

                Primitives                  Parameters           
      +--------------------------------------------------------+ 
      |                           |                            | 
      | SN_UNITDATA Request       | SN_Destination_Address,    | 
      |             Indication    | SN_Source_Address,         | 
      |                           | SN_Quality_of_Service,     | 
      |                           | SN_Userdata                | 
      +--------------------------------------------------------+

基関数パラメタ+--------------------------------------------------------+ | | | | UNITDATAが要求するSN_| SN_送付先_アドレス| | 指示| SN_ソース_アドレス| | | _サービスのSN_品質_| | | SN_Userdata| +--------------------------------------------------------+

               Table 5-2.  Subnetwork Service Primitives

5-2をテーブルの上に置いてください。 サブネットワークサービス基関数

ISO DIS 8473 (May 1984)                                        [Page 11]

ISOは8473(1984年5月)をけなします。[11ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  5.5.1  Subnetwork Addresses

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 addresses are defined in the Service Definition of each
   individual subnetwork.

ソースと送付先アドレスはトランスミッションにかかわる公共の、または、個人的なサブネットワークへの付属のポイントを指定します。 サブネットワークアドレスはそれぞれの個々のサブネットワークのService Definitionで定義されます。

   The syntax and semantics of subnetwork addresses are not defined in
   this Protocol Standard.

サブネットワークアドレスの構文と意味論はこのプロトコルStandardで定義されません。

  5.5.2  Subnetwork Quality of Service

5.5.2 サブネットワークサービスの質

   Subnetwork Quality of Service describes aspects of a subnetwork
   connectionless-mode service which are attributable solely to the
   subnetwork service provider.

ServiceのサブネットワークQualityは唯一サブネットワークサービスプロバイダーに起因するサブネットワークコネクションレスなモードサービスの局面について説明します。

   Associated with each subnetwork connectionless-mode transmission,
   certain measures of quality of service are requested when the
   primitive action is initiated. These requested measures (or parameter
   values and options) are based on a priori knowledge by the Network
   Service provider of the service(s) made available to it by the
   subnetwork. Knowledge of the nature and type of service available is
   typically obtained prior to an invocation of the subnetwork
   connectionless-mode service.

原始の動きが開始されるとき、それぞれのサブネットワークコネクションレス型伝送に関連していて、サービスの質のある基準は要求されます。 これらは、測定(または、パラメタ値とオプション)がサブネットワークでそれに利用可能にされたサービスのNetwork Serviceプロバイダーで先験的な知識に基づいているよう要求しました。 サブネットワークコネクションレスなモードサービスの実施の前に手があいているサービスの自然とタイプに関する知識を通常得ます。

    Note:

以下に注意してください。

     The quality of service parameters identified for the subnetwork
     connectionless-mode service may in some circumstances be directly
     derivable from or mappable onto those identified in the
     connectionless-mode Network Service; e.g., the parameters

サブネットワークコネクションレスなモードサービスのために特定されたサービスの質パラメタはそれらに直接誘導できるかmappableな特定されたコネがコネクションレスなモードNetwork Serviceであったならいくつかの事情でそうするかもしれません。 例えば、パラメタ

      a)  transit delay;
      b)  protection against unauthorized access;
      c)  cost determinants;
      d)  priority; and
      e)  residual error probability

a) トランジット遅れ。 不正アクセスに対するb)保護。 c) 決定因かかってください。 d)優先権。 そして、e)残差エラー確率

     as defined in ISO 8348/DAD1, Addendum to the Network Service
     Definition Covering Connectionless-mode Transmission, may be
     employed.

ISOで定義されるように、8348/DAD1(Network Service Definition Covering Connectionless-モードTransmissionへのAddendum)は使われるかもしれません。

ISO DIS 8473 (May 1984)                                        [Page 12]

ISOは8473(1984年5月)をけなします。[12ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

     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, the subnetwork service provider shall attempt to
     deliver the protocol data unit at whatever Quality of Service is
     available.

原始の動きが本来開始されるときパラメタとしてServiceのQualityを提供しないそれらのサブネットワークに関しては、要求されたサービスの意味論がどう保存されるかもしれないかに関してそれは地域にかかわる事柄です。 特に、要求されたServiceのQualityを維持できないインスタンスがあるかもしれません。 提供するそのような事情、サブネットワークサービスプロバイダーがプロトコルデータ単位を試みるものとするコネはServiceのQualityが何であっても利用可能です。

  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 service access points.

SN_Userdataを八重奏の命令された倍数であり、透過的に指定されたサブネットワークサービスアクセスポイントの間に移します。

   The subnetwork service is required to support a subnetwork service
   data unit size of at least the maximum size of the Data PDU header
   plus one octet of NS-Userdata. This requires a minimum subnetwork
   service data unit size of 256 octets.

サブネットワークサービスが、サブネットワークサービスデータ単位がData PDUヘッダーの最大サイズのサイズとNS-Userdataの1つの八重奏であるとサポートするのに必要です。 これは256の八重奏の最小のサブネットワークサービスデータ単位サイズを必要とします。

   Where the subnetwork service can support a subnetwork service data
   unit (SNSDU) size greater than the size of the Data PDU header plus
   one octet of NS_Userdata, the protocol may take advantage of this. In
   particular, if all SNSDU sizes of the subnetworks involved are known
   to be large enough that segmentation is not required, then the
   "non-segmenting" protocol subset may be used.

サブネットワークサービスが、サブネットワークサービスデータ単位(SNSDU)がData PDUヘッダーのサイズとNS_Userdataの1つの八重奏より大きいサイズであるとサポートすることができるところでは、プロトコルはこれを利用するかもしれません。 サブネットワークのSNSDUサイズがかかわったすべてが分割は必要でないほど大きいのが知られているなら、特に、「非区分」プロトコル部分集合が使用されるかもしれません。

  5.5.4  Subnetwork Dependent Convergence Functions

5.5.4 サブネットワークの依存する集合機能

   Subnetwork Dependent Convergence Functions may be performed to
   provide a connectionless-mode subnetwork service in the case where
   subnetworks also provide a connection-oriented subnetwork service. If
   a subnetwork provides a connection-oriented service, some subnetwork
   dependent function is assumed to provide a mapping into the required
   subnetwork service described in the preceding text.

サブネットワークDependent Convergence Functionsは、またサブネットワークが接続指向のサブネットワークサービスを提供するケースの中にコネクションレスなモードサブネットワークサービスを供給するために実行されるかもしれません。 サブネットワークがコネクション型サービスを提供するなら、サブネットワークに依存する何らかの機能が前のテキストで説明された必要なサブネットワークサービスにマッピングを提供すると思われます。

   A Subnetwork Dependent Convergence Protocol may also be employed in
   those cases where functions assumed from the subnetwork service
   provider are not performed.

また、Subnetwork Dependent Convergenceプロトコルはサブネットワークサービスプロバイダーから想定された機能が実行されないそれらの場合で使われるかもしれません。

ISO DIS 8473 (May 1984)                                        [Page 13]

ISOは8473(1984年5月)をけなします。[13ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 5.6  Service Assumed from Local Evironment

5.6 地方のEvironmentから想定されたサービス

  A timer service is 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;

1) S-TIMER要求。

   2)  the S_TIMER response; and

2) S_TIMER応答。 そして

   3)  the S_TIMER cancel.

3) S_TIMERは取り消します。

  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要求プリミティブは指定された名前と添字のタイマを開始して、パラメタによって指定された持続時間のためにそれを維持するべきであるのを地方の環境に示します。

  The S_TIMER response primitive is initiated by the local environment
  to indicate that the delay requested by the corresponding S_TIMER
  request primitive has elapsed.

S_TIMER応答プリミティブは地方の環境によって開始されて、遅れが、対応するSから_TIMER要求プリミティブが経過したよう要求したのを示します。

  The S_TIMER cancel primitive is an indication to the local environment
  that the specified timer(s) should be cancelled. If the subscript
  parameter is not specified, then all timers with the specified name
  are cancelled; 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キャンセル基関数は地方の環境への指定されたタイマが取り消されるべきであるという指示です。 添字パラメタが指定されないなら、指定された名前があるすべてのタイマが取り消されます。 さもなければ、名と添字のタイマは取り消されます。 タイマが全く指定されたパラメタに対応していないなら、地方の環境は行動を全く取りません。

  The parameters of the S_TIMER service primitives are:

S_TIMERサービス基関数のパラメタは以下の通りです。

ISO DIS 8473 (May 1984)                                        [Page 14]

ISOは8473(1984年5月)をけなします。[14ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

            Primitives                  Parameters             
      +--------------------------------------------------------+ 
      |                           |                            | 
      | S_TIMER Request           | S_Time                     | 
      |                           | S_Name                     | 
      |                           | S_Subscript                | 
      |                           |                            | 
      | S_TIMER Response          | S_Name                     | 
      |         Cancel            | S_Subscript                | 
      +--------------------------------------------------------+

基関数パラメタ+--------------------------------------------------------+ | | | | S_タイマ要求| S_時間| | | S_名| | | S_添字| | | | | S_タイマ応答| S_名| | キャンセル| S_添字| +--------------------------------------------------------+

                      Table 5-3.  Timer Primitives

5-3をテーブルの上に置いてください。 タイマ基関数

  The time parameter indicates the time duration of the specified timer.
  An identifying label is associated with a timer by means of the name
  parameter. The subscript parameter specifies a value to distinguish
  timers with the same name. The name and subscript taken together
  constitute a unique reference to the timer.

時間パラメタは指定されたタイマの時間持続時間を示します。 特定ラベルはパラメタという名前によるタイマに関連しています。 添字パラメタは、同じ名前でタイマを区別するために値を指定します。 一緒に取られた名前と添字はタイマのユニークな参照を構成します。

ISO DIS 8473 (May 1984)                                        [Page 15]

ISOは8473(1984年5月)をけなします。[15ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

SECTION TWO.  SPECIFICATION OF THE PROTOCOL

セクションTWO。 プロトコルの仕様

6  PROTOCOL FUNCTIONS

6 プロトコル機能

 This section describes the functions performed as part of the Protocol.

このセクションはプロトコルの一部として実行された機能について説明します。

 Not all of the functions must be performed by every implementation.
 Section 6.17 specifies which functions may be omitted and the correct
 behavior where 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 of protocol given in Section 7. Protocol
  Control Information required for delivering the data unit to its
  destination is determined from current state information and from the
  parameters provided with the N_UNITDATA Request; e.g., source and
  destination addresses, QOS, etc. User data passed from the Network
  Service user in the N_UNITDATA Request forms the Data field of the
  protocol data unit.

セクション7で与えられた典礼の規定事項によると、この機能はプロトコルデータ単位の工事に原因となります。 データ単位を送付先に提供するのに必要であるプロトコルControl情報はパラメタから現状情報と、そして、N_UNITDATA Requestが提供された決定しています。 例えば、ソースと送付先アドレス、QOSなど N_UNITDATA RequestのNetwork Serviceユーザから通過された利用者データはプロトコルデータ単位のData分野を形成します。

  During the composition of the protocol data unit, a Data Unit
  Identifier is assigned to identify uniquely all segments of the
  corresponding NS_Userdata. The "Reassemble PDU" function considers
  PDUs to correspond to the same Initial PDU, and hence N_UNITDATA
  request, if they have the same Source and Destination Addresses and
  Data Unit Identifier.

プロトコルデータ単位の構成の間、Data Unit Identifierは、唯一対応するNS_Userdataのすべてのセグメントを特定するために割り当てられます。 「PDUを組み立て直してください」という機能は、PDUsが同じInitial PDU、およびしたがって、UNITDATAが要求するN_に相当すると考えます、彼らが同じSource、Destination Addresses、およびData Unit Identifierを持っているなら。

  The Data Unit Identifier is available for ancillary functions such as
  error reporting. The originator of the PDU must choose the Data Unit
  Identifier so that it remains unique (for this Source and Destination
  Address pair) for the maximum lifetime of the PDU (or any Derived
  PDUs) in the network.

Data Unit Identifierは誤り報告などの補助的機能に利用可能です。 PDUの創始者がData Unit Identifierを選ばなければならないので、PDU(または、どんなDerived PDUsも)の最大の生涯、それはネットワークでユニークな(このSourceとDestination Address組)ままです。

ISO DIS 8473 (May 1984)                                        [Page 16]

ISOは8473(1984年5月)をけなします。[16ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  During the composition of the PDU, a value of the total length of the
  PDU 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の全長の値は、創始者によって決定されて、PDUヘッダーのTotal Length分野に置かれます。 この分野はプロトコルデータ単位の生涯のためのどんなDerived PDUでも変えられません。

  Where the non-segmenting subset is employed, neither the Total Length
  field nor the Data Unit Identifier field is present. During the
  composition of the protocol data unit, a value of the total length of
  the PDU 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.

非区分部分集合が採用しているところでは、Total Length分野もData Unit Identifier分野も存在していません。 プロトコルデータ単位の構成の間、PDUの全長の値は、創始者によって決定されて、PDUヘッダーのSegment Length分野に置かれます。 この分野はPDUの生涯に変わりません。

 6.2  PDU Decomposition Function

6.2 PDU分解機能

  This function is responsible for removing the Protocol Control
  Information from the protocol data unit. During this process,
  information pertinent to the generation of the N_UNITDATA Indication
  is retained. The data field of the PDU received is reserved until all
  segments of the original service data unit have been received; this is
  the NS_Userdata parameter of the N_UNITDATA Indication.

この機能はプロトコルデータ単位からプロトコルControl情報を取り除くのに原因となります。 このプロセスの間、N_UNITDATA Indicationの世代に適切な情報は保有されます。 PDUの分野が受け取ったデータはオリジナルのサービスデータ単位のすべてのセグメントを受け取るまで予約されています。 これはN_UNITDATA IndicationのNS_Userdataパラメタです。

 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
  indicating that this is a standard version of the Protocol, this
  function determines whether a PDU received has reached its destination
  using the destination address provided in the PDU is the same as the
  one which addresses an NSAP served by this network-entity, then the
  PDU has reached its destination; if not, it must be forwarded.

この機能はこのStandardで説明された完全なプロトコルが採用しているか、そして、それの定義された真部分集合の1つを決定します。 Network LayerプロトコルIdentifierが、プロトコルデータ単位でこれがプロトコルの標準版であることを示すなら、NSAPを扱うものがこのネットワーク実体で役立ったので、この機能は、受け取られたPDUがPDUに提供された送付先アドレスを使用することで目的地に到着したかどうかが、同じであることを決定します、次に、PDUは目的地に達しました。 そうでなければ、それを進めなければなりません。

  If the protocol data unit has a Network Layer Protocol Identifier
  indicating that the Inactive Network Layer Protocol subset is in use,
  then no further analysis of the PDU header is required. The

Network LayerプロトコルIdentifierが、プロトコルデータ単位でInactive Network Layerプロトコル部分集合が使用中であることを示すなら、PDUヘッダーのさらなる分析は全く必要ではありません。 The

ISO DIS 8473 (May 1984)                                        [Page 17]

ISOは8473(1984年5月)をけなします。[17ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  network-entity in this case determines that either the network address
  encoded in the network protocol address information of a supporting
  subnetwork protocol corresponds to a network Service Access Point
  address served by this network-entity, or that an error has occurred.
  If the subnetwork PDU has been delivered correctly, then the protocol
  data unit may be decomposed according to the procedure described for
  that particular subnetwork protocol.

ネットワーク実体はこの場合プロトコルがこのネットワーク実体によって役立たれるネットワークService Access Pointアドレスに対応しているか、または誤りが発生したというサポートサブネットワークに関するネットワーク・プロトコルアドレス情報でコード化されたネットワーク・アドレスを決定そんなにのどちらか。 サブネットワークPDUが正しく提供されたなら、その特定のサブネットワークプロトコルのために説明された手順によると、プロトコルデータ単位は分解されるかもしれません。

 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 whether
  its assigned lifetime has expired, in which case it must be discarded.

この機能は、最大のPDU生涯を実施するのに使用されます。 それは密接に「ヘッダー形式分析」機能に関連づけられます。 この機能は、PDUが受信したかどうか進めるかもしれないか、または割り当てられた寿命が期限が切れたか否かに関係なく、その場合、それを捨てなければならないことを決定します。

  The operation of the 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
  Milliseconds). The Lifetime of the Initial PDU is determined by the
  originating network-entity, and placed in the Lifetime field of the
  PDU.

Lifetime Control機能の操作はPDUヘッダーのLifetime分野に依存します。 この分野はいつでも、PDU(500Millisecondsのユニットで、表される)の残っている生涯を含みます。 Initial PDUのLifetimeは起因するネットワーク実体で決定して、PDUのLifetime分野に置かれます。

 6.5  Route PDU Function

6.5 ルートPDUは機能します。

  This function determines the network-entity to which a protocol data
  unit should be forwarded, using the destination NSAP address
  parameters, Quality of Service parameter, and/or other parameters. It
  determines the subnetwork which must be transited to reach that
  network-entity. Where segmentation occurs, it further determines which
  subnetwork(s) the segments may transit to reach that network-entity.

この機能はプロトコルデータ単位が送られるべきであるネットワーク実体を決定します、目的地NSAPアドレスパラメタ、ServiceパラメタのQuality、そして/または、他のパラメタを使用して。 それは、通過しなければならないサブネットワークがそのネットワーク実体に達することを決定します。 分割が起こるところでは、それは、セグメントがそのネットワーク実体に達するようにどのサブネットワークを通過するかもしれないかをさらに決定します。

ISO DIS 8473 (May 1984)                                        [Page 18]

ISOは8473(1984年5月)をけなします。[18ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 6.6  Forward PDU Function

6.6 前方に、PDUは機能します。

  This function issues a subnetwork service primitive (see Section 5.5)
  supplying the subnetwork identified by the "Route PDU" function with
  the protocol data unit as an SNSDU, and the address information
  required by that subnetwork to identify the "next" intermediate-system
  within the subnetwork-specific address domain.

この機能は、プロトコルデータ単位で「ルートPDU」機能によって特定されたサブネットワークを供給しながら、SNSDU、およびアドレス情報がそのサブネットワークが、サブネットワーク特有のアドレスドメインの中で「次」の中間システムを特定するのが必要であるので原始的に(セクション5.5を見ます)サブネットワークサービスを発行します。

  When an Error Report PDU is to be forwarded, and is longer than the
  maximum user data acceptable by the subnetwork, it shall be truncated
  to the maximum acceptable length ad forwarded with no other change.
  When a Data PDU is to be forwarded ad is longer than the maximum user
  data acceptable by the subnetwork, the Segmentation function is
  applied (See Section 6.7, which follows).

Error Report PDUが進めるためにあって、サブネットワークで許容できる最大の利用者データより長いときに、それは他の変化なしで転送された最大の許容できる長さの広告に先端を切られるものとします。 Data PDUが進められることになっているとき、広告はサブネットワーク、Segmentation機能で許容できる最大の利用者データが適用されているより長いです(続くセクション6.7を見てください)。

 6.7  Segmentation Function

6.7 分割機能

  Segmentation is performed when the size of the protocol data unit is
  greater than the maximum size of the user data parameter field of the
  subnetwork service primitive.

プロトコルデータ単位のサイズがサブネットワークサービスの利用者データパラメタ分野の最大サイズより原始的に大きいときに、分割は実行されます。

  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. The Protocol Control Information required to
  identify, route, and forward a PDU is duplicated in each PDU derived
  from the Initial PDU. The user data encapsulated within the PDU
  received is divided such that the Derived PDUs satisfy the size
  requirements of the user data parameter field of the subnetwork
  service primitive.

分割はPDUからの2新しいPDUs(PDUsを引き出す)が受けた構成から成ります。 受け取られたPDUはInitial PDUであるかもしれませんかそれがDerived PDUであるかもしれません。 Control情報がPDUを特定して、発送して、進めるのを必要としたプロトコルは、Initial PDUから得られた各PDUにコピーされます。 受け取られたPDUの中でカプセル化された利用者データが分割されているので、Derived PDUsは原始的にサブネットワークサービスの利用者データパラメタ分野のサイズ要件を満たします。

  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) データ単位識別子。

ISO DIS 8473 (May 1984)                                        [Page 19]

ISOは8473(1984年5月)をけなします。[19ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  The following fields of the PDU header are used in conjunction with
  the Segmentation function:

PDUヘッダーの以下の分野はSegmentation機能に関連して使用されます:

   a)  Segment Offset - identifies at which octet in the data field of
       the Initial PDU the segment begins;

a) セグメントOffset--セグメントがInitial PDUのデータ・フィールドでのどの八重奏のときに始まるかを特定します。

   b)  Segment Length - specifies the number of octets in the Derived
       PDU, including both header and data;

b) セグメントLength--ヘッダーとデータの両方を含むDerived PDUの八重奏の数を指定します。

   c)  More Segments Flag - 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) より多くのSegments Flag--このDerived PDUが利用者データの最終的な八重奏としてInitial PDUの最終的な八重奏を含まないなら、1つにセットしてください。 そして

   d)  Total Length - specifies the entire length of the Initial PDU,
       including both header and data.

d) 総Length--ヘッダーとデータの両方を含むInitial PDUの全長を指定します。

  Derived PDUs may be further segmented without constraining the routing
  of the individual Derived PDUs.

個々のDerived PDUsのルーティングを抑制しないで、派生しているPDUsはさらに区分されるかもしれません。

  A Segmentation Permitted flag is set to one to indicate that
  segmentation is permitted. If the Initial PDU is not to be segmented
  at any point during its lifetime in the network, the flag is set to
  zero.

1つにSegmentation Permitted旗が、分割が受入れられるのを示すように設定されます。 生涯、Initial PDUが任意な点でネットワークで区分されないつもりであるなら、旗はゼロに設定されます。

  When the "Segmentation Permitted" flag is set to zero, the non-
  segmenting protocol subset is in use.

「分割は可能にした」という旗がゼロに設定されるとき、非区分しているプロトコル部分集合が使用中です。

 6.8  Reassembly Function

6.8 Reassemblyは機能します。

  The Reassembly Function reconstructs the Initial PDU transmitted to
  the destination network-entity from the Derived PDUs generated during
  the lifetime of the Initial PDU.

Reassembly FunctionはInitial PDUの生涯生成されたDerived PDUsから目的地ネットワーク実体に伝えられたInitial PDUを再建します。

  A bound on the time during which segments (Derived PDUs) of an Initial
  PDU will be held at a reassembly point is provided so that resources
  may be released when it is no longer expected that any outstanding
  segments of the Initial PDU will arrive at the reassembly point. When
  such an event occurs, segments (Derived PDUs) of the Initial PDU held
  at the reassembly point are discarded, the resources allocated for
  those segments are freed,

もうInitial PDUのどんな傑出しているセグメントも再アセンブリポイントに到着しないと予想されるとき、リソースを発表できるようにInitial PDUのセグメント(PDUsを引き出す)が再アセンブリポイントで維持される時のバウンドを提供します。 そのようなイベントが起こるとき、再アセンブリポイントで持たれていたInitial PDUのセグメント(PDUsを引き出す)が捨てられる、それらのセグメントのために割り当てられたリソースは解放されます。

ISO DIS 8473 (May 1984)                                        [Page 20]

ISOは8473(1984年5月)をけなします。[20ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  and if selected, an Error Report is generated.

そして、選択されるなら、Error Reportは発生しています。

   Note:

以下に注意してください。

    The design of the Segmentation and Reassembly functions is intended
    principally to be used such that reassembly takes place at the
    destination. However, other schemes which

SegmentationとReassembly機能のデザインによって主に使用されることを意図するので、再アセンブリは目的地で行われます。 しかしながら、他はどれを計画するか。

     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/full reassembly at some point along the route
         where it is known that the subnetwork with the smallest PDU
         size has been transited

c) 最も小さいPDUサイズがあるサブネットワークが通過されたのが知られているルートに沿った何らかのポイントに部分的であるか完全な再アセンブリを許容してください。

    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.

排除されません。 これらの代替の戦略の1つの使用を可能にするのに必要な情報をNetwork Layer Management機能の操作で利用可能にするかもしれません。

    While the exact relationship between reassembly lifetime and PDU
    lifetime is a local matter, the reassembly algorithm 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.

再アセンブリ生涯とPDU生涯との正確な関係は地域にかかわる事柄ですが、再アセンブリアルゴリズムはPDU生涯の意図を保存しなければなりません。 その結果、再アセンブリ機能はそうでなければ彼らが再アセンブリ機能のコントロールの下にいなかったなら寿命が期限が切れたPDUsを捨てなければなりません。

 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 in any of the following
  situations (Note: the list is not exhaustive):

この機能は以下の状況のどれかにおけるネットワーク実体によって予約されたリソースを解放するのに必要な動作のすべてを実行します(注意: リストは徹底的ではありません):

   a)  A violation of protocol procedure has occurred.

a) プロトコル手順の違反は起こりました。

   b)  A PDU is received whose checksum is inconsistent with its
       contents.

b) 受け取られたチェックサムがコンテンツに反しているPDU。

ISO DIS 8473 (May 1984)                                        [Page 21]

ISOは8473(1984年5月)をけなします。[21ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   c)  A PDU is received, but due to 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 subnetwork
       service data unit size.

e) 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, and 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 the 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 the return of an Error Report PDU to the source
   network-entity when a protocol data unit is discarded. An "error
   report flag" in the original PDU is set by the source network-entity
   to indicate whether or not Error Report PDUs are to be returned.

プロトコルデータ単位が捨てられるとき、この機能はソースネットワーク実体へのError Report PDUの復帰を引き起こします。 ソースネットワーク実体で、オリジナルのPDUの「エラー・レポート旗」が、Error Report PDUsが返されることになっているかどうかを示すように設定されます。

   The Error Report PDU identifies the discarded PDU, specifies the type
   of error detected, and identifies the location at which the error was
   detected. Part or all of the discarded PDU is included in the data
   field of the Error Report PDU.

Error Report PDUは捨てられたPDUを特定して、検出された誤りのタイプを指定して、誤りが検出された位置を特定します。 捨てられたPDUの部分かすべてがError Report PDUのデータ・フィールドに含まれています。

   The address of the originator of the Data Protocol Data Unit is

DataプロトコルData Unitの創始者のアドレスはそうです。

ISO DIS 8473 (May 1984)                                        [Page 22]

ISOは8473(1984年5月)をけなします。[22ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   conveyed as both the destination address of the Error Report PDU as
   well as the source address of the original Data PDU; the latter is
   contained in the Data field of the Error Report PDU. The address of
   the originator of the Error Report PDU is contained in the source
   address field of the header of the Error Report PDU.

Error Report PDUの送付先アドレスとオリジナルのData PDUのソースアドレスの両方として、運ばれます。 後者はError Report PDUのData分野に保管されています。 Error Report PDUの創始者のアドレスはError Report PDUのヘッダーのソースアドレス・フィールドに保管されています。

    Note:

以下に注意してください。

     Non-receipt of an Error Report PDU does not imply correct delivery
     of a PDU issued by a source network-entity.

Error Report PDUの非領収書はソースネットワーク実体によって発行されたPDUの正しい配送を含意しません。

  6.10.2  Requirements

6.10.2 要件

   An Error Report PDU shall not be generated to report the discarding
   of a PDU that itself contains an Error Report.

Error Reportを含むPDU自身を捨てることを報告するためにError Report PDUを生成しないものとします。

   An Error Report PDU shall not be generated upon discarding of a PDU
   unless that PDU has the Error Report flag set to allow Error Reports.

そのPDUがError Report旗がError Reportsを許容するように設定させない場合PDUを捨てるとき、Error Report PDUを生成しないものとします。

   If a Data PDU is discarded, and has the Error Report flag set to
   allow Error Reports, an Error Report PDU shall be generated if the
   reason for discard (See Section 6.9)  is

破棄(セクション6.9を見る)の理由が生成されるなら、Data PDUが捨てられて、Error Report旗がError Reportsを許容するように設定させるなら、Error Report PDUは生成されるものとします。

    a)  destination address unreachable,

a) 送付先アドレス手が届きません。

    b)  source routing failure,

b)ソースルーティング失敗

    c)  unsupported options, or

またはc)非サポート・オプション。

    d)  protocol violation.

d) 違反について議定書の中で述べてください。

ISO DIS 8473 (May 1984)                                        [Page 23]

ISOは8473(1984年5月)をけなします。[23ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

    Note:

以下に注意してください。

     It is intended that this list shall include all nontransient
     reasons for discard; the list may therefore need to be amended or
     extended in the light of any changes made in the definitions of
     such reasons.

このリストが破棄のすべてのnontransient理由を含んでいるだろうことを意図します。 したがって、リストは、そのような理由の定義で行われたどんな変更の見地から修正されるか、または広げられる必要があるかもしれません。

   If a Data PDU with the Error Report flag set to allow Error Reports
   is discarded for any other reason, an Error Report PDU may be
   generated (as an implementation option).

Error Reportsを許容するように設定されたError Report旗があるData PDUがいかなる他の理由でも捨てられるなら、Error Report PDUは生成されるかもしれません(実装オプションとして)。

  6.10.3  Processing of Error Reports

6.10.3 エラー・レポートの処理

   Error Report PDUs are forwarded by intermediate network-entities in
   the same way as Data PDUs. It is possible that an Error Report PDU
   may be longer than the maximum user data size of a subnetwork that
   must be traversed to reach the origin of the discarded PDU. In this
   case, the Forward PDU function shall truncate the PDU to the maximum
   size acceptable.

Data PDUsと同様に、中間的ネットワーク実体で誤りReport PDUsを進めます。 Error Report PDUが捨てられたPDUの発生源に達するように横断しなければならないサブネットワークの最大の利用者データサイズより長いのは、可能です。 この場合、Forward PDU機能は許容できる最大サイズにPDUに先端を切らせるものとします。

   The entire header of the discarded data unit shall be included in the
   data field of the Error Report PDU. Some or all of the data field of
   the discarded data unit may also be included.

捨てられたデータ単位の全体のヘッダーはError Report PDUのデータ・フィールドに含まれているものとします。 また、捨てられたデータ単位のデータ・フィールドのいくつかかすべてが含まれるかもしれません。

    Note:

以下に注意してください。

     Since the suppression of Error Report PDUs is controlled by the
     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.

Error Report PDUsの抑圧がNS Userによって制御されるのではなく、起因するネットワーク実体によって制御されるので、注意がER PDUsを抑圧することに関して創始者によって行われるべきであるので、誤り報告は生成されたあらゆるPDUのために抑圧されるというわけではありません。

ISO DIS 8473 (May 1984)                                        [Page 24]

ISOは8473(1984年5月)をけなします。[24ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 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 PDU header. The checksum is verified at each
  point at which the PDU header is processed. If PDU header fields are
  modified (for example, due to lifetime function), then the checksum is
  modified so that the checksum remains valid.

PDU Header Error Detection機能はPDUヘッダーでの間違った情報の処理のため中間介在物か終わりの体系網実体の失敗から守ります。 機能はPDUヘッダーの上に計算されたチェックサムによって実現されます。 チェックサムはPDUヘッダーが処理される各ポイントで確かめられます。 PDUヘッダーフィールドが変更されているなら(例えば生涯機能のため)チェックサムが変更されているので、チェックサムは有効なままで残っています。

  An intermediate system network-entity must not recompute the checksum
  for the entire header, even if fields are modified.

分野が変更されていても、中間システムネットワーク実体は全体のヘッダーのためにチェックサムを再計算してはいけません。

   Note:

以下に注意してください。

    This is 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.

これは、中間システム(例えばメモリー障害のため)によってPDUが処理されている間ヘッダーの不注意な変更がPDU Header Error機能によってまだ検出されているかもしれないのを保証するためのものです。

  The use of this 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.

この機能の使用は、任意であり、起因するネットワーク実体によって選択されます。 機能が使用されていないなら、PDUヘッダーのチェックサム分野はゼロに設定されます。

  If the function is selected by the originating network-entity, the
  value of the checksum field causes the following formulae to be
  satisfied:

機能が起因するネットワーク実体によって選択されるなら、チェックサム分野の値で、以下の公式を満たします:

     L
   (SUM)     a   = 0  (modulo 255)
              i
     i=1

L(SUM)は=0(法255)i i=1です。

     L
   (SUM)     (L-i+1) a   = 0 (modulo 255)
                       i
     i=1

L(SUM)(L-i+1)は=0(法255)i i=1です。

    Where L = the number of octets in the PDU header, and
          a = value of octet at position i.
           i

Lが位置のi.iでPDUヘッダーの八重奏の数、および八重奏の=値と等しいところ

ISO DIS 8473 (May 1984)                                        [Page 25]

ISOは8473(1984年5月)をけなします。[25ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  When the function is in use, neither octet of the checksum field may
  be set to zero.

機能が使用中であるときに、チェックサム分野のどちらの八重奏もゼロに設定されないかもしれません。

  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 checksum field when the header is modified.

別館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 セキュリティ

  An issue related to the quality of the network service is the
  protection of information flowing between transport-entities. A system
  may wish to control the distribution of secure data by assigning
  levels of security to PDUs. As a local consideration, the Network
  Service user could be authenticated to ascertain whether the user has
  permission to engage in communication at a particular security level
  before sending the PDU. While no protocol exchange is required in the
  authentication process, the optional security parameter in the options
  part of the PDU header may be employed to convey the particular
  security level between peer network-entities.

ネットワーク・サービスの品質に関連する問題は輸送実体の間を流れる情報の保護です。 システムは、セキュリティのレベルをPDUsに割り当てることによって、安全なデータの分配を制御したがっているかもしれません。 地方の考慮として、ユーザにはPDUを送る前に特定のセキュリティー・レベルでコミュニケーションに従事する許可があるかどうかを確かめるためにNetwork Serviceユーザを認証できました。 プロトコル交換は全く認証過程で必要でない間、PDUヘッダーのオプション一部の任意のセキュリティパラメタが、同輩ネットワーク実体の間に特定のセキュリティー・レベルを伝えるのに使われるかもしれません。

  The syntax and semantics of the security parameter are not specified
  by this Standard. The security parameter is related to the "protection
  from unauthorized access" Quality of service parameter described in
  ISO 8348/DAD1, Addendum to the Network Service Definition Covering
  Connectionless-mode Transmission. However, to facilitate
  interoperation between end-systems and relay-systems by avoiding
  different interpretations of the same encoding, a mechanism is
  provided to distinguish user-defined security encoding from
  standardized security encoding.

セキュリティパラメタの構文と意味論はこのStandardによって指定されません。 セキュリティパラメタはISO8348/DAD1(Network Service Definition Covering Connectionless-モードTransmissionへのAddendum)で説明されたサービスパラメタの「不正アクセスからの保護」Qualityに関連します。 しかしながら、エンドシステムとリレー方式の間で同じコード化の異なった解釈を避けることによってinteroperationを容易にするなら、標準化されたセキュリティコード化とユーザによって定義されたセキュリティコード化を区別するためにメカニズムを提供します。

ISO DIS 8473 (May 1984)                                        [Page 26]

ISOは8473(1984年5月)をけなします。[26ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 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 can only be selected by the
  originator of a PDU. Source Routing is accomplished using a list of
  intermediate system addresses (or titles, see Section 5.3 and 5.5.1)
  held in a parameter within the options part of the PDU Header. The
  size of the option field is determined by the originating
  network-entity. The length of this option does not change as the PDU
  traverses the network. Associated with this list is an indicator which
  identifies the next entry in the list to be used; this indicator is
  advanced by the receiver of the PDU when the next address matches its
  own address. The indicator is updated as the PDU is forwarded so as to
  identify the appropriate entry at each stage of relaying.

Sourceルート設定機能で、創始者は発生しているPDUが取らなければならない経路を指定できます。 PDUの創始者はソースルーティングを選択できるだけです。 または、ソースルート設定が中間システムアドレスのリストを使用するのに優れている、(PDU Headerは、.1が)オプションの中にパラメタに保持したセクション5.3と5.5が離れているのを題をつけて、見ます。 オプション・フィールドのサイズは起因するネットワーク実体で決定します。 PDUがネットワークを横断するのに応じて、このオプションの長さは変化しません。 このリストに関連づけられているのは、使用されるためにリストにおける次のエントリーを特定するインディケータです。 次のアドレスがそれ自身のアドレスに合っていると、このインディケータはPDUの受信機によって進められます。 それぞれのステージのリレーで適切なエントリーを特定するためにPDUを進めるとき、インディケータをアップデートします。

  Two forms of the source routing option are provided. The first form,
  referred to as complete source routing, requires that the specified
  path must be taken; if the specified path cannot be taken, the PDU
  must be discarded. The source may be informed of the discard using the
  Error Reporting function described in Section 6.10.

ソースルーティングオプションの2つのフォームを提供します。 完全なソースルーティングと呼ばれた最初の書式は、指定された経路を取らなければならないのを必要とします。 指定された経路を取ることができないなら、PDUを捨てなければなりません。 破棄がセクション6.10で説明されたError Reporting機能を使用するのにおいてソースは知識があるかもしれません。

  The second form is referred to as partial source routing. Again, each
  address in the list must be visited in the order specified while on
  route to the destination. However, with this form of source routing
  the PDU may take any path necessary to arrive at the next address in
  the list. The PDU will not be discarded (for source routing related
  causes) unless one of the addresses specified cannot be reached by any
  available route.

2番目の書式は部分的なソースルーティングと呼ばれます。 一方、ルートに関して目的地に指定されたオーダーでリストの各アドレスを訪問しなければなりません。 しかしながら、このフォームのソースルーティングで、PDUはリストの次のアドレスに到着するのに必要などんな経路も取るかもしれません。 どんな利用可能なルートでも指定されたアドレスの1つに達することができると、PDUは捨てられないでしょう(ソースルーティングが原因を関係づけたので)。

ISO DIS 8473 (May 1984)                                        [Page 27]

ISOは8473(1984年5月)をけなします。[27ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 6.15  Record Route Function

6.15 記録的なルート機能

  The Record Route function permits the exact recording of the paths
  taken by a PDU as it traverses a series of interconnected subnetworks.
  A recorded route is composed of a list of intermediate system
  addresses held in a parameter within the options part of the PDU
  header. The size of the option field is determined by the originating
  network-entity. The length of this option does not change as the PDU
  traverses the network.

Record Route機能は一連のインタコネクトされたサブネットワークを横断するのに従ってPDUによって取られた経路の正確な録音を可能にします。 記録されたルートはPDUヘッダーのオプション一部の中にパラメタに保持された中間システムアドレスのリストで構成されます。 オプション・フィールドのサイズは起因するネットワーク実体で決定します。 PDUがネットワークを横断するのに応じて、このオプションの長さは変化しません。

  The list is constructed as the PDU traverses a set of interconnected
  subnetworks. Only intermediate system addresses are included in the
  recorded route. The address of the originator of the PDU is not
  recorded in the list. When an intermediate system network-entity
  processes a PDU containing the record route parameter, the system
  inserts its own address (or titles, see Sections 5.3 or 5.5.1) into
  the list of recorded addresses.

PDUが1セットのインタコネクトされたサブネットワークを横断するとき、リストは構成されます。 中間システムアドレスだけが記録されたルートに含まれています。 PDUの創始者のアドレスはリストに記録されません。 中間システムネットワーク実体が記録的なルートパラメタを含むPDUを処理するとき、システムがそれ自身のアドレスを挿入する、(または、タイトル、セクション5.3か5.5.1を)記録されたアドレスのリストの中に見てください。

  The record route option contains an indicator which identifies the
  next available octet to be used for recording of route. This
  identifier is updated as entries are added to the list. If the
  addition of the current address to the list would exceed the size of
  the option field, the indicator is set to show that recording of route
  has terminated. The PDU may still be forwarded to its final
  destination, without further addition of intermediate system
  addresses.

記録的なルートオプションはルートの録音に使用されるために次の利用可能な八重奏を特定するインディケータを含んでいます。 エントリーをリストに追加するとき、この識別子をアップデートします。 リストへの現在のアドレスの追加がオプション・フィールドのサイズを超えているなら、インディケータが、ルートの録音が終わったのを示すように設定されます。 中間システムアドレスのさらなる追加なしで最終的な目的地にPDUをまだ送っているかもしれません。

   Note:

以下に注意してください。

    The Record Route function is principally intended to be used in the
    diagnosis of network problems. Its mechanism has been designed on
    this basis, and may provide a return path.

Record Route機能によってネットワーク問題の診断に主に使用されるつもりです。メカニズムは、このベースで設計されていて、リターンパスを提供するかもしれません。

ISO DIS 8473 (May 1984)                                        [Page 28]

ISOは8473(1984年5月)をけなします。[28ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 6.16  Quality of Service Maintenance Function

6.16 サービスの質メインテナンス機能

  In order to support the Quality of Service requested by Network
  Service users, the Protocol may need to make QOS information available
  at intermediate systems. This information may be used by network
  entities in intermediate systems to make routing decisions where such
  decisions affect the overall QOS provided to NS users.

Network Serviceユーザによって要求されたServiceのQualityをサポートするために、プロトコルは、QOSを中間システムで利用可能な情報にする必要があるかもしれません。この情報は中間システムでネットワーク実体によって使用されて、ルーティングをそのような決定がどこでNSユーザに提供された総合的なQOSに影響するかという決定にするかもしれません。

  In those instances where the QOS indicated cannot be maintained, the
  NS provider will attempt to deliver the PDU at a QOS less than that
  indicated. The NS provider will not necessarily provide a notification
  of failure to meet the indicated quality of service.

それらのインスタンスでは、NSプロバイダーは、示されたQOSを維持できないところでそんなに示されるほどQOSでPDUを提供しないのを試みるでしょう。 NSプロバイダーは必ず示されたサービスの質を満たさないことの通知を提供するというわけではないでしょう。

 6.17  Classification of Functions

6.17 機能の分類

  Implementations do not have to support all of the functions described
  in Section 6. Functions are divided into three categories:

実装はセクション6で説明された機能のすべてをサポートする必要はありません。 機能は3つのカテゴリに分割されます:

   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 by a PDU, then the PDU shall be
            discarded, and an Error Report PDU shall be generated and
            forwarded to the originating network-entity, providing that
            the Error Report flag is set.

2はタイプします: これらの機能はサポートされるかもしれません。 実装がType2機能をサポートしないで、機能がPDUによって選択されるならPDUが捨てられるものとして、起因するネットワーク実体にError Report PDUを生成して、送るものとします、Error Report旗が設定されるなら。

   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 by a PDU, then the function is not
            performed and the PDU is processed exactly as though the
            function was not selected. The protocol data unit shall not
            be discarded.

3はタイプします: これらの機能はサポートされるかもしれません。 実装がType3機能をサポートしないで、機能がPDUによって選択されるなら、機能は実行されません、そして、まるでちょうど機能が選択されないかのようにPDUは処理されます。 プロトコルデータ単位を捨てないものとします。

  Table 6-1 shows how the functions are divided into these three
  categories:

テーブル6-1は機能がどうこれらの3つのカテゴリに分割されるかを示しています:

ISO DIS 8473 (May 1984)                                        [Page 29]

ISOは8473(1984年5月)をけなします。[29ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

         +---------------------------------------------------+
         | Function                       |  Type            |
         |--------------------------------|------------------|
         |                                |                  |
         | PDU Composition                |  1               |
         | PDU Decomposition              |  1               |
         | Header Format Analysis         |  1               |
         | PDU Lifetime Control           |  1               |
         | Route PDU                      |  1               |
         | Forward PDU                    |  1               |
         | Segment PDU                    |  1               |
         | Reassemble PDU                 |  1               |
         | Discard PDU                    |  1               |
         | Error Reporting                |  1 (note 1)      |
         | PDU Header Error Detection     |  1 (note 1)      |
         | Padding                        |  1 (notes 1   2) |
         | Security                       |  2               |
         | Complete Source Routing        |  2               |
         | Partial Source Routing         |  3               |
         | Priority                       |  3               |
         | Record Route                   |  3               |
         | Quality of Service Maintenance |  3               |
         +---------------------------------------------------+

+---------------------------------------------------+ | 機能| タイプ| |--------------------------------|------------------| | | | | PDU構成| 1 | | PDU分解| 1 | | ヘッダー形式分析| 1 | | PDU生涯コントロール| 1 | | ルートPDU| 1 | | 前進のPDU| 1 | | セグメントPDU| 1 | | PDUを組み立て直してください。| 1 | | PDUを捨ててください。| 1 | | 誤り報告| 1 (注意1)| | PDUヘッダー誤り検出| 1 (注意1)| | 詰め物| 1 (注意1 2)| | セキュリティ| 2 | | 完全なソースルート設定| 2 | | 部分的なソースルート設定| 3 | | 優先権| 3 | | ルートを記録してください。| 3 | | サービスの質メインテナンス| 3 | +---------------------------------------------------+

            Table 6-1.  Categorization of Protocol Functions

6-1をテーブルの上に置いてください。 プロトコル機能の分類

ISO DIS 8473 (May 1984)                                        [Page 30]

ISOは8473(1984年5月)をけなします。[30ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  Notes:

注意:

   1)  While the Padding, Error Reporting, and Header Error Detection
       functions must be provided, they are provided only when selected
       by the sending Network Service user.

1) Padding、Error Reporting、およびHeader Error Detection機能を提供しなければなりませんが、送付Network Serviceユーザが選択する場合にだけ、それらを提供します。

   2)  The correct treatment of the Padding function involves no
       processing. Therefore, this could equally be described as a Type
       3 function.

2) Padding機能の正しい処理は、処理することを伴いません。 したがって、等しくType3機能としてこれを記述できました。

   3)  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 and should not be the cause of the discarding of a PDU
       when not supported.

3) タイプ3機能の包含のための原理はいくつかの機能の場合では、それが中間システムの間にPDUsを送るか、またはエンドシステムにそれらを提供するために機能をサポートすることになっているより重要であるということです。 タイプ3機能は、それらが顧問に自然であるそれらの場合に使用されるべきであり、サポートされない場合、PDUを捨てることの原因であるべきではありません。

ISO DIS 8473 (May 1984)                                        [Page 31]

ISOは8473(1984年5月)をけなします。[31ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

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 put into an SNSDU. The bits in an octet
  are numbered from one (1) to eight (8), where bit one (1) is the
  low-order bit.

すべてのプロトコルData Unitsが整数の八重奏を含むものとします。 PDUの八重奏は、1つ(1)から始めて、それらがSNSDUに入れられるオーダーを増やしながら、番号付です。 八重奏におけるビットは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 subnetwork supporting this protocol is required to state in its
  specification the way octets are transferred, using the terms "most
  significant bit" and "least significant bit." The PDUs of this
  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
    section, the following representation is used:

PDUのコード化がこのセクションのダイヤグラムを使用することで表されるとき、以下の表現は使用されています:

     a)  octets are shown with the lowest numbered octet to the left,
         higher number octets being further to the right;

a) 八重奏は右に加えている左の、そして、より高い数の八重奏への最も低い番号付の八重奏で示されます。

     b)  within an octet, bits are shown with bit eight (8) to the left
         and bit one (1) to the right.

八重奏の中のb)、ビットはビットeight(8)で右への左の、そして、噛み付いているもの(1)に見せられます。

  PDUs shall contain, in the following order:

PDUsは以下のオーダーに以下を含むものとします。

   1)  the header, comprising:

1) ヘッダー、包括:

    a)  the fixed part;

a) 固定部分。

    b)  the address part;

b) アドレス部。

    c)  the segmentation part, if present;

c) 分割部分存在しているなら

    d)  the options part, if present

d) 存在しているなら、オプションは離れています。

   and

そして

ISO DIS 8473 (May 1984)                                        [Page 32]

ISOは8473(1984年5月)をけなします。[32ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   2)  the data field, if present.

2) データ・フィールド存在しているなら。

  This structure is illustrated below:

この構造は以下で例証されます:

                       Part:                Described in:

部分: 以下で説明されました。

            +-------------------+                          
            |    Fixed Part     |            Section 7.2   
            +-------------------+

+-------------------+ | 固定部分| セクション7.2 +-------------------+

            +-------------------+                          
            |   Address Part    |            Section 7.3   
            +-------------------+

+-------------------+ | アドレス部| セクション7.3 +-------------------+

            +-------------------+                          
            | Segmentation Part |            Section 7.4   
            +-------------------+

+-------------------+ | 分割部分| セクション7.4 +-------------------+

            +-------------------+                          
            |   Options Part    |            Section 7.5   
            +-------------------+

+-------------------+ | オプション一部| セクション7.5 +-------------------+

            +-------------------+                          
            |       Data        |            Section 7.6   
            +-------------------+

+-------------------+ | データ| セクション7.6 +-------------------+

                       Figure 7-1.  PDU Structure

図7-1。 PDU構造

ISO DIS 8473 (May 1984)                                        [Page 33]

ISOは8473(1984年5月)をけなします。[33ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 7.2 Fixed Part

7.2 固定部分

  7.2.1 General

7.2.1 一般

   The fixed part contains frequently occuring parameters 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.

固定部分は頻繁にプロトコルデータ単位のタイプコード(DTかER)を含む存在パラメタを含んでいます。 固定部分の長さと構造はPDUコードによって定義されます。

   The fixed part has the following format:

固定部分には、以下の形式があります:

                                                      Octet 
            +------------------------------------+          
            | Network Layer Protocol Identifier  |     1    
            |------------------------------------|          
            |         Length Indicator           |     2    
            |------------------------------------|          
            |   Version/Protocol Id Extension    |     3    
            |------------------------------------|          
            |            Lifetime                |     4    
            |------------------------------------|          
            |S |M |E/R|         Type             |     5    
            | P| S|   |                          |          
            |------------------------------------|          
            |          Segment Length            |    6,7   
            |------------------------------------|          
            |             Checksum               |    8,9   
            +------------------------------------+

八重奏+------------------------------------+ | ネットワーク層プロトコル識別子| 1 |------------------------------------| | 長さのインディケータ| 2 |------------------------------------| | バージョン/プロトコルイド拡大| 3 |------------------------------------| | 生涯| 4 |------------------------------------| |S|M|E/R| タイプ| 5 | P| S| | | |------------------------------------| | セグメントの長さ| 6,7 |------------------------------------| | チェックサム| 8,9 +------------------------------------+

                  Figure 7-2.  PDU Header--Fixed Part

図7-2。 PDUヘッダー--固定部分

  7.2.2 Network Layer Protocol Identifier

7.2.2 ネットワーク層プロトコル識別子

   The value of this field shall be binary 1000 0001. This field
   identifies this Network Layer Protocol as ISO 8473, Protocol for
   Providing the Connectionless-mode Network Service.

この分野の値は2進の1000 0001になるでしょう。 この分野は、Providing Connectionless-モードNetwork ServiceのためにこのNetwork LayerプロトコルがISO8473、プロトコルであると認識します。

ISO DIS 8473 (May 1984)                                        [Page 34]

ISOは8473(1984年5月)をけなします。[34ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  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 Section 7.1, Structure. The value 255 (1111
   1111) is reserved for possible future extensions.

長さは254(1111 1110)の最大値がある2進の数によって示されます。 Structure、示された長さはセクション7.1で説明されるようにヘッダーの八重奏で長さです。 値255の(1111 1111)は可能な今後の拡大のために予約されます。

    Note:

以下に注意してください。

     The rules for forwarding and segmentation ensure 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.

推進と分割のための規則はヘッダ長がInitial PDUのすべてのセグメント(PDUsを引き出す)に同じであり、Initial PDUのヘッダ長と同じであることを確実にします。

  7.2.4 Version/Protocol Identifier Extension

7.2.4 バージョン/プロトコル識別子拡張子

   The value of this field is binary 0000 0001. This Identifies a
   standard version of ISO 8473, Protocol for Providing the
   Connectionless-mode Network Service.

この分野の値は2進の0000 0001です。 ISO8473のこのIdentifies a標準版、Providing Connectionless-モードNetwork Serviceのためのプロトコル。

  7.2.5 PDU Lifetime

7.2.5 PDU生涯

   The Lifetime field is encoded as a binary number representing the
   remaining lifetime of the PDU, in units of 500 milliseconds.

Lifetime分野はPDUの残っている生涯を表す2進の数としてコード化されます、500ミリセカンドのユニットで。

   The Lifetime field is set by the originating network-entity, and is
   decremented by every network-entity which processes the PDU. The PDU
   shall be discarded if the value of the field reaches zero.

Lifetime分野は、起因するネットワーク実体によって設定されて、PDUを処理するあらゆるネットワーク実体で減少します。 分野の値がゼロに達するなら、PDUは捨てられるものとします。

   When a network-entity processes a PDU, it decrements the Lifetime by
   at least one. The Lifetime shall be decremented by more than one if
   the sum of:

ネットワーク実体がPDUを処理するとき、それはLifetimeを少なくとも1つ減少させます。 合計であるなら、Lifetimeは1つ以上以上減少するものとします:

    1)  the transit delay in the subnetwork from which the PDU was
        received; and

1) PDUが受け取られたサブネットワークのトランジット遅れ。 そして

ISO DIS 8473 (May 1984)                                        [Page 35]

ISOは8473(1984年5月)をけなします。[35ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

    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 error exists the value used shall be an
   overestimate, not an underestimate.

超えているか、または500人のミリセカンドを超えるために見積もられています。 この場合、生涯分野は各追加500人のミリセカンドの遅れあたり1つ減少するべきです。 遅れの決断は正確である必要はありませんが、使用される値は誤りが存在しているところの過大評価でしょう、過小でない。

   If the Lifetime reaches a value of zero before the PDU is delivered
   to the destination, the PDU shall be discarded. The Error Reporting
   function shall be invoked, as described in Section 6.10, Error
   Reporting Function, and may result in the generation of an ER PDU. It
   is a local matter whether the destination network-entity performs the
   Lifetime Control function.

PDUが送付先に提供される前にLifetimeがゼロの値に達するなら、PDUは捨てられるものとします。 Error Reporting機能は、セクション6.10、Error Reporting Functionで説明されるように呼び出されて、ER PDUの世代で結果として生じるかもしれません。 目的地ネットワーク実体がLifetime Control機能を実行するかどうかが、地域にかかわる事柄です。

   When the Segmentation function is applied to a PDU, the Lifetime
   field is copied into all of the Derived PDUs.

Segmentation機能がPDUに適用されるとき、Lifetime分野はDerived PDUsのすべてにコピーされます。

  7.2.6 Flags

7.2.6 旗

   7.2.6.1 Segmentation Permitted and More Segments Flags

7.2.6.1 受入れられた分割と、より多くのセグメント旗

    The Segmentation Permitted flag determines whether segmentation is
    permitted. A value of one indicates that segmentation is permitted.

Segmentation Permitted旗は、分割が受入れられるかどうか決定します。 1の値は、分割が受入れられるのを示します。

    A value of zero indicates that the non-segmenting protocol subset is
    employed. Where this is the case, the segmentation part of the PDU
    header is not present, and the Segment Length field serves as the
    Total Length field.

ゼロの値は、非区分プロトコル部分集合が採用しているのを示します。 これがそうであるところでは、PDUヘッダーの分割一部が存在していません、そして、Segment Length分野はTotal Length分野として機能します。

    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) then
    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 Segmentation Permitted flag is not set to one (1).

More Segments旗は、このPDUのデータ・セグメントがNSDUにおける、User Dataの最後の八重奏を含むかどうかを(最後の八重奏として)示します。 More Segments旗がその時1つ(1)に設定されるとき、分割は行われました、そして、NSDUの最後の八重奏はこのPDUに含まれていません。 Segmentation Permitted旗が1つ(1)に設定されないなら、1つ(1)にMore Segments旗を設定できません。

ISO DIS 8473 (May 1984)                                        [Page 36]

ISOは8473(1984年5月)をけなします。[36ページ]

RFC 926                                                    December 1984

RFC926 1984年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.2 Error Report Flag

7.2.6.2 エラー・レポート旗

    When the Error Report flag is set to one, the rules in Section 6.10
    are used to determine whether to generate an Error Report PDU upon
    discard of the PDU.

Error Report旗が1つに設定されるとき、セクション6.10の規則は、PDUの破棄のときにError Report PDUを生成するかどうか決定するのに使用されます。

    When the Error Report flag is set to zero, discard of the PDU will
    not cause the generation of an Error Report PDU.

Error Report旗がゼロに設定されるとき、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 7-1:

Typeコード分野はプロトコルデータ単位のタイプを特定します。 Table7-1で許容値を与えます:

                                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 7-1.  Valid PDU Types

7-1をテーブルの上に置いてください。 有効なPDUはタイプします。

  7.2.8 PDU Segment Length

7.2.8 PDUセグメントの長さ

   The Segment Length field specifies the entire length of the PDU
   segment including both header and data, if present. When the full
   protocol is employed and a PDU is not segmented, then the value of
   this field is identical to the value of the Total Length field
   located in the Segmentation Part of the header.

存在しているなら、Segment Length分野はヘッダーとデータの両方を含むPDUセグメントの全長を指定します。 完全なプロトコルが採用していて、PDUが区分されないと、この分野の値はヘッダーのSegmentation Partに位置するTotal Length分野の値と同じです。

ISO DIS 8473 (May 1984)                                        [Page 37]

ISOは8473(1984年5月)をけなします。[37ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   When the Non-segmenting protocol subset is employed, no segmentation
   part is present in the header. In this subset, the Segment Length
   field serves as the Total Length field of the header (see Section
   7.4.3).

Non-区分プロトコル部分集合が採用しているとき、どんな分割部分もヘッダーに存在していません。 この部分集合では、Segment Length分野はヘッダーのTotal Length分野として機能します(セクション7.4.3を見てください)。

  7.2.9 PDU Checksum

7.2.9 PDUチェックサム

   The checksum is computed on the entire PDU header. This includes the
   segmentation and options parts, if present. A checksum value of zero
   is reserved to indicate that the checksum is to be ignored. The
   operation of the PDU Header Error Detection function ensures that the
   value zero does not represent a valid checksum. A non-zero value
   indicates that the checksum must be processed or the PDU must be
   discarded.

チェックサムは全体のPDUヘッダーの上に計算されます。 存在しているなら、これは分割とオプション一部を含んでいます。 ゼロのチェックサム値は、チェックサムが無視されることであることを示すために予約されます。 PDU Header Error Detection機能の操作は、値ゼロが有効なチェックサムを表さないのを確実にします。 非ゼロ値は、チェックサムを処理しなければならないか、またはPDUを捨てなければならないのを示します。

 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
   illustrated below:

すぐにPDUヘッダーの固定一部に続いて、アドレスパラメタはそれらの位置によって区別されます。 アドレス部は以下で例証されます:

ISO DIS 8473 (May 1984)                                        [Page 38]

ISOは8473(1984年5月)をけなします。[38ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

                                                      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 7-3.  PDU header--Address Part

図7-3。 PDUヘッダー--アドレス部

   7.3.1.1 Destination and Source Address Information

7.3.1.1 目的地とソースアドレス情報

    The Destination and Source addresses are Network Service Access
    Point addresses as defined in ISO 8348/DAD2, Addendum to the Network
    Service Definition Covering Network Layer Addressing.

DestinationとSourceアドレスはISO8348/DAD2(Network Service Definition Covering Network Layer AddressingへのAddendum)で定義されるようにNetwork Service Access Pointアドレスです。

    The Destination and Source Address information is of variable
    length.

DestinationとSource Address情報は可変長のものです。

    The Destination Address Length Indicator field specifies the length
    of the Destination Address in number of octets. The Destination
    Address field follows the Destination Address Length Indicator
    field. The Source Address Length Indicator field specifies the
    length of the Source Address in number of octets. The Source Address
    Length Indicator field follows the Destination Address field. The
    Source Address field follows the Source Address Length Indicator
    field.

Destination Address Length Indicator分野は八重奏の数における、Destination Addressの長さを指定します。 Destination Address分野はDestination Address Length Indicator野原に続きます。 Source Address Length Indicator分野は八重奏の数における、Source Addressの長さを指定します。 Source Address Length Indicator分野はDestination Address野原に続きます。 Source Address分野はSource Address Length Indicator野原に続きます。

ISO DIS 8473 (May 1984)                                        [Page 39]

ISOは8473(1984年5月)をけなします。[39ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

    Each address parameter is encoded as follows:

それぞれのアドレスパラメタは以下の通りコード化されます:

                      Bits   8   7   6   5   4   3   2   1  
            +---------------------------------------------+ 
            | Octet  | Address parameter Length Indicator | 
            |   n    |           (e.g., 'm')              | 
            |---------------------------------------------| 
            | Octets |                                    | 
            |  n+1   |     Address Parameter Value        | 
            | thru   |                                    | 
            |  n+m   |                                    | 
            +---------------------------------------------+

ビット8 7 6 5 4 3 2 1+---------------------------------------------+ | 八重奏| アドレスパラメタLength Indicator| | n| '、(例えば、'、) | |---------------------------------------------| | 八重奏| | | n+1| アドレスパラメタ価値| | 徹底的に| | | n+m| | +---------------------------------------------+

                     Table 7-2.  Address Parameters

7-2をテーブルの上に置いてください。 アドレスパラメタ

 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 below, must be present:

PDU Header(八重奏4、Bit8)のFixed PartのSegmentation Permitted Flagが1つに用意ができているなら、以下で例証されたヘッダーの分割一部が存在していなければなりません:

                                               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 7-4.  PDU Header--Segmentation Part

図7-4。 PDUヘッダー--分割部分

  Where the "Segmentation Permitted" flag is set to zero, the
  nonsegmenting protocol subset is in use.

「分割は可能にした」という旗がゼロに設定されるところでは、非区分しているプロトコル部分集合が使用中です。

ISO DIS 8473 (May 1984)                                        [Page 40]

ISOは8473(1984年5月)をけなします。[40ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  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
   reassembled by the destination network-entity. The Data Unit
   Identifier size is two octets.

Data Unit Identifierは、目的地ネットワーク実体で正しく区分されたデータ単位を組み立て直すことができるように、Initial PDU(そして、したがって、Derived PDUs)を特定します。 Data Unit Identifierサイズは2つの八重奏です。

  7.4.2 Segment Offset

7.4.2 セグメントは相殺されました。

   For each segment the Segment Offset field specifies the relative
   position of the segment in the data part of the Initial PDU with
   respect to the start of the data field. The offset is measured in
   units of octets. The offset of the first segment is zero.

各セグメントとして、Segment Offset分野はInitial PDUのデータ部分でデータ・フィールドの始まりに関してセグメントの相対的な位置を指定します。 オフセットはユニットの八重奏で測定されます。 最初のセグメントのオフセットはゼロです。

  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 in
   any segment (Derived PDU) for the lifetime of the PDU.

Total Length分野はヘッダーとデータの両方を含むInitial PDUの全長を指定します。 この分野はどんなセグメントでもPDUの生涯に変わりません(PDUを引き出します)。

 7.5 Options Part

7.5のオプションが離れています。

  7.5.1 General

7.5.1 一般

   The options part is used to convey optional parameters. If the
   options part is present, it contains one or more parameters. The
   number of parameters that may be contained in the options part is
   indicated by the length of the options part which is:

オプション一部が、任意のパラメタを伝えるのに使用されます。 オプション一部が存在しているなら、それは1つ以上のパラメタを含んでいます。 オプション一部に保管されるかもしれないパラメタの数は以下の通りであるオプション一部の長さによって示されます。

    PDU Header Length - (length of fixed part +
                         length of address part +
                         length of segmentation part).

PDU Header Length--(固定部分+長さの分割部分のアドレス部+長さの長さ。)

ISO DIS 8473 (May 1984)                                        [Page 41]

ISOは8473(1984年5月)をけなします。[41ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   The options part of the PDU header is illustrated below:

PDUヘッダーのオプション一部が以下で例証されます:

                                               Octet 
                   +--------------------+            
                   |                    |       n+6  
                   |      Options       |            
                   |                    |       p    
                   +--------------------+

八重奏+--------------------+ | | n+6| オプション| | | p+--------------------+

                 Figure 7-5.  PDU Header--Options Part

図7-5。 PDUヘッダー--オプション一部

   Each parameter contained within the options part of the PDU header is
   encoded as follows:

PDUヘッダーのオプション一部の中に含まれた各パラメタは以下の通りコード化されます:

                          BITS    8  7  6  5  4  3  2  1  
             +------------------------------------------+ 
             |  Octets  |                               | 
             |    n     |  Parameter Code               | 
             |------------------------------------------| 
             |   n+1    |  Parameter Length (e.g., 'm') | 
             |------------------------------------------| 
             |   n+2    |  Parameter Value              | 
             |  n+m+1   |                               | 
             +------------------------------------------+

ビット8 7 6 5 4 3 2 1+------------------------------------------+ | 八重奏| | | n| パラメタコード| |------------------------------------------| | n+1| パラメタの'長さ、(例えば、'、)| |------------------------------------------| | n+2| パラメタ値| | n+m+1| | +------------------------------------------+

                   Table 7-3.  Encoding of Parameters

7-3をテーブルの上に置いてください。 パラメタのコード化

   The parameter code field is coded in binary and, without extensions,
   provides a maximum number of 255 different parameters. However, as
   noted below, bits 8 and 7 cannot take every possible value, so the
   practical maximum number of different parameters is less. A parameter
   code of 255 (binary 1111 1111) is reserved for possible extensions of
   the parameter code.

パラメタコード分野は、バイナリーでコード化されて、拡大なしで255の異なったパラメタの最大数を提供します。 しかしながら、ビット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 binary number,
   'm', with a theoretical maximum value of 255. 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 indication itself. Thus, the
   value of 'm' is limited to:

パラメタ長さの分野はパラメタ値の分野の八重奏における長さを示します。 '長さが2進の数によって示される、'、255の理論上の最大値 '実用的な最大値、'、下ろしてください。 例えば、オプション一部の中に保管されていたただ一つのパラメタの場合では、2つの八重奏がパラメタコードとパラメタ長さの指示自体に必要です。 'その結果、値、'、以下のことのために制限されます。

ISO DIS 8473 (May 1984)                                        [Page 42]

ISOは8473(1984年5月)をけなします。[42ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

     253 - (length of fixed part +
     length of address part +
     length of segmentation part).

253--(固定部分+長さの分割部分のアドレス部+長さの長さ。)

   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.

パラメタ値の分野はパラメタコード分野で特定されたパラメタの値を含んでいます。

   No parameter codes use bits 8 and 7 with the value 00.

どんなパラメタコードも値00に従ったビット8と7を使用しません。

   Implementations shall accept the parameters defined in the options
   part in any order. Duplication of options (where detected) is not
   permitted. Receipt of a PDU with an option duplicated should be
   treated as a protocol error. The rules governing the treatment of
   protocol errors are described in Section 6.10, Error Reporting
   Function.

実装は、オプション一部で定義されたパラメタが順不同であると受け入れるものとします。 オプション(検出されるところで)の複製は受入れられません。 オプションがコピーされているPDUの領収書はプロトコル誤りとして扱われるべきです。 Error Reporting Function、プロトコル誤りの処理を治める規則はセクション6.10で説明されます。

   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
   convenient size (See Section 6.12).

詰め物パラメタは、便利なサイズにPDUヘッダーを伸すのに使用されます(セクション6.12を見てください)。

    Parameter Code:       1100 1100
    Parameter Length:     variable
    Parameter Value:      any value is allowed

パラメタコード: 1100 1100パラメタの長さ: 可変Parameter Value: どんな値も許容されています。

  7.5.3 Security

7.5.3 セキュリティ

   This parameter is user defined.

このパラメタは定義されたユーザです。

    Parameter Code:       1100 0101
    Parameter Length:     variable
    Parameter Value:

パラメタコード: 1100 0101パラメタの長さ: 可変Parameter Value:

     High order bit of first octet is Security Domain bit, S, to be
     interpreted as follows:

最初の八重奏の高位のビットはSecurity Domainビット、以下の通り解釈されるためにはSです:

ISO DIS 8473 (May 1984)                                        [Page 43]

ISOは8473(1984年5月)をけなします。[43ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

      S=0

S=0

       +---------------------------
       | S | User Defined        ----
       +------------------------

+--------------------------- | S| 定義されたユーザ---- +------------------------

      S=1

S=1

       +---------------------------
       | S | CODE | ORGANIZATION ----
       +------------------------

+--------------------------- | S| コード| 組織---- +------------------------

      where

どこ

       CODE = This field contains a geographic or non-geographic code to
              which the option applies.

このCODE=分野はオプションが適用される地理的であるか非地理的なコードを含んでいます。

       ORGANIZATION = This is a further subdivision of the CODE field
                      and is determined by an administrator of the
                      geographic or non-geographic domain identified by
                      the value of CODE.

ORGANIZATION=これは、CODE分野のさらなる下位区分であり、CODEの値によって特定された地理的であるか非地理的なドメインの管理者によって決定されます。

  7.5.4 Source Routing

7.5.4 ソースルート設定

   The source routing parameter specifies, either completely or
   partially, the route to be taken from Source Network Address to
   Destination Network Address.

ソースルーティングパラメタは、Source Network AddressからDestination Network Addressまで取るためにルートを完全か部分的に指定します。

    Parameter Code:      1100 1000
    Parameter Length:    variable
    Parameter Value:     2 octet control information
                         succeeded by a concatenation
                         of ordered address fields
                         (ordered from source to destination)

パラメタコード: 1100 1000パラメタの長さ: 可変Parameter Value: 2 命令されたアドレス・フィールドの連結で引き継がれた八重奏制御情報(ソースから目的地まで注文します)

ISO DIS 8473 (May 1984)                                        [Page 44]

ISOは8473(1984年5月)をけなします。[44ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   The first octet of the parameter value is the type code. This has the
   following significance.

パラメタ価値の最初の八重奏はタイプコードです。 これには、以下の意味があります。

    0000 0001     complete source routing
    0000 0000     partial source routing

0000 0001の完全なソース掘っている0000 0000の部分的なソースルーティング

    <all other values reserved>

<は他のすべての値の予約された>です。

   The second octet indicates the octet offset of the next address to be
   processed in the list. A value of three (3) indicates that the next
   address begins immediately after this control octet. Successive
   octets are indicated by correspondingly larger values of this
   indicator.

2番目の八重奏は、リストで処理されるために次のアドレスの八重奏オフセットを示します。 3(3)の値は、次のアドレスがこのコントロール八重奏直後始まるのを示します。 連続した八重奏はこのインディケータの対応するより大きい値によって示されます。

   The third octet begins the intermediate-system address list. The
   address list consists of variable length address fields. The first
   octet of each address field identifies the length of the address
   which comprises the remainder of the address field.

3番目の八重奏は中間システム住所録を始めます。 住所録は可変長アドレス・フィールドから成ります。 それぞれのアドレス・フィールドの最初の八重奏はアドレス・フィールドの残りを包括するアドレスの長さを特定します。

  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
    Parameter Length:     variable
    Parameter Value:      two octets control information
                          succeeded  by a concatenation of
                          ordered addresses

パラメタコード: 1100 1011パラメタの長さ: 可変Parameter Value: 2つの八重奏が規則正しいアドレスの連結で引き継がれた情報を制御します。

   The first octet is used to indicate that the recording of route has
   been terminated owing to lack of space in the option. It has the
   following significance:

最初の八重奏は、ルートの録音がオプションにおける、スペースの不足で終えられたのを示すのに使用されます。 それには、以下の意味があります:

    0000 0000     Recording of Route still in progress
    1111 1111     Recording of Route terminated

まだRouteの1111 1111Recordingが終えた進行中における、Routeの0000 0000録音

    <all other values reserved>

<は他のすべての値の予約された>です。

ISO DIS 8473 (May 1984)                                        [Page 45]

ISOは8473(1984年5月)をけなします。[45ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   The second octet identifies the next octet which may be used to
   record an address. It is encoded relative to the start of the
   parameter, such that a value of three (3) indicates that the octet
   after this one is the next to be used.

2番目の八重奏はアドレスを記録するのに使用されるかもしれない次の八重奏を特定します。 それはパラメタの始まりに比例してコード化されます、3(3)の値が、この後の八重奏が使用されるべき次であることを示すように。

   The third octet begins the address list. The address list consists of
   variable length address fields. The first octet of each address field
   identifies the length of the address which comprises the remainder of
   the field. Address fields are always added to the beginning of the
   address list; i.e., the most recently added field will begin in the
   third octet of the parameter value.

3番目の八重奏は住所録を始めます。 住所録は可変長アドレス・フィールドから成ります。 それぞれのアドレス・フィールドの最初の八重奏は分野の残りを包括するアドレスの長さを特定します。 アドレス・フィールドはいつも住所録の始まりに加えられます。 すなわち、大部分は、最近、分野がパラメタ価値の3番目の八重奏で始まると言い足しました。

  7.5.6 Quality of Service Maintenance

7.5.6 サービスの質メインテナンス

   The Quality of Service parameter conveys information about the
   quality of service requested by the originating Network Service user.
   At intermediate systems, Network Layer relay entities 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 Section 6.16).

ServiceパラメタのQualityは起因しているNetwork Serviceユーザによって要求されたサービスの質に関して情報を伝達します。 中間システムでは、他のルーティング評価基準を満たす1つ以上のルートが利用可能であるときにルートを選択することにおける援助と利用可能なルートがServiceのQualityに関して異なるのが知られているとき(セクション6.16を見てください)、Network Layerリレー実体はこの情報を利用するかもしれません(しかし、必要ではありません)。

    Parameter Code:       1100 0011
    Parameter Length:     one octet
    Parameter Value:      Bit 8:  transit delay vs. cost
                          Bit 7:  residual error probability vs.
                                  transit delay
                          Bit 6:  residual error probability vs.
                                  cost
                          Bits 5 thru 0 are not specified.

パラメタコード: 1100 0011パラメタの長さ: 1つの八重奏のParameter Value: ビット8: トランジット遅れ対費用Bit7: 見逃し誤り確率対トランジット遅れBit6: 見逃し誤り確率は対費用Bits5〜0指定されていません。

   Bit 8 is set to one indicates that where possible, routing decision
   should favor low transit delay over low cost. A value of 0 indicates
   that routing decisions should favor low cost over low transit delay.

ビット8は人が、低価格の上で可能なルーティング決定が低いトランジットを支持するべきであるそんなにところに延着するように示すように設定されます。 0の値は、ルーティング決定が低いトランジット遅れより低価格を好むべきであるのを示します。

ISO DIS 8473 (May 1984)                                        [Page 46]

ISOは8473(1984年5月)をけなします。[46ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   Bit 7 set to one indicates 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つに設定されたビット7は、可能であるところでは、ルーティング決定が低いトランジット遅れより低見逃し誤り確率を好むべきであるのを示します。 ゼロの値は、ルーティング決定が低見逃し誤り確率より低いトランジット遅れを好むべきであるのを示します。

   Bit 6 is set to one indicates that where possible, routing decisions
   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.

ビット6は1つへのセットが、可能であるところでは、ルーティング決定が低価格より低見逃し誤り確率を好むべきであるのを示すということです。 0の値は、ルーティング決定が低見逃し誤り確率より低価格を好むべきであるのを示します。

 7.6 Priority

7.6 優先権

  The priority parameter carries the relative priority of the protocol
  data unit. Intermediate systems that support this option should make
  use of this information in routing and in ordering PDUs for
  transmission.

優先権パラメタはプロトコルデータ単位の相対的な優先権を運びます。 このオプションをサポートする中間システムはトランスミッションにルーティングとPDUsを注文する際にこの情報を利用するはずです。

   Parameter Code:       1100 1100
   Parameter Length:     one octet
   Parameter Value:      0000 0000 - Normal (Default)
                         thru
                         0000 1111 - Highest

パラメタコード: 1100 1100パラメタの長さ: 1つの八重奏のParameter Value: 0000 0000(0000 1111を通した標準(デフォルト))、高さ

  The values 0000 0001 through 0000 1111 are to be used for higher
  priority protocol data units. If an intermediate system does not
  support this option then all PDUs shall be treated as if the field had
  the value 0000 0000.

値0000 0001〜0000 1111は、より高い優先権プロトコルデータ単位に使用されることです。 中間システムがこのオプションをサポートしないなら、まるで分野には値0000 0000があるかのようにすべてのPDUsが扱われるものとします。

 7.7 Data Part

7.7 データ部分

  The Data part of the PDU is structured as an ordered multiple of
  octets, 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 below:

PDUのData部分は八重奏の命令された倍数として構造化されます。(それは、N_UNITDATA RequestのNS_Userdataパラメタに指定された八重奏とIndication基関数の同じ命令された倍数と同じです)。 データ・フィールドは以下で例証されます:

ISO DIS 8473 (May 1984)                                        [Page 47]

ISOは8473(1984年5月)をけなします。[47ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

                                             Octet 
                  +------------------+                
                  |                  |      p+1       
                  |       Data       |                
                  |                  |       z        
                  +------------------+

八重奏+------------------+ | | p+1| データ| | | z+------------------+

                  Figure 7-6.  PDU header--Data Field

図7-6。 PDUヘッダー--データ・フィールド

ISO DIS 8473 (May 1984)                                        [Page 48]

ISOは8473(1984年5月)をけなします。[48ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 7.8 Data (DT) PDU

7.8 データ(DT)PDU

  7.8.1 Structure

7.8.1 構造

   The DT PDU has the following format:

DT PDUには、以下の形式があります:

                                                  Octet           
     +--------------------------------------+                     
     |  Network Layer Protocol Identifier   |      1              
     |--------------------------------------|                     
     |           Length Indicator           |      2              
     |--------------------------------------|                     
     |   Version/Protocol Id Extension      |      3              
     |--------------------------------------|                     
     |              Lifetime                |      4              
     |--------------------------------------|                     
     |SP|MS|E/R|      Type                  |      5              
     |--------------------------------------|                     
     |           Segment Length             |     6,7             
     |--------------------------------------|                     
     |              Checksum                |     8,9             
     |--------------------------------------|                     
     | Destination Address Length Indicator |     10              
     |--------------------------------------|                     
     |         Destination Address          |     11 through m-1  
     |--------------------------------------|                     
     |    Source Address Length Indicator   |      m              
     |--------------------------------------|                     
     |            Source Address            |     m+1 through n-1 
     |--------------------------------------|                     
     |         Data Unit Identifier         |     n,n+1           
     |--------------------------------------|                     
     |            Segment Offset            |     n+2,n+3         
     |--------------------------------------|                     
     |             Total Length             |     n+4,n+5         
     |--------------------------------------|                     
     |                Options               |     n+6 through p   
     |--------------------------------------|                     
     |                 Data                 |     p+1 through z   
     +--------------------------------------+

八重奏+--------------------------------------+ | ネットワーク層プロトコル識別子| 1 |--------------------------------------| | 長さのインディケータ| 2 |--------------------------------------| | バージョン/プロトコルイド拡大| 3 |--------------------------------------| | 生涯| 4 |--------------------------------------| |SP|さん|E/R| タイプ| 5 |--------------------------------------| | セグメントの長さ| 6,7 |--------------------------------------| | チェックサム| 8,9 |--------------------------------------| | 目的地アドレス長さのインディケータ| 10 |--------------------------------------| | 送付先アドレス| 11 m-1を通して|--------------------------------------| | ソースアドレス長さのインディケータ| m|--------------------------------------| | ソースアドレス| n-1を通したm+1|--------------------------------------| | データ単位識別子| n、n+1|--------------------------------------| | セグメントオフセット| n+2、n+3|--------------------------------------| | 全長| n+4、n+5|--------------------------------------| | オプション| pを通したn+6|--------------------------------------| | データ| z+を通したp+1--------------------------------------+

                     Figure 7-7.  PDU Header Format

図7-7。 PDUヘッダー形式

ISO DIS 8473 (May 1984)                                        [Page 49]

ISOは8473(1984年5月)をけなします。[49ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   7.8.1.1 Fixed Part

7.8.1.1 固定部分

    1) Network Layer Protocol Identifier   See Section 7.2.2.
    2) Length Indicator                    See Section 7.2.3.
    3) Version/Protocol Id Extension       See Section 7.2.4.
    4) Lifetime                            See Section 7.2.5.
    5) SP, MS, E/R                         See Section 7.2.6.
    6) Type Code                           See Section 7.2.7.
    7) Segment Length                      See Section 7.2.8.
    8) Checksum                            See Section 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.8.1.2 Addresses

7.8.1.2 アドレス

    See Section 7.3.

セクション7.3を見てください。

   7.8.1.3 Segmentation

7.8.1.3 分割

    See Section 7.4.

セクション7.4を見てください。

   7.8.1.4 Options

7.8.1.4 オプション

    See Section 7.5.

セクション7.5を見てください。

   7.8.1.5 Data

7.8.1.5 データ

    See Section 7.7.

セクション7.7を見てください。

ISO DIS 8473 (May 1984)                                        [Page 50]

ISOは8473(1984年5月)をけなします。[50ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 7.9 Inactive Network Layer Protocol

7.9 不活発なネットワーク層プロトコル

                                              Octet         
            +-----------------------------+                 
            |  Network Layer Protocol Id  |     1           
            |-----------------------------|                 
            |           Data              |     2 through n 
            +-----------------------------+

八重奏+-----------------------------+ | ネットワーク層プロトコルイド| 1 |-----------------------------| | データ| 2 n+を通して-----------------------------+

              Figure 7-9.  Inactive Network Layer Protocol

図7-9。 不活発なネットワーク層プロトコル

  7.9.1 Network Layer Protocol Id

7.9.1 ネットワーク層プロトコルイド

   The value of the Network Layer Protocol Identifier field is binary
   zero (0000 0000).

Network LayerプロトコルIdentifier分野の値はバイナリーが(0000 0000)のゼロに合っているということです。

  7.9.2 Data Field

7.9.2 データ・フィールド

   See Section 7.7.

セクション7.7を見てください。

   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.

NS_Userdataパラメタの長さは1を引いたSN_Userdataパラメタの長さの、より値であることが抑制されます。

ISO DIS 8473 (May 1984)                                        [Page 51]

ISOは8473(1984年5月)をけなします。[51ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 7.10 Error Report PDU (ER)

7.10 エラー・レポートPDU(えー)

  7.10.1 Structure

7.10.1 構造

                                                  Octet           
     +--------------------------------------+                     
     |   Network Layer Protocol Identifier  |       1             
     |--------------------------------------|                     
     |           Length Indicator           |       2             
     |--------------------------------------|                     
     |     Version/Protocol Id Extension    |       3             
     |--------------------------------------|                     
     |               Lifetime               |       4             
     |--------------------------------------|                     
     |SP|MS|E/R|       Type                 |       5             
     |--------------------------------------|                     
     |             Segment Length           |      6,7            
     |--------------------------------------|                     
     |                Checksum              |      8,9            
     |--------------------------------------|                     
     | Destination Address Length Indicator |      10             
     |--------------------------------------|                     
     |         Destination Address          |     10 through m-1  
     |--------------------------------------|                     
     |     Source Address Length Indicator  |       m             
     |--------------------------------------|                     
     |             Source Address           |     m+1 through n-1 
     |--------------------------------------|                     
     |          Data Unit Identifier        |     n,n+1           
     |--------------------------------------|                     
     |             Segment Offset           |     n+2,n+3         
     |--------------------------------------|                     
     |              Total Length            |     n+4,n+5         
     |--------------------------------------|                     
     |                Options               |     n+6 through p-1 
     |--------------------------------------|                     
     |           Reason for Discard         |     p through q-1   
     |--------------------------------------|                     
     |       Error Report Data Field        |       z             
     +--------------------------------------+

八重奏+--------------------------------------+ | ネットワーク層プロトコル識別子| 1 |--------------------------------------| | 長さのインディケータ| 2 |--------------------------------------| | バージョン/プロトコルイド拡大| 3 |--------------------------------------| | 生涯| 4 |--------------------------------------| |SP|さん|E/R| タイプ| 5 |--------------------------------------| | セグメントの長さ| 6,7 |--------------------------------------| | チェックサム| 8,9 |--------------------------------------| | 目的地アドレス長さのインディケータ| 10 |--------------------------------------| | 送付先アドレス| 10 m-1を通して|--------------------------------------| | ソースアドレス長さのインディケータ| m|--------------------------------------| | ソースアドレス| n-1を通したm+1|--------------------------------------| | データ単位識別子| n、n+1|--------------------------------------| | セグメントオフセット| n+2、n+3|--------------------------------------| | 全長| n+4、n+5|--------------------------------------| | オプション| p-1を通したn+6|--------------------------------------| | 破棄の理由| pからq-1|--------------------------------------| | エラー・レポートデータ・フィールド| z+--------------------------------------+

                     Figure 7-10.  Error Report PDU

図7-10。 エラー・レポートPDU

ISO DIS 8473 (May 1984)                                        [Page 52]

ISOは8473(1984年5月)をけなします。[52ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   7.10.1.1 Fixed Part

7.10.1.1 固定部分

    The fixed part of the Error Report Protocol Data Unit is set as
    though this is a new (Initial) PDU. Thus, references are provided to
    precious sections describing the composition of the fields
    comprising the fixed part:

Error ReportプロトコルData Unitの固定部分はまるでこれが新しい(初期の)PDUであるかのように設定されます。 したがって、固定部分を包括する分野の構成について説明する貴重なセクションに参照を提供します:

    1) Network Layer Protocol Identifier   See Section 7.2.2.
    2) Length Indicator                    See Section 7.2.3.
    3) Version/Protocol Id Extension       See Section 7.2.4.
    4) Lifetime                            See Section 7.2.5.
    5) SP, MS, E/R                         See Section 7.2.6.
    6) Type Code                           See Section 7.2.7.
    7) Segment Length                      See Section 7.2.8.
    8) Checksum                            See Section 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.10.1.2 Addresses

7.10.1.2 アドレス

    See Section 7.3.

セクション7.3を見てください。

    The Destination Address specifies the original source of the
    discarded PDU. The Source Address specifies the intermediate system
    or end system network-entity initiating the Error Report PDU.

Destination Addressは捨てられたPDUの一次資料を指定します。 Source Addressは、Error Report PDUを開始しながら、中間システムか終わりのシステムネットワーク実体を指定します。

   7.10.1.3 Segmentation

7.10.1.3 分割

    See Section 7.4.

セクション7.4を見てください。

ISO DIS 8473 (May 1984)                                        [Page 53]

ISOは8473(1984年5月)をけなします。[53ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   7.10.1.4 Options

7.10.1.4 オプション

    See Section 7.5.

セクション7.5を見てください。

   7.10.1.5 Reason for Discard

7.10.1.5 破棄の理由

    This parameter is only valid for the Error Report PDU. It provides a
    report on the discarded protocol data unit.

Error Report PDUだけに、このパラメタは有効です。 それは捨てられたプロトコルデータ単位に関するレポートを提供します。

    Parameter Code:

パラメタコード:

     1100 0001

1100 0001

    Parameter Length:

パラメタの長さ:

     two octets
     type of error encoded in binary:

誤りのタイプがバイナリーでコード化した2つの八重奏:

      0000 0000:  Reason not specified.
      0000 0001:  Protocol Procedure Error.
                  other than below:
      0000 0010:  Incorrect checksum.
      0000 0011:  PDU discarded due to congestion.
      0000 0100:  Header syntax error (header cannot
                  be parsed).
      0000 0101:  Segmentation is needed but is not
                  permitted.

0000 0000: 理由は指定しませんでした。 0000 0001: プロトコルProcedure Error下を除いて: 0000 0010: 不正確なチェックサム。 0000 0011: PDUは混雑のため捨てました。 0000 0100: ヘッダー構文エラー(ヘッダーを分析できません)。 0000 0101: 分割は、必要ですが、受入れられません。

      1000 xxxx:  Addressing Error:
                  0000 0000:  Destination Address
                              Unreachable.
                  1000 0001:  Destination Address
                              Unknown.

1000xxxx: アドレシング誤り: 0000 0000: 送付先アドレス手が届きません。 1000 0001: 目的地住所不明。

      1001 xxxx:  Source Routing Error:
                  1001 0000:  Unspecified Source
                              Routing error.
                  1001 0001:  Syntax error in Source
                              Routing field.
                  1001 0010:  Unknown Address in
                              Source Routing field.
                  1001 0011:  Path not acceptable.

1001xxxx: ソースルート設定誤り: 1001 0000: 不特定のSourceルート設定誤り。 1001 0001: Sourceルート設定分野の構文エラー。 1001 0010: Sourceルート設定分野の未知のAddress。 1001 0011: 許容できない経路。

ISO DIS 8473 (May 1984)                                        [Page 54]

ISOは8473(1984年5月)をけなします。[54ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

      1010 xxxx:  Lifetime Expiration:
                  1010 0000:  Lifetime expired while
                              data unit in transit.
                  1010 0001:  Lifetime expired
                              during reassembly.

1010xxxx: 生涯満了: 1010 0000: 寿命はトランジットにおけるデータ単位である間、期限が切れました。 1010 0001: 寿命は再アセンブリの間、期限が切れました。

      1011 xxxx:  PDU discarded due to unsupported
                  option:
                  1011 0000:  unsupported option not
                              specified.
                  1011 0001:  unsupported padding
                              option.
                  1011 0010:  unsupported security
                              option.
                  1011 0011:  unsupported source
                              routing option.
                  1011 0100:  unsupported recording
                              of route option.
                  1011 0101:  unsupported QoS
                              Maintenance option.

1011xxxx: PDUは非サポート・オプションのため捨てました: 1011 0000: 非サポート・オプションは指定しませんでした。 1011 0001: サポートされない詰め物オプション。 1011 0010: サポートされないセキュリティオプション。 1011 0011: サポートされないソースルーティングオプション。 1011 0100: ルートオプションのサポートされない録音。 1011 0101: サポートされないQoS Maintenanceオプション。

     The second octet contains a pointer to the field in the associated
     discarded PDU which caused the error. If no one particular field
     can be associated with the error, then this field contains the
     value of zero.

2番目の八重奏は誤りを引き起こした関連捨てられたPDUの分野に指針を含んでいます。 1つの特定の野原を誤りに関連づけることができないなら、この分野はゼロの値を含んでいます。

   7.10.1.6 Error Report Data Field

7.10.1.6 エラー・レポートデータ・フィールド

    This field provides all or a portion of the discarded PDU. The
    octets comprising this field contain the rejected or discarded PDU
    up to and including the octet which caused the rejection/discard.

この分野は捨てられたPDUのすべてか一部を提供します。 この分野を包括する八重奏は拒絶/破棄を引き起こした八重奏を含めて拒絶されたか捨てられたPDUを含んでいます。

ISO DIS 8473 (May 1984)                                        [Page 55]

ISOは8473(1984年5月)をけなします。[55ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

8  FORMAL DESCRIPTION

8 形式的記述

 The operation of the protocol is modelled as a finite state automaton
 governed by a state variable with three values. The behavior of the
 automaton is defined with respect to individual independent Protocol
 Data Units. A transition of the automaton is prompted by the occurrence
 of an atomic event at one of three interfaces:

有限州のオートマトンが3つの値に従った州の変数によって治められたので、プロトコルの操作はモデル化されます。 オートマトンの動きは個々の独立しているプロトコルData Unitsに関して定義されます。 オートマトンの変遷は3つのインタフェースの1つで原子イベントの発生によってうながされます:

  1) an interface to the Transport Layer, defined by the service
      primitives of the Addendum to the Network Service Definition
      Covering Connectionless-mode Transmission;

1) Network Service Definition Covering Connectionless-モードTransmissionへのAddendumに関するサービス基関数によって定義されたTransport Layerへのインタフェース。

  2) an interface to the subnetwork service provider, defined by the
      SN_UNITDATA primitive of Section 5.5 of this Standard;

2) このStandardのセクション5.5における原始のSN_UNITDATAによって定義されたサブネットワークサービスプロバイダーへのインタフェース。

  3) an interface to an implementation-dependent timer function defined
      by the TIMER primitives described in Section 5.6 of this Standard.

3) TIMER基関数によって定義された実装依存するタイマ機能へのインタフェースはセクションでこの5.6Standardについて説明しました。

 In addition, a transition of the automaton may be prompted by the
 occurrence of a condition of the automaton.

さらに、オートマトンの変遷はオートマトンの状態の発生によってうながされるかもしれません。

 The atomic events are defined in Section 8.2. The occurrence of an
 atomic event is not in itself sufficient to cause a transition to take
 place; other conditions, called "enabling conditions" may also have to
 be met before a particular transition can take place. Enabling
 conditions are boolean expressions that depend on the values of
 parameters associated with the corresponding atomic event (that is, the
 parameters of some primitive), and on the values of locally maintained
 variables.

原子イベントはセクション8.2で定義されます。 原子イベントの発生が、本来変遷が行われることを引き起こすことができないくらいの。 また、特定の変遷が行われることができる前に他の状態、呼ばれた「可能な状態」は会われなければならないかもしれません。 可能な状態は対応する原子イベント(すなわち、何らかの基関数のパラメタ)に関連しているパラメタの値と、そして、局所的に維持された変数の値に依存する論理演算子式です。

 More than one enabling condition -- and therefore, more than one
 possible transition -- may be associated with a single atomic event. In
 every such case, the enabling conditions are mutually exclusive, so
 that for any given combination of atomic event and parameter values,
 only one state transition can take place.

1つ以上の可能な条件(したがって、1つ以上の可能な変遷)がただ一つの原子イベントに関連しているかもしれません。 いつもそのような場合では、可能な状態は互いに唯一です、1つの状態遷移しか原子イベントとパラメタ値のどんな与えられた組み合わせのためにも行われることができないように。

 Associated with each transition is an action, or "output." Actions
 consist of changes to the values of local variables and the sequential
 performance of zero or more functions. The operation of the finite
 state automaton is completely specified in Section 8.3 by defining the
 action associated with every possible transition.

各変遷に関連づけられているのは、動作、または「出力」です。 動作が局所変数の値とゼロの連続した性能への変化から成るか、または以上は機能します。 有限州のオートマトンの操作は、セクション8.3であらゆる可能な変遷に関連している動作を定義することによって、完全に指定されます。

ISO DIS 8473 (May 1984)                                        [Page 56]

ISOは8473(1984年5月)をけなします。[56ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

 8.1  Values of the State Variable

8.1 州の変数の値

  The protocol state variable has three values:

プロトコル州の変数には、3つの値があります:

  1)  INITIAL       The automaton is created in the INITIAL state.  No
                    transition may carry the automaton into the INITIAL
                    state.

1) INITIAL、オートマトンはINITIAL状態で作成されます。 どんな変遷もINITIAL状態までオートマトンを運んではいけません。

  2)  REASSEMBLING  The automaton is in the REASSEMBLING state for the
                    period in which it is assembling PDU segments into a
                    complete PDU.

2) REASSEMBLING、オートマトンがそれが完全なPDUにPDUセグメントを組み立てる期間、REASSEMBLING状態にあります。

  3)  CLOSED        The final state of the automaton is the  CLOSED
                    state.  When the automaton enters the CLOSED state
                    it ceases to exist.

3) CLOSED、オートマトンの最終的な状態はCLOSED状態です。 オートマトンがCLOSED状態に入ると、それは消滅します。

 8.2  Atomic Events

8.2 原子イベント

  An atomic event is the transfer of a unit of information across an
  interface.  The description of an atomic event specifies a primitive
  (such as an N_UNITDATA.Request), and the service boundary at which it
  is invoked (such as the Network Service boundary). The direction of
  information flow across the boundary is implied by the definition of
  each of the primitives.

原子イベントはインタフェースの向こう側の情報のユニットの転送です。 原子イベントの記述は原始の(N_UNITDATA.Requestとしてのそのようなもの)、およびそれが呼び出されるサービス境界(Network Service境界などの)を指定します。 境界の向こう側の情報流動の方向はそれぞれに関する基関数の定義で含意されます。

  8.2.1  N.UNITDATA_request and N.UNITDATA_indication

8.2.1 N.UNITDATA_要求とN.UNITDATA_指示

   The N.UNITDATA_request and N.UNITDATA_indication atomic events occur
   at the Network Service boundary. They are defined by the Addendum to
   the Network Service Definition Covering Connectionless Data
   Transmission (ISO 8348/DAD1).

N. UNITDATA_要求とN. UNITDATAの_の指示の原子イベントはNetwork Service境界に現れます。 それらはNetwork Service Definition Covering Connectionless Data Transmission(ISO8348/DAD1)へのAddendumによって定義されます。

ISO DIS 8473 (May 1984)                                        [Page 57]

ISOは8473(1984年5月)をけなします。[57ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

   N.UNITDATA_request    (NS Source_Address,
                          NS_Destination_Address,
                          NS_Quality_of_Service,
                          NS_Userdata)

N.UNITDATA_要求(ソース_が扱うナノ秒、ナノ秒_送付先_アドレス、_サービスのナノ秒_品質_、ナノ秒_Userdata)

   N.UNITDATA_indication (NS_Source_Address,
                          NS_Destination_Address,
                          NS_Quality_of_Service, NS_Userdata)

N.UNITDATA_指示(ナノ秒_ソース_アドレス、ナノ秒_送付先_アドレス、_サービスのナノ秒_品質_、ナノ秒_Userdata)

   The     parameters     of     the     N.UNITDATA_request      and
   N.UNITDATA_indication  are  collectively  referred  to as Network
   Service Data Unit (NSDUs).

N. UNITDATA_要求とN. UNITDATA_指示のパラメタはNetwork Service Data Unit(NSDUs)とまとめて呼ばれます。

  8.2.2  SN.UNITDATA_request and SN.UNITDATA_indication

8.2.2 SN.UNITDATA_要求とSN.UNITDATA_指示

   The SN.UNITDATA_request and SN.UNITDATA_indication atomic events
   occur at the interface between the Protocol described herein and a
   subnetwork service provider. They are defined in Section 5.5 of this
   Standard.

SN.UNITDATA_要求とSN.UNITDATAの_の指示の原子イベントはここに説明されたプロトコルとサブネットワークサービスプロバイダーとのインタフェースに現れます。 それらはこのStandardのセクション5.5で定義されます。

   SN.UNITDATA_request    (SN_Source_Address,
                           SN_Destination_Address,
                           SN_Quality_of_Service,
                           SN_Userdata)

SN.UNITDATA_要求(SN_ソース_アドレス、SN_目的地_アドレス、_サービスのSN_品質_、SN_Userdata)

   SN.UNITDATA_indication (SN_Source_Address,
                           SN_Destination_Address,
                           SN_Quality_of_Service,
                           SN_Userdata)

SN.UNITDATA_指示(SN_ソース_アドレス、SN_目的地_アドレス、_サービスのSN_品質_、SN_Userdata)

   The parameters of the SN_UNITDATA request and SN_UNITDATA Indication
   are collectively referred to as Subnetwork Service Data Units
   (SNSDUs).

UNITDATAが要求するSN_とSN_UNITDATA IndicationのパラメタはSubnetwork Service Data Units(SNSDUs)とまとめて呼ばれます。

   The value of the SN_Userdata parameter may represent an Initial PDU
   or a Derived PDU.

SN_Userdataパラメタの値はInitial PDUかDerived PDUを表すかもしれません。

ISO DIS 8473 (May 1984)                                        [Page 58]

ISOは8473(1984年5月)をけなします。[58ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  8.2.3  TIMER Atomic Events

8.2.3 タイマの原子イベント

   The TIMER atomic events occur at the interface between the Protocol
   described herein and its local environment. They are defined in
   Section 5.6 of this Standard.

TIMERの原子イベントはここに説明されたプロトコルとその地方の環境とのインタフェースに起こります。 それらはこのStandardのセクション5.6で定義されます。

    S.TIMER_request  (Time,
                      Name,
                      Subscript)

S.タイマ_要求(時間、名前、添字)

    S.TIMER_cancel   (Name
                      Subscript)

S.タイマ_キャンセル(名前添字)

    S.TIMER_response (Name,
                      Subscript)

S.タイマ_応答(名前、添字)

 8.3  Operation of the Finite State Automation

8.3 有限州のオートメーションの操作

  The operation of the automaton is defined by use of the formal
  description technique and notation specified in ISO/TC97/SC16 N1347.
  This technique is based on an extended finite state transition model
  and the Pascal programming language. The technique makes use of strong
  variable typing to reduce ambiguity in interpretation of the
  specification.

オートマトンの操作はISO/TC97/SC16 N1347で指定された形式的記述のテクニックと記法の使用で定義されます。 このテクニックは拡張有限状態遷移モデルとパスカルプログラミング言語に基づいています。 テクニックは、仕様の解釈におけるあいまいさを減少させるのに強い可変タイプを利用します。

  This specification formally specifies an abstract machine which
  provides a single instance of the Connectionless-Mode Network Service
  by use of the Protocol For Providing the Connectionless-Mode Network
  Service. It should be emphasized that this formal specification does
  not in any way constrain the internal operation or design of any
  actual implementation. For example, it is not required that the
  program segments contained in the state transitions will actually
  appear as part of an actual implementation. A formal protocol
  specification is useful in that it goes as far as possible to
  eliminate any degree of ambiguity or vagueness in the specification of
  a protocol standard.

この仕様は正式にプロトコルFor Providingの使用によるConnectionless-モードNetwork Serviceのただ一つのインスタンスにConnectionless-モードNetwork Serviceを提供する抽象計算機を指定します。 この形式仕様が何らかの方法でどんな実際の実装の内部の操作かデザインも抑制しないと強調されるべきです。 例えば、状態遷移に含まれたプログラム・セグメントが実際に実際の実装の一部として現れるのが必要ではありません。 正式なプロトコル仕様は、プロトコル標準の仕様でどんな度合いのあいまいさかあいまいさも排除しにできるだけ行くので、役に立ちます。

  The formal specification contained here specifies the behavior of a
  single finite-state machine, which provides the protocol

ここに含まれた形式仕様は単一の有限状態機械の働きを指定します。(有限状態機械はプロトコルを提供します)。

ISO DIS 8473 (May 1984)                                        [Page 59]

ISOは8473(1984年5月)をけなします。[59ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  behavior corresponding to a single independent service request. It is
  expected that any actual implementation will be able to handle
  behavior corresponding to many simultaneous finite state machines.

ただ一つの独立しているサービスのリクエストに対応する振舞い。 どんな実際の実装も多くの同時の有限状態機械に対応する振舞いを扱うことができると予想されます。

ISO DIS 8473 (May 1984)                                        [Page 60]

ISOは8473(1984年5月)をけなします。[60ページ]

RFC 926                                                    December 1984

RFC926 1984年12月

  8.3.1  Type and Constant Definitions

8.3.1 タイプと一定の定義

   const

const

    ZERO  = 0;
    max_user_data = 64512;

=0のゼロを合わせてください。 最大_ユーザ_データ=64512。

   type

タイプ

    NSAP_addr_type  = ...;

NSAP_addr_タイプ=…;

     { NSAP_addr_type defines the data type for NSAP addresses, as
     passed across the Network Service Boundary. }

NSAP_addr_タイプはNetwork Service Boundaryの向こう側に通過されるようにNSAPアドレスのためのデータ型を定義します。

    NPAI_addr_type  = ...;

NPAI_addr_タイプ=…;

     { NPAI_addr_type defines the data type for the addresses carried in
     PDUs. }

NPAI_addr_タイプはPDUsで運ばれたアドレスのためのデータ型を定義します。

    SN_addr_type    = ...;

SN_addr_タイプ=…;

     { SN_addr_type defines the data type for addresses in the
     underlying service used by this protocol. }

SN_addr_タイプはこのプロトコルによって利用された基本的なサービスでアドレスのためのデータ型を定義します。

    quality_of_service_type = ...;

_サービス_タイプ=の品質_…;

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

パスコードロックを無効にするセキュリティホール

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る