[要約] RFC 2835は、HIPPI-6400（GSN）上でのIPとARPの実装に関する標準仕様です。このRFCの目的は、HIPPI-6400ネットワーク上でのIPとARPの適切な動作を確保するためのガイドラインを提供することです。
Network Working Group J.-M. Pittet
Request for Comments: 2835 Silicon Graphics Inc.
Category: Standards Track May 2000
IP and ARP over HIPPI-6400 (GSN)
HIPPI-6400（GSN）を超えるIPとARP
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
概要
The ANSI T11.1 task force has standardized HIPPI-6400 also known as Gigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified in HIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3].
ANSI T11.1タスクフォースは、ギガバイトシステムネットワーク（GSN）としても知られるHIPPI-6400を標準化しました。方向ごとに6400 Mbit/sで。最大40 mの距離の平行銅ケーブルインターフェイスは、HIPPI-6400-PHで指定されています[1]。長距離光学界面への接続は、HIPPI-6400-OPTで標準化されています[3]。
HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs [10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2]. T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI-6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks.
HIPPI-6400-PH [1]は、IEEE 802.2 LLC PDUS [10]のカプセル化を定義し、含意によりGSNのIPを定義します。別のT11.1標準では、HIPPI-6400物理スイッチの動作HIPPI-6400-SCを説明しています[2]。T11.1は、HIPPI-6400のネットワーキングの問題を主に標準の範囲外に残すことを選択しました。このドキュメントは、IPローカルエリアネットワークとしてのHIPPI-6400スイッチの使用を指定しています。このドキュメントはさらに、HIPPI-6400ハードウェアアドレス（HARP）にIPアドレスを解決し、HARPの直接拡張として論理IPサブネット（LIS）でIPブロードキャストをエミュレートする方法を指定します。さらに、このメモの目標であり、HIPPI-800およびHIPPI-6400機器の相互運用性を放送および非ブロードキャストの両方の能力ネットワークの両方の相互運用性を可能にするIPとHARPを定義する目標です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Global concepts used . . . . . . . . . . . . . . . . 3
2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
3. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
3.1 Background . . . . . . . . . . . . . . . . . . . . . 5
3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
4. Internet Protocol . . . . . . . . . . . . . . . . . . . . 7
4.1 Packet Format . . . . . . . . . . . . . . . . . . . 7
4.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 7
4.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 Packet diagrams . . . . . . . . . . . . . . . 8
4.2 HIPPI-6400 Hardware address: Universal LAN MAC addr. 9
4.3 Maximum Transmission Unit - MTU . . . . . . . . . . 10
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 11
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 12
5.1.1 Selecting the authoritative HARP service . . . 12
5.1.2 HARP registration phase . . . . . . . . . . . 13
5.1.3 HARP operational phase . . . . . . . . . . . . 14
5.2 HARP Client Operational Requirements . . . . . . . . 15
5.3 Receiving Unknown HARP Messages . . . . . . . . . . 16
5.4 HARP Server Operational Requirements . . . . . . . . 16
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 18
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 18
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 19
6.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 19
6.2 HIPARP Message Formats . . . . . . . . . . . . . . . 21
6.2.1 Example Message encodings: . . . . . . . . . . 23
6.2.2 HARP_NAK message format . . . . . . . . . . . . 24
7. Broadcast and Multicast . . . . . . . . . . . . . . . . 24
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 25
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 25
7.4 A Note on Broadcast Emulation Performance . . . . . . 26
8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 26
9. Security Consierations . . . . . . . . . . . . . . . . . 26
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 27
11. HARP Examples . . . . . . . . . . . . . . . . . . . . . 27
11.1 Registr. Phase of Client Y on Non-broadcast Hardware 27
11.2 Registr. Phase of Client Y on Broadcast-capable . . 28
11.3 Operational Phase (phase II) . . . . . . . . . . . 29
11.3.1 Successful HARP_Resolve example . . . . . . 29
11.3.2 Non-successful HARP_Resolve example . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32
14. Author's Address . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . 33
HIPPI-6400 is a duplex data channel that can transmit and receive data simultaneously at nearly 6400 megabits per second. HIPPI-6400 data transfers are segmented into micropackets, each composed of 32 data bytes and 8 control bytes. HIPPI-6400 uses four multiplexed virtual channels. These virtual channels are allocated to control traffic, low latency traffic, and bulk traffic (see [1] for more details).
HIPPI-6400は、1秒あたり6400メガビットで同時にデータを送信および受信できる二重データチャネルです。HIPPI-6400データ転送は、それぞれ32のデータバイトと8つの制御バイトで構成されるマイクロパケットにセグメント化されています。HIPPI-6400は、4つの多重化された仮想チャネルを使用しています。これらの仮想チャネルは、トラフィック、低遅延トラフィック、およびバルクトラフィックを制御するために割り当てられます（詳細については[1]を参照）。
Using small packets and four virtual channels, large file transfers cannot lock out a host or switch port for interactive traffic. HIPPI-6400 guarantees in order delivery of data. It also supports link-level and end-to-end checksumming and credit-based flow control.
小さなパケットと4つの仮想チャネルを使用して、大きなファイル転送は、インタラクティブなトラフィック用のホストまたはスイッチポートをロックアウトできません。HIPPI-6400は、データの配信の順序で保証されています。また、リンクレベルとエンドツーエンドのチェックサムとクレジットベースのフロー制御もサポートしています。
HIPPI-6400-PH defines a 20-bit interface for copper cables operating at 500 MBaud. This provides a user payload bandwidth of 6400 Mb/s (800,000,000 Bytes/sec) in each direction. [8]
HIPPI-6400-PHは、500 Mbaudで動作する銅ケーブルの20ビットインターフェイスを定義します。これにより、各方向に6400 MB/s（800,000,000バイト/秒）のユーザーペイロード帯域幅が提供されます。[8]
HIPPI-6400-SC [2] defines two types of switches: bridging and non-bridging. The bridging switches are required to support hardware broadcast. Non-bridging switches are not required to support broadcast. This memo allows for a coherent implementation of IP and HARP with both types of switches.
HIPPI-6400-SC [2]は、ブリッジングと非ブリッジングの2種類のスイッチを定義します。ブリッジングスイッチは、ハードウェアブロードキャストをサポートするために必要です。ブロードキャストをサポートするために、非架橋スイッチは必要ありません。このメモにより、両方のタイプのスイッチを使用したIPとHARPのコヒーレントな実装が可能になります。
Gigabyte System Network(TM) (GSN) is a marketing name for HIPPI-6400. It is a trademark of the High Performance Networking Forum (HNF; http://www.hnf.org) for use by its member companies that supply products complying to ANSI HIPPI-6400 standards.
Gigabyte System Network（TM）（GSN）は、HIPPI-6400のマーケティング名です。これは、ANSI HIPPI-6400基準に準拠した製品を提供するメンバー企業が使用するための、高性能ネットワーキングフォーラム（hnf; http://www.hnf.org）の商標です。
2 Definitions
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 [19].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC-2119 [19]に記載されているように解釈される。
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. This document will use HIPPI-800 and HIPPI-6400 when referring to concepts that apply to one or the other technology. The term HIPPI will be used when referring to both technologies.
次の議論では、「リクエスター」と「ターゲット」という用語を使用して、アドレス解決要求を開始するポートと、それぞれアドレスを発見したいポートを識別します。このドキュメントは、いずれかのテクノロジーに適用される概念を参照する場合、HIPPI-800とHIPPI-6400を使用します。HIPPIという用語は、両方のテクノロジーを参照するときに使用されます。
Values are decimal unless otherwise noted. Formatting follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and byte ordering.
特に明記しない限り、値は10進数です。フォーマットは、IEEE 802.1a Canonical Bit OrderおよびHIPPI-6400-PH-PHビットおよびバイト順序に従います。
Broadcast
放送
A distribution mode which transmits a message to all ports. The sending port is part of "all" and will therefore also receive a copy of the sent message.
すべてのポートにメッセージを送信する配布モード。送信ポートは「All」の一部であるため、送信されたメッセージのコピーも受け取ります。
Classical/Conventional
クラシック/従来
Both terms are used with respect to networks, including 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 (HIPPI Address Resolution Protocol describes the whole set of HIPPI-6400 address resolution encodings and algorithms defined in this memo. HARP is a combination and adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 [14] and Inverse ARP (InARP) [5] (see section 5). HARP also describes the HIPPI (800 and 6400) specific version of ARP (i.e. the protocol and the HIPPI specific encoding).
HARP（HIPPIアドレス解像度プロトコルは、このメモで定義されているHIPPI-6400アドレス解像度エンコーディングとアルゴリズムのセット全体を説明します。HARPは、インターネットアドレス解像度プロトコル（ARP）RFC-826 [14]および逆ARP（inARPの組み合わせと適応です。）[5]（セクション5を参照）。HARPは、ARPのHIPPI（800および6400）特定のバージョン（つまり、プロトコルとHIPPI固有のエンコード）についても説明しています。
HARP table
ハープテーブル
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
各ホストには、IPメンバーのハードウェアアドレスアドレスマッピングを含むHARPテーブルがあります。
HRAL
hral
The HARP Request Address List. A list of ULAs to which HARP messages are sent when resolving names to addresses (see section 3.2).
HARPリクエストアドレスリスト。アドレスに名前を解決するときにHARPメッセージが送信されるULAのリスト（セクション3.2を参照）。
Hardware (HW) address
ハードウェア（HW）アドレス
The hardware address of a port; it consists of an ULA (see section 4.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.
ポートのハードウェアアドレス。ULAで構成されています（セクション4.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. A port may be an Internet host, bridge, router, or gateway.
並列またはシリアルHIPPIによってHIPPI-SCスイッチに接続され、IPデータグラムを送信および受信する1つのHIPPIソース/宛先デュアルシンプレックスペアで構成されるエンティティ。ポートは、インターネットホスト、ブリッジ、ルーター、またはゲートウェイです。
PIBES
パイブ
The Protocol for Internet Broadcast Emulation Server (see section 7).
インターネットブロードキャストエミュレーションサーバーのプロトコル（セクション7を参照）。
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 [14] 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-6400 network.
[14]で定義されているARP（アドレス解像度プロトコル）は、「ローカル」ケーブルで作業することを目的としていました。この定義により、ARPプロトコルはローカル論理IPサブネット（LIS）スコープを提供します。LISシナリオでは、それぞれの個別の管理エンティティがLIS内のホストとルーターを構成します。各LIは、同じHIPPI-6400ネットワーク上で他の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-6400 port attached to the HIPPI-6400 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-6400 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-6400 connection between the two IP members over the HIPPI-6400 network. This is an consequence of using IP and choosing to have multiple LIS's on the same HIPPI-6400 fabric.
HarpにはLISスコープのみがあり、LISのすべてのポートにサービスを提供しています。ローカルLISの外側にあるポートへの通信は、通常、IPルーターを介して提供されます。このルーターは、1つ以上のLISのメンバーとして構成されているHIPPI-6400ネットワークに接続されたHIPPI-6400ポートです。この構成により、同じHIPPI-6400ネットワークを介した多くの馬鹿げたLISが動作する可能性があります。このモデルを使用して、異なるIPサブネットのポートは、HIPPI-6400ネットワークを介して2つのIPメンバー間で直接HIPPI-6400接続を開くことができる場合でも、中間IPルーターを介して通信する必要があります。これは、IPを使用し、同じHIPPI-6400ファブリックに複数の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メンバークライアントが利用できる必要があります。
The requirement for IP members (hosts, routers) operating in a HIPPI-6400 LIS configuration is:
HIPPI-6400 LIS構成で動作するIPメンバー（ホスト、ルーター）の要件は次のとおりです。
o All members of the LIS SHALL have the same IP network/subnet address and address mask [4].
o LISのすべてのメンバーは、同じIPネットワーク/サブネットアドレスとアドレスマスクを持っている必要があります[4]。
The following list identifies the set of HIPPI-6400-specific parameters that MUST be implemented in each IP station connected to the HIPPI-6400 network:
次のリストは、HIPPI-6400ネットワークに接続された各IPステーションに実装する必要があるHIPPI-6400固有のパラメーターのセットを識別します。
o HIPPI-6400 Hardware Address:
o HIPPI-6400ハードウェアアドレス：
The HIPPI-6400 hardware address (a ULA) of an individual IP endpoint (i.e. a network adapter within a host) MUST be unique in the LIS.
個々のIPエンドポイント（つまり、ホスト内のネットワークアダプター）のHIPPI-6400ハードウェアアドレス（ULA）は、LISで一意でなければなりません。
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クライアントは同じように構成する必要があります。つまり、すべてのポートはHralに同じアドレス（ES）を持っている必要があります。
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. By default the first address MUST be the reserved address for broadcast, i.e. FF:FF:FF:FF:FF:FF.
HRALには、LIS内にあるすべてのIPメンバーのHARPリクエストを解決する権威ある責任を負う個々のHARPサービスを特定する少なくとも2つのHIPPI HWアドレスを含める必要があります。デフォルトでは、最初のアドレスは放送の予約アドレスでなければなりません。つまり、FF：FF：FF：FF：FF：FF。
The second address MUST be the standard HW address for the HARP server 00:10:3B:FF:FF:E0.
2番目のアドレスは、HARPサーバー00：10：3B：FF：FF：E0の標準HWアドレスでなければなりません。
Therefore, the HRAL entries are sorted in the following order: 1st : broadcast address (FF:FF:FF:FF:FF:FF) REQUIRED 2nd : official HARP server address (00:10:3B:FF:FF:E0) REQUIRED 3rd & on: any additional HARP server addresses will be OPTIONAL sorted in decreasing order.
したがって、Hralエントリは次の順序でソートされます：1つ：ブロードキャストアドレス（FF：FF：FF：FF：FF：FF）が2番目：公式HARPサーバーアドレス（00：10：3B：FF：FF：E0）が必要です3番目とON：追加のHARPサーバーアドレスは、順序を減少させてオプションでソートされます。
Manual configuration of the addresses and address lists presented in this section is implementation dependent and beyond the scope of this memo. However, prior to use by any service or operation detailed in this memo, clients MUST have HRAL address(es) configured as appropriate for their LIS.
このセクションで表示されているアドレスとアドレスリストの手動構成は、このメモの範囲を超えて実装に依存します。ただし、このメモで詳述されているサービスまたは操作が使用する前に、クライアントはLISに適したHralアドレスを構成する必要があります。
The HIPPI-6400 packet format for Internet datagrams [15] shall conform to the HIPPI-6400-PH standard [1]. The length of a HIPPI-6400-PH packet, including headers and trailing fill, shall be a multiple of 32 bytes as required by HIPPI-6400-PH.
インターネットデータグラムのHIPPI-6400パケット形式[15]は、HIPPI-6400-PH標準[1]に準拠するものとします。ヘッダーやトレーリングフィルを含むHIPPI-6400-PHパケットの長さは、HIPPI-6400-PHで必要とされる32バイトの倍数でなければなりません。
All IP Datagrams shall be carried on HIPPI-6400-PH Virtual Channel 1 (VC1). Since HIPPI-6400-PH has a 32-byte granularity, IP Datagrams MUST be padded to a 32-byte granularity prior to sending. Added padding is transparent to IP and is not reflected in the length field of the IP header.
すべてのIPデータグラムは、HIPPI-6400-PH仮想チャネル1（VC1）で携帯するものとします。HIPPI-6400-PHには32バイトの粒度があるため、IPデータグラムは、送信する前に32バイトの粒度にパッドで埋めなければなりません。追加されたパディングはIPに対して透明であり、IPヘッダーの長さフィールドに反映されません。
D_ULA Destination ULA SHALL be the ULA of the destination port.
D_ULA Destination ULAは、宛先ポートのULAでなければなりません。
S_ULA Source ULA SHALL be the ULA of the requesting port.
S_ULAソースULAは、リクエストポートのULAでなければなりません。
M_len Set to the IEEE 802 packet (e.g. IP or HARP message) length + 8 Bytes to account for the LLC/SNAP header length. The HIPPI-6400-PH [1] length parameter shall not include the pad.
M_Lenは、LLC/SNAPヘッダーの長さを考慮するために、IEEE 802パケット（IPまたはHARPメッセージなど）の長さ8バイトに設定します。HIPPI-6400-PH [1]長さパラメーターには、パッドを含めてはなりません。
The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len.
IEEE 802.2 LLCヘッダーは、M_LENの後に最初のバイトで開始するものとします。
The LLC values (in hexadecimal and decimal) SHALL be
LLC値（16進数および10進数）
SSAP 0xAA 170 (8 bits)
DSAP 0xAA 170 (8 bits)
CTL 0x03 3 (8 bits)
for a total length of 3 bytes. The 0x03 CTL value indicates the presence of a SNAP header.
合計3バイトの長さ。0x03 CTL値は、スナップヘッダーの存在を示します。
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) indicating that the following two-bytes is an Ethertype.
組織コードのOUI値は0x00-00-00（3バイト）でなければなりません。これは、次の2バイトが倫理であることを示しています。
The Ethertype value SHALL be set as defined in Assigned Numbers [18]:
EtherType値は、割り当てられた数字[18]で定義されているように設定するものとします。
IP 0x0800 2048 (16 bits) HARP = ARP = 0x0806 2054 (16 bits)
IP 0x0800 2048（16ビット）harp = arp = 0x0806 2054（16ビット）
The total size of the LLC/SNAP header is fixed at 8 bytes.
LLC/SNAPヘッダーの合計サイズは8バイトに固定されています。
The following diagram shows a HIPPI-6400 message carrying IEEE 802 data.
次の図は、IEEE 802データを運ぶHIPPI-6400メッセージを示しています。
|31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------
0 | |
| D_ULA +-------------------------+ HIPPI-6400
1 | | |
+-------------------------+ S_ULA | MAC
2 | |
+---------------------------------------------------+ header
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | DSAP | SSAP | Ctl | Org | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP
5 | Org | Org | Ethertype | header
+============+============+============+============+ =============
6 | Msg byte 0 | Msg byte 1 | Msg byte 2 | . . . | IEEE 802
+---------------------------------------------------+ Data
Generic 802.1 data packet diagram
The following diagram shows an IP datagram of length n with the FILL bytes ( value: 0x0 ). "<><>" indicates the micropacket separation. A HIPPI-6400-PH [1] micropacket is 32 bytes long.
次の図は、塗りつぶしバイト（値：0x0）を持つ長さnのIPデータグラムを示しています。「<> <>」は、マイクロパケットの分離を示します。HIPPI-6400-PH [1]マイクロパケットの長さは32バイトです。
All IP (v4) [15] packets will always span two or more micropackets. The first micropacket has a TYPE = header. The second and any further micropackets have a TYPE = Data (see [1]).
すべてのIP（V4）[15]パケットは、常に2つ以上のマイクロパケットに及びます。最初のマイクロパケットには型=ヘッダーがあります。2番目とその他のマイクロパケットには型=データがあります（[1]を参照）。
|31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------
0 | |
| D_ULA +-------------------------+ HIPPI-6400
1 | | |
+-------------------------+ S_ULA | MAC
2 | |
+---------------------------------------------------+ header
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | AA | AA | 03 | 00 | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP
5 | 00 | 00 | Ethertype = 0x0800=2048 | header
+============+============+============+============+ =============
6 | VER | HLEN | TOS | Total Length |
+-----+------+------------+-----+-------------------+
7 | ID | FLG | Frag Offset |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header
8 | TTL | PROTO | Header Checksum |
+------------+------------+-------------------------+
9 | Source IP Address |
+---------------------------------------------------+
10 | Destination IP Address |
+---------------------------------------------------+
11 | . . . |
+---------------------------------------------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+------------+------------+------------+------------+
| FILL | FILL | FILL | FILL |
+------------+------------+------------+------------+
M-1| FILL | FILL | FILL | FILL |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+
IP v4 data packet diagram
As shown in above figure the first eight bytes of the IP Datagram occupy the last eight bytes of the HIPPI-6400-PH [1] Header micropacket.
上の図に示すように、IPデータグラムの最初の8バイトは、HIPPI-6400-PH [1]ヘッダーマイクロパケットの最後の8バイトを占めています。
HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE Standard 802.1A [10] or a subset as defined in HIPPI-6400-SC [2]. The globally unique part of the 48 bit space is administered by the IEEE. Each port on a HIPPI-6400-SC LAN MUST be assigned a ULA. Multiple ULAs may be used if a node contains more than one IEEE 802.2 LLC protocol entity.
HIPPI-6400は、IEEE標準802.1a [10]で指定されたユニバーサルLAN MACアドレスまたはHIPPI-6400-SC [2]で定義されているサブセットを使用しています。48ビットスペースのグローバルにユニークな部分は、IEEEによって管理されています。HIPPI-6400-SC LANの各ポートには、ULAを割り当てる必要があります。ノードに複数のIEEE 802.2 LLCプロトコルエンティティが含まれている場合、複数のULAが使用される場合があります。
This memo assumes the use of "Logical Addressing" as described in Annex A.2 of HIPPI-6400-SC[2].
このメモは、HIPPI-6400-SCの付録A.2に記載されている「論理アドレス指定」の使用を想定しています[2]。
The format of the address within its 48 bit HIPPI-6400-PH fields follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and byte order:
その48ビットHIPPI-6400-PHフィールド内のアドレスの形式は、IEEE 802.1A標準ビットオーダーとHIPPI-6400-PH-PHビットおよびバイトオーダーに従います。
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 | (not used for ULA) |
+---------------+---------------+---------------+---------------+
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。
Maximum Transmission Unit (MTU) is defined as the maximum length of the IP packet, including IP header, but not including any overhead below IP, i.e., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header. Conventional LANs have MTU sizes determined by physical layer specification. MTUs may be required simply because the chosen medium won't work with larger packets, or they may serve to limit the amount of time a node must wait for an opportunity to send a packet.
最大送信ユニット（MTU）は、IPヘッダーを含むIPパケットの最大長として定義されますが、IP以下のオーバーヘッド、つまりHIPPI-6400 MACヘッダーとIEEE 802 LLC/SNAPヘッダーを含めません。従来のLANは、物理層の仕様によって決定されるMTUサイズを持っています。選択したメディアが大きなパケットで動作しないという理由だけで、MTUが必要になる場合があります。または、ノードがパケットを送信する機会を待つ必要がある時間を制限するのに役立つ場合があります。
HIPPI-6400-PH [1] limits packets to about 4 gigabytes (on VC 3) which imposes no practical limit for networking purposes. HIPPI-6400-PH VC 1, which was chosen for IP and ARP traffic, limits messages to about 128 Kbytes which is still larger than the HIPPI-800 MTU [17].
HIPPI-6400-PH [1]は、パケットを約4ギガバイト（VC 3）に制限し、ネットワーキングの目的には実用的な制限を課しません。IPおよびARPトラフィックのために選択されたHIPPI-6400-PH VC 1は、HIPPI-800 MTUよりもまだ大きい約128 Kバイトにメッセージを制限します[17]。
The MTU for HIPPI-6400 LANs SHALL be 65280 (decimal) bytes.
HIPPI-6400 LANのMTUは、65280（小数）バイトでなければなりません。
This value is backwards compatible with HIPPI-800. It allows the IP packet to fit in one 64K byte buffer with up to 256 bytes of overhead. The IP v4 overhead is 24 bytes for HIPPI-6400 and 40 bytes for HIPPI-800.
この値は、hippi-800と逆方向に互換性があります。IPパケットは、最大256バイトのオーバーヘッドを持つ1つの64Kバイトバッファーに収まることができます。IP V4オーバーヘッドは、HIPPI-6400で24バイト、HIPPI-800で40バイトです。
For HIPPI-6400 the byte accounting is:
HIPPI-6400の場合、バイトアカウンティングは次のとおりです。
HIPPI-6400-PH Header 16 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes
Unused expansion room 232 bytes
------------
Total 65536 bytes (64K)
In contrast, the HIPPI-800 accounting is:
対照的に、HIPPI-800会計は次のとおりです。
HIPPI-800-FP Header 8 bytes
HIPPI-800-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Unused expansion room 216 bytes
Maximum IP packet size (MTU) 65280 bytes
------------
Total 65536 bytes (64K)
Address resolution within the HIPPI-6400 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).
HIPPI-6400 LIS内のアドレス解像度は、HIPPIアドレス解像度プロトコル（HARP）と逆HIPPIアドレス解像度プロトコル（INHARP）を利用するものとします。HARPは、インターネットアドレス解像度プロトコル（ARP）と同じ機能を提供します。
HARP is based on ARP which is defined in RFC-826 [14] except the HIPPI-6400 specific packet format. Knowing the Internet address, conventional networks use ARP to discover another node'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. InHARP is the same protocol as the original Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400 specific packet format. Knowing its hardware address, InARP is used to discover the other party's Internet address.
HARPは、HIPPI-6400固有のパケット形式を除き、RFC-826 [14]で定義されているARPに基づいています。インターネットアドレスを知っていると、従来のネットワークはARPを使用して別のノードのハードウェアアドレスを発見します。このセクションで提示されたHARPは、元のプロトコル定義の組み合わせをさらに指定して、ハードウェアのブロードキャスト機能に依存しないコヒーレントアドレス解像度サービスを形成します。INHARPは、HIPPI-6400固有のパケット形式を除き、[5]で提示された元の逆ARP（INARP）プロトコルと同じプロトコルです。ハードウェアアドレスを知っているINARPは、相手のインターネットアドレスを発見するために使用されます。
This memo further REQUIRES the PIBES (see section 7) extension to the HARP protocol, guaranteeing broadcast service to upper layer protocols like IP.
このメモでは、ハーププロトコルのパイブ（セクション7を参照）の拡張をさらに必要とし、IPのような上層層プロトコルへのブロードキャストサービスを保証します。
Internet addresses are assigned independent of ULAs. Before using HARP, each node MUST know its IP and its HW addresses. The ULA is optional but is RECOMMENDED if interoperability with conventional networks is desired.
インターネットアドレスは、ULASから独立して割り当てられます。HARPを使用する前に、各ノードはIPとHWアドレスを知っている必要があります。ULAはオプションですが、従来のネットワークとの相互運用性が必要な場合は推奨されます。
If all switches in the LIS support broadcast, then the source address in the reply will be the target's source address. If all switches in the LIS do not support broadcast, then a HARP server MUST be used to provide the address resolution service, and the source address in the reply will be the HARP server's source address.
LISサポートのブロードキャストのすべてのスイッチの場合、返信のソースアドレスがターゲットのソースアドレスになります。LIS内のすべてのスイッチがブロードキャストをサポートしていない場合、HARPサーバーを使用してアドレス解像度サービスを提供する必要があり、返信のソースアドレスはHARPサーバーのソースアドレスになります。
This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI-6400-SC networks. HARP creates a table in each port which maps remote ports' IP addresses to ULAs, so that when an application requests a connection to a remote port by its IP address, the remote ULA can be determined, a correct HIPPI-6400-PH header can be built, and a connection to the port can be established using the ULA.
このセクションでは、ブロードキャストと非放送の両方のHIPPI-6400-SCネットワークの両方でのHARP実装の動作と要件を定義します。Harpは各ポートにTableを作成し、リモートポートのIPアドレスをULASにマッピングするため、アプリケーションがIPアドレスでリモートポートへの接続を要求すると、リモートULAを決定できます。構築すると、ULAを使用してポートへの接続を確立できます。
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. To select the authoritative HARP service, each port needs to determine if it is connected to a broadcast network. At each point in time there is only one authoritative HARP service.
Hippi Lis内には、権威あるHarpサービスがあります。権威あるHARPサービスを選択するには、各ポートがブロードキャストネットワークに接続されているかどうかを判断する必要があります。それぞれの時点で、権威あるハープサービスは1つだけです。
The port SHALL send an InHARP_REQUEST to the first address in the HRAL (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（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サービスは、HRALに最初に表示されるHARPサーバーでなければなりません。
The order of addresses in 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.
権威あるHARPサーバーは、（1）クライアントによる1つ以上の登録要求（セクション5.1.2および5.2を参照）、（2）過去120秒の任意の2つのharp_requestsに返信できなかった場合、非応答性と見なされる必要があります。または（3）外部エージェントが権威あるHARPサーバーの障害を検出した場合。このような外部エージェントの詳細とHARPクライアントとの相互作用は、このドキュメントの範囲を超えています。権威あるHARPサーバーが反応しない場合、登録プロセスを再起動する必要があります。権威あるHARPサービスを選択するための代替方法は禁止されていません。
HARP clients SHALL initiate the registration phase by sending an InHARP_REQUEST message using the HRAL addresses in order. The client SHALL terminate the registration phase and transition into the operational phase, when either: (1) it receives its own InHARP_REQUEST, or (2) when it receives an InHARP_REPLY from at least one of the HARP servers and it has determined the authoritative HARP service as described in 5.1.1.
HARPクライアントは、HRALアドレスを順番に使用してINHARP_REQUESTメッセージを送信することにより、登録フェーズを開始するものとします。クライアントは、登録段階を終了し、次のいずれかの場合の運用段階に移行します。5.1.1で説明されているサービス。
When ports are initiated they send an InHARP_REQUEST to the authoritative HRAL address. The first address to be tried will be the broadcast address "FF:FF:FF:FF:FF:FF". There are two outcomes:
ポートが開始されると、権威あるHRALアドレスにINHARP_REQUESTを送信します。最初に試されるアドレスは、放送アドレス「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を受け取りません。その後、ポートはブロードキャストの有能なネットワークに接続されています。
The port SHALL choose the next address in the HRAL as a candidate for a HARP server and send an InHARP_REQUEST to that address: (00:10:3B:FF:FF:E0).
ポートは、HARPサーバーの候補としてHRALの次のアドレスを選択し、そのアドレスにINHARP_REQUESTを送信するものとします。（00：10：3B：FF：FF：E0）。
The port SHALL continue to retry each non-broadcast HARP server address in the HRAL at least once every 5 seconds until one of the following termination criteria are met for each address.
ポートは、各アドレスに対して次の終了基準のいずれかが満たされるまで、少なくとも5秒ごとにHRALの各非放送ハープサーバーアドレスを引き続き再試行します。
a. 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).
a. ポートが独自のメッセージを受信した場合、ポート自体はハープサーバーであり、ポートはパイブを使用してブロードキャストサービスを提供する必要があります（セクション7を参照）。
b. If the port receives an InHARP_REPLY, then it is a HARP client and not a HARP server. In both cases, the current candidate address becomes the authoritative HARP service address.
b. ポートがINHARP_REPLYを受信した場合、それはHARPクライアントであり、HARPサーバーではありません。どちらの場合も、現在の候補者アドレスが権威ある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プロトコルの適用です。目的は、ハードウェアブロードキャスト機能を存在または検出した場合、HARPサーバーを使用してポートIPアドレスマッピングの登録を達成することです。
If the HIPPI-6400-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-6400-SC LANがブロードキャストをサポートしている場合、クライアントは独自のINHARP_REQUESTメッセージを表示し、登録フェーズを完了します。クライアントはさらに、ブロードキャスト対応ネットワークに接続されていることに注意し、この情報を使用して、HARPサーバーエントリの老化と、それぞれセクション5.4および5.6で指定されているIPブロードキャストエミュレーションに使用します。
If the client doesn't see its own InHARP_REQUEST 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-6400-SC network.
クライアントが独自のinharp_requestを表示しない場合、登録フェーズを完了する前にinharp_replyを待つものとします。これにより、クライアントにHarpサーバーがアドレス指定できるプロトコルアドレスを提供します。これは、クライアントがたまたまブロードキャストの有能なHIPPI-6400-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 information about other IP members by sending of HARP_REQUESTs to the authoritative address in the HRAL and by receiving of HARP_REPLYs. The client is fully operational during the operational phase.
HARPクライアントが登録フェーズを完了すると、運用フェーズに入ります。プロトコルのこの段階では、HARPクライアントは、HARP_REQUESTSをHRALの権威ある住所に送信し、HARP_REPLYSを受信することにより、他のIPメンバーに関する独自のHARPテーブル情報を取得して更新するものとします。クライアントは、運用段階で完全に動作します。
In the operational phase, the client's behavior for requesting HARP resolution is the same for broadcast or non-broadcast HIPPI-6400-SC switched networks.
運用段階では、HARP解像度を要求するクライアントの動作は、ブロードキャストまたは非放送のHIPPI-6400-SCスイッチされたネットワークで同じです。
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つがリクエストに当てはまる場合、ポートはアドレス解決要求のターゲットです。
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, is in the ULA part of the Target Hardware Address field (ar$tha) of the message.
2. ポートのULAは、メッセージのターゲットハードウェアアドレスフィールド（ar $ tha）のULA部分にあります。
3. The port is a HARP server.
3. ポートはハープサーバーです。
NOTE: It is REQUIRED to have a HARP server run on a port that has a non-zero ULA.
注：ゼロ以外のULAを持つポートでHARPサーバーを実行する必要があります。
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サーバーに連絡して、独自のHARP情報を登録し、他のIPメンバーに関する独自の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. インターフェイスが有効になっている場合（たとえば、IPアドレスを使用して「ifconfig <interface> up」）、または追加の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 [5].)
2. 運用段階では、クライアントがターゲットポートである場合、harp_requestおよびinharp_requestメッセージに応答する必要があります。インターフェイスに複数のIPアドレス（IPエイリアスなど）がある場合、クライアントはすべてのIPアドレスをサイクリングし、そのようなアドレスごとにinharp_replyを生成する必要があります。その場合、inharp_requestには複数の返信があります。（RFC-1293 [5]のセクション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.
説明：これにより、HARPサーバーは、サーバーのマッピングの1つが変更されたときにクライアントを更新できます。
4. Generate and transmit InHARP_REQUEST messages as needed and process InHARP_REPLY messages appropriately (see section 5.1.3 and 5.6). All InHARP_REPLY messages SHALL be used to build/refresh its client HARP table entries. (Refer to Section 7, "Protocol Operation" in [5].)
4. 必要に応じてinharp_requestメッセージを生成および送信し、inharp_replyメッセージを適切に処理します（セクション5.1.3および5.6を参照）。すべてのinharp_replyメッセージは、クライアントのハープテーブルエントリを構築/更新するために使用するものとします。（[5]のセクション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 Exchangeの後にこのタイムアウトをリセットする必要があります。
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 showed that the underlying network supports broadcast, then the refresh sequence is 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メッセージを受信した場合、メッセージを優雅に破棄し、通常の操作を継続する必要があります。HARPクライアントは、未定義のメッセージの送信者にメッセージを返す必要はありません。
A HARP server MUST accept HIPPI-6400 connections from other HIPPI-6400 ports. The HARP server expects an InHARP_REQUEST as the first message from the client. A server examines the IP address, the hardware address of the InHARP_REQUEST and adds or updates its HARP table entry <IP address(es), ULA> as well as the time stamp.
HARPサーバーは、他のHIPPI-6400ポートからのHIPPI-6400接続を受け入れる必要があります。HARPサーバーは、クライアントからの最初のメッセージとしてINHARP_REQUESTを期待しています。サーバーは、IPアドレス、INHARP_REQUESTのハードウェアアドレスを調べ、HARPテーブルエントリ<IPアドレス（ES）、ULA>、およびタイムスタンプを追加または更新します。
A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on the information which it has in its table. The HARP server replies SHALL contain the hardware type and corresponding format of the request (see also sec. 6).
HARPサーバーは、そのテーブルにある情報に基づいて、harp_requestsおよびinharp_requestsに返信します。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:
INHARP_REQUESTのIPソースアドレスがテーブルエントリIPアドレス（IPA <-> HWAなど）を複製し、INHARP_REQUESTハードウェアソースアドレスがハードウェアアドレスエントリ（たとえばG。HWB<-> IPB）と一致する場合、それらはリンクされていません。：
- 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
- HWAエントリは、現在のIPAアドレスを削除することを参照する必要があります。-HWBはIPAを追加する新しい参照を持つ必要があります-IPAはHWBにリンクする必要があります
The result will be a table with: IPb <-> HWa <-> IPb If IPb was the only IP address referred to by the HWb entry, then delete the HWb entry.
結果は、IPB <-> HWA <-> IPBのテーブルになります。IPBがHWBエントリで言及された唯一のIPアドレスである場合、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 Requesterの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 Requesterのハードウェアソースアドレスがハードウェアソースアドレスのエントリを複製しているが、受信したIPアドレスに一致するIPエントリがない場合、IPアドレスは以前のIPアドレス（ES）のハードウェアエントリに追加されるものとします。（例：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テーブルエントリのタイムアウトを更新することにより、クライアントがまだ「生きている」ことに注意する必要があります。
A HARP server SHOULD use the PIBES (see sect. 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サーバーは、PIBE（セクション7を参照）を使用して、HARP_REPLYSをテーブル内のすべてのハードウェアアドレスに送信する必要があります。この機能は、クライアントの古いエントリの時間を短縮します。
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.
IPアドレス、特にIPエイリアス、およびインターフェイス（ULAを使用）が移動する可能性が高いため、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クライアントはテーブルエントリを無効にする必要があります。
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 the invalidated entry prior to transmitting any non-address resolution traffic to the port referred to by this entry.
注：クライアントは、高齢化する前にハープテーブルエントリを再検証する必要があります。そのため、テーブルエントリが正常に再検証された老化時間を再起動する必要があります。クライアントは、テーブルエントリが老化していない限り、再生が進行中にこのエントリで言及されたポートにトラフィックを送信し続けることができます。クライアントは、このエントリで言及されているポートにアドドレス解像度以外のトラフィックを送信する前に、無効なエントリを再確認する必要があります。
The client revalidates the entry by querying the HARP server. 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サーバーを照会することにより、エントリを再確認します。有効な返信が受信された場合（harp_replyなど）、エントリが更新されます。アドレス解像度サービスがエントリを解決できない場合（例：HARP_NAK、「ホストは見つかりません」）、関連するテーブルエントリが削除されます。アドレス解像度サービスが利用できない場合（つまり、「サーバー障害」）、クライアントは、問題のエントリのハードウェアアドレスにINHARP_REQUESTを送信し、INHARP_REPLYの受領時にエントリを更新することにより、エントリの再評価を試みなければなりません。inharp_requestの試行がinharp_replyを返すことに失敗した場合、関連するテーブルエントリが削除されます。
The HARP message is another type of IEEE 802 payload as described in section 4.1.3 above. The HIPPI-6400 HARP SHALL support two packet formats, both the generic Ethernet ARP packet and the HIPPI-800 HARP packet format defined in [13]. HARP messages SHALL be transmitted with a hardware type code of 28 on non-broadcast capable hardware or 1 in either case.
HARPメッセージは、上記のセクション4.1.3で説明されているように、IEEE 802ペイロードの別のタイプです。HIPPI-6400 HARPは、[13]で定義されているジェネリックイーサネットARPパケットとHIPPI-800 HARPパケット形式の両方の2つのパケット形式をサポートするものとします。HARPメッセージは、いずれの場合も、非放送能力のあるハードウェアまたは1で1つのハードウェアタイプのコードで送信されます。
The ar$hrd field SHALL be used to differentiate between the two packet formats. The reply SHALL be in the format of the request.
AR $ HRDフィールドは、2つのパケット形式を区別するために使用するものとします。返信はリクエストの形式でなければなりません。
This is the ARP packet format used by conventional IEEE 802 networks (i.e. Ethernet, etc). The packet format is described in RFC-826 [14] and is given here only for completeness purpose.
これは、従来のIEEE 802ネットワーク（イーサネットなど）で使用されるARPパケット形式です。パケット形式はRFC-826 [14]で説明されており、完全な目的でのみここで説明されています。
ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$hln 8 bits byte length of each hardware address ar$pln 8 bits byte length of each protocol address ar$op 16 bits opcode (ares_op$REQUEST | ares_op$REPLY) ar$sha 48 bits Hardware address of sender of this packet ar$spa 32 bits Protocol address of sender of this packet ar$tha 48 bits Hardware address of target of this ar$tpa 32 bits Protocol address of target.
AR $ 16ビットハードウェアタイプAR $ PRO 16ビットプロトコルタイプ以下のプロトコルフィールドのタイプ、各ハードウェアアドレスの8ビットバイト長さar $ PLN各プロトコルアドレスの8ビットバイト長op 16ビットOpcode（ares_op $ $ $リクエスト| ares_op $ Reply）ar $ sha 48ビットハードウェアこのパケットの送信者のアドレスAr $ SPA 32ビットプロトコルこのパケットの送信者のアドレス48ビット32ビットのターゲットのアドレスこのAR $ TPA 32ビットプロトコルアドレスのターゲット。
Where: ar$hrd - SHALL contain 1. (Ethernet)
場所：ar $ hrd -1。（イーサネット）
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar $ pro-は、IPプロトコルコード2048（小数）を含めるものとします。
ar$hln - SHALL contain 6.
ar $ hln-含める6。
ar$pln - SHALL contain 4.
ar $ pln-には4が含まれます。
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 $ op -conforational Value（decimal）：1 harp_replys 8のharp_requests 2の場合：inharp_replys 9 for harp_replys 10 for harp_nak
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-リクエストとnaksでは、既知の場合はリクエスターのIPアドレスが含まれます。他の返信では、ターゲットポートのIPアドレスが含まれます。
ar$sha - in requests and NAKs it SHALL contain the requester's ULA In replies it SHALL contain the target port's ULA.
ar $ sha-リクエストとnaksでは、リクエスターのULAがターゲットポートのULAを含めるものとします。
ar$spa - 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 $ spa-リクエストとnaksでは、既知の場合はリクエスターのIPアドレスが含まれ、それ以外の場合はゼロが含まれます。他の返信では、ターゲットポートのIPアドレスが含まれます。
ar$tha - in requests and NAKs it SHALL contain the target's ULA if known, otherwise zero. In other replies it SHALL contain the requester's ULA.
ar $ tha-リクエストとnaksでは、既知の場合はターゲットのULAが含まれ、それ以外の場合はゼロが含まれます。他の返信では、リクエスターのULAが含まれます。
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-リクエストとnaksでは、既知の場合はターゲットのIPアドレスが含まれ、それ以外の場合はゼロが含まれます。他の返信では、要求者のIPアドレスが含まれます。
|31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+-----
0 | |
| D_ULA +-------------------------------+HIPPI
1 | | |6400
+-------------------------------+ S_ULA |MAC
2 | |hdr
+---------------------------------------------------------------+
3 | M_len |
+---------------+---------------+---------------+---------------+-----
4 | AA | AA | 03 | 00 |IEEE
+---------------+---------------+---------------+---------------+802
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/
+------------+------------------+-------------------------------+SNAP
6 | hrd (1) | pro (2048) |
+---------------+---------------+---------------+---------------+
7 | hln (6) | phl (4) | op (ar$op) |
+<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
8 | Source Hardware Address 0 - 3 |
+-------------------------------+-------------------------------+
9 | Source ULA bytes 4 - 5 | Source IP Address bytes 0 - 1 |
+-------------------------------+-------------------------------+
10 | Source IP Address bytes 2 - 3 | Target ULA bytes 0 - 1 |
+-------------------------------+-------------------------------+
11 | Target Hardware Address (ULA) bytes 2 - 5 |
+---------------------------------------------------------------+
12 | Target IP Address |
+---------------+---------------+---------------+---------------+
13 | FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
14 | FILL | FILL | FILL | FILL |
+><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+
The HARP protocols further SHALL support the HIPARP hardware type (ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation code (ar$op) data formats as the ARP, and InARP protocols [14,7]. In addition, HARP makes use of an additional operation code for ARP_NAK introduced with [11]. The remainder of the HIPARP message format (defined in [13]) is different than the ARP/InARP message format defined in [14,7,10] and it is also different from the format defined in the first "IP and ARP on HIPPI" RFC-1374 [16].
HARPプロトコルはさらに、HIPARPハードウェアタイプ（AR $ HRD）= 28（DEC）[18]、プロトコルタイプ（AR $ PRO）、および操作コード（AR $ OP）データ形式をARPとしてサポートし、ARPおよびINARPプロトコルをサポートするものとします。14,7]。さらに、HARPは[11]で導入されたARP_NAKの追加操作コードを使用します。HIPARPメッセージ形式の残り（[13]で定義）は、[14,7,10]で定義されているARP/INARPメッセージ形式とは異なり、最初の「IPとARPで定義された形式とは異なります。「RFC-1374 [16]。
The HARP message has several fields that have the following format and values: 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
HARPメッセージには、次の形式と値を持ついくつかのフィールドがあります。データサイズとフィールドの意味：AR $ 16ビットハードウェアタイプAR $ 16ビットプロトコルタイプ以下のプロトコルフィールド、またはnak）ar $ pln各プロトコルアドレスの8ビットバイトの長さar $ rhl 8ビットリクエスト担当者のヒッピハードウェアアドレス長（q）ar $ thl 8ビットターゲットのヒッピハードウェアアドレス長（x）ar $ rpa 32ビットリクエスタのプロトコルアドレスar$ TPA 32ビットターゲットのプロトコルアドレスar $ rha qbytes requesters hippiハードウェアアドレス
Where : ar$hrd - SHALL contain 28. (HIPARP)
場所：ar $ hrd- 28.（hiparp）が含まれます
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar $ pro-は、IPプロトコルコード2048（小数）を含めるものとします。
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 $ op -conforational Value（decimal）：1 harp_replys 8のharp_requests 2の場合：inharp_replys 9 for harp_replys 10 for harp_nak
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-これがHIPPI-800 HWアドレスである場合は10を含むものとする。HIPPI-6400の場合、6を含む。
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アドレスである場合は、HIPPI-6400の場合、6を含む6を含む6。
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-リクエストとnaksでは、要求者の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-リクエストとnaksでは、既知の場合はリクエスターのIPアドレスが含まれます。他の返信では、ターゲットポートのIPアドレスが含まれます。
ar$tha - in requests and NAKs it SHALL contain the target's HW address if known, otherwise zero.
ar $ tha-リクエストとnaksでは、既知の場合はターゲットのHWアドレスが含まれ、それ以外の場合はゼロが含まれます。
In other replies it SHALL contain the requester's HW address.
他の返信では、要求者のHWアドレスが含まれます。
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-リクエストとnaksでは、既知の場合はターゲットのIPアドレスが含まれ、それ以外の場合はゼロが含まれます。他の返信では、要求者のIPアドレスが含まれます。
Payload Format for HARP/InHARP PDUs:
HARP/INHARP PDUのペイロード形式：
|31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+-----
0 | |
| D_ULA +-------------------------------+HIPPI
1 | | |6400
+-------------------------------+ S_ULA |MAC
2 | |hdr
+---------------------------------------------------------------+
3 | M_len |
+---------------+---------------+---------------+---------------+-----
4 | AA | AA | 03 | 00 |IEEE
+---------------+---------------+---------------+---------------+802
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/
+------------+------------------+-------------------------------+SNAP
6 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
7 | op (ar$op) | pln (6) | shl (q) |
+<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
8 | thl (x) | Source IP Address upper (24 bits) |
+---------------------------------------------------------------+
9 | Src. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
10 | Tgt. IP lower | Source HW Address bytes 0 - 2 |
+---------------+-------------------------------+---------------+
11 | Source HW Address bytes 3 - q | Tgt HW byte 0 |
+-----------------------------------------------+---------------+
12 | Target Hardware Address bytes 1 - 4 |
+---------------+-----------------------------------------------+
13 |Tgt HW byte 5-x|
+---------------+
HARP - InHARP Message
6.2.1 Example Message encodings:
6.2.1 メッセージメッセージのエンコーディング：
Assume for the following example that the HARP server is in the HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side of the non-broadcast capable network.
次の例では、HARPサーバーがHIPPI-6400側にあり、クライアントであるXとYが非ブロードキャスト対応ネットワークのHIPPI-800側にあると仮定します。
HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = IPx
HARP ar$rha = SWy ULAy HARP ar$tha = **
** is what we would like to find out
HARP_REPLY message format
HARP ar$op = 2 (HARP_REPLY)
HARP ar$rpa = IPx HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx * 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 = SWx ULAx
** is what we would like to find out
InHARP_REPLY message format
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPx * HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx 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 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 and MUST be implemented.
harp_nakメッセージ形式は、操作コードがharp_nakに設定された、受信したharp_requestメッセージ形式と同じです。つまり、HARP_REQUESTメッセージデータは、HARP_NAK値に変更されたHARP_REQUEST操作コードを使用して送信のためにコピーされます。HARPは、harp_nakの追加操作コードを使用し、実装する必要があります。
7 Broadcast and Multicast
7ブロードキャストとマルチキャスト
HIPPI-6400-SC requires compliant systems to support broadcast. Initial HIPPI-6400-SC systems MAY defer broadcast capability to a broadcast server rather than support it directly in the switching mechanism. A centralized HARP server architecture meets two of the three major duties of a broadcast server.
HIPPI-6400-SCには、ブロードキャストをサポートするための準拠システムが必要です。初期HIPPI-6400-SCシステムは、切り替えメカニズムで直接サポートするのではなく、ブロードキャストサーバーにブロードキャスト機能を延期する場合があります。集中化されたHARPサーバーアーキテクチャは、ブロードキャストサーバーの3つの主要な任務のうち2つを満たしています。
A central entity serving the whole LIS solves the coordination problem of a distributed approach. The registration requirement solves the second problem of determining which addresses make up the set loosely called "everyone". The last duty of a broadcast server is to replicate an incoming packet and send it to "everyone".
LIS全体にサービスを提供する中央エンティティは、分散アプローチの調整問題を解決します。登録要件は、どのアドレスが「Everyone」と呼ばれるセットをゆるく構成するかを決定する2番目の問題を解決します。ブロードキャストサーバーの最後の義務は、着信パケットを複製して「全員」に送信することです。
During its registration phase, every port , including HARP server(s), discover if the underlying medium is capable of broadcast (see section 5.1.1). Should this not be the case, then the HARP server(s) MUST emulate broadcast through an IP broadcast emulation server.
登録段階では、HARPサーバーを含むすべてのポートが、基礎となる媒体がブロードキャストできるかどうかを発見します（セクション5.1.1を参照）。そうでない場合、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により、一般的な上層ネットワーキングプロトコル（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テーブルをターゲットリストと呼ばれるアドレスのリストとして使用するものとします。ブロードキャストサーバーは、すべての着信メッセージがターゲットリストのアドレスに対応するソースアドレスを持っていることを検証するものとします。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.
このメモは、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サーバーと同じポートで実行されることをお勧めします。その場合、パイブはHARPサーバーと同じアドレスを使用するものとします。
HIPPI-6400 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 [7]) 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-6400はマルチキャストアドレスを直接サポートしていないため、IPマルチキャストアドレスからHIPPIマルチキャストサービスに利用できるマッピングはありません。現在のIPマルチキャストの実装（つまり、MBONEおよびIPトンネリング、[7]を参照）は、すべての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:
ブロードキャストエミュレーションサービス（セクション7.1で定義されている）には、固有のパフォーマンス制限があることは明らかです。Nポートを備えたLISでは、そのようなサービスがブロードキャストできる帯域幅の上限は次のとおりです。
(total bandwidth)/(n+1)
（総帯域幅）/（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を説明してから、すべての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-6400 network to look similar to an Ethernet network to the higher layers.
このサービスは、RIP、OSPF、NISなどの標準的なネットワークプロトコルに適しています。通常、ネットワーク帯域幅のごく一部をブロードキャストに使用するためです。これらの目的のために、このメモで定義されているブロードキャストエミュレーションサーバーは、HIPPI-6400ネットワークがイーサネットネットワークに似ているように見えることができます。
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
スケジュールされた転送のための8ハープ
This RFC also applies for resolving addresses used with Scheduled Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message types and algorithms can be used for ST (since ST uses Internet Addresses) as long as there is also an IP over HIPPI-6400 implementation on all the ports.
このRFCは、IPの代わりにHIPPI-6400を介してスケジュールされた転送（ST）で使用されるアドレスの解決にも適用されます。このRFCのメッセージタイプとアルゴリズムは、すべてのポートにHIPPI-6400の実装を介してIPがある限り、STには（STがインターネットアドレスを使用するため）（インターネットアドレスを使用するため）に使用できます。
9 Security Consierations
9つのセキュリティ上の考慮事項
There are known security issues relating to port impersonation via the address resolution protocols used in the Internet [6]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using HARP.
インターネットで使用されているアドレス解像度プロトコルを介したポートのなりすましに関連するセキュリティの問題が既知の問題があります[6]。HARPを使用してネットワークで使用するためにここで定義されているアドレス解像度メカニズムに特別なセキュリティメカニズムは追加されていません。
Not all of the security issues relating to ARP over HIPPI-6400 are clearly understood at this time, due to the fluid state of HIPPI-6400 specifications, newness of the technology, and other factors. However, given the security hole ARP allows, other concerns are probably minor.
HIPPI-6400を超えるARPに関連するすべてのセキュリティ問題が、HIPPI-6400仕様の流体状態、テクノロジーの新しさ、およびその他の要因のために、この時点で明確に理解されているわけではありません。ただし、セキュリティホールARPが許可されていることを考えると、他の懸念はおそらくマイナーです。
10 Open Issues
10の開かれた問題
Synchronization and coordination of multiple HARP servers and multiple broadcast servers are left for further study.
複数のHARPサーバーと複数のブロードキャストサーバーの同期と調整は、さらなる研究のために残されています。
11 HARP Examples
11のハープの例
Assume a HIPPI-6400-SC switch is installed with three connected ports: x, y, and a. Each port has a unique hardware address that consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa, this address is the authoritative HIPPI hardware address in the HRAL (HARP Request Address List).
HIPPI-6400-SCスイッチが3つの接続されたポートでインストールされていると仮定します：x、y、およびa。各ポートには、一意のULA（それぞれUlax、Ulay、ULAA）で構成される一意のハードウェアアドレスがあります。アドレスHWAにマッピングされたスイッチポートに接続された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. Both ports X and Y have their interfaces configured DOWN.
Harpサーバーのテーブルは空です。ポートXとYはそれぞれ独自のハードウェアアドレスを知っています。最終的に彼らはお互いに話したいと思っています。それぞれが相手のIPアドレス（ポートデータベースから）を知っていますが、どちらも相手のULAを知りません。ポートXとYの両方に、インターフェイスが下に構成されています。
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. As well as ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.
注：LLC、SNAP、ETHERTYPE、AR $ HRD、AR $ PRO、AR $ PLNフィールドは、一定であるため、以下の例から除外されています。ar $ rhl = ar $ thl = 6だけでなく、これらはすべてhippi-6400の例です。
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 the HWa after starting a table entry for the HWa.
1. ポートYは、インターフェイスを開始し、HWAのテーブルエントリを開始した後、HWAにinharp_requestを送信します。
HIPPI-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = 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-6400-PH D_ULA = ULAy HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = ULAa HARP ar$tha = ULAy * answer we were looking for
hippi-6400-ph d_ula = ulay hippi-6400-ph s_ula = ulaa harp ar $ op = 9（inharp_reply）harp ar $ rpa = ips * harp ar $ tpa = ipy harp ar $ rha = ulaa harp ar $ tha = ulayay*私たちが探していた答え
3. Port Y examines the incoming InHARP_REPLY and 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. Port Yは、着信HARP_REPLYを調べ、HARPサーバーのテーブルエントリを完了します。サーバーのクライアントのHARPテーブルエントリは、有効な状態に渡され、通常のHARPトラフィックに使用可能になりました。この返信を受信すると、Harpサーバーがクライアントを適切に登録したことが保証されます。
If port Y is connected to a broadcast-capable network then the authoritative address is the broadcast address, HWb = SWb, ULAb (FF:FF:FF:FF:FF:FF).
ポートYがブロードキャスト対応ネットワークに接続されている場合、権威あるアドレスはブロードキャストアドレス、hwb = swb、ulab（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-6400-PH D_ULA = ULAb
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = 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-6400 hardware. The authoritative address in the HRAL for this example will be HWa: <SWa, ULAa> and IPs for simplicity reasons.
このメモで指定されているHARPプロトコルの運用フェーズは、ブロードキャストと非ブロードキャストの両方のHIPPI-6400ハードウェアの両方で同じです。この例のHRALの権威あるアドレスは、単純な理由でHWA：<SWA、ULAA>およびIPSです。
Assume the same process (steps 1-3 of section 11.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で同じプロセス（セクション11.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-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = 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-6400-PH D_ULA = ULAx HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 2 (HARP_Reply) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = ULAy * HARP ar$tha = ULAx * answer we were looking for
hippi-6400-ph d_ula = ulax hippi-6400-ph s_ula = ulaa harp ar $ op = 2（harp_reply）harp ar $ rpa = ipy harp ar $ tpa = ipx harp ar $ rha = ulay * harp ar $ tha = 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-6400-PH D_ULA = ULAy HIPPI-6400-PH S_ULA = ULAx <data>
hippi-6400-ph d_ula = ulay hippi-6400-ph s_ula = ulax <data>
If the network had been broadcast-capable, 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.
ネットワークがブロードキャスト対応だった場合、ターゲットポート自体が上記のステップ2のharp_requestを受信し、HARPサーバーが行ったのと同じように応答しました。
As in 11.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,
11.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-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = 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-6400-PH D_ULA = ULAx
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 10 (HARP_NAK)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = 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 the network had been broadcast-capable, then there would not have been a reply.
ネットワークがブロードキャスト対応だった場合、返信はなかったでしょう。
12 References
12の参照
[1] ANSI NCITS 323-1998, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[1] ANSI NCITS 323-1998、情報技術 - 高性能並列インターフェイス-6400 MBIT/S物理層（HIPPI-6400-PH）。
[2] ANSI NCITS 324-199x, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Switch Control (HIPPI-6400-SC).
[2] ANSI NCITS 324-199X、情報技術 - 高性能並列インターフェイス-6400 MBIT/S物理スイッチ制御（HIPPI-6400-SC）。
[3] ANSI NCITS Project Number 1249-D, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Optical Specification (HIPPI-6400-OPT).
[3] ANSI NCITSプロジェクト番号1249-D、情報技術 - 高性能並列インターフェイス-6400 MBIT/S光学仕様（HIPPI-6400-OPT）。
[4] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[4] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[5] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[5] Bradley、T。およびC. Brown、「逆住所解像度プロトコル」、RFC 2390、1998年9月。
[6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[6] Bellovin、Steven M.、「TCP/IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、Vol。19、第2号、pp。32-48、1989。
[7] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[7] Deering、S、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects 1996, Stanford University.
[8] チェッソン、グレッグ、「HIPPI-6400概要」、IEEE Hot Interconnects 1996、スタンフォード大学。
[10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control IEEE, IEEE, New York, New York, 1989.
[10] ansi/ieee std。802.2-1989、情報処理システム - ローカルエリアネットワーク - 論理リンク制御IEEE、IEEE、ニューヨーク、ニューヨーク、1989年。
[11] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[11] Laubach、M。、「ATM上の古典的なIPとARP」、RFC 2225、1998年4月。
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November, 1990.
[12] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834, May 2000.
[13] Pittet、J.-M。、「ARPおよびIPブロードキャストHIPPI-800」、RFC 2834、2000年5月。
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
[14] Plummer、D。、「イーサネットアドレス解像度プロトコル - または - ネットワークアドレスをイーサネットハードウェア上の送信用の48ビットイーサネットアドレスに変換する」、RFC -826、MIT、1982年11月。
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[15] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[16] Renwick、J。およびA. Nicholson、「IP and ARP on Hippi」、RFC 1374、1992年10月。
[17] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[17] Renwick、J。、「IP Over Hippi」、RFC 2067、1997年1月。
[18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[18] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[19] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
13 Acknowledgments
13謝辞
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 [17], written by John Renwick. ARP [14] written by Dave Plummer and Inverse ARP [7] written by Terry Bradley and Caralyn Brown provide the fundamental algorithms of HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [13], written by Mark Laubach who laid the structural groundwork for the HARP server.
このメモは、ジョン・レンウィックによって書かれた[17]の第2部に基づいています。Tery BradleyとCaralyn Brownによって書かれたDave Plummerとinverse Arp [7]によって書かれたArp [14]は、このメモに示されているHarpの基本的なアルゴリズムを提供します。さらに、HARPサーバーは、HARPサーバーの構造的基礎を築いたMark Laubachによって書かれた[13]で提示された概念とモデルに基づいています。
14 Author's Address
14著者の住所
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94040
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View、CA 94040
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org
15 Full Copyright Statement
15完全な著作権ステートメント
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エディター機能の資金は現在、インターネット協会によって提供されています。