the network bandwidth for broadcast. For these 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 is required.
8 HARP for Scheduled Transfer Protocol[17]
This RFCalso applies for resolving addresses used with Scheduled
Transfer (STP) over HIPPI-800 instead of IP. This RFC's message
types and algorithms can be used for STP (since STP uses Internet
Addresses) as long as there is also an IP over HIPPI implementation
on all of the ports.
9 Discovery of One's Own Switch Address
This HARP specification assumes that each port has prior knowledge 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 logical address through the algorithm described below.
Ports are NOT REQUIRED to implement this switch address discovery
protocol 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 as detailed in RFC-1374 [14]. The
concept of the discovery process is to scan all possible switch
addresses. The messages that are received will be the ones containing
one of our switch addresses.
If a port implements this algorithm it SHALL form a HIPPI-LE message
as defined in HIPPI-LE: containing an Self_Address_Resolution_Request
(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 and Destination_Switch_Address.
This self address resolution message uses the same HIPPI-LE message
format as described in HIPPI-SC and HIPPI-LE: the Self Address
Resolution Request PDU and Self Address Resolution Response PDU type
codes and no piggybacked ULP data. The HIPPI-LE header contents for
the request are:
HIPPI-LE Message_Type is = 3, Self Addr. Resolution Request
HIPPI-LE Destination_Address_Type = 0 (undefined)
HIPPI-LE Destination_Switch_Address = X (X element scan range)
HIPPI-LE Source_Address_Type = 0 (undefined)
HIPPI-LE Source_Switch_Address = 0 (unknown)
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = my ULA
There is no D2 data; the message contains only the HIPPI-FP header
and D1_Area with the HIPPI-LE header.
Ports SHALL start the scan with a configurable logical address
(default 0x000) and increment the value for by one for each
subsequent try. The port SHALL continue until it sees its own self
address resolution request or it has reached the end, which may be
another configurable value (default 0xFFF). It is RECOMMENDED that
the range of addresses to scan be configurable since some networks
have equipment that does not gracefully handle HIPPI-LE messages.
After a port sends the[se] request[s], two positive outcomes are
possible:
o the port receives its own request(s), and obtains one of its own
Switch Address, or
o the port receives an AR_S_Response with the
Destination_Switch_Address filled in.
10 Security Considerations
HARP messages are not authenticated which is a potentially flaw that
could allow corrupt information to be introduced into the server
system.
There are other known security issues relating to port impersonation
via 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 HARP.
Not all of the security issues relating to ARP over HIPPI are clearly
understood at this time. However, given the security hole ARP allows,
other concerns are probably minor.
11 Open Issues
Synchronization and coordination of multiple HARP servers and
multiple broadcast servers are left for further study.
12 HARP Examples
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
Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and
ULAa, respectively). There is a HARP server connected to a switch
port that is mapped to the address HWa (SWa, ULAa), this address is
the authoritative HIPPI hardware address in the HRAL (HARP Request
Address List).
The HARP server's table is empty. Ports 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 port database) but neither
knows the other's ULA or Switch Address. Both ports 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. Likewise, ar$rhl = ar$thl = 9 are omitted since these
are all HIPPI-800 examples.
12.1 Registration Phase of Client Y on Non-broadcast Hardware
Port Y starts: its HARP table entry state for the server: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa
after starting a table entry for HWa.
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy
HARP ar$tha = SWa ULAa
** is what we would like to find out
2. HARP server receives Y's InHARP_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
InHARP_REQUEST. The HARP server will then send a InHARP_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 = ULAa
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs *
HARP ar$tpa = IPy
HARP ar$rha = SWa ULAa
HARP ar$tha = SWy ULAy
* answer we were looking for
3. Port Y examines the incoming InHARP_REPLY, completes its table
entry for the HARP server. The client's HARP table entry for the
server now passes into the VALID state and is usable for regular
HARP traffic. Receiving this reply ensures that the HARP 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 authoritative
address in the HRAL would be mapped to the broadcast address, HWb =
SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
Port Y starts: its HARP table entry state for HWa: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa,
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
HIPPI-LE Source_IEEE_Address = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy
HARP ar$tha = SWb ULAb
** is what we would like to find out
2. Since the network is a broadcast network, client Y will receive a
copy of its InHARP_REQUEST. Client Y examines the source
addresses. Since they are the same as what Y filled in the
InHARP_REQUEST, Y can deduce that it is connected to a broadcast
medium. Port Y completes its table entry for HWa. This entry will
not timeout since it is considered unlikely for a particular
underlying hardware type to change between broadcast and non-
broadcast; therefore this mapping will never change.
12.3 Operational Phase (phase II)
The Operational Phase of the HARP protocol as specified in this memo
is the same for both broadcast and non-broadcast capable HIPPI
hardware. The authoritative address in the HRAL for this example will
be HWa: <SWa, ULAa> and IPs for simplicity reasons.
12.3.1 Standard successful HARP_Resolve example
Assume the same process (steps 1-3 of section 10.1) happened for port
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
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
a HARP_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
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** is what we would like to find out
2. The HARP server receives the HARP request and updates its entry
for X if necessary. It then generates a HARP_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
HARP ar$op = 2 (HARP_Reply)
HARP ar$rpa = IPy
HARP ar$tpa = IPx
HARP ar$rha = SWy ULAy *
HARP ar$tha = SWx ULAx
* answer we were looking for
3. Port X connects to port Y and transmits an IP message 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 ports
would themselves have received the HARP_REQUEST of step 2 above and
responded to them in the same way the HARP server did.
12.3.2 Standard non-successful HARP_Resolve example
Like in 12.3.1, assume that X and Y are fully registered with the
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
message to Q. Further assume that interface Q is NOT configured UP,
i.e. it is DOWN. Since X doesn't have an entry for Q,
1. Port X connects to the HARP server switch address and sends a
HARP_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
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** is what we would like to find out
2. The HARP server receives the HARP request and updates its entry
for X if necessary. It then looks up IPq in its tables and doesn't
find it. The HARP server then generates a HARP_NAK reply message.
HIPPI-LE Destination_Switch_Address = SWx
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAx
HIPPI-LE Source_IEEE_Address = ULAa
HARP ar$op = 10 (HARP_NAK)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 ***
*** No Answer, and notice that the fields do not get swapped,
i.e. the HARP message is the same as the HARP_REQUEST
except for the operation code.
If there had been a broadcast capable HIPPI network, then there would
not have been a reply.
13 References
[1] ANSI X3.183-1991(R1996), Information Technology - High-
Performance Parallel Interface - Mechanical, Electrical and
Signaling Protocol Specification; (HIPPI-PH).
[2] ANSI X3.210-1998, Information Technology - High-Performance
Parallel Interface - Framing Protocol; (HIPPI-FP).
[3] ANSI X3.218-1993, Information Technology - High-Performance
Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std
802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
[4] ANSI X3.222-1997, Information Technology - High-Performance
Parallel Interface - Physical Switch Control; (HIPPI-SC).
[5] ANSI X3.300-1997, Information Technology - High-Performance
Parallel Interface - Serial Specification; (HIPPI-Serial).
[6] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[7] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
RFC2390, September 1998.
[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", STD 5, RFC
1112, August 1989.
[10] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "A Reverse
Address Resolution Protocol", RFC903, June 1984.
[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, New York, New
York, 1985.
[12] Laubach, Mark., "Classical IP and ARP over ATM", RFC2225, April
1998.
[13] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC826, November 1982.
[14] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC1374,
October 1992.
[15] Renwick, J., "IP over HIPPI", RFC2067, January 1997.
[16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol
ANSI NCITS, Scheduled Transfer Protocol draft standard.
[18] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
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 (specifically Jim Pinkerton, Brad Strand
and Jeff Young) 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 [14], written by John
Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written
by T. Bradley and C. Brown provide the fundamental algorithms of HARP
as presented in this memo. Further, the HARP server is based on
concepts and models presented in [12], written by Mark Laubach who
laid the structural groundwork for the HARP server.
15 Changes from RFC-1374 [14]
RFC-2067 obsoletes RFC-1374 but left ARP outside 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 [14] are:
o A new message format to acknowledge the HIPPI hardware address
format and to eliminate the requirement of HIPPI-LE ARP for HARP
to function.
o Explicit registration phase.
o Additional message formats: InHARP requests and replies as well as
HARP_NAKs.
o Details about the IP subnetwork configuration.
o Details about table aging.
o IP broadcast emulation.
16 Author's Address
Jean-Michel Pittet
Silicon Graphics Inc
1600 Amphitheatre Parkway
Mountain View, CA 94043
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org
17 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.