< draft-pittet-hippiarp-03.txt   draft-pittet-hippiarp-04.txt >
Network Working Group J.-M. Pittet Network Working Group J.-M. Pittet
INTERNET DRAFT Silicon Graphics Inc. INTERNET DRAFT Silicon Graphics Inc.
Expires April 2000 October 1999 Expires July 2000 January 2000
ARP and IP Broadcast over HIPPI-800 ARP and IP Broadcast over HIPPI-800
<draft-pittet-hippiarp-03.txt> <draft-pittet-hippiarp-04.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Abstract Abstract
This document specifies a method for resolving IP addresses to ANSI This document specifies a method for resolving IP addresses to ANSI
High-Performance Parallel Interface (HIPPI) hardware addresses and High-Performance Parallel Interface (HIPPI) hardware addresses and
for emulating IP broadcast in a logical IP subnet (LIS) as a direct for emulating IP broadcast in a logical IP subnet (LIS) as a direct
extension of HARP. This memo defines a HARP that will interoperate extension of HARP. This memo defines a HARP that will interoperate
between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System
Network, GSN). Network, GSN).
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Changes from RFC-1374 . . . . . . . . . . . . . . . . 4 2.1 Changes from RFC-1374 . . . . . . . . . . . . . . . . 4
2.2 Terminology . . . . . . . . . . . . . . . . . . . . . 5 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Global Concepts . . . . . . . . . . . . . . . . . . . 5 3.1 Global Concepts . . . . . . . . . . . . . . . . . . . 5
3.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 5
4. IP Subnetwork Configuration . . . . . . . . . . . . . . . 7 4. IP Subnetwork Configuration . . . . . . . . . . . . . . . 7
4.1 Background . . . . . . . . . . . . . . . . . . . . . 7 4.1 Background . . . . . . . . . . . . . . . . . . . . . 7
4.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 8 4.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 8
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 9 5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 9
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 9 5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 10
5.1.1 Selecting the authoritative HARP service . . . 10 5.1.1 Selecting the authoritative HARP service . . . 10
5.1.2 HARP registration phase . . . . . . . . . . . . 11 5.1.2 HARP registration phase . . . . . . . . . . . . 11
5.1.3 HARP operational phase . . . . . . . . . . . . 12 5.1.3 HARP operational phase . . . . . . . . . . . . 12
5.2 HARP Client Operational Requirements . . . . . . . . . . 13 5.2 HARP Client Operational Requirements . . . . . . . . . . 13
5.3 Receiving Unknown HARP Messages . . . . . . . . . . . 14 5.3 Receiving Unknown HARP Messages . . . . . . . . . . . 14
5.4 HARP Server Operational Requirements . . . . . . . . 14 5.4 HARP Server Operational Requirements . . . . . . . . 14
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 16 5.5 HARP and Permanent ARP Table Entries . . . . . . . . 16
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 16 5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 16
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 17 6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 17
6.1 HIPPI-LE Header of HARP Messages . . . . . . . . . . 17 6.1 HIPPI-LE Header of HARP Messages . . . . . . . . . . 17
skipping to change at page 2, line 45 skipping to change at page 2, line 45
6.2.1 48-bit Universal LAN MAC Addresses . . . . . . 20 6.2.1 48-bit Universal LAN MAC Addresses . . . . . . 20
6.3 HARP and InHARP Message Formats . . . . . . . . . . . 21 6.3 HARP and InHARP Message Formats . . . . . . . . . . . 21
6.3.1 Example Message encodings . . . . . . . . . . . 23 6.3.1 Example Message encodings . . . . . . . . . . . 23
6.3.2 HARP_NAK message format . . . . . . . . . . . . 24 6.3.2 HARP_NAK message format . . . . . . . . . . . . 24
6.3.3 Combined HIPPI-LE and HARP message addresses . 24 6.3.3 Combined HIPPI-LE and HARP message addresses . 24
7. Broadcast and Multicast . . . . . . . . . . . . . . . . . 25 7. Broadcast and Multicast . . . . . . . . . . . . . . . . . 25
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25 7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 26 7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 26
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 26 7.3 IP Multicast Address . . . . . . . . . . . . . . . . 26
7.4 A Note on Broadcast Emulation Performance . . . . . . 26 7.4 A Note on Broadcast Emulation Performance . . . . . . 26
8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 26 8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 27
9. Discovery of One's Own Switch Address . . . . . . . . . . 29 9. Discovery of One's Own Switch Address . . . . . . . . . . 27
10. Security . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Security . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 28 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 28
12. HARP Examples . . . . . . . . . . . . . . . . . . . . . . 28 12. HARP Examples . . . . . . . . . . . . . . . . . . . . . . 28
12.1 Registration Phase of Client Y on Non-broadcast HW . 29 12.1 Registration Phase of Client Y on Non-broadcast HW . 29
12.2 Registration Phase of Client Y on Broadcast Hardware 30 12.2 Registration Phase of Client Y on Broadcast Hardware 30
12.3 Operational Phase (phase II) . . . . . . . . . . . . 30 12.3 Operational Phase (phase II) . . . . . . . . . . . . 30
12.3.1 Standard successful HARP_Resolve example . . 30 12.3.1 Standard successful HARP_Resolve example . . 30
12.3.2 Standard non-successful HARP_Resolve example 31 12.3.2 Standard non-successful HARP_Resolve example 31
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
13. References . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . 32
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 34 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 34
15. Author's Address . . . . . . . . . . . . . . . . . . . . 34 15. Author's Address . . . . . . . . . . . . . . . . . . . . 34
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
1. Introduction 1. Introduction
The ANSI High-Performance Parallel Interface (HIPPI) is a dual The ANSI High-Performance Parallel Interface (HIPPI) is a dual
simplex data channel. HIPPI can send and receive data simplex data channel. HIPPI can send and receive data
simultaneously at 800 or 1600 megabits per second. Between 1987 and simultaneously at 800 or 1600 megabits per second. Between 1987 and
1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1) 1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1)
Standardized five documents that bear on the use of HIPPI as a Standardized five documents that bear on the use of HIPPI as a
network interface. They cover the physical and electrical network interface. They cover the physical and electrical
specification (HIPPI-PH [1]), the framing of a stream of bytes specification (HIPPI-PH [1]), the framing of a stream of bytes
skipping to change at page 5, line 5 skipping to change at page 5, line 5
effort to clarify and expand the definition of ARP over HIPPI as effort to clarify and expand the definition of ARP over HIPPI as
found in RFC-1374 such that implementations will be more readily found in RFC-1374 such that implementations will be more readily
possible, especially considering forward interoperability with possible, especially considering forward interoperability with
HIPPI-6400. HIPPI-6400.
The changes from RFC-1374 [14] are: The changes from RFC-1374 [14] are:
o A new message format to acknowledge the HIPPI hardware address o A new message format to acknowledge the HIPPI hardware address
format and to eliminate the requirement of HIPPI-LE ARP for HARP format and to eliminate the requirement of HIPPI-LE ARP for HARP
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
to function. to function.
o Explicit registration phase. o Explicit registration phase.
o Additional message formats: InHARP requests and replies as o Additional message formats: InHARP requests and replies as
well as HARP_NAKs. well as HARP_NAKs.
o Details about the IP subnetwork configuration. o Details about the IP subnetwork configuration.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
In the following discussion, the terms "requester" and "target" are In the following discussion, the terms "requester" and "target" are
used to identify the port initiating the address resolution request used to identify the port initiating the address resolution request
and the port whose address it wishes to discover, respectively. If and the port whose address it wishes to discover, respectively. If
not all switches in the LIS support broadcast then there will be a not all switches in the LIS support broadcast then there will be a
HARP server providing the address resolution service and it will be HARP server providing the address resolution service and it will be
the source of the reply. If on the other hand all switches support the source of the reply. If on the other hand all switches support
broadcast then the source address of a reply will be the target's broadcast then the source address of a reply will be the target's
target address. target address.
Values are decimal unless otherwise noted. Values are decimal unless otherwise noted. Formatting follows IEEE
802.1A canonical bit order and and HIPPI-FP bit and byte order.
3.2 Glossary 3.2 Glossary
Broadcast Broadcast
A distribution mode which transmits a message to all ports. A distribution mode which transmits a message to all ports.
Particularly also the port sending the message. Particularly also the port sending the message.
Classical/Conventional Classical/Conventional
Both terms are used to refer to networks such as Ethernet, FDDI, and Both terms are used to refer to networks such as Ethernet, FDDI, and
other 802 LAN types, as distinct from HIPPI-SC LANs. other 802 LAN types, as distinct from HIPPI-SC LANs.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
Destination Destination
The HIPPI port that receives data from a HIPPI Source. The HIPPI port that receives data from a HIPPI Source.
HARP HARP
HARP describes the whole set of HIPPI address resolution encodings HARP describes the whole set of HIPPI address resolution encodings
and algorithms defined in this memo. HARP is a combination and and algorithms defined in this memo. HARP is a combination and
adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 adaptation of the Internet Address Resolution Protocol (ARP) RFC-826
skipping to change at page 6, line 32 skipping to change at page 6, line 32
Each host has a HARP table which contains the IP to hardware address Each host has a HARP table which contains the IP to hardware address
mapping of IP members. mapping of IP members.
HIPPI-Serial HIPPI-Serial
An implementation of HIPPI in serial fashion on coaxial cable or An implementation of HIPPI in serial fashion on coaxial cable or
optical fiber. (see [5]) optical fiber. (see [5])
HRAL HRAL
The HARP Request Address List (see section 4.2). The HARP Request Address List. A list of ULAs to which HARP messages
are sent when resolving names to addresses (see section 4.2).
Hardware (HW) address Hardware (HW) address
The hardware address consisting of an I-Field and an optional ULA The hardware address of a port consisting of an I-Field and an
(see section 6.2) optional ULA (see section 6.2). Note: the term port as used in this
document refers to a HIPPI port and is roughly equivalent to the term
"interface" as commonly used in other IP documents.
Host Host
An entity, usually a computer system, that may have one or more HIPPI An entity, usually a computer system, that may have one or more HIPPI
ports and which may serve as a client or a HARP server. ports and which may serve as a client or a HARP server.
Port Port
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
An entity consisting of one HIPPI Source/Destination dual simplex An entity consisting of one HIPPI Source/Destination dual simplex
pair that is connected by parallel or serial HIPPI to a HIPPI-SC pair that is connected by parallel or serial HIPPI to a HIPPI-SC
switch and that transmits and receives IP datagrams. switch and that transmits and receives IP datagrams.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
PIBES PIBES
The Protocol for Internet Broadcast Emulation Server (see section 7). The Protocol for Internet Broadcast Emulation Server (see section 7).
Switch Address Switch Address
A value used as the address of a port on a HIPPI-SC network. It is A value used as the address of a port on a HIPPI-SC network. It is
transmitted in the I-field. HIPPI-SC switches map Switch Addresses transmitted in the I-field. HIPPI-SC switches map Switch Addresses
to physical switch port numbers. The switch address is extended with to physical switch port numbers. The switch address is extended with
a mode byte to form an I-Field (see [4] and 6.2.2) a mode byte to form an I-Field (see [4] and 6.2.2)
skipping to change at page 7, line 47 skipping to change at page 8, line 4
HARP has LIS scope only and serves all ports in the LIS. HARP has LIS scope only and serves all ports in the LIS.
Communication to ports located outside of the local LIS is usually Communication to ports located outside of the local LIS is usually
provided via an IP router. This router is a HIPPI port attached to provided via an IP router. This router is a HIPPI port attached to
the HIPPI network that is configured as a member of one or more the HIPPI network that is configured as a member of one or more
LIS's. This configuration MAY result in a number of disjoint LIS's LIS's. This configuration MAY result in a number of disjoint LIS's
operating over the same HIPPI network. Using this model, ports of operating over the same HIPPI network. Using this model, ports of
different IP subnets SHOULD communicate via an intermediate IP router different IP subnets SHOULD communicate via an intermediate IP router
even though it may be possible to open a direct HIPPI connection even though it may be possible to open a direct HIPPI connection
between the two IP members over the HIPPI network. This is a between the two IP members over the HIPPI network. This is a
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
consequence of using IP and choosing to have multiple LIS's on the consequence of using IP and choosing to have multiple LIS's on the
same HIPPI fabric. same HIPPI fabric.
By default, the HARP method detailed in section 5 and the classical By default, the HARP method detailed in section 5 and the classical
LIS routing model MUST be available to any IP member client in the LIS routing model MUST be available to any IP member client in the
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
LIS. LIS.
4.2 HIPPI LIS Requirements 4.2 HIPPI LIS Requirements
The requirement for IP members (hosts, routers) operating in a HIPPI The requirement for IP members (hosts, routers) operating in a HIPPI
LIS configuration is: LIS configuration is:
o All members of the LIS SHALL have the same IP network/subnet o All members of the LIS SHALL have the same IP network/subnet
address and address mask [6]. address and address mask [6].
skipping to change at page 8, line 35 skipping to change at page 8, line 40
contain a non-zero ULA address. If there is no ULA then that field contain a non-zero ULA address. If there is no ULA then that field
MUST be zero. MUST be zero.
o HARP Request Address List (HRAL): o HARP Request Address List (HRAL):
The HRAL is an ordered list of two or more addresses identifying The HRAL is an ordered list of two or more addresses identifying
the address resolution service(s). All HARP clients MUST be the address resolution service(s). All HARP clients MUST be
configured identically, i.e. all ports MUST have the same configured identically, i.e. all ports MUST have the same
addresses(es) in the HRAL. addresses(es) in the HRAL.
The HRAL MUST Contain at least two HIPPI HW addresses identifying The HRAL MUST contain at least two HIPPI HW addresses identifying
the individual HARP service(s) that have authoritative the individual HARP service(s) that have authoritative
responsibility for resolving HARP requests of all IP members responsibility for resolving HARP requests of all IP members
located within the LIS. located within the LIS.
It is REQUIRED that the first address be the address used for By default the first address MUST be the reserved address for
broadcasting messages i.e. the address for "IP traffic broadcast, i.e. the address for "IP traffic conventionally
conventionally directed to the IEEE 802.1 broadcast address: directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The ULA
0xFE1" [4]. The ULA for this HARP service entry SHALL be for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF.
FF:FF:FF:FF:FF:FF.
It is REQUIRED that the second address be the address for It is REQUIRED that the second address be the address for
"Messages pertaining to (the) ... address resolution requests: "Messages pertaining to (the) ... address resolution requests:
0xFE0" [4]. The ULA for this HARP server entry is 0xFE0" [4]. The ULA for this HARP server entry is
00:00:00:00:00:00. 00:00:00:00:00:00.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
Therefore, the HRAL entries are sorted in the following order: Therefore, the HRAL entries are sorted in the following order:
1st : broadcast address (0x07000FE1 1st ** : broadcast address (0x07000FE1 FF:FF:FF:FF:FF:FF),
FF:FF:FF:FF:FF:FF), 2nd ** : official HARP server address (0x07000FE0 00:00:00:00:00:00),
2nd : official HARP server address (0x07000FE0
00:00:00:00:00:00),
3rd & on: any additional HARP server addresses will be sorted in 3rd & on: any additional HARP server addresses will be sorted in
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
decreasing order of the 12bit destination switch decreasing order of the 12bit destination switch
address portion of their I-Field (see section 6.2). address portion of their I-Field (see section 6.2).
** REQUIRED
Within the restrictions mentioned above and in Section 6.2.2, local Within the restrictions mentioned above and in Section 6.2.2, local
administration choose address(es) for the additional HARP services administration choose address(es) for the additional HARP services
which they will put into the HRAL. which they will put into the HRAL.
An example of such a list: An example of such a list:
1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF 1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF
2nd entry: 0x07000FE0 00:00:00:00:00:00 2nd entry: 0x07000FE0 00:00:00:00:00:00
3rd entry: 0x07000001 <Alternate-HARP-server-ula> 3rd entry: 0x07000001 <Alternate-HARP-server-ula>
... ...
Manual configuration of the addresses and address lists presented in Manual configuration of the addresses and address lists presented in
this section is implementation dependent and further details are this section is implementation dependent and beyond the scope of this
beyond the scope of this memo. memo.
5. HIPPI Address Resolution Protocol - HARP 5. HIPPI Address Resolution Protocol - HARP
Address resolution within the HIPPI LIS SHALL make use of the HIPPI Address resolution within the HIPPI LIS SHALL make use of the HIPPI
Address Resolution Protocol (HARP) and the Inverse HIPPI Address Address Resolution Protocol (HARP) and the Inverse HIPPI Address
Resolution Protocol (InHARP). HARP provides the same functionality as Resolution Protocol (InHARP). HARP provides the same functionality as
the Internet Address Resolution Protocol (ARP). HARP is based on ARP the Internet Address Resolution Protocol (ARP). HARP is based on ARP
which is defined in RFC-826 [13]. Knowing the Internet address, which is defined in RFC-826 [13]. Knowing the Internet address,
conventional networks use ARP to discover another port's hardware conventional networks use ARP to discover another port's hardware
address. HARP presented in this section further specifies the address. HARP presented in this section further specifies the
skipping to change at page 9, line 48 skipping to change at page 9, line 53
presented in [7]. Knowing its hardware address, InARP is used to presented in [7]. Knowing its hardware address, InARP is used to
discover the other party's Internet address. discover the other party's Internet address.
This memo further REQUIRES the PIBES (see section 7 below) extension This memo further REQUIRES the PIBES (see section 7 below) extension
to the HARP protocol, guaranteeing broadcast service to upper layer to the HARP protocol, guaranteeing broadcast service to upper layer
protocols like IP. protocols like IP.
Internet addresses are assigned independent of ULAs and switch Internet addresses are assigned independent of ULAs and switch
addresses. Before using HARP, each port MUST know its IP and its addresses. Before using HARP, each port MUST know its IP and its
hardware addresses. The ULA is optional but is RECOMMENDED if hardware addresses. The ULA is optional but is RECOMMENDED if
interoperability with conventional networks is desired. bridging to conventional networks is desired.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
5.1 HARP Algorithm 5.1 HARP Algorithm
This section defines the behavior and requirements for HARP This section defines the behavior and requirements for HARP
implementations on both broadcast and non-broadcast capable HIPPI-SC implementations on both broadcast and non-broadcast capable HIPPI-SC
networks. HARP creates a table in each port which maps the IP address networks. HARP creates a table in each port which maps the IP address
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
of each port to a hardware address, so that when an application of each port to a hardware address, so that when an application
requests a connection to a remote port by its IP address, the requests a connection to a remote port by its IP address, the
hardware address can be determined, a correct HIPPI-LE header can be hardware address can be determined, a correct HIPPI-LE header can be
built, and a connection to the port can be established using the built, and a connection to the port can be established using the
correct Switch Address in the I-field. correct Switch Address in the I-field.
HARP is a two phase protocol. The first phase is the registration HARP is a two phase protocol. The first phase is the registration
phase and the second phase is the operational phase. In the phase and the second phase is the operational phase. In the
registration phase the port detects if it is connected to broadcast registration phase the port detects if it is connected to broadcast
hardware or not. The InHARP protocol is used in the registration hardware or not. The InHARP protocol is used in the registration
skipping to change at page 10, line 48 skipping to change at page 10, line 53
the HRAL. Every address which sends an InHARP_REPLY is considered to the HRAL. Every address which sends an InHARP_REPLY is considered to
be a responsive HARP server. The authoritative HARP service SHALL be be a responsive HARP server. The authoritative HARP service SHALL be
the HARP server which appears first in the HRAL. the HARP server which appears first in the HRAL.
The sequence of the HRAL is only important for deciding which address The sequence of the HRAL is only important for deciding which address
will be the authoritative one. On a non-broadcast network, the port will be the authoritative one. On a non-broadcast network, the port
is REQUIRED to keep "registered" with all HARP server addresses in is REQUIRED to keep "registered" with all HARP server addresses in
the HRAL (NOTE: not the broadcast address since it is not a HARP the HRAL (NOTE: not the broadcast address since it is not a HARP
server address). If for instance the authoritative HARP service is server address). If for instance the authoritative HARP service is
non-responsive, then the port will consider the next address in the non-responsive, then the port will consider the next address in the
HRAL as a candidate for the selected address and send an HRAL as a candidate for the authoritative address and send an
InHARP_REQUEST. InHARP_REQUEST.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
The authoritative HARP server SHOULD be considered non-responsive The authoritative HARP server SHOULD be considered non-responsive
when it has failed to reply to: (1) one or more registration requests when it has failed to reply to: (1) one or more registration requests
by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs
in the last 120 seconds or (3) if an external agent has detected in the last 120 seconds or (3) if an external agent has detected
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
failure of the authoritative HARP server. The details of such an failure of the authoritative HARP server. The details of such an
external agent and its interaction with the HARP client are beyond external agent and its interaction with the HARP client are beyond
the scope of this document. Should an authoritative HARP server the scope of this document. Should an authoritative HARP server
become non-responsive, then the registration process SHOULD be become non-responsive, then the registration process SHOULD be
restarted. Alternative methods for choosing an authoritative HARP restarted. Alternative methods for choosing an authoritative HARP
service are not prohibited. service are not prohibited.
5.1.2 HARP registration phase 5.1.2 HARP registration phase
HARP clients SHALL initiate the registration phase by sending an HARP clients SHALL initiate the registration phase by sending an
InHARP_REQUEST message using the addresses in the HRAL in order. The InHARP_REQUEST message using the addresses in the HRAL in order. The
client SHALL terminate the registration phase and transition into the client SHALL terminate the registration phase and transition into the
operational phase, either when it receives its own InHARP_REQUEST or operational phase, either when it receives its own InHARP_REQUEST or
when it receives an InHARP_REPLY from at least one of the HARP when it receives an InHARP_REPLY from at least one of the HARP
servers and when it has determined the authoritative HARP service as servers and when it has determined the authoritative HARP service as
described in section 5.1.1. described in section 5.1.1.
When ports are initiated they send an InHARP_REQUEST to the selected When ports are initiated they send an InHARP_REQUEST to the
address as described in section 5.1.2. The first address to be tried authoritative address as described in section 5.1.2. The first
will be the broadcast address "0x07000FE1 FF:FF:FF:FF:FF:FF". There address to be tried will be the broadcast address "0x07000FE1
are two outcomes: FF:FF:FF:FF:FF:FF". There are two outcomes:
1. The port sees its own InHARP_REQUEST: then the port is connected 1. The port sees its own InHARP_REQUEST: then the port is connected
to a broadcast capable network. The first address becomes and to a broadcast capable network. The first address becomes and
remains the selected address for the HARP service. remains the authoritative address for the HARP service.
2. The port does not receive its InHARP_REQUEST: then the port is 2. The port does not receive its InHARP_REQUEST: then the port is
connected to a non-broadcast capable network. connected to a non-broadcast capable network.
In the second case, the port SHALL choose the next address in the In the second case, the port SHALL choose the next address in the
HRAL as a candidate for a selected address and send an InHARP_REQUEST HRAL as a candidate for a authoritative address and send an
to that address: (0x07000FE0 00:00:00:00:00:00). InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).
o If the port receives its own message, then the port itself is the o If the port receives its own message, then the port itself is the
HARP server and the port is REQUIRED to provide broadcast services HARP server and the port is REQUIRED to provide broadcast services
using the PIBES (see section 7). using the PIBES (see section 7).
o If the port receives an InHARP_REPLY, then it is a HARP client and o If the port receives an InHARP_REPLY, then it is a HARP client and
not a HARP server. not a HARP server.
In both cases, the current candidate address becomes the In both cases, the current candidate address becomes the
authoritative HARP service address. authoritative HARP service address.
If the client determines it is connected to a non-broadcast capable If the client determines it is connected to a non-broadcast capable
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
network then the client SHALL continue to retry each non-broadcast network then the client SHALL continue to retry each non-broadcast
HARP server address in the HRAL at least once every 5 seconds until HARP server address in the HRAL at least once every 5 seconds until
one of these two termination criteria are met for each address. one of these two termination criteria are met for each address.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
InHARP is an application of the InARP protocol for a purpose not InHARP is an application of the InARP protocol for a purpose not
originally intended. The purpose is to accomplish registration of originally intended. The purpose is to accomplish registration of
port IP address mappings with a HARP server if one exists or detect port IP address mappings with a HARP server if one exists or detect
hardware broadcast capability. hardware broadcast capability.
If the HIPPI-SC LAN supports broadcast, then the client will see its If the HIPPI-SC LAN supports broadcast, then the client will see its
own InHARP_REQUEST message and SHALL complete the registration phase. own InHARP_REQUEST message and SHALL complete the registration phase.
The client SHOULD further note that it is connected to a broadcast The client SHOULD further note that it is connected to a broadcast
capable network and use this information for aging the HARP server capable network and use this information for aging the HARP server
entry and for IP broadcast emulation as specified in sections 5.4 and entry and for IP broadcast emulation as specified in sections 5.4 and
skipping to change at page 12, line 31 skipping to change at page 12, line 35
also provide the client with the protocol address by which the HARP also provide the client with the protocol address by which the HARP
server is addressable. This will be the case when the client happens server is addressable. This will be the case when the client happens
to be connected to a non-broadcast capable HIPPI-SC network. to be connected to a non-broadcast capable HIPPI-SC network.
5.1.3 HARP operational phase 5.1.3 HARP operational phase
Once a HARP client has completed its registration phase it enters the Once a HARP client has completed its registration phase it enters the
operational phase. In this phase of the protocol, the HARP client operational phase. In this phase of the protocol, the HARP client
SHALL gain and refresh its own HARP table which contains the IP to HW SHALL gain and refresh its own HARP table which contains the IP to HW
address mapping of IP members by sending HARP_REQUESTS to the address mapping of IP members by sending HARP_REQUESTS to the
selected address in the HRAL and receiving HARP_REPLYs. The client is authoritative address in the HRAL and receiving HARP_REPLYs. The
fully operational during the operational phase. client is fully operational during the operational phase.
In the operational phase, the client's behavior for requesting HARP In the operational phase, the client's behavior for requesting HARP
resolution is the same for broadcast or non-broadcast networks. resolution is the same for broadcast or non-broadcast networks.
The target of an address resolution request updates its address The target of an address resolution request updates its address
mapping tables with any new information it can find in the request. 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. If it is the target port it SHALL formulate and send a reply message.
A port is the target of an address resolution request if at least ONE A port is the target of an address resolution request if at least ONE
of the following statements is true of the request: of the following statements is true of the request:
1. The port's IP address is in the target protocol address field 1. The port's IP address is in the target protocol address field
(ar$tpa) of the HARP message. (ar$tpa) of the HARP message.
2. The port's ULA (if non-zero), is in the ULA part of the Target 2. The port's ULA (if non-zero), is in the ULA part of the Target
Hardware Address field (ar$tha) of the message. Hardware Address field (ar$tha) of the message.
3. The port's switch address is in the Target Switch Address field 3. The port's switch address is in the Target Switch Address field
of Target Hardware Address field (ar$tha) of the message (see of Target Hardware Address field (ar$tha) of the message (see
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
section 6.2.2). section 6.2.2).
4. The port is a HARP server. 4. The port is a HARP server.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
NOTE: It is RECOMMENDED that all HARP servers run on a ports which NOTE: It is RECOMMENDED that all HARP servers run on a ports which
each have a non-zero ULA. each have a non-zero ULA.
5.2 HARP Client Operational Requirements 5.2 HARP Client Operational Requirements
The HARP client is responsible for contacting the HARP server(s) to The HARP client is responsible for contacting the HARP server(s) to
have its own HARP information registered and to gain and refresh its have its own HARP information registered and to gain and refresh its
own HARP entry/information about other IP members. This means, as own HARP entry/information about other IP members. This means, as
noted above, that HARP clients MUST be configured with the hardware noted above, that HARP clients MUST be configured with the hardware
address of the HARP server(s) in the HRAL. address of the HARP server(s) in the HRAL.
HARP clients MUST: HARP clients MUST:
1. When an interface is enabled, changes hardware or IP address 1. When an interface is enabled (e.g. "ifconfig <interface> up" with
or is assigned an IP alias, the client SHALL initiate the an IP address) or assigned the first or an additional IP address
registration phase. (i.e. an IP alias), the client SHALL initiate the registration
phase.
2. In the operational phase the client MUST respond to HARP_REQUEST 2. In the operational phase the client MUST respond to HARP_REQUEST
and InHARP_REQUEST messages if it is the target port. If an and InHARP_REQUEST messages if it is the target port. If an
interface has multiple IP addresses (e.g., IP aliases) then the interface has multiple IP addresses (e.g., IP aliases) then the
client MUST cycle through all the IP addresses and generate an client MUST cycle through all the IP addresses and generate an
InHARP_REPLY for each such address. In that case an InHARP_REPLY for each such address. In that case an
InHARP_REQUEST will have multiple replies. (Refer to Section 7, InHARP_REQUEST will have multiple replies. (Refer to Section 7,
"Protocol Operation" in RFC-1293 [7].) "Protocol Operation" in RFC-1293 [7].)
3. React to address resolution reply messages appropriately to build 3. React to address resolution reply messages appropriately to build
or refresh its HARP table entries. All solicited and unsolicited or refresh its own client HARP table entries. All solicited and
HARP_REPLYs from the authoritative HARP server SHALL be used to unsolicited HARP_REPLYs from the authoritative HARP server SHALL
update and refresh its HARP table entries. be used to update and refresh its own client HARP table entries.
Explanation: This allows the HARP server to update the clients Explanation: This allows the HARP server to update the clients
when one of server's mappings change, similar to what is when one of server's mappings change, similar to what is
accomplished on Ethernet with gratuitous ARP. accomplished on Ethernet with gratuitous ARP.
4. Generate and transmit InHARP_REQUEST messages as needed and 4. Generate and transmit InHARP_REQUEST messages as needed and
process InHARP_REPLY messages appropriately (see section 5.1.2 process InHARP_REPLY messages appropriately (see section 5.1.2
and 5.6). All InHARP_REPLY messages SHALL be used by the client and 5.6). All InHARP_REPLY messages SHALL be used by the client
to build or refresh its HARP table entries. (Refer to Section 7, to build or refresh its HARP table entries. (Refer to Section 7,
"Protocol Operation" in [7].) "Protocol Operation" in [7].)
If the registration phase showed that the hardware does not support If the registration phase showed that the hardware does not support
broadcast, then the client MUST refresh its own entry for the HARP broadcast, then the client MUST refresh its own entry for the HARP
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
server, created during the registration phase, at least once every 15 server, created during the registration phase, at least once every 15
minutes. This can be accomplished either through the exchange of a minutes. This can be accomplished either through the exchange of a
HARP request/reply with the HARP server or by repeating step 1. To HARP request/reply with the HARP server or by repeating step 1. To
decrease the redundant network traffic, this timeout SHOULD be reset decrease the redundant network traffic, this timeout SHOULD be reset
after each HARP_REQUEST/HARP_REPLY exchange. after each HARP_REQUEST/HARP_REPLY exchange.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
Explanation: The HARP_REQUEST shows the HARP server that the client Explanation: The HARP_REQUEST shows the HARP server that the client
is still alive. Receiving a HARP_REPLY indicates to the client that is still alive. Receiving a HARP_REPLY indicates to the client that
the server must have seen the HARP_REQUEST. the server must have seen the HARP_REQUEST.
If the registration phase shows that the underlying network supports If the registration phase shows that the underlying network supports
broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of
step 4 are NOT REQUIRED. step 4 are NOT REQUIRED.
5.3 Receiving Unknown HARP Messages 5.3 Receiving Unknown HARP Messages
skipping to change at page 15, line 5 skipping to change at page 15, line 5
requested information in its tables; otherwise it SHALL reply with a requested information in its tables; otherwise it SHALL reply with a
HARP_NAK. The HARP server replies SHALL contain the hardware type and HARP_NAK. The HARP server replies SHALL contain the hardware type and
corresponding format of the request (see also section 6). corresponding format of the request (see also section 6).
The following table shows all possible source address combinations on The following table shows all possible source address combinations on
an incoming message and the actions to be taken. "linked" indicates an incoming message and the actions to be taken. "linked" indicates
that an existing "IP entry" is linked to a "hardware entry". It is that an existing "IP entry" is linked to a "hardware entry". It is
possible to have an existing "IP entry" and to have an existing possible to have an existing "IP entry" and to have an existing
"hardware entry" but neither is linked to the other. "hardware entry" but neither is linked to the other.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
+---+----------+----------+------------+---------------------+ +---+----------+----------+------------+---------------------+
| # | IP entry | HW entry | misc | Action | | # | IP entry | HW entry | misc | Action |
+---+----------+----------+------------+---------------------+ +---+----------+----------+------------+---------------------+
| 1 | exists | exists | linked | * | | 1 | exists | exists | linked | * |
| 2 | exists | exists | not linked | *, a, b, e, f | | 2 | exists | exists | not linked | *, a, b, e, f |
| 3 | exists | new | not linked | *, a, b, d, e, f | | 3 | exists | new | not linked | *, a, b, d, e, f |
| 4 | new | exists | not linked | *, c, e, f | | 4 | new | exists | not linked | *, c, e, f |
| 5 | new | new | not linked | *, c, d, e, f | | 5 | new | new | not linked | *, c, d, e, f |
+---+----------+----------+------------+---------------------+ +---+----------+----------+------------+---------------------+
Actions: Actions:
*: update timeout value *: update timeout value
a: break the existing IP -> hardware (HW) - old link a: break the existing IP -> hardware (HW) - old link
b: delete HW(old) -> IP link and decrement HW(old) refcount, if b: delete HW(old) -> IP link and decrement HW(old) refcount, if
refcount = 0, delete HW(old) refcount = 0, delete HW(old)
c: create new IP entry c: create new IP entry
d: create new HW entry d: create new HW entry
e: add new IP -> HW link to IP entry e: add new IP -> HW link to IP entry
f: add new HW -> IP link to HW entry f: add new HW -> IP link to HW entry
Examples of when this could happen: Examples of when this could happen (Numbers match lines in above
table):
1: supplemental message 1: supplemental message
Just update timer. Just update timer.
2: move an IP alias to an existing interface 2: move an IP alias to an existing interface
If the IP source address of the InHARP_REQUEST duplicates a table If the IP source address of the InHARP_REQUEST duplicates a table
entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST
hardware source address matches a hardware address entry (e.g. HWb hardware source address matches a hardware address entry (e.g. HWb
skipping to change at page 15, line 48 skipping to change at page 15, line 49
- HWa entry needs to have its reference to the current IPa address - HWa entry needs to have its reference to the current IPa address
removed. removed.
- HWb needs to have a new reference to IPa added - HWb needs to have a new reference to IPa added
- IPa needs to be linked to HWb - IPa needs to be linked to HWb
3: move IP address to a new interface 3: move IP address to a new interface
If the InHARP_REQUEST requester's IP source address duplicates a If the InHARP_REQUEST requester's IP source address duplicates a
table entry IP address and the InHARP_REQUEST hardware source table entry IP address and the InHARP_REQUEST hardware source
address does not match the table entry hardware address, then a address does not match the table entry hardware address, then a
new HW entry SHALL be created and the IP entry SHALL be updated. new HW entry SHALL be created. The requestor's IP address SHALL be
moved from the original HW entry to the new one (see above).
4: add IP alias to table 4: add IP alias to table
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
If the InHARP_REQUEST requester's hardware source address If the InHARP_REQUEST requester's hardware source address
duplicates a hardware source address entry, but there is no IP duplicates a hardware source address entry, but there is no IP
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
entry matching the received IP address, then the IP address SHALL entry matching the received IP address, then the IP address SHALL
be added to the hardware entry in addition to the other IP be added to the hardware entries previous IP address(es). (E.g.
address(es) already mapped to the hardware entry. (E.g. adding an adding an IP alias).
IP alias).
5: fresh entry, add it 5: fresh entry, add it
Standard case, create both entries and link them. Standard case, create both entries and link them.
A server MUST update the HARP table entry's timeout for each A server MUST update the HARP table entry's timeout for each
HARP_REQUEST. Explanation: if the client is sending HARP requests to HARP_REQUEST. Explanation: if the client is sending HARP requests to
the server, then the server SHOULD note that the client is still the server, then the server SHOULD note that the client is still
"alive" by updating the timeout on the client's HARP table entry. "alive" by updating the timeout on the client's HARP table entry.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
aliases and also interfaces (with their ULA), are likely to move. aliases and also interfaces (with their ULA), are likely to move.
When so doing the mapping in the clients own HARP table/cache becomes When so doing the mapping in the clients own HARP table/cache becomes
invalid and stale. invalid and stale.
o When a client's HARP table entry ages beyond 15 minutes, a HARP o When a client's HARP table entry ages beyond 15 minutes, a HARP
client MUST invalidate the table entry. client MUST invalidate the table entry.
o When a server's HARP table entry ages beyond 20 minutes, the HARP o When a server's HARP table entry ages beyond 20 minutes, the HARP
server MUST delete the table entry. server MUST delete the table entry.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
NOTE: the client SHOULD revalidate a HARP table entry before it ages, NOTE: the client SHOULD revalidate a HARP table entry before it ages,
thus restarting the aging time when the table entry is successfully thus restarting the aging time when the table entry is successfully
revalidated. The client MAY continue sending traffic to the port revalidated. The client MAY continue sending traffic to the port
referred to by this entry while revalidation is in progress, as long referred to by this entry while revalidation is in progress, as long
as the table entry has not aged. The client MUST revalidate an aged as the table entry has not aged. The client MUST revalidate an aged
entry prior to transmitting any non-address-resolution traffic to the entry prior to transmitting any non-address-resolution traffic to the
port referred to by this entry. port referred to by this entry.
The client revalidates the entry by querying the HARP server with a The client revalidates the entry by querying the HARP server with a
skipping to change at page 18, line 5 skipping to change at page 18, line 5
NOT address the implications on HARP when this bit is set to 1 NOT address the implications on HARP when this bit is set to 1
indicating the possibility of a port being able to accept 64-bit indicating the possibility of a port being able to accept 64-bit
HIPPI connections. HIPPI connections.
Message_Type SHALL contain 0 to indicate a data message. HARP Message_Type SHALL contain 0 to indicate a data message. HARP
messages are identified using the Ethertype and the message type in messages are identified using the Ethertype and the message type in
the ar$op field of the HARP message. the ar$op field of the HARP message.
Destination_Switch_Address, SHALL be the Switch Address of the Destination_Switch_Address, SHALL be the Switch Address of the
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
destination port. destination port.
Destination_IEEE_Address SHALL be the ULA of the destination port, if Destination_IEEE_Address SHALL be the ULA of the destination port, if
known, otherwise zero. known, otherwise zero.
Destination_Address_Type SHALL be 2, a 12-bit logical address. The Destination_Address_Type SHALL be 2, a 12-bit logical address. The
behavior with type = 1, source routing, is NOT defined in this behavior with type = 1, source routing, is NOT defined in this
specification. specification.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
6.1.2 SNAP 6.1.2 SNAP
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
indicating that the following two-bytes is an Ethertype. indicating that the following two-bytes is an Ethertype.
The Ethertype value SHALL be set as defined in Assigned Numbers [16]: The Ethertype value SHALL be set as defined in Assigned Numbers [16]:
InHARP = InARP = HARP = ARP = 2054 = 0x0806. InHARP = InARP = HARP = ARP = 2054 = 0x0806.
The total size of the LLC/SNAP header is fixed at 8-bytes. The total size of the LLC/SNAP header is fixed at 8-bytes.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
6.1.3 HIPPI-LE header Diagram 6.1.3 HIPPI-LE header Diagram
HIPPI-LE header for HARP/InHARP PDUs: HIPPI-LE header for HARP/InHARP PDUs:
31 28 23 21 15 10 7 2 0 31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+ +-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 = IP ULP |1|0| 000 | 03 | 0 | 0 | 04 = IP ULP |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+ +---------------+-+-+---------------------+---------------+-----+
1 | n + 8 | 1 | n + 8 |
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Words 10-(N-1): D2_Area (HARP message) Words 10-(N-1): D2_Area (HARP message)
(n+8) is the nb of bytes in the HARP message, incl. LLC/SNAP. (n+8) is the nb of bytes in the HARP message, incl. LLC/SNAP.
+====+ denotes the boundary between D1_Area and D2_Area. +====+ denotes the boundary between D1_Area and D2_Area.
[LA] fields are zero unless used otherwise locally. [LA] fields are zero unless used otherwise locally.
Abbreviations: Abbreviations:
"W" = Double_Wide field SHALL be 0 "W" = Double_Wide field SHALL be 0
"M_Type" = Message_Type field SHALL be set according to "M_Type" = Message_Type field SHALL be set according to
HIPPI-LE HIPPI-LE
"D_A_T" = Destination_Address_Type SHALL be 2 "D_A_T" = Destination_Address_Type SHALL be 2
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
"S_A_T" = Source_Address_Type SHALL be 2 "S_A_T" = Source_Address_Type SHALL be 2
[FILL] bytes complete the HIPPI message to an even [FILL] bytes complete the HIPPI message to an even
number of 32 bit words. The number of fill bytes number of 32 bit words. The number of fill bytes
is not counted in the data length. is not counted in the data length.
6.2 HIPPI Hardware Address Formats and Requirements 6.2 HIPPI Hardware Address Formats and Requirements
For HIPPI-800, the Hardware Address is a 10-byte unit that SHALL For HIPPI-800, the Hardware Address is a 10-byte unit that SHALL
contain the Switch Address AND the ULA. The format of a hardware contain the Switch Address AND the ULA. The format of a hardware
skipping to change at page 21, line 5 skipping to change at page 21, line 5
format. The globally unique part of the 48-bit space is administered format. The globally unique part of the 48-bit space is administered
by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA. by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA.
Multiple ULAs may be used if a port contains more than one IEEE 802.2 Multiple ULAs may be used if a port contains more than one IEEE 802.2
LLC protocol entity. LLC protocol entity.
The format of the HIPPI hardware address within its HARP message The format of the HIPPI hardware address within its HARP message
follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte 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 order. For example the requester's ULA part of the HIPPI hardware
address would decompose to: address would decompose to:
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
31 23 15 7 0 31 23 15 7 0
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
|ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 | |ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 | | ULA byte 4 | ULA byte 5 |
+---------------+---------------+ +---------------+---------------+
Universal LAN MAC Address Format Universal LAN MAC Address Format
skipping to change at page 22, line 5 skipping to change at page 22, line 5
Data sizes and field meaning: Data sizes and field meaning:
ar$hrd 16 bits Hardware type ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below ar$pro 16 bits Protocol type of the protocol fields below
ar$op 16 bits Operation code (request, reply, or NAK) ar$op 16 bits Operation code (request, reply, or NAK)
ar$pln 8 bits byte length of each protocol address ar$pln 8 bits byte length of each protocol address
ar$rhl 8 bits requester's HIPPI hardware address length (q) ar$rhl 8 bits requester's HIPPI hardware address length (q)
ar$thl 8 bits target's HIPPI hardware address length (x) ar$thl 8 bits target's HIPPI hardware address length (x)
ar$rpa 32 bits requester's protocol address ar$rpa 32 bits requester's protocol address
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
ar$tpa 32 bits target's protocol address ar$tpa 32 bits target's protocol address
ar$rha qbytes requester's HIPPI Hardware address ar$rha qbytes requester's HIPPI Hardware address
ar$tha xbytes target's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address
Where : Where :
ar$hrd - SHALL contain 28. (HIPARP) ar$hrd - SHALL contain 28. (HIPARP)
ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$pro - SHALL contain the IP protocol code 2048 (decimal).
skipping to change at page 23, line 5 skipping to change at page 23, line 5
target's IP address if known, otherwise zero. target's IP address if known, otherwise zero.
In other replies it SHALL contain the requester's In other replies it SHALL contain the requester's
IP address. IP address.
The format of the six bytes of the ULA SHALL be the same as required The format of the six bytes of the ULA SHALL be the same as required
in the HIPPI-LE header (see section 6.2), except for the alignment of in the HIPPI-LE header (see section 6.2), except for the alignment of
the ULAs with respect to the 32-bit HIPPI word, which is different 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 between ARP and HIPPI-LE. No bit reversal is necessary as is
required with FDDI. required with FDDI.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
31 28 23 21 15 10 7 2 0 31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+ +-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 | 0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+ +---------------+-+-+---------------------+---------------+-----+
1 | 45 | 1 | 45 |
+-----+-+-------+-----------------------+-----------------------+ +-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr | 2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+ +-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr | 3 | 2 | 2 | 000 | Source Switch Addr |
skipping to change at page 24, line 5 skipping to change at page 24, line 5
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL | 19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
HARP - InHARP Message HARP - InHARP Message
6.3.1 Example Message encodings: 6.3.1 Example Message encodings:
HARP_REQUEST message HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST) HARP ar$op = 1 (HARP_REQUEST)
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
HARP ar$rpa = IPy HARP ar$tpa = IPa HARP ar$rpa = IPy HARP ar$tpa = IPa
HARP ar$rha = SWy ULAy HARP ar$tha = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = 0 **
** is what we would like to find out ** is what we would like to find out
HARP_REPLY message format HARP_REPLY message format
HARP ar$op = 2 (HARP_REPLY) HARP ar$op = 2 (HARP_REPLY)
HARP ar$rpa = IPa HARP ar$tpa = IPy HARP ar$rpa = IPa HARP ar$tpa = IPy
HARP ar$rha = SWa ULAa * HARP ar$tha = SWy ULAy HARP ar$rha = SWa ULAa * HARP ar$tha = SWy ULAy
* answer we were looking for * answer we were looking for
skipping to change at page 25, line 5 skipping to change at page 25, line 5
Source Switch Address (HIPPI-LE) Source Switch Address (HIPPI-LE)
Source ULA (HIPPI-LE) Source ULA (HIPPI-LE)
Requester IP Address (HARP) Requester IP Address (HARP)
Requester ULA (HARP) Requester ULA (HARP)
Requester Switch Address (HARP) Requester Switch Address (HARP)
Target IP Address (HARP) Target IP Address (HARP)
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
Target ULA (HARP) Target ULA (HARP)
Target Switch Address (HARP) Target Switch Address (HARP)
Examples: Examples:
The following relations are true for a HARP_REQUEST and The following relations are true for a HARP_REQUEST and
InHARP_REQUESTs. InHARP_REQUESTs.
LIS without broadcast - Dest SW Addr = HARP server SW Addr LIS without broadcast - Dest SW Addr = HARP server SW Addr
skipping to change at page 25, line 43 skipping to change at page 25, line 43
(RIP, TCP, UDP, etc.) to access IP (RIP, TCP, UDP, etc.) to access IP
LIS broadcast. LIS broadcast.
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 7.1 Protocol for an IP Broadcast Emulation Server - PIBES
To emulate broadcast within an LIS, a PIBES SHALL use To emulate broadcast within an LIS, a PIBES SHALL use
the currently valid HARP table of the HARP server as a list of the currently valid HARP table of the HARP server as a list of
addresses called the target list. The broadcast server SHALL addresses called the target list. The broadcast server SHALL
validate that all incoming messages have a source address which validate that all incoming messages have a source address which
corresponds to an address in the target list. Only messages addressed to corresponds to an address in the target list. Only messages addressed to
the IP LIS broadcast address or FF.FF.FF.FF are considered valid the IP LIS broadcast addresses, multicast address or 255.255.255.255
messages for broadcasting. Invalid messages MUST be dropped. All are considered valid messages for broadcasting. Invalid messages MUST
valid incoming messages shall be forwarded to all addresses in the be dropped. All valid incoming messages shall be forwarded to all
target list. addresses in the target list.
It is RECOMMENDED that the broadcast server run on the same port as It is RECOMMENDED that the broadcast server run on the same port as
the HARP server since this memo does not define the protocol for the HARP server since this memo does not define the protocol for
exchanging the valid HARP table. exchanging the valid HARP table. The default address to use for
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00 INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
the broadcast address is the operational HARP server address.
7.2 IP Broadcast Address 7.2 IP Broadcast Address
This memo only defines IP broadcast. It is independent of the This memo only defines IP broadcast. It is independent of the
underlying hardware addressing and broadcast capabilities. Any port can underlying hardware addressing and broadcast capabilities. Any port can
differentiate between IP traffic directed to itself and a broadcast differentiate between IP traffic directed to itself and a broadcast
message sent to it by looking at the IP address. All IP broadcast message sent to it by looking at the IP address. All IP broadcast
messages SHALL use the IP LIS broadcast address. messages SHALL use the IP LIS broadcast address or.
It is RECOMMENDED that the PIBES run on the same port as the HARP It is RECOMMENDED that the PIBES run on the same port as the HARP
server. In that case, the PIBES SHALL use the same address as the HARP server. In that case, the PIBES SHALL use the same address as the HARP
server. server.
7.3 IP Multicast Address 7.3 IP Multicast Address
HIPPI does not directly support multicast address, therefore there are HIPPI does not directly support multicast address, therefore there are
no mappings available from IP multicast addresses to HIPPI multicast no mappings available from IP multicast addresses to HIPPI multicast
services. Current IP multicast implementations (i.e. MBONE and IP services. Current IP multicast implementations (i.e. MBONE and IP
tunneling, see [9]) will continue to operate over HIPPI-based logical tunneling, see [9]) will continue to operate over HIPPI-based logical
IP subnets if all IP multicast addresses are mapped to the IP LIS IP subnets if all IP multicast packets are sent using the same
broadcast address or FF.FF.FF.FF. algorithm as if the packet were being sent to 255.255.255.255.
7.4 A Note on Broadcast Emulation Performance 7.4 A Note on Broadcast Emulation Performance
It is obvious that a broadcast emulation service (as defined in It is obvious that a broadcast emulation service (as defined in
section 7.1) has an inherent performance limit. In an LIS section 7.1) has an inherent performance limit. In an LIS
with n ports, the upper bound on the bandwidth that such a service can with n ports, the upper bound on the bandwidth that such a service can
broadcast is: broadcast is:
(total bandwidth)/(n+1) (total bandwidth)/(n+1)
since each message must first enter the broadcast server, accounting since each message must first enter the broadcast server, accounting
skipping to change at page 26, line 52 skipping to change at page 27, line 5
This service is adequate for the standard networking protocols such as This service is adequate for the standard networking protocols such as
RIP, OSPF, NIS, etc. since they usually use a small fraction of RIP, OSPF, NIS, etc. since they usually use a small fraction of
the network bandwidth for broadcast. For these purposes, the the network bandwidth for broadcast. For these purposes, the
broadcast emulation server as defined in this memo allows the HIPPI broadcast emulation server as defined in this memo allows the HIPPI
network to look similar to an Ethernet network to the higher layers. network to look similar to an Ethernet network to the higher layers.
It is further obvious that such an emulation cannot be used to It is further obvious that such an emulation cannot be used to
broadcast high bandwidth traffic. For such a solution, hardware broadcast high bandwidth traffic. For such a solution, hardware
support for true broadcast is required. support for true broadcast is required.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
8 HARP for Scheduled Transfer [17] 8 HARP for Scheduled Transfer [17]
This RFC also applies for resolving addresses used with Scheduled This RFC also applies for resolving addresses used with Scheduled
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
Transfer (ST) over HIPPI-800 instead of IP. This RFC's message Transfer (ST) over HIPPI-800 instead of IP. This RFC's message
types and algorithms can be used for ST (since ST uses Internet types and algorithms can be used for ST (since ST uses Internet
Addresses) as long as there is also an IP over HIPPI implementation Addresses) as long as there is also an IP over HIPPI implementation
on all of the ports. on all of the ports.
9 Discovery of One's Own Switch Address 9 Discovery of One's Own Switch Address
This HARP specification assumes that each port has prior knowledge This HARP specification assumes that each port has prior knowledge
of its own hardware address. This address may be manually configured, of its own hardware address. This address may be manually configured,
by means outside the scope of this memo or a port may discover its own by means outside the scope of this memo or a port may discover its own
logical address through the algorithm described below. logical address through the algorithm described below.
Ports are NOT REQUIRED to implement this switch address discovery Ports are NOT REQUIRED to implement this switch address discovery protocol
protocol
but are encouraged to do so since it reduces the administrative overhead. but are encouraged to do so since it reduces the administrative overhead.
The algorithm presented in this section is based on John Renwick's work The algorithm presented in this section is based on John Renwick's work
as detailed in RFC-1374 [14]. The concept of the discovery process is as detailed in RFC-1374 [14]. The concept of the discovery process is
to scan all possible switch addresses. The messages that are received to scan all possible switch addresses. The messages that are received
will be the ones containing one of our switch addresses. will be the ones containing one of our switch addresses.
If a port implements this algorithm it SHALL form a HIPPI-LE message If a port implements this algorithm it SHALL form a HIPPI-LE message
as defined in HIPPI-LE: containing an Self_Address_Resolution_Request as defined in HIPPI-LE: containing an Self_Address_Resolution_Request
(see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address (see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address
(set to the correct ULA for the sender), and the Source_Switch_Address (set to the correct ULA for the sender), and the Source_Switch_Address
skipping to change at page 27, line 53 skipping to change at page 28, line 4
HIPPI-LE Source_Switch_Address = 0 (unknown) HIPPI-LE Source_Switch_Address = 0 (unknown)
HIPPI-LE Destination_IEEE_Address = 0 HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = my ULA HIPPI-LE Source_IEEE_Address = my ULA
There is no D2 data; the message contains only the HIPPI-FP header There is no D2 data; the message contains only the HIPPI-FP header
and D1_Area with the HIPPI-LE header. and D1_Area with the HIPPI-LE header.
Ports SHALL start the scan with a configurable logical address Ports SHALL start the scan with a configurable logical address
(default 0x000) and increment the value for by one for each (default 0x000) and increment the value for by one for each
subsequent try. The port SHALL continue until it sees its own self subsequent try. The port SHALL continue until it sees its own self
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
address resolution request or it has reached the end, which may be address resolution request or it has reached the end, which may be
another configurable value (default 0xFFF). It is RECOMMENDED that another configurable value (default 0xFFF). It is RECOMMENDED that
the range of addresses to scan be configurable since some networks the range of addresses to scan be configurable since some networks
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
have equipment that does not gracefully handle HIPPI-LE messages. have equipment that does not gracefully handle HIPPI-LE messages.
After a port sends the[se] request[s], two positive outcomes are After a port sends the[se] request[s], two positive outcomes are
possible: possible:
o the port receives its own request(s), and obtains one of its own o the port receives its own request(s), and obtains one of its own
Switch Address, or Switch Address, or
o the port receives an AR_S_Response with the o the port receives an AR_S_Response with the
Destination_Switch_Address filled in. Destination_Switch_Address filled in.
skipping to change at page 28, line 45 skipping to change at page 28, line 48
Synchronization and coordination of multiple HARP servers and Synchronization and coordination of multiple HARP servers and
multiple broadcast servers are left for further study. multiple broadcast servers are left for further study.
12 HARP Examples 12 HARP Examples
Assume a HIPPI-SC switch is installed with three connected ports: x, Assume a HIPPI-SC switch is installed with three connected ports: x,
y, and a. Each port has a unique hardware address that consists of y, and a. Each port has a unique hardware address that consists of
Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and
ULAa, respectively). There is a HARP server connected to a switch ULAa, respectively). There is a HARP server connected to a switch
port that is mapped to the address HWa (SWa, ULAa), this address is port that is mapped to the address HWa (SWa, ULAa), this address is
the selected HIPPI hardware address in the HRAL (HARP Request Address the authoritative HIPPI hardware address in the HRAL (HARP Request
List). Address List).
The HARP server's table is empty. Ports X and Y each know their own The HARP server's table is empty. Ports X and Y each know their own
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
hardware address. Eventually they want to talk to each other; each hardware address. Eventually they want to talk to each other; each
knows the other's IP address (from the port database) but neither knows the other's IP address (from the port database) but neither
knows the other's ULA or Switch Address. Both ports X and Y have knows the other's ULA or Switch Address. Both ports X and Y have
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
their interfaces configured DOWN. their interfaces configured DOWN.
NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd, NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd,
ar$pro, ar$pln fields are left out from the examples below ar$pro, ar$pln fields are left out from the examples below
since they are constant. Likewise, ar$rhl = ar$thl = 9 since they are constant. Likewise, ar$rhl = ar$thl = 9
are omitted since these are all HIPPI-800 examples. are omitted since these are all HIPPI-800 examples.
12.1 Registration Phase of Client Y on Non-broadcast Hardware 12.1 Registration Phase of Client Y on Non-broadcast Hardware
Port Y starts: its HARP table entry state for the server: PENDING Port Y starts: its HARP table entry state for the server: PENDING
skipping to change at page 29, line 52 skipping to change at page 30, line 4
HIPPI-LE Source_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAa
HARP ar$op = 9 (InHARP_REPLY) HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs * HARP ar$rpa = IPs *
HARP ar$tpa = IPy HARP ar$tpa = IPy
HARP ar$rha = SWa ULAa HARP ar$rha = SWa ULAa
HARP ar$tha = SWy ULAy HARP ar$tha = SWy ULAy
* answer we were looking for * answer we were looking for
3. Port Y examines the incoming InHARP_REPLY, completes its table 3. Port Y examines the incoming InHARP_REPLY, completes its table
entry for the HARP server. The client's HARP table entry for entry for the HARP server. The client's HARP table entry for
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
the server now passes into the VALID state and is usable for the server now passes into the VALID state and is usable for
regular HARP traffic. Receiving this reply ensures that the regular HARP traffic. Receiving this reply ensures that the
HARP server has properly registered the client. HARP server has properly registered the client.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
12.2 Registration Phase of Client Y on Broadcast Capable Hardware 12.2 Registration Phase of Client Y on Broadcast Capable Hardware
If there is a broadcast capable network then the selected address in If there is a broadcast capable network then the authoritative address in
the HRAL would be mapped to the broadcast address, HWb = SWb, ULAb the HRAL would be mapped to the broadcast address, HWb = SWb, ULAb
(likely 0xFE1 and FF:FF:FF:FF:FF:FF). (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
Port Y starts: its HARP table entry state for HWa: PENDING Port Y starts: its HARP table entry state for HWa: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to 1. Port Y initiates its interface and sends an InHARP_REQUEST to
HWa, in this example the broadcast address, after starting a table HWa, in this example the broadcast address, after starting a table
entry. entry.
HIPPI-LE Destination_Switch_Address = SWb HIPPI-LE Destination_Switch_Address = SWb
skipping to change at page 30, line 43 skipping to change at page 30, line 47
Y can deduce that it is connected to a broadcast medium. Port Y Y can deduce that it is connected to a broadcast medium. Port Y
completes its table entry for HWa. This entry will not timeout completes its table entry for HWa. This entry will not timeout
since it is considered unlikely for a particular underlying since it is considered unlikely for a particular underlying
hardware type to change between broadcast and non-broadcast; hardware type to change between broadcast and non-broadcast;
therefore this mapping will never change. therefore this mapping will never change.
12.3 Operational Phase (phase II) 12.3 Operational Phase (phase II)
The Operational Phase of the HARP protocol as specified in this memo The Operational Phase of the HARP protocol as specified in this memo
is the same for both broadcast and non-broadcast capable HIPPI is the same for both broadcast and non-broadcast capable HIPPI
hardware. The selected address in the HRAL for this example will be hardware. The authoritative address in the HRAL for this example will
HWa: <SWa, ULAa> and IPs for simplicity reasons. be HWa: <SWa, ULAa> and IPs for simplicity reasons.
12.3.1 Standard successful HARP_Resolve example 12.3.1 Standard successful HARP_Resolve example
Assume the same process (steps 1-3 of section 10.1) happened for port Assume the same process (steps 1-3 of section 10.1) happened for port
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
X. Then the state of X and Y's tables is: the HARP server table entry X. Then the state of X and Y's tables is: the HARP server table entry
is in the VALID state. So lets look at the message traffic when X is in the VALID state. So lets look at the message traffic when X
tries to send a message to Y. Since X doesn't have an entry for Y, 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 sends 1. Port X connects to the authoritative address of the HRAL and sends
a HARP_REQUEST for Y's hardware address: a HARP_REQUEST for Y's hardware address:
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST) HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx HARP ar$rpa = IPx
HARP ar$tpa = IPy HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx HARP ar$rha = SWx ULAx
HARP ar$tha = 0 ** HARP ar$tha = 0 **
** is what we would like to find out ** is what we would like to find out
skipping to change at page 31, line 48 skipping to change at page 32, line 4
HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Destination_IEEE_Address = ULAy
HIPPI-LE Source_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAx
If there had been a broadcast capable HIPPI network, the target ports If there had been a broadcast capable HIPPI network, the target ports
would themselves have received the HARP_REQUEST of step 2 above would themselves have received the HARP_REQUEST of step 2 above
and responded to them in the same way the HARP server did. and responded to them in the same way the HARP server did.
12.3.2 Standard non-successful HARP_Resolve example 12.3.2 Standard non-successful HARP_Resolve example
Like in 12.3.1, assume that X and Y are fully registered with the Like in 12.3.1, assume that X and Y are fully registered with the
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
HARP server. Then the state of X and Y's HARP server table entry HARP server. Then the state of X and Y's HARP server table entry
is: VALID. So lets look at the message traffic when X tries to send a is: VALID. So lets look at the message traffic when X tries to send a
message to Q. Further assume that interface Q is NOT configured UP, 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, 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 1. Port X connects to the HARP server switch address and sends
a HARP_REQUEST for Q's hardware address: a HARP_REQUEST for Q's hardware address:
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST) HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx HARP ar$rpa = IPx
HARP ar$tpa = IPq HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx HARP ar$rha = SWx ULAx
HARP ar$tha = 0 ** HARP ar$tha = 0 **
** is what we would like to find out ** is what we would like to find out
skipping to change at page 32, line 46 skipping to change at page 33, line 4
If there had been a broadcast capable HIPPI network, then there If there had been a broadcast capable HIPPI network, then there
would not have been a reply. would not have been a reply.
13 References 13 References
[1] ANSI X3.183-1991(R1996), Information Technology - [1] ANSI X3.183-1991(R1996), Information Technology -
High-Performance Parallel Interface - Mechanical, High-Performance Parallel Interface - Mechanical,
Electrical and Signaling Protocol Specification; (HIPPI-PH). Electrical and Signaling Protocol Specification; (HIPPI-PH).
[2] ANSI X3.210-1998, Information Technology - High-Performance [2] ANSI X3.210-1998, Information Technology - High-Performance
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
Parallel Interface - Framing Protocol; (HIPPI-FP). Parallel Interface - Framing Protocol; (HIPPI-FP).
[3] ANSI X3.218-1993, Information Technology - High-Performance [3] ANSI X3.218-1993, Information Technology - High-Performance
Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std
802.2) Logical Link Control Protocol Data Units; (HIPPI-LE). 802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
[4] ANSI X3.222-1997, Information Technology - High-Performance [4] ANSI X3.222-1997, Information Technology - High-Performance
Parallel Interface - Physical Switch Control; (HIPPI-SC). Parallel Interface - Physical Switch Control; (HIPPI-SC).
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
[5] ANSI X3.300-1997, Information Technology - High-Performance [5] ANSI X3.300-1997, Information Technology - High-Performance
Parallel Interface - Serial Specification; (HIPPI-Serial). Parallel Interface - Serial Specification; (HIPPI-Serial).
[6] Braden, R., "Requirements for Internet Hosts -- Communication [6] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC-1122, USC/Information Sciences Institute, October Layers", RFC-1122, USC/Information Sciences Institute, October
1989. 1989.
[7] Bradely, T., and Brown, C., "Inverse Address Resolution [7] Bradely, T., and Brown, C., "Inverse Address Resolution
Protocol", RFC-1293, USC/Information Sciences Institute, January Protocol", RFC-2390, September 1998.
1992.
[8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol [8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp.
32-48, 1989. 32-48, 1989.
[9] Deering, S, "Host Extensions for IP Multicasting", RFC-1112, [9] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
USC/Information Sciences Institute, August 1989. USC/Information Sciences Institute, August 1989.
[10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse [10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse
Address Resolution Protocol", RFC-903, Stanford University, June Address Resolution Protocol", RFC-903, Stanford University, June
1984. 1984.
[11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local [11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local
Area Networks - Logical Link Control, "IEEE Standards for Local Area Networks - Logical Link Control, "IEEE Standards for Local
Area Networks: Logical Link Control", IEEE, New York, New York, Area Networks: Logical Link Control", IEEE, New York, New York,
1985. 1985.
[12] Laubach, Mark., "Classical IP and ARP over ATM", RFC-1577, [12] Laubach, Mark., "Classical IP and ARP over ATM", RFC-2225,
Hewlett-Packard Laboratories, January 1994. Com21, Inc., April 1998.
[13] Plummer, D., "An Ethernet Address Resolution Protocol - or - [13] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC-826, MIT, November 1982. Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
[14] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374, [14] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC-1374,
Cray Research, Inc., October 1992. Cray Research, Inc., October 1992.
[15] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January [15] Renwick, J., "IP over HIPPI", RFC-2067, NetStar, Inc., January
1997. 1997.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 7/00
[16] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, [16] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC-1700, USC/Information Sciences Institute, October 1994. RFC-1700, USC/Information Sciences Institute, October 1994.
[17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol [17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol
ANSI NCITS, Scheduled Transfer Protocol draft standard. ANSI NCITS, Scheduled Transfer Protocol draft standard.
INTERNET DRAFT ARP and IP Broadcast over HIPPI-800 Expires 4/00
14 Acknowledgments 14 Acknowledgments
This memo could not have come into being without the critical review This memo could not have come into being without the critical review
from Greg Chesson, Carlin Otto, the high performance interconnect from Greg Chesson, Carlin Otto, the high performance interconnect
group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand
and Jeff Young) and the expertise of the ANSI T11.1 Task Group and Jeff Young) and the expertise of the ANSI T11.1 Task Group
responsible for the HIPPI standards work. responsible for the HIPPI standards work.
This memo is based on the second part of [14], written by John This memo is based on the second part of [14], written by John
Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written
by T. Bradley and C. Brown provide the fundamental algorithms of HARP by T. Bradley and C. Brown provide the fundamental algorithms of HARP
as presented in this memo. Further, the HARP server is based on as presented in this memo. Further, the HARP server is based on
concepts and models presented in [12], written by Mark Laubach who concepts and models presented in [12], written by Mark Laubach who
laid the structural groundwork for the HARP server. laid the structural groundwork for the HARP server.
15 Author's Address 15 Author's Address
Jean-Michel Pittet Jean-Michel Pittet
Silicon Graphics Inc Silicon Graphics Inc
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94040 Mountain View, CA 94043
Phone: 650-933-6149 Phone: 650-933-6149
Fax: 650-933-3542 Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org EMail: jmp@sgi.com, jmp@acm.org
--
-----8<-----
Jean-Michel Pittet jmp@sgi.com Phone:650-933-6149 Fax:933-3542
SGI, 1600 Amphitheatre Parkway, MS 802, Mountain View, CA, 94043 USA
 End of changes. 85 change blocks. 
121 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/