own switch address from the destination address field of the received
I-field.
HIPPI-LE self address resolution uses the same HIPPI-LE message
format described in "ARP and RARP Message Format," above, with the
AR_S_Request and AR_S_Response message type codes and no piggybacked
ULP data. The HIPPI-LE header contents for the request are:
Message_Type is 3, AR_S_Request
Destination_Address_Type = 0 (undefined)
Destination_Switch_Address = 0 (unknown)
Source_Address_Type = 0 (undefined)
Source_Switch_Address = 0 (unknown)
Destination_IEEE_Address = my ULA
Source_IEEE_Address = my ULA
There is no D2 data; the packet contains only the HIPPI-FP header and
D1_Area containing the HIPPI-LE header.
The node that wants to discover its address connects to the multicast
address for this purpose (hex FE0 in HIPPI-SC) and transmits the
request packet. What happens next depends on the particular network:
With multicast:
The node receives its own request and can learn its own switch
address from the I-field it receives. This is the only time a
node should use an address from a received I-field.
With an ARP agent:
The node may receive an AR_S_Response message with its own ULA in
the Destination_IEEE_Address field and its own switch address in
the Destination_Switch_Address field. This address may be
different from the address contained in the I-field, and should be
used instead.
The ARP agent response alternative requires that the agent have prior
knowledge of the node's location and ULA through some process not
specified by this memo. The node may receive both its request and
the agent's response if both an ARP agent and multicast are active.
In this case the address it learns from the I-field is later replaced
by the address given by the ARP agent in the response. Agents may
assign new addresses to nodes and inform them by sending unsolicited
AR_S_Response messages. Any node whose switch address is updated in
this way should invalidate the switch addresses it has saved for
other nodes, and use ARP to rediscover them.
If the node reacts correctly to either the multicast request or
agent-generated response, it can discover its address without having
to know whether or not an ARP agent is active. The full procedure
is:
1. Transmit the AR_S_Request
2. When a connection arrives, accept it and save the I-field for
later analysis.
3. Receive the message and look at the HIPPI-LE header. If the
message is Message Type AR_S_Request, analyze the I-field to
discover the node's own switch address. HIPPI-SC I-field formats
suggest the following:
if bit 25 == 1
Address type is HIPPI-SC logical address.
if bit 27 == 1
take address from bits 23-12
else
take address from bits 11-00
endif
else
Address is unusable (source route)
endif
This is a one-time operation. Once the node knows an address for
itself, it should not take any new address from a received I-
field.
4. If a message of type AR_S_Response arrives and the
Destination_IEEE_Address field contains the node's own ULA, take
the new switch address from the Destination_Switch_Address field
and its type from the Destination_Address_Type field.
5. The node should invalidate its ARP tables when an AR_S_Response
changes its own switch address, to force retransmission of ARP
requests containing its new address to all the remote nodes with
which it communicates.
Path MTU Discovery
RFC1191 [13] describes the method of determining MTU restrictions on
an arbitrary network path between two hosts. HIPPI nodes may use
this method without modification to discover restrictions on paths
between HIPPI-SC LANs and other networks. Gateways between HIPPI-SC
LANs and other types of networks should implement RFC1191.
Channel Data Rate Discovery
HIPPI exists in two data rate options (800 megabit/second and 1600
megabit/second). The higher data rate is achieved by making the
HIPPI 64 bits parallel instead of 32, using an extra cable containing
32 additional data bits and four parity bits. HIPPI-SC switches can
be designed to attach to both. Source and Destination HIPPI
implementations can be designed to operate at either rate, selectable
at the time a connection is established. The "W" bit (bit 28) of the
I-field controls the width of the connection through the switch.
Sources with both cables A and B attached to the switch may set the
"W" bit to request a 1600 megabit/second connection. If the
requested destination also has both cables attached, the switch can
connect Source to Destination on both cables. If the requested
Destination has only Cable A, the switch rejects the request.
Sixty-four bit Sources can connect to 32 bit Destinations by
requesting with the "W" bit clear and not using Cable B. Sixty-four
bit Destinations must examine the "W" bit in the received I-field and
use or ignore Cable B accordingly. Note that both INTERCONNECT
signals stay active while a 64 bit HIPPI is used in 32 bit mode.
The following table summarizes the possible combinations, the
switch's action for each, and the width of the resulting connection.
Destination
+-------------------+-------------------+
| 32 | 64 |
+----+-----+-------------------+-------------------+
| | W=0 | Accept 32 | Accept 32 |
| 32 +-----+-------------------+-------------------+
| | W=1 | N/A | N/A |
Source +----+-----+-------------------+-------------------+
| | W=0 | Accept 32 | Accept 32 |
| 64 +-----+-------------------+-------------------+
| | W=1 | Reject | Accept 64 |
+----+-----+-------------------+-------------------+
HIPPI Connection Combinations
If the path between a 64 bit Source and a 64 bit Destination includes
more than one switch, and the route between switches uses a link that
is only 32 bits wide, the switch rejects 64 bit connection requests
as if the Destination did not have 64 bit capability.
In a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to
know the data rates available at each Destination and on the path to
it. This can be known a priori by manual configuration, or it can be
discovered dynamically. The only reliable method of discovery is
simply to attempt a 64 bit connection with Camp-on. As long as 64
bit connections succeed, the Source knows the Destination and path
are double width. If a 64 bit connection is rejected, the Source
tries to connect for 32 bits. If the 32 bit connection succeeds, the
Source assumes that the Destination or path is not capable of double
width operation, and uses only 32 bit requests after that. If the 32
bit request is rejected, the Source assumes that the Destination or
path is down and makes no determination of its capability.
The Double_Wide bit in the HIPPI-LE header, if nonzero, gives the
node that receives it a hint that the 64 bit connection attempt may
be worthwhile when sending on the return path.
Note that Camp-on must be used at least in the 64 bit attempt,
because it removes some ambiguity from the meaning of rejects. If
the request is made with the "W" bit and no Camp-on, a reject could
mean either that the Destination has no Cable B or that it is simply
busy, and no conclusion can be drawn as to its status for 64 bit
connections.
Performance
The HIPPI connection rules are designed to permit best utilization of
the available HIPPI throughput under the constraint that each
Destination must be made available frequently to receive packets from
different Sources. This discipline asks both Sources and
Destinations to minimize connection setup overhead to deliver high
performance. Low connection setup times are easily achieved by
hardware implementations, but overhead may be too high if software is
required to execute between the initial request of a connection and
the beginning of data transfer. Hardware implementations in which
connection setup and data transfer proceed from a single software
action are very desirable.
HIPPI connections are controlled by HIPPI Sources; a Destination,
being unable to initiate a disconnect without the possibility of data
loss, is a slave to the Source once it has accepted a connection.
Optimizations of connection strategy are therefore the province of
the HIPPI Source, and several optimizations are permitted.
If the rate of available message traffic is less than the available
HIPPI throughput and Destinations are seldom busy when a connection
is requested, connection optimizations do not pay off and the
simplest strategy of waiting indefinitely for each connection to be
made and sending messages strictly in the order queued cannot be
improved upon. However if some nodes are slow, or network
applications can send or receive messages at a higher aggregate rate
than the available HIPPI bandwidth, Sources may frequently encounter
a busy Destination. In these cases, certain host output queuing
strategies may enhance channel utilization. Sources may maintain
separate output queues for different HIPPI Destinations, and abandon
one Destination in favor of another if a connection attempt without
Camp-on is rejected or a connection request with Camp-on is not
accepted within a predetermined interval. Such a strategy results in
aborted connection sequences (defined in HIPPI-PH: REQUEST is
deasserted before any data is sent). Destinations must treat these
as normal events, perhaps counting them but otherwise ignoring them.
Two components of connection setup time are out of the control of
both Source and Destination. One is the time required for the switch
to connect Source to Destination, currently less than four
microseconds in the largest commercially available (32 port) switch.
The second component is the round trip propagation time of the
REQUEST and CONNECT signals, negligible on a standard 25 meter copper
HIPPI cable, but contributing a total of about 10 microseconds per
kilometer on fiber optic links. HIPPI-SC LANs spanning more than a
few kilometers will have reduced throughput. Limited span networks
with buffered gateways or bridges between them may perform better
than long serial HIPPI links.
A Source is required to drop its connection after the transmission of
68 HIPPI bursts. This number was chosen to allow the transmission of
one maximum sized packet or a reasonable number of smaller sized
packets. The following table lists some possibilities, with
calculated maximum burst and throughput rates in millions (10**6) of
bytes per second:
Maximum HIPPI Throughput Rates
Number Number Hold Burst ------Max throughput MB/sec-------
User of of Time Rate Connection Setup Overhead (usec)
Data Packets Bursts (usec) MB/sec 10 30 60 90 120 150
---- ------- ------ ------ ------ ---- ---- ---- ---- ---- ----
63K 1 64 654 98.7 97.2 94.4 90.4 86.8 83.4 80.3
32K 2 66 665 98.6 97.1 94.3 90.4 86.8 83.5 80.4
16K 4 68 667 98.3 96.8 94.1 90.2 86.6 83.3 80.2
8K 7 63 587 97.8 96.1 93.0 88.7 84.8 81.2 77.8
4K 13 65 551 96.7 95.0 91.7 87.2 83.1 79.4 76.0
2K 22 66 476 94.6 92.7 89.0 84.0 79.6 75.6 72.0
1K 34 68 384 90.8 88.5 84.2 78.5 73.5 75.8 65.3
These calculations are based 259 40 ns clock periods to transmit a
full burst and 23 clock periods for a short burst. (HIPPI-PH
specifies three clock periods of overhead per burst.) A packet of "n"
kilobytes of user data consists of "n" full bursts and one short
burst equal in length to the number of bytes in the HIPPI, LLC, IP
and TCP headers. "Hold Time" is the minimum connection duration
needed to send the packets. "Burst Rate" is the effective transfer
rate for the duration of the connection, not counting connection
switching time. Throughput rates are in megabytes/second, accounting
for connection switching times of 10, 30, 60, 90, 120 and 150
microseconds. These calculations ignore any limit on the rate at
which a Source or Destination can process small packets; such limits
may further reduce the available throughput if small packets are
used.
Sharing the Switch
Network interconnection is only one potential application of HIPPI
and HIPPI-SC switches. While network applications need very frequent
transient connections, other applications may favor longer term or
even permanent connections between Source and Destination. Since the
switch can serve each Source or Destination with hardware paths
totally separate from every other, it is quite feasible to use the
same switch to support LAN interconnects and computer/peripheral
applications simultaneously.
Switch sharing is no problem when unlike applications do not share a
HIPPI cable on any path. However if a host must use a single input
or output cable for network as well as other kinds of traffic, or if
a link between switches must be shared, care must be taken to ensure
that all applications are compatible with the connection discipline
described in this memo. Applications that hold connections too long
on links shared with network traffic may cause loss of network
packets or serious degradation of network service.
Appendix A -- HIPPI Basics
This section is included as an aid to readers who are not completely
familiar with the HIPPI standards.
HIPPI-PH describes a parallel copper data channel between a Source
and a Destination. HIPPI transmits data in one direction only, so
that two sets are required for bidirectional flow. The following
figure shows a simple point-to-point link between two computer
systems:
+----------+ +----------+
| | | |
| +--------+ +--------+ |
| | HIPPI | Cable | HIPPI | |
| | +--------------------->| | |
| | Source | | Dest. | |
| System +--------+ +--------+ System |
| X +--------+ +--------+ Y |
| | HIPPI | Cable | HIPPI | |
| | |<---------------------+ | |
| | Dest. | | Source | |
| +--------+ +--------+ |
| | | |
+----------+ +----------+
A Simple HIPPI Duplex Link
Parallel copper cables may be up to 25 meters in length.
In this document, all HIPPI connections are assumed to be paired
HIPPI channels.
HIPPI-PH has a single optional feature: it can use a single cable in
each direction for a 32 bit parallel channel with a maximum data rate
of 800 megabit/second, or two cables for 64 bits and 1600
megabit/second. Cable A carries bits 0-31 and is used in both modes;
Cable B carries bits 32-63 and is use only with the 1600
megabit/second data rate option.
HIPPI Signal Hierarchy
HIPPI has the following hardware signals:
Source to Destination
INTERCONNECT A
INTERCONNECT B (64 bit only)
CLOCK (25 MHz)
REQUEST
PACKET
BURST
DATA (32 or 64 signals)
PARITY (4 or 8 signals)
Destination to Source
INTERCONNECT A
INTERCONNECT B (64 bit only)
CONNECT
READY
The INTERCONNECT lines carry DC voltages that indicate that the
cable is connected and that the remote interface has power.
INTERCONNECT is not used for signaling.
The CLOCK signal is a continuous 25 MHz (40 ns period) square
wave. All Source-to-Destination signals are synchronized to the
clock.
The REQUEST and CONNECT lines are used to establish logical
connections. A connection is always initiated by a Source as it
asserts REQUEST. At the same time it puts 32 bits of data on DATA
lines 0-31, called the I-field. The Destination samples the DATA
lines and can complete a connection by asserting CONNECT. Packets
can be transmitted only while both REQUEST and CONNECT are
asserted.
A Destination can also reject a connection by asserting CONNECT
for only a short interval between 4 and 16 HIPPI clock periods
(160-640 nanoseconds). The Source knows a connection has been
accepted when CONNECT is asserted for more than 16 clocks or it
receives a READY pulse.
Either Source or Destination can terminate a connection by
deasserting REQUEST or CONNECT, respectively. Normally
connections are terminated by the Source after its last Packet has
been sent. A Destination cannot terminate a connection without
potential loss of data.
+------+-------------------------+------+
| Idle | Connected | Idle | . . .
+------+-------------------------+------+
/ \
/ \
/ \
/ \
/ \
+-------+ +-------+ +-------+ +-------+
|I-field| |Packet | |Packet | |Packet |
+-------+ +-------+ +-------+ +-------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+-----+ +-----+ +-----+
|Burst| |Burst|...|Burst|
+-----+ +-----+ +-----+
HIPPI Logical Framing Hierarchy
The Source asserts PACKET for the duration of a Packet
transmission, deasserting it to indicate the end of a Packet. A
sequence of Bursts comprise a Packet. To send a burst, a Source
asserts the BURST signal for 256 clock periods, during which it
places 256 words of data on the DATA lines. The first or last
Burst of a Packet may be less than 256 clock periods, allowing the
transmission of any integral number of 32 or 64 bit words in a
Packet.
The READY signal is a pulse four or more clock periods long. Each
pulse signals the Source that the Destination can receive one
Burst. The Destination need not wait for a burst before sending
another READY if it has burst buffers available; up to 63
unanswered READYs may be sent, allowing HIPPI to operate at full
speed over distances of many kilometers. If a Source must wait
for flow control, it inserts idle periods between Bursts.
+------------------------------------------------+
REQUEST---+ +----
+--------------------------------------------+
CONNECT---------+ +--
+---------------------------------------+
PACKET-------------+ +----
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--
+-------+ +-------+ +-------+ +-----+
BURST--------------+ +-+ +-+ +-+ +--------
DATA------I-field----DATA------DATA------DATA-----DATA----------
HIPPI Signal Timing Diagram
Serial HIPPI
There is no ANSI standard for HIPPI other than the parallel copper
cable version. However an implementors' agreement exists,
specifying a serial protocol to extend HIPPI signals on optical
fiber or coaxial copper cable. Serial links may be used
interchangeably with parallel links to overcome HIPPI distance
limitations; they are transparent to the Source and Destination,
except for the possibility of longer propagation delays.
I-Field and Switch Control
The REQUEST, CONNECT and I-field features of HIPPI-PH were
designed for the control of switches as described in HIPPI-SC. A
switch is a hub with a number of input and output HIPPI ports.
HIPPI Sources are cabled to switch input ports, and switch output
ports are cabled to HIPPI Destinations. When a HIPPI Source
requests a connection, the switch interprets the I-field to select
an output port and electrically connects the HIPPI Source to the
HIPPI Destination on that port. Once connected, the switch does
not interact with the HIPPIs in any way until REQUEST or CONNECT
is deasserted, at which time it breaks the physical connection and
deasserts its output signals to both sides. Some existing switch
implementations can switch connections in less than one
microsecond. There is the potential for as many simultaneous
connections, each transferring data at HIPPI speeds, as there are
input or output ports on the switch. A switch offers much greater
total throughput capacity than broadcast or ring media.
31 28 26 23 11 0
+-+---+-+-+---+-+-----------------------+-----------------------+
|L| |W|D|PS |C| Source Address | Destination Address |
+-+---+-+-+---+-+-----------------------+-----------------------+
HIPPI-SC I-field Format (Logical Address Mode)
L = Locally defined (1 => entire I-field is locally defined)
W = Width (1 => 64 bit connection)
D = Direction (1 => swap Source and Destination Address)
PS = Path Selection (01 => Logical Address Mode)
C = Camp-on (1 => wait until Destination is free)
HIPPI-SC defines I-field formats for two different addressing
modes. The first, called Source Routing, encodes a string of port
numbers in the lower 24 bits. This string specifies a route over
a number of switches. A Destination's address may differ from one
Source to another if multiple switches are used.
The second format, called Logical Address Mode, defines two 12 bit
fields, Source Address and Destination Address. A Destination's
12 bit Switch Address is the same for all Sources. Switches
commonly have address lookup tables to map 12 bit logical
addresses to physical ports. This mode is used for networking.
Control fields in the I-field are:
L The "Locally Defined" bit, when set, indicates that the I-field
is not in the standard format. The meaning of bits 30-0 are
locally defined.
W The Width bit, when set, requests a 64 bit connection through
the switch. It is meaningless if Cable B is not installed at
the Source. If W is set and either the Source or the requested
Destination has no Cable B to the switch, the switch rejects
the connection. Otherwise the switch connects both Cable A and
Cable B if W is set, or Cable A only if W is clear. This
feature is useful if both Source and Destination
implementations can selectively disable or enable Cable B on
each new connection.
D The Direction bit, when set, reverses the sense of the Source
Address and Destination Address fields. In other words, D=1
means that the Source Address is in bits 0-11 and the
Destination Address is in bits 12-23. This bit was defined to
give devices a simple way to route return messages. It is not
useful for LAN operations.
PS The Path Selection field determines whether the I-field
contains Source Route or Address information, and in Logical
Address mode, whether the switch may select from multiple
possible routes to the destination. The value "01" selects
Logical Address mode and fixed routes.
C The Camp-on bit requests the switch not to reject the
connection if the selected Destination is busy (connected to
another Source) but wait and make the connection when the
Destination is free.
Appendix B -- How to Build a Practical HIPPI LAN
"IP and ARP on HIPPI" describes the network host's view of a HIPPI
local area network without providing much information on the
architecture of the network itself. Here we describe a network
constructed from available HIPPI components, having the following
characteristics:
1. A tree structure with a central HIPPI-SC compliant hub and
optional satellite switches
2. Each satellite is connected to the hub by just one bidirectional
HIPPI link.
3. Serial HIPPI or transparent fiber optic HIPPI extender devices
may be used in any link.
4. Some satellites may be a particular switch product which is not
HIPPI-SC compliant.
5. Host systems are attached either directly to the hub or to
satellites, by single bidirectional links in which both HIPPI
cables go to the same numbered switch port.
6. A server system is attached to the hub. It provides multicast
and ARP services.
7. All options of the Internet Draft are supported. Hosts may use
any form of address resolution: manual configuration, ARP with
multicast, or ARP with a server.
Switch Address Management
Switch addresses use a flat address space. The 12-bit address is
subdivided into 6 bits of switch number and 6 bits of port number.
11 5 0
+-----------------------+-----------------------+
| Switch Number | Port Number |
+-----------------------+-----------------------+
Logical Address Construction
Switches may be numbered arbitrarily. A given host's address
consists of the number of the switch it is directly attached to
and the physical port number on that switch to which its input
channel is attached.
In the singly-connected tree structure, there is exactly one path
between any pair of hosts. Since each satellite must be connected
directly to the hub, the maximum length of this path is three
hops, and the minimum length is one. Each HIPPI-SC compliant
switch is programmed to map each of the host switch addresses to
the appropriate output port: either the port to which the host is
directly attached or a port that is linked to another switch in
the path to it.
Special Treatment of Nonstandard Switches
There is one commercially available switch that was designed
before the drafting of HIPPI-SC and is not fully compliant. It is
in common use, so it is worth making some special provisions to
allow its use in a HIPPI LAN. This switch supports only the
Source Route mode of addressing with a four bit right shift that
can be disabled by a hardware switch on each input port.
Addresses cannot be mapped. The switch does not support the "W,"
"D," or "PS" fields of the I-field; it ignores their contents.
Use of this switch as a satellite will require a slight deviation
from normal I-field usage by the hosts that are directly attached
to it. Hosts attached to standard switches are not affected.
For a destination connected to a non compliant satellite, the
satellite uses only the least significant four bits of the I-field
as the address. Since the address contains the destination's
physical port number in the least significant bits, its port will
be selected. Nonstandard switches should be set to disable I-
field shifting at the input from the hub, so that the destination
host will see its correct switch address in the I-field when
performing self-address discovery. I-field shifting must be
enabled on the satellite for each input port to which a host is
attached.
Hosts attached to nonstandard satellites must deviate from the
normal I-field usage when connecting to hosts on another switch.
It is suggested that all host implementations have this capability
as long as the nonstandard switches remain in use. The host must
know, by some manual configuration method, that it is connected to
a nonstandard switch, and it must have its "link port" number;
that is, the number of the port on the satellite that is connected
to the hub.
The normal I-field format for a 32-bit connection, per the
Internet Draft, is this:
31 26 23 11 0
+---------+---+-+-----------------------+-----------------------+
|0 0 0 0 0|x 1|C| Unused | Destination Address |
+---------+---+-+-----------------------+-----------------------+
The special I-field format is:
31 26 24 15 4 3 0
+---------+---+-+---------------+-----------------------+-------+
|0 0 0 0 0|x 1|C| Unused | Destination Address | Link |
+---------+---+-+---------------+-----------------------+-------+
This I-field is altered by shifting the lower 24 bits left by four
and adding the link port number. Camp-on is optional, and the PS
field is set to 01 or 11 (the host's option) as if the switch
supported logical address mode. All other I-field bits are set to
zero. When the host requests a connection with this I-field, the
switch selects a connection through the link port to the hub, and
shifts the lower 24 bits of the I-field right by four bits. The
link port number is discarded and the I-field passed through to
the hub is a proper HIPPI-SC I-field selecting logical address
mode.
A host on a nonstandard satellite may use the special I-field
format for all connection requests. If connecting to another host
on the same satellite, this will cause the connection to take an
unnecessarily long path through the hub and back. If an
optimization is desired, the host can be given additional
information to allow it to use the standard I-field format when
connecting to another host on the same switch. This information
could consist of a list of the other hosts on the same switch, or
the details of address formation, along with the switch number of
the local satellite, which would allow the host to analyze the
switch address to determine whether or not the destination is on
the local switch. This optimization is fairly complicated and may
not always be worthwhile.
Server Algorithm
Different host implementations may take any of three approaches to
address resolution:
1. Manual configuration, no ARP
2. Send ARP requests but expect a server to reply on its behalf
3. Send ARP requests and expect to receive them via multicast.
If the network includes a server that is capable of both multicast
and ARP service, and that knows the services expected by each
host, all can coexist on the same net.
The HIPPI-SC compliant switches are programmed to route the
HIPPI-SC "broadcast" address FE0 (hex) to the server's port. It
is initially given the following information by a human network
administrator:
1. The list of all addresses eligible to be used by network hosts
2. The list of addresses that should not receive multicast
messages (a subset of list 1). This is also the list of all
hosts that either do manual configuration or expect a server
to answer ARP requests.
3. The list of addresses of hosts that do manual configuration
and do not send ARP requests (a subset of list 2) with the IP
address corresponding to each one.
The server maintains an address resolution cache that it
initializes from list 3 (the manually configured hosts). It will
add to its cache as other hosts send ARP requests.
When the server receives a message sent to the broadcast address
FE0, it
1. Repeats the message to all addresses in list 1 but not in list
2
2. If the message is a HIPPI-LE AR_Request with a piggybacked ARP
Request, update the cache with information about the sender.
3. If the message is a HIPPI-LE AR_Request with a piggybacked ARP
Request, the target system has an entry in the cache and the
target is in list 2, respond to the ARP request.
Server Optimizations
1. The server could be given a topological map of the hub and
satellites from which it could construct list 1.
2. If all the hosts in list 2 ignore ARP messages as required
in the Internet Draft, list 2 may be eliminated and the
server can respond to all ARP requests (redundant replies
may be sent).
Sharing Switch Hardware With Other Devices
Some host channels and peripheral devices that are connected to
the switches may use protocols other than IP, and not participate
in the LAN. Since connections in a switch are independent, these
applications can share switch hardware with no effect on LAN
operation. To ensure success:
The server's lists of addresses should not include addresses
for ports that are not used by LAN links or hosts.
If non-LAN applications use paths between switches, separate
links should be installed for them so that they do not use the
same inter-switch links the LAN does.
References
[1] ANSI X3.183-1991, High-Performance Parallel Interface - Mechanical,
Electrical and Signalling Protocol Specification (HIPPI-PH).
[2] ANSI X3.210-199X, High-Performance Parallel Interface - Framing
Protocol (HIPPI-FP).
[3] ANSI X3.218-199X, High-Performance Parallel Interface -
Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link Control
Protocol Data Units (802.2 Link Encapsulation) (HIPPI-LE).
[4] ANSI X3.222-199X, High-Performance Parallel Interface - Physical
Switch Control (HIPPI-SC).
[5] Postel, J., "Internet Protocol", RFC791, USC/Information Sciences
Institute, September 1981.
[6] Postel, J., and Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
Sciences Institute, February 1988.
[7] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985.
[8] Reynolds, J.K., and Postel, J., "Assigned Numbers", RFC1340,
USC/Information Sciences Institute, July 1992.
[9] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC826, MIT, November
1982.
[10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse
Address Resolution Protocol", RFC903, Stanford University, June
1984.
[11] Katz, D., "A Proposed Standard for the Transmission of IP Datagrams
over FDDI Networks", RFC1188, Merit/NSFNET, October, 1990.
[12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
[13] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC1191,
Stanford University, November, 1990.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
John K. Renwick
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55121
Phone: (612) 683-5573
Mailing List: (none)
EMail: jkr@CRAY.COM
Andy Nicholson
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55121
Phone: (612) 683-5473
Mailing List: (none)
EMail: droid@CRAY.COM