RFC1575 日本語訳
1575 An Echo Function for CLNP (ISO 8473). S. Hares, C. Wittbrodt. February 1994. (Format: TXT=22479 bytes) (Obsoletes RFC1139) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Hares
Request for Comments: 1575 Merit/NSFNET
Obsoletes: 1139 C. Wittbrodt
Category: Standards Track Stanford University/BARRNet
February 1994
野兎がコメントのために要求するワーキンググループS.をネットワークでつないでください: 1575長所/NSFNETは以下を時代遅れにします。 1139年のC.Wittbrodtカテゴリ: 標準化過程スタンフォード大学/BARRNet1994年2月
An Echo Function for CLNP (ISO 8473)
CLNPのためのエコー機能(ISO8473)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473.
このメモはコネクションレスなネットワーク層プロトコルのためにエコー機能を定義します。 ここで強制されるメカニズムが決勝がISOによって標準化されるのを処理するコネである、「修正X:」 「ISO8473へのEcho機能の追加」はISO8473のバージョン2の不可欠の部分です。
Table of Contents
目次
Section 1. Conventions ................................. 2 Section 2. Introduction ................................ 2 Section 3. The Generic Echo Function ................... 3 Section 3.1 The Echo-Request ........................... 3 Section 3.2 The Echo-Response .......................... 3 Section 4. The Implementation Mechanism ................ 4 Section 4.1 The Echo-Request ........................... 4 Section 4.2 The Echo-Response .......................... 4 Section 5. Implementation Notes ........................ 4 Section 5.1 Discarding Packets ......................... 4 Section 5.2 Error Report Flag .......................... 4 Section 5.3 Use of the Lifetime Field .................. 5 Section 5.4 Echo-request function ...................... 5 Section 5.5 Echo-response function ..................... 6 Section 5.6 Use of the Priority Option ................. 8 Section 5.7 Use of the Source Route Option ............. 8 Section 5.8 Transmission of Multiple Echo-Requests ..... 9 Section 6. Security Considerations ..................... 9 Section 7. Authors' Addresses .......................... 9 Section 8. References .................................. 9
セクション1。 コンベンション… 2 セクション2。 序論… 2 セクション3。 ジェネリックエコー機能… 3 セクション3.1 エコー要求… 3 セクション3.2 エコー応答… 3 セクション4。 実装メカニズム… 4 セクション4.1 エコー要求… 4 セクション4.2 エコー応答… 4 セクション5。 実装注意… 4 セクション5.1 パケットを捨てます… 4 セクション5.2 エラー・レポート旗… 4 セクション5.3 生涯分野の使用… 5 セクション5.4Echo-要求機能… 5 セクション5.5Echo-レスポンス関数… 6 セクション5.6 優先権オプションの使用… 8 セクション5.7 送信元経路オプションの使用… 8 セクション5.8 複数のエコー要求の伝達… 9 セクション6。 セキュリティ問題… 9 セクション7。 作者のアドレス… 9 セクション8。 参照… 9
Hares & Wittbrodt [Page 1] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[1ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
1. Conventions
1. コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
o MUST, SHALL, or MANDATORY -- the item is an absolute
requirement of the specification.
o SHALL、MANDATORY--項目は仕様に関する絶対条件であるに違いありません。
o SHOULD or RECOMMENDED -- the item should generally be followed
for all but exceptional circumstances.
o SHOULDかRECOMMENDED--一般に、商品はほとんど例外的な事情のために従われるべきです。
o MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the implementor.
o 5月かOPTIONAL--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
2. Introduction
2. 序論
The OSI Connection-less network layer protocol (ISO 8473) defines a means for transmitting and relaying data and error protocol data units, (PDUs) or preferably, packets 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. Hosts and routers which support the OSI network layer MUST be able to originate an echo packet as well as respond when an echo is received.
OSI Connectionなしのネットワーク層プロトコル(ISO8473)はOSIインターネットを通してデータを送って、リレーするための手段と誤りプロトコルデータ単位か(PDUs)か望ましくはパケットを定義します。 残念ながら、これらのパケットが旅行する世界は不完全です。 ゲートウェイとリンクは失敗するかもしれません。 このメモは、OSIネットワーク層のデバッグとテストで使用されるためにエコー機能を定義します。 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.
ゲートウェイの状態を決定するか、またはリンクするのにネットワーク管理プロトコルを使用できます。 しかしながら、これらのプロトコル自体がパケット損失になるかもしれないプロトコルを利用するので、ネットワークマネージメントアプリケーションを利用できるのを保証できません。 ネットワーク層における簡単なメカニズムが、ネットワークソフトウェアの最も低いレベルが正しく作動しているかどうか決定するためにシステムを調べることができるくらい必要です。 このメカニズムは、ネットワークマネージメントを競争するか、または取り替えることを意図しません。 むしろそれは追加としてネットワークマネージメントで提供された施設に見なされるべきです。
The code-path consideration requires that the echo path through a system be 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.
コード経路の考慮は、システムを通したエコー経路が正常なデータによって使用される経路と同じであることを(非常に近い)必要とします。 エコー経路が正常なデータ経路と一致して成功して、失敗しなければならない、さもなければ、それは役に立つ診断用道具を提供しないでしょう。
Previous drafts describing an echo function for CLNP offered two implementation alternatives (see RFC 1139). Although backward compatibility is an important consideration whenever a change is made to a protocol, it is more important at this point that the echo mechanisms used on the Internet interoperate. For this reason, this memo defines one implementation mechanism (consistent with one of the previous drafts).
CLNPのためにエコー機能について説明する前の草稿が2つの実装選択肢を提供しました(RFC1139を見てください)。 変更をプロトコルにするときはいつも、後方の互換性は重要な考慮すべき事柄ですが、ここに、インターネットで使用されるエコーメカニズムが共同利用するのは、より重要です。 この理由で、このメモは1つの実装メカニズム(前の草稿の1つと一致した)を定義します。
Hares & Wittbrodt [Page 2] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[2ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
3. The Generic Echo Function
3. ジェネリックエコー機能
The following section describes 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 packet, perform some processing, and generate an echo-response packet. The echo implementation may be thought of as an entity that coexists with the network layer. Subsequent sections will detail the implementation mechanism.
以下のセクションはジェネリックファッションでエコー機能について説明します。 このメモはエコー要求実体を定義します。 エコー要求実体の関数は、入って来るエコー要求パケットを受け入れて、何らかの処理を実行して、エコー応答パケットを生成することです。 エコー実装はネットワーク層と共存する実体として考えられるかもしれません。 その後のセクションは実装メカニズムについて詳述するでしょう。
For the purposes of this memo, the term "ping" shall be used to mean the act of transmitting an echo-request packet to a remote system (with the expectation that an echo-response packet will be sent back to the transmitter).
このメモの目的において、「ピング」という用語は、リモートシステムにエコー要求パケットを伝える行為を意味するのに使用されるものとします(エコー応答パケットがそうする期待で、送信機は送り返されてください)。
3.1. The Echo-Request
3.1. エコー要求
When a system decides to ping a remote system, an echo-request is built. All fields of the packet 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 NSAP address. The rules of segmentation defined for a data (DT) packet also apply to the echo-request packet.
システムが、リモートシステムを確認すると決めるとき、エコー要求は組立しています。 正常値はパケットのヘッダーのすべての分野に割り当てられます(詳しい情報に関して実装の特定の部を見てください)。 確認されるべきシステムのアドレスは送付先NSAPアドレスとして挿入されます。 また、データ(DT)パケットのために定義された分割の規則はエコー要求パケットに適用されます。
The echo-request is switched through the network toward its destination. (An echo packet must follow the same path as CLNP data packet with the same options in the CLNP header.) Upon reaching the destination system, the packet is processed according to normal processing rules. At the end of the input processing, the echo- request packet is delivered to the echo-request entity.
エコー要求はネットワークを通して目的地に向かって切り換えられます。 (エコーパケットはCLNPヘッダーで同じオプションでCLNPデータ・パケットと同じ経路に続かなければなりません。) 目的地システムに達すると、正常処理規則に従って、パケットは処理されます。 入力処理の終わりに、エコーリクエスト・パケットはエコー要求実体に提供されます。
The echo-request entity will build and dispatch the echo-response packet. This is a new packet. Except as noted below, this second packet is built using the normal construction procedures. The destination address of the echo-response packet is taken from the source address of the echo-request packet. Most options present in the echo-request packet are copied into the echo-response packet (see implementation notes for more information).
エコー要求実体は、エコー応答パケットを建てて、派遣するでしょう。 これは新しいパケットです。 以下に述べられるのを除いて、正常な構成手順を用いるのはこの2番目のパケットに建てられます。 エコー応答パケットの送付先アドレスはエコー要求パケットのソースアドレスから抜粋されます。 エコー要求パケットの現在のほとんどのオプションがエコー応答パケットにコピーされます(詳しい情報のための実装注意を見てください)。
3.2. The Echo-Response
3.2. エコー応答
The entire echo-request packet is included in the data portion of the echo-response packet. This includes the echo-request packet header as well as any data that accompanies the echo-request packet. The entire echo-request packet is included in the echo-response so that fields such as the echo-request lifetime may be examined when the response is received. After the echo-response packet is built, it is transmitted toward the new destination (the original source of the
全体のエコー要求パケットはエコー応答パケットのデータ部に含まれています。 これはエコー要求に伴うどんなデータと同様にエコー要求パケットヘッダーパケットを含んでいます。 全体のエコー要求パケットがエコー応答に含まれているので、それは応答が受け取られているときの寿命が調べられるかもしれないというエコー要求としてそのようなものをさばきます。 エコー応答パケットが組立していた後に、それが新しい目的地に向かって送られる、(一次資料
Hares & Wittbrodt [Page 3] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[3ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
echo-request). The rules of segmentation defined for a data packet also apply to the echo-response packet.
エコー要求) また、データ・パケットのために定義された分割の規則はエコー応答パケットに適用されます。
The echo-response packet is relayed through the network toward its destination. (A echo response packet must follow the same path as a CLNP data packet with the same options in the CLNP header.) Upon reaching its destination, it is processed by the packet input function and delivered to the entity that created the echo-request.
エコー応答パケットはネットワークを通して目的地に向かってリレーされます。 (エコー応答パケットはCLNPヘッダーで同じオプションでCLNPデータ・パケットと同じ経路に続かなければなりません。) 目的地に到着すると、それは、パケット入力機能によって処理されて、エコー要求を作成した実体に提供されます。
4. The Implementation Mechanism
4. 実装メカニズム
The implementation mechanism defines two new 8473 packet types: ERQ (echo-request) and ERP (echo-response). With the exception of a new type code, these packets will be identical to the date packet in every respect.
実装メカニズムは8473年の新しいパケットがタイプする2を定義します: ERQ(エコー要求)とERP(エコー応答)。 新しいタイプコードを除いて、これらのパケットはすべての点で日付のパケットと同じになるでしょう。
4.1. The Echo-Request
4.1. エコー要求
The type code for the echo-request packet is decimal 30.
エコー要求パケットのためのタイプコードは10進30です。
4.2. The Echo-Response
4.2. エコー応答
The type code for the echo-response packet is decimal 31.
エコー応答パケットのためのタイプコードは10進31です。
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 Packets
5.1. パケットを捨てます。
The rules used for discarding a data packet (ISO 8473, Section 6.9 - Section 6.10) are applied when an echo-request or echo-response is discarded.
エコー要求かエコー応答が捨てられるとき、データ・パケット(ISO8473、セクション6.9--6.10を区分する)を捨てるのに使用される規則は適用されています。
5.2. Error Report Flag
5.2. エラー・レポート旗
The error report flag may be set on the echo-request packet, the echo-response packet, or both. If an echo-request is discarded, the associated error-report (ER) packet will be sent to the echo-request source address on the originating machine. If an echo-response is discarded, the associated error-report packet will be sent to the echo-response source address. In general, this will be the destination address of the echo-request entity. It should be noted that the echo-request entity and the originator of the echo-request packet are not required to process error-report packets.
エラー・レポート旗はエコー要求パケット、エコー応答パケット、または両方に設定されるかもしれません。 エコー要求が捨てると、関連エラー・レポート(ER)パケットを起因するマシンに関するエコー要求ソースアドレスに送るでしょう。 エコー応答が捨てると、関連エラー・レポートパケットをエコー応答ソースアドレスに送るでしょう。 一般に、これはエコー要求実体の送付先アドレスになるでしょう。 エコー要求実体とエコー要求パケットの創始者がエラー・レポートパケットを処理する必要はないことに注意されるべきです。
Hares & Wittbrodt [Page 4] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[4ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
5.3. Use of the Lifetime Field
5.3. 生涯分野の使用
The lifetime field of the echo-request and echo-response packets should be set to the value normally used for a data packet. Note: although this memo does not prohibit the generation of a packet 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-response packet. This memo recommends the lifetime value that would under normal circumstances by used when sending a data packet.
エコー要求とエコー応答パケットの生涯分野は通常、データ・パケットに使用される値に設定されるべきです。 以下に注意してください。 このメモは標準より小さい生涯分野でパケットの世代を禁止しませんが、このメモは、エコー応答パケットで生涯分野セットを変えるためにメカニズムを定義するのを明らかに試みません。 このメモはデータ・パケットを送るとき使用される平常な時の下でそうする生涯値を推薦します。
5.4. Echo-request function
5.4. エコー要求機能
This function is invoked by system management to obtain information about the dynamic state of the Network layer with respect to (a) the reachability of specific network-entities, and (b) the characteristics of the path or paths that can be created between network-entities through the operation of Network layer routing functions. When invoked, the echo-request function causes an echo- request (ERQ) packet to be created. The echo-request packet shall be constructed and processed by ISO 8473 network-entities in end systems and intermediate systems in exactly the same way as the data packet, with the following caveats:
この機能は、(a) 特定のネットワーク実体の可到達性、および(b) ネットワーク実体の間でNetwork層の経路選択機能の操作で作成できる経路か経路の特性に関してNetwork層の動態の情報を得るためにシステム管理で呼び出されます。 呼び出されると、エコー要求機能で、エコー要求(ERQ)パケットを作成します。 エコー要求パケットは、エンドシステムと中間システムでISO8473ネットワーク実体によってまさにデータ・パケットと同じように組み立てられて、処理されるものとします、以下の警告で:
a) The information available to the packet composition function
(ISO 8473) consists of current state, local information, and
information supplied by system management.
a) パケット構成機能(ISO8473)に利用可能な情報は現状、ローカルの情報、およびシステム管理で提供された情報から成ります。
b) The source and destination address fields of the echo-request
packet shall contain, respectively, a Network entity title (NET)
of the originating network-entity and a Network entity title of
the destination network-entity (which may be in either an end
system or an intermediate system). NOTE: A Network entity title
is syntactically indistinguishable from an NSAP address. The
additional information in an NSAP address, if any, beyond that
which is present in a Network entity title, is relevant only to
the operation of the packet decomposition function in a
destination end system, and therefore is not needed for the
processing of an echo-request packet (from which no N-UNITDATA
indication is ever produced). The fact that the source and
destination address fields of the echo-request packet contain NETs
rather than NSAP addresses therefore does not affect the
processing of an echo-request packet by any network-entity.
b) エコー要求パケットのソースと目的地アドレス・フィールドはそれぞれ起因するネットワーク実体のNetwork実体タイトル(NET)と目的地ネットワーク実体のNetwork実体タイトル(エンドシステムか中間システムのどちらかにあるかもしれない)を含むものとします。 以下に注意してください。 Network実体タイトルはNSAPアドレスからシンタクス上区別がつきません。 Network実体タイトルに存在しているそれを超えたもしあればNSAPアドレスの追加情報は、目的地エンドシステムにおける、パケット分解機能の操作だけに関連していて、したがって、エコー要求パケット(N-UNITDATA指示が全く今までに起こされない)の処理に必要ではありません。 したがって、エコー要求パケットのソースと目的地アドレス・フィールドがNSAPアドレスよりむしろNETsを含んでいるという事実はどんなネットワーク実体でもエコー要求パケットの処理に影響しません。
c) When an echo-request packet has reached its destination, as
determined by the Header processing (call HEADER FORMAT Analysis
function in ISO 8473), the echo-response function shall handle
this Network Protocol Data Units (NPDU) instead of the packet
c) エコー要求パケットがHeader処理で決定するように目的地に到着したとき(呼び出しHEADER FORMAT AnalysisはISO8473で機能します)、エコーレスポンス関数はパケットの代わりにこのNetworkプロトコルData Units(NPDU)を扱うものとします。
Hares & Wittbrodt [Page 5] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[5ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
decomposition function. In ISO 8473, the packet decomposition
function is like a decomposing fish on the sea shore - it takes a
packet down to its bare bones and processes it.
分解機能。 ISO8473では、パケット分解機能は海の岸の分解している魚に似ています--それは、パケットを骨子まで取って、それを処理します。
Also, it is up to each individual system whether or not handling
echo-request packets involves system management. One example of
involving system management is the reporting reception of the echo
packets as some systems do with the ping packet. Some systems
find this of value if they are being pinged to death.
また、エコー要求パケットを扱うとシステム管理がかかわるか否かに関係なく、それは各個人能率給制まで達しています。 いくつかのシステムがピングパケットを処理するとき、意味ありげなシステム管理に関する1つの例がエコーパケットの報告レセプションです。 それらが死ぬほど確認されているなら、いくつかのシステムが価値のこれに当たります。
d) The maximum length of the echo-request packet is equal to the
maximum length of the echo-response packet minus the maximum
length of the echo-response packet header. This ensures that the
entire echo-request packet can be contained within the data field
of the echo-response packet (see ISO 8473).
d) エコー要求パケットの最大の長さはエコー応答パケットのヘッダーの最大の長さを引いてエコー応答パケットの最大の長さと等しいです。 これは、エコー応答パケットのデータ・フィールドの中に全体のエコー要求パケットを保管できるのを確実にします(ISO8473を見てください)。
e) The data part of the echo-request packet may, as a local
matter, contain zero or more octets with any values that fit
within the echo-request packet. (see (d) above for maximum length
of the echo-request packet). If the first octet of data is binary
1000 0001, then an echo-response header is contained in the echo-
request packet. The existence of this header insures that a
router can formulate a standard echo-response packet.
e) いずれがあるパケットが地域にかかわる事柄としてゼロか以上を含むかもしれないというエコー要求八重奏のデータ部分はエコー要求パケットの中でその発作を評価します。 (エコー要求パケットの最大の長さに関して(d) 上を見ます。) データの最初の八重奏が2進の1000 0001であるなら、エコー応答ヘッダはエコーリクエスト・パケットに含まれています。 このヘッダーの存在は、ルータが標準のエコー応答パケットを定式化できるのを保障します。
Normally, the "more segmentation" flag in the encapsulated echo- response packet header shall be zero, and the segmentation portion of the encapsulated packet shall not be included. The segmentation length in the echo-response packet header shall be zero.
通常、カプセル化されたエコー応答パケットのヘッダーの「より多くの分割」旗はゼロになるでしょう、そして、カプセル化されたパケットの分割一部を含んでいないものとします。 エコー応答パケットのヘッダーの分割の長さはゼロになるでしょう。
If the "more segmentation" flag is set in the encapsulated echo- response packet header, then a segmentation length shall be filled in and the segmentation part of the echo-response packet header will be present in the echo-response header. This same segmentation function shall be present in the echo-response sent by the router.
「より多くの分割」旗がカプセル化されたエコー応答パケットのヘッダーに設定されるなら、分割の長さは記入されるものとします、そして、エコー応答パケットのヘッダーの分割一部がエコー応答ヘッダに存在するでしょう。 この同じ分割機能はルータによって送られたエコー応答で存在するでしょう。
NOTE: However, this formulated echo-response is not required between any two systems. With a common format for an echo-request packet used in an environment such as the Internet, the echo-response header may not be needed, and may in fact be unnecessary overhead.
以下に注意してください。 しかしながら、この定式化されたエコー応答はどんな2台のシステムの間でも必要ではありません。インターネットなどの環境で使用されるエコー要求パケットのための一般的な形式では、エコー応答ヘッダは、必要でないかもしれなく、事実上、頭上で不要であるかもしれません。
5.5. Echo-response function
5.5. エコーレスポンス関数
This function is performed by a network-entity when it has received an echo-request packet that has reached its destination, as determined by the Header format analysis function (ISO 8473 clause 6.3) that is, an echo-request packet which contains, in its destination address field, a Network entity title that identifies the network-entity. When invoked, the echo-response function causes an
目的地に到着したエコー要求パケットを受けたとき、この機能はネットワーク実体によって実行されます、すなわち、目的地アドレス・フィールドにネットワーク実体を特定するNetwork実体タイトルを保管しているHeader形式分析機能(6.3番目のISO8473節)で同じくらい断固としたエコー要求パケット。 呼び出されたいつ、エコーレスポンス関数原因
Hares & Wittbrodt [Page 6] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[6ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
echo-response (ERP) packet to be created. The echo-response packet shall be constructed and processed by ISO 8473 network-entities in end systems and intermediate systems in exactly the same way as the data packet, with the following caveats:
作成されるべきエコー応答(ERP)パケット。 エコー応答パケットは、エンドシステムと中間システムでISO8473ネットワーク実体によってまさにデータ・パケットと同じように組み立てられて、処理されるものとします、以下の警告で:
a) The information available to the packet composition function
consists of current state, local information, and information
contained in the corresponding echo-request packet.
a) パケット構成機能に利用可能な情報は対応するエコー要求パケットに含まれた現状、ローカルの情報、および情報から成ります。
b) The source address field of the echo-response packet shall
contain the value of the destination address field of the
corresponding echo-request packet. The destination address field
of the echo-response packet shall contain the value of the source
address field of the corresponding echo-request packet.
b) エコー応答パケットのソースアドレス分野は対応するエコー要求パケットの目的地アドレス・フィールドの値を含むものとします。 エコー応答パケットの目的地アドレス・フィールドは対応するエコー要求パケットのソースアドレス・フィールドの値を含むものとします。
c) The echo-request packet, in its entirety, shall be placed into
the data part of the echo-response packet. The data part of the
echo-response packet shall contain only the corresponding echo-
request packet.
c) エコー要求パケットはエコー応答パケットのデータ一部に全体として置かれるものとします。 エコー応答パケットのデータ一部が対応するエコーリクエスト・パケットだけを含むものとします。
d) If the data part of the echo-request packet contains an echo-
response header, the packet composition function may, but is not
required to, use some or all of the information contained therein
to select values for the fields of the echo-response packet
header. In this case, however, the value of the lifetime field
contained in the echo-response packet header in the echo-request
packet data part must be used as the value of the lifetime field
in the echo-response packet. The values of the segment length and
checksum fields shall be computed by the network-entity regardless
of the contents of those fields in the echo-response packet header
in the data part of the echo-request packet.
d) エコー要求パケットのデータ一部は応答ヘッダ、パケット構成機能が含むエコーを含んでいますが、必要でないなら、エコー応答パケットのヘッダーの分野に値を選択するためにそこに含まれた情報のいくつかかすべてを使用してください。 しかしながら、この場合、エコー応答パケットの生涯分野の値としてエコー要求パケットデータ部分にエコー応答パケットのヘッダーに含まれた生涯分野の値を使用しなければなりません。 セグメントの長さとチェックサム分野の値はエコー要求パケットのデータ一部のエコー応答パケットのヘッダーのそれらの分野のコンテンツにかかわらずネットワーク実体によって計算されるものとします。
e) The options part of the echo-response packet may contain any
(or none) of the options described in ISO 8473 (but see Section
5.7 of this RFC). The values for these options, if present, are
determined by the network-entity as a local matter. They may be,
but are not required to be, either identical to or derived from
the corresponding options in the echo-request packet and/or the
echo-response packet header contained in the data part of the
echo-request packet (if present). The source routing option in
the echo-response packet shall not be identical to (copied from)
the source routing option in the echo-request packet header. If
the recording of route option in the echo-response packet is
identical to (copied from) the recording of route option in the
echo-request packet header, the second octet of the parameter
value field shall be set to the value 3.
e) エコー応答パケットのオプション一部がISO8473で説明されたオプションのいずれ(または、なにも)も含むかもしれません(このRFCのセクション5.7を見てください)。 存在しているなら、これらのオプションのための値は地域にかかわる事柄としてネットワーク実体で決定します。 それらは、あるかもしれませんが、エコー要求パケットのデータ一部にエコー要求パケット、そして/または、エコー応答パケットのヘッダーに含まれて、あるか、同じであるかまたは対応するオプションから派生していて、(現在)であることが必要ではありません。 エコー応答パケットのソースルーティングオプションはエコー要求パケットのヘッダーで(模造します)ソースルーティングオプションと同じにならないでしょう。 エコー応答パケットでのルートオプションの録音がエコー要求パケットのヘッダーでのルートオプションの(模造します)録音と同じであるなら、パラメタ値の分野の2番目の八重奏は値3に設定されるものとします。
Hares & Wittbrodt [Page 7] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[7ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
f) It is a local matter whether or not the destination network-
entity performs the lifetime control function on an echo-request
packet before performing the echo-response function. The
destination network-entity shall make the same decision in this
regard that it would make, as a local matter, for a data packet in
accordance with ISO 8473.
f) エコーレスポンス関数を実行する前に目的地が実体をネットワークでつなぐかどうかが生涯コントロール機能をエコー要求パケットに実行するのは、地域にかかわる事柄です。 目的地ネットワーク実体はそれが作るこの点における同じ決定をするものとします、地域にかかわる事柄として、ISO8473に従ったデータ・パケットのために。
5.6. Use of the Priority Option
5.6. 優先権オプションの使用
The 8473 priority function indicates the relative priority of
packet. 0 is normal and 14 is the highest. Packets with higher
values will be transmitted before lower values. The specific
action upon receiving a 8473 packet with the priority field set is
a "LOCAL MATTER". These means, any two systems could do it
differently.
8473年の優先権機能はパケットの相対的な優先権を示します。 0は正常です、そして、14は最も高いです。 より高い値があるパケットは下側の値の前に伝えられるでしょう。 優先権分野セットで8473年のパケットを受けることへの特定の動作は「地域にかかわる事柄」です。 これらの手段であり、どんな2台のシステムも異なってそれをするかもしれません。
Hopefully, in the future, Internet routers will handle this as a
priority queueing function. Some implementors consider the
priority queueing function to be a cap. For example, if a router
is congested, all those packets with priorities higher than 20,
will be allowed through, and those with priority less than 20 will
be dropped.
希望をいだいてと、将来、インターネットルータは優先権待ち行列機能としてこれを扱うでしょう。 作成者の中には優先権待ち行列機能が上限であると考える人もいます。 例えばプライオリティが20より高いそれらのすべてのパケットがルータが混雑しているなら通じて許容されるでしょう、そして、優先権20があるものは下げられるでしょう。
In short, the basic function of priority has wide latitude in the
ISO specification. This wide latitude of implementation needs to
be narrowed for implementations within a common network
environment such as the Internet. The 8473 priority function is
rarely implemented in today's Internet. The transmission of an
echo-request packet with a priority set may provided unexcepted
results until a more wide spread deployment of the priority
feature in 8473 capable routers and end systems.
要するに、優先権の基本機能はISO仕様に広い緯度を持っています。 実装のこの広い緯度は、実装のためにインターネットなどの一般的なネットワーク環境の中で狭くされる必要があります。 8473年の優先権機能は今日のインターネットでめったに実装されません。 非除外された優先権の、より広い普及の展開までの結果が8473年にできるルータとエンドシステムを特徴とするなら、優先権セットがあるエコー要求パケットのトランスミッションはそうするかもしれません。
However, if the priority function must be used it is the safest
value may be the value 0 - which indicates Normal priority. It
most likely this value will follow the 8473 pathways.
しかしながら、優先権機能を使用しなければならないなら、値0(Normalを示します)が優先権であったかもしれないなら、それは最も安全な値です。 それはたぶん8473の小道に続くでしょうこれが、評価する。
In the future, as the implementation of the priority function
further Internet documents will need to deal with its expected
use.
将来、優先権機能の実装として、さらなるインターネットドキュメントは、予想された使用に対処する必要があるでしょう。
5.7. Use of the Source Route Option
5.7. 送信元経路オプションの使用
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-response packets. If the source route option
is used to specify the route that the echo-request packet takes
toward its destination, this memo does not recommend the use of an
ISO8473における送信元経路オプションの使用で、彼らの寿命が期限が切れるまで、パケットは輪にされるかもしれません。 この理由で、このメモは、ソースの使用に対してエコー要求かエコー応答パケットのどちらかでオプションを発送するように勧めます。 送信元経路オプションはエコー要求パケットが目的地に向かって持って行くルートを指定するのに使用されます、とこのメモは使用を勧めません。
Hares & Wittbrodt [Page 8] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994
1エコーあたり野兎とWittbrodt[8ページ]RFC1575は1994年2月にCLNP(ISO8473)のために機能します。
automatically generated source route on the echo-response packet.
エコー応答パケットの上の自動的に生成している送信元経路。
5.8. Transmission of Multiple Echo-Requests
5.8. 複数のエコー要求の伝達
The echo function may be utilized by more than one process on any
individual machine. The mechanism by which multiple echo-requests
and echo-responses are correlated between multiple processes on a
single machine is a local matter and not defined by this memo.
エコー機能はどんな個々のマシンの上の1つ以上のプロセスによって利用されるかもしれません。 複数のエコー要求とエコー応答は単一マシンの上の複数のプロセスの間で関連させられるメカニズムが、このメモで地域にかかわる事柄であって定義されていません。
6. Security Considerations
6. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
7. Authors' Addresses
7. 作者のアドレス
Susan K. Hares
MERIT/NSFNET
Internet Engineering
1075 Beal Avenue
Ann Arbor, MI 48109-2112
ビール・Avenueアナーバー、スーザンK.野兎の長所/NSFNETインターネットEngineering1075MI48109-2112
Phone: (313) 936-3000
EMail: skh@merit.edu
以下に電話をしてください。 (313) 936-3000 メールしてください: skh@merit.edu
Cathy J. Wittbrodt
Stanford University/BARRNet
Networking Systems
Pine Hall 115
Stanford, CA 94305
カリフォルニア 松のHall115スタンフォード、キャシーJ.Wittbrodtスタンフォード大学/BARRNetネットワークシステム94305
Phone: (415) 725-5481
EMail: cjw@magnolia.Stanford.EDU
以下に電話をしてください。 (415) 725-5481 メールしてください: cjw@magnolia.Stanford.EDU
8. References
8. 参照
[1] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[1] ISO/IEC。 コネクションレスなモードネットワーク・サービスを提供するには、議定書を作ってください。 国際規格8473、ISO/IEC JTC1、スイス1986。
[2] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
Working Group, January 1990.
[2]Hagens、R.、「ISO8473のためのエコー機能」、RFC1139、IETF-OSI作業部会、1990年1月。
[3] ISO 8473-1993 Protocol for providing the connectionless-mode
network service, edition 2 (IS under preparation).
[3] コネクションレスなモードネットワーク・サービスを提供するためのISO8473-1993プロトコル、版2(準備で、あります)。
Hares & Wittbrodt [Page 9]
野兎とWittbrodt[9ページ]
一覧
スポンサーリンク
