Network Working Group J.-M. Pittet
Request for Comments: 2834 Silicon Graphics Inc.
Obsoletes: 1374 May 2000
Category: Standards Track
ARP and IP Broadcast over HIPPI-800
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC-2067 "IP over HIPPI") obsoletes RFC-1374.
この文書では、ANSI高性能パラレルインタフェース（HIPPI）ハードウェアアドレスへとHARPの直接の延長として論理IPサブネット（LIS）にIPブロードキャストをエミュレートするためにIPアドレスを解決する方法を指定します。このメモは、HIPPI-800（またギガバイトシステムネットワーク、GSNとしても知られる）HIPPI-6400との間で相互運用できますHARPを定義します。この文書は、（RFC-2067 "HIPPIオーバーIP" と組み合わせたとき）、RFC-1374を廃止します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Global Concepts . . . . . . . . . . . . . . . . . . . 3
3.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 3
4. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
4.1 Background . . . . . . . . . . . . . . . . . . . . . 5
4.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 7
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 8
5.1.1 Selecting the authoritative HARP service . . . 8
5.1.2 HARP registration phase . . . . . . . . . . . . 9
5.1.3 HARP operational phase . . . . . . . . . . . . 10
5.2 HARP Client Operational Requirements . . . . . . . . . . 11
5.3 Receiving Unknown HARP Messages . . . . . . . . . . . 12
5.4 HARP Server Operational Requirements . . . . . . . . 12
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 14
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 14
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 15
6.1 HIPPI-LE Header of HARP Messages . . . . . . . . . . 15
6.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 16
6.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 16
6.1.3 Diagram . . . . . . . . . . . . . . . . . . . . 17
6.2 HIPPI Hardware Address Formats and Requirements . . . 18
6.2.1 48-bit Universal LAN MAC Addresses . . . . . . 18
6.3 HARP and InHARP Message Formats . . . . . . . . . . . 19
6.3.1 Example Message encodings . . . . . . . . . . . 22
6.3.2 HARP_NAK message format . . . . . . . . . . . . 22
6.3.3 Combined HIPPI-LE and HARP message addresses . 22
7. Broadcast and Multicast . . . . . . . . . . . . . . . . . 23
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 23
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 24
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 24
7.4 A Note on Broadcast Emulation Performance . . . . . . 24
8. HARP for Scheduled Transfer Protocol . . . . . . . . . . 25
9. Discovery of One's Own Switch Address . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . 26
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 26
12. HARP Examples . . . . . . . . . . . . . . . . . . . . . . 26
12.1 Registration Phase of Client Y on Non-broadcast HW . 27
12.2 Registration Phase of Client Y on Broadcast Hardware 28
12.3 Operational Phase (phase II) . . . . . . . . . . . . 28
12.3.1 Standard successful HARP_Resolve example . . 29
12.3.2 Standard non-successful HARP_Resolve example 30
13. References . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32
15. Changes from RFC-1374 . . . . . . . . . . . . . . . . . . 32
16. Author's Address . . . . . . . . . . . . . . . . . . . . 33
17. Full Copyright Statement . . . . . . . . . . . . . . . . 34
The ANSI High-Performance Parallel Interface (HIPPI) is a dual simplex data channel. HIPPI can send and receive data simultaneously at 800 or 1600 megabits per second. Between 1987 and 1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1) Standardized five documents that bear on the use of HIPPI as a network interface. They cover the physical and electrical specification (HIPPI-PH [1]), the framing of a stream of bytes (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC (HIPPI-LE [3]), the behavior of a physical layer switch (HIPPI-SC [4]) and the physical-level and optical specification (HIPPI-Serial [5]). HIPPI-LE also implies the encapsulation of Internet Protocol[5]. The reader should be familiar with the ANSI HIPPI documents. Approved ANSI NCITS standards are available from ANSI (http://www.ansi.org). The working documents of the T11.1 working group may be obtained from the T11 web page (http://www.t11.org/).
ANSI高性能パラレルインタフェース（HIPPI）は、デュアルシンプレックスデータチャネルです。 HIPPIは、毎秒800または1600メガビットのデータを同時に送受信することができます。 1987年から1997年の間に、（今NCITS T11.1として知られている）ANSI X3T11.1 HIPPIワーキンググループは、ネットワークインタフェースとしてHIPPIの使用に耐え5つの文書を標準化しました。これらは、IEEE 802.2 LLC（HIPPI-LE [3]）の挙動のカプセル化を、バイトストリームのフレーミングを物理的および電気的仕様（HIPPI-PH [1]）を覆う（HIPPI-FP [2]）物理レイヤスイッチ（HIPPI-SC [4]）と物理レベルおよび光学仕様（HIPPIシリアル[5]）。 HIPPI-LEは、インターネットプロトコル[5]のカプセル化を意味しています。読者は、ANSI HIPPI文書に精通している必要があります。承認されたANSI NCITS規格は、ANSI（http://www.ansi.org）から入手できます。 T11.1ワーキンググループの作業文書は、T11のWebページ（http://www.t11.org/）から得ることができます。
HIPPI switches can be used to connect a variety of computers and peripheral equipment for many purposes, but the working group stopped short of describing their use as Local Area Networks. RFC-2067 [15] describes the encapsulation of IP over HIPPI-800. This memo takes up where the working group and RFC-2067 [15] left off and defines address resolution and LIS IP broadcast emulation for HIPPI-800 networks.
HIPPIスイッチは、多くの目的のためにコンピュータと周辺機器の様々を接続するために使用することができますが、ワーキンググループは、ローカルエリアネットワークとしての使用を説明する短い停止しました。 RFC-2067 [15]はHIPPI-800オーバーIPのカプセル化を説明しています。ワーキンググループおよびRFC-2067 [15]がオフに左及びアドレス解決及びHIPPI-800ネットワークのLIS IP放送エミュレーションを定義する場合、このメモを取ります。
While investigating possible solutions for HARP it became evident that IP broadcast could easily be emulated for both HIPPI-800 and HIPPI-6400 hardware types. This is useful since HIPPI switches are not required to implement broadcast but many standard networking protocols rely on broadcast. This memo therefore further addresses the emulation of LIS IP broadcast as an extension of HARP.
HARPのための可能な解決策を検討している間、それは、IP放送を簡単にHIPPI-800とHIPPI-6400ハードウェアの種類の両方のためにエミュレートすることができたことが明らかになりました。 HIPPIスイッチはブロードキャストを実装するために必要な多くの標準的なネットワークプロトコルは、ブロードキャストに依存していないので、これは便利です。このメモは、したがって、さらにHARPの延長としてLIS IP放送のエミュレーションに対応しています。
2 Terminology
2用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [18].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC-2119 [18]に記載されているように解釈されます。
In the following discussion, the terms "requester" and "target" are used to identify the port initiating the address resolution request and the port whose address it wishes to discover, respectively. If not all switches in the LIS support broadcast then there will be a HARP server providing the address resolution service and it will be the source of the reply. If on the other hand all switches support broadcast then the source address of a reply will be the target's target address.
以下の議論では、用語「要求者」と「ターゲット」はアドレスがそれぞれ、検出したいアドレス解決要求及びポートを開始するポートを識別するために使用されます。そうでない場合LISサポート放送内のすべてのスイッチは、アドレス解決サービスを提供するHARPサーバがあるでしょうし、それが応答のソースになります。一方、すべてのスイッチがブロードキャストをサポートする場合は、応答の送信元アドレスは、ターゲットのターゲットアドレスになります。
Values are decimal unless otherwise noted. Formatting follows IEEE 802.1A canonical bit order and and HIPPI-FP bit and byte order.
特に断りのない限り、値は小数です。フォーマットは、IEEE 802.1A正規のビット順とし、HIPPI-FPビットやバイト順序に従います。
Broadcast
放送
A distribution mode which transmits a message to all ports. Particularly also the port sending the message.
すべてのポートにメッセージを送信する配信モード。特に、ポートは、メッセージを送信します。
Classical/Conventional
従来の/クラシック
Both terms are used to refer to networks such as Ethernet, FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs.
両方の用語は、HIPPI-SC用のLANとは異なるように、例えばイーサネット（登録商標）、FDDI、および他の802のLANタイプなどのネットワークを参照するために使用されます。
Destination
先
The HIPPI port that receives data from a HIPPI Source.
HIPPIソースからのデータを受信するHIPPIポート。
HARP
ハープ
HARP describes the whole set of HIPPI address resolution encodings and algorithms defined in this memo. HARP is a combination and adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 [13] and Inverse ARP (InARP) [7] (see section 5). HARP also describes the HIPPI specific version of ARP [10] (i.e. the protocol and the HIPPI specific encoding).
HARPは、このメモで定義されたHIPPIアドレス解決エンコーディング及びアルゴリズムのセット全体を記述する。 HARPは、インターネットアドレス解決プロトコル（ARP）RFC-826 [13]及び逆ARP（がInARP）[7]（セクション5を参照）との組み合わせと適応です。 HARPはまた、ARPのHIPPI特定のバージョンを記述する[10]（すなわち、プロトコル及びHIPPI特定のエンコーディング）。
HARP table
HARPテーブル
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
各ホストはIPメンバーのハードウェアアドレスへのマッピングIPが含まれているHARPテーブルを持っています。
HIPPI-Serial
HIPPI-シリアル
An implementation of HIPPI in serial fashion on coaxial cable or optical fiber. (see [5])
同軸ケーブルまたは光ファイバに直列にHIPPIの実装。 （[5]を参照）
HRAL
HRAL
The HARP Request Address List. A list of ULAs to which HARP messages are sent when resolving names to addresses (see section 4.2).
HARP要求アドレス一覧。 （セクション4.2を参照）のアドレスに名前を解決するときにHARPメッセージが送信されるまでULAsのリスト。
Hardware (HW) address
ハードウェア（HW）アドレス
The hardware address of a port consisting of an I-Field and an optional ULA (see section 6.2). Note: the term port as used in this document refers to a HIPPI port and is roughly equivalent to the term "interface" as commonly used in other IP documents.
I-フィールド及び任意ULAからなるポートのハードウェアアドレス（セクション6.2を参照）。注：この文書で使用される用語ポートはHIPPIポートを指し、一般に他のIP文書で使用される用語「界面」とほぼ同等です。
Host
ホスト
An entity, usually a computer system, that may have one or more HIPPI ports and which may serve as a client or a HARP server.
エンティティ、一つ以上のHIPPIポートを有することができ、クライアントまたはHARPサーバとして機能することができるこれは通常のコンピュータシステム。
Port
港
An entity consisting of one HIPPI Source/Destination dual simplex pair that is connected by parallel or serial HIPPI to a HIPPI-SC switch and that transmits and receives IP datagrams.
HIPPI-SCスイッチに並列または直列HIPPIによって接続され、それが送信したIPデータグラムを受信したものHIPPIソース/宛先デュアルシンプレックス対からなるエンティティ。
PIBES
PIBES
The Protocol for Internet Broadcast Emulation Server (see section 7).
インターネット放送エミュレーションサーバのプロトコル（セクション7を参照）。
Switch Address
スイッチの住所
A value used as the address of a port on a HIPPI-SC network. It is transmitted in the I-field. HIPPI-SC switches map Switch Addresses to physical switch port numbers. The switch address is extended with a mode byte to form an I-Field (see [4] and 6.2.2)
HIPPI-SCネットワーク上のポートのアドレスとして使用される値。これは、I-フィールドで送信されます。 HIPPI-SCは、物理スイッチポート番号にマップスイッチのアドレスを切り替えます。スイッチ・アドレスはI-フィールドを形成するために、モード・バイトで拡張されている（[4]を参照6.2.2）
Source
ソース
The HIPPI port that generates data to send to a HIPPI Destination.
データを生成HIPPIポートはHIPPI送信先に送信します。
Universal LAN MAC Address (ULA)
ユニバーサルLAN MACアドレス（ULA）
A 48-bit globally unique address, administered by the IEEE, assigned to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN.
イーサネット（登録商標）、FDDI、802ネットワーク、またはHIPPI-SC LAN上の各ポートに割り当てられたIEEEによって投与する48ビットのグローバルに一意のアドレス、。
ARP (address resolution protocol) as defined in [12] was meant to work on the 'local' cable. This definition gives the ARP protocol a local logical IP subnet (LIS) scope. In the LIS scenario, each separate administrative entity configures its hosts and routers within the LIS. Each LIS operates and communicates independently of other LIS's on the same HIPPI network.
ARP（アドレス解決プロトコル）で定義されている[12]「ローカル」ケーブル上で動作することを意味しました。この定義は、ARPプロトコルにローカル論理IPサブネット（LIS）の範囲を提供します。 LISのシナリオでは、各個別の管理エンティティは、そのホストとLIS内のルータを構成します。各LISが動作し、独立して同じHIPPIネットワーク上の他のLIS年代の通信を行います。
HARP has LIS scope only and serves all ports in the LIS. Communication to ports located outside of the local LIS is usually provided via an IP router. This router is a HIPPI port attached to the HIPPI network that is configured as a member of one or more LIS's. This configuration MAY result in a number of disjoint LIS's operating over the same HIPPI network. Using this model, ports of different IP subnets SHOULD communicate via an intermediate IP router even though it may be possible to open a direct HIPPI connection between the two IP members over the HIPPI network. This is a consequence of using IP and choosing to have multiple LIS's on the same HIPPI fabric.
HARPは、LIS範囲を有し、LIS内のすべてのポートを提供しています。地元LISの外に位置するポートへの通信は、通常、IPルーターを介して提供されます。このルータは、一つ以上のLIS年代のメンバーとして設定されているHIPPIのネットワークに接続されているHIPPIポートです。この構成では、同じHIPPIネットワーク上で動作してばらばらのLIS年代の数になることがあります。このモデルを使用して、異なるIPサブネットのポートは、HIPPIネットワーク上で2つのIP部材との間の直接HIPPI接続を開くことが可能であっても、中間IPルータを介して通信すべきです。これは、IPを使用して、同じHIPPIファブリック上に複数のLIS年代を持つように選択の結果です。
By default, the HARP method detailed in section 5 and the classical LIS routing model MUST be available to any IP member client in the LIS.
デフォルトでは、HARPの方法は、セクション5で詳述し、古典LISルーティングモデルは、LIS内の任意のIPメンバークライアントに利用可能でなければなりません。
The requirement for IP members (hosts, routers) operating in a HIPPI LIS configuration is:
あるHIPPI LIS構成で動作するIP部材（ホスト、ルータ）の要件：
o All members of the LIS SHALL have the same IP network/subnet address and address mask [6].
O LISのすべてのメンバーが同じIPネットワーク/サブネットアドレスとアドレスマスクを持たなければならない[6]。
The following list identifies the set of HIPPI-specific parameters that MUST be implemented in each IP station connected to the HIPPI network:
以下のリストは、HIPPIネットワークに接続された各IPステーションに実装されなければならないHIPPI固有のパラメータのセットを識別する。
o HIPPI Hardware Address:
O HIPPIのハードウェアアドレス：
The HIPPI hardware address of an individual IP port MUST contain the port's Switch Address (see section 9). The address SHOULD also contain a non-zero ULA address. If there is no ULA then that field MUST be zero.
個々のIPポートのHIPPIハードウェアアドレスは、ポートのスイッチ・アドレスを含まなければならない（セクション9を参照）。アドレスは、非ゼロULAアドレスを含むべきです。何ULAが存在しない場合、そのフィールドはゼロでなければなりません。
o HARP Request Address List (HRAL):
HARP要求アドレス一覧（HRAL）○：
The HRAL is an ordered list of two or more addresses identifying the address resolution service(s). All HARP clients MUST be configured identically, i.e. all ports MUST have the same addresses(es) in the HRAL.
HRALは、アドレス解決サービス（単数または複数）を同定する二つ以上のアドレスの順序付きリストです。全てHARPクライアントは、すべてのポートがHRALに同じアドレス（複数可）を持つ必要があり、すなわち、同じ構成されなければなりません。
The HRAL MUST contain at least two HIPPI HW addresses identifying the individual HARP service(s) that have authoritative responsibility for resolving HARP requests of all IP members located within the LIS.
HRALは、LIS内に配置されたすべてのIPメンバーのHARP要求を解決するための正式な責任を持つ個々のHARPサービス（複数可）を識別する少なくとも2つのHIPPI HWアドレスを含まなければなりません。
By default the first address MUST be the reserved address for broadcast, i.e. the address for "IP traffic conventionally directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The ULA for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF.
[4]：デフォルトで最初のアドレスは、ブロードキャスト、「0xFE1従来IEEE 802.1ブロードキャストアドレスに向けられたIPトラフィック」の、すなわちアドレスの予約アドレスでなければなりません。このHARPサービスエントリのULAはされなければならないFF：FF：FF：FF：FF：FF。
It is REQUIRED that the second address be the address for "Messages pertaining to (the) ... address resolution requests: 0xFE0" [4]. The ULA for this HARP server entry is 00:00:00:00:00:00.
[4]：2番目のアドレスは「0xFE0（）...アドレス解決要求に関連するメッセージ」のアドレスであることが要求されます。 00：00：00：00：00このHARPサーバーエントリのULAは00です。
Therefore, the HRAL entries are sorted in the following order: 1st ** : broadcast address (0x07000FE1 FF:FF:FF:FF:FF:FF), 2nd ** : official HARP server address (0x07000FE0 00:00:00:00:00:00), 3rd & on: any additional HARP server addresses will be sorted in decreasing order of the 12bit destination switch address portion of their I-Field (see section 6.2). ** REQUIRED
したがって、HRALエントリは次の順序でソートされている：第一**：ブロードキャストアドレス（0x07000FE1 FF：FF：FF：FF：FF：FF）、第二**：公式HARPサーバーアドレス（0x07000FE0 00：00：00：00 00）、第3回＆：：：00追加のHARPサーバアドレスは（セクション6.2を参照）、それらのIフィールドの12ビット宛先スイッチアドレス部の降順にソートされます。 **必須
Within the restrictions mentioned above and in Section 6.2.2, local administration choose address(es) for the additional HARP services which they will put into the HRAL.
6.2.2項の上とに記載された制限内では、局所投与は、彼らがHRALに入れます追加HARPサービス用のアドレス（複数可）を選択します。
An example of such a list: 1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF 2nd entry: 0x07000FE0 00:00:00:00:00:00 3rd entry: 0x07000001 <Alternate-HARP-server-ula> ...
そのようなリストの例：第一エントリ：0x07000FE1 FF：FF：FF：FF：FF：FF 2番目のエントリ：0x07000FE0 00：00：00：00：00：00第三エントリ：0x07000001 <代替-HARP-サーバULA> ...
Manual configuration of the addresses and address lists presented in this section is implementation dependent and beyond the scope of this memo.
このセクションで提示アドレスおよびアドレスリストの手動設定が依存し、このメモの範囲を超えて実装したものです。
Address resolution within the HIPPI LIS SHALL make use of the HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI Address Resolution Protocol (InHARP). HARP provides the same functionality as the Internet Address Resolution Protocol (ARP). HARP is based on ARP which is defined in RFC-826 [13]. Knowing the Internet address, conventional networks use ARP to discover another port's hardware address. HARP presented in this section further specifies the combination of the original protocol definitions to form a coherent address resolution service that is independent of the hardware's broadcast capability.
HIPPI LIS内のアドレス解決は、HIPPIの使用が解決プロトコル（HARP）と逆HIPPIアドレス解決プロトコル（InHARP）に対処しなければなりません。 HARPは、インターネットのアドレス解決プロトコル（ARP）と同じ機能を提供します。 HARPは、RFC-826で定義されているARP [13]に基づいています。インターネットアドレスを知って、従来のネットワークは、別のポートのハードウェアアドレスを発見するためにARPを使用しています。このセクションで提示HARPはさらに、ハードウェアのブロードキャスト機能とは独立したコヒーレントアドレス解決サービスを形成するために、オリジナルのプロトコル定義の組み合わせを指定します。
InHARP is based on the original Inverse ARP (InARP) protocol presented in [7]. Knowing its hardware address, InARP is used to discover the other party's Internet address.
InHARPは、[7]に提示元インバースARP（がInARP）プロトコルに基づいています。そのハードウェアアドレスを知ること、がInARPは相手のインターネットアドレスを発見するために使用されています。
This memo further REQUIRES the PIBES (see section 7 below) extension to the HARP protocol, guaranteeing broadcast service to upper layer protocols like IP.
このメモは、さらに、IPのような上位層プロトコルに放送サービスを保証する、PIBES（以下のセクション7を参照）HARPプロトコルの拡張を必要とします。
Internet addresses are assigned independent of ULAs and switch addresses. Before using HARP, each port MUST know its IP and its hardware addresses. The ULA is optional but is RECOMMENDED if bridging to conventional networks is desired.
インターネットアドレスはULAsとスイッチアドレスとは無関係に割り当てられています。 HARPを使用する前に、各ポートは、そのIPとそのハードウェアアドレスを知っている必要があります。 ULAは任意であるが、従来のネットワークにブリッジが所望される場合に推奨されます。
This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI-SC networks. HARP creates a table in each port which maps the IP address of each port to a hardware address, so that when an application requests a connection to a remote port by its IP address, the hardware address can be determined, a correct HIPPI-LE header can be built, and a connection to the port can be established using the correct Switch Address in the I-field.
このセクションでは、放送と非放送可能なHIPPI-SCネットワークの両方にHARP実装の挙動と要件を定義します。 HARPは、アプリケーションがそのIPアドレスでリモートポートへの接続を要求するときに、ハードウェア・アドレスを決定することができるように、ハードウェア・アドレスに、各ポートのIPアドレスをマッピングし、各ポート、正しいHIPPI-LEヘッダーにテーブルを作成し構築することができ、およびポートへの接続は、I-フィールドに正しいスイッチ・アドレスを使用して確立することができます。
HARP is a two phase protocol. The first phase is the registration phase and the second phase is the operational phase. In the registration phase the port detects if it is connected to broadcast hardware or not. The InHARP protocol is used in the registration phase. In case of non-broadcast capable hardware, the InHARP Protocol will register and establish a table entry with the server. The operational phase works much like conventional ARP with the exception of the message format.
HARPは、二相のプロトコルです。最初のフェーズは、登録段階であり、第二段階は、運用段階です。ハードウェアを放送したりしないように接続されている場合、登録段階ではポートを検出します。 InHARPプロトコルは、登録フェーズで使用されます。非放送対応のハードウェアの場合は、InHARPプロトコルは、サーバーと、テーブルのエントリを登録し、確立します。運用フェーズは、多くのメッセージ・フォーマットを除いて、従来のARPのように動作します。
Within the HIPPI LIS, there SHALL be an authoritative HARP service. At each point in time there is only one authoritative HARP service.
HIPPI LISの中で、権威あるHARPサービスがなければなりません。各時点で唯一の権威あるHARPサービスがあります。
To select the authoritative HARP service, each port needs to determine if it is connected to a broadcast network.
権威あるHARPサービスを選択するには、各ポートは、それがブロードキャストネットワークに接続されているかどうかを決定する必要があります。
The port SHALL send an InHARP_REQUEST to the first address in its HRAL (0x07000FE1 FF:FF:FF:FF:FF:FF). If the port sees its own InHARP_REQUEST, then it is connected to a broadcast capable network. In this case, the rest of the HRAL is ignored and the authoritative HARP service is the broadcast entry.
ポートは、そのHRAL（0x07000FE1 FF：FF：FF：FF：FF：FF）で最初のアドレスにInHARP_REQUESTを送付しなければなりません。ポートは独自のInHARP_REQUESTを見れば、それは放送が可能なネットワークに接続されています。この場合、HRALの残りの部分は無視され、権威あるHARPサービスは、放送エントリです。
If the port is connected to a non-broadcast capable network, then the port SHALL send the InHARP_REQUEST to all of the remaining entries in the HRAL. Every address which sends an InHARP_REPLY is considered to be a responsive HARP server. The authoritative HARP service SHALL be the HARP server which appears first in the HRAL.
ポートは非放送対応ネットワークに接続されている場合、ポートはHRALの残りのエントリのすべてにInHARP_REQUESTを送付しなければなりません。 InHARP_REPLYを送信し、すべてのアドレスが応答HARPサーバであると考えられています。権威あるHARPサービスはHRALの最初に表示されるHARPサーバーされなければなりません。
The sequence of the HRAL is only important for deciding which address will be the authoritative one. On a non-broadcast network, the port is REQUIRED to keep "registered" with all HARP server addresses in the HRAL (NOTE: not the broadcast address since it is not a HARP server address). If for instance the authoritative HARP service is non-responsive, then the port will consider the next address in the HRAL as a candidate for the authoritative address and send an InHARP_REQUEST.
HRALのシーケンスは、権威いずれかになりますどのアドレスを決定するための重要なだけです。非ブロードキャストネットワークでは、ポートがHRAL（：ないブロードキャスト・アドレス、それはHARPサーバーのアドレスではないので注意）内のすべてのHARPサーバーのアドレスを「登録」に保つために必要とされます。例えば権威あるHARPサービスが応答しない場合、そのポートは、信頼できるアドレスの候補としてHRALで次のアドレスを考慮してInHARP_REQUESTを送信します。
The authoritative HARP server SHOULD be considered non-responsive when it has failed to reply to: (1) one or more registration requests by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs in the last 120 seconds or (3) if an external agent has detected failure of the authoritative HARP server. The details of such an external agent and its interaction with the HARP client are beyond the scope of this document. Should an authoritative HARP server become non-responsive, then the registration process SHOULD be restarted. Alternative methods for choosing an authoritative HARP service are not prohibited.
クライアントが（1）一つ以上の登録要求最後の120秒（2）任意の2 HARP_REQUESTs、（セクション5.1.2と5.2を参照してください）：それはに返信に失敗したとき権威HARPサーバーが応答しないとみなされるべきですまたは（3）外部エージェントは権威HARPサーバの障害を検出した場合。このような外部エージェントとHARPクライアントとの相互作用の詳細は、このドキュメントの範囲を超えています。権威HARPサーバが非応答になった場合は、その後、登録プロセスを再起動する必要があります。権威あるHARPサービスを選択するための別の方法は禁止されていません。
HARP clients SHALL initiate the registration phase by sending an InHARP_REQUEST message using the addresses in the HRAL in order. The client SHALL terminate the registration phase and transition into the operational phase, either when it receives its own InHARP_REQUEST or when it receives an InHARP_REPLY from at least one of the HARP servers and when it has determined the authoritative HARP service as described in section 5.1.1.
HARPクライアントが順にHRALのアドレスを使用してInHARP_REQUESTメッセージを送信することによって、登録段階を開始しなければなりません。それ自体InHARP_REQUESTとき、またはそれがHARPサーバの少なくとも一つからInHARP_REPLYを受信し、セクション5.1で説明したように、権威HARPサービスを決定したときに受信した場合、クライアントは、いずれかの、運用段階に登録フェーズ遷移を終了するもの。 1。
When ports are initiated they send an InHARP_REQUEST to the authoritative address as described in section 5.1.2. The first address to be tried will be the broadcast address "0x07000FE1 FF:FF:FF:FF:FF:FF". There are two outcomes:
ポートが開始された場合のセクション5.1.2で説明したように、彼らは権威のアドレスにInHARP_REQUESTを送信します。試される最初のアドレスはブロードキャストアドレス "：FF：FF：FF：FF：FF 0x07000FE1 FF" になります。 2つの結果があります。
1. The port sees its own InHARP_REQUEST: then the port is connected to a broadcast capable network. The first address becomes and remains the authoritative address for the HARP service.
その後、ポートが放送できるネットワークに接続されている：1ポートは独自のInHARP_REQUESTを見ています。最初のアドレスはなってHARPサービスの正式なアドレスのまま。
2. The port does not receive its InHARP_REQUEST: then the port is connected to a non-broadcast capable network.
2.ポートはInHARP_REQUESTを受信しない。次いで、ポートは非放送可能なネットワークに接続されています。
In the second case, the port SHALL choose the next address in the HRAL as a candidate for a authoritative address and send an InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).
第二の場合では、ポートは、信頼できるアドレスの候補としてHRALの次のアドレスを選択するものとし、そのアドレスにInHARP_REQUESTを送信する：（0x07000FE0 00：00：00：00：00：00）。
o If the port receives its own message, then the port itself is the HARP server and the port is REQUIRED to provide broadcast services using the PIBES (see section 7).
ポートは、独自のメッセージを受信した場合、O、ポート自体は、HARPサーバであり、ポートがPIBESを用いて放送サービスを提供するために必要とされている（セクション7参照）。
o If the port receives an InHARP_REPLY, then it is a HARP client and not a HARP server.
ポートがInHARP_REPLYを受信した場合、O、それはHARPクライアントではなくHARPサーバーです。
In both cases, the current candidate address becomes the authoritative HARP service address.
どちらの場合も、現在の候補アドレスは、権威あるHARPサービスのアドレスになります。
If the client determines it is connected to a non-broadcast capable network then the client SHALL continue to retry each non-broadcast HARP server address in the HRAL at least once every 5 seconds until one of these two termination criteria are met for each address.
クライアントが非ブロードキャストが可能なネットワークに接続されていると判断した場合、クライアントは、これらの2つの終端基準の1つは、各アドレスのために満たされるまでに少なくとも一度HRALに5秒ごとに各非放送HARPサーバーアドレスを再試行し続けるものとします。
InHARP is an application of the InARP protocol for a purpose not originally intended. The purpose is to accomplish registration of port IP address mappings with a HARP server if one exists or detect hardware broadcast capability.
InHARPは、本来意図していない目的のためのがInARPプロトコルのアプリケーションです。目的は1つが存在する場合HARPサーバとポートIPアドレスのマッピングの登録を行うか、ハードウェアのブロードキャスト機能を検出することです。
If the HIPPI-SC LAN supports broadcast, then the client will see its own InHARP_REQUEST message and SHALL complete the registration phase. The client SHOULD further note that it is connected to a broadcast capable network and use this information for aging the HARP server entry and for IP broadcast emulation as specified in sections 5.4 and 5.6 respectively.
HIPPI-SC LANがブロードキャストをサポートしている場合、クライアントは自身のInHARP_REQUESTメッセージが表示され、登録フェーズを完了しなければなりません。クライアントは、さらにそれが放送できるネットワークに接続されていることに注意して、それぞれのセクション5.4および5.6に指定されているHARPサーバのエントリを熟成し、IP放送エミュレーションのためにこの情報を使用すべきです。
If the client doesn't see its own InHARP_REQUEST, then it SHALL await an InHARP_REPLY before completing the registration phase. This will also provide the client with the protocol address by which the HARP server is addressable. This will be the case when the client happens to be connected to a non-broadcast capable HIPPI-SC network.
クライアントが独自InHARP_REQUESTを見ていない場合、それは登録フェーズを完了する前にInHARP_REPLYを待つものとします。これはまた、HARPサーバがアドレス指定可能であることにより、プロトコルアドレスをクライアントに提供します。クライアントが非ブロードキャストできるHIPPI-SCネットワークに接続されるように発生したときにこれがケースになります。
Once a HARP client has completed its registration phase it enters the operational phase. In this phase of the protocol, the HARP client SHALL gain and refresh its own HARP table which contains the IP to HW address mapping of IP members by sending HARP_REQUESTS to the authoritative address in the HRAL and receiving HARP_REPLYs. The client is fully operational during the operational phase.
HARPクライアントはその登録フェーズを完了すると、それは運用段階に入ります。プロトコルのこの段階では、HARPクライアントはHRALに権威のアドレスにHARP_REQUESTSを送信し、HARP_REPLYsを受信することにより、IPメンバーのHWアドレスマッピングへのIPが含まれている独自のHARPテーブルを獲得し、リフレッシュしないものとします。クライアントは、運用フェーズで完全に動作します。
In the operational phase, the client's behavior for requesting HARP resolution is the same for broadcast or non-broadcast networks.
運用段階では、HARPの解決を要求するためのクライアントの動作は、ブロードキャストまたは非ブロードキャストネットワークでも同じです。
The target of an address resolution request updates its address mapping tables with any new information it can find in the request. If it is the target port it SHALL formulate and send a reply message. A port is the target of an address resolution request if at least ONE of the following statements is true of the request:
アドレス解決要求の対象は、リクエストに見つけることができる任意の新しい情報でそのアドレスマッピングテーブルを更新します。それはターゲットポートである場合には、策定し、応答メッセージを送信しなければなりません。次の文のうち少なくとも一つは、要求の真である場合、ポートはアドレス解決要求の対象であります：
1. The port's IP address is in the target protocol address field (ar$tpa) of the HARP message.
1.ポートのIPアドレスは、HARPメッセージのターゲットプロトコルアドレスフィールド（ARます$ TPA）です。
2. The port's ULA (if non-zero), is in the ULA part of the Target Hardware Address field (ar$tha) of the message.
2.ポートのULA（ゼロ以外の場合）、メッセージのターゲットハードウェアアドレスフィールド（ARます$ THA）のULAの一部です。
3. The port's switch address is in the Target Switch Address field of Target Hardware Address field (ar$tha) of the message (see section 6.2.2).
3.ポートのスイッチアドレスは、メッセージのターゲットハードウェアアドレスフィールド（ARます$ THA）のターゲットスイッチのアドレスフィールドにある（セクション6.2.2を参照してください）。
NOTE: It is RECOMMENDED that all HARP servers run on a ports which each have a non-zero ULA.
注：これは、すべてのHARPサーバは、それぞれが非ゼロのULAを持っているポート上で実行することをお勧めします。
The HARP client is responsible for contacting the HARP server(s) to have its own HARP information registered and to gain and refresh its own HARP entry/information about other IP members. This means, as noted above, that HARP clients MUST be configured with the hardware address of the HARP server(s) in the HRAL.
HARPクライアントは、自身のHARP情報が登録され持っていると、他のIPメンバーに関する独自のHARPエントリー/情報を獲得し、リフレッシュしHARPサーバ（複数可）に連絡する責任があります。上述したように、この手段は、そのHARPクライアントはHRALでHARPサーバ（複数可）のハードウェア・アドレスを設定する必要があります。
HARP clients MUST:
HARPクライアントする必要があります。
1. When an interface is enabled (e.g. "ifconfig <interface> up" with an IP address) or assigned the first or an additional IP address (i.e. an IP alias), the client SHALL initiate the registration phase.
1.インターフェースが有効になっている（例えば、「ifconfigコマンド<インターフェース>アップ」IPアドレスを持つ）、または割り当てられた最初の又は追加のIPアドレス（すなわち、IPエイリアス）、クライアントは、登録段階を開始しなければなりません。
2. In the operational phase the client MUST respond to HARP_REQUEST and InHARP_REQUEST messages if it is the target port. If an interface has multiple IP addresses (e.g., IP aliases) then the client MUST cycle through all the IP addresses and generate an InHARP_REPLY for each such address. In that case an InHARP_REQUEST will have multiple replies. (Refer to Section 7, "Protocol Operation" in RFC-1293 [7].)
それはターゲットポートである場合2.運用フェーズでは、クライアントはHARP_REQUESTとInHARP_REQUESTメッセージに応答しなければなりません。インターフェイスは、複数のIPアドレス（例えば、IPエイリアス）を有している場合、クライアントMUSTサイクルすべてのIPアドレスを介して、そのような各アドレスにInHARP_REPLYを生成します。その場合にはInHARP_REQUESTは、複数の応答を持っています。 （セクション7を参照して、RFC-1293で "プロトコル操作" [7]）。
3. React to address resolution reply messages appropriately to build or refresh its own client HARP table entries. All solicited and unsolicited HARP_REPLYs from the authoritative HARP server SHALL be used to update and refresh its own client HARP table entries.
3.は、独自のクライアントHARPテーブルのエントリを作成したり、リフレッシュするために、適切に解決応答メッセージに対処するために反応します。権威HARPサーバからのすべての募集と迷惑HARP_REPLYsは、独自のクライアントHARPテーブルエントリを更新し、リフレッシュするために使用しなければなりません。
Explanation: This allows the HARP server to update the clients when one of server's mappings change, similar to what is accomplished on Ethernet with gratuitous ARP.
説明：これは、とき無償ARPをイーサネット上で達成されたものと同様のサーバーのマッピングの変更の1、HARPサーバはクライアントを更新することができます。
4. Generate and transmit InHARP_REQUEST messages as needed and process InHARP_REPLY messages appropriately (see section 5.1.2 and 5.6). All InHARP_REPLY messages SHALL be used by the client to build or refresh its HARP table entries. (Refer to Section 7, "Protocol Operation" in [7].)
4.（セクション5.1.2および5.6を参照）を適宜生成し、必要に応じてメッセージをInHARP_REQUEST送信し、プロセスInHARP_REPLYメッセージ。すべてInHARP_REPLYのメッセージは、そのHARPテーブルエントリを作成したり、リフレッシュするために、クライアントによって使用されなければなりません。 （[7]に "プロトコル動作"、第7章を参照）。
If the registration phase showed that the hardware does not support broadcast, then the client MUST refresh its own entry for the HARP server, created during the registration phase, at least once every 15 minutes. This can be accomplished either through the exchange of a HARP request/reply with the HARP server or by repeating step 1. To decrease the redundant network traffic, this timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange.
登録フェーズは、ハードウェアがブロードキャストをサポートしていないことが示された場合、クライアントは、少なくとも一回15分ごとに、登録段階中に作成された、HARPサーバのための独自のエントリを更新する必要があります。 HARP要求の交換を介し/ HARPサーバに返信または冗長ネットワークトラフィックを減少させるために、ステップ1を繰り返して、このタイムアウトは、各HARP_REQUEST / HARP_REPLY交換後にリセットされるべきであるいずれかこれを達成することができます。
Explanation: The HARP_REQUEST shows the HARP server that the client is still alive. Receiving a HARP_REPLY indicates to the client that the server must have seen the HARP_REQUEST.
説明：HARP_REQUESTは、クライアントがまだ生きているHARPサーバーを示しています。 HARP_REPLYを受信すると、サーバはHARP_REQUESTを見ている必要がありますクライアントに示します。
If the registration phase shows that the underlying network supports broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of step 4 are NOT REQUIRED.
登録フェーズは、基礎となるネットワークがブロードキャストをサポートしていることを示した場合は、ステップ4の定期的なInHARP_REQUEST / InHARP_REPLY操作は必要ありません。
If a HARP client receives a HARP message with an operation code (ar$op) that it does not support, it MUST gracefully discard the message and continue normal operation. A HARP client is NOT REQUIRED to return any message to the sender of the undefined message.
HARPのクライアントがサポートされていないことをオペレーションコード（ARます$ OP）とHARPメッセージを受信した場合、それは優雅にメッセージを破棄し、通常の動作を継続する必要があります。 HARPクライアントは、未定義のメッセージの送信者に任意のメッセージを返すために必要ではありません。
A HARP server MUST accept HIPPI connections from other HIPPI ports. The HARP server expects an InHARP_REQUEST as the first message from the client. A server examines the IP source address, the hardware source address of the InHARP_REQUEST and adds or updates its HARP table entry <IP address(es), switch address, ULA> as well as the time stamp.
HARPサーバは、他のHIPPIポートからHIPPI接続を受け入れなければなりません。 HARPサーバは、クライアントからの最初のメッセージとしてInHARP_REQUESTを期待しています。サーバは、IPソースアドレス、InHARP_REQUESTのハードウェア送信元アドレスを調べ、そのHARPテーブルエントリ<IPアドレス（ES）、スイッチ・アドレス、ULA>ならびにタイムスタンプを追加または更新します。
A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs based on the information which it has in its HARP table. The HARP server SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has the requested information in its tables; otherwise it SHALL reply with a HARP_NAK. The HARP server replies SHALL contain the hardware type and corresponding format of the request (see also section 6).
HARPサーバは、そのHARPテーブルに持っていた情報に基づいてHARP_REQUESTsとInHARP_REQUESTsに返信ものとします。それはそのテーブルに要求された情報を持っている場合HARPサーバは、HARP_REPLYまたはInHARP_REPLYで応答しなければなりません。それ以外の場合は、HARP_NAKで返答ものとします。 HARPサーバ応答がハードウェアタイプ及び要求の対応フォーマットを含まなければならない（また、セクション6を参照）。
The following table shows all possible source address combinations on an incoming message and the actions to be taken. "linked" indicates that an existing "IP entry" is linked to a "hardware entry". It is possible to have an existing "IP entry" and to have an existing "hardware entry" but neither is linked to the other.
次の表は、着信メッセージのすべての可能なソースアドレスの組み合わせと取るべきアクションを示します。 「リンク」既存の「IPエントリが」「ハードウェアのエントリ」にリンクされていることを示しています。既存の「IPエントリ」を持っていると、既存の「ハードウェアのエントリを」持つことが可能ではありませんが、どちらも他にリンクされています。
+---+----------+----------+------------+---------------------+
| # | IP entry | HW entry | misc | Action |
+---+----------+----------+------------+---------------------+
| 1 | exists | exists | linked | * |
| 2 | exists | exists | not linked | *, a, b, e, f |
| 3 | exists | new | not linked | *, a, b, d, e, f |
| 4 | new | exists | not linked | *, c, e, f |
| 5 | new | new | not linked | *, c, d, e, f |
+---+----------+----------+------------+---------------------+
Actions:
*: update timeout value
a: break the existing IP -> hardware (HW) - old link
b: delete HW(old) -> IP link and decrement HW(old) refcount, if
refcount = 0, delete HW(old)
c: create new IP entry
d: create new HW entry
e: add new IP -> HW link to IP entry
f: add new HW -> IP link to HW entry
Examples of when this could happen (Numbers match lines in above table):
これは（上記の表の番号が一致線）起こり得る場合の例：
1: supplemental message
1：補足メッセージ
Just update timer.
ただ、タイマーを更新します。
2: move an IP alias to an existing interface
2：既存のインターフェイスにIPエイリアスを移動
If the IP source address of the InHARP_REQUEST duplicates a table entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST hardware source address matches a hardware address entry (e.g. HWb <-> IPb), but they are not linked together, then: - HWa entry needs to have its reference to the current IPa address removed. - HWb needs to have a new reference to IPa added - IPa needs to be linked to HWb
InHARP_REQUESTのIP送信元アドレスは、テーブルエントリのIPアドレス重複する場合（< - >例えばIPaのHWA）とInHARP_REQUESTハードウェアの送信元アドレスをハードウェアアドレスエントリと一致する（< - >例えばHWB IPbとし）、しかし、彼らはその後、一緒にリンクされていません： - HWAのエントリは削除現在のIPAアドレスへの参照を持っている必要があります。 - HWBは、IPAが追加に新しい参照を持っている必要があります - IPAがHWBにリンクする必要があります
3: move IP address to a new interface
3：新しいインターフェイスにIPアドレスを移動
If the InHARP_REQUEST requester's IP source address duplicates a table entry IP address and the InHARP_REQUEST hardware source address does not match the table entry hardware address, then a new HW entry SHALL be created. The requestor's IP address SHALL be moved from the original HW entry to the new one (see above).
InHARP_REQUESTの要求者のIP送信元アドレスは、テーブルエントリのIPアドレスとテーブルエントリのハードウェアアドレスと一致しないInHARP_REQUESTハードウェアの送信元アドレスと重複する場合、新しいHWエントリが作成されるものとします。要求元のIPアドレスは、新しいもの（上記参照）に、元HWエントリから移動するものとします。
4: add IP alias to table
4：テーブルにIP別名を追加
If the InHARP_REQUEST requester's hardware source address duplicates a hardware source address entry, but there is no IP entry matching the received IP address, then the IP address SHALL be added to the hardware entries previous IP address(es). (E.g. adding an IP alias).
InHARP_REQUESTリクエスタのハードウェア送信元アドレスがハードウェアソースアドレスエントリと重複するが、受信したIPアドレスと一致するIPエントリが存在しない場合、IPアドレスは、ハードウェアエントリ以前のIPアドレス（複数可）に添加することがSHALL。 （例えば、IPエイリアスを追加します）。
5: fresh entry, add it
5：新鮮なエントリー、それを追加
Standard case, create both entries and link them.
標準の場合、両方のエントリを作成し、それらをリンクします。
A server MUST update the HARP table entry's timeout for each HARP_REQUEST. Explanation: if the client is sending HARP requests to the server, then the server SHOULD note that the client is still "alive" by updating the timeout on the client's HARP table entry.
サーバは、各HARP_REQUESTについてHARPテーブルエントリのタイムアウトを更新する必要があります。説明：クライアントがサーバにHARPリクエストを送信している場合、サーバは、クライアントはまだ、クライアントのHARPテーブルエントリのタイムアウトを更新することで「生きて」であることに注意してください。
A HARP server SHOULD use the PIBES (see section 7) to send out HARP_REPLYs to all hardware addresses in its table when the HARP server table changes mappings. This feature decreases the time of stale entries in the clients.
HARPサーバは、HARPサーバテーブルにはマッピングを変更したときに、そのテーブル内のすべてのハードウェアアドレスにHARP_REPLYsを送信する（セクション7を参照）PIBESを使用すべきです。この機能は、クライアントでの古いエントリの時間を短縮します。
If there are multiple addresses in the HRAL, then a server needs to act as a client to the other servers.
複数のアドレスがHRALである場合、サーバは他のサーバへのクライアントとして機能する必要があります。
An IP station MUST have a mechanism (e.g. manual configuration) for determining what permanent entries it has. The details of the mechanism are beyond the scope of this memo. The permanent entries allow interoperability with legacy HIPPI adapters which do not yet implement dynamic HARP and use a table-based static ARP. Permanent entries are not aged.
IP局は、それが有する永久どのエントリを決定するための機構（例えば、手動設定）が必要。機構の詳細は、このメモの範囲を超えています。恒久的なエントリはまだダイナミックHARPを実装して、テーブルベースの静的ARPを使用していない従来のHIPPIアダプタとの相互運用性を可能にします。永久的なエントリは高齢者ではありません。
The HARP server SHOULD use the static entries to resolve incoming HARP_REQUESTs from the clients. This feature eliminates the need for maintaining a static HARP table on the client ports.
HARPサーバは、クライアントからの着信HARP_REQUESTsを解決するために静的エントリを使用すべきです。この機能は、クライアントポートに静的HARPテーブルを維持する必要がなくなります。
HARP table aging MUST be supported since IP addresses, especially IP aliases and also interfaces (with their ULA), are likely to move. When so doing the mapping in the clients own HARP table/cache becomes invalid and stale.
HARPテーブル老化は、IPアドレス、特にIPエイリアスとも（そのULAで）インターフェイスからサポートされなければならない、移動する可能性があります。そのクライアントでのマッピングを行う場合には独自のHARPテーブル/キャッシュは無効と古くなり。
o When a client's HARP table entry ages beyond 15 minutes, a HARP client MUST invalidate the table entry.
場合は、クライアントのHARPテーブルエントリ年齢15分を超えO、HARPクライアントは、テーブルのエントリを無効にしなければなりません。
o When a server's HARP table entry ages beyond 20 minutes, the HARP server MUST delete the table entry.
O場合は、サーバーのHARPテーブルエントリ年齢20分を超え、HARPサーバは、テーブルエントリを削除しなければなりません。
NOTE: the client SHOULD revalidate a HARP table entry before it ages, thus restarting the aging time when the table entry is successfully revalidated. The client MAY continue sending traffic to the port referred to by this entry while revalidation is in progress, as long as the table entry has not aged. The client MUST revalidate an aged entry prior to transmitting any non-address-resolution traffic to the port referred to by this entry.
注：クライアントは、このようにテーブルエントリが正常に再検証されたエージングタイムの再起動、それの年齢の前にHARPテーブルエントリを再検証すべきです。クライアントは、ポートへのトラフィックの送信を継続するかもしれ再検証は限りテーブルエントリが高齢者ではない持っているとして、進行中にこのエントリによって参照されます。クライアントは以前このエントリによって参照されるポートに任意の非アドレス解決トラフィックを送信歳のエントリを再検証しなければなりません。
The client revalidates the entry by querying the HARP server with a HARP_REQUEST. If a valid reply is received (e.g. HARP_REPLY), the entry is updated. If the address resolution service cannot resolve the entry (e.g. HARP_NAK, "host not found"), the associated table entry is removed. If the address resolution service is not available (i.e. "server failure") the client MUST attempt to revalidate the entry by transmitting an InHARP_REQUEST to the hardware address of the entry in question and updating the entry on receipt of an InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the associated table entry is removed.
クライアントはHARP_REQUESTとHARPサーバーを照会して、エントリを再検証します。有効な応答（例えばHARP_REPLY）受信した場合、エントリが更新されます。アドレス解決サービス（例えばHARP_NAK、「ホストが見つかりません」）エントリを解決できない場合、関連するテーブルエントリが削除されます。アドレス解決サービスが利用できない場合（つまり、「サーバ障害」）クライアントは、問題のエントリのハードウェアアドレスにInHARP_REQUESTを送信し、InHARP_REPLYの領収書上のエントリを更新することにより、エントリを再検証しようとしなければなりません。 InHARP_REQUESTの試みがInHARP_REPLYを返すことに失敗した場合は、関連するテーブルエントリが削除されます。
The HARP Message is encapsulated over HIPPI-FP and HIPPI-LE headers. The HARP FP header values are to be set as defined in RFC-2067 "IP over HIPPI" [15]. The following sections detail the HIPPI-LE field contents and HARP message structure and contents. In a broadcast capable network the client MAY also support Type 1 and 6, Ethernet and IEEE 802 ARP packet formats.
HARPメッセージHIPPI-FPとHIPPI-LEヘッダー上にカプセル化されます。 HARP FPヘッダの値は、RFC-2067「HIPPIオーバーIP」[15]で定義されるように設定されます。以下のセクションで詳細HIPPI-LEフィールドの内容とHARPメッセージの構造と内容。放送が可能なネットワークでは、クライアントはまた、タイプ1と6、イーサネットおよびIEEE 802 ARPパケットフォーマットをサポートすることができます。
The HIPPI message format for Internet datagrams shall conform to the HIPPI-FP [2] and HIPPI-LE [3] standards. The length of a HIPPI message, including trailing fill, shall be a multiple of eight bytes as required by HIPPI-LE. The HIPPI-LE header fields of HARP and InHARP requests and replies SHALL be:
インターネットデータグラムのためのHIPPIメッセージフォーマットは、HIPPI-FP [2]、HIPPI-LE [3]の規格に適合しなければなりません。 HIPPI-LEによって要求されるように、トレーリングフィル含むHIPPIメッセージの長さは、8バイトの倍数でなければなりません。 HARPとInHARP要求と応答のHIPPI-LEヘッダフィールドがなければなりません。
FC (3 bits) SHALL contain zero.
FC（3ビット）はゼロを含まなければなりません。
Double-wide SHOULD be set according to HIPPI-LE [3]. This memo does NOT address the implications on HARP when this bit is set to 1 indicating the possibility of a port being able to accept 64-bit HIPPI connections.
ダブルワイドHIPPI-LE [3]に応じて設定されるべきです。このメモは、このビットはポート64ビットHIPPI接続を受け入れることができるという可能性を示す1に設定されているHARPに影響に対処していません。
Message_Type SHALL contain 0 to indicate a data message. HARP messages are identified using the Ethertype and the message type in the ar$op field of the HARP message.
Messageは、データメッセージを示すために0を含まなければなりません。 HARPのメッセージは、イーサタイプとHARPメッセージのARの$のOPフィールドにメッセージタイプを使用して識別されます。
Destination_Switch_Address, SHALL be the Switch Address of the destination port.
Destination_Switch_Addressは、宛先ポートのスイッチ・アドレスされなければなりません。
Destination_IEEE_Address SHALL be the ULA of the destination port, if known, otherwise zero.
そうでない場合はゼロ、既知の場合Destination_IEEE_Addressは、宛先ポートのULAでなければなりません。
Destination_Address_Type SHALL be 2, a 12-bit logical address. The behavior with type = 1, source routing, is NOT defined in this specification.
Destination_Address_Type 2、12ビットの論理アドレスでなければなりません。タイプ= 1、ソースルーティングと動作は、本明細書中で定義されていません。
Source_Switch_Address in requests SHALL be the sender's Switch Address.
リクエストでSource_Switch_Addressは、送信者のスイッチ・アドレスされなければなりません。
Source_IEEE_Address SHALL be the sender's ULA if known, otherwise zero.
それ以外の場合はゼロ、既知の場合Source_IEEE_Addressは、送信者のULAでなければなりません。
Source_Address_Type SHALL be 2, a 12-bit logical address. The behavior with type = 1, source routing, is NOT defined in this specification.
Source_Address_Type 2、12ビットの論理アドレスでなければなりません。タイプ= 1、ソースルーティングと動作は、本明細書中で定義されていません。
The IEEE 802.2 LLC Header SHALL begin in the first byte of the HIPPI-FP D2_Area.
IEEE 802.2 LLCヘッダーは、HIPPI-FP D2_Areaの最初のバイトで始まるものとします。
The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes) indicating the presence of a SNAP header.
SSAP-DSAP-CTLのためのLLC値が0xAAを-AA-03（3バイト）SNAPヘッダの存在を示すものでなければなりません。
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) indicating that the following two-bytes is an Ethertype.
組織コードのためのOUI値は、次の2バイトがイーサタイプであることを示す0x00-00-00（3バイト）でなければなりません。
The Ethertype value SHALL be set as defined in Assigned Numbers [16]: InHARP = InARP = HARP = ARP = 2054 = 0x0806.
InHARP =がInARP = HARP = ARP = 2054 = 0x0806：割り当て番号[16]で定義されるようにイーサタイプ値を設定しなければなりません。
The total size of the LLC/SNAP header is fixed at 8-bytes.
LLC / SNAPヘッダの合計サイズは8バイトで固定されています。
HIPPI-LE header for HARP/InHARP PDUs:
HARP / InHARP PDUに対してHIPPI-LEヘッダー：
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 = IP ULP |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | n + 8 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|M_Type | 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | D_A_T | S_A_T | 000 | Source Switch Addr |
+-------+-------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 |Message byte 0 |Message byte 1 |Message byte 2 | . . . |
+---------------+---------------+---------------+--- |
| . . . |
+ ------------+---------------+---------------+---------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HIPPI Message Format
Words 0-1: HIPPI-FP Header Words 2-7: D1_Area (HIPPI-LE Header) Words 8-9: D2_Area (IEEE 802.2 LLC/SNAP) Words 10-(N-1): D2_Area (HARP message) (n+8) is the nb of bytes in the HARP message, incl. LLC/SNAP. +====+ denotes the boundary between D1_Area and D2_Area. [LA] fields are zero unless used otherwise locally. Abbreviations: "W" = Double_Wide field SHALL be 0 "M_Type" = Message_Type field SHALL be set according to HIPPI-LE "D_A_T" = Destination_Address_Type SHALL be 2
単語0-1：HIPPI-FPヘッダワード2-7：D1_Area（HIPPI-LEヘッダ）単語8-9：D2_Area（IEEE 802.2 LLC / SNAP）ワード10-（N-1）：D2_Area（HARPメッセージ）（N +8）込み、HARPメッセージのバイトNBです。 LLC / SNAP。 + ==== + D1_AreaとD2_Areaとの間の境界を示しています。そうでなければローカルで使用しない限り、[LA]フィールドはゼロです。略語：0 "M_Type" =のMessageフィールドは= Destination_Address_Type 2でなければならないHIPPI-LE "D_A_T" に応じて設定される "W" = Double_Wideフィールドでなければなりません
"S_A_T" = Source_Address_Type SHALL be 2 [FILL] bytes complete the HIPPI message to an even number of 32 bit words. The number of fill bytes is not counted in the data length.
「S_A_T」= Source_Address_Type 2 [FILL]バイトは、32ビット・ワードの偶数にHIPPIメッセージを完了しなければなりません。フィル・バイトの数は、データ長がカウントされません。
For HIPPI-800, the Hardware Address is a 10-byte unit that SHALL contain the Switch Address AND the ULA. The format of a hardware address is:
HIPPI-800の場合は、ハードウェアアドレスは、スイッチのアドレスとULAを含まなければならない10バイト単位です。ハードウェアアドレスの形式は次のとおりです。
31 23 15 7 0
+---------------+---------------+-------+-------+---------------+
| Mode Byte | 00 | 0 | X | XX |
+---------------+---------------+-------+-------+---------------+
| ULA byte 0 | ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 |
+---------------+---------------+
Where "XXX" is the 12 bit HIPPI logical address defined in HIPPI-SC [4]. Details on ULA see next section.
ここで、 "XXX" はHIPPI-SCで定義された12ビットのHIPPI論理アドレスである[4]。 ULAの詳細については、次のセクションを参照してください。
Two switch addresses are considered to be the same when they have the same 12 bit destination HIPPI logical address.
2つのスイッチのアドレスは、それらが同じ12ビットのデスティネーションHIPPI論理アドレスを持っているときに、同じであると考えられています。
NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6- byte ULA. Therefore the length of the hardware address clearly defines which version of HIPPI is being used.
注：HIPPI-6400の場合、ハードウェア・アドレスは、6バイトULAあります。したがって、ハードウェアアドレスの長さは明らかに使用されているHIPPIのバージョンを定義します。
IEEE Standard 802.1A [11] specifies the Universal LAN MAC Address format. The globally unique part of the 48-bit space is administered by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA. Multiple ULAs may be used if a port contains more than one IEEE 802.2 LLC protocol entity.
IEEE標準802.1A [11]ユニバーサルLAN MACアドレス形式を指定します。 48ビット空間のグローバルにユニークな部分は、IEEEによって管理されます。 HIPPI-SC LAN上の各ポートには、ULAを割り当てる必要があります。ポートが複数のIEEE 802.2 LLCプロトコルエンティティが含まれている場合、複数のULAsを使用することができます。
The format of the HIPPI hardware address within its HARP message follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order. For example the requester's ULA part of the HIPPI hardware address would decompose to:
そのHARPメッセージ内HIPPIハードウェアアドレスのフォーマットは、IEEE 802.1A正規のビット順とHIPPI-FPビット及びバイト順序に従います。例えばHIPPIハードウェアアドレスの要求者のULA部分はに分解します：
31 23 15 7 0
+---------------+---------------+---------------+---------------+
|ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 |
+---------------+---------------+
Universal LAN MAC Address Format
ユニバーサルLAN MACアドレス形式
L (U/L bit) = 1 for Locally administered addresses, 0 for Universal. G (I/G bit) = 1 for Group addresses, 0 for Individual.
L（U / Lビット）は、局所的に投与するためのアドレス1 =ユニバーサル0。 G個人のグループアドレスのための（I / Gビット）= 1、0。
The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is REQUIRED if a port wishes to interoperate with a conventional network.
ULAsの使用は任意ですが、お勧めします。ポートは、従来のネットワークと相互運用することを望む場合ULAsの使用が必要です。
ULAs may also be used by bridging devices that replace HIPPI hardware headers with the MAC headers of other LANs.
ULAsはまた、他のLANのMACヘッダとHIPPIハードウェアヘッダを置き換えるデバイスを架橋して用いてもよいです。
The HARP protocols use the HIPARP hardware type (ar$hrd) [16], protocol type (ar$pro), and operation code (ar$op) data formats as the ARP, and InARP protocols [15,7]. In addition, HARP makes use of an additional operation code for ARP_NAK introduced with [12]. The remainder of the HARP/InHARP message format is different than the ARP/InARP message format defined in [15,7,10] and it is also different from the format defined in the first "IP and ARP on HIPPI" RFC-1374 [14].
HARPプロトコルはHIPARPハードウェアタイプ（ARする$ HRD）[16]、プロトコルタイプ（アルゴン$プロ）、及びオペレーションコード（ARする$ OP）ARP、及びがInARPプロトコル[15,7]のようなデータ・フォーマットを使用します。また、HARPはARP_NAKための追加のオペレーションコードの使用は[12]で導入させます。 HARP / InHARPメッセージフォーマットの残りは[15,7,10]で定義されたARP /がInARPメッセージフォーマットとは異なる、それはまた、RFC-1374「HIPPI上でIPとARP」最初に定義されたフォーマットと異なっています[ 14]。
HARP messages SHALL be transmitted with the HIPARP hardware type code of 28 (decimal). Furthermore, HARP messages SHALL be accepted if received with hardware type codes of either 28, 1 or 6 (decimal).
HARPメッセージ28のHIPARPハードウェアタイプコード（10進数）で送信されなければなりません。いずれか28、1又は6（10進数）のハードウェアタイプコードと受信した場合、さらに、HARPメッセージは受け入れられるものとします。
The HARP message has several fields that have the following format and values:
HARPメッセージは次の書式と値を持っているいくつかのフィールドがあります。
Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address
データサイズ及びフィールドの意味：AR $オペアンプ16ビットオペレーションコード下プロトコルフィールドの$ HRD 16ビット・ハードウェア・タイプのAr $プロ16ビットのプロトコルタイプAR（要求、応答、またはNAK）各プロトコルのAR $ PLN 8ビットバイト長アドレスARの$ RHL 8ビット・リクエスタのHIPPIハードウェアアドレス長（Q）AR $ THL 8ビットターゲットのHIPPIハードウェアアドレス長（X）のArの$ RPA 32ビット・リクエスタのプロトコルアドレスARする$ TPA 32ビットターゲットのプロトコルアドレスのAr $のRHAは、要求者のHIPPIハードウェアをQBYTESアドレスのar $股関節xbytesターゲットのHIPPIハードウェアアドレス
Where : ar$hrd - SHALL contain 28. (HIPARP)
どこ：$難しいです - SHELLは28（HIPARP）を含有します
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ARの$プロ - IPプロトコルコード2048（10進数）を含まなければなりません。
ar$op - SHALL contain the operational value (decimal): 1 for HARP_REQUESTs 2 for HARP_REPLYs 8 for InHARP_REQUESTs 9 for InHARP_REPLYs 10 for HARP_NAK
AR $オペアンプ - 演算値（10進数）を含まなければならない：1 HARP_NAKためInHARP_REPLYs 10用InHARP_REQUESTs 9ためHARP_REPLYs 8ためHARP_REQUESTs 2
ar$pln - SHALL contain 4.
ARの$のPLNは - 4を含まなければなりません。
ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 6.
ARの$のRLNは - これはELSE HIPPI-800 HWアドレスである場合には、HIPPI-6400のために、それが6を含まなければならない10を含まなければなりません。
ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 6.
ARの$のTHLは - これはHIPPI-800 HWはELSEに対処されている場合は、HIPPI-6400のために、それが6を含まなければならない10を含まなければなりません。
ar$rha - in requests and NAKs it SHALL contain the requester's HW address. In replies it SHALL contain the target port's HW address.
ARの$のRHA - 要求とのNAKで、それは要求者のHWアドレスを含まなければなりません。回答では、ターゲットポートのHWアドレスを含まなければなりません。
ar$rpa - in requests and NAKs it SHALL contain the requester's IP address if known, otherwise zero. In other replies it SHALL contain the target port's IP address.
ARの$のRPA - 要求と知られている場合、それは要求者のIPアドレスを含まなければならないのNAKで、そうでない場合はゼロ。他の回答では、ターゲットポートのIPアドレスを含まなければなりません。
ar$tha - in requests and NAKs it SHALL contain the target's HW address if known, otherwise zero. In other replies it SHALL contain the requester's HW addressA.
ARの$股関節 - 要求と知られている場合、それは、ターゲットのHWアドレスを含まなければならないのNAKで、そうでない場合はゼロ。他の回答では、要求者のHW ADDRESSAを含まなければなりません。
ar$tpa - in requests and NAKs it SHALL contain the target's IP address if known, otherwise zero. In other replies it SHALL contain the requester's IP address.
ARの$のTPA - 要求と知られている場合、それは、ターゲットのIPアドレスを含まなければならないのNAKで、そうでない場合はゼロ。他の回答では、要求者のIPアドレスを含まなければなりません。
The format of the six bytes of the ULA SHALL be the same as required in the HIPPI-LE header (see section 6.2), except for the alignment of the ULAs with respect to the 32-bit HIPPI word, which is different between ARP and HIPPI-LE. No bit reversal is necessary as is required with FDDI.
HIPPI-LEヘッダーに必要とされるULAの6バイトの形式は、ARPとの間で異なる32ビットHIPPIワード、に対するULAsの位置合わせを除いて、（セクション6.2を参照）と同じでなければなりませんHIPPI-LE。 FDDIで必要とされる何ビット反転は必要ではありません。
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP Message
HARP_REQUEST message HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = IPa HARP ar$rha = SWy ULAy HARP ar$tha = 0 ** ** is what we would like to find out
HARP_REQUESTメッセージHARPのAR $ OP = 1（HARP_REQUEST）HARPのar $のRPA = IPY HARPのARます$トン= IPaのHARPのar $のRHA = SWYウレイHARPは、AR $ THA = 0 ** **見つけるために私たちが希望するものです
HARP_REPLY message format HARP ar$op = 2 (HARP_REPLY) HARP ar$rpa = IPa HARP ar$tpa = IPy HARP ar$rha = SWa ULAa * HARP ar$tha = SWy ULAy * answer we were looking for
私たちが探していたHARP_REPLYメッセージフォーマットHARPのARの$のOP = 2（HARP_REPLY）HARPのar $ RPA = IPaのHARPのar $トン= IPY HARPのar $ RHA = SWaをULAa * HARP AR $ THA = SWYウレイ*答え
InHARP_REQUEST message format HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAa ** is what we would like to find out
InHARP_REQUESTメッセージフォーマットHARPのARの$のOP = 8（InHARP_REQUEST）HARPのARの$ RPA = IPY HARPのar $のTPA = 0 ** HARPのar $のRHA = SWYウレイHARPのARの$ THA = SWaをULAa **私たちが知りたいものです
InHARP_REPLY message format HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy * answer we were looking for
InHARP_REPLYメッセージフォーマットHARPのar $のOP = 9（InHARP_REPLY）HARP AR $ RPA = IPアドレス* HARPのARます$トン= IPY HARPのARます$ RHA = SWaをULAa HARP我々が探していたのar $股関節= SWYウレイ*の答え
The HARP_NAK message format is the same as the received HARP_REQUEST message format with the operation code set to HARP_NAK; i.e. the HARP_REQUEST message data is copied byte for byte for transmission with the HARP_REQUEST operation code changed to the HARP_NAK value. HARP makes use of an additional operation code for HARP_NAK. Hence, HARP_NAK MUST be implemented.
HARP_NAKメッセージフォーマットはHARP_NAKに設定された動作コードを用いて受信HARP_REQUESTメッセージフォーマットと同一です。 HARP_REQUEST操作コードで伝送するためのバイトのための、すなわちHARP_REQUESTメッセージデータがコピーされるバイトはHARP_NAK値に変更しました。 HARPはHARP_NAKのための追加的な操作コードを使用しています。したがって、HARP_NAKを実装する必要があります。
The combined HIPPI-LE/HARP message contains ten addresses, two for the destination and two for the source of the message, three for the requester and three for the target:
合わせたHIPPI-LE / HARPメッセージは10のアドレス、宛先のための2つのメッセージと、要求者のための3つのターゲットのための3つの源のための2つが含まれています。
Destination Switch Address (HIPPI-LE) Destination ULA (HIPPI_LE)
宛先スイッチアドレス（HIPPI-LE）先ULA（HIPPI_LE）
Source Switch Address (HIPPI-LE) Source ULA (HIPPI-LE)
ソーススイッチアドレス（HIPPI-LE）ソースULA（HIPPI-LE）
Requester IP Address (HARP) Requester ULA (HARP) Requester Switch Address (HARP)
リクエスタIPアドレス（HARP）リクエスタULA（HARP）リクエスタスイッチ・アドレス（HARP）
Target IP Address (HARP) Target ULA (HARP) Target Switch Address (HARP)
ターゲットのIPアドレス（HARP）ターゲットULA（HARP）ターゲットスイッチアドレス（HARP）
Examples:
例：
The following relations are true for a HARP_REQUEST and InHARP_REQUESTs.
以下の関係がHARP_REQUESTとInHARP_REQUESTsのために真です。
LIS without broadcast - Dest SW Addr = HARP server SW Addr (with HARP server) Dest ULA = HARP server ULA Source SW Addr = Requester's SW Addr Source ULA = Requester's ULA
放送なしLIS - DestはSWアドレス= HARPサーバ（HARPサーバと）SW ADDR DestはULA = HARPサーバULAソースSWアドレス=リクエスタのSW ADDRソースULA =リクエスタのULA
7 Broadcast and Multicast
7ブロードキャストおよびマルチキャスト
HIPPI-SC does not require switches to support broadcast. Broadcast support has therefore been absent from many HIPPI networks.
HIPPI-SCはブロードキャストをサポートするためのスイッチを必要としません。ブロードキャストのサポートは、それゆえ、多くのHIPPIネットワークから欠席しています。
During its registration phase, every port, including HARP server(s), discover if the underlying medium is capable of broadcast (see section 5.1.2). Should this not be the case, then the HARP server(s) MUST emulate broadcast through an IP broadcast emulation server.
根本的な媒体が放送できる場合、登録フェーズでは、HARPサーバ（複数可）を含むすべてのポートは、発見（セクション5.1.2を参照してください）。このような場合であってはならない、そして、HARPサーバ（複数可）IPブロードキャスト・エミュレーション・サーバーを介して放送をエミュレートしなければなりません。
A HIPPI IP broadcast server (PIBES) is an extension to the HARP server and only makes sense when the LIS does not inherently support broadcast. The PIBES allows common upper layer networking protocols (RIP, TCP, UDP, etc.) to access IP LIS broadcast.
HIPPI IPブロードキャストサーバ（PIBES）は、HARPサーバへの拡張であり、LISは、本質的にブロードキャストをサポートしていない場合にのみ意味があります。 PIBESは、IP LIS放送にアクセスするために、共通の上位層ネットワークプロトコル（RIP、TCP、UDPなど）を可能にします。
To emulate broadcast within an LIS, a PIBES SHALL use the currently valid HARP table of the HARP server as a list of addresses called the target list. The broadcast server SHALL validate that all incoming messages have a source address which corresponds to an address in the target list. Only messages addressed to the IP LIS broadcast addresses, multicast address or 255.255.255.255 are considered valid messages for broadcasting. Invalid messages MUST be dropped. All valid incoming messages shall be forwarded to all addresses in the target list.
LIS内放送をエミュレートするために、PIBESは、ターゲットリストと呼ばれるアドレスのリストとしてHARPサーバの現在有効なHARPテーブルを使用しなければなりません。放送サーバは、すべての着信メッセージは、ターゲットリスト内のアドレスに対応するソースアドレスを持っていることを確認するものとします。メッセージだけIP LISブロードキャストアドレス、マルチキャストアドレスまたは255.255.255.255宛は放送用の有効なメッセージと考えられています。無効なメッセージは廃棄されなければなりません。すべての有効な受信メッセージは、ターゲットリスト内のすべてのアドレスに転送されなければなりません。
It is RECOMMENDED that the broadcast server run on the same port as the HARP server since this memo does not define the protocol for exchanging the valid HARP table. The default address to use for the broadcast address is the operational HARP server address.
このメモ以来HARPサーバと同じポート上で実行する放送サーバが有効なHARPテーブルを交換するためのプロトコルを定義していないことが推奨されます。ブロードキャストアドレスに使用するデフォルトのアドレスは、運用HARPサーバーのアドレスです。
This memo only defines IP broadcast. It is independent of the underlying hardware addressing and broadcast capabilities. Any port can differentiate between IP traffic directed to itself and a broadcast message sent to it by looking at the IP address. All IP broadcast messages SHALL use the IP LIS broadcast address or.
このメモは、IP放送を定義します。これは、基盤となるハードウェアのアドレッシングと放送機能とは無関係です。任意のポートを自身に向けIPトラフィックとIPアドレスを見て、それに送信されたブロードキャストメッセージを区別することができます。すべてのIPブロードキャストメッセージは、IP LISのブロードキャストアドレスを使用するか、ないものとします。
It is RECOMMENDED that the PIBES run on the same port as the HARP server. In that case, the PIBES SHALL use the same address as the HARP server.
PIBESがHARPサーバと同じポート上で実行することをお勧めします。その場合には、PIBESは、HARPサーバーと同じアドレスを使用しなければなりません。
HIPPI does not directly support multicast address, therefore there are no mappings available from IP multicast addresses to HIPPI multicast services. Current IP multicast implementations (i.e. MBONE and IP tunneling, see [9]) will continue to operate over HIPPI-based logical IP subnets if all IP multicast packets are sent using the same algorithm as if the packet were being sent to 255.255.255.255.
HIPPIは直接マルチキャストアドレスをサポートしていない、したがって、マルチキャストサービスをHIPPIするIPマルチキャストアドレスから利用可能なマッピングはありません。現在のIPマルチキャスト実装パケットが255.255.255.255に送られたかのようにすべてのIPマルチキャストパケットは、同じアルゴリズムを使用して送信される場合HIPPIベースの論理IPサブネット上で動作し続ける（即ちMBONEとIPトンネリングは、[9]を参照）。
It is obvious that a broadcast emulation service (as defined in section 7.1) has an inherent performance limit. In an LIS with n ports, the upper bound on the bandwidth that such a service can broadcast is: (total bandwidth)/(n+1)
放送エミュレーションサービス（セクション7.1で定義されるように）固有の性能限界を有していることが明らかです。 NポートとLISにおいて、そのようなサービスがブロードキャストできること帯域幅の上限は、（合計帯域幅）/（N + 1）
since each message must first enter the broadcast server, accounting for the additional 1, and then be sent to all n ports. The broadcast server could forward the message destined to the port on which it runs internally, thus reducing (n+1) to (n) in a first optimization.
各メッセージは、第1の追加の1を占め、ブロードキャスト・サーバーを入力する必要があり、その後、すべてのNポートに送信される。のでブロードキャスト・サーバーは、このように第1の最適化中に（N）と（N + 1）の還元、それが内部的に実行されているポートに宛てたメッセージを転送することができました。
This service is adequate for the standard networking protocols such as RIP, OSPF, NIS, etc. since they usually use a small fraction of the network bandwidth for broadcast. For these purposes, the broadcast emulation server as defined in this memo allows the HIPPI network to look similar to an Ethernet network to the higher layers.
彼らは通常、放送用のネットワーク帯域幅のごく一部を使用するので、このサービスは、などRIP、OSPF、NIS、などの標準ネットワークプロトコルには十分です。これらの目的のために、このメモで定義されている放送エミュレーションサーバーは、HIPPIネットワークが上位レイヤにイーサネット・ネットワークに類似して見えることができます。
It is further obvious that such an emulation cannot be used to broadcast high bandwidth traffic. For such a solution, hardware support for true broadcast is required.
このようなエミュレーションは、高帯域幅のトラフィックをブロードキャストするために使用することができないこと、さらに明らかです。そのような解決のために、真の放送のためのハードウェアサポートが必要です。
8 HARP for Scheduled Transfer Protocol[17]
スケジュールされた転送プロトコル[17] 8 HARP
This RFC also applies for resolving addresses used with Scheduled Transfer (STP) over HIPPI-800 instead of IP. This RFC's message types and algorithms can be used for STP (since STP uses Internet Addresses) as long as there is also an IP over HIPPI implementation on all of the ports.
このRFCはまた、HIPPI-800の代わりに、IP上のスケジュール転送（STP）で使用されるアドレスを解決するために適用されます。このRFCのメッセージタイプおよびアルゴリズムは限りIPは、すべてのポート上のHIPPIの実装上にもありますよう（STPは、インターネットアドレスを使用しているため）STPのために使用することができます。
9 Discovery of One's Own Switch Address
自分のスイッチ・アドレスの9発見
This HARP specification assumes that each port has prior knowledge of its own hardware address. This address may be manually configured, by means outside the scope of this memo or a port may discover its own logical address through the algorithm described below.
このHARP仕様は、各ポートが独自のハードウェアアドレスの予備知識を持っていることを前提としています。このアドレスは、手動で、このメモの範囲の外の手段により、構成され得るか、またはポートは、以下に説明するアルゴリズムを介して、自身の論理アドレスを発見することができます。
Ports are NOT REQUIRED to implement this switch address discovery protocol but are encouraged to do so since it reduces the administrative overhead. The algorithm presented in this section is based on John Renwick's work as detailed in RFC-1374 [14]. The concept of the discovery process is to scan all possible switch addresses. The messages that are received will be the ones containing one of our switch addresses.
ポートは、このスイッチのアドレス検索プロトコルを実装する必要はありませんが、それは管理上のオーバーヘッドを削減するので、そうすることをお勧めします。 RFC-1374 [14]で説明するように、このセクションで提示するアルゴリズムは、ジョン・レンウィックの仕事に基づいています。発見プロセスの概念は、すべての可能なスイッチアドレスをスキャンすることです。受信したメッセージは、私たちのスイッチアドレスのいずれかを含むものになります。
If a port implements this algorithm it SHALL form a HIPPI-LE message as defined in HIPPI-LE: containing an Self_Address_Resolution_Request (see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address (set to the correct ULA for the sender), and the Source_Switch_Address and Destination_Switch_Address.
ポートは、このアルゴリズムを実装している場合には、HIPPI-LEで定義されてHIPPI-LEメッセージを形成しなければならないSelf_Address_Resolution_Requestを含有する（送信者の正しいULAに設定）PDUタイプ、Source_IEEE_Address及びDestination_IEEE_Address（[3]を参照）、およびSource_Switch_AddressとDestination_Switch_Address。
This self address resolution message uses the same HIPPI-LE message format as described in HIPPI-SC and HIPPI-LE: the Self Address Resolution Request PDU and Self Address Resolution Response PDU type codes and no piggybacked ULP data. The HIPPI-LE header contents for the request are:
HIPPI-SCおよびHIPPI-LEに記載されているように、この自己アドレス解決メッセージは、同じHIPPI-LEメッセージフォーマットを使用：自己アドレス解決要求PDUと自己アドレス解決応答PDUタイプコードなしピギーバックULPデータ。要求のHIPPI-LEヘッダの内容は次のとおりです。
HIPPI-LE Message_Type is = 3, Self Addr. Resolution Request HIPPI-LE Destination_Address_Type = 0 (undefined) HIPPI-LE Destination_Switch_Address = X (X element scan range) HIPPI-LE Source_Address_Type = 0 (undefined) HIPPI-LE Source_Switch_Address = 0 (unknown) HIPPI-LE Destination_IEEE_Address = 0 HIPPI-LE Source_IEEE_Address = my ULA
HIPPI-LEのMessage = 3、自己ADDRです。解決要求HIPPI-LE Destination_Address_Type = 0（未定義）HIPPI-LE Destination_Switch_Address = X（X元素走査範囲）HIPPI-LE Source_Address_Type = 0（未定義）HIPPI-LE Source_Switch_Address = 0（不明）HIPPI-LE Destination_IEEE_Address = 0 HIPPI-LE Source_IEEE_Address =私のULA
There is no D2 data; the message contains only the HIPPI-FP header and D1_Area with the HIPPI-LE header.
何D2のデータはありません。メッセージは、HIPPI-LEヘッダでのみHIPPI-FPヘッダとD1_Areaを含有します。
Ports SHALL start the scan with a configurable logical address (default 0x000) and increment the value for by one for each subsequent try. The port SHALL continue until it sees its own self address resolution request or it has reached the end, which may be another configurable value (default 0xFFF). It is RECOMMENDED that the range of addresses to scan be configurable since some networks have equipment that does not gracefully handle HIPPI-LE messages.
ポートは、設定可能な論理アドレス（デフォルトの$ 000）でスキャンを開始し、後続の各試みのための1での値をインクリメントするものとします。それは自身の自己アドレス解決要求を見てまで、ポートは継続する必要か、それは別の設定可能な値（デフォルト0xFFF）であってもよい終わりに達しています。いくつかのネットワークが正常HIPPI-LEメッセージを処理しない機器を持っているので、スキャンするアドレスの範囲は、設定することをお勧めします。
After a port sends the[se] request[s], two positive outcomes are possible:
ポートは、[SE]要求[S]を送信した後、2つの正の結果が可能です。
o the port receives its own request(s), and obtains one of its own Switch Address, or
Oポートは、独自の要求（複数可）を受け取り、独自のスイッチ・アドレスのいずれかを取得、または
o the port receives an AR_S_Response with the Destination_Switch_Address filled in.
Oポートは、記入Destination_Switch_AddressとAR_S_Responseを受けます。
10 Security Considerations
10のセキュリティの考慮事項
HARP messages are not authenticated which is a potentially flaw that could allow corrupt information to be introduced into the server system.
HARPのメッセージが破損している情報は、サーバシステムに導入される可能性があり、潜在的な欠陥がある認証されません。
There are other known security issues relating to port impersonation via the address resolution protocols used in the Internet [8]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using HARP.
インターネット[8]で使用されるアドレス解決プロトコルを介しポート偽装に関連する他の既知のセキュリティ問題があります。特別なセキュリティメカニズムは、HARPを使用してネットワークで使用するために、ここで定義されたアドレス解決メカニズムに追加されていません。
Not all of the security issues relating to ARP over HIPPI are clearly understood at this time. However, given the security hole ARP allows, other concerns are probably minor.
HIPPI上でARPに関連するセキュリティ上の問題のすべては明らかに、この時点で理解されているわけではありません。しかし、ARPができますセキュリティホールを与え、他の懸念は、おそらくマイナーです。
11 Open Issues
11点の未解決の問題
Synchronization and coordination of multiple HARP servers and multiple broadcast servers are left for further study.
複数のHARPサーバと複数の放送サーバの同期と調整はさらなる研究のために残されています。
12 HARP Examples
12のHARP例
Assume a HIPPI-SC switch is installed with three connected ports: x, y, and a. Each port has a unique hardware address that consists of Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and ULAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa (SWa, ULAa), this address is the authoritative HIPPI hardware address in the HRAL (HARP Request Address List).
X、Y、および：HIPPI-SCスイッチは、3つの接続ポートが設置されていると仮定する。各ポートは、スイッチ・アドレス（例えばSWxと、SWY、スイッチSWa）及びユニークULA（それぞれULAx、ウレイおよびULAa、）からなる一意のハードウェアアドレスを持っています。アドレスHWA（スイッチSWa、ULAa）にマッピングされているスイッチポートに接続されているHARPサーバーは、このアドレスはHRAL（HARP要求アドレス一覧）における権威HIPPIハードウェアアドレスです。
The HARP server's table is empty. Ports X and Y each know their own hardware address. Eventually they want to talk to each other; each knows the other's IP address (from the port database) but neither knows the other's ULA or Switch Address. Both ports X and Y have their interfaces configured DOWN.
HARPサーバーのテーブルは空です。ポートXとYは、それぞれ独自のハードウェアアドレスを知っています。結局、彼らはお互いに話をしたいです。それぞれが（ポートデータベースから）の他のIPアドレスを知っているが、どちらも相手のULAまたはスイッチのアドレスを知っています。両方のポートXおよびYは、それらのインターフェースがDOWN設定されています。
NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. Likewise, ar$rhl = ar$thl = 9 are omitted since these are all HIPPI-800 examples.
注：彼らは一定であるため、LLC、SNAP、イーサタイプ、HIPPI-LEメッセージタイプ、ARの$のHRD、ARの$ Proは、ARの$のPLNフィールドは以下の例から除外されています。これらはすべてHIPPI-800の例であるため、同様に、AR $ RHL = AR $ THL = 9は省略されています。
Port Y starts: its HARP table entry state for the server: PENDING
ポートYが開始されます：サーバー用のHARPテーブルエントリの状態を：PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa after starting a table entry for HWa.
1.ポートYは、そのインターフェイスを開始し、HWAのテーブルエントリを開始した後HWAにInHARP_REQUESTを送信します。
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Source_Switch_Address = SWy HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAa ** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWaをHIPPI-LE Source_Switch_Address = SWY HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address =ウレイHARP ARする$ OP = 8（InHARP_REQUEST）HARPのアルゴン$ RPA = IPY HARP ARする$ TPA = 0 ** HARPのARの$ RHA = SWYウレイHARPのar $股関節= SWaをULAa **は、私たちが知りたいものです
2. HARP server receives Y's InHARP_REQUEST, it examines the source addresses and scans its tables for a match. Since this is the first time Y connects to this server there is no entry and one will be created and time stamped with the information from the InHARP_REQUEST. The HARP server will then send a InHARP_REPLY including its IP address.
2. HARPサーバーがYのInHARP_REQUESTを受信すると、送信元アドレスを調べ、一致のためにそのテーブルをスキャンします。これは、Yは、このサーバに接続する最初の時間ですので、そこにはエントリがありませんし、1が作成され、時間がInHARP_REQUESTからの情報を刻印します。 HARPサーバーは、そのIPアドレスを含むInHARP_REPLYを送信します。
HIPPI-LE Destination_Switch_Address = SWy HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy * answer we were looking for
HIPPI-LE $ RHA AR Destination_Switch_Address = SWY HIPPI-LE Source_Switch_Address = SWaをHIPPI-LE Destination_IEEE_Address =ウレイHIPPI-LE Source_IEEE_Address = ULAa HARPのAr $ OP = 9（InHARP_REPLY）HARP AR $ RPA = IPアドレス* HARPのARする$ TPA = IPY HARP =スイッチSWa ULAa我々が探していたHARPのARの$股関節= SWYウレイ*の答え
3. Port Y examines the incoming InHARP_REPLY, completes its table entry for the HARP server. The client's HARP table entry for the server now passes into the VALID state and is usable for regular HARP traffic. Receiving this reply ensures that the HARP server has properly registered the client.
3.ポートYは、入ってくるInHARP_REPLYを調べHARPサーバ用のテーブルエントリを完了します。サーバーのクライアントのHARPテーブルエントリは現在、VALID状態に入り、通常のHARPトラフィックのために使用可能です。この応答を受信すると、HARPサーバーがクライアントを正しく登録していることを保証します。
If there is a broadcast capable network then the authoritative address in the HRAL would be mapped to the broadcast address, HWb = SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
ブロードキャスト可能なネットワークが存在する場合、HRALにおける権威アドレスがブロードキャストアドレスにマッピングされる、HWB = SWbを、ULAb（おそらく0xFE1とFF：FF：FF：FF：FF：FF）。
Port Y starts: its HARP table entry state for HWa: PENDING
ポートYが開始されます：HWAのためにそのHARPテーブルエントリの状態を：PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa, in this example the broadcast address, after starting a table entry.
1.ポートYは、そのインターフェイスを開始し、テーブルエントリを開始した後、この例では、HWAにブロードキャストアドレスをInHARP_REQUESTを送信します。
HIPPI-LE Destination_Switch_Address = SWb HIPPI-LE Source_Switch_Address = SWy HIPPI-LE Destination_IEEE_Address = ULAb HIPPI-LE Source_IEEE_Address = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWb ULAb ** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWbをHIPPI-LE Source_Switch_Address = SWY HIPPI-LE Destination_IEEE_Address = ULAb HIPPI-LE Source_IEEE_Address =ウレイHARP ARする$ OP = 8（InHARP_REQUEST）HARPのアルゴン$ RPA = IPY HARP ARする$ TPA = 0 ** HARPのARの$ RHA = SWYウレイHARP AR $ THA = SWbをULAb **は、私たちが知りたいものです
2. Since the network is a broadcast network, client Y will receive a copy of its InHARP_REQUEST. Client Y examines the source addresses. Since they are the same as what Y filled in the InHARP_REQUEST, Y can deduce that it is connected to a broadcast medium. Port Y completes its table entry for HWa. This entry will not timeout since it is considered unlikely for a particular underlying hardware type to change between broadcast and non-broadcast; therefore this mapping will never change.
2.ネットワークがブロードキャストネットワークであるので、クライアントYは、そのInHARP_REQUESTのコピーを受信します。クライアントYは、送信元アドレスを調べます。彼らはYがInHARP_REQUESTに満たされたものと同じなので、Yは、それが放送媒体に接続されていることを推測することができます。ポートYは、HWAのためにそのテーブルエントリを完了します。それは放送と非放送の間で変更するには、特定の基盤となるハードウェアの種類の可能性は低いと考えられているので、このエントリはタイムアウトしません。したがって、このマッピングは変更されることはありません。
The Operational Phase of the HARP protocol as specified in this memo is the same for both broadcast and non-broadcast capable HIPPI hardware. The authoritative address in the HRAL for this example will be HWa: <SWa, ULAa> and IPs for simplicity reasons.
このメモで指定されるようにHARPプロトコルの運用段階は、放送及び非放送可能HIPPIハードウェアの両方で同じです。 <スイッチSWa、ULAa>とシンプルさの理由のためのIPアドレス：この例のHRALにおける権威アドレスがHWAになります。
Assume the same process (steps 1-3 of section 10.1) happened for port X. Then the state of X and Y's tables is: the HARP server table entry is in the VALID state. So lets look at the message traffic when X tries to send a message to Y. Since X doesn't have an entry for Y,
同じプロセスが（セクション10.1のステップ1-3）ポートXに起こっと仮定すると、次に、XおよびYのテーブルの状態がある：HARPサーバ・テーブル・エントリが有効状態になっています。だから、Xは、XがYのエントリを持っていないので、Y.にメッセージを送信しようとするとメッセージトラフィックを見てみましょう
1. Port X connects to the authoritative address of the HRAL and sends a HARP_REQUEST for Y's hardware address:
1.ポートXはHRALの権威アドレスに接続し、YのハードウェアアドレスのHARP_REQUESTを送信します。
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPy HARP ar$rha = SWx ULAx HARP ar$tha = 0 ** ** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWaをHIPPI-LE Source_Switch_Address = SWxとHIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAx HARPのAr $ OP = 1（HARP_REQUEST）HARPのAr $のRPA = IPxをHARPのARする$ TPA = IPY HARP ARする$ RHA = SWxとULAx HARP AR $ THA = 0 ** **見つけるために私たちが希望するものです
2. The HARP server receives the HARP request and updates its entry for X if necessary. It then generates a HARP_REPLY with Y's hardware address information.
2. HARPサーバは、HARP要求を受信し、必要に応じてX用のエントリを更新します。その後、Yのハードウェアアドレス情報とHARP_REPLYを生成します。
HIPPI-LE Destination_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 2 (HARP_Reply) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = SWy ULAy * HARP ar$tha = SWx ULAx * answer we were looking for
HIPPI-LE Destination_Switch_Address = SWxとHIPPI-LE Source_Switch_Address = SWaをHIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAaのHARPのAR $ OP = 2（HARP_Reply）HARPのAr $のRPA = IPY HARPのARする$ TPA = IPxをHARP ARする$ RHA =私たちが探していたSWYウレイ* HARP AR $ THA = SWxとULAx *答え
3. Port X connects to port Y and transmits an IP message with the following information in the HIPPI-LE header:
3.ポートX、ポートYに接続し、HIPPI-LEのヘッダに以下の情報を有するIPメッセージを送信します。
HIPPI-LE Destination_Switch_Address = SWy HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Source_IEEE_Address = ULAx
HIPPI-LE Destination_Switch_Address = SWY HIPPI-LE Source_Switch_Address = SWxとHIPPI-LE Destination_IEEE_Address =ウレイHIPPI-LE Source_IEEE_Address = ULAx
If there had been a broadcast capable HIPPI network, the target ports would themselves have received the HARP_REQUEST of step 2 above and responded to them in the same way the HARP server did.
放送対応HIPPIネットワークがあった場合は、ターゲットポート自体は、上記のステップ2のHARP_REQUESTを受け、HARPサーバーがやったのと同じ方法でそれらに対応してきたでしょう。
Like in 12.3.1, assume that X and Y are fully registered with the HARP server. Then the state of X and Y's HARP server table entry is: VALID. So lets look at the message traffic when X tries to send a message to Q. Further assume that interface Q is NOT configured UP, i.e. it is DOWN. Since X doesn't have an entry for Q,
12.3.1のように、XとYが完全にHARPサーバに登録されていることを前提としています。そして、XとYのHARPサーバ・テーブル・エントリの状態は次のとおりです。VALID。だから、DOWNである、すなわち、Xはまた、そのインターフェイスのQがUPに構成されていないと仮定Q.にメッセージを送信しようとするとメッセージトラフィックを見てみましょう。 Xは、Qのエントリを持っていないので、
1. Port X connects to the HARP server switch address and sends a HARP_REQUEST for Q's hardware address:
1.ポートXは、HARPサーバスイッチアドレスに接続し、QのハードウェアアドレスのHARP_REQUESTを送信します。
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = SWx ULAx HARP ar$tha = 0 ** ** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWaをHIPPI-LE Source_Switch_Address = SWxとHIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAx HARPのAr $ OP = 1（HARP_REQUEST）HARPのAr $のRPA = IPxをHARPのARする$ TPA = IPQ HARP ARする$ RHA = SWxとULAx HARP AR $ THA = 0 ** **見つけるために私たちが希望するものです
2. The HARP server receives the HARP request and updates its entry for X if necessary. It then looks up IPq in its tables and doesn't find it. The HARP server then generates a HARP_NAK reply message.
2. HARPサーバは、HARP要求を受信し、必要に応じてX用のエントリを更新します。その後、そのテーブルにIPQを検索し、それを見つけることができません。 HARPサーバは、HARP_NAK応答メッセージを生成します。
HIPPI-LE Destination_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 10 (HARP_NAK) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = SWx ULAx HARP ar$tha = 0 *** *** No Answer, and notice that the fields do not get swapped, i.e. the HARP message is the same as the HARP_REQUEST except for the operation code.
HIPPI-LE Destination_Switch_Address = SWxとHIPPI-LE Source_Switch_Address = SWaをHIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAaのHARPのAR $ OP = 10（HARP_NAK）HARPのAr $のRPA = IPxをHARPのARする$ TPA = IPQ HARP ARする$ RHA = SWxとULAx HARP AR $ THA = 0 *** ***無回答、およびHARPメッセージが操作コードを除くHARP_REQUESTと同じである。すなわちフィールドは、スワップされませんがわかります。
If there had been a broadcast capable HIPPI network, then there would not have been a reply.
放送対応HIPPIネットワークがあった場合は、応答がなかったであろう。
13 References
13の参考文献
[1] ANSI X3.183-1991(R1996), Information Technology - High-Performance Parallel Interface - Mechanical, Electrical and Signaling Protocol Specification; (HIPPI-PH).
[1] ANSI X3.183-1991（R1996）、情報技術 - 高性能パラレルインターフェイス - 機械、電気およびシグナリングプロトコル仕様。 （HIPPI-PH）。
[2] ANSI X3.210-1998, Information Technology - High-Performance Parallel Interface - Framing Protocol; (HIPPI-FP).
[2] ANSI X3.210-1998、情報技術 - 高性能パラレルインタフェース - フレーミングプロトコル。 （HIPPI-FP）。
[3] ANSI X3.218-1993, Information Technology - High-Performance Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std 802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
[3] ANSI X3.218-1993、情報技術 - 高性能パラレル・インターフェース - ISO 8802-2のカプセル化（IEEE STD 802.2）論理リンク制御プロトコルデータユニット。 （HIPPI-LE）。
[4] ANSI X3.222-1997, Information Technology - High-Performance Parallel Interface - Physical Switch Control; (HIPPI-SC).
[4] ANSI X3.222-1997、情報技術 - 高性能パラレルインターフェイス - 物理スイッチコントロール。 （HIPPI-SC）。
[5] ANSI X3.300-1997, Information Technology - High-Performance Parallel Interface - Serial Specification; (HIPPI-Serial).
[5] ANSI X3.300-1997、情報技術 - 高性能パラレル・インターフェース - シリアル仕様。 （HIPPIシリアル）。
[6] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[6]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[7] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[7] Bradely、T.とC.ブラウン、 "逆アドレス解決プロトコル"、RFC 2390、1998年9月。
[8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[8] Bellovin氏、スティーブンM.、 "TCP / IPプロトコルスイートのセキュリティ問題"、ACMコンピュータコミュニケーションレビュー、巻。 19、第2号、頁32-48、1989。
[9] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[9]デアリング、S、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[10] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, June 1984.
[10]フィンレイソン、R.、マン、T.、モーグル、J.とM. Theimer、 "逆アドレス解決プロトコル"、RFC 903、1984年6月。
[11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.
[11] ANSI / IEEE STD。 802.2から1989、情報処理システム - ローカルエリアネットワーク - 論理リンク制御、「ローカルエリアネットワークのためのIEEE規格：論理リンク制御」、IEEE、ニューヨーク、ニューヨーク、1985年。
[12] Laubach, Mark., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[12]ラウバッハ、マーク。、 "ATMを介したClassical IPとARP"、RFC 2225、1998年4月。
[13] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982.
[13]プラマー、D.、「イーサネットアドレス解決プロトコル - または - ネットワークを変換すると、イーサネットハードウェア上での送信のための48ビットイーサネットアドレスへのアドレス」、RFC 826、1982年11月。
[14] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[14]レンウィック、J.およびA.ニコルソン、 "HIPPIのIPとARP"、RFC 1374、1992年10月。
[15] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[15]レンウィック、J.、 "HIPPIオーバーIP"、RFC 2067、1997年1月。
[16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[16]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol ANSI NCITS, Scheduled Transfer Protocol draft standard.
[17] ANSI NCITS xxx.199x、プロジェクト1245-D、スケジュール転送プロトコルANSI NCITS、スケジュール転送プロトコルドラフト標準。
[18] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[18]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
14 Acknowledgments
14の謝辞
This memo could not have come into being without the critical review from Greg Chesson, Carlin Otto, the high performance interconnect group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand and Jeff Young) and the expertise of the ANSI T11.1 Task Group responsible for the HIPPI standards work.
このメモはグレッグChesson、カーリンオットー、シリコングラフィックス（特にジム・ピンカートン、ブラッド・ストランドとジェフ・ヤング）の高性能インターコネクト・グループからの批判的検討およびANSI T11.1タスクグループが責任を負うの専門知識がないものになってきたことができませんでしたHIPPI規格作業のため。
This memo is based on the second part of [14], written by John Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written by T. Bradley and C. Brown provide the fundamental algorithms of HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [12], written by Mark Laubach who laid the structural groundwork for the HARP server.
このメモは、ジョンレンウィックによって書かれた[14]の第二の部分に基づいています。 ARP [13]デイブプラマーおよびインバースARPによって書かれた[7]この文書で提示されるようT.ブラッドリーとC.ブラウンHARPの基本的なアルゴリズムを提供することによって書かれました。さらに、HARPサーバはHARPサーバのための構造基礎を築いマークラウバッハによって書かれた[12]に提示概念とモデルに基づいています。
15 Changes from []
[]から15点の変更
RFC-2067 obsoletes RFC-1374 but left ARP outside of its scope because there was not enough implementation experience. This memo is an effort to clarify and expand the definition of ARP over HIPPI as found in RFC-1374 such that implementations will be more readily possible, especially considering forward interoperability with HIPPI-6400.
RFC-2067はRFC-1374を廃止ますが、十分な実装経験がなかったので、その範囲の外でARPを残しました。このメモはRFC-1374の実装は、特に前方HIPPI-6400との相互運用性を考慮し、より容易に可能となるようにして見られるようHIPPI超えるARPの定義を明確化し、拡大するための努力です。
The changes from RFC-1374 [14] are:
RFC-1374 [14]からの変更は、次のとおり
o A new message format to acknowledge the HIPPI hardware address format and to eliminate the requirement of HIPPI-LE ARP for HARP to function.
HIPPIのハードウェア・アドレス形式を確認し、機能するHARP用HIPPI-LE ARPの必要性を排除するために、新しいメッセージフォーマットO。
o Explicit registration phase.
O明示的な登録フェーズ。
o Additional message formats: InHARP requests and replies as well as HARP_NAKs.
InHARP要求と応答だけでなく、HARP_NAKs：追加のメッセージ・フォーマットO。
o Details about the IP subnetwork configuration.
IPサブネットワークの構成に関するOの詳細。
o Details about table aging.
テーブルのエージングについてOの詳細。
o IP broadcast emulation.
お いＰ ｂろあｄかｓｔ えむぁちおん。
16 Author's Address
16著者のアドレス
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94043
ジャン・ミッシェル・Pittetシリコングラフィックス株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043
Phone: 650-933-6149 Fax: 650-933-3542 EMail: jmp@sgi.com, jmp@acm.org
電話：650-933-6149ファックス：650-933-3542 Eメール：jmp@sgi.com、jmp@acm.org
17 Full Copyright Statement
17完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。