RFC1139 日本語訳

Network Working Group                             IETF-OSI Working Group
Request for Comments: 1139                                     R. Hagens
                                                            January 1990

コメントを求めるワーキンググループIETF-OSIワーキンググループ要求をネットワークでつないでください: 1139 R.Hagens1990年1月

                     An Echo Function for ISO 8473

ISO8473のためのエコー機能

Status of this Memo

このMemoの状態

   This memo defines an echo function for the connection-less network
   layer protocol.  This memo is not intended to compete with an ISO
   standard.  This is a Proposed Elective Standard for the Internet.
   Distribution of this memo is unlimited.

このメモはコネクションレスなネットワーク層プロトコルのためにエコー機能を定義します。 このメモがISO規格と競争することを意図しません。 これはインターネットへのProposed Elective Standardです。 このメモの分配は無制限です。

Abstract

要約

   This memo defines an echo function for the connection-less network
   layer protocol.  Two mechanisms are introduced that may be used to
   implement the echo function.  The first mechanism is recommended as
   an interim solution for the Internet community.  The second mechanism
   will be progressed to the ANSI X3S3.3 working group for consideration
   as a work item.

このメモはコネクションレスなネットワーク層プロトコルのためにエコー機能を定義します。 エコー機能を実行するのに使用されるかもしれない2つのメカニズムが紹介されます。 最初のメカニズムはインターネットコミュニティの当座の解決策としてお勧めです。 2番目のメカニズムは考慮のために仕事項目としてANSI X3S3.3ワーキンググループに進行されるでしょう。

   When an ISO standard is adopted that provides functionality similar
   to that described by this memo, then this memo will become obsolete
   and superceded by the ISO standard.

ISO規格が採用されるとき、それが同様の機能性を提供して、次に、このメモは、時代遅れになって、ISO規格によってスーパー割譲されました。

1.  Introduction

1. 序論

   The OSI Connection-less network layer protocol (ISO 8473) defines a
   means for transmitting and relaying data and error report PDUs
   through an OSI internet.  Unfortunately, the world that these packets
   travel through is imperfect.  Gateways and links may fail.  This memo
   defines an echo function to be used in the debugging and testing of
   the OSI network layer.

OSI Connectionなしのネットワーク層プロトコル(ISO8473)はOSIインターネットを通してデータとエラー・レポートPDUsを送って、リレーするための手段を定義します。 残念ながら、これらのパケットが旅行する世界は不完全です。 ゲートウェイとリンクは失敗するかもしれません。 このメモは、OSIネットワーク層のデバッグとテストで使用されるためにエコー機能を定義します。

   Network management protocols can be used to determine the state of a
   gateway or link.  However, since these protocols themselves utilize a
   protocol that may experience packet loss, it cannot be guaranteed
   that the network management applications can be utilized.  A simple
   mechanism in the network layer is required so that systems can be
   probed to determine if the lowest levels of the networking software
   are operating correctly.  This mechanism is not intended to compete
   with or replace network management; rather it should be viewed as an
   addition to the facilities offered by network management.

ゲートウェイの状態を決定するか、またはリンクするのにネットワーク管理プロトコルを使用できます。 しかしながら、これらのプロトコル自体がパケット損失になるかもしれないプロトコルを利用するので、ネットワークマネージメントアプリケーションを利用できるのを保証できません。 ネットワーク層における簡単なメカニズムが、ネットワークソフトウェアの最も低いレベルが正しく作動しているかどうか決定するためにシステムを調べることができるくらい必要です。 このメカニズムは、ネットワークマネージメントを競争するか、または取り替えることを意図しません。 むしろそれはネットワークマネージメントで提供された施設への添加として見なされるべきです。

   There are three important issues to consider when defining an echo
   extension to ISO 8473: complexity, code-path divergence, and backward

エコー拡大をISO8473と定義すると考えるために、3つの切迫した課題があります: コード経路分岐であって、後方の複雑さ

IETF-OSI Working Group                                          [Page 1]

RFC 1139             An Echo Function for ISO 8473          January 1990

1エコーあたりIETF-OSI作業部会[1ページ]RFC1139は1990年1月にISO8473のために機能します。

   compatibility.  The complexity of the echo facility must be kept low.
   If it is not, then there is a good chance that the facility will not
   be universally provided.  The code-path consideration requires that
   the echo path through a system is identical (or very close) to the
   path used by normal data.  An echo path must succeed and fail in
   unison with the normal data path or else it will not provide a useful
   diagnostic tool.

互換性。 エコー施設の複雑さを低く保たなければなりません。 そして、それがそうでないなら、施設が一般に提供されないという十分な見込みがあります。 コード経路の考慮は、システムを通したエコー経路が正常なデータによって使用される経路と同じであることを(非常に近い)必要とします。 エコー経路が正常なデータ経路と一致して成功して、失敗しなければならない、さもなければ、それは役に立つ診断用道具を提供しないでしょう。

   Backward compatibility is an important consideration whenever a
   change is made to a protocol.  For this reason, this memo defines two
   implementation mechanisms: the short term approach and the long term
   approach.  The short term approach will produce echo packets that are
   indistinguishable from normal data ISO 8473 PDUs.  These echo packets
   may be switched through ISO 8473 routers that do not implement the
   echo function.  The short term approach will be adopted as an
   Elective Internet Standard because it is backward compatible with ISO
   8473.  However, due to its nature, the short term approach will never
   be incorporated into future versions of ISO 8473.

変更をプロトコルにするときはいつも、後方の互換性は重要な考慮すべき事柄です。 この理由で、このメモは2つの実現メカニズムを定義します: 短期間アプローチと長期に近づきます。 短期間アプローチは正常なデータISO8473PDUsから区別がつかないエコーパケットを作り出すでしょう。 これらのエコーパケットはエコー機能を実行しないISO8473ルータを通して切り換えられるかもしれません。 それがISO8473と互換性があった状態で後方であるので、短期間アプローチはElectiveインターネットStandardとして取られるでしょう。 しかしながら、自然のため、短期間アプローチはISO8473の将来のバージョンに決して組み入れられないでしょう。

   The long term approach will produce echo packets that are not
   compatible with the existing standard.  However, the long term
   approach may be acceptable by ISO as an addendum to ISO 8473.  In
   this event, backward compatibility will no longer be an issue.  At
   that juncture, the short term approach defined by this memo will be
   obsolete and superseded by the ISO addendum.

長期アプローチは既存の規格と互換性がないエコーパケットを作り出すでしょう。 しかしながら、長期アプローチはISOが付加物としてISO8473に許容できるかもしれません。 この出来事では、後方の互換性はもう問題にならないでしょう。 その時点に、このメモで定義された短期間アプローチは、時代遅れであり、ISO付加物によって取って代わられるでしょう。

2.  The Generic Echo Function

2. 一般的なエコー機能

   The following section will describe the echo function in a generic
   fashion.  This memo defines an echo-request entity.  The function of
   the echo-request entity is to accept an incoming echo-request PDU,
   perform some processing, and generate an echo-reply PDU.  Depending
   on the echo implementation, the echo-request entity may be thought of
   as an entity that exists above the network layer, or as an entity
   that co-exists with the network layer.  Subsequent sections will
   detail the short and long term implementation mechanisms.

以下のセクションは一般的なファッションでエコー機能について説明するでしょう。 このメモはエコー要求実体を定義します。 エコー要求実体の関数は、入って来るエコー要求PDUを受け入れて、何らかの処理を実行して、エコー・リプライPDUを発生させることです。 エコー実現によって、エコー要求実体はネットワーク層を超えて存在する実体として、または、ネットワーク層と共存する実体として考えられるかもしれません。 その後のセクションは長・短期実現メカニズムについて詳述するでしょう。

   For the purposes of this memo, the term "ping" shall be used to mean
   the act of transmitting an echo-request PDU to a remote system (with
   the expectation that an echo-reply PDU will be sent back to the
   transmitter).

このメモの目的において、「ピング」という用語は、エコー要求PDUをリモートシステムに伝える行為を意味するのに使用されるものとします(エコー・リプライPDUがそうする期待で、送信機は送り返されてください)。

   2.1  The Echo Request

2.1 エコー要求

      When a system decides to ping a remote system, an echo-request is
      built.  All fields of the PDU header are assigned normal values
      (see implementation specific sections for more information).  The
      address of the system to be pinged is inserted as the destination

システムが、リモートシステムを確認すると決めるとき、エコー要求は組立しています。 正常値はPDUヘッダーのすべての分野に割り当てられます(詳しい情報に関して実現の特定の部を見てください)。 確認されるべきシステムのアドレスは目的地として挿入されます。

IETF-OSI Working Group                                          [Page 2]

RFC 1139             An Echo Function for ISO 8473          January 1990

1エコーあたりIETF-OSI作業部会[2ページ]RFC1139は1990年1月にISO8473のために機能します。

      NSAP address.  The rules of segmentation defined for a DT PDU also
      apply to the echo-request PDU.

NSAPアドレス。 また、DT PDUのために定義された分割の規則はエコー要求PDUに適用されます。

      The echo-request is switched through the network toward its
      destination.  Upon reaching the destination system, the PDU is
      processed according to normal processing rules.  At the end of the
      input processing, the echo-request PDU is delivered to the echo-
      request entity.

エコー要求はネットワークを通して目的地に向かって切り換えられます。 目的地システムに達すると、正常処理規則に従って、PDUは処理されます。 入力処理の終わりに、エコー要求実体にエコー要求PDUを届けます。

      The echo-request entity will build and dispatch the echo-reply
      PDU.  This is a new PDU.  Except as noted below, this second PDU
      is built using the normal construction procedures.  The
      destination address of the echo-reply PDU is taken from the source
      address of the echo-request PDU.  Most options present in the
      echo-request PDU are copied into the echo-reply PDU (see
      implementation notes for more information).

エコー要求実体は、エコー・リプライPDUを造って、派遣するでしょう。 これは新しいPDUです。 以下に述べられるのを除いて、正常な構成手順を用いるのはこの第2PDUに建てられます。 エコー・リプライPDUの送付先アドレスはエコー要求PDUのソースアドレスから抜粋されます。 エコー要求PDUの現在のほとんどのオプションがエコー・リプライPDUにコピーされます(詳しい情報のための実現注意を見てください)。

   2.2  The Echo Reply

2.2 エコー・リプライ

      The entire echo-request PDU is included in the data portion of the
      echo-reply PDU.  This includes the echo-request PDU header as well
      as the any data that accompanies the echo-request PDU.  The entire
      echo-request PDU is included in the echo-reply so that fields such
      as the echo-request lifetime may be examined when the reply is
      received.  After the echo-reply PDU is built, it is transmitted
      toward the new destination (the original source of the echo-
      request).  The rules of segmentation defined for a DT PDU also
      apply to the echo-reply PDU.

全体のエコー要求PDUはエコー・リプライPDUのデータ部に含まれています。 これがまた、エコー要求PDUヘッダーを含んでいる、エコー要求PDUに同伴するどんなデータ。 全体のエコー要求PDUがエコー・リプライに含まれているので、それは回答が受け取られているときの寿命が調べられるかもしれないというエコー要求としてそのようなものをさばきます。 エコー・リプライPDUが組立していた後に、それは新しい目的地(エコー要求の一次資料)に向かって送られます。 また、DT PDUのために定義された分割の規則はエコー・リプライPDUに適用されます。

      The echo-reply PDU is relayed through the network toward its
      destination.  Upon reaching its destination, it is processed by
      the PDU input function and delivered to the entity that created
      the echo-request.

エコー・リプライPDUはネットワークを通して目的地に向かってリレーされます。 目的地に到着すると、それをPDU入力機能で処理して、エコー要求を作成した実体に届けます。

3.  The Short Term Implementation Mechanism

3. 短期間実現メカニズム

   The short term implementation mechanism  will use an ISO 8473 normal
   data PDU as the echo-request and echo-reply PDU.  A special NSAP
   selector value will be used to identify the echo-request and insure
   that it reaches the echo-request entity.  This selector value is
   known as the echo-request selector.  In addition, an echo-reply
   selector is defined so that the echo-reply PDU may be identified at
   the destination system.  It is important to note that (except for the
   NSAP selector) the echo-request PDU and the echo-reply PDU are
   indistinguishable from a DT PDU.

短期間実現メカニズムはエコー要求とエコー・リプライPDUとしてISO8473の正常なデータPDUを使用するでしょう。 特別なNSAPセレクタ価値は、エコー要求を特定して、エコー要求実体に達するのを保障するのに使用されるでしょう。 このセレクタ値はエコー要求セレクタとして知られています。 さらに、エコー・リプライセレクタは、目的地システムでエコー・リプライPDUを特定できるように定義されます。 (NSAPセレクタを除いた)エコー要求PDUとエコー・リプライPDUがDT PDUから区別がつかないことに注意するのは重要です。

   This approach has the advantage that it is simple and does not allow
   any code-path divergence.  In addition, this approach requires that

このアプローチは、それが利点ですが、簡単な状態で許容して、少しのコード経路分岐も許容しません。 さらに、このアプローチはそれを必要とします。

IETF-OSI Working Group                                          [Page 3]

RFC 1139             An Echo Function for ISO 8473          January 1990

1エコーあたりIETF-OSI作業部会[3ページ]RFC1139は1990年1月にISO8473のために機能します。

   only the systems which wish to generate an echo-reply PDU must
   change.  Systems that do not adhere to this memo will not generate an
   echo-reply PDU, but will still switch other echo-request and echo-
   reply PDUs.

エコー・リプライPDUを発生させたがっているシステムだけが変化しなければなりません。 このメモを固く守らないシステムが、エコー・リプライPDUを発生させませんが、それでも、他のエコー要求とエコー回答PDUsを切り換えるでしょう。

   3.1  The Echo Request

3.1 エコー要求

      An echo-request is built using the normal DT PDU construction
      procedures.  All fields of the PDU header are assigned normal
      values (see implementation notes).  The address of the system to
      be pinged is inserted as the destination NSAP address.  The
      selector field of the destination NSAP address must contain the
      echo-request selector.  The selector field of the source NSAP
      address must contain the echo-reply selector.

正常なDT PDU構成手順を用いるのはエコー要求に建てられます。 正常値はPDUヘッダーのすべての分野に割り当てられます(実現注意を見てください)。 確認されるべきシステムのアドレスは送付先NSAPアドレスとして挿入されます。 送付先NSAPアドレスのセレクタ分野はエコー要求セレクタを含まなければなりません。 ソースNSAPアドレスのセレクタ分野はエコー・リプライセレクタを含まなければなりません。

   3.2  The Echo Reply

3.2 エコー・リプライ

      Except as noted below (see implementation notes), an echo-reply is
      built using the normal DT PDU construction procedures.  The
      destination NSAP address is taken from the source address of the
      echo-request PDU.

以下(実現注意を見る)に述べられるのを除いて、正常なDT PDU構成手順を用いるのはエコー・リプライに建てられます。 送付先NSAPアドレスはエコー要求PDUのソースアドレスから抜粋されます。

   3.3  Use of NSAP Selectors

3.3 NSAPセレクタの使用

      The choice of echo-request and echo-reply NSAP selectors is a
      local matter.  However, to insure interoperability, and as an
      interim measure until use of the directory service becomes
      widespread, this memo will recommend the following default values
      (specified in decimal):

エコー要求とエコー・リプライNSAPセレクタの選択は地域にかかわる事柄です。 しかしながら、電話番号案内の使用が広範囲になるまで臨時措置として相互運用性を保障するために、このメモは以下のデフォルト値(小数では、指定される)を推薦するでしょう:

         Echo Request Selector - 30
         Echo Reply Selector - 31

エコー要求セレクタ--30エコー・リプライセレクタ--31

4.  The Long Term Implementation Mechanism

4. 長期実現メカニズム

   The long term implementation mechanism will define two new 8473 PDU
   types: ERQ (echo-request) and ERP (echo-reply).  With the exception
   of a new type code, these PDUs will be identical to the DT PDU in
   every respect.

長期実現メカニズムは新しい8473PDUがタイプする2を定義するでしょう: ERQ(エコー要求)とERP(エコー・リプライ)。 新しいタイプコードを除いて、これらのPDUsはすべての点でDT PDUと同じになるでしょう。

   4.1  The Echo Request

4.1 エコー要求

      The type code for the ERQ PDU is decimal 30.

ERQ PDUのためのタイプコードは10進30です。

   4.2  The Echo Reply

4.2 エコー・リプライ

      The type code for the ERP PDU is decimal 31.

ERP PDUのためのタイプコードは10進31です。

IETF-OSI Working Group                                          [Page 4]

RFC 1139             An Echo Function for ISO 8473          January 1990

1エコーあたりIETF-OSI作業部会[4ページ]RFC1139は1990年1月にISO8473のために機能します。

5.  Implementation Notes

5. 実現注意

   The following notes are an integral part of memo.  It is important
   that implementors take heed of these points.

以下の注意はメモの不可欠の部分です。 作成者がこれらのポイントに注意を払うのは、重要です。

   5.1  Discarding PDUs

5.1 PDUsを捨てること。

      The rules used for discarding a DT PDU (8473, sec 6.9 - sec 6.10)
      are applied when an echo-request or echo-reply is discarded.

エコー要求かエコー・リプライが捨てられるとき、DT PDU(秒6.9--8473、秒6.10)を捨てるのに使用される規則は適用されています。

   5.2  Error Report Flag

5.2エラー・レポート旗

      The error report flag may be set on the echo-request PDU, the
      echo-reply PDU, or both.  If an echo-request is discarded, the
      associated ER PDU will be sent to the echo-request source address
      on the originating machine.  If an echo-reply is discarded, the
      associated ER PDU will be sent to the echo-reply source address.
      In general, this will be the address of the echo-request entity.
      It should be noted that the echo-request entity and the originator
      of the echo-request PDU are not required to process ER PDUs.

エラー・レポート旗はエコー要求PDU、エコー・リプライPDU、または両方に設定されるかもしれません。 エコー要求が捨てると、由来しているマシンに関するエコー要求ソースアドレスに関連ER PDUを送るでしょう。 エコー・リプライが捨てると、関連ER PDUをエコー・リプライソースアドレスに送るでしょう。 一般に、これはエコー要求実体のアドレスになるでしょう。 エコー要求実体とエコー要求PDUの創始者がER PDUsを処理する必要はないことに注意されるべきです。

   5.3  Use of the Lifetime Field

5.3 生涯分野の使用

      The lifetime field of the echo-request and echo-reply PDU should
      be set to the value normally used for a DT PDU.  Note: although
      this memo does not prohibit the generation of a PDU with a
      smaller-than-normal lifetime field, this memo explicitly does not
      attempt to define a mechanism for varying the lifetime field set
      in the echo-reply PDU.  This memo recommends that the normal DT
      lifetime value should be set in the echo-request and echo-reply
      PDU.

エコー要求とエコー・リプライPDUの生涯分野は通常、DT PDUに使用される値に設定されるべきです。 以下に注意してください。 このメモは標準より小さい生涯分野があるPDUの世代を禁止しませんが、このメモは、生涯分野セットを変えるためにエコー・リプライPDUでメカニズムを定義するのを明らかに試みません。 このメモは、正常なDT生涯価値がエコー要求とエコー・リプライPDUで設定されるべきであることを勧めます。

   5.4  Transfer of Options from the echo-request
        PDU to the echo-reply PDU

5.4 Optionsのエコー要求PDUからエコー・リプライPDUまでの転送

      With two exceptions, all options present in the echo-request
      header are copied directly into the echo-reply header.  The two
      exceptions are the record route option and the source route
      option.  A record route option present in an echo-request PDU is
      copied into the echo-reply PDU, but the routes recorded in the
      option are "erased" by resetting the second octet of the option to
      3.  This allows the entire record route option space to be used by
      the echo-reply PDU.  Note: the record route present on the echo-
      request is not lost because the echo-request PDU is wholly
      contained in the data part of the echo-reply PDU.

2つの例外で、エコー要求ヘッダーの現在のすべてのオプションが直接エコー・リプライヘッダーにコピーされます。 2つの例外が、記録的なルートオプションと送信元経路オプションです。 エコー要求PDUの現在の記録的なルートオプションはエコー・リプライPDUにコピーされますが、オプションに記録されたルートは、オプションの2番目の八重奏を3にリセットすることによって、「消されます」。 これは、全体の記録的なルートオプションスペースがエコー・リプライPDUによって使用されるのを許容します。 以下に注意してください。 エコー要求PDUがエコー・リプライPDUのデータ部分に完全に含まれているので、エコー要求の現在の記録的なルートは無くなっていません。

      The second exception concerns the source route option.  A source
      route option present on the echo-request PDU is not copied into

2番目の例外は送信元経路オプションに関係があります。 エコー要求PDUの現在のオプションがコピーされない送信元経路

IETF-OSI Working Group                                          [Page 5]

RFC 1139             An Echo Function for ISO 8473          January 1990

1エコーあたりIETF-OSI作業部会[5ページ]RFC1139は1990年1月にISO8473のために機能します。

      the echo-reply PDU.

エコー・リプライPDU。

   5.5  Use of the Priority Option

5.5 優先権オプションの使用

      If the priority option is included, it will normally be set to
      value 0 (default priority).  This memo allows for priority values
      higher than 0 to be set in the echo-request or echo-reply header,
      but cautions against this practice.

優先権オプションが含まれていると、通常、それが0(デフォルト優先権)を評価するように設定されるでしょう。 エコー要求かエコー・リプライヘッダーにセットになるように0より高い優先順位の値を許容しますが、このメモはこの習慣に対して警告を許容します。

   5.6  Use of the Source Route Option

5.6 送信元経路オプションの使用

      Use of the source route option in ISO 8473 may cause packets to
      loop until their lifetime expires.  For this reason, this memo
      recommends against the use of the source route option in either an
      echo-request or echo-reply PDU.  If the source route option is
      used to specify the route that the echo-request PDU takes toward
      its destination, this memo does not recommend the use of an
      automatically generated source route on the echo-reply PDU.

ISO8473における送信元経路オプションの使用で、彼らの寿命が期限が切れるまで、パケットは輪にされるかもしれません。 この理由で、このメモはエコー要求かエコー・リプライのどちらかにおける送信元経路オプションの使用に対してPDUを推薦します。 送信元経路オプションがエコー要求PDUが目的地に向かって持って行くルートを指定するのに使用されるなら、このメモはエコー・リプライPDUの自動的に発生した送信元経路の使用を推薦しません。

   5.7  Transmission of Multiple Echo Requests

5.7 複数のエコー要求の伝達

      The echo function may be utilized by more than one process on any
      individual machine.  The mechanism by which multiple echo-requests
      and echo-replies are correlated between multiple processes on a
      single machine is a local matter and not defined by this memo.

エコー機能はどんな個々のマシンの1つ以上の工程でも利用されるかもしれません。 複数のエコー要求とエコー・リプライは単一マシンの複数の過程の間で関連させられるメカニズムが、このメモで地域にかかわる事柄であって定義されていません。

Security Considerations

セキュリティ問題

   Security issues are not addressed in this memo.

安全保障問題はこのメモに記述されません。

Author's Address

作者のアドレス

   Robert A. Hagens
   Computer Science Department
   1210 West Dayton Street
   Madison, WI  53706

西デイトン通りマディソン、ロバートA.Hagensコンピュータ理学部1210ウィスコンシン 53706

   Phone: (608) 262-1204

以下に電話をしてください。 (608) 262-1204

   EMail:  hagens@CS.WISC.EDU

メール: hagens@CS.WISC.EDU

IETF-OSI Working Group                                          [Page 6]

IETF-OSI作業部会[6ページ]