[要約] RFC 2834は、高速ネットワーク規格であるHIPPI-800上でのARPおよびIPブロードキャストの実装仕様を定めています。HIPPIの特性を考慮したアドレス解決の手順と、ブロードキャストデータの処理方法を詳しく説明しています。HIPPI-800環境において、標準的なIPプロトコルスタックを効率的に動作させるための技術基準を提供することを目的としています。
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
HIPPI-800でARPとIP放送
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.
Copyright（c）The Internet Society（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.
このドキュメントは、IPアドレスをANSI高性能並列インターフェイス（HIPPI）ハードウェアアドレスに解決し、HARPの直接拡張として論理IPサブネット（LIS）でIPブロードキャストをエミュレートする方法を指定します。このメモは、HIPPI-800とHIPPI-6400（Gigabyte System Network、GSNとしても知られている）の間で相互操作するHARPを定義します。このドキュメント（RFC-2067 "IP over Hippi"と組み合わせた場合）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は、1秒あたり800または1600メガビットで同時にデータを送信および受信できます。1987年から1997年の間に、ANSI X3T11.1 HIPPIワーキンググループ（現在はNCITS T11.1として知られています）は、ネットワークインターフェイスとしてのHippiの使用に耐える5つのドキュメントを標準化しました。物理的および電気仕様（HIPPI-PH [1]）、バイトの流れのフレーミング（HIPPI-FP [2]）、IEEE 802.2 LLCのカプセル化（HIPPI-LE [3]）、物理層スイッチ（Hippi-SC [4]）および物理レベルおよび光学仕様（Hippi-Serial [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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 または関連する仕様で説明されているように解釈されるものとします。
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.
特に明記しない限り、値は10進数です。フォーマットは、IEEE 802.1A Canonical Bit OrderとHippi-FP BitおよびByte Orderに従います。
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 [10]のHIPPI固有バージョン（つまり、プロトコルとHIPPI固有のエンコード）についても説明しています。
HARP table
ハープテーブル
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
各ホストには、IPメンバーのハードウェアアドレスアドレスマッピングを含むHARPテーブルがあります。
HIPPI-Serial
ヒッピシリアル
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リクエストアドレスリスト。アドレスに名前を解決するときにHARPメッセージが送信されるULAのリスト（セクション4.2を参照）。
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.
エンティティ（通常はコンピューターシステム）が1つ以上の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によってHIPPI-SCスイッチに接続され、IPデータグラムを送信および受信する1つのHIPPIソース/宛先デュアルシンプレックスペアで構成されるエンティティ。
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-fieldに送信されます。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)
ユニバーサルランマックアドレス（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.
IEEEが管理する48ビットのグローバルに一意のアドレスは、イーサネット、FDDI、802ネットワーク、またはHIPPI-SC LANの各ポートに割り当てられています。
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.
[12]で定義されているARP（アドレス解像度プロトコル）は、「ローカル」ケーブルで作業することを目的としていました。この定義により、ARPプロトコルはローカル論理IPサブネット（LIS）スコープを提供します。LISシナリオでは、それぞれの個別の管理エンティティがLIS内のホストとルーターを構成します。各LIは、同じ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ルータを介して提供されます。このルータは、1つ以上のLISのメンバーとして設定されているHIPPIネットワークに接続されたHIPPIポートです。この設定により、同じHIPPIネットワーク上で複数の分離したLISが動作することになってもよいです (MAY)。このモデルを使用する場合、HIPPIネットワーク上で2つのIPメンバー間に直接HIPPI接続を開くことが可能であっても、異なるIPサブネットのポートは中間IPルータを介して通信すべきです (SHOULD)。これは、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.
デフォルトでは、セクション5で詳述されているHARP方式および古典的なLISルーティングモデルは、LIS内のすべてのIPメンバークライアントに対して利用可能でなければなりません (MUST)。
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ネットワーク/サブネットアドレスおよびアドレスマスクを持たなければなりません (SHALL) [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ステーションに実装しなければならない (MUST) 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ハードウェアアドレスには、ポートのスイッチアドレスが含まれていなければなりません (MUST)（セクション9を参照）。アドレスにはゼロ以外のULAアドレスも含めるべきです (SHOULD)。ULAがない場合、そのフィールドはゼロでなければなりません (MUST)。
o HARP Request Address List (HRAL):
o 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は、アドレス解決サービスを識別する2つ以上のアドレスの順序付けられたリストです。すべてのHARPクライアントは同一に設定されなければならず (MUST)、すなわちすべてのポートがHRAL内に同じアドレスを持たなければなりません (MUST)。
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アドレスが含まれていなければなりません (MUST)。
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.
デフォルトでは、最初のアドレスはブロードキャスト用の予約アドレス、すなわち「従来IEEE 802.1ブロードキャストアドレス宛てとされていたIPトラフィック: 0xFE1」[4]のアドレスでなければなりません (MUST)。このHARPサービスエントリのULAは FF:FF:FF:FF:FF:FF でなければなりません (SHALL)。
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.
2番目のアドレスは「...アドレス解決要求に関するメッセージ: 0xFE0」[4]のアドレスであることが要求されます (REQUIRED)。このHARPサーバエントリのULAは 00:00:00:00:00: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
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>
...
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) を利用しなければなりません (SHALL)。HARPは、インターネットアドレス解決プロトコル (ARP) と同じ機能を提供します。HARPはRFC-826 [13]で定義されているARPに基づいています。従来のネットワークでは、インターネットアドレスが分かっている場合に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.
このメモでは、HARPプロトコルのPIBE（以下のセクション7を参照）の拡張をさらに必要とし、IPのような上層層プロトコルへのブロードキャストサービスを保証します。
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.
インターネットアドレスは、ULAおよびスイッチアドレスとは無関係に割り当てられます。HARPを使用する前に、各ポートは自身のIPアドレスおよびハードウェアアドレスを把握していなければなりません (MUST)。ULAは任意ですが、従来のネットワークへのブリッジングが望まれる場合には推奨されます (RECOMMENDED)。
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アドレスでリモートポートへの接続を要求すると、ハードウェアアドレスを決定できます。構築でき、i-fieldの正しいスイッチアドレスを使用してポートへの接続を確立できます。
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は2位のプロトコルです。最初のフェーズは登録フェーズで、第2フェーズは運用フェーズです。登録フェーズでは、ポートがブロードキャストハードウェアに接続されているかどうかを検出します。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サービスが存在しなければなりません (SHALL)。各時点において、権威あるHARPサービスは1つだけです。
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を送信しなければなりません (SHALL)。ポートが自身の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を送信しなければなりません (SHALL)。InHARP_REPLYを送信するすべてのアドレスは応答性のあるHARPサーバとみなされます。権威あるHARPサービスは、HRAL内で最初に現れるHARPサーバでなければなりません (SHALL)。
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サーバアドレスに「登録」を維持することが要求されます (REQUIRED)（注: ブロードキャストアドレスは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.
権威あるHARPサーバは、(1) クライアントによる1つ以上の登録要求（セクション5.1.2および5.2を参照）、(2) 過去120秒間における任意の2つのHARP_REQUEST、への応答に失敗した場合、または (3) 外部エージェントが権威あるHARPサーバの障害を検出した場合に、非応答とみなされるべきです (SHOULD)。そのような外部エージェントの詳細およびHARPクライアントとの相互作用は、本文書の範囲外です。権威あるHARPサーバが非応答になった場合、登録プロセスは再開されるべきです (SHOULD)。権威ある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メッセージを送信することにより、登録フェーズを開始しなければなりません (SHALL)。クライアントは、自身のInHARP_REQUESTを受信したとき、または少なくとも1つのHARPサーバからInHARP_REPLYを受信し、かつセクション5.1.1で説明されている権威あるHARPサービスを決定したときのいずれかに、登録フェーズを終了して運用フェーズへと移行しなければなりません (SHALL)。
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を送信します。最初に試されるアドレスは、ブロードキャストアドレス「0x07000fe1 ff：ff：ff：ff：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).
2番目のケースでは、ポートはHRAL内の次のアドレスを権威あるアドレスの候補として選択し、そのアドレス (0x07000FE0 00:00:00:00:00:00) にInHARP_REQUESTを送信しなければなりません (SHALL)。
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を使用してブロードキャストサービスを提供することが要求されます (REQUIRED)（セクション7を参照）。
o If the port receives an InHARP_REPLY, then it is a HARP client and not a HARP server.
o ポートがInHARP_REPLYを受信した場合、それは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つの終了基準のいずれかが満たされるまで、HRAL内の各非ブロードキャストHARPサーバアドレスへの再試行を少なくとも5秒に1回継続しなければなりません (SHALL)。
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プロトコルの適用です。目的は、ハードウェアブロードキャスト機能を存在または検出した場合、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メッセージを確認し、登録フェーズを完了しなければなりません (SHALL)。クライアントはさらに、自身がブロードキャスト対応ネットワークに接続されていることに留意すべきであり (SHOULD)、セクション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を待たなければなりません (SHALL)。これにより、クライアントには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_REQUESTを送信してHARP_REPLYを受信することにより、IPメンバーのIPからHWアドレスへのマッピングを含む自身のHARPテーブルを取得および更新しなければなりません (SHALL)。クライアントは運用フェーズ中は完全に動作可能です。
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:
アドレス解決要求のターゲットは、要求内に見つかる新しい情報を用いて自身のアドレスマッピングテーブルを更新します。自身がターゲットポートである場合、応答メッセージを作成して送信しなければなりません (SHALL)。以下の文のうち少なくとも1つが要求に当てはまる場合、そのポートはアドレス解決要求のターゲットとなります:
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を参照）。
4. The port is a HARP server.
4. ポートはハープサーバーです。
NOTE: It is RECOMMENDED that all HARP servers run on a ports which each have a non-zero ULA.
注: すべてのHARPサーバは、それぞれゼロ以外のULAを持つポート上で実行されることが推奨されます (RECOMMENDED)。
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サーバのハードウェアアドレスで設定されていなければならない (MUST) ことを意味します。
HARP clients MUST:
HARPクライアントは以下を行わなければなりません (MUST):
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. インターフェースが有効化された場合（例: IPアドレスを指定して "ifconfig <interface> up"）、または最初もしくは追加のIPアドレス（すなわちIPエイリアス）が割り当てられた場合、クライアントは登録フェーズを開始しなければなりません (SHALL)。
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メッセージに応答しなければなりません (MUST)。インターフェースに複数のIPアドレス（例: IPエイリアス）がある場合、クライアントはすべてのIPアドレスを巡回し、各アドレスに対してInHARP_REPLYを生成しなければなりません (MUST)。その場合、InHARP_REQUESTには複数の応答が発生します（RFC-1293 [7]のセクション7「Protocol Operation」を参照）。
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_REPLYは、自身のクライアントHARPテーブルエントリを更新およびリフレッシュするために使用しなければなりません (SHALL)。
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.
説明：これにより、HARPサーバーは、サーバーのマッピングの1つが変更されたときにクライアントを更新できます。
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. 必要に応じてInHARP_REQUESTメッセージを生成・送信し、InHARP_REPLYメッセージを適切に処理します（セクション5.1.2および5.6を参照）。すべてのInHARP_REPLYメッセージは、クライアントが自身のHARPテーブルエントリを構築または更新するために使用しなければなりません (SHALL)（[7]のセクション7「Protocol Operation」を参照）。
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.
登録フェーズでハードウェアがブロードキャストをサポートしていないことが示された場合、クライアントは登録フェーズ中に作成されたHARPサーバに関する自身のエントリを少なくとも15分に1回更新しなければなりません (MUST)。これは、HARPサーバとのHARP要求/応答の交換を介して、またはステップ1を繰り返すことによって達成できます。冗長なネットワークトラフィックを削減するために、このタイムアウトはHARP_REQUEST/HARP_REPLYの交換ごとにリセットされるべきです (SHOULD)。
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操作は要求されません (NOT REQUIRED)。
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メッセージを受信した場合、そのメッセージを適切に破棄して通常の動作を継続しなければなりません (MUST)。HARPクライアントは、未定義のメッセージの送信者に対していかなるメッセージも返すことは要求されません (NOT REQUIRED)。
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接続を受け入れなければなりません (MUST)。HARPサーバは、クライアントからの最初のメッセージとしてInHARP_REQUESTを期待します。サーバはIP送信元アドレス、InHARP_REQUESTのハードウェア送信元アドレスを検査し、タイムスタンプとともにそのHARPテーブルエントリ <IPアドレス, スイッチアドレス, 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_REQUESTおよびInHARP_REQUESTに応答しなければなりません (SHALL)。HARPサーバは、テーブル内に要求された情報がある場合はHARP_REPLYまたはInHARP_REPLYで応答しなければならず (SHALL)、そうでない場合はHARP_NAKで応答しなければなりません (SHALL)。HARPサーバの応答には、要求のハードウェアタイプおよび対応するフォーマットが含まれていなければなりません (SHALL)（セクション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エントリが作成されなければなりません (SHALL)。要求元のIPアドレスは、元のHWエントリから新しいエントリへと移動されなければなりません (SHALL)（上記参照）。
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テーブルエントリのタイムアウトを更新しなければなりません (MUST)。説明: クライアントがサーバにHARP要求を送信している場合、サーバはクライアントのHARPテーブルエントリのタイムアウトを更新することにより、クライアントがまだ「生存」していることに留意すべきです (SHOULD)。
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_REPLYを送信するためにPIBES（セクション7を参照）を使用すべきです (SHOULD)。この機能により、クライアントにおける古いエントリの保持時間が短縮されます。
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ステーションは、自身が持つ永続エントリを決定するためのメカニズム（例: 手動設定）を持たなければなりません (MUST)。そのメカニズムの詳細は本文書の範囲外です。永続エントリにより、動的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_REQUESTを解決するために静的エントリを使用すべきです (SHOULD)。この機能により、クライアントポート側で静的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.
IPアドレス（特にIPエイリアス）やインターフェース（そのULAを含む）は移動する可能性があるため、HARPテーブルのエージングはサポートされなければなりません (MUST)。移動が発生すると、クライアント自身のHARPテーブル/キャッシュ内のマッピングは無効かつ古いものになります。
o When a client's HARP table entry ages beyond 15 minutes, a HARP client MUST invalidate the table entry.
o クライアントのHARPテーブルエントリが15分を超えてエージングした場合、HARPクライアントはそのテーブルエントリを無効化しなければなりません (MUST)。
o When a server's HARP table entry ages beyond 20 minutes, the HARP server MUST delete the table entry.
o サーバのHARPテーブルエントリが20分を超えてエージングした場合、HARPサーバはそのテーブルエントリを削除しなければなりません (MUST)。
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テーブルエントリがエージングする前にそれを再検証すべきであり (SHOULD)、テーブルエントリが正常に再検証された時点でエージング時間を再開します。テーブルエントリがエージングしていない限り、クライアントは再検証の進行中もこのエントリが参照するポートへトラフィックを送信し続けてもよいです (MAY)。クライアントは、このエントリが参照するポートへアドレス解決以外のトラフィックを送信する前に、エージングしたエントリを再検証しなければなりません (MUST)。
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「host not found」）、関連付けられたテーブルエントリは削除されます。アドレス解決サービスが利用できない場合（すなわち「server failure」）、クライアントは問題のエントリのハードウェアアドレスにInHARP_REQUESTを送信し、InHARP_REPLYの受信時にエントリを更新することによってエントリの再検証を試みなければなりません (MUST)。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「IP over HIPPI」[15]で定義されているように設定されます。以下のセクションでは、HIPPI-LEフィールドの内容ならびにHARPメッセージの構造および内容について詳述します。ブロードキャスト対応ネットワークでは、クライアントはタイプ1および6（イーサネットおよびIEEE 802 ARPパケットフォーマット）もサポートしてもよいです (MAY)。
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メッセージの長さは、HIPPI-LEによって要求されるとおり8バイトの倍数でなければなりません。HARPおよびInHARPの要求および応答のHIPPI-LEヘッダーフィールドは以下でなければなりません (SHALL):
FC (3 bits) SHALL contain zero.
FC（3ビット）にはゼロを含めなければなりません (SHALL)。
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.
Double-wideはHIPPI-LE [3]に従って設定されるべきです (SHOULD)。本文書では、ポートが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_Typeには、データメッセージを示す0を含めなければなりません (SHALL)。HARPメッセージは、EthertypeおよびHARPメッセージのar$opフィールド内のメッセージタイプを使用して識別されます。
Destination_Switch_Address, SHALL be the Switch Address of the destination port.
Destination_Switch_Addressは、宛先ポートのスイッチアドレスでなければなりません (SHALL)。
Destination_IEEE_Address SHALL be the ULA of the destination port, if known, otherwise zero.
Destination_IEEE_Addressは、既知の場合は宛先ポートのULA、そうでない場合はゼロでなければなりません (SHALL)。
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は、12ビット論理アドレスである2でなければなりません (SHALL)。type = 1（ソースルーティング）の場合の動作は、本仕様では定義されていません。
Source_Switch_Address in requests SHALL be the sender's Switch Address.
要求におけるSource_Switch_Addressは、送信者のスイッチアドレスでなければなりません (SHALL)。
Source_IEEE_Address SHALL be the sender's ULA if known, otherwise zero.
Source_IEEE_Addressは、既知の場合は送信者のULA、そうでない場合はゼロでなければなりません (SHALL)。
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は、12ビット論理アドレスである2でなければなりません (SHALL)。type = 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の最初のバイトから開始しなければなりません (SHALL)。
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値は、SNAPヘッダーの存在を示す0xAA-AA-03（3バイト）でなければなりません (SHALL)。
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) indicating that the following two-bytes is an Ethertype.
組織コードのOUI値は、後続の2バイトがEthertypeであることを示す0x00-00-00（3バイト）でなければなりません (SHALL)。
The Ethertype value SHALL be set as defined in Assigned Numbers [16]: InHARP = InARP = HARP = ARP = 2054 = 0x0806.
Ethertype値は、Assigned Numbers [16]で定義されているように設定しなければなりません (SHALL): InHARP = InARP = HARP = ARP = 2054 = 0x0806。
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 PDUSのヒッピルヘッダー：
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
"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でなければなりません (SHALL)。[FILL]バイトはHIPPIメッセージを32ビットワードの偶数個に補完します。フィルバイト数はデータ長にはカウントされません。
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を含まなければならない (SHALL) 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 Standard 802.1A [11]は、Universal LAN MACアドレスフォーマットを規定しています。48ビット空間のグローバルに一意な部分はIEEEによって管理されています。HIPPI-SC LAN上の各ポートにはULAが割り当てられるべきです (SHOULD)。ポートに複数のIEEE 802.2 LLCプロトコルエンティティが含まれる場合は、複数のULAが使用されてもよいです。
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:
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 bit）= 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.
ULAの使用は任意 (OPTIONAL) ですが、推奨されます (RECOMMENDED)。ポートが従来のネットワークと相互運用することを望む場合、ULAの使用が要求されます (REQUIRED)。
ULAs may also be used by bridging devices that replace HIPPI hardware headers with the MAC headers of other LANs.
ULASは、Hippiハードウェアヘッダーを他のLANのMacヘッダーに置き換えるブリッジングデバイスでも使用できます。
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 $ PRO）、および操作コード（AR $ OP）データ形式をARPとして使用し、ARP [15,7]を使用します。さらに、HARPは[12]で導入されたARP_NAKの追加操作コードを使用しています。HARP/InHARPメッセージ形式の残りは、[15,7,10]で定義されているARP/InARPメッセージ形式とは異なり、最初の「HIPPIのIPとARP」RFC-1374 [RFC-1374で定義された形式とも異なります。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メッセージは、HIPARPハードウェアタイプコード28（10進数）で送信しなければなりません (SHALL)。さらに、HARPメッセージは、28、1、または6（10進数）のいずれかのハードウェアタイプコードで受信された場合に受け入れられなければなりません (SHALL)。
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
Where : ar$hrd - SHALL contain 28. (HIPARP)
ここで: ar$hrd - 28を含まなければなりません (SHALL)。（HIPARP）
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$pro - IPプロトコルコード2048（10進数）を含まなければなりません (SHALL)。
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$pln - SHALL contain 4.
ar$pln - 4を含まなければなりません (SHALL)。
ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 6.
ar$rln - これがHIPPI-800 HWアドレスである場合は10を含まなければならず (SHALL)、そうではなくHIPPI-6400の場合は6を含まなければなりません (SHALL)。
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アドレスである場合は10を含まなければならず (SHALL)、そうではなくHIPPI-6400の場合は6を含まなければなりません (SHALL)。
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アドレスを含まなければなりません (SHALL)。応答ではターゲットポートのHWアドレスを含まなければなりません (SHALL)。
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 - 要求およびNAKでは既知の場合は要求元のIPアドレス、そうでない場合はゼロを含まなければなりません (SHALL)。他の応答ではターゲットポートのIPアドレスを含まなければなりません (SHALL)。
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$tha - 要求およびNAKでは既知の場合はターゲットのHWアドレス、そうでない場合はゼロを含まなければなりません (SHALL)。他の応答では要求元のHWアドレスを含まなければなりません (SHALL)。
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 - 要求およびNAKでは既知の場合はターゲットのIPアドレス、そうでない場合はゼロを含まなければなりません (SHALL)。他の応答では要求元のIPアドレスを含まなければなりません (SHALL)。
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.
ULAの6バイトのフォーマットは、ARPとHIPPI-LEとの間で異なる32ビットHIPPIワードに関するULAの整列を除き、HIPPI-LEヘッダーで要求されるものと同じでなければなりません (SHALL)（セクション6.2を参照）。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
6.3.1 Example Message encodings:
6.3.1 メッセージメッセージのエンコーディング：
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_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
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_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
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は実装されなければなりません (MUST)。
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つ、メッセージのソースに2つ、リクエスター用に3つ、ターゲットに3つのアドレスが含まれています。
Destination Switch Address (HIPPI-LE) Destination ULA (HIPPI_LE)
宛先スイッチアドレス（hippi-le）宛先ULA（HIPPI_LE）
Source Switch Address (HIPPI-LE)
Source ULA (HIPPI-LE)
Requester IP Address (HARP)
Requester ULA (HARP)
Requester Switch Address (HARP)
Target IP Address (HARP)
Target ULA (HARP)
Target Switch Address (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
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ブロードキャストエミュレーションサーバを通じてブロードキャストをエミュレートしなければなりません (MUST)。
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により、一般的な上層ネットワーキングプロトコル（RIP、TCP、UDPなど）がIP LISブロードキャストにアクセスできます。
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テーブルをターゲットリストと呼ばれるアドレスリストとして使用しなければなりません (SHALL)。ブロードキャストサーバは、すべての着信メッセージがターゲットリスト内のアドレスに対応する送信元アドレスを持っていることを検証しなければなりません (SHALL)。IP LISブロードキャストアドレス、マルチキャストアドレス、または255.255.255.255宛てのメッセージのみがブロードキャスト用の有効なメッセージとみなされます。無効なメッセージは破棄されなければなりません (MUST)。すべての有効な着信メッセージは、ターゲットリスト内のすべてのアドレスに転送されるものとします。
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サーバと同じポートで実行されることが推奨されます (RECOMMENDED)。ブロードキャストアドレスとして使用するデフォルトアドレスは、運用中の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ブロードキャストアドレスを使用しなければなりません (SHALL)。
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サーバと同じポートで実行されることが推奨されます (RECOMMENDED)。その場合、PIBESはHARPサーバと同じアドレスを使用しなければなりません (SHALL)。
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はマルチキャストアドレスを直接サポートしていないため、IPマルチキャストアドレスからHIPPIマルチキャストサービスまで利用可能なマッピングはありません。現在のIPマルチキャストの実装（つまり、MBONEおよびIPトンネリング、[9]を参照）は、すべてのIPマルチキャストパケットが255.255.255.255に送信されているかのようにすべてのIPマルチキャストパケットを使用して送信された場合、HIPPIベースの論理IPサブネットを引き続き動作します。
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では、そのようなサービスがブロードキャストできる帯域幅の上限は次のとおりです。
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を説明してから、すべてのNポートに送信する必要があります。ブロードキャストサーバーは、内部で実行されるポートに運命づけられているメッセージを転送することができ、最初の最適化で（n 1）に（n）に削減できます。
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]
8スケジュールされた転送プロトコルのハープ[17]
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は、IPの代わりにHIPPI-800を介してスケジュールされた転送（STP）で使用されるアドレスの解決にも適用されます。このRFCのメッセージタイプとアルゴリズムは、すべてのポートにHIPPIを介したIPを介してIPがある限り、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.
ポートはこのスイッチアドレス検出プロトコルを実装することは要求されません (NOT REQUIRED) が、管理オーバーヘッドを削減できるため実装することが推奨されます。本セクションで提示するアルゴリズムは、RFC-1374 [14]で詳述されているJohn Renwickの成果に基づいています。検出プロセスの概念は、考えられるすべてのスイッチアドレスをスキャンすることです。受信されるメッセージは、自身のスイッチアドレスの1つを含むメッセージとなります。
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メッセージを形成しなければなりません (SHALL)。これにはSelf_Address_Resolution_Request（[3]を参照）PDUタイプ、Source_IEEE_AddressおよびDestination_IEEE_Address（送信者の正しいULAに設定）、ならびに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 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
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.
ポートは設定可能な論理アドレス（デフォルト0x000）でスキャンを開始し、その後の試行ごとに値を1ずつインクリメントしなければなりません (SHALL)。ポートは自身の自己アドレス解決要求を確認するか、あるいは設定可能な別の値（デフォルト0xFFF）である末尾に達するまで継続しなければなりません (SHALL)。一部のネットワークにはHIPPI-LEメッセージを適切に処理しない機器が存在するため、スキャンするアドレスの範囲は設定可能であることが推奨されます (RECOMMENDED)。
After a port sends the[se] request[s], two positive outcomes are possible:
ポートが[se]リクエストを送信した後、2つの肯定的な結果が可能です。
o the port receives its own request(s), and obtains one of its own Switch Address, or
o ポートは独自の要求を受け取り、独自のスイッチアドレスの1つを取得するか、
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のハープの例
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).
Hippi-SCスイッチが3つの接続されたポートでインストールされていると仮定します：x、y、およびa。各ポートには、スイッチアドレス（SWX、SWY、SWAなど）とユニークなULA（Ulax、Ulay、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の両方に、インターフェイスが下に構成されています。
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、ETHERTYPE、HIPPI-LEメッセージタイプ、ar $ hrd、ar $ pro、ar $ plnフィールドは、一定であるため、以下の例から除外されています。同様に、ar $ rhl = ar $ thl = 9はすべてhippi-800の例であるため省略されています。
Port Y starts: its HARP table entry state for the server: PENDING
ポートYの開始：サーバーのハープテーブルエントリ状態：保留中
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
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 Serverは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
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テーブルエントリは、有効な状態に渡され、通常の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のハープテーブルエントリ状態：保留中
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
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 ynharp_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ハードウェアの両方で同じです。この例のHRALの権威あるアドレスは、単純な理由でHWA：<SWA、ULAA>およびIPSです。
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,
ポートXで同じプロセス（セクション10.1のステップ1〜3）が発生したと仮定します。XとYの表の状態は次のとおりです。HARPサーバーテーブルエントリは有効な状態にあります。XがYにメッセージを送信しようとしたときにメッセージトラフィックを見てみましょう。Xは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
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
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
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サーバーテーブルエントリの状態は次のとおりです。そのため、XがQにメッセージを送信しようとしたときにメッセージトラフィックを見てみましょう。さらに、インターフェイス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
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.
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-Serial）。
[6] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[6] Braden, R.、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[7] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[7] Bradely, T. and C. Brown、「逆アドレス解決プロトコル」、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, Steven M.、「TCP/IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、Vol。19、第2号、pp。32-48、1989。
[9] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[9] Deering, 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] Finlayson, R., Mann, T., Mogul, J. and M. Theimer、「A Reverse Address Resolution Protocol」、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] Laubach、Mark。、「Classical IP and ARP Over ATM」、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] Plummer, D.、「イーサネットアドレス解像度プロトコル - または - ネットワークアドレスをイーサネットハードウェア上の送信用の48ビットイーサネットアドレスに変換する」、RFC 826、1982年11月。
[14] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[14] Renwick, J. and A. Nicholson、「IP and ARP on Hippi」、RFC 1374、1992年10月。
[15] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[15] Renwick, J.、「IP Over Hippi」、RFC 2067、1997年1月。
[16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[16] Reynolds, J. and J. Postel、「割り当てられた番号」、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] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
このメモは、グレッグ・チェッソン、カーリン・オットー、シリコングラフィックスの高性能相互接続グループ（特にジム・ピンカートン、ブラッド・ストランド、ジェフ・ヤング）、およびANSI T11.1タスクグループの専門知識から批判的なレビューなしで存在することはできませんでした。Hippi Standardsの作業。
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]の第2部に基づいています。Dave Plummerとinverse Arp [7]によって書かれたArp [13] T. BradleyとC. Brownによって書かれた著者は、このメモに示されているHarpの基本的なアルゴリズムを提供します。さらに、HARPサーバーは、HARPサーバーの構造的基礎を築いたMark Laubachによって書かれた[12]で提示された概念とモデルに基づいています。
15 Changes from RFC-1374 [14]
RFC-1374からの15の変更[14]
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を残しました。このメモは、特にHIPPI-6400との前方の相互運用性を考慮して、RFC-1374で見つかった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.
o HIPPIハードウェアアドレス形式を確認し、HARPが機能するためのHippi-le ARPの要件を排除するための新しいメッセージ形式。
o Explicit registration phase.
o 明示的な登録フェーズ。
o Additional message formats: InHARP requests and replies as well as HARP_NAKs.
o 追加のメッセージ形式：HARP_NAKsと同様に、InHARPリクエストと返信。
o Details about the IP subnetwork configuration.
o IPサブネットワーク構成の詳細。
o Details about table aging.
o テーブル老化の詳細。
o IP broadcast emulation.
o IPブロードキャストエミュレーション。
16 Author's Address
16著者の住所
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94043
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View、CA 94043
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org
17 Full Copyright Statement
17完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。