Network Working Group J.-M. Pittet
Request for Comments: 2834 Silicon Graphics Inc.
Obsoletes: 1374 May 2000
Category: Standards Track
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.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC-2067 "IP over HIPPI") obsoletes RFC-1374.
本文档规定了将IP地址解析为ANSI高性能并行接口（HIPPI）硬件地址的方法，以及在逻辑IP子网（LIS）中模拟IP广播作为HARP的直接扩展的方法。本备忘录定义了一个HARP，该HARP将在HIPI-800和HIPI-6400（也称为千兆字节系统网络，GSN）之间进行互操作。本文件（与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
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
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
ANSI高性能并行接口（HIPPI）是一个双单工数据通道。HIPPI可以以每秒800或1600兆的速度同时发送和接收数据。1987年至1997年间，ANSI X3T11.1 HIPPI工作组（现称为NCITS T11.1）标准化了将HIPPI用作网络接口的五个文件。它们涵盖物理和电气规范（HIPPI-PH[1]）、字节流的帧（HIPPI-FP[2]）、IEEE 802.2 LLC的封装（HIPPI-LE[3]）、物理层交换机的行为（HIPPI-SC[4]）以及物理级和光学规范（HIPPI串行[5]）。HIPPI-LE还意味着互联网协议的封装[5]。读者应熟悉ANSI HIPPI文件。认可的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获得(http://www.ansi.org). T11.1工作组的工作文件可从T11网页获取(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]描述了IP在HIPPI-800上的封装。本备忘录介绍了工作组和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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[18]中所述进行解释。
In the following discussion, the terms "requester" and "target" are used to identify the port initiating the address resolution request and the port whose address it wishes to discover, respectively. If not all switches in the LIS support broadcast then there will be a HARP server providing the address resolution service and it will be the source of the reply. If on the other hand all switches support broadcast then the source address of a reply will be the target's target address.
在下面的讨论中，术语“请求者”和“目标”分别用于标识发起地址解析请求的端口和希望发现其地址的端口。如果不是LIS中的所有交换机都支持广播，那么将有一个HARP服务器提供地址解析服务，它将是回复的来源。另一方面，如果所有交换机都支持广播，则应答的源地址将是目标的目标地址。
Values are decimal unless otherwise noted. Formatting follows IEEE 802.1A canonical bit order and and HIPPI-FP bit and byte order.
除非另有说明，否则数值为十进制。格式化遵循IEEE 802.1A标准位顺序和HIPPI-FP位和字节顺序。
Broadcast
广播
A distribution mode which transmits a message to all ports. Particularly also the port sending the message.
向所有端口发送消息的一种分发模式。尤其是发送消息的端口。
Classical/Conventional
古典/传统
Both terms are used to refer to networks such as Ethernet, FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs.
这两个术语均用于指代以太网、FDDI和其他802 LAN类型的网络，与HIPPI-SC LAN不同。
Destination
目的地
The HIPPI port that receives data from a HIPPI Source.
从HIPPI源接收数据的HIPPI端口。
HARP
竖琴
HARP describes the whole set of HIPPI address resolution encodings and algorithms defined in this memo. HARP is a combination and adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 [13] and Inverse ARP (InARP) [7] (see section 5). HARP also describes the HIPPI specific version of ARP [10] (i.e. the protocol and the HIPPI specific encoding).
HARP描述了本备忘录中定义的整套HIPPI地址解析编码和算法。HARP是互联网地址解析协议（ARP）RFC-826[13]和反向ARP（InARP）[7]的组合和改编（见第5节）。HARP还描述了ARP的HIPPI特定版本[10]（即协议和HIPPI特定编码）。
HARP table
竖琴桌
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
每个主机都有一个HARP表，其中包含IP成员的IP到硬件地址映射。
HIPPI-Serial
希皮连载
An implementation of HIPPI in serial fashion on coaxial cable or optical fiber. (see [5])
在同轴电缆或光纤上以串行方式实现HIPPI。（见[5]）
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
硬件（硬件）地址
The hardware address of a port consisting of an I-Field and an optional ULA (see section 6.2). Note: the term port as used in this document refers to a HIPPI port and is roughly equivalent to the term "interface" as commonly used in other IP documents.
端口的硬件地址，包括一个I字段和一个可选的ULA（见第6.2节）。注：本文件中使用的术语端口指HIPPI端口，大致等同于其他IP文件中常用的术语“接口”。
Host
主办
An entity, usually a computer system, that may have one or more HIPPI ports and which may serve as a client or a HARP server.
一种实体，通常是一个计算机系统，可能有一个或多个HIPPI端口，可用作客户机或HARP服务器。
Port
港口城市
An entity consisting of one HIPPI Source/Destination dual simplex pair that is connected by parallel or serial HIPPI to a HIPPI-SC switch and that transmits and receives IP datagrams.
一种实体，由一个HIPPI源/目标双单工对组成，通过并行或串行HIPPI连接到HIPPI-SC交换机，并传输和接收IP数据报。
PIBES
皮布斯
The Protocol for Internet Broadcast Emulation Server (see section 7).
Internet广播仿真服务器的协议（参见第7节）。
Switch Address
交换机地址
A value used as the address of a port on a HIPPI-SC network. It is transmitted in the I-field. HIPPI-SC switches map Switch Addresses to physical switch port numbers. The switch address is extended with a mode byte to form an I-Field (see [4] and 6.2.2)
用作HIPPI-SC网络上端口地址的值。它在I字段中传输。HIPPI-SC交换机将交换机地址映射到物理交换机端口号。开关地址扩展为一个模式字节，以形成一个I字段（见[4]和6.2.2）
Source
来源
The HIPPI port that generates data to send to a HIPPI Destination.
HIPPI端口，用于生成要发送到HIPPI目的地的数据。
Universal LAN MAC Address (ULA)
通用局域网MAC地址（ULA）
A 48-bit globally unique address, administered by the IEEE, assigned to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN.
由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中配置其主机和路由器。每个LIS独立于同一HIPPI网络上的其他LIS进行操作和通信。
HARP has LIS scope only and serves all ports in the LIS. Communication to ports located outside of the local LIS is usually provided via an IP router. This router is a HIPPI port attached to the HIPPI network that is configured as a member of one or more LIS's. This configuration MAY result in a number of disjoint LIS's operating over the same HIPPI network. Using this model, ports of different IP subnets SHOULD communicate via an intermediate IP router even though it may be possible to open a direct HIPPI connection between the two IP members over the HIPPI network. This is a consequence of using IP and choosing to have multiple LIS's on the same HIPPI fabric.
HARP仅具有LIS作用域，服务于LIS中的所有端口。与本地LIS外部端口的通信通常通过IP路由器提供。此路由器是连接到HIPI网络的HIPI端口，配置为一个或多个LIS的成员。这种配置可能导致许多不相交的LIS在同一HIPPI网络上运行。使用此模型，不同IP子网的端口应通过中间IP路由器进行通信，即使可以通过HIPI网络在两个IP成员之间打开直接HIPI连接。这是使用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成员客户端。
The requirement for IP members (hosts, routers) operating in a HIPPI LIS configuration is:
在HIPPI LIS配置中运行的IP成员（主机、路由器）的要求为：
o All members of the LIS SHALL have the same IP network/subnet address and address mask [6].
o LIS的所有成员应具有相同的IP网络/子网地址和地址掩码[6]。
The following list identifies the set of HIPPI-specific parameters that MUST be implemented in each IP station connected to the HIPPI network:
以下列表确定了必须在连接到HIPI网络的每个IP站中实施的HIPI特定参数集：
o HIPPI Hardware Address:
o HIPPI硬件地址：
The HIPPI hardware address of an individual IP port MUST contain the port's Switch Address (see section 9). The address SHOULD also contain a non-zero ULA address. If there is no ULA then that field MUST be zero.
单个IP端口的HIPPI硬件地址必须包含端口的交换机地址（参见第9节）。地址还应包含一个非零地址。如果没有ULA，则该字段必须为零。
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是两个或多个地址的有序列表，用于标识地址解析服务。所有HARP客户端的配置必须相同，即所有端口在HRAL中必须具有相同的地址。
The HRAL MUST contain at least two HIPPI HW addresses identifying the individual HARP service(s) that have authoritative responsibility for resolving HARP requests of all IP members located within the LIS.
HRAL必须包含至少两个HIPPI HW地址，用于标识对解决LIS内所有IP成员的HARP请求负有权威责任的单个HARP服务。
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]。此HARP服务条目的ULA应为FF:FF:FF:FF:FF:FF。
It is REQUIRED that the second address be the address for "Messages pertaining to (the) ... address resolution requests: 0xFE0" [4]. The ULA for this HARP server entry is 00:00:00:00:00:00.
第二个地址必须是“与……地址解析请求有关的消息：0xFE0”[4]的地址。此HARP服务器条目的ULA为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
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> ...
此类列表的示例：第一个条目：0x07000FE1 FF:FF:FF:FF:FF:FF第二个条目：0x07000FE0 00:00:00:00:00:00第三个条目：0x0700001<备用HARP服务器>。。。
Manual configuration of the addresses and address lists presented in this section is implementation dependent and beyond the scope of this memo.
本节所述地址和地址列表的手动配置取决于实施情况，超出了本备忘录的范围。
Address resolution within the HIPPI LIS SHALL make use of the HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI Address Resolution Protocol (InHARP). HARP provides the same functionality as the Internet Address Resolution Protocol (ARP). HARP is based on ARP which is defined in RFC-826 [13]. Knowing the Internet address, conventional networks use ARP to discover another port's hardware address. HARP presented in this section further specifies the combination of the original protocol definitions to form a coherent address resolution service that is independent of the hardware's broadcast capability.
HIPPI LIS中的地址解析应使用HIPPI地址解析协议（HARP）和反向HIPPI地址解析协议（InHARP）。HARP提供与Internet地址解析协议（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）协议。知道其硬件地址后，INRAP用于发现另一方的Internet地址。
This memo further REQUIRES the PIBES (see section 7 below) extension to the HARP protocol, guaranteeing broadcast service to upper layer protocols like IP.
该备忘录还要求PIBES（见下文第7节）扩展到HARP协议，以保证向上层协议（如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.
Internet地址的分配独立于ULA和交换机地址。在使用HARP之前，每个端口必须知道其IP和硬件地址。ULA是可选的，但如果需要桥接到传统网络，建议使用。
This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI-SC networks. HARP creates a table in each port which maps the IP address of each port to a hardware address, so that when an application requests a connection to a remote port by its IP address, the hardware address can be determined, a correct HIPPI-LE header can be built, and a connection to the port can be established using the correct Switch Address in the I-field.
本节定义了广播和非广播HIPPI-SC网络上HARP实现的行为和要求。HARP在每个端口中创建一个表，该表将每个端口的IP地址映射到硬件地址，以便当应用程序通过其IP地址请求连接到远程端口时，可以确定硬件地址，可以构建正确的HIPPI-LE头，并且可以使用I字段中的正确交换机地址建立到端口的连接。
HARP is a two phase protocol. The first phase is the registration phase and the second phase is the operational phase. In the registration phase the port detects if it is connected to broadcast hardware or not. The InHARP protocol is used in the registration phase. In case of non-broadcast capable hardware, the InHARP Protocol will register and establish a table entry with the server. The operational phase works much like conventional ARP with the exception of the message format.
HARP是一个两阶段协议。第一阶段是登记阶段，第二阶段是运作阶段。在注册阶段，端口检测是否连接到广播硬件。InHARP协议用于注册阶段。对于不支持广播的硬件，InHARP协议将向服务器注册并建立一个表条目。操作阶段的工作原理与传统的ARP非常相似，只是消息格式不同。
Within the HIPPI LIS, there SHALL be an authoritative HARP service. At each point in time there is only one authoritative HARP service.
在HIPPI LIS中，应有权威的竖琴服务。在每个时间点只有一个权威的HARP服务。
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）中的第一个地址发送InHARP_请求。如果端口看到自己的InHARP_请求，那么它将连接到支持广播的网络。在这种情况下，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_请求。发送InHARP_回复的每个地址都被视为响应HARP服务器。权威HARP服务应为HRAL中首先出现的HARP服务器。
The sequence of the HRAL is only important for deciding which address will be the authoritative one. On a non-broadcast network, the port is REQUIRED to keep "registered" with all HARP server addresses in the HRAL (NOTE: not the broadcast address since it is not a HARP server address). If for instance the authoritative HARP service is non-responsive, then the port will consider the next address in the HRAL as a candidate for the authoritative address and send an InHARP_REQUEST.
HRAL的顺序只对决定哪个地址是权威地址很重要。在非广播网络上，端口需要与HRAL中的所有HARP服务器地址保持“注册”（注意：不是广播地址，因为它不是HARP服务器地址）。例如，如果权威的HARP服务不响应，那么端口将考虑在HALL中的下一个地址作为权威地址的候选，并发送一个InHARP1请求。
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）客户端的一个或多个注册请求（见第5.1.2和5.2节），（2）过去120秒内的任何两个HARP_请求，或（3）如果外部代理检测到权威HARP服务器出现故障，则应将其视为无响应。此类外部代理及其与HARP客户端交互的详细信息超出了本文档的范围。如果权威HARP服务器没有响应，则应重新启动注册过程。不禁止选择权威HARP服务的替代方法。
HARP clients SHALL initiate the registration phase by sending an InHARP_REQUEST message using the addresses in the HRAL in order. The client SHALL terminate the registration phase and transition into the operational phase, either when it receives its own InHARP_REQUEST or when it receives an InHARP_REPLY from at least one of the HARP servers and when it has determined the authoritative HARP service as described in section 5.1.1.
HARP客户端应按顺序使用HRAL中的地址发送InHARP_请求消息，以启动注册阶段。当客户收到自己的InHARP_请求或从至少一个HARP服务器收到InHARP_回复时，以及当客户确定第5.1.1节所述的权威HARP服务时，客户应终止注册阶段并过渡到运营阶段。
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_请求。要尝试的第一个地址将是广播地址“0x07000FE1 FF:FF:FF:FF:FF:FF”。有两个结果：
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_请求：然后端口连接到支持广播的网络。第一个地址成为并保持HARP服务的权威地址。
2. The port does not receive its InHARP_REQUEST: then the port is connected to a non-broadcast capable network.
2. 该端口未收到其InHARP_请求：则该端口连接到不支持广播的网络。
In the second case, the port SHALL choose the next address in the HRAL as a candidate for a authoritative address and send an InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).
在第二种情况下，端口应选择HRAL中的下一个地址作为权威地址的候选地址，并向该地址发送InHARP_请求：（0x07000FE0 00:00:00:00）。
o If the port receives its own message, then the port itself is the HARP server and the port is REQUIRED to provide broadcast services using the PIBES (see section 7).
o 如果端口接收到自己的消息，那么端口本身就是HARP服务器，需要该端口使用PIBES提供广播服务（参见第7节）。
o If the port receives an InHARP_REPLY, then it is a HARP client and not a HARP server.
o 如果端口收到InHARP_回复，则它是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.
如果客户端确定其连接到非广播网络，则客户端应至少每5秒重试HRAL中的每个非广播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-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_请求消息，并应完成注册阶段。客户应进一步注意，它连接到一个支持广播的网络，并使用此信息老化HARP服务器条目，并分别用于第5.4节和第5.6节中规定的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_请求，则应在完成注册阶段之前等待InHARP_回复。这还将为客户端提供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_请求并接收HARP_回复，获得并刷新自己的HARP表，该表包含IP成员的IP到HW地址映射。在运营阶段，客户完全可以运营。
In the operational phase, the client's behavior for requesting HARP resolution is the same for broadcast or non-broadcast networks.
在操作阶段，对于广播或非广播网络，客户端请求HARP解析的行为是相同的。
The target of an address resolution request updates its address mapping tables with any new information it can find in the request. If it is the target port it SHALL formulate and send a reply message. A port is the target of an address resolution request if at least ONE of the following statements is true of the request:
地址解析请求的目标使用在请求中可以找到的任何新信息更新其地址映射表。如果是目标端口，则应制定并发送回复消息。如果以下语句中至少有一条对请求为真，则端口是地址解析请求的目标：
1. The port's IP address is in the target protocol address field (ar$tpa) of the HARP message.
1. 端口的IP地址位于HARP消息的目标协议地址字段（ar$tpa）中。
2. The port's ULA (if non-zero), is in the ULA part of the Target Hardware Address field (ar$tha) of the message.
2. 端口的ULA（如果非零）位于消息的目标硬件地址字段（ar$tha）的ULA部分。
3. The port's switch address is in the Target Switch Address field of Target Hardware Address field (ar$tha) of the message (see section 6.2.2).
3. 端口的交换机地址位于消息的目标硬件地址字段（ar$tha）的目标交换机地址字段中（参见第6.2.2节）。
4. The port is a HARP server.
4. 该端口是一个HARP服务器。
NOTE: It is RECOMMENDED that all HARP servers run on a ports which each have a non-zero ULA.
注意：建议所有HARP服务器在每个端口都有非零ULA的端口上运行。
The HARP client is responsible for contacting the HARP server(s) to have its own HARP information registered and to gain and refresh its own HARP entry/information about other IP members. This means, as noted above, that HARP clients MUST be configured with the hardware address of the HARP server(s) in the HRAL.
HARP客户端负责联系HARP服务器以注册其自己的HARP信息，并获取和刷新其自己的HARP条目/关于其他IP成员的信息。这意味着，如上所述，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别名）时，客户端应启动注册阶段。
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_请求和InHARP_请求消息。如果接口有多个IP地址（例如，IP别名），则客户端必须循环访问所有IP地址，并为每个此类地址生成InHARP_回复。在这种情况下，InHARP_请求将有多个回复。（参考RFC-1293[7]中的第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_回复应用于更新和刷新其自己的客户端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服务器在其中一个服务器映射发生更改时更新客户端，类似于在以太网上使用免费ARP实现的操作。
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_请求消息，并适当处理InHARP_回复消息（见第5.1.2和5.6节）。客户端应使用所有InHARP_回复消息来构建或刷新其HARP表条目。（参考[7]中的第7节“协议操作”）
If the registration phase showed that the hardware does not support broadcast, then the client MUST refresh its own entry for the HARP server, created during the registration phase, at least once every 15 minutes. This can be accomplished either through the exchange of a HARP request/reply with the HARP server or by repeating step 1. To decrease the redundant network traffic, this timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange.
如果注册阶段显示硬件不支持广播，则客户端必须至少每15分钟刷新一次注册阶段创建的HARP服务器的自身条目。这可以通过与HARP服务器交换HARP请求/应答或重复步骤1来实现。为了减少冗余网络流量，应在每次HARP_请求/HARP_应答交换后重置此超时。
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_请求向HARP服务器显示客户端仍处于活动状态。接收到HARP_回复向客户端表明服务器一定看到了HARP_请求。
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_请求/InHARP_回复操作。
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客户端接收到一条HARP消息，其中包含它不支持的操作代码（ar$op），则它必须优雅地丢弃该消息并继续正常操作。HARP客户端不需要向未定义消息的发送者返回任何消息。
A HARP server MUST accept HIPPI connections from other HIPPI ports. The HARP server expects an InHARP_REQUEST as the first message from the client. A server examines the IP source address, the hardware source address of the InHARP_REQUEST and adds or updates its HARP table entry <IP address(es), switch address, ULA> as well as the time stamp.
HARP服务器必须接受来自其他HIPI端口的HIPI连接。HARP服务器期望InHARP_请求作为来自客户端的第一条消息。服务器检查IP源地址、InHARP_请求的硬件源地址，并添加或更新其HARP表条目<IP地址（es）、交换机地址、ULA>以及时间戳。
A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs based on the information which it has in its HARP table. The HARP server SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has the requested information in its tables; otherwise it SHALL reply with a HARP_NAK. The HARP server replies SHALL contain the hardware type and corresponding format of the request (see also section 6).
HARP服务器应根据其HARP表中的信息回复HARP_请求和InHARP_请求。如果HARP服务器的表中包含请求的信息，则HARP服务器应使用HARP_回复或InHARP_回复进行回复；否则，它将以竖琴作答。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
+---+----------+----------+------------+---------------------+
| # | 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_请求的IP源地址与表项IP地址（例如IPa<->HWa）重复，且InHARP_请求硬件源地址与硬件地址项（例如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_请求请求者的IP源地址与表条目IP地址重复，且InHARP_请求硬件源地址与表条目硬件地址不匹配，则应创建新的HW条目。请求者的IP地址应从原始HW条目移动到新的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_请求请求者的硬件源地址与硬件源地址条目重复，但没有与接收到的IP地址匹配的IP条目，则IP地址应添加到硬件条目之前的IP地址中。（例如，添加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_请求更新HARP表项的超时。说明：如果客户端正在向服务器发送HARP请求，则服务器应通过更新客户端HARP表项上的超时来注意到客户端仍然处于“活动”状态。
A HARP server SHOULD use the PIBES (see section 7) to send out HARP_REPLYs to all hardware addresses in its table when the HARP server table changes mappings. This feature decreases the time of stale entries in the clients.
当HARP服务器表更改映射时，HARP服务器应使用PIBES（参见第7节）向其表中的所有硬件地址发送HARP_回复。此功能可减少客户端中过时条目的时间。
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_请求。此功能消除了在客户端端口上维护静态HARP表的需要。
HARP table aging MUST be supported since IP addresses, especially IP aliases and also interfaces (with their ULA), are likely to move. When so doing the mapping in the clients own HARP table/cache becomes invalid and stale.
必须支持HARP表老化，因为IP地址，特别是IP别名和接口（及其ULA）可能会移动。这样做时，客户机自己的HARP表/缓存中的映射将变得无效和过时。
o When a client's HARP table entry ages beyond 15 minutes, a HARP client MUST invalidate the table entry.
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 an aged entry prior to transmitting any non-address-resolution traffic to the port referred to by this entry.
注意：客户机应该在HARP表条目老化之前重新验证它，从而在表条目成功重新验证时重新启动老化时间。在重新验证过程中，只要表条目没有老化，客户端就可以继续向该条目所引用的端口发送通信量。客户端必须在将任何非地址解析流量传输到此条目所指的端口之前重新验证过期条目。
The client revalidates the entry by querying the HARP server with a HARP_REQUEST. If a valid reply is received (e.g. HARP_REPLY), the entry is updated. If the address resolution service cannot resolve the entry (e.g. HARP_NAK, "host not found"), the associated table entry is removed. If the address resolution service is not available (i.e. "server failure") the client MUST attempt to revalidate the entry by transmitting an InHARP_REQUEST to the hardware address of the entry in question and updating the entry on receipt of an InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the associated table entry is removed.
客户端通过使用HARP_请求查询HARP服务器来重新验证条目。如果收到有效回复（如HARP_回复），则更新条目。如果地址解析服务无法解析条目（例如HARP_NAK，“找不到主机”），则删除关联的表条目。如果地址解析服务不可用（即“服务器故障”），则客户端必须通过将InHARP_请求发送到相关条目的硬件地址，并在收到InHARP_回复后更新条目，尝试重新验证条目。如果InHARP_请求尝试未能返回InHARP_回复，则删除关联的表项。
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数据包格式。
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]标准。HIPI信息的长度，包括尾随填充，应为HIPI-LE要求的8字节的倍数。HARP和InHARP请求和回复的HIPPI-LE头字段应为：
FC (3 bits) SHALL contain zero.
FC（3位）应包含零。
Double-wide SHOULD be set according to HIPPI-LE [3]. This memo does NOT address the implications on HARP when this bit is set to 1 indicating the possibility of a port being able to accept 64-bit HIPPI connections.
应根据HIPPI-LE[3]设置双宽。当此位设置为1表示端口能够接受64位HIPPI连接的可能性时，此备忘录没有说明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.
消息类型应包含0以表示数据消息。在HARP消息的ar$op字段中，使用Ethertype和消息类型识别HARP消息。
Destination_Switch_Address, SHALL be the Switch Address of the destination port.
目的地\交换机\地址，应为目的地端口的交换机地址。
Destination_IEEE_Address SHALL be the ULA of the destination port, if known, otherwise zero.
目的地地址应为目的地端口的ULA（如果已知），否则为零。
Destination_Address_Type SHALL be 2, a 12-bit logical address. The behavior with type = 1, source routing, is NOT defined in this specification.
目的地址类型应为2，12位逻辑地址。类型为1的行为（源路由）未在本规范中定义。
Source_Switch_Address in requests SHALL be the sender's Switch Address.
请求中的源开关地址应为发送方的开关地址。
Source_IEEE_Address SHALL be the sender's ULA if known, otherwise zero.
如果已知，源地址应为发送方的ULA，否则为零。
Source_Address_Type SHALL be 2, a 12-bit logical address. The behavior with type = 1, source routing, is NOT defined in this specification.
源地址类型应为2，12位逻辑地址。类型为1的行为（源路由）未在本规范中定义。
The IEEE 802.2 LLC Header SHALL begin in the first byte of the HIPPI-FP D2_Area.
IEEE 802.2 LLC报头应从HIPPI-FP D2_区域的第一个字节开始。
The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes) indicating the presence of a SNAP header.
SSAP-DSAP-CTL的LLC值应为0xAA-AA-03（3字节），表示存在快照标头。
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个字节），表示以下两个字节为以太网类型。
The Ethertype value SHALL be set as defined in Assigned Numbers [16]: InHARP = InARP = HARP = ARP = 2054 = 0x0806.
Ethertype值应按照分配编号[16]中的定义进行设置：InHARP=INRAP=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 PDU的HIPPI-LE收割台：
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 = IP ULP |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | n + 8 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|M_Type | 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | D_A_T | S_A_T | 000 | Source Switch Addr |
+-------+-------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 |Message byte 0 |Message byte 1 |Message byte 2 | . . . |
+---------------+---------------+---------------+--- |
| . . . |
+ ------------+---------------+---------------+---------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HIPPI Message Format
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
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”=源地址类型应为2个[填充]字节，将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:
对于HIPI-800，硬件地址是一个10字节的单元，其中应包含交换机地址和ULA。硬件地址的格式为：
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 |
+---------------+---------------+
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[4]中定义的12位HIPPI逻辑地址。有关详细信息，请参见下一节。
Two switch addresses are considered to be the same when they have the same 12 bit destination HIPPI logical address.
如果两个交换机地址具有相同的12位目标HIPPI逻辑地址，则认为它们是相同的。
NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6- byte ULA. Therefore the length of the hardware address clearly defines which version of HIPPI is being used.
注意：对于HIPPI-6400，硬件地址仅为6字节的ULA。因此，硬件地址的长度清楚地定义了正在使用的HIPPI版本。
IEEE Standard 802.1A [11] specifies the Universal LAN MAC Address format. The globally unique part of the 48-bit space is administered by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA. Multiple ULAs may be used if a port contains more than one IEEE 802.2 LLC protocol entity.
IEEE标准802.1A[11]规定了通用LAN MAC地址格式。48位空间的全局唯一部分由IEEE管理。HIPPI-SC LAN上的每个端口都应分配一个ULA。如果一个端口包含多个IEEE 802.2 LLC协议实体，则可以使用多个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:
其HARP消息中的HIPPI硬件地址格式遵循IEEE 802.1A规范位顺序和HIPPI-FP位和字节顺序。例如，HIPPI硬件地址中请求者的ULA部分将分解为：
31 23 15 7 0
+---------------+---------------+---------------+---------------+
|ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 |
+---------------+---------------+
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
通用局域网MAC地址格式
L (U/L bit) = 1 for Locally administered addresses, 0 for Universal. G (I/G bit) = 1 for Group addresses, 0 for Individual.
L（U/L位）=1表示本地管理的地址，0表示通用地址。G（I/G位）=1表示组地址，0表示单个地址。
The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is REQUIRED if a port wishes to interoperate with a conventional network.
ULAs的使用是可选的，但建议使用。如果端口希望与传统网络互操作，则需要使用ULAs。
ULAs may also be used by bridging devices that replace HIPPI hardware headers with the MAC headers of other LANs.
ULA也可由桥接设备使用，桥接设备将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，以及InARP协议[15,7]。此外，HARP还为[12]中介绍的ARP_NAK使用了额外的操作代码。HARP/InHARP消息格式的其余部分不同于[15,7,10]中定义的ARP/InARP消息格式，也不同于第一个“HIPPI上的IP和ARP”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（十进制）进行传输。此外，如果接收到硬件类型代码为28、1或6（十进制），则应接受HARP消息。
The HARP message has several fields that have the following format and values:
HARP消息有几个字段，其格式和值如下：
Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address
数据大小和字段含义：ar$hrd 16位硬件类型ar$pro 16位以下协议字段的协议类型ar$op 16位操作码（请求、应答或NAK）ar$pln每个协议地址的8位字节长度ar$rhl 8位请求者的HIPI硬件地址长度（q）ar$thl 8位目标的HIPI硬件地址长度（x）ar$rpa 32位请求方的协议地址ar$tpa 32位目标方的协议地址
ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address
ar$rha qbytes请求者的HIPI硬件地址ar$tha xbytes目标的HIPI硬件地址
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-应包含操作值（十进制）：1用于HARP_请求2用于HARP_回复8用于InHARP_请求9用于InHARP_回复10用于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硬件地址，则应包含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硬件地址，则应包含10个。对于HIPPI-6400，则应包含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中，它应包含请求者的硬件地址。在应答中，它应包含目标端口的硬件地址。
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. In other replies it SHALL contain the requester's HW addressA.
ar$tha-在请求和NAKs中，如果已知，则应包含目标的硬件地址，否则为零。在其他回复中，应包含请求者的硬件地址A。
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地址。
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的六个字节的格式应与HIPPI-LE标题中要求的格式相同（见第6.2节），但ULA与32位HIPPI字的对齐除外，这在ARP和HIPPI-LE之间是不同的。FDDI不需要进行位反转。
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP Message
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_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
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_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
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_请求消息格式相同，操作代码设置为HARP_NAK；i、 e.逐字节复制HARP_请求消息数据，以便传输，HARP_请求操作代码更改为HARP_NAK值。HARP为HARP_NAK使用附加的操作代码。因此，必须实现HARP_NAK。
The combined HIPPI-LE/HARP message contains ten addresses, two for the destination and two for the source of the message, three for the requester and three for the target:
组合HIPPI-LE/HARP消息包含十个地址，两个用于目标，两个用于消息源，三个用于请求者，三个用于目标：
Destination Switch Address (HIPPI-LE) Destination ULA (HIPPI_LE)
目标交换机地址（HIPPI-LE）目标ULA（HIPPI_LE）
Source Switch Address (HIPPI-LE) Source ULA (HIPPI-LE)
源交换机地址（HIPPI-LE）源ULA（HIPPI-LE）
Requester IP Address (HARP) Requester ULA (HARP) Requester Switch Address (HARP)
请求者IP地址（HARP）请求者ULA（HARP）请求者交换机地址（HARP）
Target IP Address (HARP) Target ULA (HARP) Target Switch Address (HARP)
目标IP地址（HARP）目标ULA（HARP）目标交换机地址（HARP）
Examples:
示例：
The following relations are true for a HARP_REQUEST and InHARP_REQUESTs.
以下关系适用于HARP_请求和InHARP_请求。
LIS without broadcast - Dest SW Addr = HARP server SW Addr
(with HARP server) Dest ULA = HARP server ULA
Source SW Addr = Requester's SW Addr
Source ULA = Requester's ULA
LIS 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广播模拟服务器模拟广播。
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 or.
本备忘录仅定义IP广播。它独立于底层硬件寻址和广播功能。通过查看IP地址，任何端口都可以区分定向到自身的IP通信量和发送给它的广播消息。所有IP广播信息应使用IP LIS广播地址或。
It is RECOMMENDED that the PIBES run on the same port as the HARP server. In that case, the PIBES SHALL use the same address as the HARP server.
建议PIBES与HARP服务器在同一端口上运行。在这种情况下，PIBES应使用与HARP服务器相同的地址。
HIPPI does not directly support multicast address, therefore there are no mappings available from IP multicast addresses to HIPPI multicast services. Current IP multicast implementations (i.e. MBONE and IP tunneling, see [9]) will continue to operate over HIPPI-based logical IP subnets if all IP multicast packets are sent using the same algorithm as if the packet were being sent to 255.255.255.255.
HIPPI不直接支持多播地址，因此没有从IP多播地址到HIPPI多播服务的映射。如果所有IP多播数据包使用与发送到255.255.255.255相同的算法发送，则当前IP多播实施（即MBONE和IP隧道，请参见[9]）将继续在基于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中，此类服务可以广播的带宽上限为：（总带宽）/（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 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 HARP用于定时传输协议[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还适用于通过HIPPI-800而不是IP解析与定时传输（STP）一起使用的地址。该RFC的消息类型和算法可用于STP（因为STP使用互联网地址），只要所有端口上都有IP over HIPPI实现。
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.
实现此交换机地址发现协议不需要端口，但鼓励这样做，因为它减少了管理开销。本节介绍的算法基于John Renwick的工作，详见RFC-1374[14]。发现过程的概念是扫描所有可能的交换机地址。接收到的消息将是包含一个交换机地址的消息。
If a port implements this algorithm it SHALL form a HIPPI-LE message as defined in HIPPI-LE: containing an Self_Address_Resolution_Request (see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address (set to the correct ULA for the sender), and the Source_Switch_Address and Destination_Switch_Address.
如果端口实现此算法，它将形成HIPPI-LE中定义的HIPPI-LE消息：包含自\u地址\u解析\u请求（参见[3]）PDU类型、源\u IEEE\u地址和目标\u IEEE\u地址（设置为发送方的正确ULA）、源\u交换机\u地址和目标\u交换机\u地址。
This self address resolution message uses the same HIPPI-LE message format as described in HIPPI-SC and HIPPI-LE: the Self Address Resolution Request PDU and Self Address Resolution Response PDU type codes and no piggybacked ULP data. The HIPPI-LE header contents for the request are:
该自地址解析消息使用与HIPPI-SC和HIPPI-LE中所述相同的HIPPI-LE消息格式：自地址解析请求PDU和自地址解析响应PDU类型代码，无搭载ULP数据。请求的HIPPI-LE标题内容为：
HIPPI-LE Message_Type is = 3, Self Addr. Resolution Request HIPPI-LE Destination_Address_Type = 0 (undefined) HIPPI-LE Destination_Switch_Address = X (X element scan range) HIPPI-LE Source_Address_Type = 0 (undefined) HIPPI-LE Source_Switch_Address = 0 (unknown) HIPPI-LE Destination_IEEE_Address = 0 HIPPI-LE Source_IEEE_Address = my ULA
HIPPI-LE消息类型=3，自添加。解析请求HIPPI-LE目的地\地址\类型=0（未定义）HIPPI-LE目的地\交换机\地址=X（X元素扫描范围）HIPPI-LE源\地址\类型=0（未定义）HIPPI-LE源\交换机\地址=0（未知）HIPPI-LE目的地\ IEEE \地址=0 HIPPI-LE源\ IEEE\地址=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-FP标头和带有HIPPI-LE标头的D1_区域。
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。端口应继续运行，直到它看到自己的自地址解析请求，或者它已到达末尾，这可能是另一个可配置值（默认0xFFF）。建议扫描的地址范围是可配置的，因为某些网络的设备不能正常处理HIPI-LE消息。
After a port sends the[se] request[s], two positive outcomes are possible:
端口发送[se]请求后，可能出现两种积极结果：
o the port receives its own request(s), and obtains one of its own Switch Address, or
o 端口接收自己的请求，并获得自己的一个交换机地址，或
o the port receives an AR_S_Response with the Destination_Switch_Address filled in.
o 端口接收AR_S_响应，并填写目标_交换机_地址。
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交换机安装有三个连接端口：x、y和a。每个端口都有一个唯一的硬件地址，该地址由交换机地址（例如SWx、SWy、SWa）和唯一的ULA（分别为ULAx、ULAy和ULAa）组成。有一个HARP服务器连接到一个交换机端口，该端口映射到地址HWa（SWa，ULAa），该地址是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启动：服务器的HARP表条目状态：挂起
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa after starting a table entry for HWa.
1. 在启动HWa的表条目后，端口Y启动其接口并向HWa发送InHARP_请求。
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy
HARP ar$tha = SWa ULAa
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = 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服务器接收Y的InHARP_请求，它检查源地址并扫描其表以查找匹配项。由于这是Y第一次连接到此服务器，因此没有条目，将创建一个条目，并用InHARP_请求中的信息加盖时间戳。然后，HARP服务器将发送包含其IP地址的InHARP_回复。
HIPPI-LE Destination_Switch_Address = SWy HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy * answer we were looking for
HIPPI-LE Destination\u Switch\u Address=SWy HIPPI-LE Source\u Switch\u Address=SWa HIPPI-LE Destination\u IEEE\u Address=ULAy HIPPI-LE Source\u IEEE\u Address=ULAa HARP ar$op=9（InHARP\u回复）HARP ar$rpa=IPs*HARP ar$tpa=IPy HARP ar$rha=SWa ULAa HARP ar$tha=SWy ULAy*我们正在寻找的答案
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_应答，为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）。
Port Y starts: its HARP table entry state for HWa: PENDING
端口Y启动：其HARP表条目状态为HWa:PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa, in this example the broadcast address, after starting a table entry.
1. 端口Y启动其接口，并在启动表条目后向HWa发送InHARP_请求，在本例中为广播地址。
HIPPI-LE Destination_Switch_Address = SWb
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAb
HIPPI-LE Source_IEEE_Address = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy
HARP ar$tha = SWb ULAb
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWb
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAb
HIPPI-LE Source_IEEE_Address = 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_请求的副本。客户端Y检查源地址。由于它们与Y在InHARP_请求中填写的内容相同，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的权威地址，并发送一个HARP_请求以获取Y的硬件地址：
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** 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_应答。
HIPPI-LE Destination_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 2 (HARP_Reply) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = SWy ULAy * HARP ar$tha = SWx ULAx * answer we were looking for
HIPPI-LE Destination\u Switch\u Address=SWx HIPPI-LE Source\u Switch\u Address=SWa HIPPI-LE Destination\u IEEE\u Address=ULAx HIPPI-LE Source\u IEEE\u Address=ULAa HARP ar$op=2（HARP\u回复）HARP ar$rpa=IPy HARP ar$tpa=IPx HARP$rha=SWy ULAy*HARP$tha=SWx ULAx*我们正在寻找的答案
3. Port X connects to port Y and transmits an IP message with the following information in the HIPPI-LE header:
3. 端口X连接到端口Y，并在HIPPI-LE报头中传输包含以下信息的IP消息：
HIPPI-LE Destination_Switch_Address = SWy HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Source_IEEE_Address = ULAx
HIPPI-LE目的地\交换机\地址=SWy HIPPI-LE源\交换机\地址=SWx HIPPI-LE目的地\ IEEE \地址=ULAy HIPPI-LE源\ IEEE \地址=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_请求，并以与HARP服务器相同的方式响应它们。
Like in 12.3.1, assume that X and Y are fully registered with the HARP server. Then the state of X and Y's HARP server table entry is: VALID. So lets look at the message traffic when X tries to send a message to Q. Further assume that interface Q is NOT configured UP, i.e. it is DOWN. Since X doesn't have an entry for Q,
与12.3.1一样，假设X和Y已在HARP服务器上完全注册。那么X和Y的HARP服务器表项的状态是：VALID。因此，让我们看看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服务器交换机地址，并发送一个HARP_请求，请求Q的硬件地址：
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** 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.
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标准802.2）逻辑链路控制协议数据单元的封装；（希皮-勒）。
[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，信息技术-高性能并行接口-串行规范；（希皮系列）。
[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.和C.Brown，“反向地址解析协议”，RFC 23901998年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] “TCP/IP协议套件中的安全问题”，《ACM计算机通信评论》，第19卷，第2期，第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.和M.Theimer，“反向地址解析协议”，RFC 903，1984年6月。
[11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.
[11] ANSI/IEEE标准802.2-1989，信息处理系统-局域网-逻辑链路控制，“局域网IEEE标准：逻辑链路控制”，IEEE，纽约，纽约，1985年。
[12] Laubach, Mark., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[12] 马克·劳巴赫，“ATM上的经典IP和ARP”，RFC2225，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.和A.Nicholson，“HIPPI上的IP和ARP”，RFC 1374，1992年10月。
[15] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[15] Renwick，J.，“IP超过HIPPI”，RFC 2067，1997年1月。
[16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[16] Reynolds，J.和J.Postel，“分配的数字”，标准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.
如果没有Greg Chesson、Carlin Otto、硅图形高性能互连小组（特别是Jim Pinkerton、Brad Strand和Jeff Young）以及负责HIPPI标准工作的ANSI T11.1工作组的专业知识的批判性审查，本备忘录不可能形成。
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]的第二部分，由John Renwick撰写。Dave Plummer编写的ARP[13]和T.Bradley和C.Brown编写的反向ARP[7]提供了本备忘录中介绍的HARP的基本算法。此外，HARP服务器基于[12]中提出的概念和模型，由Mark Laubach编写，他为HARP服务器奠定了结构基础。
15 Changes from RFC-1374 [14]
15对RFC-1374的变更[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排除在其范围之外，因为没有足够的实施经验。本备忘录旨在澄清和扩展RFC-1374中关于HIPPI的ARP定义，以便更容易实现，特别是考虑到与HIPPI-6400的前向互操作性。
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硬件地址格式，并消除HIPPI-LE ARP对HARP功能的要求。
o Explicit registration phase.
o 显式注册阶段。
o Additional message formats: InHARP requests and replies as well as HARP_NAKs.
o 其他消息格式：InHARP请求和回复以及HARP_NAKs。
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 Pitte Silicon Graphics Inc.1600圆形剧场公园路山景城，加利福尼亚州94043
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org
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.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。