As per Relevance of the word resolution, we have this rfc below:
Network Working Group J.
Request for Comments: 1374 A.
Cray Research, Inc
October 1992
IP and ARP on
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
The ANSI X3T9.3 committee has drafted a proposal for
encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP
HIPPI. Another X3T9.3 draft describes the operation of
physical switches. X3T9.3 chose to leave HIPPI networking
largely outside the scope of their standards; this document
methods of using of ANSI standard HIPPI hardware and protocols in
context of the Internet, including the use of HIPPI switches as
and interoperation with other networks.
Table of
Introduction 2
Scope 2
Definitions 3
Equipment 4
Protocol 6
Packet Format 6
48 bit Universal LAN MAC addresses 10
I-Field Format 11
Rules For Connections 13
MTU 15
Camp-on 16
Address Resolution 16
ARP and RARP Message Format 17
ARP Procedure 21
ARP Implementation Methods 22
Renwick & Nicholson [Page 1]
RFC 1374 IP and ARP on HIPPI October 1992
ARP Example 23
Discovery of One's Own Switch Address 25
Path MTU Discovery 27
Channel Data Rate Discovery 27
Performance 29
Sharing the Switch 31
Appendix A -- HIPPI Basics 31
Appendix B -- How to Build a Practical HIPPI LAN 37
References 41
Security Considerations 42
Authors' Addresses 42
The ANSI High-Performance Parallel Interface (HIPPI) is a
data channel. Configured in pairs, HIPPI can send and receive
simultaneously at nearly 800 megabits per second. (HIPPI has
equally applicable 1600 megabit/second option.) Between 1987
1991, the ANSI X3T9.3 HIPPI working group drafted four documents
bear on the use of HIPPI as a network interface. They cover
physical and electrical specification (HIPPI-PH [1]), the framing
a stream of octets (HIPPI-FP [2]), encapsulation of IEEE 802.2
(HIPPI-LE [3]), and the behavior of a standard physical layer
(HIPPI-SC [4]). HIPPI-LE also implies the encapsulation of
Protocol[5]. The reader should be familiar with the ANSI
documents, copies of which are archived at the
"nsco.network.com" in the directory "hippi," and may be obtained
anonymous FTP until they become published standards
HIPPI switches can be used to connect a variety of computers
peripheral equipment for many purposes, but the working group
short of describing their use as Local Area Networks. This
takes up where the working group left off, using the
principle that except for length and hardware header,
datagrams sent on HIPPI should be identical to the same
sent on a conventional network, and that any datagram sent on
conventional 802 network[6] should be valid on HIPPI
This memo describes the HIPPI interface between a host and
crosspoint switch that complies with the HIPPI-SC draft standard
Issues that have no impact on host implementations are outside
scope of this memo. Host implementations that comply with this
are believed to be interoperable on a network composed of a
HIPPI-SC switch. They are also interoperable on a simple point-to
point, two-way HIPPI connection with no switch between them.
Renwick & Nicholson [Page 2]
RFC 1374 IP and ARP on HIPPI October 1992
may as well be interoperable on more complex networks, depending
the internals of the switches and how they are interconnected
however, these details are implementation dependent and outside
scope of this memo. To the extent that a gateway acts as a host on
HIPPI-SC LAN, its behavior is within the scope of this memo
Within the scope of this memo are
1. Packet format and header contents, including HIPPI-FP, HIPPI-LE
IEEE 802.2 LLC[7], SNAP and
2. I-Field
3. HIPPI switch address resolution, including self
4. Rules for the use of connections
Outside of the scope
1. Vendor dependent solutions for multicast or third party
2. Network configuration and
3. Host internal
4. The interface between a host and an outboard protocol processor
Used with respect to networks, this refers to Ethernet, FDDI
802 LAN types, as distinct from HIPPI-SC LANs
The HIPPI implementation that receives data from a HIPPI Source
An entity consisting of one HIPPI Source/Destination pair that
connected by parallel or serial HIPPI to a HIPPI-SC switch
that transmits and receives ARP and IP datagrams. A node may
an Internet host, bridge, router or gateway. This memo uses
term node in place of the usual "host" to indicate that a
might be connected to the HIPPI LAN not directly, but through
external adaptor that does some of the protocol processing for
host
Renwick & Nicholson [Page 3]
RFC 1374 IP and ARP on HIPPI October 1992
Serial
An implementation of HIPPI in serial fashion on coaxial cable
optical fiber, informally standardized by implementor's
in the Spring of 1991.
Switch
A value used as the address of a node on a HIPPI-SC network.
is transmitted in the I-field. HIPPI-SC switches may map
Addresses to physical port numbers
The HIPPI implementation that generates data to send to a
Destination
Universal LAN Address (ULA
A 48 bit globally unique address, administered by the IEEE
assigned to each node on an Ethernet, FDDI, 802 network or HIPPI
SC LAN
A HIPPI network can be composed of nodes with HIPPI interfaces,
cables or serial links, HIPPI-SC switches, gateways to other
and, possibly, proprietary equipment that multicasts or responds
ARP requests on behalf of the real nodes
Each HIPPI interconnection between a node and a switch shall
of a pair of HIPPI links, one in each direction
If a link between a node and the switch is capable of the 1600
Megabit/second data rate option (i.e. Cable B installed for 64
wide operation) in either direction, the node's HIPPI-
implementation shall also be capable of 32 bit operation (Cable
data suppressed) and shall be able to select or deselect the 1600Mb/
data rate option at the establishment of each new connection
The following figure shows a sample HIPPI switch configuration
Renwick & Nicholson [Page 4]
RFC 1374 IP and ARP on HIPPI October 1992
+-----+
| | H 4 |
| +--+--+
| +----+ +----+ +----+ |
| | H1 | | H2 | | H3 | +-++
| +--+ +-++-+ +-++-+ +-++-+ |PP
+---+H5| || || || ++++
| +--+ || || || ||
| +---++--------++--------++------++----+
| | | +---+
| +----+ | HIPPI-SC +----+ARP
+---+ G1 +--------+ +----+ |
| | +--------+ Switch | +---+
| +----+ | |
| +---++--------++--------++------++----+
| +--+ || || || ||
+---+H6| || ++++
| +--+ +-++-+ |PP
| | | +-++
| | G2 | |
| | | +--+--+
| +--+-+ | H 7 |
| | +-----+
|
-----+------------+-------+-----------+-------------+------
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H 8 | | H 9 | | H10 | | H11 |
+-----+ +-----+ +-----+ +-----+
Legend: ---+---+---+-- = 802 network, Ethernet or
|| = Paired HIPPI
H = Host
PP = Outboard Protocol
G =
ARP = ARP
A possible HIPPI
A single HIPPI-SC switch has a "non-blocking" characteristic,
means there is always a path available from any Source to
Destination. If the network consists of more than one switch,
path from a Source to a Destination may include a HIPPI link
switches. If this link is used by more than one Source/
pair, a "blocking" network is created: one Source may be blocked
access to a Destination because another Source is using the link
shares. Strategies for establishing connections may be
Renwick & Nicholson [Page 5]
RFC 1374 IP and ARP on HIPPI October 1992
complicated on blocking networks than on non-blocking ones
This memo ignores blocking issues, assuming that the HIPPI
consists of one HIPPI-SC switch or, if the network is more
than that, it presents no additional problems that a node must
aware of
Packet
The HIPPI packet format for Internet datagrams shall conform to
HIPPI-FP and HIPPI-LE draft standards. The HIPPI-FP D1_Area
contain the HIPPI-LE header. The HIPPI-FP D2_Area, when present
shall contain one IEEE 802.2 Type 1 LLC Unnumbered Information (UI
PDU. Support of IEEE 802.2 XID, TEST and Type 2 PDUs is not
on HIPPI, and Destinations that receive these PDUs may either
them or respond correctly according to IEEE 802.2 requirements
The length of a HIPPI packet, including trailing fill, shall be
multiple of eight octets as required by HIPPI-LE
+----------+-----------+---------------------+----------- ------+
| | | | IP . . . 0 - 7 |
| HIPPI-FP | HIPPI-LE | IEEE 802.2 LLC/SNAP | octets
|(8 octets)|(24 octets)| (8 octets) | ARP . . . fill |
+----------+-----------+---------------------+----------- ------+
HIPPI Packet
HIPPI-FP
ULP-id (8 bits) shall contain 4.
D1_Data_Set_Present (1 bit) shall be set
Start_D2_on_Burst_Boundary (1 bit) shall be zero
Reserved (11 bits) shall contain zero
D1_Area_Size (8 bits) should be sent as 3. Destinations
accept any value that HIPPI-FP defines as legal: from 3 to 127
(32 bit HIPPI) or 3 to 255 (64 bit HIPPI).
D2_Offset (3 bits) may be any value from 0 to 7.
D2_Size (32 bits) Shall contain the number of octets in
Renwick & Nicholson [Page 6]
RFC 1374 IP and ARP on HIPPI October 1992
IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present.
shall not exceed 65,288 (decimal). This value includes
IEEE 802.2 LLC/SNAP header and the IP datagram. It does
include trailing fill octets. (See "MTU," below.)
The first octet of the IEEE 802.2 LLC PDU (SSAP) shall
located at offset "n" of the packet,
n = 8 + (D1_Area_Size*8) + D2_
as specified in HIPPI-FP
HIPPI-LE
FC (3 bits) shall contain zero unless otherwise defined
local administration
Double_Wide (1 bit) shall contain one if the
associated with the sending Source supports 64 bit
operation. Otherwise it shall contain zero
Message_Type (4 bits) contains a code identifying the type
HIPPI-LE PDU. Defined values (binary) are
0 Data
1 Address Resolution Request PDU (AR_Request
2 Address Resolution Response PDU (AR_Response
3 Self Address Resolution Request PDU (AR_S_Request
4 Self Address Resolution Response PDU (AR_S_Response
5-11 Reserved by the ANSI X3T9.3
12-15 Locally
Destination_Switch_Address is a 24-bit field containing
Switch Address of the Destination if known, otherwise zero.
the address comprises less than 24 bits, it shall be
justified (occupying the least significant bits) in the field
Destination_Address_Type (4 bits) and Source_Address_Type (4
bits) contain codes identifying the type of addresses in
Destination_Switch_Address and Source_Switch_Address
respectively. Defined values (binary) are
0
1 HIPPI-SC Source Route (24 bits
2 HIPPI-SC Address (12 bits
3-11 Reserved by the ANSI X3T9.3
12-15 Locally
Renwick & Nicholson [Page 7]
RFC 1374 IP and ARP on HIPPI October 1992
Source_Switch_Address is a 24-bit field containing the
Address of the Source. If the address comprises less than 24
bits, it shall be right justified (occupying the
significant bits) in the field
Reserved (16 bits) shall contain zero
Destination_IEEE_Address (48 bits) shall contain the 48
Universal LAN MAC Address of the Destination if known
otherwise zero
LE_Locally_Administered (16 bits) shall contain zero
otherwise defined by local administration
Source_IEEE_Address (48 bits) shall contain the 48
Universal LAN MAC Address of the Source if known,
zero
IEEE 802.2
The IEEE 802.2 LLC Header shall begin in the first octet of
HIPPI-FP D2_Area
SSAP (8 bits) shall contain 170 (decimal).
DSAP (8 bits) shall contain 170 (decimal).
CTL (8 bits) shall contain 3 (Unnumbered Information).
Organization Code (24 bits) shall be zero
EtherType (16 bits) shall be set as defined in Assigned
[8] (IP = 2048, ARP = 2054, RARP = 32,821).
Renwick & Nicholson [Page 8]
RFC 1374 IP and ARP on HIPPI October 1992
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| Reserved | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | (n+8) |
+-----+-+-------+-----------------------------------------------+
2 |[LA] |W|M_Type | Destination_Switch_Address |
+-----+-+-------+-----------------------------------------------+
3 | D_A_T | S_A_T | Source_Switch_Address |
+-------+-------+---------------+-------------------------------+
4 | Reserved | [Destination_IEEE_Address] |
+-------------------------------+ |
5 | |
+-------------------------------+-------------------------------+
6 | [LA] | [Source_IEEE_Address] |
+-------------------------------+ |
7 | |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | [EtherType] |
+---------------+---------------+---------------+---------------+
10 |Message octet 0|Message octet 1|Message octet 2| . . . |
+---------------+---------------+---------------+--- |
| . . .
|
| -------+---------------+---------------+---------------+
| . . . | octet (n-2) | octet (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HIPPI Packet
Words 0-1: HIPPI-FP
Words 2-7: D1 Area (HIPPI-LE Header
Words 8-9: D2 Area (IEEE 802.2 LLC/SNAP
Words 10-(N-1): D2 Area (IP or ARP message
(n) is the number of octets in the IP or ARP message
+====+ denotes the boundary between D1 and D2 areas
[LA] fields are zero unless used otherwise locally
Abbreviations: "W" = Double_Wide field
"M_Type" = Message_Type field
"D_A_T" = Destination_Address_Type
"S_A_T" = Source_Address_Type
[FILL] octets complete the HIPPI packet to an
number of 32 bit words. The number of fill
is not counted in the data length
Renwick & Nicholson [Page 9]
RFC 1374 IP and ARP on HIPPI October 1992
IEEE 802.2
The IEEE 802.2 Data shall follow the EtherType field immediately
Fill octets shall be used following the Data as necessary to
the number of octets in the packet a multiple of 8. In
with HIPPI-FP, the amount of this fill is not included in
D2_Size value in the HIPPI-FP Header
The order of the octets in the data stream is from higher
to lower numbered data signal (left to right) within the
word, as specified in HIPPI-FP Clause 7, "Word and byte formats."
With the 1600 megabit/second data rate option (64 bit) bits 32
through 63 are on Cable B, so that the four octets on Cable B
logically before those on Cable A. Within each octet, the
significant bit is the highest numbered signal
48 bit Universal LAN MAC
IEEE Standard 802.1A specifies the Universal LAN MAC Address.
globally unique part of the 48 bit space is administered by the IEEE
Each node on a HIPPI-SC LAN should be assigned a ULA. Multiple
may be used if a node contains more than one IEEE 802.2 LLC
entity
The format of the address within its 48 bit HIPPI-LE fields
IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order
31 23 15 7 0
+-------------------------------+---------------+---------------+
| (not used for ULA) |ULA octet 0|L|G| ULA octet 1 |
+---------------+---------------+---------------+---------------+
| ULA octet 2 | ULA octet 3 | ULA octet 4 | ULA octet 5 |
+---------------+---------------+---------------+---------------+
Universal LAN MAC Address
L (U/L bit) = 1 for Locally administered addresses, 0
Universal
G (I/G bit) = 1 for Group addresses, 0 for Individual
The use of ULAs is optional, but encouraged. Although ULAs are
used by HIPPI-SC switches, they are helpful for HIPPI Switch
resolution, and for distinguishing between multiple logical
that may exist within one node. They may also be used by
devices that replace HIPPI hardware headers with the MAC headers
other LANs. Carrying the ULAs in the HIPPI header may simplify
devices, and it may also help if HIPPI is used as an interface
some future HIPPI based LAN that uses ULAs for addressing
Renwick & Nicholson [Page 10]
RFC 1374 IP and ARP on HIPPI October 1992
Recommended HIPPI-FP
HIPPI-FP allows some flexibility in the construction of a
packet, including placement of short bursts, optional fill and
octets between the D1 and D2 areas and fill following the D2 data
For efficiency, Sources should limit the use of these options
1. Send the short burst as the last burst of the packet rather
the first
2. Do not place fill octets between the HIPPI-LE header and
start of the D2_Area
3. Use no more than seven octets after the D2 Data, as needed
make the total packet length a multiple of 8 octets
One HIPPI-FP option is forbidden: setting the Start_D2_on_Burst_
flag to one. This places no limitation on the formation of packets
a series of bursts; a Source may segment the packet in any legal
according to HIPPI-FP, including forcing the D2_Area to start on a
boundary. The purpose of the Start_D2_on_Burst_Boundary flag is to
preserve the segmentation of the packet for some device-
protocols that use the first burst boundary to separate command and
areas within the packet. Requiring this flag to be clear means
when a packet arrives at the Destination its burst boundaries might
be exactly as the Source sent them. This may occur if a HIPPI
passes over some other medium in the route between HIPPI LANs
Notwithstanding these recommendations, each Destination shall accept
well-formed HIPPI packet within the definitions in HIPPI-FP
Note that neither HIPPI-FP nor HIPPI-LE limits the number of fill
placed between the end of the IP packet and the end of the HIPPI-
packet. Some source implementations may add fill sufficient to
a destination input buffer. To avoid interpreting valid packets
errors, destinations should ignore overflow conditions and verify
at least the number of bytes indicated by the IP header
arrived
I-Field
The I-field bits, as defined in HIPPI-SC, shall be set as follows
Locally Administered (bit 31) shall be zero
Reserved (bits 30, 29) should be zero. Destinations shall
any value for these bits
Renwick & Nicholson [Page 11]
RFC 1374 IP and ARP on HIPPI October 1992
Double wide (bit 28) shall be set when Source Cable B is
and the Source wants a 64 bit connection. It shall be
otherwise
Direction (bit 27) should be sent as zero, however
shall accept either zero or one and interpret the Routing
field accordingly, per HIPPI-SC
Path Selection (bits 26, 25) shall be 00, 01, or 11 (binary)
the Source's option. 00 (source route mode) indicates that
I-field bits 23-00 contain a 24 bit source route; 01 or 11
(logical address mode) indicate that bits 23-00 contain 12
Source and Destination Addresses. The value 11 is meaningful
more than one route exists from a Source to a Destination;
allows the switch to choose the route. Use of 01 forces
switch always to use the same route for the
Source/Destination pair
Camp-on (bit 24) may be 1 or 0; however, a Source shall not
consecutive requests without Camp-on to the same Destination
the requests are being rejected. The purpose of this
is to prevent a node from circumventing the fair share
mechanism of the switch by repeating requests at a very high rate
If logical address mode is used
Source Address (bits 23-12) is not used
Destination Address (bits 11-0) shall contain the
Address of the Destination
If source route mode is used
Routing control (bits 23-00) shall contain the route to
Destination
Note: the outcome of Switch Address Resolution (see "
Resolution" below) determines whether to use logical address
or source route mode. If source route mode is used with
interconnected switches, different sources may use
addresses to reach the same destination, and multicast-
address resolution may not be possible because a target node
not know the route to itself from a given remote source
Regardless of this difficulty, it may be possible to use
route mode if the network consists of a single switch, or
address resolution is supported by an ARP agent that is able
deliver correct routes to each node. The nodes themselves
not be concerned with these problems if they use the
Renwick & Nicholson [Page 12]
RFC 1374 IP and ARP on HIPPI October 1992
mode suggested by the value of the Source_Address_Type field in
HIPPI-LE Address Resolution Response packet
Rules For
The following rules for connection management by Source
Destination are intended to insure frequent, fair share access
Destinations for which multiple Sources are contending. If possible
nodes should transfer data at full HIPPI speeds and hold
no longer than necessary
A source may hold a connection for as long as it takes to send 68
HIPPI bursts at what ever speed the two connected nodes can
together. The number of packets sent in one connection is
limited, except that the number of bursts over all the packets
not exceed 68. This is not a recommendation to send as many
as possible per connection; one packet per connection is acceptable
The purpose of this limit is to give each Source an fair share of
common Destination's bandwidth. Without a limit, if there is
Destination that is constantly in demand by multiple Sources,
Source that sends the most data per connection wins the
share of bandwidth
The limit of 68 bursts is not absolute. An implementation may
the burst count after transmission of a packet and end the
if it is greater than or equal to some threshold. If this is done
the threshold should be less than 68 depending on the typical
size, to ensure that the 68 burst limit is not normally exceeded
For instance, a Source sending 64K packets would send two
connection (130 bursts) if it checked for 68 at the end of
packet. In this situation the Source is required to check for
value small enough that it will not send a second packet in the
connection
Destinations shall accept all packets that arrive during
connection, and may discard those that exceed its buffering capacity
A Destination shall not abort a connection (deassert CONNECT)
because too many bursts were received; however a Destination
abort a connection whose duration has exceeded a time period of
Destination's choosing, as long as the Source is allowed ample
to transmit its quota of bursts
The rules admonish the node to do certain things as fast as it can
however there is no absolute measure of compliance. Nodes
cannot transfer data at full HIPPI speeds can still interoperate
the faster the implementation, the better the performance of
network will be
Renwick & Nicholson [Page 13]
RFC 1374 IP and ARP on HIPPI October 1992
Assuming that bursts flow at the maximum rate, the most
factor in network throughput is the connection switching time
measured from the deassertion of REQUEST by the Source at the end
one connection to its first assertion of BURST after
establishment of the new connection. Implementations should
this time as short as possible. For a guideline, assuming
HIPPI and a single HIPPI-SC switch, ten microseconds permits
full HIPPI throughput with full-sized packets, and at 60
the available throughput is reduced by about 10%. (
"Performance," below.)
All HIPPI electrical signaling shall comply with HIPPI-PH. In
case, the following rules go beyond what HIPPI-PH requires
Rules for the
1. Do not assert REQUEST until a packet is ready to send
2. Transmit bursts as quickly as READYs permit. Except for
required HIPPI Source Wait states, there should be no delay
the assertion of BURST whenever the Source's READY counter
nonzero
3. Make a best effort to ensure that connection durations do
exceed 68 bursts
4. Deassert REQUEST immediately when no packet is available
immediate transmission or the last packet of the
has been sent
Rules for the
1. Reject all connections if unable to receive packets.
frees the requesting Source to connect to other
with a minimum of delay. Inability to receive packets is
a transient condition, but is the state of the
when its network interface is not initialized
2. A HIPPI node should be prepared to efficiently
connections and process incoming data packets. While this
be best achieved by not asserting connect unless 68
worth of buffers is available, it may be possible to meet
requirement with fewer buffers. This may be due to a
agreement between nodes on packet sizes, the speed of
interface to move buffers, or other implementation
considerations
Renwick & Nicholson [Page 14]
RFC 1374 IP and ARP on HIPPI October 1992
3. Accept a connection immediately when buffers are available
The Destination should never delay the acceptance of
connection unnecessarily
4. Once initialized, a Destination may reject connection
only for one of the following reasons
1. The I-field was received with incorrect parity
2. The I-field contents are invalid, e.g. the "W" bit
when the Destination does not support the 1600
data rate option, the "Locally Administered" bit is set
the Source is not permitted to send to this Destination
etc
Transient conditions within the Destination, such as
buffer shortages, must never cause rejected connections
5. Ignore aborted connection sequences. Sources may time out
abandon attempts to connect; therefore aborted
sequences are normal events
Maximum Transmission Unit (MTU) is defined as the length of the
packet, including IP header, but not including any overhead
IP. Conventional LANs have MTU sizes determined by physical
specification. MTUs may be required simply because the
medium won't work with larger packets, or they may serve to
the amount of time a node must wait for an opportunity to send
packet
HIPPI has no inherent limit on packet size. The HIPPI-FP
contains a 32 bit D2_Size field that, while it may limit
to about 4 gigabytes, imposes no practical limit for
purposes. Even so, a HIPPI-SC switch used as a LAN needs an
so that Destination buffer sizes can be determined
The MTU for HIPPI-SC LANs is 65280 (decimal) octets
This value was selected because it allows the IP packet to fit
one 64K octet buffer with up to 256 octets of overhead.
overhead is 40 octets at the present time; there are 216 octets
room for expansion
Renwick & Nicholson [Page 15]
RFC 1374 IP and ARP on HIPPI October 1992
HIPPI-FP Header 8
HIPPI-LE Header 24
IEEE 802.2 LLC/SNAP Headers 8
Maximum IP packet size (MTU) 65280
------------
Total 65320 octets (64K - 216)
Camp-
When several Sources contend for a single Destination, the Camp-
feature allows the HIPPI-SC switch to arbitrate and ensure that
Sources have fair access. (HIPPI-SC does not specify the method
arbitration.) Without Camp-on, the contending Sources would
have to retry the connection repeatedly until it was accepted,
the fastest Source would usually win. To guarantee fair
arbitration, Sources are prohibited from making repeated requests
the same Destination without Camp-on in such a way as to defeat
arbitration
There is another important reason to use Camp-on: when a
without Camp-on is rejected, the Source cannot determine whether
rejection came from the requested Destination or from the switch
The Source also cannot tell the reason for the rejection, which
be either that the Destination was off line or not cabled, or the I
field was erroneous or had incorrect parity. Sources should
treat a rejection of a request without Camp-on as an error. Camp-
prevents rejection due to the temporary busy case; with
exception, rejection of a Camp-on request indicates an
condition, and an error event can be recorded. The exception
when a 64 bit connection is attempted to a Destination that does
have Cable B connected, resulting in a reject. This case is
in "Channel Data Rate Discovery," below
Address
The Internet Address Resolution Protocol (ARP) is defined in RFC 826
[9]. Ethernet, FDDI and 802 networks use ARP to discover
host's ULA knowing the Internet address. Reverse ARP [10] is used
discover the Internet address, knowing the ULA. ARP can be used
the conventional way on HIPPI-SC LANs equipped with a
capability or third party ARP agent
HIPPI-LE defines similar lower-level address resolution between
and switches. HIPPI-LE adds a self-address resolution mechanism
defined for Internet ARP, which allows a node to discover its
switch address dynamically
Renwick & Nicholson [Page 16]
RFC 1374 IP and ARP on HIPPI October 1992
ARP for the purpose of discovering ULAs is not necessary for
operation of a HIPPI-SC LAN, but it serves as the vehicle
discovery of HIPPI-SC Switch Addresses, without which the HIPPI-
LAN cannot function. In other words, at the same time a node
using ARP to map another node's IP address to its ULA, it is
mapping the ULA to the 12 bit HIPPI Switch Address, from which
will construct the I-field value for sending messages to that node
This additional level of hardware addressing uses the address
in the HIPPI-LE header
In the following discussion, the terms "requester" and "target"
used to identify the node requesting address resolution and the
whose address it wishes to discover, respectively. In third
ARP (see "ARP Implementation Methods," below) the source of a
is an ARP agent node, not the target node
ARP and RARP Message
The HIPPI ARP/RARP protocol uses the same packet format as ARP
Ethernet. ARP packets shall be transmitted with a hardware
code of 1 (as for Ethernet). Furthermore, ARP packets shall
accepted if received with hardware type codes of either 1 or 6
(IEEE 802 networks).
ar$hrd (16 bits) shall contain 1.
ar$pro (16 bits) shall contain the IP protocol code 2048
(decimal).
ar$hln (8 bits) shall contain 6.
ar$pln (8 bits) shall contain 4.
ar$op (16 bits) shall contain 1 for requests, 2 for responses
ar$sha (48 bits) in requests shall contain the requester's ULA
In replies it shall contain the target node's ULA
ar$spa (32 bits) in requests shall contain the requester's
address if known, otherwise zero. In replies it shall contain
target node's IP address
ar$tha (48 bits) in requests shall contain the target's ULA
known, otherwise zero. In replies it shall contain
requester's ULA
ar$tpa (32 bits) in requests shall contain the target's IP
if known, otherwise zero. In replies it shall contain
Renwick & Nicholson [Page 17]
RFC 1374 IP and ARP on HIPPI October 1992
requester's IP address
The format of the six octets of the ULA shall be the same
required in the HIPPI-LE header (see "48 bit Universal LAN
Addresses" above), except for the alignment of the Source ULA
respect to the 32 bit HIPPI word, which is different between
and HIPPI-LE. No bit reversal is necessary as is required
FDDI [11].
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 36 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W| 1 | 000 | Target Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 |Requester's Switch Addr
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Target ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Requester's ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | EtherType (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (1) | pro (2048) |
+---------------+---------------+-------------------------------+
11 | hln (6) | pln (4) | op (1) |
+---------------+---------------+-------------------------------+
12 | Requester's ULA octets 0 - 3 |
+-------------------------------+-------------------------------+
13 | Requester's ULA octets 4 - 5 | Requester's IP Address upper |
+-------------------------------+-------------------------------+
14 | Requester's IP Address lower | Target ULA octets 0 - 1 |
+-------------------------------+-------------------------------+
15 | Target ULA octets 2 - 5 |
+---------------------------------------------------------------+
16 | Target IP Address |
+---------------------------------------------------------------+
HIPPI ARP/RARP Request (logical address mode
Renwick & Nicholson [Page 18]
RFC 1374 IP and ARP on HIPPI October 1992
All ARP requests shall be sent with the I-field bit 28 set to zero
i.e. requesting a 32 bit connection
Unless another convention is locally defined for ARP requests,
I-field Path Selection bits may be set to binary 01 or 11 (
address mode), and Destination Address field set to the HIPPI-
address reserved for traffic conventionally directed to the
802.1[12] broadcast address (which HIPPI-SC defines as FE0, hex).
Reply packets shall be sent with I-field Path Selection and
Control fields set according to the Source_Address_Type
Source_Switch_Address fields in the request
In the HIPPI-LE header of ARP/RARP requests and replies the
fields shall be set
Double-Wide should be 1 if the HIPPI Destination at the sending
can accept 64 bit HIPPI connections
Message_Type shall contain an address resolution type code as
in HIPPI-LE. It shall be set appropriately to the value of the
operation code (ar$op) in piggybacked ARP messages
+-----------------------+-----------------------+
| ARP ar$op | HIPPI-LE Message_Type |
+=======================+=======================+
|ARP Request (1) |AR_Request (1) |
|ARP Reply (2) |AR_Response (2) |
+-----------------------+-----------------------+
|Reverse ARP Request (3)|AR_Request (1) |
|Reverse ARP Reply (4) |AR_Response (2) |
+-----------------------+-----------------------+
There is no ARP message corresponding to HIPPI-LE self
discovery; these packets are sent without ULP data
Destination_Switch_Address in requests shall be the Switch Address
the target node if known, otherwise zero. In replies it shall be
requesting node's Switch
Destination_Address_Type shall be 1 if the Destination_Switch_
is a source route, 2 if it is a 12 bit address
Source_Address_Type shall be 1 if the Source_Switch_Address is
source route, 2 if it is a 12 bit address
Source_Switch_Address in requests shall be the Switch Address of
requesting node if known, otherwise zero. In replies it shall be
Renwick & Nicholson [Page 19]
RFC 1374 IP and ARP on HIPPI October 1992
target node's Switch Address
Destination_IEEE_Address shall be the same as the ar$tha field in
ARP message
Source_IEEE_Address shall be the same as the ar$sha field in the
message
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 36 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W| 2 | 000 |Requester's Switch Addr
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Target Switch Address |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Requester's ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Target ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | EtherType (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (1) | pro (2048) |
+---------------+---------------+-------------------------------+
11 | hln (6) | pln (4) | op (2) |
+---------------+---------------+-------------------------------+
12 | Target ULA octets 0 - 3 |
+-------------------------------+-------------------------------+
13 | Target ULA octets 4 - 5 | Target IP Address upper |
+-------------------------------+-------------------------------+
14 | Target IP Address lower | Requester's ULA octets 0 - 1 |
+-------------------------------+-------------------------------+
15 | Requester's ULA octets 2 - 5 |
+---------------------------------------------------------------+
16 | Requester's IP Address |
+---------------------------------------------------------------+
HIPPI ARP/RARP Reply (logical address mode
Renwick & Nicholson [Page 20]
RFC 1374 IP and ARP on HIPPI October 1992
ARP
The combined HIPPI-LE/ARP packet contains six addresses, three
for the requester and the target
Requester's IP Address (ARP
Requester's ULA (ARP and HIPPI-LE
Requester's Switch Address (HIPPI-LE
Target's IP Address (ARP
Target's ULA (ARP and HIPPI-LE
Target's Switch Address (HIPPI-LE
Internet ARP concerns the IP Address and ULA; HIPPI-LE
resolution concerns the ULA and Switch Address. Thus the ULA
in both parts of the packet
Successful ARP results in tables in each node that map remote nodes
IP addresses to ULAs and ULAs to Switch Addresses, so that when
application requests a connection to a remote node by its IP address
both the remote ULA and Switch Address can be determined, a
HIPPI-LE header can be built, and a connection to the node can
established using the correct Switch Address in the I-field.
recipient of an ARP request or reply may use information in
packet to augment its tables, even if it is neither the target
nor the requester
Note that the use of ULAs with HIPPI is not required. In both
HIPPI-LE header and the Internet ARP message, the fields that
ULAs should be set to zero when the ULA is not known.
resolution consists of two separate protocols, HIPPI-LE
resolution and Internet ARP, neither of which can
independently without ULAs. However HIPPI Switch Address
can work without ULAs if the two protocols are piggybacked
treated as one operation in which Internet addresses are
directly to switch addresses. With the exception of the
self-address resolution request, which has no analogous
protocol, HIPPI-LE address resolution and Internet ARP
should be sent together as a single HIPPI packet
If ULAs are used, the HIPPI-LE address resolution request can be
without a piggybacked 802.2 LLC PDU, so it is possible to map ULAs
HIPPI Switch Addresses without using ARP. Nodes shall accept
piggybacked and non-piggybacked forms of HIPPI-LE address
messages
The recipient of an address resolution request, having first
its address mapping tables with any new information it can find
Renwick & Nicholson [Page 21]
RFC 1374 IP and ARP on HIPPI October 1992
the request, checks to see if it is the target node. If it is,
generates a reply by filling in the unknown target address
according to the HIPPI-LE message type and the ARP operation code
and swapping the four pairs of source/target address fields. Then
connects to the requesting node with the Source Switch Address
the request, and sends the reply packet
A node is the target of an address resolution request if the
contains one of the following
1. the node's ULA in the Destination_IEEE_Address field of a HIPPI
LE AR_Request
2. the node's IP address in the target protocol address
(ar$tpa) of a piggybacked Internet ARP
If two target fields are known but are not mapped together in
recipient's address mapping tables, it may do one of three things
1. treat the request as having two targets, and send correct
for both to the requester
2. assume its own tables are invalid and ignore the request
3. assume one of the "known" target fields is correct and respond
if the other had been unknown
The best choice depends on which fields conflict and the nature
the implementation. Choice 3 is probably best for ordinary nodes
but third party ARP agents may have reason to use one of the
two. Future experience may shed light on this
ARP Implementation
The requirements for nodes to handle address resolution
depend on the means by which address resolution is implemented on
LAN
In conventional networks ARP is a distributed function. ARP
are broadcast; each host may update its address mappings with any
request or reply it sees, and responds to ARP requests that
its own address in the target protocol address field. HIPPI-
switches are not required to provide multicast service, although
do. Even if the switches do not multicast, one or more nodes can
as multicast servers, receiving packets sent to the HIPPI-
broadcast address and repeating them to each other node in turn
Either way, if multicast exists on a HIPPI-SC LAN, ARP can be
distributed function. In this situation each node is required
Renwick & Nicholson [Page 22]
RFC 1374 IP and ARP on HIPPI October 1992
respond correctly to address resolution requests for which it is
target
Third party ARP is a second method that does not depend on multicast
The switches can map the HIPPI ARP multicast address to a node
acts as an ARP agent, replying to ARP requests on behalf of the
target nodes. Ordinary nodes never receive ARP requests or
replies and never have the opportunity to update mapping tables
on ARP requests from other nodes, as usually happens on
networks. Each node must request any address information it needs
but never has to process ARP information it doesn't need.
third party ARP a node should not receive address
requests, and each node that is not an ARP agent should ignore
that it does receive
As a third possibility, one can omit the implementation of
entirely, choosing instead to build address mapping tables in
node from information available to a network administrator. Such
technique is implementation dependent and outside the scope of
memo. It may be helpful in prototype networks without
where no ARP agent is yet implemented. In this case, nodes are
required to respond to address resolution requests, but must
any they may receive
ARP
Assume a HIPPI-SC switch is installed with two nodes, X and Y
connected. Each node has a unique Switch Address. Both nodes
access to the host data base (e.g. /etc/hosts) in which the
administrator has configured the network and given the two nodes
addresses. There is an ARP agent connected to a switch port that
mapped to the address FE0 (hex). The ARP agent contains no
of any IP, IEEE or Switch addresses. Both nodes know their own
and Switch Addresses. They want to talk to each other; each
the other's IP address (from the host data base) but neither
the other's ULA or Switch Address. Node X starts
1. Node X connects to FE0 and sends a piggyback ARP
requesting addresses for Y
HIPPI-LE Message_Type is 1, AR_
HIPPI-LE Destination_Switch_Address = 0
HIPPI-LE Source_Switch_Address = X's Switch
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = X's
ARP ar$op = 1 (request
ARP ar$sha = X's
ARP ar$spa = X's IP
Renwick & Nicholson [Page 23]
RFC 1374 IP and ARP on HIPPI October 1992
ARP ar$tha = 0
ARP ar$tpa = Y's IP
2. The ARP agent receives the ARP request and adds an entry for X
its address mapping table. It does not know about Y, so it
not generate a reply
3. Node X waits for a reply. It may set a timer to retransmit
request periodically, but its requests will be ignored until
Y sends an ARP request
4. Node Y connects to FE0 and sends an ARP request
addresses for X
HIPPI-LE Message_Type is 1, AR_
HIPPI-LE Destination_Switch_Address = 0
HIPPI-LE Source_Switch_Address = Y's Switch
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = Y's
ARP ar$op = 1 (request
ARP ar$sha = Y's
ARP ar$spa = Y's IP
ARP ar$tha = 0
ARP ar$tpa = X's IP
5. The ARP agent receives Y's request and adds an entry for Y to
address mapping table. It knows about the target node, X, so
connects to Y (using the Source_Switch_Address given in
request) and sends an ARP Reply
HIPPI-LE Message_Type is 2, AR_
HIPPI-LE Destination_Switch_Address = Y's Switch
HIPPI-LE Source_Switch_Address = X's Switch
HIPPI-LE Destination_IEEE_Address = Y's
HIPPI-LE Source_IEEE_Address = X's
ARP ar$op = 2 (reply
ARP ar$sha = X's
ARP ar$spa = X's IP
ARP ar$tha = Y's
ARP ar$tpa = Y's IP
6. Node Y receives the ARP reply and builds its address
table entry for Node X
7. Node Y connects to node X and transmits an IP packet with
following information in the HIPPI-LE header
HIPPI-LE Message_Type is 0, AR_
Renwick & Nicholson [Page 24]
RFC 1374 IP and ARP on HIPPI October 1992
HIPPI-LE Destination_Switch_Address = X's Switch
HIPPI-LE Source_Switch_Address = Y's Switch
HIPPI-LE Destination_IEEE_Address = X's
HIPPI-LE Source_IEEE_Address = Y's
8. Node X receives the IP packet. Since the ARP agent now
about node Y, node X can retransmit its ARP request (
step 1) and receive an ARP reply
HIPPI-LE Message_Type is 2, AR_
HIPPI-LE Destination_Switch_Address = X's Switch
HIPPI-LE Source_Switch_Address = Y's Switch
HIPPI-LE Destination_IEEE_Address = X's
HIPPI-LE Source_IEEE_Address = Y's
ARP ar$op = 2 (reply
ARP ar$sha = Y's
ARP ar$spa = Y's IP
ARP ar$tha = X's
ARP ar$tpa = X's IP
Address resolution is now complete for both nodes
If there had been a multicast facility instead of the ARP agent
the configuration, the target nodes themselves would have
the requests and responded to them in the same way the ARP agent did
Discovery of One's Own Switch
The ARP example above assumed that each node had prior knowledge
its own switch address. This may be manually configured, by
that are outside the scope of this memo, when each node is
to the switch. If a multicast capability exists, the node
discover its own address automatically when it starts up, using
protocol defined in HIPPI-LE
In the self-address discovery protocol, a node connects to
multicast address and sends a HIPPI-LE message containing its
ULA. It receives a multicast copy of its own message, and learns
own switch address from the destination address field of the
I-field
HIPPI-LE self address resolution uses the same HIPPI-LE
format described in "ARP and RARP Message Format," above, with
AR_S_Request and AR_S_Response message type codes and no
ULP data. The HIPPI-LE header contents for the request are
Message_Type is 3, AR_S_
Destination_Address_Type = 0 (undefined
Renwick & Nicholson [Page 25]
RFC 1374 IP and ARP on HIPPI October 1992
Destination_Switch_Address = 0 (unknown
Source_Address_Type = 0 (undefined
Source_Switch_Address = 0 (unknown
Destination_IEEE_Address = my
Source_IEEE_Address = my
There is no D2 data; the packet contains only the HIPPI-FP header
D1_Area containing the HIPPI-LE header
The node that wants to discover its address connects to the
address for this purpose (hex FE0 in HIPPI-SC) and transmits
request packet. What happens next depends on the particular network
With multicast
The node receives its own request and can learn its own
address from the I-field it receives. This is the only time
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
the Destination_IEEE_Address field and its own switch address
the Destination_Switch_Address field. This address may
different from the address contained in the I-field, and should
used instead
The ARP agent response alternative requires that the agent have
knowledge of the node's location and ULA through some process
specified by this memo. The node may receive both its request
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
by the address given by the ARP agent in the response. Agents
assign new addresses to nodes and inform them by sending
AR_S_Response messages. Any node whose switch address is updated
this way should invalidate the switch addresses it has saved
other nodes, and use ARP to rediscover them
If the node reacts correctly to either the multicast request
agent-generated response, it can discover its address without
to know whether or not an ARP agent is active. The full
is
1. Transmit the AR_S_
Renwick & Nicholson [Page 26]
RFC 1374 IP and ARP on HIPPI October 1992
2. When a connection arrives, accept it and save the I-field
later analysis
3. Receive the message and look at the HIPPI-LE header. If
message is Message Type AR_S_Request, analyze the I-field
discover the node's own switch address. HIPPI-SC I-field
suggest the following
if bit 25 == 1
Address type is HIPPI-SC logical address
if bit 27 == 1
take address from bits 23-12
take address from bits 11-00
Address is unusable (source route
This is a one-time operation. Once the node knows an address
itself, it should not take any new address from a received I
field
4. If a message of type AR_S_Response arrives and
Destination_IEEE_Address field contains the node's own ULA,
the new switch address from the Destination_Switch_Address
and its type from the Destination_Address_Type field
5. The node should invalidate its ARP tables when an AR_S_
changes its own switch address, to force retransmission of
requests containing its new address to all the remote nodes
which it communicates
Path MTU
RFC 1191 [13] describes the method of determining MTU restrictions
an arbitrary network path between two hosts. HIPPI nodes may
this method without modification to discover restrictions on
between HIPPI-SC LANs and other networks. Gateways between HIPPI-
LANs and other types of networks should implement RFC 1191.
Channel Data Rate
HIPPI exists in two data rate options (800 megabit/second and 1600
megabit/second). The higher data rate is achieved by making
HIPPI 64 bits parallel instead of 32, using an extra cable
32 additional data bits and four parity bits. HIPPI-SC switches
Renwick & Nicholson [Page 27]
RFC 1374 IP and ARP on HIPPI October 1992
be designed to attach to both. Source and Destination
implementations can be designed to operate at either rate,
at the time a connection is established. The "W" bit (bit 28) of
I-field controls the width of the connection through the switch
Sources with both cables A and B attached to the switch may set
"W" bit to request a 1600 megabit/second connection. If
requested destination also has both cables attached, the switch
connect Source to Destination on both cables. If the
Destination has only Cable A, the switch rejects the request
Sixty-four bit Sources can connect to 32 bit Destinations
requesting with the "W" bit clear and not using Cable B. Sixty-
bit Destinations must examine the "W" bit in the received I-field
use or ignore Cable B accordingly. Note that both
signals stay active while a 64 bit HIPPI is used in 32 bit mode
The following table summarizes the possible combinations,
switch's action for each, and the width of the resulting connection
+-------------------+-------------------+
| 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
If the path between a 64 bit Source and a 64 bit Destination
more than one switch, and the route between switches uses a link
is only 32 bits wide, the switch rejects 64 bit connection
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
know the data rates available at each Destination and on the path
it. This can be known a priori by manual configuration, or it can
discovered dynamically. The only reliable method of discovery
simply to attempt a 64 bit connection with Camp-on. As long as 64
bit connections succeed, the Source knows the Destination and
are double width. If a 64 bit connection is rejected, the
tries to connect for 32 bits. If the 32 bit connection succeeds,
Source assumes that the Destination or path is not capable of
width operation, and uses only 32 bit requests after that. If the 32
Renwick & Nicholson [Page 28]
RFC 1374 IP and ARP on HIPPI October 1992
bit request is rejected, the Source assumes that the Destination
path is down and makes no determination of its capability
The Double_Wide bit in the HIPPI-LE header, if nonzero, gives
node that receives it a hint that the 64 bit connection attempt
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.
the request is made with the "W" bit and no Camp-on, a reject
mean either that the Destination has no Cable B or that it is
busy, and no conclusion can be drawn as to its status for 64
connections
The HIPPI connection rules are designed to permit best utilization
the available HIPPI throughput under the constraint that
Destination must be made available frequently to receive packets
different Sources. This discipline asks both Sources
Destinations to minimize connection setup overhead to deliver
performance. Low connection setup times are easily achieved
hardware implementations, but overhead may be too high if software
required to execute between the initial request of a connection
the beginning of data transfer. Hardware implementations in
connection setup and data transfer proceed from a single
action are very desirable
HIPPI connections are controlled by HIPPI Sources; a Destination
being unable to initiate a disconnect without the possibility of
loss, is a slave to the Source once it has accepted a connection
Optimizations of connection strategy are therefore the province
the HIPPI Source, and several optimizations are permitted
If the rate of available message traffic is less than the
HIPPI throughput and Destinations are seldom busy when a
is requested, connection optimizations do not pay off and
simplest strategy of waiting indefinitely for each connection to
made and sending messages strictly in the order queued cannot
improved upon. However if some nodes are slow, or
applications can send or receive messages at a higher aggregate
than the available HIPPI bandwidth, Sources may frequently
a busy Destination. In these cases, certain host output
strategies may enhance channel utilization. Sources may
separate output queues for different HIPPI Destinations, and
one Destination in favor of another if a connection attempt
Camp-on is rejected or a connection request with Camp-on is
accepted within a predetermined interval. Such a strategy results
Renwick & Nicholson [Page 29]
RFC 1374 IP and ARP on HIPPI October 1992
aborted connection sequences (defined in HIPPI-PH: REQUEST
deasserted before any data is sent). Destinations must treat
as normal events, perhaps counting them but otherwise ignoring them
Two components of connection setup time are out of the control
both Source and Destination. One is the time required for the
to connect Source to Destination, currently less than
microseconds in the largest commercially available (32 port) switch
The second component is the round trip propagation time of
REQUEST and CONNECT signals, negligible on a standard 25 meter
HIPPI cable, but contributing a total of about 10 microseconds
kilometer on fiber optic links. HIPPI-SC LANs spanning more than
few kilometers will have reduced throughput. Limited span
with buffered gateways or bridges between them may perform
than long serial HIPPI links
A Source is required to drop its connection after the transmission
68 HIPPI bursts. This number was chosen to allow the transmission
one maximum sized packet or a reasonable number of smaller
packets. The following table lists some possibilities,
calculated maximum burst and throughput rates in millions (10**6)
bytes per second
Maximum HIPPI Throughput
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
full burst and 23 clock periods for a short burst. (HIPPI-
specifies three clock periods of overhead per burst.) A packet of "n
kilobytes of user data consists of "n" full bursts and one
burst equal in length to the number of bytes in the HIPPI, LLC,
and TCP headers. "Hold Time" is the minimum connection
needed to send the packets. "Burst Rate" is the effective
rate for the duration of the connection, not counting
switching time. Throughput rates are in megabytes/second,
for connection switching times of 10, 30, 60, 90, 120 and 150
microseconds. These calculations ignore any limit on the rate
Renwick & Nicholson [Page 30]
RFC 1374 IP and ARP on HIPPI October 1992
which a Source or Destination can process small packets; such
may further reduce the available throughput if small packets
used
Sharing the
Network interconnection is only one potential application of
and HIPPI-SC switches. While network applications need very
transient connections, other applications may favor longer term
even permanent connections between Source and Destination. Since
switch can serve each Source or Destination with hardware
totally separate from every other, it is quite feasible to use
same switch to support LAN interconnects and computer/
applications simultaneously
Switch sharing is no problem when unlike applications do not share
HIPPI cable on any path. However if a host must use a single
or output cable for network as well as other kinds of traffic, or
a link between switches must be shared, care must be taken to
that all applications are compatible with the connection
described in this memo. Applications that hold connections too
on links shared with network traffic may cause loss of
packets or serious degradation of network service
Appendix A -- HIPPI
This section is included as an aid to readers who are not
familiar with the HIPPI standards
HIPPI-PH describes a parallel copper data channel between a
and a Destination. HIPPI transmits data in one direction only,
that two sets are required for bidirectional flow. The
figure shows a simple point-to-point link between two
systems
Renwick & Nicholson [Page 31]
RFC 1374 IP and ARP on HIPPI October 1992
+----------+ +----------+
| | | |
| +--------+ +--------+ |
| | HIPPI | Cable | HIPPI | |
| | +--------------------->| | |
| | Source | | Dest. | |
| System +--------+ +--------+ System |
| X +--------+ +--------+ Y 