As per Relevance of the word hardware, we have this rfc below:
Network Working Group J.-M.
Request for Comments: 2835 Silicon Graphics Inc
Category: Standards Track May 2000
IP and ARP over HIPPI-6400 (GSN
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
The ANSI T11.1 task force has standardized HIPPI-6400 also known
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
copper cable interface for distances of up to 40 m is specified
HIPPI-6400-PH [1]. Connections to a longer-distance
interface are standardized in HIPPI-6400-OPT [3].
HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC
[10] and by implication, IP on GSN. Another T11.1 standard
the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].
T11.1 chose to leave HIPPI-6400 networking issues largely outside
scope of their standards; this document specifies the use of HIPPI
6400 switches as IP local area networks. This document
specifies a method for resolving IP addresses to HIPPI-6400
addresses (HARP) and for emulating IP broadcast in a logical
subnet (LIS) as a direct extension of HARP. Furthermore it is
goal of this memo to define a IP and HARP that will
interoperability for HIPPI-800 and HIPPI-6400 equipment
broadcast and non-broadcast capable networks
Table of
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.
HIPPI-6400 is a duplex data channel that can transmit and
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
virtual channels. These virtual channels are allocated to
traffic, low latency traffic, and bulk traffic (see [1] for
details).
Using small packets and four virtual channels, large file
cannot lock out a host or switch port for interactive traffic
HIPPI-6400 guarantees in order delivery of data. It also
link-level and end-to-end checksumming and credit-based flow control
HIPPI-6400-PH defines a 20-bit interface for copper cables
at 500 MBaud. This provides a user payload bandwidth of 6400 Mb/
(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
broadcast. Non-bridging switches are not required to
broadcast. This memo allows for a coherent implementation of IP
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
products complying to ANSI HIPPI-6400 standards
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 [19].
2.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.
document will use HIPPI-800 and HIPPI-6400 when referring to
that apply to one or the other technology. The term HIPPI will
used when referring to both technologies
Values are decimal unless otherwise noted. Formatting follows
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
A distribution mode which transmits a message to all ports.
sending port is part of "all" and will therefore also receive a
of the sent message
Classical/
Both terms are used with respect to networks, including Ethernet
FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs
The HIPPI port that receives data from a HIPPI Source
HARP (HIPPI Address Resolution Protocol describes the whole set
HIPPI-6400 address resolution encodings and algorithms defined
this memo. HARP is a combination and adaptation of the
Address Resolution Protocol (ARP) RFC-826 [14] and Inverse
(InARP) [5] (see section 5). HARP also describes the HIPPI (800
6400) specific version of ARP (i.e. the protocol and the
specific encoding).
HARP
Each host has a HARP table which contains the IP to hardware
mapping of IP members
The HARP Request Address List. A list of ULAs to which HARP
are sent when resolving names to addresses (see section 3.2).
Hardware (HW)
The hardware address of a port; it consists of an ULA (see
4.2). Note: the term port as used in this document refers to a
port and is roughly equivalent to the term "interface" as
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 2835 IP and ARP over HIPPI-6400 (GSN) 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. A port may
an Internet host, bridge, router, or gateway
The Protocol for Internet Broadcast Emulation Server (see section 7).
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
3. IP Subnetwork
3.1
ARP (address resolution protocol) as defined in [14] 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-6400 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-6400 port
to the HIPPI-6400 network that is configured as a member of one
more LIS's. This configuration MAY result in a number of
LIS's operating over the same HIPPI-6400 network. Using this model
ports of different IP subnets SHOULD communicate via an
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
LIS's on the same HIPPI-6400 fabric
By default, the HARP method detailed in section 5 and the
LIS routing model MUST be available to any IP member client in
LIS
Pittet Standards Track [Page 5]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
3.2 HIPPI LIS
The requirement for IP members (hosts, routers) operating in
HIPPI-6400 LIS configuration is
o All members of the LIS SHALL have the same IP network/
address and address mask [4].
The following list identifies the set of HIPPI-6400-
parameters that MUST be implemented in each IP station connected
the HIPPI-6400 network
o HIPPI-6400 Hardware Address
The HIPPI-6400 hardware address (a ULA) of an individual
endpoint (i.e. a network adapter within a host) MUST be unique
the LIS
o HARP Request Address List (HRAL):
The HRAL is an ordered list of two or more addresses identifying
address resolution service(s). All HARP clients MUST be
identically, i.e. all ports MUST have the same addresses(es) in
HRAL
The HRAL MUST contain at least two HIPPI HW addresses identifying
individual HARP service(s) that have authoritative responsibility
resolving HARP requests of all IP members located within the LIS.
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
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)
2nd : official HARP server address (00:10:3B:FF:FF:E0)
3rd & on: any additional HARP server addresses will be
sorted in decreasing order
Manual configuration of the addresses and address lists presented
this section is implementation dependent and beyond the scope of
memo. However, prior to use by any service or operation detailed
this memo, clients MUST have HRAL address(es) configured
appropriate for their LIS
Pittet Standards Track [Page 6]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
4. Internet
4.1 Packet
The HIPPI-6400 packet format for Internet datagrams [15]
conform to the HIPPI-6400-PH standard [1]. The length of a HIPPI
6400-PH packet, including headers and trailing fill, shall be
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
MUST be padded to a 32-byte granularity prior to sending.
padding is transparent to IP and is not reflected in the length
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
the pad
4.1.1 IEEE 802.2
The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len
The LLC values (in hexadecimal and decimal) SHALL
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
presence of a SNAP header
4.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 [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
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 |
2 | |
+---------------------------------------------------+
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | DSAP | SSAP | Ctl | Org | IEEE 802
+------------+------------+------------+------------+ LLC/
5 | Org | Org | Ethertype |
+============+============+============+============+ =============
6 | Msg byte 0 | Msg byte 1 | Msg byte 2 | . . . | IEEE 802
+---------------------------------------------------+
Generic 802.1 data packet
The following diagram shows an IP datagram of length n with the
bytes ( value: 0x0 ). "<><>" indicates the micropacket separation.
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
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 |
2 | |
+---------------------------------------------------+
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | AA | AA | 03 | 00 | IEEE 802
+------------+------------+------------+------------+ LLC/
5 | 00 | 00 | Ethertype = 0x0800=2048 |
+============+============+============+============+ =============
6 | VER | HLEN | TOS | Total Length |
+-----+------+------------+-----+-------------------+
7 | ID | FLG | Frag Offset |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4
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
As shown in above figure the first eight bytes of the IP
occupy the last eight bytes of the HIPPI-6400-PH [1]
micropacket
4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA
HIPPI-6400 uses Universal LAN MAC Addresses specified in
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
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
Annex A.2 of HIPPI-6400-SC[2].
The format of the address within its 48 bit HIPPI-6400-PH
follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit
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
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 -
Maximum Transmission Unit (MTU) is defined as the maximum length
the IP packet, including IP header, but not including any
below IP, i.e., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header
Conventional LANs have MTU sizes determined by physical
specification. MTUs may be required simply because the chosen
won't work with larger packets, or they may serve to limit the
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)
imposes no practical limit for networking purposes. HIPPI-6400-PH
1, which was chosen for IP and ARP traffic, limits messages to
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
packet to fit in one 64K byte buffer with up to 256 bytes
overhead. The IP v4 overhead is 24 bytes for HIPPI-6400 and 40
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
IEEE 802.2 LLC/SNAP Headers 8
Maximum IP packet size (MTU) 65280
Unused expansion room 232
------------
Total 65536 bytes (64K
In contrast, the HIPPI-800 accounting is
HIPPI-800-FP Header 8
HIPPI-800-LE Header 24
IEEE 802.2 LLC/SNAP Headers 8
Unused expansion room 216
Maximum IP packet size (MTU) 65280
------------
Total 65536 bytes (64K
5. HIPPI Address Resolution Protocol -
Address resolution within the HIPPI-6400 LIS SHALL make use of
HIPPI Address Resolution Protocol (HARP) and the Inverse
Address Resolution Protocol (InHARP). HARP provides the
functionality as the Internet Address Resolution Protocol (ARP).
HARP is based on ARP which is defined in RFC-826 [14] except
HIPPI-6400 specific packet format. Knowing the Internet address
conventional networks use ARP to discover another node'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 the same protocol as the
Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400
specific packet format. Knowing its hardware address, InARP is
to discover the other party's Internet address
This memo further REQUIRES the PIBES (see section 7) extension to
HARP protocol, guaranteeing broadcast service to upper
protocols like IP
Internet addresses are assigned independent of ULAs. Before
HARP, each node MUST know its IP and its HW addresses. The ULA
optional but is RECOMMENDED if interoperability with
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
in the reply will be the target's source address. If all switches
the LIS do not support broadcast, then a HARP server MUST be used
provide the address resolution service, and the source address in
reply will be the HARP server's source address
5.1 HARP
This section defines the behavior and requirements for
implementations on both broadcast and non-broadcast capable HIPPI
6400-SC networks. HARP creates a table in each port which maps
ports' IP addresses to ULAs, so that when an application requests
connection to a remote port by its IP address, the remote ULA can
determined, a correct HIPPI-6400-PH header can be built, and
connection to the port can be established using the ULA
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
To select the authoritative HARP service, each port needs
determine if it is connected to a broadcast network. At each point
time there is only one authoritative HARP service
The port SHALL send an InHARP_REQUEST to the first address in
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
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 order of addresses in the HRAL is only important for
which address will be the authoritative one. On a non-
network, the port is REQUIRED to keep "registered" with all
server addresses in the HRAL (NOTE: not the broadcast address
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
HARP service is non-responsive, then the port will consider the
address in the HRAL as a candidate for the authoritative address
send an InHARP_REQUEST
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 HRAL addresses in order. The
SHALL terminate the registration phase and transition into
operational phase, when either: (1) it receives its
InHARP_REQUEST, or (2) when it receives an InHARP_REPLY from at
one of the HARP servers and it has determined the authoritative
service as described in 5.1.1.
When ports are initiated they send an InHARP_REQUEST to
authoritative HRAL address. The first address to be tried will be
broadcast address "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
The port SHALL choose the next address in the HRAL as a
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
address in the HRAL at least once every 5 seconds until one of
following termination criteria are met for each address
a. If the port receives its own message, then the port itself
the HARP server and the port is REQUIRED to provide
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
and not a HARP server. In both cases, the current
address becomes the authoritative HARP service 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-6400-SC LAN supports broadcast, then the client will
its own InHARP_REQUEST message and SHALL complete the
phase. The client SHOULD further note that it is connected to
broadcast capable network and use this information for aging the
server entry and for IP broadcast emulation as specified in
5.4 and 5.6 respectively
If the client doesn't see its own InHARP_REQUEST it SHALL await
InHARP_REPLY before completing the registration phase. This will
provide the client with the protocol address by which the HARP
is addressable. This will be the case when the client happens to
connected to a non-broadcast capable HIPPI-6400-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 information about other
members by sending of HARP_REQUESTs to the authoritative address
the HRAL and by receiving of HARP_REPLYs. The client is
operational during the operational phase
In the operational phase, the client's behavior for requesting
resolution is the same for broadcast or non-broadcast HIPPI-6400-
switched 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, is in the ULA part of the Target Hardware
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
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 [5].)
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.3
5.6). All InHARP_REPLY messages SHALL be used to build/refresh
client HARP table entries. (Refer to Section 7, "
Operation" in [5].)
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
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
is still alive. Receiving a HARP_REPLY indicates to the client
the server must have seen the HARP_REQUEST
If the registration phase showed that the underlying network
broadcast, then the refresh sequence is 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-6400 connections from other HIPPI
6400 ports. The HARP server expects an InHARP_REQUEST as the
message from the client. A server examines the IP address,
hardware address of the InHARP_REQUEST and adds or updates its
table entry as well as the time stamp
A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based
the information which it has in its table. The HARP server
SHALL contain the hardware type and corresponding format of
request (see also sec. 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
+---+----------+----------+------------+---------------------+
| # | 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
if refcount = 0, delete HW(old
c: create new IP
Pittet Standards Track [Page 16]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
HWb <-> 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
The result will be a table with: IPb <-> HWa <-> IPb If IPb
the only IP address referred to by the HWb entry, then delete
HWb entry
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).
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
Pittet Standards Track [Page 17]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 sect. 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
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
invalidated entry prior to transmitting any non-address
traffic to the port referred to by this entry
Pittet Standards Track [Page 18]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
The client revalidates the entry by querying the HARP server. If
valid reply is received (e.g. HARP_REPLY), the entry is updated.
the address resolution service cannot resolve the entry (e.g
HARP_NAK, "host not found"), the associated table entry is removed
If the address resolution service is not available (i.e. "
failure") the client MUST attempt to revalidate the entry
transmitting an InHARP_REQUEST to the hardware address of the
in question and updating the entry on receipt of an InHARP_REPLY.
the InHARP_REQUEST attempt fails to return an InHARP_REPLY,
associated table entry is removed
6. HARP Message
The HARP message is another type of IEEE 802 payload as described
section 4.1.3 above. The HIPPI-6400 HARP SHALL support two
formats, both the generic Ethernet ARP packet and the HIPPI-800
packet format defined in [13]. HARP messages SHALL be
with a hardware type code of 28 on non-broadcast capable hardware
1 in either case
The ar$hrd field SHALL be used to differentiate between the
packet formats. The reply SHALL be in the format of the request
6.1 Generic IEEE 802 ARP Message
This is the ARP packet format used by conventional IEEE 802
(i.e. Ethernet, etc). The packet format is described in RFC-826 [14]
and is given here only for completeness purpose
ar$hrd 16 bits Hardware
ar$pro 16 bits Protocol type of the protocol fields
ar$hln 8 bits byte length of each hardware
ar$pln 8 bits byte length of each protocol
ar$op 16 bits opcode (ares_op$REQUEST | ares_op$REPLY
ar$sha 48 bits Hardware address of sender of this
ar$spa 32 bits Protocol address of sender of this
ar$tha 48 bits Hardware address of target of
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.
Pittet Standards Track [Page 19]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
ar$op - SHALL contain the operational value (decimal):
1 for HARP_
2 for HARP_
8 for InHARP_
9 for InHARP_
10 for HARP_
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$sha - in requests and NAKs it SHALL contain the requester's
In replies it SHALL contain the target port's ULA
ar$spa - 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's
if known, otherwise zero
In other replies it SHALL contain the requester's ULA
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
Pittet Standards Track [Page 20]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
|31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+-----
0 | |
| D_ULA +-------------------------------+
1 | | |6400
+-------------------------------+ S_ULA |
2 | |
+---------------------------------------------------------------+
3 | M_len |
+---------------+---------------+---------------+---------------+-----
4 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+802
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC
+------------+------------------+-------------------------------+
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
The HARP protocols further SHALL support the HIPARP hardware
(ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation
(ar$op) data formats as the ARP, and InARP protocols [14,7].
addition, HARP makes use of an additional operation code for ARP_
introduced with [11]. The remainder of the HIPARP message
(defined in [13]) is different than the ARP/InARP message
defined in [14,7,10] and it is also different from the format
in the first "IP and ARP on HIPPI" RFC-1374 [16].
The HARP message has several fields that have the following
and values
Pittet Standards Track [Page 21]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
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 target 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 address
Pittet Standards Track [Page 22]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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
Payload Format for HARP/InHARP PDUs
|31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+-----
0 | |
| D_ULA +-------------------------------+
1 | | |6400
+-------------------------------+ S_ULA |
2 | |
+---------------------------------------------------------------+
3 | M_len |
+---------------+---------------+---------------+---------------+-----
4 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+802
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC
+------------+------------------+-------------------------------+
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
6.2.1 Example Message encodings
Assume for the following example that the HARP server is in
HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side
the non-broadcast capable network
Pittet Standards Track [Page 23]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
HARP_REQUEST
HARP ar$op = 1 (HARP_REQUEST
HARP ar$rpa = IPy HARP ar$tpa =
HARP ar$rha = SWy ULAy HARP ar$tha = **
** is what we would like to find
HARP_REPLY message
HARP ar$op = 2 (HARP_REPLY
HARP ar$rpa = IPx HARP ar$tpa =
HARP ar$rha = SWx ULAx * 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 = SWx
** is what we would like to find
InHARP_REPLY message
HARP ar$op = 9 (InHARP_REPLY
HARP ar$rpa = IPx * HARP ar$tpa =
HARP ar$rha = SWx ULAx HARP ar$tha = SWy
* answer we were looking
6.2.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 for transmission with
HARP_REQUEST operation code changed to the HARP_NAK value.
makes use of an additional operation code for HARP_NAK and MUST
implemented
7 Broadcast and
HIPPI-6400-SC requires compliant systems to support broadcast
Initial HIPPI-6400-SC systems MAY defer broadcast capability to
broadcast server rather than support it directly in the
mechanism. A centralized HARP server architecture meets two of
three major duties of a broadcast server
A central entity serving the whole LIS solves the
problem of a distributed approach. The registration
solves the second problem of determining which addresses make up
set loosely called "everyone". The last duty of a broadcast server
to replicate an incoming packet and send it to "everyone".
Pittet Standards Track [Page 24]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
During its registration phase, every port , including HARP server(s),
discover if the underlying medium is capable of broadcast (
section 5.1.1). 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
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
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-6400 does not directly support multicast address,
there are no mappings available from IP multicast addresses to
multicast services. Current IP multicast implementations (i.e.
and IP tunneling, see [7]) 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.
Pittet Standards Track [Page 25]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 HIPPI
6400 network to look similar to an Ethernet network to the
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
8 HARP for Scheduled
This RFC also applies for resolving addresses used with
Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message
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
the ports
9 Security
There are known security issues relating to port impersonation
the address resolution protocols used in the Internet [6].
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-6400
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
probably minor
Pittet Standards Track [Page 26]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
10 Open
Synchronization and coordination of multiple HARP servers
multiple broadcast servers are left for further study
11 HARP
Assume a HIPPI-6400-SC switch is installed with three
ports: x, y, and a. Each port has a unique hardware address
consists unique ULA (ULAx, ULAy and UlAa, respectively). There is
HARP server connected to a switch port that is mapped to the
HWa, this address is the authoritative HIPPI hardware address in
HRAL (HARP Request Address List).
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. Both ports X and Y have their
configured DOWN
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields
left out from the examples below since they are constant. As well
ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples
11.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
HWa after starting a table entry for the HWa
HIPPI-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 8 (InHARP_REQUEST
HARP ar$rpa =
HARP ar$tpa = 0 **
HARP ar$rha =
HARP ar$tha =
** 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
Pittet Standards Track [Page 27]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
HIPPI-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 9 (InHARP_REPLY
HARP ar$rpa = IPs *
HARP ar$tpa =
HARP ar$rha =
HARP ar$tha =
* answer we were looking
3. Port Y examines the incoming InHARP_REPLY and 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
11.2 Registration Phase of Client Y on Broadcast Capable
If port Y is connected to a broadcast-capable network then
authoritative address is the broadcast address, HWb = SWb,
(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-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 8 (InHARP_REQUEST
HARP ar$rpa =
HARP ar$tpa = 0 **
HARP ar$rha =
HARP ar$tha =
** 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
Pittet Standards Track [Page 28]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
11.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 HIPPI-6400
hardware. The authoritative address in the HRAL for this example
be HWa: and IPs for simplicity reasons
11.3.1 Successful HARP_Resolve
Assume the same process (steps 1-3 of section 11.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-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 1 (HARP_REQUEST
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha =
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-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 2 (HARP_Reply
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha = ULAy *
HARP ar$tha =
* 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-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
Pittet Standards Track [Page 29]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
If the network had been broadcast-capable, the target ports
themselves have received the HARP_REQUEST of step 2 above
responded to them in the same way the HARP server did
11.3.2 Non-successful HARP_Resolve
As in 11.3.1, assume that X and Y are fully registered with the
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-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 1 (HARP_REQUEST
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha =
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-6400-PH D_ULA =
HIPPI-6400-PH S_ULA =
HARP ar$op = 10 (HARP_NAK
HARP ar$rpa =
HARP ar$tpa =
HARP ar$rha =
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 the network had been broadcast-capable, then there would not
been a reply
Pittet Standards Track [Page 30]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
12
[1] ANSI NCITS 323-1998, Information Technology - High-
Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[2] ANSI NCITS 324-199x, Information Technology - High-
Parallel Interface - 6400 Mbit/s Physical Switch
(HIPPI-6400-SC).
[3] ANSI NCITS Project Number 1249-D, Information Technology -
High-Performance Parallel Interface - 6400 Mbit/s
Specification (HIPPI-6400-OPT).
[4] Braden, R., "Requirements for Internet Hosts --
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
Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
pp. 32-48, 1989.
[7] Deering, S, "Host Extensions for IP Multicasting", STD 5,
1112, August 1989.
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot
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,
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
Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
Pittet Standards Track [Page 31]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
[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
Levels", BCP 14, RFC 2119, March 1997.
13
This memo could not have come into being without the critical
from Greg Chesson, Carlin Otto, the High performance
group of Silicon Graphics (specifically Jim Pinkerton, Brad
and Jeff Young) and the expertise of the ANSI T11.1 Task
responsible for the HIPPI standards work
This memo is based on the second part of [17], written by
Renwick. ARP [14] written by Dave Plummer and Inverse ARP [7]
by Terry Bradley and Caralyn Brown provide the fundamental
of HARP as presented in this memo. Further, the HARP server is
on concepts and models presented in [13], written by Mark Laubach
laid the structural groundwork for the HARP server
14 Author's
Jean-Michel
Silicon Graphics
1600 Amphitheatre
Mountain View, CA 94040
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.
Pittet Standards Track [Page 32]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
15 Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the 