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)
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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].
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Global concepts used . . . . . . . . . . . . . . . . 3
2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
Pittet Standards Track [Page 1]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
Pittet Standards Track [Page 2]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
1. Introduction
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).
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-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-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.
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.
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].
2.1 Global concepts used
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.
Values are decimal unless otherwise noted. Formatting follows IEEE
802.1A canonical bit order and HIPPI-6400-PH bit and byte ordering.
Pittet Standards Track [Page 3]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
2.2 Glossary
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.
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. 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 table
Each host has a HARP table which contains the IP to hardware address
mapping of IP members.
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).
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.
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.
Pittet Standards Track [Page 4]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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.
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. 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.
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.
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.
Pittet Standards Track [Page 5]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
3.2 HIPPI LIS Requirements
The requirement for IP members (hosts, routers) operating in a
HIPPI-6400 LIS configuration is:
o All members of the LIS SHALL have the same IP network/subnet
address and address mask [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:
o 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.
o HARP Request Address List (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.
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.
The second address MUST be the standard HW address for the HARP
server 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.
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.
Pittet Standards Track [Page 6]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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.
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
indicating that the following two-bytes is 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.
Pittet Standards Track [Page 7]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 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.
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]).
Pittet Standards Track [Page 8]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
|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.
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.
Pittet Standards Track [Page 9]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 Format
L (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.
Pittet Standards Track [Page 10]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
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).
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.
This memo further REQUIRES the PIBES (see section 7) extension to the
HARP protocol, guaranteeing broadcast service to upper layer
protocols like 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.
Pittet Standards Track [Page 11]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 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.
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.
5.1.1 Selecting the authoritative HARP service
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.
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.
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.
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
Pittet Standards Track [Page 12]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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.
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.
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 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.
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:
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.
2. 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 are 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).
Pittet Standards Track [Page 13]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 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.
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.
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.
5.1.3 HARP operational phase
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.
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.
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.
2. The port's ULA, is in the ULA part of the Target Hardware Address
field (ar$tha) of the message.
3. The port is a HARP server.
Pittet Standards Track [Page 14]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
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 clients MUST:
1. When an interface is enabled (e.g. "ifconfig <interface> up" with
an IP address) or assigned the first or an additional IP address
(i.e. an IP alias), the client SHALL initiate the registration
phase.
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].)
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.
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.
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].)
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.
Pittet Standards Track [Page 15]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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.
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 continue 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 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.
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).
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 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
Pittet Standards Track [Page 16]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
Just update 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 are not linked together, then:
- HWa entry needs to have its reference to the current IPa
address removed.
- HWb needs to have a new reference to IPa added
- IPa needs to be linked to HWb
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 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).
4: add IP alias to table
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).
5: fresh entry, add it
Standard case, create both entries and link them.