7.1 Protocol for an IP Broadcast Emulation Server - PIBES
To emulate broadcast within an LIS, a PIBES SHALL use the currently
valid HARP table of the HARP server as a list of addresses called the
target list. The broadcast server SHALL validate that all incoming
messages have a source address which corresponds to an address in the
target list. Only messages addressed to the IP LIS broadcast
addresses, multicast address or 255.255.255.255 are considered valid
messages for broadcasting. Invalid messages MUST be dropped. All
valid incoming messages shall be forwarded to all addresses in the
target list.
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
exchanging the valid HARP table. The default address to use for the
broadcast address is the operational HARP server address.
7.2 IP Broadcast Address
This memo only defines IP broadcast. It is independent of the
underlying hardware addressing and broadcast capabilities. Any port
can differentiate between IP traffic directed to itself and a
broadcast message sent to it by looking at the IP address. All IP
broadcast messages SHALL use the IP LIS broadcast address.
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.
7.3 IP Multicast Address
HIPPI-6400 does not directly support multicast address, therefore
there are no mappings available from IP multicast addresses to HIPPI
multicast services. Current IP multicast implementations (i.e. MBONE
and IP tunneling, see [7]) will continue to operate over HIPPI-based
logical IP subnets if all IP multicast packets are sent using the
same algorithm as if the packet were being sent to 255.255.255.255.
7.4 A Note on Broadcast Emulation Performance
It is obvious that a broadcast emulation service (as defined in
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
broadcast is:
(total bandwidth)/(n+1)
since each message must first enter the broadcast server, accounting
for the additional 1, and then be sent to all n ports. The broadcast
server could forward the message destined to the port on which it
runs internally, thus reducing (n+1) to (n) in a first optimization.
This service is adequate for the standard networking protocols such
as RIP, OSPF, NIS, etc. since they usually use a small fraction of
the network bandwidth for broadcast. For these purposes, the
broadcast emulation server as defined in this memo allows the HIPPI-
6400 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
This RFCalso applies for resolving addresses used with Scheduled
Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message types
and algorithms can be used for ST (since ST uses Internet Addresses)
as long as there is also an IP over HIPPI-6400 implementation on all
the ports.
9 Security Consierations
There are known security issues relating to port impersonation via
the address resolution protocols used in the Internet [6]. 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-6400 are
clearly understood at this time, due to the fluid state of HIPPI-6400
specifications, newness of the technology, and other factors.
However, given the security hole ARP allows, other concerns are
probably minor.
10 Open Issues
Synchronization and coordination of multiple HARP servers and
multiple broadcast servers are left for further study.
11 HARP Examples
Assume a HIPPI-6400-SC switch is installed with three connected
ports: x, y, and a. Each port has a unique hardware address that
consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a
HARP server connected to a switch port that is mapped to the address
HWa, 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. Both ports X and Y have their interfaces
configured DOWN.
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are
left out from the examples below since they are constant. As well as
ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.
11.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 the
HWa after starting a table entry for the HWa.
HIPPI-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = 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-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs *
HARP ar$tpa = IPy
HARP ar$rha = ULAa
HARP ar$tha = ULAy
* answer we were looking for
3. Port Y examines the incoming InHARP_REPLY and 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.
11.2 Registration Phase of Client Y on Broadcast Capable Hardware
If port Y is connected to a broadcast-capable network then the
authoritative address is the broadcast address, HWb = SWb, ULAb
(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-6400-PH D_ULA = ULAb
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = 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.
11.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-6400
hardware. The authoritative address in the HRAL for this example will
be HWa: <SWa, ULAa> and IPs for simplicity reasons.
11.3.1 Successful HARP_Resolve example
Assume the same process (steps 1-3 of section 11.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-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = 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-6400-PH D_ULA = ULAx
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 2 (HARP_Reply)
HARP ar$rpa = IPy
HARP ar$tpa = IPx
HARP ar$rha = ULAy *
HARP ar$tha = 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-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAx
<data>
If the network had been broadcast-capable, 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.
11.3.2 Non-successful HARP_Resolve example
As in 11.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-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = 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-6400-PH D_ULA = ULAx
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 10 (HARP_NAK)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = 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 the network had been broadcast-capable, then there would not have
been a reply.
12 References
[1] ANSI NCITS 323-1998, Information Technology - High-Performance
Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[2] ANSI NCITS 324-199x, Information Technology - High-Performance
Parallel Interface - 6400 Mbit/s Physical Switch Control
(HIPPI-6400-SC).
[3] ANSI NCITS Project Number 1249-D, Information Technology -
High-Performance Parallel Interface - 6400 Mbit/s Optical
Specification (HIPPI-6400-OPT).
[4] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[5] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
RFC2390, September 1998.
[6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
pp. 32-48, 1989.
[7] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects
1996, Stanford University.
[10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems -
Local Area Networks - Logical Link Control IEEE, IEEE, New York,
New York, 1989.
[11] Laubach, M., "Classical IP and ARP over ATM", RFC2225, April
1998.
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC1191,
November, 1990.
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC2834,
May 2000.
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
[15] Postel, J., "Internet Protocol", STD 5, RFC791, September 1981.
[16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC1374,
October 1992.
[17] Renwick, J., "IP over HIPPI", RFC2067, January 1997.
[18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
13 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 [17], written by John
Renwick. ARP [14] written by Dave Plummer and Inverse ARP [7] written
by Terry Bradley and Caralyn Brown provide the fundamental algorithms
of HARP as presented in this memo. Further, the HARP server is based
on concepts and models presented in [13], written by Mark Laubach who
laid the structural groundwork for the HARP server.
14 Author's Address
Jean-Michel Pittet
Silicon Graphics Inc
1600 Amphitheatre Parkway
Mountain View, CA 94040
Phone: 650-933-6149
Fax: 650-933-3542
EMail: jmp@sgi.com, jmp@acm.org
15 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.