Network Working Group J.-M. Pittet
INTERNET DRAFT Silicon Graphics Inc.
Expires September 1998 March 1998
ARP and IP Broadcast over HIPPI-800
<draft-pittet-hippiarp-00.txt>
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
The ANSI X3T11.1 task force has standardized the encapsulation of
IEEE 802.2 LLC PDUs [3]. Another X3T11.1 standard [4] describes the
operation of HIPPI physical switches. X3T11.1 chose to leave HIPPI
networking issues largely outside the scope of their standards; this
document specifies a method for resolving IP addresses to HIPPI
hardware addresses (HIPARP) and for emulating IP broadcast in a
logical IP subnet (LIS) as a direct extension of HIPARP.
Furthermore it is the goal of this memo to define a HIPARP that will
allow interoperability for HIPPI-800 and HIPPI-6400 (a.k.a. Gigabit
Systems Network, GSN) equipment both broadcast and non-broadcast
capable.
Pittet [Page 1]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
TABLE OF CONTENTS
1. Introduction
2. Scope
2.1 Changes from RFC-1374
2.2 Terminology
3. Definitions
3.1 Global Concepts
3.2 Glossary
4. IP Subnetwork Configuration
4.1 Background
4.2 HIPPI LIS Requirements
5. HIPPI Address Resolution Protocol - HIPARP
5.1 HIPARP Algorithm
5.1.1 HIPARP registration phase
5.1.2 HIPARP operational phase
5.2 HIPARP Client Operational Requirements
5.3 Receiving Unknown HIPARP Packets
5.4 HIPARP Single Server Operational Requirements
5.5 HIPARP and Permanent ARP Table Entries
5.6 HIPARP Table Aging
6. HIPARP Message Encoding
6.1 HIPPI-LE Header of HIPARP Messages
6.1.1 IEEE 802.2 LLC
6.1.2 SNAP
6.1.3 Diagram
6.2 HIPPI Hardware Address Formats and Requirements
6.2.1 48-bit Universal LAN MAC Addresses
6.2.2 I-Field requirements for HIPARP messages
6.3 HIPARP and InHIPARP Message Formats
6.3.1 HIPARP_NAK packet format
6.3.2 Combined HIPPI-LE and HIPARP packet addresses
7. Broadcast and Multicast
7.1 HIPPI IP Broadcast Emulation Server - HIPIBS
7.2 IP Broadcast Address
7.3 IP Multicast Address
7.4 A Note on Broadcast Emulation Performance
8. HIPARP for Scheduled Transfer
9. Discovery of One's Own Switch Address
9.1 Switch Address Discovery
10. Security
11. Open Issues
12. HIPARP Examples
12.1 Registration Phase of Client Y on Non-broadcast Hardware
12.2 Registration Phase of Client Y on Broadcast Hardware
12.3 Operational Phase (phase II)
12.3.1 Standard successful HIPARP_Resolve example
12.3.2 Standard non-successful HIPARP_Resolve example
Pittet [Page 2]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
13. References
14. Acknowledgments
15. Author's Address
1. Introduction
The ANSI High-Performance Parallel Interface (HIPPI) is a dual
simplex data channel. HIPPI can send and receive data
simultaneously at nearly 800 megabits per second. (HIPPI has an
equally applicable 1600 megabit/second option.) Between 1987 and
1997, the ANSI X3T11.1 HIPPI working group standardised five
documents that bear on the use of HIPPI as a network interface. They
cover the physical and electrical specification (HIPPI-PH [1]), the
framing of a stream of octets (HIPPI-FP [2]), encapsulation of IEEE
802.2 LLC (HIPPI-LE [3]), the behavior of a standard physical layer
switch (HIPPI-SC [4]) and the physical-level and optical
specification (HIPPI-Serial [5]). HIPPI-LE also implies the
encapsulation of Internet Protocol[5]. The reader should be familiar
with the ANSI HIPPI documents. Approved ANSI standards are available
from ANSI (http://www.ansi.org). The working document of the T11.1
HIPPI Standards Committee may be obtained from the T11 web page
(http://www.t11.org/) until they become published standards.
HIPPI switches can be used to connect a variety of computers and
peripheral equipment for many purposes, but the working group stopped
short of describing their use as Local Area Networks. This memo
takes up where the working group and RFC-2067 [18] left off and
defines address resolution and LIS IP broadcast emulation for HIPPI-
800 networks.
While investigating possible solutions for HIPARP it became evident
that IP broadcast could easily be emulated for both HIPPI-800 and
HIPPI-6400 hardware types. This is useful since HIPPI switches are
not required to implement broadcast but many standard networking
protocols rely on broadcast. This memo therefore further addresses
the emulation of LIS IP broadcast as an extension of HIPARP.
2. Scope
2.1 Changes from RFC-1374
RFC-2067 left ARP out of its scope because there was not enough
implementation experience. This memo is an effort to clarify and
expand the definition of ARP over HIPPI as found in RFC-1374 such
that implementations will be more readily possible, especially
considering forward interoperability with HIPPI-6400.
The changes from RFC-1374 are:
Pittet [Page 3]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
o A new packet format to acknowledge the HIPPI hardware address
format and to eliminate the requirement of HIPPI-LE ARP for HIPARP
to function.
o Explicit registration phase.
o Additional packet formats: InHIPARP requests and replies as
well as HIPARP_NAKs.
o Details about the IP subnetwork configuration.
o Details about table aging.
o IP broadcast emulation.
2.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
2.3 Limitations
This memo defines the address resolution service in the LIS and
constrains it to consist of a single HIPARP service address. This
memo recognizes the possible future development of standards and
implementations of multiple-HIPARP-server models that will extend the
operations as defined in this memo to provide a highly reliable
address resolution service.
3. Definitions
3.1 Global concepts used
In the following discussion, the terms "requester" and "target" are
used to identify the node initiating the address resolution request
and the node whose address it wishes to discover, respectively. If
not all switches in the LIS support boadcast then there will be a
HIPARP server providing the address resolution service and it will be
the source of the reply. If on the other hand all switches support
broadcast then the source address of a reply will be the address of
the target.
This document uses the terms node, host, etc. when talking about
destinations of messages. This is not entirely correct in the sense
that HIPPI addresses or IP addresses which are said to identify such
an entity actually identify one host adapter within that entity.
Pittet [Page 4]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
3.2 Glossary
Classical/Conventional
Used with respect to networks, this refers to Ethernet, FDDI and 802
LAN types, as distinct from HIPPI-SC LANs.
Destination
The HIPPI implementation that receives data from a HIPPI Source.
HIPARP
HIPARP describes the whole set of HIPPI address resolution encodings
and algorithm defined in this memo. HIPARP is a combination and
adaptation of the Internet Address Resolution Protocol (ARP) RFC-826
[15], Inverse ARP (InARP), and Reverse ARP [10] (see section 5).
HIPARP also describes the HIPPI specific version of ARP [10] (i.e.
the protocol and the HIPPI specific encoding).
HIPIBS
HIPPI IP Broadcast Server (see section 7).
HIPRAL
The HIPARP Request Address List (see section 4.2).
Host
An entity, ususally a computer system, that may have one or more
HIPPI nodes and which may serve as a client or a HIPARP server.
Node
An entity consisting of one HIPPI Source/Destination dual simplex
pair that is connected by parallel or serial HIPPI to a HIPPI-SC
switch and that transmits and receives IP datagrams. A node may be
an Internet host, bridge, router, or gateway. This memo uses the
term node in place of the usual term "host", to indicate that a host
might be connected to the HIPPI LAN through an external adaptor that
does some of the protocol processing for the host (instead of being
connected directly).
Pittet [Page 5]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
HIPPI-Serial
An implementation of HIPPI in serial fashion on coaxial cable or
optical fiber. (see [5])
Switch Address
A value used as the address of a node on a HIPPI-SC network. It is
transmitted in the I-field. HIPPI-SC switches may map Switch
Addresses to physical port numbers. The switch address is extended
with a mode byte to form an I-Field (see [4] and 6.2.2)
Source
The HIPPI implementation that generates data to send to a HIPPI
Destination.
Universal LAN MAC Address (ULA)
A 48-bit globally unique address, administered by the IEEE, assigned
to each node on an Ethernet, FDDI, 802 network, or HIPPI- SC LAN.
4. IP Subnetwork Configuration
4.1 Background
ARP (address resolution protocol) as defined in [13] was meant to
work on the 'local' cable. This definition gives the ARP protocol a
local logical IP subnet (LIS) scope. In the LIS scenario, each
separate administrative entity configures its hosts and routers
within the LIS. Each LIS operates and communicates independently of
other LISs on the same HIPPI network.
In the classical model, hosts communicate directly via HIPPI to other
hosts within the same LIS using the HIPARP mechanism described in
section 5 for resolving target IP addresses to target HIPPI endpoint
addresses. HIPARP has LIS scope only and serves all hosts in the
LIS. Communication to hosts located outside of the local LIS is
usually provided via an IP router. This router is a HIPPI endpoint
attached to the HIPPI network that is configured as a member of one
or more LISs. This configuration MAY result in a number of disjoint
LISs operating over the same HIPPI network. Using this model, hosts
of different IP subnets MUST communicate via an intermediate IP
router even though it may be possible to open a direct HIPPI
connection between the two IP members over the HIPPI network. This is
Pittet [Page 6]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
an obvious consequence of using IP and choosing to have multiple
LIS's on the same HIPPI fabric.
By default, the HIPARP method detailed in section 5 and the classical
LIS routing model MUST be available to any IP member client in the
LIS.
4.2 HIPPI LIS Requirements
The requirements for IP members (hosts, routers) operating in a HIPPI
LIS configuration are:
o All members of the LIS SHALL have the same IP network/subnet
and address mask [6].
o All members within an LIS SHALL be directly connected to the
HIPPI network.
o All members of an LIS MUST implement the HIPARP mechanism for
resolving IP addresses to HIPPI addresses as detailed in this memo
in section 5, "HIPPI Address Resolution Protocol - HIPARP."
o All members within an LIS MUST be able to communicate via HIPPI
with all other members in the same LIS.
The following list identifies the set of HIPPI-specific parameters
that MUST be implemented in each IP station connected to the HIPPI
network:
o HIPPI Hardware Address:
The HIPPI hardware address of an individual IP endpoint (i.e. a
network adapter within a host) MUST contain a switch address (see
section 9). The address SHOULD also contain a non-zero ULA
address. If there is no ULA then that field MUST be zero.
o HIPARP Request Address List (HIPRAL):
The HIPRAL is an ordered list of one or more addresses identifying
the address resolution service(s). The HIPRAL SHOULD be the same
for all nodes within a LIS. The HIPRAL MUST contain at least one,
and MAY contain more than one HIPPI address, identifying the
individual HIPARP service(s) that have authoritative
responsibility for resolving HIPARP requests of all IP members
located within the LIS. An LIS MUST have at least one HIPARP
service entry configured and available to all members of the LIS.
Pittet [Page 7]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
This memo only defined the behaviour of the address resolution
service for one entry in the HIPRAL. This memo recognizes the
future development of standards and implementations of multiple-
HIPARP-server models that will extend the operations as defined in
this memo to provide a highly reliable address resolution service.
Depending on the hardware broadcast capabilities, the address MAY
be the address for "IP traffic conventionally directed to the IEEE
802.1 broadcast address: 0xFE1" [4] if every switch in the LIS
supports this address feature or otherwise the address of a HIPARP
server. For example, the HIPARP server address MAY be the
reserved address for "Messages pertaining to (the) ... address
resolution requests: 0xFE0 " [4] or any other address identifying
a HIPARP server.
In the case where there is only a single HIPRAL address, all HIPARP
clients MUST be configured identically to have one non-null entry in
HIPRAL configured with the same address. That identifies the primary
HIPARP service.
Within the restrictions mentioned above and in Section 6.2.2, local
administration MUST choose an address(es) for the HIPARP service
which they will put into the HIPRAL.
Manual configuration of the addresses and address lists presented in
this section is implementation dependent and beyond the scope of this
memo; i.e. this memo does not require any specific configuration
method. For all implementations designed in compliance with this
memo, these addresses MUST be configured completely on the client, as
appropriate for the LIS, prior to use by any service or operation
detailed in this memo.
5. HIPPI Address Resolution Protocol - HIPARP
Address resolution within the HIPPI LIS SHALL make use of the HIPPI
Address Resolution Protocol (HIPARP) (based on [15]) and the Inverse
HIPPI Address resolution Protocol (InHIPARP) (based on [7]). HIPARP
is the same protocol as the Internet Address Resolution Protocol
(ARP) which is defined in RFC-826 [15] except the HIPPI specific
packet format. Ethernet, FDDI, and 802 networks use ARP to discover
another host's hardware address, knowing the Internet address.
InHIPARP is the same protocol as the original Inverse ARP (InARP)
protocol presented in [7] except the HIPPI specific packet format.
InARP is used to discover the other party's Internet address, knowing
its hardware address. HIPRARP is the same protocol as reverse ARP
[10] and is used by a client to discover it's own Internet address,
from its own hardware address.
Pittet [Page 8]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
HIPARP presented in this section further specifies the combination of
these original protocol definitions to form a coherent address
resolution service that is independent of the harware's broadcast
capability.
Internet addresses are assigned independent of ULAs and switch
addresses. Each host implementation MUST know its own IP, ULA and
switch address (see section 9 "Discovery of One's Own Switch Address"
for one implementation method) and MUST respond to address resolution
requests appropriately (see sections 6.2 and 6.3, within "HIPARP
Message Encodings"). IP members MUST use HIPARP to resolve IP
addresses to hardware addresses when needed.
This memo defines the address resolution service in the LIS and
constrains it to consist of a single HIPARP server. Client-server
interaction is defined by using a single server approach as a
reference model.
This memo recognizes the future development of standards and
implementations of multiple-HIPARP-server models that will extend the
operations as defined in this memo to provide a highly reliable
address resolution service.
5.1 HIPARP Algorithm
This section defines the behavior and requirements for host HIPARP
implementation on both broadcast and non-broadcast capable HIPPI-SC
networks. HIPARP creates a table in each node that map remote nodes'
IP addresses to Switch Addresses and to optional ULAs, so that when
an application requests a connection to a remote node by its IP
address, both the Switch Address and the remote ULA can be
determined, a correct HIPPI-LE header can be built, and a connection
to the node can be established using the correct Switch Address in
the I-field.
HIPARP is a two phase protocol. The first phase is a registration
phase and the second phase is the operational phase. The operational
phase works much like conventional ARP with the exception of the
packet format. The registration phase uses the InARP protocol to
register and establish a table entry with the server.
5.1.1 HIPARP registration phase
The HIPARP client is responsible for contacting the HIPARP server to
have its own IP and HIPPI hardware address information registered.
HIPARP clients SHALL initiate the registration phase through the
sending of an InHIPARP_REQUEST message to the primary address in the
HIPRAL.
Pittet [Page 9]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
If the HIPPI-SC LAN supports broadcast, then the client will see its
own InHIPARP_REQUEST packet. The client SHALL complete the
registration phase after verifying that the InHIPARP_REQUEST contains
the address information it previously inserted. The client will
further note that it is connected to a broadcast capable network and
use this information for table aging and IP broadcast emulation as
specified in sections 5.4 and 5.6 respectively.
If on the other hand the client is connected to a non-broadcast
capable HIPPI-SC network it SHALL await an InHIPARP_REPLY before
completing the registration phase. This will also provide the client
with the protocol address by which the HIPARP server is addressable.
5.1.2 HIPARP operational phase
Once a HIPARP client has completed its registration phase it enters
the operational phase. In this phase of the protocol, the HIPARP
client SHALL gain and refresh its own HIPARP table information about
other IP members through the sending of HIPARP_REQUESTS to the
primary address in the HIPRAL and the reception of HIPARP_REPLYs. The
client is fully operational during the operational phase.
In this phase, the client's behavior is the same for broadcast or
non-broadcast HIPPI-SC switched networks.
The target of an address resolution request SHOULD first update its
address mapping tables with any new information it can find in a
request. If it is the target node (see table below) it SHALL
formulate and send a reply packet. A node is the target of an
address resolution request if any ONE of the following statements are
true of the request:
1. The node's IP address is in the target protocol address field
(ar$tpa) of the HIPARP message.
2. The node's ULA (if non-zero), is in the ULA part of the Target
Hardware Address field (ar$tha) of the message.
3. The node's switch address is in the Target Switch Address field
of Target Hardware Address field (ar$tha) of the message (see
section 6.2.2).
4. The node is the primary HIPARP server .
NOTE: It is strongly RECOMMENDED to have a HIPARP server run on a
node which has a non-zero ULA.
5.2 HIPARP Client Operational Requirements
Pittet [Page 10]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
The HIPARP client is responsible for contacting the HIPARP server to
have its own HIPARP information registered and to gain and refresh
its own HIPARP entry/information about other IP members. This means,
as noted above, that HIPARP clients MUST be configured with the
switch address and optionally the ULA of the HIPARP server in the
HIPRAL.
HIPARP clients MUST:
1. When an interface is enabled (e.g. "ifconfig <interface> up"),
the client SHALL send an InHIPARP_REQUEST message to the primary
address in the HIPRAL. This allows the client to detect a
broadcast network or this message registers the client with the
HIPARP server if. The client will either receive its
InHIPARP_REQUEST on a broadcast capable LIS or an InHIPARP_REPLY.
The client SHALL await one of the two messages before successfuly
completing the registration phase and passing into the
operational phase.
2. After successfully completing the registration phase, the clients
MUST respond to HIPARP_REQUEST and InHIPARP_REQUEST packets, if
it is the target node. If an interface has multiple IP addresses
(e.g., IP aliases) then the client MUST cycle through all the IP
addresses and generate an InHIPARP_REPLY for each such address.
In that case an InHIPARP_REQUEST can have multiple replies.
(Refer to Section 7, "Protocol Operation" in RFC-1293 [7].)
3. Generate and transmit HIPARP_REQUEST packets to the primary
address in the HIPRAL. It must respond to address resolution
reply packets appropriately to build/refresh its own client
HIPARP table entries. All (solicited and unsolicited)
HIPARP_REPLYs SHALL be used to update and refresh its own client
HIPARP table entries.
Explanation: This allows the HIPARP server to update the clients
when one of its mappings change, similar to what is accomplished
on Ethernet with gratuitous ARP.
4. Generate and transmit InHIPARP_REQUEST packets as needed and
process InHIPARP_REPLY packets appropriately (see section 5.1.1
and 5.6). All InHIPARP_REPLY packets SHALL be used to
build/refresh its own client HIPARP table entries. (Refer to
Section 7, "Protocol Operation" in [7].)
If the registration phase showed that the underlying network doesn't
support broadcast, then the client MUST refresh its own HIPARP
information with the server at least once every 15 minutes through
the repetition of step 1 or the exchange of other HIPARP traffic with
Pittet [Page 11]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
the HIPARP server. To decrease the redundant network traffic, his
timeout SHOULD be reset after each HIPARP_REPLY from the server.
Explanation: The HIPARP_REQUEST shows the HIPARP server that the
client is still alive. Receiving a HIPARP_REPLY indicates to the
client that the server must have seen the HIPARP_REQUEST.
5.3 Receiving Unknown HIPARP Packets
If a HIPARP client receives a HIPARP message with an operation code
(ar$op) that it is not coded to support, it MUST gracefully discard
the message and continue normal operation. A HIPARP client is NOT
REQUIRED to return any message to the sender of the unsupported
message.
5.4 HIPARP Single Server Operational Requirements
The HIPARP server accepts HIPPI connections from other HIPPI
endpoints. The HIPARP server expects an InARP_REQUEST from the client
as first message from the client. The server examines the IP address,
the switch address, and the ULA of the InARP_REQUEST and adds or
updates its HIPARP table entry <IP address(es), switch address, ULA>
as well as the time stamp.
If the InHIPARP_REQUEST requester's IP address duplicates a table
entry IP address and the InHIPARP_REQUEST hardware address does not
match the table entry hardware address, then the table entry SHALL be
updated to the new mapping (E.g. moving an IP alias). If the
InHIPARP_REQUEST requester's ULA and switch address pair duplicates a
ULA and switch address table entry, the IP address SHALL be added to
the previous IP address(es). (E.g. adding an IP alias). If the ULA
and switch address match only partially, the information SHALL be
discarded and no modification to the table is made.
The server MUST update the HIPARP table entry's timeout for each
HIPARP_REQUEST. Explanation: if the client is sending HIPARP requests
to the server, then the server should note that the client is still
"alive" by updating the timeout on the client's HIPARP table entry.
The HIPARP server SHOULD send out HIPARP_REPLYs to all HW addresses
in its table when it undertakes a change of an existing entry in its
tables. This feature decreases the time of stale entries in the
clients.
The following table shows all possible situations at the HIPARP
server when a HIPARP_REQUEST is received. Since a HIPPI hardware
address is one unit, it is invalid only to change part of it. Any
actions marked with (*) indicate that the inactivity timeout SHALL be
Pittet [Page 12]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
reset.
+---+-----------+-----------+-----------+-----------------------+
| # | IP entry | ULA entry | Sw addr |Action |
+---+-----------+-----------+-----------+-----------------------+
| 1 | duplicate | duplicate | duplicate | * |
| 2 | duplicate | duplicate | new | Not Valid |
| 3 | duplicate | new | duplicate | Not Valid |
| 4 | duplicate | new | new | move IP alias,* |
| 5 | new | duplicate | duplicate | add IP alias to tbl,* |
| 6 | new | duplicate | new | Not Valid |
| 7 | new | new | duplicate | Not Valid |
| 8 | new | new | new | fresh entry, add it,* |
+---+-----------+-----------+-----------+-----------------------+
5.5 HIPARP and Permanent ARP Table Entries
An IP station MUST have a mechanism (e.g. manual configuration) for
determining what permanent entries it has. The details of the
mechanism are beyond the scope of this memo. The permanent entries
allow interoperability with legacy HIPPI adapters which do not yet
implement dynamic HIPARP and use a table based static ARP. Permanent
entries are not aged.
5.6 HIPARP Table Aging
HIPARP table aging MUST be supported since IP addresses, especially
IP aliases and also interfaces (with their ULA), are likely to move.
When so doing the mapping in the clients own HIPARP table/cache
becomes invalid and stale.
o HIPARP table entries in client tables are valid for a maximum
time of 15 minutes.
o HIPARP table entries in the server table are valid for a
maximum time of 20 minutes.
If a server entry ages beyond 20 minutes without being updated
(refreshed) by the client, that entry SHALL be deleted from the
HIPARP server's table.
When a client HIPARP table entry ages, a HIPARP client MUST
invalidate the table entry. The client MUST revalidate the entry
prior to transmitting any non address resolution traffic to the node
referred to by this entry.
NOTE: the client is permitted to revalidate a HIPARP table entry
Pittet [Page 13]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
before it ages, thus restarting the aging time when the table entry
is successfully revalidated. The client MAY continue sending traffic
to the node referred to by this entry while revalidation is in
progress, as long as the table entry has not aged.
The client revalidates the entry by querying the address resolution
service. If a valid reply is received (e.g. HIPARP_REPLY), the entry
is updated. If the address resolution service cannot resolve the
entry (e.g. HIPARP_NAK, "host not found"), the associated table entry
is removed. If the address resolution service is not available (i.e.
"server failure") the client MUST attempt to revalidate the entry by
transmitting an InHIPARP_REQUEST to the hardware address of the entry
in question and updating the entry on receipt of an InHIPARP_REPLY.
If the InHIPARP_REQUEST attempt fails to return an InHIPARP_REPLY,
the associated table entry is removed.
6. HIPARP Message Encoding
The HIPARP FP header values are to be set as defined in RFC-2067 "IP
over HIPPI" [18].
6.1 HIPPI-LE Header of HIPARP Messages
The HIPPI packet format for Internet datagrams shall conform to the
HIPPI-FP [2] and HIPPI-LE [3] standards. The length of a HIPPI
packet, including trailing fill, shall be a multiple of eight octets
as required by HIPPI-LE. The HIPPI-LE header fields of HIPARP,
HIPRARP, and InHIPARP requests and replies SHALL be set to:
FC (3 bits) shall contain zero unless otherwise defined by local
administration.
Double-wide SHALL be set to 0. This memo does not address the
implications on HIPARP when this bit is set to 1 indicating the
possibility of a node being able to accept 64-bit HIPPI connections.
Message_Type SHALL contain 0 to indicate data. as defined in
HIPPI-LE.
There is no HIPARP message corresponding to HIPPI-LE self-address
discovery; these packets are sent without ULP data as specified in
HIPPI-LE [3].
Destination_Switch_Address, in requests, SHALL be the Switch Address
of the destination node if known, otherwise zero. In replies, it
SHALL be the requester's Switch Address.
Destination_Address_Type SHALL be 2, a 12-bit address. Type 1, source
Pittet [Page 14]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
routing, is not acceptable in this specification.
Source_Address_Type SHALL be 2, a 12-bit address. Type 1, source
routing, is not acceptable in this specification.
Source_Switch_Address in requests SHALL be the Switch Address of the
requesting node. In replies it SHALL be the replying node's Switch
Address. That is, the switch address of either the target or the
HIPARP server, depending on whether a LIS supports broadcast or not,
respectively.
Destination_IEEE_Address SHALL be the ULA of the destination node, if
known, otherwise zero. In replies, it SHALL be the requester's ULA.
Source_IEEE_Address SHALL be the ULA of the requesting node. In
replies it SHALL be the replying node's ULA Address. That is the the
target's ULA or HIPARP server's ULA, depending on whether a LIS
supports broadcast or not, respectively.
6.1.1 IEEE 802.2 LLC
The IEEE 802.2 LLC Header SHALL begin in the first byte of the
HIPPI-FP D2_Area.
The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 octets)
indicates the presence of a SNAP header.
6.1.2 SNAP
The OUI value for Organization Code SHALL be 0x00-00-00 (3 octets)
indicating that the following two-bytes is an ethertype.
The Ethertype value SHALL be set as defined in Assigned Numbers [21]:
HIPARP = ARP = 2054 ('0806'h), HIPRARP = RARP = 32,821 ('8035'h).
The total size of the LLC/SNAP header is fixed at 8-octets.
6.1.3 Diagram
Payload Format for HIPARP/InHIPARP/HIPRARP PDUs:
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 36 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|M_Type | 000 |Requester's Switch Addr|
Pittet [Page 15]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
+-----+-+-------+-----------------------+-----------------------+
3 | D_A_T | S_A_T | 000 | Replyer's Switch Addr |
+-------+-------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Requester's ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Destination ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | EtherType (2054) |
+---------------+---------------+-------------------------------+
10 |Message octet 0|Message octet 1|Message octet 2| . . . |
+---------------+---------------+---------------+--- |
| . . . |
+ ------------+---------------+---------------+---------------+
| . . . | octet (n-2) | octet (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HIPPI Packet Format
Words 0-1: HIPPI-FP Header
Words 2-7: D1 Area (HIPPI-LE Header)
Words 8-9: D2 Area (IEEE 802.2 LLC/SNAP)
Words 10-(N-1): D2 Area (HIPARP message)
(n) is the number of octets in the HIPARP message.
+====+ denotes the boundary between D1 and D2 areas.
[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 to
HIPPI-LE
"D_A_T" = Destination_Address_Type SHALL be 2
"S_A_T" = Source_Address_Type SHALL be 2
[FILL] octets complete the HIPPI packet to an even
number of 32 bit words. The number of fill octets
is not counted in the data length.
6.2 HIPPI Hardware Address Formats and Requirements
For HIPPI-800, the Hardware Address is a 9-byte unit that SHALL
Pittet [Page 16]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
contain the Switch Address AND the ULA. Since HIPPI-800 doesn't
require the use of a ULA, its fields MAY be zero. The address length
is still 9 bytes. See the following diagram for an example of the
HIPPI Hardware Address in the HIPARP Message:
31 23 15 7 0
+---------------+-----------------------------------------------+
| ... |Requester's HIPPI Hardware Address octets 0 - 2|
+---------------+-----------------------------------------------+
| Requester's HIPPI Hardware Address octets 3 - 6 |
+-------------------------------+-------------------------------+
| Requester's HW Addr oct 7 - 8 |
+---------------+---------------+
In the case of the Requester's HIPPI Hardware Address, the HIPPI
hardware address is split into Switch address and ULA as follows:
31 23 15 7 0
+---------------+-----------------------------------------------+
| ... |Requester's Switch Address 0-2, HW Addr 0 - 2 |
+---------------+---------------+---------------+---------------+
| Requester's ULA octets 0 - 3 = Hardware Addr octets 3 - 6 |
+---------------+---------------+---------------+---------------+
| Req's ULA 4-6 = HW Addr 7-8 |
+---------------+---------------+
NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6-
byte ULA. Therefore the length of the hardware address clearly
defines which version of HIPPI is being used.
6.2.1 48-bit Universal LAN MAC Addresses
IEEE Standard 802.1A specifies the Universal LAN MAC Address. The
globally unique part of the 48-bit space is administered by the IEEE.
Each node on a HIPPI-SC LAN should be assigned a ULA. Multiple ULAs
may be used if a node contains more than one IEEE 802.2 LLC protocol
entity.
The format of the HIPPI hardware address within its HIPARP packet
follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte
order. For example the requester's ULA part of the HIPPI hardware
address would decompose to:
31 23 15 7 0
+---------------+---------------+---------------+---------------+
|ULA octet 0|L|G| ULA octet 1 | ULA octet 2 | ULA octet 3 |
+---------------+---------------+---------------+---------------+
| ULA octet 4 | ULA octet 5 |
Pittet [Page 17]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
+---------------+---------------+
Universal LAN MAC Address Format
L (U/L bit) = 1 for Locally administered addresses, 0 for
Universal.
G (I/G bit) = 1 for Group addresses, 0 for Individual.
The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is
REQUIRED if a host wishes to interoperate with HIPPI-6400 units.
Although ULAs are not used by HIPPI-SC switches, they are helpful for
HIPPI Switch Address resolution, and for distinguishing between
multiple logical entities that may exist within one node. They may
also be used by bridging devices that replace HIPPI hardware headers
with the MAC headers of other LANs. Carrying the ULAs in the HIPPI
header may simplify these devices, and it may also help if HIPPI is
used as an interface to some future HIPPI based LAN that uses only
ULAs for addressing (e.g. HIPPI-6400).
6.2.2 I-Field requirements for HIPARP messages
The first byte of the I-Field contains mode bits defined in HIPPI-SC
[4]. For simplicity and feasibility, this byte SHALL be the same for
all nodes in an LIS. It MAY be a configurable parameter. Consistency
across ALL the nodes in an LIS MUST be assured through means which
are beyond the scope of this memo.
Unless another convention is locally defined for HIPARP requests, the
I-field Path Selection bits SHOULD be set to binary 01 or 11 (logical
address mode). Section 6.1, "HIPPI-LE Header of the HIPARP Messages"
defines the values for the FC, Double-wide and Mesage-type fields.
6.3 HIPARP and InHIPARP Message Formats
The HIPARP protocols use the same hardware type (ar$hrd), protocol
type (ar$pro), and operation code (ar$op) data formats as the ARP,
InARP and RARP protocols [15,7,10]. The location of these three
fields within the HIPARP packet are in the same byte positions as
those in conventional ARP, RARP and InARP packets.In addition, HIPARP
makes use of an additional operation code for ARP_NAK introduced with
[13].The remainder of the HIPARP/InHIPARP packet format is different
than the ARP/InARP packet format defined in [15,7,10] and it is also
different from the format defined in the first "IP and ARP on HIPPI"
RFC-1374 [17].
HIPARP packets SHALL be transmitted with a hardware type code of 1
(as for Ethernet). Furthermore, HIPARP packets SHALL be accepted if
Pittet [Page 18]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
received with hardware type codes of either 1 or 6 (IEEE 802
networks).
The HIPARP message has several fields that have the following format
and values:
Data sizes and field meaning:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below
ar$op 16 bits Operation code (request, reply, or NAK)
ar$pln 8 bits byte length of each protocol address
ar$rhl 8 bits requester's HIPPI hardware address length (q)
ar$thl 8 bits target's HIPPI hardware address length (x)
ar$rpa 32 bits requester's protocol address
ar$tpa 32 bits target's protocol address
ar$rha qoctets requester's HIPPI Hardware address
ar$tha xoctets target's HIPPI Hardware address
Where :
ar$hrd - SHALL contain 1. (Ethernet)
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$op - SHALL contain the operational value (decimal):
1 for HIPARP_REQUESTs
2 for HIPARP_REPLYs
3 for HIPRARP_REPLYs
4 for HIPRARP_REPLYs
8 for InHIPARP_REQUESTs
9 for InHIPARP_REPLYs
10 for HIPARP_NAK
ar$hln - SHALL contain 9 IF this is a HIPPI-800 link
ELSE, for HIPPI-6400, it SHALL contain 6.
ar$pln - SHALL contain 4.
ar$rha - in requests and NAKs it SHALL contain the requester's ULA
In replies it SHALL contain the target node's ULA.
ar$rpa - in requests and NAKs it SHALL contain the requester's IP
address if known, otherwise zero.
In other replies it SHALL contain the target
node's IP address.
ar$tha - in requests and NAKs it SHALL contain the target's ULA
if known, otherwise zero.
In other replies it SHALL contain the requester's ULA.
Pittet [Page 19]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
ar$tpa - in requests and NAKs it SHALL contain the
target's IP address if known, otherwise zero.
In other replies it SHALL contain the requester's
IP address.
The format of the six octets of the ULA SHALL be the same as required
in the HIPPI-LE header (see section 6.2, "HIPPI Hardware Address
Formats and Requirements" above), except for the alignment of the
ULAs with respect to the 32-bit HIPPI word, which is different
between ARP and HIPPI-LE. No bit reversal is necessary as is
required with FDDI.
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 36 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W| 1 | 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 |Requester's Switch Addr|
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Requester's ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | EtherType (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (1) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | shl (q) |
+---------------+---------------+---------------+---------------+
12 | thl (x) | Requester's IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Src. IP lower | Target's IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower |Requester's HIPPI Hardware Address octets 0 - 2|
+---------------+-----------------------------------------------+
15 | Requester's HIPPI Hardware Address octets 3 - 6 |
+-------------------------------+-------------------------------+
16 | Requester's HW Addr oct 7 - 8 | Target's HIPPI HW Addr 0 - 2 |
+---------------+---------------+-------------------------------+
Pittet [Page 20]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
17 | Target's HIPPI Hardware Address octets 2 - 5 |
+-----------------------------------------------+---------------+
18 | Target's HIPPI Hardware Address octets 6 - 8 |
+-----------------------------------------------+
HIPARP - HIPRARP - InHIPARP Packet
( using 2 HIPPI-800 addresses )
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester's ULA octets 0 - 2 |
+---------------+-------------------------------+---------------+
15 | Requester's ULA octets 3 - 5 | Tgt ULA oct 0 |
+-----------------------------------------------+---------------+
16 | Target ULA octets 1 - 4 |
+---------------+-----------------------------------------------+
17 | Tgt ULA oct 5 |
+---------------+
HIPARP - HIPRARP - InHIPARP Packet
(bottom half with 2 HIPPI 6400 addresses)
6.3.1 HIPARP_NAK packet format
The HIPARP_NAK packet format is the same as the received
HIPARP_REQUEST packet format with the operation code set to
HIPARP_NAK; i.e. the HIPARP_REQUEST packet data is exactly copied for
transmission with the HIPARP_REQUEST operation code changed to the
HIPARP_NAK value. HIPARP makes use of an additional operation code
for HIPARP_NAK and MUST be implemented.
6.3.2 Combined HIPPI-LE and HIPARP packet addresses
The combined HIPPI-LE/HIPARP packet contains ten addresses, two for
the destination and two for the source of the message, three for the
requester and three for the target:
Destination Switch Address (HIPPI-LE)
Destination ULA (HIPPI_LE)
Source Switch Address (HIPPI-LE)
Source ULA (HIPPI-LE)
Requester's IP Address (HIPARP)
Requester's ULA (HIPARP)
Requester's Switch Address (HIPARP)
Target's IP Address (HIPARP)
Target's ULA (HIPARP)
Pittet [Page 21]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
Target's Switch Address (HIPARP)
Examples:
The following relations are true for a HIPARP_REQUEST and
InHIPARP_REQUESTs.
LIS without broadcast - Dest SW Addr = HIPARP server SW Addr
(with HIPARP server) Dest ULA = HIPARP server ULA
Source SW Addr = Requester's SW Addr
Source ULA = Requester's ULA
For InHIPARP_REPLYs and HIPARP_REPLYs for instance would be:
LIS without broadcast - Dest SW Addr= Requester's SW Addr
(with HIPARP server) Dest ULA = Requester's ULA
Source SW Addr = HIPARP server SW Addr
Source ULA = HIPARP server ULA
Note that the use of ULAs with HIPPI is not required. In both the
HIPPI-LE header and the HIPARP message, the fields that contain ULAs
SHOULD be set to zero if the ULA is not known.
7 Broadcast and Multicast
HIPPI-SC does not require switches to support broadcast. Broadcast
support has therefore been absent from many HIPPI networks. However,
a centralized HIPARP server architecture solves two of the three
major duties of a broadcast server.
A central entity serving the whole LIS solves the coordination
problem of a distributed approach. The registration requirement
solves the second problem of determining which addresses make up the
set loosely called "everyone". The last duty of a broadcast server is
to replicate an incoming packet and send it to "everyone".
During its registration phase, every node, including the node which
has the same hardware address as the primary address in the HIPRAL
and which is therefore the HIPARP server, discovers if the
underlying medium is capable of broadcast (see section 5.1.1). Should
this not be the case, then it makes sense for the HIPARP server to
emulate broadcast through an IP broadcast emulation server.
A HIPPI IP broadcast server (HIPIBS) is an extension to the HIPARP
server and only makes sense when the LIS does not inherently support
broadcast. The HIBIS is optional and MAY be implemented.
7.1 HIPPI IP Broadcast Emulation Server - HIPIBS
Pittet [Page 22]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
To emulate broadcast within an LIS, a HIPIBS SHALL use the currently
valid HIPARP table of the HIPARP server as a list of addresses called
the target list. The broadcast server SHALL validate that all
incoming packets have a source address which corresponds to an
address in the target list. Non-valid packets SHALL be dropped and a
warning flag MAY be raised with the system administrator. All valid
packets shall be forwarded to all addresses in the target list.
It is RECOMMENDED that the broadcast server run on the same node as
the HIPARP server since this memo does not define the protocol of
exchanging the valid HIPARP table.
7.2 IP Broadcast Address
HIPPI-SC supports broadcast addressing, defined in section 4.2,
"Reserved Logical Addresses". It is RECOMMENDED to pair the HIPARP
server addresses in the HIPRAL (see section ) with a corresponding
broadcast address. The default broadcast address SHALL be 0xFE1 as
described in HIPPI-SC as being the address used for "All IP protocol
traffic conventionally directed to the IEEE 802.1 broadcast address
as described in RFC-1042".
This memo defines the IP broadcast emulation service in the LIS and
constrains it to consist of a single IP broadcast server. Client-
server interaction is defined by using a single server approach as a
reference model.
This memo recognizes the possibility of future development of
standards and implementations of multiple-IP-broadcast-server models
that will extend the operations defined in this memo in order to
provide a highly reliable broadcast service.
7.3 IP Multicast Address
HIPPI does not directly support IP multicast address services,
therefore there are no mappings available from IP multicast addresses
to HIPPI multicast services. Current IP multicast implementations
(i.e. MBONE and IP tunneling, see [9]) will continue to operate over
HIPPI-based logical IP subnets if all IP multicast addresses are
mapped to the address of the primary broadcast emulation server.
7.4 A Note on Broadcast Emulation Performance
It is obvious that a broadcast emulation service (as defined in
section 7.1) is an inherent performance bottleneck. In an LIS with n
hosts, the upper bound on the bandwidth that such a service can
broadcast is:
(total bandwidth)/(n+1)
Pittet [Page 23]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
since each packet must first enter the broadcast server, accounting
for the additional 1, and then be sent to all n hosts. The broadcast
server could forward the packet destined to the node on which it
runs, thus internally reducing (n+1) to (n) in a first optimization.
The point is that such a service works for the standard networking
protocols such as RIP, OSPF, NIS, NFS, etc. since they usually
represent a small fraction of the network bandwidth. For all general
purposes, the broadcast emulation server as defined in this memo
allows the HIPPI network to look similar to an Ethernet network to
the higher layers.
It is further obvious that such an emulation cannot be used to
broadcast high bandwidth traffic. For such a solution, hardware
support for true broadcast, implemented in a distributed fashion
inside the individual switches, is required.
8 HIPARP for Scheduled Transfer
This RFC also applies for resolving addresses used with Scheduled
Transfer (ST) over HIPPI-800 instead of IP. This RFC's message types
and algorithms can be used for ST (since ST uses Internet Addresses)
as long as there is also an IP over HIPPI implementation on all the
hosts.
9 Discovery of One's Own Switch Address
This HIPARP specification assumes that each node has prior knowledge
of its own switch address. This may be manually configured, by means
that are outside the scope of this memo. If a broadcast capability
exists, the node may discover its own address automatically when it
starts up, using a protocol defined in HIPPI-LE.
If on the other hand, one can not rely on the underlying hardware to
support broadcast, then a node may discover its own logical address
through the algorithm described in section 9.1.
9.1 Switch Address Discovery
Nodes are NOT REQUIRED to implement this protocol but are encouraged
to do so since it reduces the administrative overhead of systems
administration.
If a node implements this feature it SHALL form a HIPPI-LE message as
defined in HIPPI-LE: containing an AR_S_Request Message Type, and
where the Source_IEEE_Address and Destination_IEEE_Address are set
to the correct ULA for the sender, and the Source_Switch_Address and
Destination_Switch_Address contain zero.
Pittet [Page 24]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
This self address resolution message uses the same HIPPI-LE message
format as described in HIPPI-SC and HIPPI-LE: the AR_S_Request and
AR_S_Response message type codes and no piggybacked ULP data. The
HIPPI-LE header contents for the request are:
HIPPI-LE Message_Type is = 3, AR_S_Request
HIPPI-LE Destination_Address_Type = 0 (undefined)
HIPPI-LE Destination_Switch_Address = 0 (unknown)
HIPPI-LE Source_Address_Type = 0 (undefined)
HIPPI-LE Source_Switch_Address = 0 (unknown)
HIPPI-LE Destination_IEEE_Address = my ULA
HIPPI-LE Source_IEEE_Address = my ULA
There is no D2 data; the packet contains only the HIPPI-FP header and
D1_Area containing the HIPPI-LE header.
HIPPI-LE leaves the target of such an address outside its scope. This
memo defines that nodes SHALL start with the HIPPI broadcast address
0xFE1 and if no reply is received, SHALL continue with the logical
address of START ( e.g. 0x000) and increment the value by one each
subsequent try. The node SHALL try until reaching 0xFFF or until it
sees its own address resolution request. It is RECOMMENDED to make
the starting address of the previous scan a configurable parameter
for the network since some networks have equipment that does not
gracefully drop HIPPI-LE packets that it cannot decode. HIPPI-LE
section 7.1 HIPPI Address Resolution Overview:
"After a host sends the[se] request[s], two positive outcomes are
possible:
o the host receives its own request, and obtains its own Switch
Address from the CCI passed up from the underlying HIPPI-FP
layer, or
o the host receives an AR_S_Response with the
Destination_Switch_Address filled in.
In the first case the host should not respond to its own request."
Or it receives a broadcast copy of its own message, and learns its
own switch address from the destination address field of the
received I-field.
10 Security
Not all of the security issues relating to ARP over HIPPI are clearly
understood at this time.
There are known security issues relating to host impersonation via
Pittet [Page 25]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
the address resolution protocols used in the Internet [8]. No
special security mechanisms have been added to the address resolution
mechanism defined here for use with networks using HIPARP.
11 Open Issues
o Synchronization and coordination of multiple HIPARP servers and
multiple broadcast servers are left for further study.
o HIPARP packets are not authenticated. This is a potentially
serious flaw in the overall system by allowing a mechanism by
which corrupt information may be introduced into the server
system.
12 HIPARP Examples
Assume a HIPPI-SC switch is installed with three connected nodes: X,
Y, and a. Each node has a unique hardware address that consists of
Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and
ULAa, respectively). There is a HIPARP server connected to a switch
port that is mapped to the address HWa (SWa, ULAa), this address is
the primary HIPPI hardware address in the HIPRAL (HIPARP Request
Address List).
The HIPARP server's table is empty. Nodes X and Y each know their own
hardware address. Eventually they want to talk to each other; each
knows the other's IP address (from the host database) but neither
knows the other's ULA or Switch Address. Both nodes X and Y have
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 they
are constant. As well as ar$shl = ar$thl = 9 since these are
all
HIPPI-800 examples.
12.1 Registration Phase of Client Y on Non-broadcast Hardware
Node Y starts: its HIPARP table entry state for the server: PENDING
1. Node Y initiates its interface and sends an InHIPARP_REQUEST to
the HIPARP server after starting a table entry for the HIPARP
server.
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAa
Pittet [Page 26]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
HIPPI-LE Source_IEEE_Address = ULAy
HIPARP ar$op = 8 (InHIPARP_request)
HIPARP ar$rpa = IPy
HIPARP ar$tpa = 0 **
HIPARP ar$rha = SWy ULAy
HIPARP ar$tha = SWa ULAs
** is what we would like to find out
2. HIPARP server receives Y's InHIPARP_REQUEST, it examines the
source addresses and scans its tables for a match. Since this is
the first time Y connects to this server there is no entry and
one will be created and time stamped with the information from
the InHIPARP_REQUEST. The HIPARP server will then send a
InHIPARP_REPLY including its IP address.
HIPPI-LE Destination_Switch_Address = SWy
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAy
HIPPI-LE Source_IEEE_Address = ULAs
HIPARP ar$op = 9 (InHIPARP_REPLY)
HIPARP ar$rpa = IPs *
HIPARP ar$tpa = IPy
HIPARP ar$rha = SWa ULAs
HIPARP ar$tha = SWy ULAy
* answer we were looking for
3. Node Y examines the incoming InHIPARP_REPLY, completes its table
entry for the HIPARP server. The client's HIPARP table entry for
the server now passes into the VALID state and is usable for
regular HIPARP traffic. Receiving this reply ensures that the
HIPARP server has properly registered the client.
12.2 Registration Phase of Client Y on Broadcast Capable Hardware
If there is a broadcast capable network then the primary address in
the HIPRAL would be the broadcast address, HWb = SWb, ULAb (likely
0xFE1 and FF.FF.FF.FF.FF.FF).
Node Y starts: its HIPARP table entry state for the primary address
in the HIPRAL: PENDING
1. Node Y initiates its interface and sends an InHIPARP_REQUEST to
the primary address in the HIPRAL, in this example the
broadcast address, after starting a table entry.
HIPPI-LE Destination_Switch_Address = SWb
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAb
Pittet [Page 27]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
HIPPI-LE Source_IEEE_Address = ULAy
HIPARP ar$op = 8 (InHIPARP_REQUEST)
HIPARP ar$rpa = IPy
HIPARP ar$tpa = 0 **
HIPARP ar$rha = SWy ULAy
HIPARP ar$tha = SWb ULAb
** is what we would like to find out
2. Since the network is a broadcast network, client Y will see an
InHIPARP_REQUEST, it examines the source addresses. Since they
are the same as what Y filled in the InHIPARP_REQUEST, Y can
deduce that it is connected to a broadcast medium. Node Y
completes its table entry for the primary address of the
HIPRAL. This entry will not timeout since it is considered less
than likely for a particular underlying hardware type to loose
its quality of being able to do broadcast and therefore this
mapping will never change.
12.3 Operational Phase (phase II)
The Operational Phase of the HIPARP protocol as specified in this
memo is the same for both possibilities of a broadcast and non-
broadcast capable HIPPI hardware. The primary address in the HIPRAL
for this example section will be HWa: <SWa, ULAa> amd IPs for
simplicity reasons.
12.2.1 Standard successful HIPARP_Resolve example
Assume the same process (steps 1-3 of section 10.1) happened for host
X. Then the state of X and Y's tables is: the HIPARP server table
entry is in the VALID state. So lets look at the packet traffic when
X tries to send a packet to Y. Since X doesn't have an entry for Y,
1. node X connects to the primary address of the HIPRAL and sends
a HIPARP_REQUEST for Y's hardware address:
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HIPARP ar$op = 1 (HIPARP_REQUEST)
HIPARP ar$rpa = IPx
HIPARP ar$tpa = IPy
HIPARP ar$rha = SWx ULAx
HIPARP ar$tha = 0 **
** is what we would like to find out
Pittet [Page 28]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
2. The HIPARP server receives the HIPARP request and updates its
entry for X if necessary. It then generates a HIPARP_REPLY with
Y's hardware address information.
HIPPI-LE Destination_Switch_Address = SWx
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAx
HIPPI-LE Source_IEEE_Address = ULAa
HIPARP ar$op = 2 (HIPARP_Reply)
HIPARP ar$rpa = IPy
HIPARP ar$tpa = IPx
HIPARP ar$rha = SWy ULAy *
HIPARP ar$tha = SWx ULAx
* answer we were looking for
7. Node X connects to node Y and transmits an IP packet with the
following information in the HIPPI-LE header:
HIPPI-LE Destination_Switch_Address = SWy
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAy
HIPPI-LE Source_IEEE_Address = ULAx
If there had been a broadcast capable HIPPI network, the target nodes
would themselves have received the HIPARP_REQUEST of step 2 above
and responded to them in the same way the HIPARP server did.
12.3.2 Standard non-successful HIPARP_Resolve example
Like in 12.3.1, assume that X and Y are fully registered with the
HIPARP server. Then the state of X and Y's HIPARP server table entry
is: VALID. So
lets look at the packet traffic when X tries to send a packet 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. node X connects to the HIPARP server switch address and sends
a HIPARP_REQUEST for Q's hardware address:
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HIPARP ar$op = 1 (HIPARP_REQUEST)
HIPARP ar$rpa = IPx
HIPARP ar$tpa = IPq
HIPARP ar$rha = SWx ULAx
HIPARP ar$tha = 0 **
Pittet [Page 29]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
q ** is what we would like to find out
2. The HIPARP server receives the HIPARP request and updates its
entry for X if necessary. It then looks up IPq in its tables
and doesn't find it. The HIPARP server then generates a
HIPARP_NAK reply packet.
HIPPI-LE Destination_Switch_Address = SWx
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAx
HIPPI-LE Source_IEEE_Address = ULAa
HIPARP ar$op = 10 (HIPARP_NAK)
HIPARP ar$rpa = IPx
HIPARP ar$tpa = IPy
HIPARP ar$rha = SWx ULAx
HIPARP ar$tha = 0 ***
*** No Answer, and notice that the fields do not get swapped,
i.e. the HIPARP message is the same as the HIPARP_REQUEST
except for the operation code.
If there had been a broadcast capable HIPPI network, then there
would not have been any reply.
13 References
[1] ANSI X3.183-1991, High-Performance Parallel Interface -
Mechanical, Electrical and Signaling Protocol Specification;
ISO/IEC 11518-1:1995, High-Performance Parallel Interface -
Part 1: Mechanical, Electrical, and Signalling Protocol
Specification (HIPPI-PH).
[2] ANSI X3.210-1992, High-Performance Parallel Interface - Framing
Protocol; ISO/IEC 11518-2:1995 High-Performance Parallel Interface
- Part 2: Framing Protocol (HIPPI-FP).
[3] ANSI X3.218-1993, High-Performance Parallel Interface -
Encapsulation of of ISO 8802-2 (IEEE Std 802.2) Logical Link
Control Protocol Data Units (802.2 Link Encapsulation);
ISO/IEC 11518-3:1995 High-Performance Parallel Interface -
Part 3: Encapsulation of ISO/IEC 8802-2 Logical link control
protocol data units(HIPPI-LE).
[4] ANSI X3.222-1997, High-Performance Parallel Interface - Physical
Switch Control; ISO/IEC 11518-6:199x High-Performance Parallel
Interface - Part 6: Physical Switch Control (HIPPI-SC).
[5] ANSI X3.300-1997, High-Performance Parallel
Pittet [Page 30]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
Interface - Serial Specification, ISO/IEC 11518-6:199x
High-Performance Parallel Interface -
Part 8: Serial Specification (HIPPI-Serial)
[6] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC-1122, USC/Information Sciences Institute, October
1989.
[7] Bradely, T., and Brown, C., "Inverse Address Resolution
Protocol", RFC-1293, USC/Information Sciences Institute, January
1992.
[8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp.
32-48, 1989.
[9] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
USC/Information Sciences Institute, August 1989.
[10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse
Address Resolution Protocol", RFC-903, Stanford University, June
1984.
[11] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985.
[12] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985.
[13] Laubach, Mark., "Classical IP and ARP over ATM", RFC-1577,
Hewlett-Packard Laboratories, January 1994
[14] Mogul, J.C., and Deering, S.E., "Path MTU Discovery", RFC-1191,
Stanford University, November, 1990.
[15] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
[16] Postel, J., "Internet Protocol", STD 5, RFC-791, USC/Information
Sciences Institute, September 1981.
[17] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374,
Cray Research, Inc., October 1992.
[18] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January
1997.
Pittet [Page 31]
INTERNET DRAFT ARP and IP Broadcast over HIPPI 800 Expires 9/98
[20] Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2, RFC-
1340, USC/Information Sciences Institute, July 1992.
[21] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC-1700, USC/Information Sciences Institute, October 1994.
14 Acknowledgments
This memo could not have come into being without the critical review
from Greg Chesson, Carlin Otto, the High performance interconnect
group of Silicon Graphics and the expertise of the ANSI T11.1 Task
Group responsible for the HIPPI standards work.
This memo is based on the second part of [17], written by John
Renwick. ARP [15] written by Dave Plummer and Inverse ARP [7] written
by Terry Bradley and Caralyn Brown provide the fundamental algorithms
of HIPARP as presented in this memo. Further, the HIPARP server is
based on concepts and models presented in [13], written by Mark
Laubach who laid the structural groundwork for the HIPARP server.
15 Author's Address
Jean-Michel Pittet
Silicon Graphics Inc
2011 N. Shoreline Ave
Mountain View, CA 94040
Phone: 650-933-6149
Fax:650-933-3542
EMail: jmp@sgi.com
Pittet [Page 32]
