Network Working Group J.-M. Pittet
Request for Comments: 2835 Silicon Graphics Inc.
Category: Standards Track May 2000
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.
版权所有（C）互联网协会（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工作组已将HIPPI-6400（也称为千兆字节系统网络（GSN））标准化，这是一种物理级、点对点、全双工、链路接口，用于以6400 Mbit/s的速度以每个方向可靠、流控制地传输用户数据。HIPPI-6400-PH[1]中规定了距离不超过40m的平行铜电缆接口。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 PDU[10]的封装，并暗示了GSN上的IP。另一个T11.1标准描述了HIPPI-6400物理交换机HIPPI-6400-SC的操作[2]。T11.1选择将HIPPI-6400网络问题大部分排除在其标准范围之外；本文件规定将HIPPI-6400交换机用作IP局域网。本文件进一步规定了将IP地址解析为HIPPI-6400硬件地址（HARP）的方法，以及将逻辑IP子网（LIS）中的IP广播模拟为HARP的直接扩展的方法。此外，本备忘录的目标是定义IP和HARP，以实现HIPI-800和HIPI-6400设备的互操作性，包括广播和非广播网络。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Global concepts used . . . . . . . . . . . . . . . . 3
2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
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
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是一个双工数据通道，可以以接近每秒6400兆的速度同时发送和接收数据。HIPPI-6400数据传输被分割成微包，每个微包由32个数据字节和8个控制字节组成。HIPPI-6400使用四个多路复用虚拟通道。这些虚拟通道被分配用于控制流量、低延迟流量和批量流量（有关更多详细信息，请参见[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.
使用小数据包和四个虚拟通道，大文件传输无法锁定主机或交换机端口以进行交互通信。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定义了一个20位接口，用于在500毫巴下工作的铜电缆。这在每个方向上提供6400 Mb/s（80000000字节/秒）的用户有效负载带宽。[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]定义了两种类型的开关：桥接和非桥接。桥接交换机需要支持硬件广播。非桥接交换机不需要支持广播。此备忘录允许使用这两种类型的交换机连贯地实现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.
千兆字节系统网络（TM）（GSN）是HIPPI-6400的市场名称。它是高性能网络论坛（HNF；http://www.hnf.org)供提供符合ANSI HIPPI-6400标准产品的成员公司使用。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
除非另有说明，否则数值为十进制。格式化遵循IEEE 802.1A标准位顺序和HIPPI-6400-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.
向所有端口发送消息的一种分发模式。发送端口是“全部”的一部分，因此也将接收已发送消息的副本。
Classical/Conventional
古典/传统
Both terms are used with respect to networks, including 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 (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还描述了HIPPI（800和6400）ARP的特定版本（即协议和HIPPI特定编码）。
HARP table
竖琴桌
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
每个主机都有一个HARP表，其中包含IP成员的IP到硬件地址映射。
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
硬件（硬件）地址
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.
一种实体，通常是一个计算机系统，可能有一个或多个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连接到HIPPI-SC交换机，并传输和接收IP数据报。端口可以是Internet主机、网桥、路由器或网关。
PIBES
皮布斯
The Protocol for Internet Broadcast Emulation Server (see section 7).
Internet广播仿真服务器的协议（参见第7节）。
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 [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中配置其主机和路由器。每个LIS独立于同一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路由器提供。此路由器是连接到HIPPI-6400网络的HIPPI-6400端口，该网络配置为一个或多个LIS的成员。这种配置可能导致许多不相交的LIS在同一HIPPI-6400网络上运行。使用此模型，不同IP子网的端口应通过中间IP路由器进行通信，即使可以通过HIPI-6400网络在两个IP成员之间打开直接的HIPI-6400连接。这是使用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:
以下列表确定了必须在连接到HIPI-6400网络的每个IP站中实施的HIPI-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是两个或多个地址的有序列表，用于标识地址解析服务。所有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. By default the first address MUST be the reserved address for broadcast, i.e. FF:FF:FF:FF:FF:FF.
HRAL必须包含至少两个HIPPI HW地址，用于标识对解决LIS内所有IP成员的HARP请求负有权威责任的单个HARP服务。默认情况下，第一个地址必须是广播的保留地址，即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.
第二个地址必须是HARP服务器00:10:3B:FF:FF:E0的标准硬件地址。
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条目按以下顺序排序：第一：广播地址（FF:FF:FF:FF:FF）必需第二：官方HARP服务器地址（00:10:3B:FF:FF:E0）必需第三&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]。HIPI-6400-PH数据包的长度（包括标题和尾随填充）应为HIPI-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.
目的港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设置为IEEE 802数据包（例如IP或HARP消息）长度+8字节，以说明LLC/SNAP报头长度。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值（十六进制和十进制）应为
SSAP 0xAA 170 (8 bits) DSAP 0xAA 170 (8 bits) CTL 0x03 3 (8 bits)
SSAP 0xAA 170（8位）DSAP 0xAA 170（8位）CTL 0x03 3（8位）
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个字节），表示以下两个字节为以太网类型。
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
|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.
下图显示了长度为n的IP数据报，其中包含填充字节（值：0x0）。“<><>”表示微包分离。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]数据包将始终跨越两个或多个微数据包。第一个微包的类型为头。第二个和任何进一步的微分组具有类型=数据（参见[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
|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数据报的前八个字节占用HIPPI-6400-PH[1]头微数据包的最后八个字节。
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].
本备忘录假设使用HIPI-6400-SC[2]附录A.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位和字节顺序：
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) |
+---------------+---------------+---------------+---------------+
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
通用局域网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表示单个地址。
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报头。传统局域网的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]将数据包限制在4G字节左右（在VC 3上），这对网络目的没有实际限制。选择用于IP和ARP通信的HIPPI-6400-PH VC 1将消息限制在128 KB左右，仍然比HIPPI-800 MTU大[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数据包装入一个64K字节的缓冲区，开销高达256字节。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)
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)
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提供与Internet地址解析协议（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基于RFC-826[14]中定义的ARP，但HIPPI-6400特定数据包格式除外。知道因特网地址后，传统网络使用ARP来发现另一个节点的硬件地址。本节中介绍的HARP进一步规定了原始协议定义的组合，以形成独立于硬件广播能力的一致地址解析服务。InHARP与[5]中介绍的原始反向ARP（InARP）协议相同，但HIPPI-6400特定数据包格式除外。知道其硬件地址后，INRAP用于发现另一方的Internet地址。
This memo further REQUIRES the PIBES (see section 7) 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. 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.
Internet地址的分配独立于ULA。在使用HARP之前，每个节点必须知道其IP和硬件地址。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在每个端口中创建一个表，该表将远程端口的IP地址映射到ULA，以便当应用程序通过其IP地址请求连接到远程端口时，可以确定远程ULA，可以构建正确的HIPPI-6400-PH头，并且可以使用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是一个两阶段协议。第一阶段是登记阶段，第二阶段是运作阶段。在注册阶段，端口检测是否连接到广播硬件。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服务。
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中的第一个地址发送InHARP_请求（FF:FF:FF:FF:FF）。如果端口看到自己的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 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
HRAL中的地址顺序只对决定哪个地址是权威地址很重要。在非广播网络上，端口需要与HRAL中的所有HARP服务器地址保持“注册”（注意：不是广播地址，因为
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.
它不是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 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_请求消息来启动注册阶段。当：（1）客户收到自己的InHARP_请求，或（2）客户收到至少一个HARP服务器的InHARP_回复，并且客户已确定5.1.1中所述的权威HARP服务时，客户应终止注册阶段并过渡到运营阶段。
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_请求。要尝试的第一个地址将是广播地址“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_请求：则该端口连接到不支持广播的网络。
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).
端口应选择HRAL中的下一个地址作为HARP服务器的候选地址，并向该地址发送InHARP_请求：（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中的每个非广播HARP服务器地址一次，直到每个地址满足以下终止标准之一。
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. 如果端口接收到自己的消息，那么端口本身就是HARP服务器，需要该端口使用PIBES提供广播服务（参见第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_回复，则它是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_请求消息，并应完成注册阶段。客户应进一步注意，它连接到一个支持广播的网络，并使用此信息老化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_请求，则应在完成注册阶段之前等待InHARP_回复。这还将为客户端提供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客户端应通过向HRAL中的权威地址发送HARP_请求和接收HARP_回复来获取并刷新其自身关于其他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.
在操作阶段，对于广播或非广播HIPI-6400-SC交换网络，客户端请求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, 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. 该端口是一个HARP服务器。
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信息，并获取和刷新其自己的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 [5].)
2. 在操作阶段，如果是目标端口，客户端必须响应HARP_请求和InHARP_请求消息。如果接口有多个IP地址（例如，IP别名），则客户端必须循环访问所有IP地址，并为每个此类地址生成InHARP_回复。在这种情况下，InHARP_请求将有多个回复。（参考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_回复应用于更新和刷新其自己的客户端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.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_请求消息，并适当处理InHARP_回复消息（见第5.1.3和5.6节）。所有InHARP_回复消息应用于构建/刷新其客户端HARP表条目。（参考[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_请求/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 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客户端接收到一条HARP消息，其中包含它不支持的操作代码（ar$op），则它必须优雅地丢弃该消息并继续正常操作。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_请求作为来自客户端的第一条消息。服务器检查InHARP_请求的IP地址和硬件地址，并添加或更新其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_请求和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
+---+----------+----------+------------+---------------------+
| # | 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
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_请求的IP源地址与表项IP地址（例如IPa<->HWa）重复，且InHARP_请求硬件源地址与硬件地址项（例如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是HWb条目引用的唯一IP地址，则结果将是一个带有：IPb<->HWa<->IPb的表，然后删除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 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服务器表更改映射时，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 the invalidated 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. 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_NAK，“找不到主机”），则删除关联的表条目。如果地址解析服务不可用（即“服务器故障”），则客户端必须通过将InHARP_请求发送到相关条目的硬件地址，并在收到InHARP_回复后更新条目，尝试重新验证条目。如果InHARP_请求尝试未能返回InHARP_回复，则删除关联的表项。
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数据包格式。HARP信息应在非广播硬件上以28的硬件类型代码传输，或在任何情况下均为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字段应用于区分两种数据包格式。答复应采用请求的格式。
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$hrd 16位硬件类型ar$pro 16位以下协议字段的协议类型ar$hln每个硬件地址的8位字节长度ar$pln每个协议地址的8位字节长度ar$op 16位操作码（ares_op$请求| ares_op$回复）ar$sha此数据包发送方的48位硬件地址ar$spa此数据包发送方的32位协议地址ar$tha此ar$tpa目标方的48位硬件地址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-应包含操作值（十进制）：1用于HARP_请求2用于HARP_回复8用于InHARP_请求9用于InHARP_回复10用于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-在请求和NAK中，如果已知，则应包含目标的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 |
+><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+
|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和InARP协议[14,7]。此外，HARP还为[11]中介绍的ARP_NAK使用了额外的操作代码。HIPARP消息格式的其余部分（定义见[13]）不同于[14,7,10]中定义的ARP/InARP消息格式，也不同于第一个“HIPI上的IP和ARP”RFC-1374[16]中定义的格式。
The HARP message has several fields that have the following format and values:
HARP消息有几个字段，其格式和值如下：
Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address
数据大小和字段含义：ar$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请求者的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.
ar$tha-在请求和NAKs中，如果已知，则应包含目标的硬件地址，否则为零。
In other replies it SHALL contain the requester's HW address.
在其他回复中，应包含请求者的硬件地址。
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
|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_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
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_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
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_请求消息格式相同，操作代码设置为HARP_NAK；i、 e.复制HARP_请求消息数据以进行传输，HARP_请求操作代码更改为HARP_NAK值。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服务器体系结构满足广播服务器三个主要职责中的两个。
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”的集合。广播服务器的最后一项职责是复制传入的数据包并将其发送给“所有人”。
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服务器在同一端口上运行。在这种情况下，PIBES应使用与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多播数据包使用与发送到255.255.255.255相同的算法发送，则当前IP多播实施（即MBONE和IP隧道，请参见[7]）将继续在基于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还适用于通过HIPPI-6400而不是IP解析与定时传输（ST）一起使用的地址。该RFC的消息类型和算法可用于ST（因为ST使用互联网地址），只要所有端口上都有IP over HIPPI-6400实现。
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规范的流动状态、技术的新颖性和其他因素，目前并不是所有与HIPPI-6400上的ARP相关的安全问题都被清楚地理解。然而，考虑到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交换机安装有三个连接端口：x、y和a。每个端口都有一个唯一的硬件地址，该地址由唯一的ULA组成（分别为ULAx、ULAy和UlAa）。有一个HARP服务器连接到映射到地址HWa的交换机端口，该地址是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地址（从端口数据库），但都不知道对方的地址。端口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启动：服务器的HARP表条目状态：挂起
1. Port Y initiates its interface and sends an InHARP_REQUEST to the HWa after starting a table entry for the HWa.
1. 在启动HWa的表条目后，端口Y启动其接口并向HWa发送InHARP_请求。
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
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服务器接收Y的InHARP_请求，它检查源地址并扫描其表以查找匹配项。由于这是Y第一次连接到此服务器，因此没有条目，将创建一个条目，并用InHARP_请求中的信息加盖时间戳。然后，HARP服务器将发送包含其IP地址的InHARP_回复。
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竖琴ar$op=9（回复）竖琴ar$rpa=IPs*竖琴ar$tpa=IPy竖琴ar$rha=ULAa竖琴ar$tha=ULAy*我们正在寻找的答案
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. 端口Y检查传入的InHARP_应答，并为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）。
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-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
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_请求的副本。客户端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-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的权威地址，并发送一个HARP_请求以获取Y的硬件地址：
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
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_应答。
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_回复）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_请求，并以与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服务器表项的状态是：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-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
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.
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] Bradely，T.和C.Brown，“反向地址解析协议”，RFC 23901998年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] “TCP/IP协议套件中的安全问题”，《ACM计算机通信评论》，第19卷，第2期，第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] Chesson，Greg，“HIPPI-6400概述”，IEEE热互连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标准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”，RFC2225，1998年4月。
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November, 1990.
[12] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834, May 2000.
[13] Pitte，J.-M.，“HIPPI-800上的ARP和IP广播”，RFC 28342000年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，麻省理工学院，1982年11月。
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[15] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[16] Renwick，J.和A.Nicholson，“HIPPI上的IP和ARP”，RFC 1374，1992年10月。
[17] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[17] Renwick，J.，“IP超过HIPPI”，RFC 2067，1997年1月。
[18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[18] Reynolds，J.和J.Postel，“分配的数字”，标准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.
如果没有Greg Chesson、Carlin Otto、硅图形高性能互连小组（特别是Jim Pinkerton、Brad Strand和Jeff Young）以及负责HIPPI标准工作的ANSI T11.1工作组的专业知识的批判性审查，本备忘录不可能形成。
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]的第二部分，由John Renwick撰写。Dave Plummer编写的ARP[14]和Terry Bradley和Caralyn Brown编写的反向ARP[7]提供了本备忘录中介绍的HARP的基本算法。此外，HARP服务器基于[13]中提出的概念和模型，由Mark Laubach编写，他为HARP服务器奠定了结构基础。
14 Author's Address
14提交人地址
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94040
Jean-Michel Pitte Silicon Graphics Inc.加利福尼亚州山景大道1600号圆形剧场，邮编94040
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
15 Full Copyright Statement
15完整版权声明
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编辑功能的资金目前由互联网协会提供。