As per Relevance of the word hardware, we have this rfc below:
Network Working Group J.-M.
Request for Comments: 2834 Silicon Graphics Inc
Obsoletes: 1374 May 2000
Category: Standards
ARP and IP Broadcast over HIPPI-800
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document specifies a method for resolving IP addresses to
High-Performance Parallel Interface (HIPPI) hardware addresses
for emulating IP broadcast in a logical IP subnet (LIS) as a
extension of HARP. This memo defines a HARP that will
between HIPPI-800 and HIPPI-6400 (also known as Gigabyte
Network, GSN). This document (when combined with RFC-2067 "IP
HIPPI") obsoletes RFC-1374.
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Global Concepts . . . . . . . . . . . . . . . . . . . 3
3.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 3
4. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
4.1 Background . . . . . . . . . . . . . . . . . . . . . 5
4.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 7
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 8
5.1.1 Selecting the authoritative HARP service . . . 8
5.1.2 HARP registration phase . . . . . . . . . . . . 9
5.1.3 HARP operational phase . . . . . . . . . . . . 10
5.2 HARP Client Operational Requirements . . . . . . . . . . 11
5.3 Receiving Unknown HARP Messages . . . . . . . . . . . 12
5.4 HARP Server Operational Requirements . . . . . . . . 12
Pittet Standards Track [Page 1]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 14
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 14
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 15
6.1 HIPPI-LE Header of HARP Messages . . . . . . . . . . 15
6.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 16
6.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 16
6.1.3 Diagram . . . . . . . . . . . . . . . . . . . . 17
6.2 HIPPI Hardware Address Formats and Requirements . . . 18
6.2.1 48-bit Universal LAN MAC Addresses . . . . . . 18
6.3 HARP and InHARP Message Formats . . . . . . . . . . . 19
6.3.1 Example Message encodings . . . . . . . . . . . 22
6.3.2 HARP_NAK message format . . . . . . . . . . . . 22
6.3.3 Combined HIPPI-LE and HARP message addresses . 22
7. Broadcast and Multicast . . . . . . . . . . . . . . . . . 23
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 23
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 24
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 24
7.4 A Note on Broadcast Emulation Performance . . . . . . 24
8. HARP for Scheduled Transfer Protocol . . . . . . . . . . 25
9. Discovery of One's Own Switch Address . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . 26
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 26
12. HARP Examples . . . . . . . . . . . . . . . . . . . . . . 26
12.1 Registration Phase of Client Y on Non-broadcast HW . 27
12.2 Registration Phase of Client Y on Broadcast Hardware 28
12.3 Operational Phase (phase II) . . . . . . . . . . . . 28
12.3.1 Standard successful HARP_Resolve example . . 29
12.3.2 Standard non-successful HARP_Resolve example 30
13. References . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32
15. Changes from RFC-1374 . . . . . . . . . . . . . . . . . . 32
16. Author's Address . . . . . . . . . . . . . . . . . . . . 33
17. Full Copyright Statement . . . . . . . . . . . . . . . . 34
1.
The ANSI High-Performance Parallel Interface (HIPPI) is a
simplex data channel. HIPPI can send and receive
simultaneously at 800 or 1600 megabits per second. Between 1987
1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1)
Standardized five documents that bear on the use of HIPPI as
network interface. They cover the physical and
specification (HIPPI-PH [1]), the framing of a stream of
(HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC (HIPPI-LE [3]),
behavior of a physical layer switch (HIPPI-SC [4]) and the physical
level and optical specification (HIPPI-Serial [5]). HIPPI-LE
implies the encapsulation of Internet Protocol[5]. The reader
be familiar with the ANSI HIPPI documents. Approved ANSI
Pittet Standards Track [Page 2]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
standards are available from ANSI (http://www.ansi.org). The
documents of the T11.1 working group may be obtained from the T11
page (http://www.t11.org/).
HIPPI switches can be used to connect a variety of computers
peripheral equipment for many purposes, but the working group
short of describing their use as Local Area Networks. RFC-2067 [15]
describes the encapsulation of IP over HIPPI-800. This memo takes
where the working group and RFC-2067 [15] left off and
address resolution and LIS IP broadcast emulation for HIPPI-800
networks
While investigating possible solutions for HARP it became
that IP broadcast could easily be emulated for both HIPPI-800
HIPPI-6400 hardware types. This is useful since HIPPI switches
not required to implement broadcast but many standard
protocols rely on broadcast. This memo therefore further
the emulation of LIS IP broadcast as an extension of HARP
2
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119 [18].
3.
3.1 Global concepts
In the following discussion, the terms "requester" and "target"
used to identify the port initiating the address resolution
and the port whose address it wishes to discover, respectively.
not all switches in the LIS support broadcast then there will be
HARP server providing the address resolution service and it will
the source of the reply. If on the other hand all switches
broadcast then the source address of a reply will be the target'
target address
Values are decimal unless otherwise noted. Formatting follows
802.1A canonical bit order and and HIPPI-FP bit and byte order
3.2
A distribution mode which transmits a message to all ports
Particularly also the port sending the message
Pittet Standards Track [Page 3]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Classical/
Both terms are used to refer to networks such as Ethernet, FDDI,
other 802 LAN types, as distinct from HIPPI-SC LANs
The HIPPI port that receives data from a HIPPI Source
HARP describes the whole set of HIPPI address resolution
and algorithms defined in this memo. HARP is a combination
adaptation of the Internet Address Resolution Protocol (ARP) RFC-826
[13] and Inverse ARP (InARP) [7] (see section 5). HARP also
the HIPPI specific version of ARP [10] (i.e. the protocol and
HIPPI specific encoding).
HARP
Each host has a HARP table which contains the IP to hardware
mapping of IP members
HIPPI-
An implementation of HIPPI in serial fashion on coaxial cable
optical fiber. (see [5])
The HARP Request Address List. A list of ULAs to which HARP
are sent when resolving names to addresses (see section 4.2).
Hardware (HW)
The hardware address of a port consisting of an I-Field and
optional ULA (see section 6.2). Note: the term port as used in
document refers to a HIPPI port and is roughly equivalent to the
"interface" as commonly used in other IP documents
An entity, usually a computer system, that may have one or more
ports and which may serve as a client or a HARP server
Pittet Standards Track [Page 4]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
An entity consisting of one HIPPI Source/Destination dual
pair that is connected by parallel or serial HIPPI to a HIPPI-
switch and that transmits and receives IP datagrams
The Protocol for Internet Broadcast Emulation Server (see section 7).
Switch
A value used as the address of a port on a HIPPI-SC network. It
transmitted in the I-field. HIPPI-SC switches map Switch
to physical switch port numbers. The switch address is extended
a mode byte to form an I-Field (see [4] and 6.2.2)
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,
to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN
4. IP Subnetwork
4.1
ARP (address resolution protocol) as defined in [12] was meant
work on the 'local' cable. This definition gives the ARP protocol
local logical IP subnet (LIS) scope. In the LIS scenario,
separate administrative entity configures its hosts and
within the LIS. Each LIS operates and communicates independently
other LIS's on the same HIPPI network
HARP has LIS scope only and serves all ports in the LIS
Communication to ports located outside of the local LIS is
provided via an IP router. This router is a HIPPI port attached
the HIPPI network that is configured as a member of one or
LIS's. This configuration MAY result in a number of disjoint LIS'
operating over the same HIPPI network. Using this model, ports
different IP subnets SHOULD communicate via an intermediate IP
even though it may be possible to open a direct HIPPI
between the two IP members over the HIPPI network. This is
consequence of using IP and choosing to have multiple LIS's on
same HIPPI fabric
Pittet Standards Track [Page 5]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
By default, the HARP method detailed in section 5 and the
LIS routing model MUST be available to any IP member client in
LIS
4.2 HIPPI LIS
The requirement for IP members (hosts, routers) operating in a
LIS configuration is
o All members of the LIS SHALL have the same IP network/
address and address mask [6].
The following list identifies the set of HIPPI-specific
that MUST be implemented in each IP station connected to the
network
o HIPPI Hardware Address
The HIPPI hardware address of an individual IP port MUST
the port's Switch Address (see section 9). The address SHOULD
contain a non-zero ULA address. If there is no ULA then that
MUST be zero
o HARP Request Address List (HRAL):
The HRAL is an ordered list of two or more addresses
the address resolution service(s). All HARP clients MUST
configured identically, i.e. all ports MUST have the
addresses(es) in the HRAL
The HRAL MUST contain at least two HIPPI HW addresses
the individual HARP service(s) that have
responsibility for resolving HARP requests of all IP
located within the LIS
By default the first address MUST be the reserved address
broadcast, i.e. the address for "IP traffic
directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The
for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF
It is REQUIRED that the second address be the address
"Messages pertaining to (the) ... address resolution requests
0xFE0" [4]. The ULA for this HARP server entry
00:00:00:00:00:00.
Pittet Standards Track [Page 6]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Therefore, the HRAL entries are sorted in the following order
1st ** : broadcast address (0x07000FE1 FF:FF:FF:FF:FF:FF),
2nd ** : official HARP server address (0x07000FE0 00:00:00:00:00:00),
3rd & on: any additional HARP server addresses will be sorted
decreasing order of the 12bit destination
address portion of their I-Field (see section 6.2).
**
Within the restrictions mentioned above and in Section 6.2.2,
administration choose address(es) for the additional HARP
which they will put into the HRAL
An example of such a list
1st entry: 0x07000FE1 FF:FF:FF:FF:FF:
2nd entry: 0x07000FE0 00:00:00:00:00:00
3rd entry: 0x07000001 <Alternate-HARP-server-ula
...
Manual configuration of the addresses and address lists presented
this section is implementation dependent and beyond the scope of
memo
5. HIPPI Address Resolution Protocol -
Address resolution within the HIPPI LIS SHALL make use of the
Address Resolution Protocol (HARP) and the Inverse HIPPI
Resolution Protocol (InHARP). HARP provides the same functionality
the Internet Address Resolution Protocol (ARP). HARP is based on
which is defined in RFC-826 [13]. Knowing the Internet address
conventional networks use ARP to discover another port's
address. HARP presented in this section further specifies
combination of the original protocol definitions to form a
address resolution service that is independent of the hardware'
broadcast capability
InHARP is based on the original Inverse ARP (InARP)
presented in [7]. Knowing its hardware address, InARP is used
discover the other party's Internet address
This memo further REQUIRES the PIBES (see section 7 below)
to the HARP protocol, guaranteeing broadcast service to upper
protocols like IP
Internet addresses are assigned independent of ULAs and
addresses. Before using HARP, each port MUST know its IP and
hardware addresses. The ULA is optional but is RECOMMENDED
bridging to conventional networks is desired
Pittet Standards Track [Page 7]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
5.1 HARP
This section defines the behavior and requirements for
implementations on both broadcast and non-broadcast capable HIPPI-
networks. HARP creates a table in each port which maps the IP
of each port to a hardware address, so that when an
requests a connection to a remote port by its IP address,
hardware address can be determined, a correct HIPPI-LE header can
built, and a connection to the port can be established using
correct Switch Address in the I-field
HARP is a two phase protocol. The first phase is the
phase and the second phase is the operational phase. In
registration phase the port detects if it is connected to
hardware or not. The InHARP protocol is used in the
phase. In case of non-broadcast capable hardware, the
Protocol will register and establish a table entry with the server
The operational phase works much like conventional ARP with
exception of the message format
5.1.1 Selecting the authoritative HARP
Within the HIPPI LIS, there SHALL be an authoritative HARP service
At each point in time there is only one authoritative HARP service
To select the authoritative HARP service, each port needs
determine if it is connected to a broadcast network
The port SHALL send an InHARP_REQUEST to the first address in
HRAL (0x07000FE1 FF:FF:FF:FF:FF:FF). If the port sees its
InHARP_REQUEST, then it is connected to a broadcast capable network
In this case, the rest of the HRAL is ignored and the
HARP service is the broadcast entry
If the port is connected to a non-broadcast capable network, then
port SHALL send the InHARP_REQUEST to all of the remaining entries
the HRAL. Every address which sends an InHARP_REPLY is considered
be a responsive HARP server. The authoritative HARP service SHALL
the HARP server which appears first in the HRAL
The sequence of the HRAL is only important for deciding which
will be the authoritative one. On a non-broadcast network, the
is REQUIRED to keep "registered" with all HARP server addresses
the HRAL (NOTE: not the broadcast address since it is not a
server address). If for instance the authoritative HARP service
non-responsive, then the port will consider the next address in
HRAL as a candidate for the authoritative address and send
InHARP_REQUEST
Pittet Standards Track [Page 8]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
The authoritative HARP server SHOULD be considered non-
when it has failed to reply to: (1) one or more registration
by the client (see section 5.1.2 and 5.2), (2) any two HARP_
in the last 120 seconds or (3) if an external agent has
failure of the authoritative HARP server. The details of such
external agent and its interaction with the HARP client are
the scope of this document. Should an authoritative HARP
become non-responsive, then the registration process SHOULD
restarted. Alternative methods for choosing an authoritative
service are not prohibited
5.1.2 HARP registration
HARP clients SHALL initiate the registration phase by sending
InHARP_REQUEST message using the addresses in the HRAL in order.
client SHALL terminate the registration phase and transition into
operational phase, either when it receives its own InHARP_REQUEST
when it receives an InHARP_REPLY from at least one of the
servers and when it has determined the authoritative HARP service
described in section 5.1.1.
When ports are initiated they send an InHARP_REQUEST to
authoritative address as described in section 5.1.2. The
address to be tried will be the broadcast address "0x07000FE
FF:FF:FF:FF:FF:FF". There are two outcomes
1. The port sees its own InHARP_REQUEST: then the port is
to a broadcast capable network. The first address becomes
remains the authoritative address for the HARP service
2. The port does not receive its InHARP_REQUEST: then the port
connected to a non-broadcast capable network
In the second case, the port SHALL choose the next address in
HRAL as a candidate for a authoritative address and send
InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).
o If the port receives its own message, then the port itself is
HARP server and the port is REQUIRED to provide broadcast
using the PIBES (see section 7).
o If the port receives an InHARP_REPLY, then it is a HARP client
not a HARP server
In both cases, the current candidate address becomes
authoritative HARP service address
Pittet Standards Track [Page 9]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
If the client determines it is connected to a non-broadcast
network then the client SHALL continue to retry each non-
HARP server address in the HRAL at least once every 5 seconds
one of these two termination criteria are met for each address
InHARP is an application of the InARP protocol for a purpose
originally intended. The purpose is to accomplish registration
port IP address mappings with a HARP server if one exists or
hardware broadcast capability
If the HIPPI-SC LAN supports broadcast, then the client will see
own InHARP_REQUEST message and SHALL complete the registration phase
The client SHOULD further note that it is connected to a
capable network and use this information for aging the HARP
entry and for IP broadcast emulation as specified in sections 5.4
5.6 respectively
If the client doesn't see its own InHARP_REQUEST, then it SHALL
an InHARP_REPLY before completing the registration phase. This
also provide the client with the protocol address by which the
server is addressable. This will be the case when the client
to be connected to a non-broadcast capable HIPPI-SC network
5.1.3 HARP operational
Once a HARP client has completed its registration phase it enters
operational phase. In this phase of the protocol, the HARP
SHALL gain and refresh its own HARP table which contains the IP to
address mapping of IP members by sending HARP_REQUESTS to
authoritative address in the HRAL and receiving HARP_REPLYs.
client is fully operational during the operational phase
In the operational phase, the client's behavior for requesting
resolution is the same for broadcast or non-broadcast networks
The target of an address resolution request updates its
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
of the following statements is true of the request
1. The port's IP address is in the target protocol address
(ar$tpa) of the HARP message
2. The port's ULA (if non-zero), is in the ULA part of the
Hardware Address field (ar$tha) of the message
Pittet Standards Track [Page 10]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
3. The port's switch address is in the Target Switch Address field
Target Hardware Address field (ar$tha) of the message (see
6.2.2).
4. The port is a HARP server
NOTE: It is RECOMMENDED that all HARP servers run on a ports
each have a non-zero ULA
5.2 HARP Client Operational
The HARP client is responsible for contacting the HARP server(s)
have its own HARP information registered and to gain and refresh
own HARP entry/information about other IP members. This means,
noted above, that HARP clients MUST be configured with the
address of the HARP server(s) in the HRAL
HARP clients MUST
1. When an interface is enabled (e.g. "ifconfig <interface> up"
an IP address) or assigned the first or an additional IP
(i.e. an IP alias), the client SHALL initiate the
phase
2. In the operational phase the client MUST respond to HARP_
and InHARP_REQUEST messages if it is the target port. If
interface has multiple IP addresses (e.g., IP aliases) then
client MUST cycle through all the IP addresses and generate
InHARP_REPLY for each such address. In that case an InHARP_
will have multiple replies. (Refer to Section 7, "
Operation" in RFC-1293 [7].)
3. React to address resolution reply messages appropriately to
or refresh its own client HARP table entries. All solicited
unsolicited HARP_REPLYs from the authoritative HARP server
be used to update and refresh its own client HARP table entries
Explanation: This allows the HARP server to update the
when one of server's mappings change, similar to what
accomplished on Ethernet with gratuitous ARP
4. Generate and transmit InHARP_REQUEST messages as needed
process InHARP_REPLY messages appropriately (see section 5.1.2
5.6). All InHARP_REPLY messages SHALL be used by the client
build or refresh its HARP table entries. (Refer to Section 7,
"Protocol Operation" in [7].)
Pittet Standards Track [Page 11]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
If the registration phase showed that the hardware does not
broadcast, then the client MUST refresh its own entry for the
server, created during the registration phase, at least once every 15
minutes. This can be accomplished either through the exchange of
HARP request/reply with the HARP server or by repeating step 1.
decrease the redundant network traffic, this timeout SHOULD be
after each HARP_REQUEST/HARP_REPLY exchange
Explanation: The HARP_REQUEST shows the HARP server that the
is still alive. Receiving a HARP_REPLY indicates to the client
the server must have seen the HARP_REQUEST
If the registration phase shows that the underlying network
broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations
step 4 are NOT REQUIRED
5.3 Receiving Unknown HARP
If a HARP client receives a HARP message with an operation
(ar$op) that it does not support, it MUST gracefully discard
message and continue normal operation. A HARP client is NOT
to return any message to the sender of the undefined message
5.4 HARP Server Operational
A HARP server MUST accept HIPPI connections from other HIPPI ports
The HARP server expects an InHARP_REQUEST as the first message
the client. A server examines the IP source address, the
source address of the InHARP_REQUEST and adds or updates its
table entry as well as
time stamp
A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs
on the information which it has in its HARP table. The HARP
SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has
requested information in its tables; otherwise it SHALL reply with
HARP_NAK. The HARP server replies SHALL contain the hardware type
corresponding format of the request (see also section 6).
The following table shows all possible source address combinations
an incoming message and the actions to be taken. "linked"
that an existing "IP entry" is linked to a "hardware entry". It
possible to have an existing "IP entry" and to have an
"hardware entry" but neither is linked to the other
Pittet Standards Track [Page 12]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
+---+----------+----------+------------+---------------------+
| # | 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
a: break the existing IP -> hardware (HW) - old
b: delete HW(old) -> IP link and decrement HW(old) refcount,
refcount = 0, delete HW(old
c: create new IP
d: create new HW
e: add new IP -> HW link to IP
f: add new HW -> IP link to HW
Examples of when this could happen (Numbers match lines in
table):
1: supplemental
Just update timer
2: move an IP alias to an existing
If the IP source address of the InHARP_REQUEST duplicates a
entry IP address (e.g. IPa <-> HWa) and the InHARP_
hardware source address matches a hardware address entry (e.g.
<-> IPb), but they are not linked together, then
- HWa entry needs to have its reference to the current
address removed
- HWb needs to have a new reference to IPa
- IPa needs to be linked to
3: move IP address to a new
If the InHARP_REQUEST requester's IP source address duplicates
table entry IP address and the InHARP_REQUEST hardware
address does not match the table entry hardware address, then
new HW entry SHALL be created. The requestor's IP address SHALL
moved from the original HW entry to the new one (see above).
Pittet Standards Track [Page 13]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
4: add IP alias to
If the InHARP_REQUEST requester's hardware source
duplicates a hardware source address entry, but there is no
entry matching the received IP address, then the IP address
be added to the hardware entries previous IP address(es). (E.g
adding an IP alias).
5: fresh entry, add
Standard case, create both entries and link them
A server MUST update the HARP table entry's timeout for
HARP_REQUEST. Explanation: if the client is sending HARP requests
the server, then the server SHOULD note that the client is
"alive" by updating the timeout on the client's HARP table entry
A HARP server SHOULD use the PIBES (see section 7) to send
HARP_REPLYs to all hardware addresses in its table when the
server table changes mappings. This feature decreases the time
stale entries in the clients
If there are multiple addresses in the HRAL, then a server needs
act as a client to the other servers
5.5 HARP and Permanent ARP Table
An IP station MUST have a mechanism (e.g. manual configuration)
determining what permanent entries it has. The details of
mechanism are beyond the scope of this memo. The permanent
allow interoperability with legacy HIPPI adapters which do not
implement dynamic HARP and use a table-based static ARP.
entries are not aged
The HARP server SHOULD use the static entries to resolve
HARP_REQUESTs from the clients. This feature eliminates the need
maintaining a static HARP table on the client ports
5.6 HARP Table
HARP table aging MUST be supported since IP addresses, especially
aliases and also interfaces (with their ULA), are likely to move
When so doing the mapping in the clients own HARP table/cache
invalid and stale
o When a client's HARP table entry ages beyond 15 minutes, a
client MUST invalidate the table entry
Pittet Standards Track [Page 14]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
o When a server's HARP table entry ages beyond 20 minutes, the
server MUST delete the table entry
NOTE: the client SHOULD revalidate a HARP table entry before it ages
thus restarting the aging time when the table entry is
revalidated. The client MAY continue sending traffic to the
referred to by this entry while revalidation is in progress, as
as the table entry has not aged. The client MUST revalidate an
entry prior to transmitting any non-address-resolution traffic to
port referred to by this entry
The client revalidates the entry by querying the HARP server with
HARP_REQUEST. If a valid reply is received (e.g. HARP_REPLY),
entry is updated. If the address resolution service cannot
the entry (e.g. HARP_NAK, "host not found"), the associated
entry is removed. If the address resolution service is not
(i.e. "server failure") the client MUST attempt to revalidate
entry by transmitting an InHARP_REQUEST to the hardware address
the entry in question and updating the entry on receipt of
InHARP_REPLY. If the InHARP_REQUEST attempt fails to return
InHARP_REPLY, the associated table entry is removed
6. HARP Message
The HARP Message is encapsulated over HIPPI-FP and HIPPI-LE headers
The HARP FP header values are to be set as defined in RFC-2067 "
over HIPPI" [15]. The following sections detail the HIPPI-LE
contents and HARP message structure and contents. In a
capable network the client MAY also support Type 1 and 6,
and IEEE 802 ARP packet formats
6.1 HIPPI-LE Header of HARP
The HIPPI message format for Internet datagrams shall conform to
HIPPI-FP [2] and HIPPI-LE [3] standards. The length of a
message, including trailing fill, shall be a multiple of eight
as required by HIPPI-LE. The HIPPI-LE header fields of HARP
InHARP requests and replies SHALL be
FC (3 bits) SHALL contain zero
Double-wide SHOULD be set according to HIPPI-LE [3]. This memo
NOT address the implications on HARP when this bit is set to 1
indicating the possibility of a port being able to accept 64-
HIPPI connections
Pittet Standards Track [Page 15]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Message_Type SHALL contain 0 to indicate a data message.
messages are identified using the Ethertype and the message type
the ar$op field of the HARP message
Destination_Switch_Address, SHALL be the Switch Address of
destination port
Destination_IEEE_Address SHALL be the ULA of the destination port,
known, otherwise zero
Destination_Address_Type SHALL be 2, a 12-bit logical address.
behavior with type = 1, source routing, is NOT defined in
specification
Source_Switch_Address in requests SHALL be the sender's
Address
Source_IEEE_Address SHALL be the sender's ULA if known,
zero
Source_Address_Type SHALL be 2, a 12-bit logical address.
behavior with type = 1, source routing, is NOT defined in
specification
6.1.1 IEEE 802.2
The IEEE 802.2 LLC Header SHALL begin in the first byte of
HIPPI-FP D2_Area
The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes
indicating the presence of a SNAP header
6.1.2
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 [16]:
InHARP = InARP = HARP = ARP = 2054 = 0x0806.
The total size of the LLC/SNAP header is fixed at 8-bytes
Pittet Standards Track [Page 16]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
6.1.3 HIPPI-LE header
HIPPI-LE header for HARP/InHARP PDUs
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 = IP ULP |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | n + 8 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|M_Type | 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | D_A_T | S_A_T | 000 | Source Switch Addr |
+-------+-------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 |Message byte 0 |Message byte 1 |Message byte 2 | . . . |
+---------------+---------------+---------------+--- |
| . . . |
+ ------------+---------------+---------------+---------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HIPPI Message
Words 0-1: HIPPI-FP
Words 2-7: D1_Area (HIPPI-LE Header
Words 8-9: D2_Area (IEEE 802.2 LLC/SNAP
Words 10-(N-1): D2_Area (HARP message
(n+8) is the nb of bytes in the HARP message, incl. LLC/SNAP
+====+ denotes the boundary between D1_Area and D2_Area
[LA] fields are zero unless used otherwise locally
Abbreviations
"W" = Double_Wide field SHALL be 0
"M_Type" = Message_Type field SHALL be set according
HIPPI-
"D_A_T" = Destination_Address_Type SHALL be 2
Pittet Standards Track [Page 17]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
"S_A_T" = Source_Address_Type SHALL be 2
[FILL] bytes complete the HIPPI message to an
number of 32 bit words. The number of fill
is not counted in the data length
6.2 HIPPI Hardware Address Formats and
For HIPPI-800, the Hardware Address is a 10-byte unit that
contain the Switch Address AND the ULA. The format of a
address is
31 23 15 7 0
+---------------+---------------+-------+-------+---------------+
| Mode Byte | 00 | 0 | X | XX |
+---------------+---------------+-------+-------+---------------+
| ULA byte 0 | ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 |
+---------------+---------------+
Where "XXX" is the 12 bit HIPPI logical address defined in HIPPI-
[4]. Details on ULA see next section
Two switch addresses are considered to be the same when they have
same 12 bit destination HIPPI logical address
NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6-
byte ULA. Therefore the length of the hardware address
defines which version of HIPPI is being used
6.2.1 48-bit Universal LAN MAC
IEEE Standard 802.1A [11] specifies the Universal LAN MAC
format. The globally unique part of the 48-bit space is
by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA
Multiple ULAs may be used if a port contains more than one IEEE 802.2
LLC protocol entity
The format of the HIPPI hardware address within its HARP
follows IEEE 802.1A canonical bit order and HIPPI-FP bit and
order. For example the requester's ULA part of the HIPPI
address would decompose to
Pittet Standards Track [Page 18]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
31 23 15 7 0
+---------------+---------------+---------------+---------------+
|ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 |
+---------------+---------------+
Universal LAN MAC Address
L (U/L bit) = 1 for Locally administered addresses
0 for Universal
G (I/G bit) = 1 for Group addresses
0 for Individual
The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs
REQUIRED if a port wishes to interoperate with a
network
ULAs may also be used by bridging devices that replace HIPPI
headers with the MAC headers of other LANs
6.3 HARP and InHARP Message
The HARP protocols use the HIPARP hardware type (ar$hrd) [16],
protocol type (ar$pro), and operation code (ar$op) data formats
the ARP, and InARP protocols [15,7]. In addition, HARP makes use
an additional operation code for ARP_NAK introduced with [12].
remainder of the HARP/InHARP message format is different than
ARP/InARP message format defined in [15,7,10] and it is
different from the format defined in the first "IP and ARP on HIPPI
RFC-1374 [14].
HARP messages SHALL be transmitted with the HIPARP hardware type
of 28 (decimal). Furthermore, HARP messages SHALL be accepted
received with hardware type codes of either 28, 1 or 6 (decimal).
The HARP message has several fields that have the following
and values
Data sizes and field meaning
ar$hrd 16 bits Hardware
ar$pro 16 bits Protocol type of the protocol fields
ar$op 16 bits Operation code (request, reply, or NAK
ar$pln 8 bits byte length of each protocol
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
ar$tpa 32 bits target's protocol
Pittet Standards Track [Page 19]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
ar$rha qbytes requester's HIPPI Hardware
ar$tha xbytes target's HIPPI Hardware
Where :
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_
2 for HARP_
8 for InHARP_
9 for InHARP_
10 for HARP_
ar$pln - SHALL contain 4.
ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW
ELSE, for HIPPI-6400, it SHALL contain 6.
ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW
ELSE, for HIPPI-6400, it SHALL contain 6.
ar$rha - in requests and NAKs it SHALL contain the requester'
HW address. In replies it SHALL contain the
port's HW address
ar$rpa - in requests and NAKs it SHALL contain the requester's
address if known, otherwise zero
In other replies it SHALL contain the
port's IP address
ar$tha - in requests and NAKs it SHALL contain the target'
HW address if known, otherwise zero
In other replies it SHALL contain the requester'
HW addressA
ar$tpa - in requests and NAKs it SHALL contain
target's IP address if known, otherwise zero
In other replies it SHALL contain the requester'
IP address
The format of the six bytes of the ULA SHALL be the same as
in the HIPPI-LE header (see section 6.2), except for the alignment
the ULAs with respect to the 32-bit HIPPI word, which is
between ARP and HIPPI-LE. No bit reversal is necessary as
required with FDDI
Pittet Standards Track [Page 20]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP
Pittet Standards Track [Page 21]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
6.3.1 Example Message encodings
HARP_REQUEST
HARP ar$op = 1 (HARP_REQUEST
HARP ar$rpa = IPy HARP ar$tpa =
HARP ar$rha = SWy ULAy HARP ar$tha = 0 **
** is what we would like to find
HARP_REPLY message
HARP ar$op = 2 (HARP_REPLY
HARP ar$rpa = IPa HARP ar$tpa =
HARP ar$rha = SWa ULAa * HARP ar$tha = SWy
* answer we were looking
InHARP_REQUEST message
HARP ar$op = 8 (InHARP_REQUEST
HARP ar$rpa = IPy HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy HARP ar$tha = SWa
** is what we would like to find
InHARP_REPLY message
HARP ar$op = 9 (InHARP_REPLY
HARP ar$rpa = IPs * HARP ar$tpa =
HARP ar$rha = SWa ULAa HARP ar$tha = SWy
* answer we were looking
6.3.2 HARP_NAK message
The HARP_NAK message format is the same as the received HARP_
message format with the operation code set to HARP_NAK; i.e.
HARP_REQUEST message data is copied byte for byte for
with the HARP_REQUEST operation code changed to the HARP_NAK value
HARP makes use of an additional operation code for HARP_NAK. Hence
HARP_NAK MUST be implemented
6.3.3 Combined HIPPI-LE and HARP message
The combined HIPPI-LE/HARP message contains ten addresses, two
the destination and two for the source of the message, three for
requester and three for the target
Destination Switch Address (HIPPI-LE
Destination ULA (HIPPI_LE
Source Switch Address (HIPPI-LE
Source ULA (HIPPI-LE
Pittet Standards Track [Page 22]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Requester IP Address (HARP
Requester ULA (HARP
Requester Switch Address (HARP
Target IP Address (HARP
Target ULA (HARP
Target Switch Address (HARP
Examples
The following relations are true for a HARP_REQUEST
InHARP_REQUESTs
LIS without broadcast - Dest SW Addr = HARP server SW
(with HARP server) Dest ULA = HARP server
Source SW Addr = Requester's SW
Source ULA = Requester's
7 Broadcast and
HIPPI-SC does not require switches to support broadcast.
support has therefore been absent from many HIPPI networks
During its registration phase, every port, including HARP server(s),
discover if the underlying medium is capable of broadcast (
section 5.1.2). Should this not be the case, 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
server and only makes sense when the LIS does not inherently
broadcast. The PIBES allows common upper layer networking
(RIP, TCP, UDP, etc.) to access IP LIS broadcast
7.1 Protocol for an IP Broadcast Emulation Server -
To emulate broadcast within an LIS, a PIBES SHALL use the
valid HARP table of the HARP server as a list of addresses called
target list. The broadcast server SHALL validate that all
messages have a source address which corresponds to an address in
target list. Only messages addressed to the IP LIS
addresses, multicast address or 255.255.255.255 are considered
messages for broadcasting. Invalid messages MUST be dropped.
valid incoming messages shall be forwarded to all addresses in
target list
Pittet Standards Track [Page 23]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
It is RECOMMENDED that the broadcast server run on the same port
the HARP server since this memo does not define the protocol
exchanging the valid HARP table. The default address to use for
broadcast address is the operational HARP server address
7.2 IP Broadcast
This memo only defines IP broadcast. It is independent of
underlying hardware addressing and broadcast capabilities. Any
can differentiate between IP traffic directed to itself and
broadcast message sent to it by looking at the IP address. All
broadcast messages SHALL use the IP LIS broadcast address or
It is RECOMMENDED that the PIBES run on the same port as the
server. In that case, the PIBES SHALL use the same address as
HARP server
7.3 IP Multicast
HIPPI does not directly support multicast address, therefore
are no mappings available from IP multicast addresses to
multicast services. Current IP multicast implementations (i.e.
and IP tunneling, see [9]) will continue to operate over HIPPI-
logical IP subnets if all IP multicast packets are sent using
same algorithm as if the packet were being sent to 255.255.255.255.
7.4 A Note on Broadcast Emulation
It is obvious that a broadcast emulation service (as defined
section 7.1) has an inherent performance limit. In an LIS with
ports, the upper bound on the bandwidth that such a service
broadcast is
(total bandwidth)/(n+1)
since each message must first enter the broadcast server,
for the additional 1, and then be sent to all n ports. The
server could forward the message destined to the port on which
runs internally, thus reducing (n+1) to (n) in a first optimization
This service is adequate for the standard networking protocols
as RIP, OSPF, NIS, etc. since they usually use a small fraction
the network bandwidth for broadcast. For these purposes,
broadcast emulation server as defined in this memo allows the
network to look similar to an Ethernet network to the higher layers
It is further obvious that such an emulation cannot be used
broadcast high bandwidth traffic. For such a solution,
support for true broadcast is required
Pittet Standards Track [Page 24]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
8 HARP for Scheduled Transfer Protocol[17]
This RFC also applies for resolving addresses used with
Transfer (STP) over HIPPI-800 instead of IP. This RFC's
types and algorithms can be used for STP (since STP uses
Addresses) as long as there is also an IP over HIPPI
on all of the ports
9 Discovery of One's Own Switch
This HARP specification assumes that each port has prior knowledge
its own hardware address. This address may be manually configured
by means outside the scope of this memo or a port may discover
own logical address through the algorithm described below
Ports are NOT REQUIRED to implement this switch address
protocol but are encouraged to do so since it reduces
administrative overhead. The algorithm presented in this section
based on John Renwick's work as detailed in RFC-1374 [14].
concept of the discovery process is to scan all possible
addresses. The messages that are received will be the ones
one of our switch addresses
If a port implements this algorithm it SHALL form a HIPPI-LE
as defined in HIPPI-LE: containing an Self_Address_Resolution_
(see [3]) PDU Type, a Source_IEEE_Address
Destination_IEEE_Address (set to the correct ULA for the sender),
the Source_Switch_Address and Destination_Switch_Address
This self address resolution message uses the same HIPPI-LE
format as described in HIPPI-SC and HIPPI-LE: the Self
Resolution Request PDU and Self Address Resolution Response PDU
codes and no piggybacked ULP data. The HIPPI-LE header contents
the request are
HIPPI-LE Message_Type is = 3, Self Addr. Resolution
HIPPI-LE Destination_Address_Type = 0 (undefined
HIPPI-LE Destination_Switch_Address = X (X element scan range
HIPPI-LE Source_Address_Type = 0 (undefined
HIPPI-LE Source_Switch_Address = 0 (unknown
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = my
There is no D2 data; the message contains only the HIPPI-FP
and D1_Area with the HIPPI-LE header
Pittet Standards Track [Page 25]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Ports SHALL start the scan with a configurable logical
(default 0x000) and increment the value for by one for
subsequent try. The port SHALL continue until it sees its own
address resolution request or it has reached the end, which may
another configurable value (default 0xFFF). It is RECOMMENDED
the range of addresses to scan be configurable since some
have equipment that does not gracefully handle HIPPI-LE messages
After a port sends the[se] request[s], two positive outcomes
possible
o the port receives its own request(s), and obtains one of its
Switch Address,
o the port receives an AR_S_Response with
Destination_Switch_Address filled in
10 Security
HARP messages are not authenticated which is a potentially flaw
could allow corrupt information to be introduced into the
system
There are other known security issues relating to port
via the address resolution protocols used in the Internet [8].
special security mechanisms have been added to the address
mechanism defined here for use with networks using HARP
Not all of the security issues relating to ARP over HIPPI are
understood at this time. However, given the security hole ARP allows
other concerns are probably minor
11 Open
Synchronization and coordination of multiple HARP servers
multiple broadcast servers are left for further study
12 HARP
Assume a HIPPI-SC switch is installed with three connected ports: x
y, and a. Each port has a unique hardware address that consists
Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy
ULAa, respectively). There is a HARP server connected to a
port that is mapped to the address HWa (SWa, ULAa), this address
the authoritative HIPPI hardware address in the HRAL (HARP
Address List).
Pittet Standards Track [Page 26]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
The HARP server's table is empty. Ports X and Y each know their
hardware address. Eventually they want to talk to each other;
knows the other's IP address (from the port database) but
knows the other's ULA or Switch Address. Both ports X and Y
their interfaces configured DOWN
NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd
ar$pro, ar$pln fields are left out from the examples below since
are constant. Likewise, ar$rhl = ar$thl = 9 are omitted since
are all HIPPI-800 examples
12.1 Registration Phase of Client Y on Non-broadcast
Port Y starts: its HARP table entry state for the server:
1. Port Y initiates its interface and sends an InHARP_REQUEST to
after starting a table entry for HWa
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 8 (InHARP_REQUEST
HARP ar$rpa =
HARP ar$tpa = 0 **
HARP ar$rha = SWy
HARP ar$tha = SWa
** is what we would like to find
2. HARP server receives Y's InHARP_REQUEST, it examines the
addresses and scans its tables for a match. Since this is
first time Y connects to this server there is no entry and
will be created and time stamped with the information from
InHARP_REQUEST. The HARP server will then send a InHARP_
including its IP address
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 9 (InHARP_REPLY
HARP ar$rpa = IPs *
HARP ar$tpa =
HARP ar$rha = SWa
HARP ar$tha = SWy
* answer we were looking
Pittet Standards Track [Page 27]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
3. Port Y examines the incoming InHARP_REPLY, completes its
entry for the HARP server. The client's HARP table entry for
server now passes into the VALID state and is usable for
HARP traffic. Receiving this reply ensures that the HARP
has properly registered the client
12.2 Registration Phase of Client Y on Broadcast Capable
If there is a broadcast capable network then the
address in the HRAL would be mapped to the broadcast address, HWb =
SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
Port Y starts: its HARP table entry state for HWa:
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa
in this example the broadcast address, after starting a
entry
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 8 (InHARP_REQUEST
HARP ar$rpa =
HARP ar$tpa = 0 **
HARP ar$rha = SWy
HARP ar$tha = SWb
** is what we would like to find
2. Since the network is a broadcast network, client Y will receive
copy of its InHARP_REQUEST. Client Y examines the
addresses. Since they are the same as what Y filled in
InHARP_REQUEST, Y can deduce that it is connected to a
medium. Port Y completes its table entry for HWa. This entry
not timeout since it is considered unlikely for a
underlying hardware type to change between broadcast and non
broadcast; therefore this mapping will never change
12.3 Operational Phase (phase II
The Operational Phase of the HARP protocol as specified in this
is the same for both broadcast and non-broadcast capable
hardware. The authoritative address in the HRAL for this example
be HWa: and IPs for simplicity reasons
Pittet Standards Track [Page 28]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
12.3.1 Standard successful HARP_Resolve
Assume the same process (steps 1-3 of section 10.1) happened for
X. Then the state of X and Y's tables is: the HARP server table
is in the VALID state. So lets look at the message traffic when
tries to send a message to Y. Since X doesn't have an entry for Y
1. Port X connects to the authoritative address of the HRAL and
a HARP_REQUEST for Y's hardware address
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 1 (HARP_REQUEST
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha = SWx
HARP ar$tha = 0 **
** is what we would like to find
2. The HARP server receives the HARP request and updates its
for X if necessary. It then generates a HARP_REPLY with Y'
hardware address information
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 2 (HARP_Reply
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha = SWy ULAy *
HARP ar$tha = SWx
* answer we were looking
3. Port X connects to port Y and transmits an IP message with
following information in the HIPPI-LE header
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
If there had been a broadcast capable HIPPI network, the target
would themselves have received the HARP_REQUEST of step 2 above
responded to them in the same way the HARP server did
Pittet Standards Track [Page 29]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
12.3.2 Standard non-successful HARP_Resolve
Like in 12.3.1, assume that X and Y are fully registered with
HARP server. Then the state of X and Y's HARP server table entry is
VALID. So lets look at the message traffic when X tries to send
message to Q. Further assume that interface Q is NOT configured UP
i.e. it is DOWN. Since X doesn't have an entry for Q
1. Port X connects to the HARP server switch address and sends
HARP_REQUEST for Q's hardware address
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 1 (HARP_REQUEST
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha = SWx
HARP ar$tha = 0 **
** is what we would like to find
2. The HARP server receives the HARP request and updates its
for X if necessary. It then looks up IPq in its tables and doesn'
find it. The HARP server then generates a HARP_NAK reply message
HIPPI-LE Destination_Switch_Address =
HIPPI-LE Source_Switch_Address =
HIPPI-LE Destination_IEEE_Address =
HIPPI-LE Source_IEEE_Address =
HARP ar$op = 10 (HARP_NAK
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha = SWx
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_
except for the operation code
If there had been a broadcast capable HIPPI network, then there
not have been a reply
Pittet Standards Track [Page 30]
RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
13
[1] ANSI X3.183-1991(R1996), Information Technology - High
Performance Parallel Interface - Mechanical, Electrical
Signaling Protocol Specification; (HIPPI-PH).
[2] ANSI X3.210-1998, Information Technology - High-
Parallel Interface - Framing Protocol; (HIPPI-FP).
[3] ANSI X3.218-1993, Information Technology - High-
Parallel Interface - Encapsulation of ISO 8802-2 (IEEE
802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
[4] ANSI X3.222-1997, Information Technology - High-
Parallel Interface - Physical Switch Control; (HIPPI-SC).
[5] ANSI X3.300-1997, Information Technology - High-
Parallel Interface - Serial Specification; (HIPPI-Serial).
[6] Braden, R., "Requirements for Internet Hosts --
Layers", STD 3, RFC 1122, October 1989.
[7] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
RFC 2390, September 1998.
[8] Bellovin, Steven M., "Security Problems in the TCP/IP
Suite", ACM Computer Communications R