RFC 2835
IP and ARP over HIPPI-6400 (GSN)
RFC 2835: IP and ARP over HIPPI-6400 (GSN) 🦋
Okay bestie, this one is a Standards Track RFC from May 2000, written by J.-M. Pittet at Silicon Graphics Inc. 💖 Its title is IP and ARP over HIPPI-6400 (GSN). The header doesn't list anything it obsoletes or updates, so it's a standalone spec. Let's get into it 🌸
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜
Copyright Notice 🎀
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🔥
Okay, so the ANSI T11.1 task force standardized HIPPI-6400, which is also called Gigabyte System Network (GSN) 😭 It's a physical-level, point-to-point, full-duplex link interface for reliable, flow-controlled transmission of user data at 6400 Mbit/s per direction ✨ There's a parallel copper cable interface for distances of up to 40 m, specified in HIPPI-6400-PH [1]. Longer-distance optical connections are standardized in 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, HIPPI-6400-SC [2], describes how HIPPI-6400 physical switches operate 💅 T11.1 mostly left the networking stuff out of scope, so this document is the one that specifies using HIPPI-6400 switches as IP local area networks 🧚
This doc also specifies a way to resolve IP addresses to HIPPI-6400 hardware addresses (HARP), and a way to emulate IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP 🍓 And the big goal? Defining IP and HARP so that HIPPI-800 and HIPPI-6400 equipment can interoperate, whether the networks are broadcast capable or not. Main character energy 👑🦋
Table of Contents 🌸
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Global concepts used . . . . . . . . . . . . . . . . 3
2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
3. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
3.1 Background . . . . . . . . . . . . . . . . . . . . . 5
3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
4. Internet Protocol . . . . . . . . . . . . . . . . . . . . 7
4.1 Packet Format . . . . . . . . . . . . . . . . . . . 7
4.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 7
4.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 Packet diagrams . . . . . . . . . . . . . . . 8
4.2 HIPPI-6400 Hardware address: Universal LAN MAC addr. 9
4.3 Maximum Transmission Unit - MTU . . . . . . . . . . 10
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 11
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 12
5.1.1 Selecting the authoritative HARP service . . . 12
5.1.2 HARP registration phase . . . . . . . . . . . 13
5.1.3 HARP operational phase . . . . . . . . . . . . 14
5.2 HARP Client Operational Requirements . . . . . . . . 15
5.3 Receiving Unknown HARP Messages . . . . . . . . . . 16
5.4 HARP Server Operational Requirements . . . . . . . . 16
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 18
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 18
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 19
6.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 19
6.2 HIPARP Message Formats . . . . . . . . . . . . . . . 21
6.2.1 Example Message encodings: . . . . . . . . . . 23
6.2.2 HARP_NAK message format . . . . . . . . . . . . 24
7. Broadcast and Multicast . . . . . . . . . . . . . . . . 24
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 25
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 25
7.4 A Note on Broadcast Emulation Performance . . . . . . 26
8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 26
9. Security Consierations . . . . . . . . . . . . . . . . . 26
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 27
11. HARP Examples . . . . . . . . . . . . . . . . . . . . . 27
11.1 Registr. Phase of Client Y on Non-broadcast Hardware 27
11.2 Registr. Phase of Client Y on Broadcast-capable . . 28
11.3 Operational Phase (phase II) . . . . . . . . . . . 29
11.3.1 Successful HARP_Resolve example . . . . . . 29
11.3.2 Non-successful HARP_Resolve example . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32
14. Author's Address . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . 331. Introduction ✨
HIPPI-6400 is a duplex data channel that can send and receive data at the same time, at nearly 6400 megabits per second 🔥 Its data transfers get chopped up into micropackets, and each one is made of 32 data bytes and 8 control bytes 🧚 HIPPI-6400 uses four multiplexed virtual channels, and those get allocated to control traffic, low latency traffic, and bulk traffic (see [1] for more details) 💅
Using small packets plus four virtual channels means big file transfers can't lock out a host or switch port for interactive traffic. That's so iconic 😭 HIPPI-6400 guarantees in order delivery of data, and it also supports link-level and end-to-end checksumming and credit-based flow control 🫶
HIPPI-6400-PH defines a 20-bit interface for copper cables running at 500 MBaud 🌈 That gives a user payload bandwidth of 6400 Mb/s (800,000,000 Bytes/sec) in each direction [8] 🦋
HIPPI-6400-SC [2] defines two types of switches: bridging and non-bridging. Bridging switches are required to support hardware broadcast, while non-bridging switches are not required to support broadcast. This memo lets you run IP and HARP coherently with both types of switches, which is giving full flexibility 💖
Gigabyte System Network(TM) (GSN) is just the marketing name for HIPPI-6400. It's a trademark of the High Performance Networking Forum (HNF; http://www.hnf.org), used by its member companies that make products complying with ANSI HIPPI-6400 standards 💜
2. Definitions 🌷
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]. Those words are the official rule words, so read them carefully 🙈
2.1 Global concepts used 🎀
Here's the setup. The terms "requester" and "target" identify the port starting the address resolution request, and the port whose address it wants to find, respectively 💅 This document uses HIPPI-800 and HIPPI-6400 when it's talking about concepts that apply to one or the other tech. When it says HIPPI, it means both technologies 🌸
Values are decimal unless otherwise noted. Formatting follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and byte ordering 🧚
2.2 Glossary 📖
Broadcast A distribution mode that sends a message to all ports. The sending port is part of "all," so it also gets a copy of the message it sent 🦋
Classical/Conventional Both terms are about networks, including Ethernet, FDDI, and other 802 LAN types, as opposed to HIPPI-SC LANs 🌈
Destination The HIPPI port that receives data from a HIPPI Source 💖
HARP HARP (HIPPI Address Resolution Protocol) describes the whole set of HIPPI-6400 address resolution encodings and algorithms defined in this memo. It's a mix and adaptation of the Internet Address Resolution Protocol (ARP), RFC-826 [14], and Inverse ARP (InARP) [5] (see section 5). HARP also covers the HIPPI-specific version of ARP (the protocol and the HIPPI-specific encoding, for both 800 and 6400) 👑
HARP table Every host has a HARP table holding the IP to hardware address mapping of IP members 💜
HRAL The HARP Request Address List. It's a list of ULAs that HARP messages get sent to when resolving names to addresses (see section 3.2) 🍓
Hardware (HW) address The hardware address of a port. It consists of a ULA (see section 4.2). Note: "port" in this document means a HIPPI port, and it's roughly the same as "interface" as it's used in other IP documents 🫶
Host An entity, usually a computer system, that may have one or more HIPPI ports and may serve as a client or a HARP server ✨
Port An entity made of one HIPPI Source/Destination dual simplex pair, connected by parallel or serial HIPPI to a HIPPI-SC switch, that transmits and receives IP datagrams. A port can be an Internet host, bridge, router, or gateway 🔥
PIBES The Protocol for Internet Broadcast Emulation Server (see section 7) 🧚
Source The HIPPI port that generates data to send to a HIPPI Destination 💅
Universal LAN MAC Address (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 🌈
3. IP Subnetwork Configuration 🌸
3.1 Background 🦋
ARP (address resolution protocol), as defined in [14], was meant to work on the 'local' cable. That definition gives ARP 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 the other LISs on the same HIPPI-6400 network 👑
HARP has LIS scope only, and it serves all ports in the LIS. Communication with ports outside the local LIS is usually handled by an IP router. That router is a HIPPI-6400 port attached to the HIPPI-6400 network, configured as a member of one or more LISs 🫶 This configuration MAY result in a number of disjoint LISs running over the same HIPPI-6400 network. With this model, ports on different IP subnets SHOULD communicate through an intermediate IP router, even though it might be possible to open a direct HIPPI-6400 connection between the two IP members over the network 💜 That's just a consequence of using IP and choosing to have multiple LISs on the same HIPPI-6400 fabric 🙈
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 🔥✨
3.2 HIPPI LIS Requirements ✨
Okay bestie, so for IP members (hosts and routers) running in a HIPPI-6400 LIS, the rule is super simple 💅:
- All members of the LIS SHALL have the same IP network/subnet address and address mask [4].
Next, here's the list of HIPPI-6400-specific parameters that MUST be implemented in every IP station plugged into the HIPPI-6400 network 🔌:
- HIPPI-6400 Hardware Address:
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.
- HARP Request Address List (HRAL):
The HRAL is an ordered list of two or more addresses that identify 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.
The HRAL MUST contain at least two HIPPI HW addresses that identify the individual HARP service(s) with 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.
The second address MUST be the standard HW address for the HARP server 00:10:3B:FF:FF:E0.
So the HRAL entries get sorted in this 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.Manual configuration of the addresses and address lists in this section is implementation dependent and beyond the scope of this memo. However, before any service or operation detailed in this memo gets used, clients MUST have HRAL address(es) configured as appropriate for their LIS 🫶.
4. Internet Protocol 🦋
4.1 Packet format 🎀
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.
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. ✨
D_ULA: Destination ULA SHALL be the ULA of the destination port.S_ULA: Source ULA SHALL be the ULA of the requesting port.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.
4.1.1 IEEE 802.2 LLC 💖
The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len.
The LLC values (in hexadecimal and decimal) SHALL be:
SSAP 0xAA 170 (8 bits)
DSAP 0xAA 170 (8 bits)
CTL 0x03 3 (8 bits)for a total length of 3 bytes. The 0x03 CTL value indicates the presence of a SNAP header.
4.1.2 SNAP 🌸
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes), indicating that the following two bytes are an Ethertype.
The Ethertype value SHALL be set as defined in Assigned Numbers [18]:
IP 0x0800 2048 (16 bits)
HARP = ARP = 0x0806 2054 (16 bits)The total size of the LLC/SNAP header is fixed at 8 bytes. 🍓
4.1.3 HIPPI-6400 802 Packet diagrams 🌈
The following diagram shows a HIPPI-6400 message carrying IEEE 802 data 👀:
|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 diagramThe 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.
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]).
|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 diagramAs shown in the figure above, the first eight bytes of the IP Datagram occupy the last eight bytes of the HIPPI-6400-PH [1] Header micropacket. 🧚♀️
4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA) 💜
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. 🔥
This memo assumes the use of "Logical Addressing" as described in Annex A.2 of HIPPI-6400-SC[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:
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 FormatL (U/L bit) = 1 for Locally administered addresses, 0 for Universal. G (I/G bit) = 1 for Group addresses, 0 for Individual.
4.3 Maximum Transmission Unit - MTU 🌟
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. 🙈
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].
The MTU for HIPPI-6400 LANs SHALL be 65280 (decimal) bytes.
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.
For HIPPI-6400 the byte accounting is:
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-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)5. HIPPI Address Resolution Protocol - HARP 🎀
Okay bestie, address resolution inside the HIPPI-6400 LIS SHALL make use of the HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI Address Resolution Protocol (InHARP). HARP gives you the same vibes as the Internet Address Resolution Protocol (ARP) ✨
HARP is based on ARP, which is defined in RFC-826 [14], except it has the HIPPI-6400 specific packet format 🦋 Normally, if you know someone's Internet address, conventional networks use ARP to find their hardware address. HARP takes those original protocol definitions and combines them into one coherent address resolution service that doesn't depend on whether the hardware can broadcast 🌸 InHARP is the same protocol as the original Inverse ARP (InARP) defined in [5], except again with the HIPPI-6400 specific packet format. If you know a hardware address, InARP lets you find the other party's Internet address 💜
This memo further REQUIRES the PIBES (see section 7) extension to the HARP protocol, which guarantees broadcast service for upper layer protocols like IP. Literally the glue holding it together 🫶
Internet addresses are assigned independently of ULAs. Before using HARP, each node MUST know its IP and its HW addresses. The ULA is optional but is RECOMMENDED if you want interoperability with conventional networks 🍓
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 👑
5.1 HARP Algorithm 🧚
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 that maps remote ports' IP addresses to ULAs. So when an application asks for 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 💅
HARP is a two phase protocol. The first phase is the registration phase and the second is the operational phase. During registration the port figures out whether it's connected to broadcast hardware or not. InHARP is used in the registration phase. On non-broadcast hardware, InHARP registers and sets up a table entry with the server. The operational phase works a lot like conventional ARP, just with a different message format 🌈
5.1.1 Selecting the authoritative HARP service
Within the HIPPI LIS, there SHALL be an authoritative HARP service. To pick it, each port needs to determine whether it's connected to a broadcast network. At any point in time there is only one authoritative HARP service 👑
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's connected to a broadcast capable network. In that case the rest of the HRAL is ignored and the authoritative HARP service is the broadcast entry 🦋
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 that sends an InHARP_REPLY counts as a responsive HARP server. The authoritative HARP service SHALL be the HARP server that appears first in the HRAL ✨
The order of addresses in the HRAL only matters 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). So if the authoritative HARP service stops responding, the port considers the next address in the HRAL as a candidate for the authoritative address and sends an InHARP_REQUEST 🫶
The authoritative HARP server SHOULD be considered non-responsive when it has failed to reply to: (1) one or more registration requests by the client (see sections 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 🙈 If the authoritative HARP server becomes non-responsive, then the registration process SHOULD be restarted. Alternative methods for choosing an authoritative HARP service are not prohibited 💖
5.1.2 HARP registration phase 🌸
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 move into the operational phase when either: (1) it receives its own InHARP_REQUEST, or (2) it receives an InHARP_REPLY from at least one of the HARP servers and has determined the authoritative HARP service as described in 5.1.1 ✨
When ports start up, they send an InHARP_REQUEST to the authoritative HRAL address. The first address tried is the broadcast address "FF:FF:FF:FF:FF:FF". There are two outcomes:
- The port sees its own
InHARP_REQUEST: then the port is connected to a broadcast capable network. The first address becomes, and stays, the authoritative address for the HARP service. - The port does not receive its
InHARP_REQUEST: then the port is connected to a non-broadcast capable network.
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).
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 is met for each address.
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).
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 🦋
InHARP is an application of the InARP protocol for a purpose it wasn't originally intended for 😭 The point is to register port IP address mappings with a HARP server if one exists, or to detect hardware broadcast capability.
If the HIPPI-6400-SC LAN supports broadcast, then the client sees its own InHARP_REQUEST message and SHALL complete the registration phase. The client SHOULD also note that it's connected to a broadcast capable network and use that info for aging the HARP server entry and for IP broadcast emulation, as specified in sections 5.4 and 5.6 respectively 💅
If the client doesn't see its own InHARP_REQUEST, it SHALL await an InHARP_REPLY before completing the registration phase. That reply also gives the client the protocol address the HARP server can be reached at. This is the case when the client happens to be connected to a non-broadcast capable HIPPI-6400-SC network 🌈
5.1.3 HARP operational phase 💜
Once a HARP client has completed registration, it enters the operational phase. In this phase, the HARP client SHALL gain and refresh its own HARP table information about other IP members by sending HARP_REQUESTs to the authoritative address in the HRAL and by receiving HARP_REPLYs. The client is fully operational during this phase 👑
In the operational phase, the client's behavior for requesting HARP resolution is the same whether the HIPPI-6400-SC switched network is broadcast or non-broadcast 🫶
The target of an address resolution request updates its address mapping tables with any new information it finds in the request. If it's 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:
- The port's IP address is in the target protocol address field (
ar$tpa) of the HARP message. - The port's ULA is in the ULA part of the Target Hardware Address field (
ar$tha) of the message. - The port is a HARP server.
NOTE: It is REQUIRED to have a HARP server run on a port that has a non-zero ULA. 🙈
5.2 HARP Client Operational Requirements 🍓
The HARP client is responsible for contacting the HARP server(s) to get its own HARP information registered, and to gain and refresh its own HARP entries about other IP members. As noted above, this means HARP clients MUST be configured with the hardware address of the HARP server(s) in the HRAL 💖
HARP clients MUST:
- When an interface is enabled (e.g.
ifconfig <interface> upwith an IP address) or assigned the first or an additional IP address (i.e. an IP alias), the client SHALL initiate the registration phase. - In the operational phase the client MUST respond to
HARP_REQUESTandInHARP_REQUESTmessages if it is the target port. If an interface has multiple IP addresses (e.g., IP aliases), then the client MUST cycle through all of the IP addresses and generate anInHARP_REPLYfor each one. In that case anInHARP_REQUESTwill get multiple replies. (Refer to Section 7, "Protocol Operation" in RFC-1293 [5].) - 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.
Explanation: This lets the HARP server update the clients when one of the server's mappings changes, similar to what gratuitous ARP does on Ethernet 🧚
- Generate and transmit
InHARP_REQUESTmessages as needed, and processInHARP_REPLYmessages appropriately (see sections 5.1.3 and 5.6). AllInHARP_REPLYmessages SHALL be used to build or refresh its client HARP table entries. (Refer to Section 7, "Protocol Operation" in [5].)
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 done either through an exchange of a HARP request/reply with the HARP server, or by repeating step 1. To cut down on redundant network traffic, this timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange 🌸
Explanation: The HARP_REQUEST shows the HARP server that the client is still alive. Receiving a HARP_REPLY tells the client that the server must have seen the HARP_REQUEST 🫶
If the registration phase showed that the underlying network supports broadcast, then the refresh sequence is NOT REQUIRED 🦋
5.3 Receiving Unknown HARP Messages 🙈
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 carry on with normal operation. A HARP client is NOT REQUIRED to return any message to the sender of the undefined message 💅
5.4 HARP Server Operational Requirements 💖
A HARP server MUST accept HIPPI-6400 connections from other HIPPI-6400 ports 🔌✨ The server expects an InHARP_REQUEST as the first message from the client. The server examines the IP address and the hardware address of the InHARP_REQUEST, then adds or updates its HARP table entry <IP address(es), ULA> along with the time stamp 🕰️
A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on what it has in its table. The HARP server replies SHALL contain the hardware type and corresponding format of the request (see also sec. 6) 🎀
The table below shows every possible source address combination on an incoming message and the action to take. "linked" means an existing "IP entry" is linked to a "hardware entry". It's possible to have an existing "IP entry" and an existing "hardware entry" that aren't linked to each other 👀
+---+----------+----------+------------+---------------------+
| # | 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 entryHere are examples of when each of these could happen (the numbers match the lines in the table above) 🧩
1: supplemental message
Just update the timer ⏱️
2: move an IP alias to an existing interface
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 aren't linked together, then:
- The 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.
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 🫶
3: move IP address to a new interface
If the InHARP_REQUEST requester's IP source address duplicates a table entry IP address, and the InHARP_REQUEST hardware source address doesn't match the table entry hardware address, then a new HW entry SHALL be created. The requester's IP address SHALL be moved from the original HW entry to the new one (see above) 🦋
4: add IP alias to table
If the InHARP_REQUEST requester's hardware source address duplicates a hardware source address entry, but there's no IP entry matching the received IP address, then the IP address SHALL be added to the hardware entry's previous IP address(es). (E.g. adding an IP alias) 🌸
5: fresh entry, add it
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 💜
A HARP server SHOULD use the PIBES (see sect. 7) to send out HARP_REPLYs to all hardware addresses in its table whenever the HARP server table changes mappings. This feature decreases the time stale entries hang around in the clients 🧹
If there are multiple addresses in the HRAL, then a server needs to act as a client to the other servers 🌈
5.5 HARP and Permanent ARP Table Entries 🎀
An IP station MUST have a mechanism (e.g. manual configuration) for determining what permanent entries it has. The details of that mechanism are beyond the scope of this memo 📝 The permanent entries allow interoperability with legacy HIPPI adapters which don't implement dynamic HARP yet and use a table-based static ARP. Permanent entries are not aged ⏳
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 🙌
5.6 HARP Table Aging ⏳
HARP table aging MUST be supported, since IP addresses (especially IP aliases) and also interfaces (with their ULA) are likely to move. When that happens, the mapping in the client's own HARP table/cache becomes invalid and stale 🥀
- When a client's HARP table entry ages beyond 15 minutes, a HARP client MUST invalidate the table entry.
- When a server's HARP table entry ages beyond 20 minutes, the HARP server MUST delete the table entry.
NOTE: the client SHOULD revalidate a HARP table entry before it ages, which restarts the aging time once 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 before transmitting any non-address resolution traffic to the port referred to by this entry 🚨
The client revalidates the entry by querying the HARP server. If a valid reply is received (e.g. HARP_REPLY), the entry is updated. If the address resolution service can't resolve the entry (e.g. HARP_NAK, "host not found"), the associated table entry is removed 🗑️ If the address resolution service isn't 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 update 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 💀
6. HARP Message Encoding 🧁
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: 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.
The ar$hrd field SHALL be used to tell the two packet formats apart. The reply SHALL be in the format of the request 🔍
6.1 Generic IEEE 802 ARP Message Format 🫧
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 purposes 📖
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.Where:
ar$hrd- SHALL contain 1. (Ethernet)ar$pro- SHALL contain the IP protocol code 2048 (decimal).ar$hln- SHALL contain 6.ar$pln- SHALL contain 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_NAKar$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$sha- in requests and NAKs it SHALL contain the requester's ULA. In replies it SHALL contain the target port's 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$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$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.
Here's the layout, bit by bit 🧩
|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 |
+><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+6.2. HIPARP Message Formats ✨
okay bestie, so HARP has to SHALL support the HIPARP hardware type (ar$hrd) = 28 (dec) [18], plus the same protocol type (ar$pro) and operation code (ar$op) formats that ARP and InARP already use [14,7]. HARP also adds one extra operation code for ARP_NAK, which comes from [11] 🫶. The rest of the HIPARP message format (defined in [13]) is different from the ARP/InARP format in [14,7,10], and it's also different from the one in the first "IP and ARP on HIPPI" RFC-1374 [16]. so it's not the same as the old stuff, no cap 💅
HARP messages have a bunch of fields, and here's how they're laid out 🎀
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 addressHere's the tea on what each field has to hold 👑
ar$hrd- SHALL contain 28. (HIPARP)ar$pro- SHALL contain the IP protocol code 2048 (decimal).ar$op- SHALL contain the operational value (decimal):- 1 for HARP_REQUESTs
- 2 for HARP_REPLYs
- 8 for InHARP_REQUESTs
- 9 for InHARP_REPLYs
- 10 for HARP_NAK
ar$pln- SHALL contain 4.ar$rln- SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 6.ar$thl- SHALL contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 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$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$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 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.
And here's the visual for the payload format for HARP/InHARP PDUs. it's giving architecture diagram 🧚
Payload Format for HARP/InHARP PDUs:
|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 Message6.2.1. Example Message encodings
okay, examples time, this is where it clicks 🦋 For this one, pretend the HARP server is on the HIPPI-6400 side and the clients, X and Y, are on the HIPPI-800 side of the non-broadcast capable network.
HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = IPx
HARP ar$rha = SWy ULAy HARP ar$tha = **
** is what we would like to find out
HARP_REPLY message format
HARP ar$op = 2 (HARP_REPLY)
HARP ar$rpa = IPx HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx * HARP ar$tha = SWy ULAy
* answer we were looking for
InHARP_REQUEST message format
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy HARP ar$tha = SWx ULAx
** is what we would like to find out
InHARP_REPLY message format
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPx * HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx HARP ar$tha = SWy ULAy
* answer we were looking for6.2.2. HARP_NAK message format
the HARP_NAK message is basically the received HARP_REQUEST copied over, just with the operation code switched to HARP_NAK, so it's literally the same vibe with a new label 💀 HARP also makes use of an extra operation code for HARP_NAK, and it MUST be implemented. no skipping this one bestie 🙅♀️
7. Broadcast and Multicast ✨
okay so HIPPI-6400-SC requires compliant systems to support broadcast 📣 Initial HIPPI-6400-SC systems MAY defer broadcast capability to a broadcast server instead of doing it directly in the switching mechanism. A centralized HARP server setup covers two of the three major jobs of a broadcast server, and it's giving main character energy 👑
A central entity serving the whole LIS solves the coordination problem you'd have with a distributed approach. The registration requirement takes care of the second problem, which is figuring out which addresses make up the set loosely called "everyone" 🫶 The last job of a broadcast server is to copy an incoming packet and send it to "everyone".
During its registration phase, every port, including HARP server(s), finds out whether the underlying medium can do broadcast (see section 5.1.1). If it can't, then the HARP server(s) MUST emulate broadcast through an IP broadcast emulation server 😭
A HIPPI IP broadcast server (PIBES) is an extension to the HARP server, and it only makes sense when the LIS doesn't inherently support broadcast. The PIBES lets common upper layer networking protocols (RIP, TCP, UDP, etc.) access IP LIS broadcast ✨
7.1. Protocol for an IP Broadcast Emulation Server - PIBES
so to fake broadcast inside 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 check that every incoming message has a source address that matches an address in the target list. Only messages addressed to the IP LIS broadcast addresses, a multicast address, or 255.255.255.255 count as valid for broadcasting. Invalid messages MUST be dropped. All valid incoming messages shall be forwarded to all addresses in the target list 💅
It is RECOMMENDED that the broadcast server runs on the same port as the HARP server, since this memo doesn't define how the valid HARP table gets exchanged 🍓 The default address to use for the broadcast address is the operational HARP server address.
7.2. IP Broadcast Address
this memo only defines IP broadcast, and it's independent of the underlying hardware addressing and broadcast capabilities 🌈 Any port can tell IP traffic meant for itself apart from a broadcast message sent to it, just by looking at the IP address. All IP broadcast messages SHALL use the IP LIS broadcast address.
It is RECOMMENDED that the PIBES runs on the same port as the HARP server. In that case, the PIBES SHALL use the same address as the HARP server 🦋
7.3. IP Multicast Address
HIPPI-6400 doesn't directly support multicast addresses, so there are no mappings from IP multicast addresses to HIPPI multicast services 🙈 Current IP multicast implementations (i.e. MBONE and IP tunneling, see [7]) will keep working over HIPPI-based logical IP subnets as long as all IP multicast packets are sent with the same algorithm as if the packet were going to 255.255.255.255. ✨
7.4. A Note on Broadcast Emulation Performance
it's 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)the reason is that each message has to enter the broadcast server first (that's the extra 1) and then get sent to all n ports. The broadcast server could forward the message meant for the port it runs on internally, which turns (n+1) into (n) as a first optimization 🔥
This service is good enough for standard networking protocols like RIP, OSPF, NIS, etc., since they usually use a small fraction of the network bandwidth for broadcast 🫶 For those purposes, the broadcast emulation server defined in this memo lets the HIPPI-6400 network look similar to an Ethernet network to the higher layers 🌸
It's also obvious that this kind of emulation can't be used to broadcast high bandwidth traffic 💀 For that, hardware support for true broadcast is required.
8. HARP for Scheduled Transfer ✨
this RFC also applies to 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.
9. Security Consierations 💅
⚠️ this section is serious, bestie, so read it carefully 😭
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.
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 🙈
10. Open Issues 🌈
synchronization and coordination of multiple HARP servers and multiple broadcast servers are left for further study 🧚
okay that's the vibe for this part, more is coming 💖
11 HARP Examples 🧚
okay bestie, let's walk through some real HARP traffic. 🎀 We're setting up a HIPPI-6400-SC switch with three ports: x, y, and a. Each port has its own unique hardware address, made of a unique ULA: ULAx, ULAy, and UlAa. A HARP server sits on the port mapped to HWa, and that's the authoritative HIPPI hardware address in the HRAL (HARP Request Address List). 💅
The HARP server's table starts out empty 🫙. Ports X and Y each know their own hardware address, and they eventually want to talk to each other. Each one knows the other's IP address from the port database, but neither knows the other's ULA 🙈. Both ports have their interfaces configured DOWN to start.
NOTE: The LLC, SNAP, Ethertype,ar$hrd,ar$pro, andar$plnfields are left out of the examples below because they're constant.ar$rhlandar$thlare left out too, and they're both 6 because these are all HIPPI-6400 examples. 🌸
11.1 Registration Phase of Client Y on Non-broadcast Hardware
Port Y starts with its HARP table entry state for the server set to PENDING. ✨
- Port Y initiates its interface and sends an InHARP_REQUEST to
HWaafter starting a table entry forHWa. 🦋
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- The HARP server gets Y's InHARP_REQUEST, checks the source addresses, and scans its tables for a match. Since this is Y's first time connecting, there's no entry yet, so the server makes one and timestamps it using the info from the InHARP_REQUEST. Then it sends back an InHARP_REPLY that includes its own IP address. 🧚
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- Port Y reads the incoming InHARP_REPLY and completes its table entry for the HARP server. The client's HARP table entry for the server now moves into the VALID state and is ready for regular HARP traffic 🎉. Getting this reply is how Y knows the HARP server has properly registered the client. 💖
11.2 Registration Phase of Client Y on Broadcast Capable Hardware
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). 📡
Port Y starts with its HARP table entry state for HWa set to PENDING. 💜
- Port Y initiates its interface and sends an InHARP_REQUEST to HWa, which in this example is the broadcast address, after starting a table entry. 📣
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- Because the network is broadcast, client Y receives a copy of its own InHARP_REQUEST. Y checks the source addresses. They match what Y filled in, so Y can work out that it's connected to a broadcast medium 🕵️♀️. Port Y then completes its table entry for HWa. This entry won't time out, since it's considered unlikely that a particular underlying hardware type will switch between broadcast and non-broadcast, so this mapping will never change. 🔒
11.3 Operational Phase (phase II)
The Operational Phase of HARP, as specified in this memo, is the same for both broadcast and non-broadcast capable HIPPI-6400 hardware. 🔁 For simplicity in this example, the authoritative address in the HRAL is HWa: <SWa, ULAa>, and IPs is used too.
11.3.1 Successful HARP_Resolve example
Assume the same process (steps 1-3 of section 11.1) happened for port X. Now the HARP server table entry is in the VALID state for both X and Y. So let's look at the message traffic when X tries to send a message to Y. Since X doesn't have an entry for Y yet: 💌
- Port X connects to the authoritative address of the HRAL and sends a HARP_REQUEST for Y's hardware address. 🙋♀️
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- The HARP server gets the HARP request and updates its entry for X if needed. Then it builds a HARP_REPLY with Y's hardware address information 🪄.
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- Port X connects to port Y and transmits an IP message with the following info in the HIPPI-LE header 🚀:
HIPPI-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAx
<data>If the network were broadcast-capable, the target ports would have received the HARP_REQUEST from step 2 above themselves and responded in the same way the HARP server did. 📻
11.3.2 Non-successful HARP_Resolve example
As in 11.3.1, assume X and Y are fully registered with the HARP server, so the HARP server table entries for X and Y are VALID. Now let's see the message traffic when X tries to send a message to Q. Further assume that interface Q is NOT configured UP, which means it's DOWN. 😬 Since X doesn't have an entry for Q:
- Port X connects to the HARP server switch address and sends a HARP_REQUEST for Q's hardware address. 🙏
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- The HARP server gets the HARP request and updates its entry for X if needed. Then it looks up IPq in its tables and doesn't find it. So the HARP server builds a HARP_NAK reply message. 🙅♀️
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 were broadcast-capable, there would be no reply at all. 🤫
12 References 📚
[1] ANSI NCITS 323-1998, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[2] ANSI NCITS 324-199x, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Switch Control (HIPPI-6400-SC).
[3] ANSI NCITS Project Number 1249-D, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Optical Specification (HIPPI-6400-OPT).
[4] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[5] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[7] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects 1996, Stanford University.
[10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control IEEE, IEEE, New York, New York, 1989.
[11] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November, 1990.
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834, May 2000.
[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.
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[17] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
13 Acknowledgments 🫶
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. 👏
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. 🌈
14 Author's Address 💌
Jean-Michel Pittet
Silicon Graphics Inc
1600 Amphitheatre Parkway
Mountain View, CA 94040
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org15. Full Copyright Statement 💖
Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀
okay so bestie, this is the legal part 💅 The Internet Society owns the copyright, and here's what you're allowed to do with this doc:
- You can copy it and hand it out to other people, and you can translate it. 🌸
- You can make derivative works that comment on it, explain it, or help people implement it, and publish and distribute those too. 🧚
- Every copy and every derivative work has to keep the copyright notice and this paragraph. No skipping it! 🫶
The one thing you can't do is modify the document itself. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations, for example. ✨ There are two exceptions: you can change it when it's needed to develop Internet standards (and then the Internet Standards process copyright procedures have to be followed), or you can change it to translate it into languages other than English. 🌈
The permissions I just described are perpetual. The Internet Society and its successors or assigns can't take them back. 💜
Now the important part, and I need you to read it fr fr 🚨 This document and everything in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe anyone's rights, and any implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 💀 Basically, they're not promising it'll work for whatever you want, so be careful. 🙈
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 Thank you to them for keeping the RFC process running! 🫶💖
📦 where this page comes from
- ietf: rfc2835 2000-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms