As per Relevance of the word switches, we have this rfc below:
Network Working Group J.
Request for Comments: 2067 NetStar, Inc
Category: Standards Track January 1997
Obsoletes: 1374
IP over
Status of This
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation
IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. ANSI X3.222-
1993 (HIPPI-SC[4]) describes the operation of HIPPI
switches. The ANSI committee responsible for these standards
to leave HIPPI networking issues largely outside the scope of
standards; this document describes the use of HIPPI switches as
local area networks
This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and
intended to replace it in the Standards Track. RFC 1374 has been
Proposed Standard since November, 1992, with at least 10
implementations of IP encapsulation and HIPPI switch discipline.
major changes to it are required. However, the ARP part of RFC 1374
has not had sufficient implementation experience to be advanced
Draft Standard. The present document contains all of RFC 1374
for the description ARP, which has been moved into a
document
TABLE OF
1 Introduction............................................. 2
2 Scope.................................................... 3
2.1 Changes from RFC 1374.............................. 3
2.2 Terminology........................................ 4
3 Definitions.............................................. 4
4 Equipment................................................ 5
5 Protocol ................................................ 7
5.1 Packet Format...................................... 7
5.2 48 bit Universal LAN MAC addresses................. 11
5.3 I-Field Format..................................... 12
Renwick Standards Track [Page 1]
RFC 2067 IP over HIPPI January 1997
5.4 Rules For Connections.............................. 13
5.5 MTU................................................ 15
6 Camp-on ................................................. 16
7 Path MTU Discovery....................................... 17
8 Channel Data Rate Discovery.............................. 17
9 Performance.............................................. 18
10 Sharing the Switch....................................... 20
11 References............................................... 21
12 Security Considerations.................................. 21
13 Author's Address......................................... 21
14 Appendix A -- HIPPI Basics............................... 22
15 Appendix B -- How to Build a Practical HIPPI LAN......... 27
1
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 bytes (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 site "ftp.network.com
in the directory "hippi", and may be obtained via anonymous FTP
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
Renwick Standards Track [Page 2]
RFC 2067 IP over HIPPI January 1997
2
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.
may be interoperable on more complex networks as well, depending
the internals of the switches and how they are interconnected
however, these details are implementation dependent and outside
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] and SNAP
2. I-Field
3. Rules for the use of connections
Outside of the scope
1. Address Resolution (ARP
2. Network configuration and
3. Host internal
4. The interface between a host and an outboard
processor
2.1 Changes from RFC 1374
RFC 1374 described the use of ARP on HIPPI, but because
insufficient implementation experience, the description of ARP
been separated from IP encapsulation and moved to an
memo. It may be returned to the standards track in the future
interest and implementations warrant it
Renwick Standards Track [Page 3]
RFC 2067 IP over HIPPI January 1997
RFC 1374's specification of IP over HIPPI has been changed in
document. Certain packet format options, permitted in RFC 1374,
no longer allowed
1. Optional short burst first
2. D1 fill bytes
3. Nonzero D2 offset
That is, the header format is no longer variable and is required
be that which is recommended by RFC 1374.
With these changes, it is possible to send packets which conform
the ANSI standards but not to this memo. Because there are no
1374 implementations in use that used these options, we believe
all existing RFC 1374 implementations are compliant with
requirements of this memo, and there should be no
problems associated with these changes
2.2
In this document the use of the word SHALL in capital
indicates mandatory points of compliance
3
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 IP datagrams. A node may be
Internet host, bridge, router or gateway. This memo uses the
node in place of the usual "host" to indicate that a host might
connected to the HIPPI LAN not directly, but through an
adaptor that does some of the protocol processing for the host
Renwick Standards Track [Page 4]
RFC 2067 IP over HIPPI January 1997
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
4
A HIPPI network can be composed of nodes with HIPPI interfaces,
cables or serial links, HIPPI-SC switches, gateways to
networks
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
Renwick Standards Track [Page 5]
RFC 2067 IP over HIPPI January 1997
The following figure shows a sample HIPPI switch configuration
+-----+
| H 4 |
| +--+--+
| +----+ +----+ +----+ |
| | H1 | | H2 | | H3 | +-++
| +--+ +-++-+ +-++-+ +-++-+ |PP
+---+H5| || || || ++++
| +--+ || || || ||
| +---++--------++--------++------++----+
| | |
| +----+ | HIPPI-SC |
+---+ 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 =
A possible HIPPI
Renwick Standards Track [Page 6]
RFC 2067 IP over HIPPI January 1997
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
complicated on blocking networks than on non-blocking ones
This memo does not take blocking issues into account, assuming
the HIPPI LAN consists of one HIPPI-SC switch or, if the network
more complex than that, it presents no additional problems that
node must be aware of
5
5.1 Packet
The HIPPI packet format for Internet datagrams SHALL conform to
HIPPI-FP and HIPPI-LE draft standards, with further restrictions
imposed by this memo. Because this memo is more restrictive than
ANSI standards, it is possible to send encapsulated IP datagrams
conform to the ANSI standards, but are illegal according to
memo. Destinations may either accept or ignore such datagrams
To summarize the additional restrictions on ANSI standards
here
Any short burst must be the last burst of the packet
Leading short bursts are not permitted
Nonzero values for the HIPPI-FP D2_Offset field are
permitted
The D1_AreaSize SHALL be 3 (64-bit words). No D1 Fill
permitted
Note: Although this document is for IP over HIPPI, the
described below accommodates ARP as well
The HIPPI-FP D1_Area SHALL contain the HIPPI-LE header. The HIPPI-
D2_Area, when present, SHALL contain one IEEE 802.2 Type 1
Unnumbered Information (UI) PDU. Support of IEEE 802.2 XID, TEST
Type 2 PDUs is not required on HIPPI, and Destinations that
these PDUs may either ignore them or respond correctly according
IEEE 802.2 requirements
Renwick Standards Track [Page 7]
RFC 2067 IP over HIPPI January 1997
The length of a HIPPI packet, including trailing fill, SHALL be
multiple of eight bytes as required by HIPPI-LE
+----------+-----------+---------------------+----------- ------+
| | | | 0 - 7 |
| HIPPI-FP | HIPPI-LE | IEEE 802.2 LLC/SNAP | IP . . . bytes |
|(8 bytes) |(24 bytes) | (8 bytes) | fill |
+----------+-----------+---------------------+----------- ------+
HIPPI Packet
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) SHALL be sent as 3.
D2_Offset (3 bits) SHALL be zero
D2_Size (32 bits) Shall contain the number of bytes in
IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present.
SHALL NOT exceed 65,288. This value includes the IEEE 802.2
LLC/SNAP header and the IP datagram. It does not
trailing fill bytes. (See "MTU", below.)
HIPPI-LE
FC (3 bits) SHALL contain zero unless otherwise defined by
administration
Double_Wide (1 bit) SHALL contain one if the Destination
with the sending Source supports 64 bit HIPPI operation.
it SHALL contain zero
Message_Type (4 bits) contains a code identifying the type of HIPPI
LE PDU. Defined values 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
Renwick Standards Track [Page 8]
RFC 2067 IP over HIPPI January 1997
Destination_Switch_Address is a 24-bit field containing
Switch Address of the Destination if known, otherwise zero
If the address comprises less than 24 bits, it SHALL be
justified (occupying the least significant bits) in
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
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 byte of
HIPPI-FP D2_Area
SSAP (8 bits) SHALL contain 170 ('AA'h).
DSAP (8 bits) SHALL contain 170 ('AA'h).
CTL (8 bits) SHALL contain 3 (Unnumbered Information).
Organization Code (24 bits) SHALL be zero
Renwick Standards Track [Page 9]
RFC 2067 IP over HIPPI January 1997
EtherType (16 bits) SHALL be set as defined in Assigned Numbers [8]:
IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h).
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 byte 0 |Message byte 1 |Message byte 2 | . . . |
+---------------+---------------+---------------+--- |
| . . .
|
| -------+---------------+---------------+---------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
Renwick Standards Track [Page 10]
RFC 2067 IP over HIPPI January 1997
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 message
(n) is the number of bytes in the IP message
[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] bytes complete the HIPPI packet to an
number of 32 bit words. The number of fill
is not counted in the data length
IEEE 802.2
The IEEE 802.2 Data SHALL begin in the byte following the
field. Fill bytes SHALL be used following the Data as necessary
make the number of bytes in the packet a multiple of 8.
accordance with HIPPI-FP, the amount of this fill is not included
the D2_Size value in the HIPPI- FP Header
The order of the bytes in the data stream is from higher numbered
lower numbered data signal (left to right) within the HIPPI word,
specified in HIPPI-FP Clause 7, "Word and byte formats." With
1600 megabit/second data rate option (64 bit) bits 32 through 63
on Cable B, so that the four bytes on Cable B come logically
those on Cable A. Within each byte, the most significant bit is
highest numbered signal
5.2 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
Renwick Standards Track [Page 11]
RFC 2067 IP over HIPPI January 1997
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 byte 0 |L|G| ULA byte 1 |
+---------------+---------------+---------------+---------------+
| ULA byte 2 | ULA byte 3 | ULA byte 4 | ULA byte 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 may be helpful for HIPPI
Address resolution, and for distinguishing between multiple
entities that may exist within one node. They may also be used
gateway devices that replace HIPPI hardware headers with the
headers of other LANs. Carrying the ULAs in the HIPPI header
simplify these devices, and it may also help if HIPPI is used as
interface to some future HIPPI based LAN that uses ULAs
addressing
5.3 I-Field
fi 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
accept any value for these bits
Double wide (bit 28) SHALL be set when Source Cable B
connected and the Source wants a 64 bit connection. It
be zero otherwise
Direction (bit 27) should be sent as zero,
Destinations SHALL accept either zero or one and
the Routing Control field accordingly, per HIPPI-SC
Path Selection (bits 26, 25) SHALL be 00, 01, or 11 (binary
at the Source's option. 00 (source route mode)
that the I-field bits 23-00 contain a 24 bit source route; 01
or 11 (logical address mode) indicate that bits 23-00
12 bit Source and Destination Addresses. The value 11
Renwick Standards Track [Page 12]
RFC 2067 IP over HIPPI January 1997
meaningful when more than one route exists from a Source to
Destination; it allows the switch to choose the route.
of 01 forces the switch always to use the same route for
same Source/Destination pair
Camp-on (bit 24) may be 1 or 0; however, a Source SHALL
make consecutive requests without Camp-on to the
Destination while the requests are being rejected.
purpose of this restriction is to prevent a node
circumventing the fair share arbitration mechanism of
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
the Destination
5.4 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
Renwick Standards Track [Page 13]
RFC 2067 IP over HIPPI January 1997
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
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 keep this time as short as possible. For
guideline, assuming parallel HIPPI and a single HIPPI-SC switch,
microseconds permits nearly full HIPPI throughput with full-
packets, and at 60 microseconds the available throughput is
by about 10%. (See "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
the required HIPPI Source Wait states, there should be
delay in the assertion of BURST whenever the Source's
counter is nonzero
3. Make a best effort to ensure that connection durations
not exceed 68 bursts
Renwick Standards Track [Page 14]
RFC 2067 IP over HIPPI January 1997
4. Deassert REQUEST immediately when no packet is
for immediate transmission or the last packet of
connection has been sent
Rules for the
1. Reject all connections if unable to receive packets
This frees the requesting Source to connect to
Destinations with a minimum of delay. Inability to
packets is not a transient condition, but is the state of
Destination when its network interface is not initialized
2. A HIPPI node should be prepared to efficiently
connections and process incoming data packets. While
may be best achieved by not asserting connect unless 68
bursts worth of buffers is available, it may be possible
meet this requirement with fewer buffers. This may be due
a priori agreement between nodes on packet sizes, the
of the interface to move buffers, or other
dependent considerations
3. Accept a connection immediately when buffers
available. The Destination should never delay the
of a connection unnecessarily
4. Once initialized, a Destination may reject
requests 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 set when
Destination does not support the 1600 megabit data rate option
the "Locally Administered" bit is set, the Source is
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
out and abandon attempts to connect; therefore
connection sequences are normal events
5.5
Maximum Transmission Unit (MTU) is defined as the length of the
packet, including IP header, but not including any overhead below IP
Conventional LANs have MTU sizes determined by physical
specification. MTUs may be required simply because the chosen
Renwick Standards Track [Page 15]
RFC 2067 IP over HIPPI January 1997
won't work with larger packets, or they may serve to limit the
of time a node must wait for an opportunity to send a packet
HIPPI has no inherent limit on packet size. The HIPPI-FP
contains a 32 bit D2_Size field that, while it may limit packets
about 4 gigabytes, imposes no practical limit for
purposes. Even so, a HIPPI-SC switch used as a LAN needs an MTU
that Destination buffer sizes can be determined
The MTU for HIPPI-SC LANs is 65280 bytes
This value was selected because it allows the IP packet to fit in
64K byte buffer with up to 256 bytes of overhead. The overhead is 40
bytes at the present time; there are 216 bytes of room for expansion
HIPPI-FP Header 8
HIPPI-LE Header 24
IEEE 802.2 LLC/SNAP Headers 8
Maximum IP packet size (MTU) 65280
------------
Total 65320 bytes (64K - 216)
6 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
Renwick Standards Track [Page 16]
RFC 2067 IP over HIPPI January 1997
7 Path MTU
RFC 1191 [9] 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.
8 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
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 |
+----+-----+-------------------+-------------------+
Renwick Standards Track [Page 17]
RFC 2067 IP over HIPPI January 1997
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
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
9
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
Renwick Standards Track [Page 18]
RFC 2067 IP over HIPPI January 1997
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
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
Renwick Standards Track [Page 19]
RFC 2067 IP over HIPPI January 1997
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
which a Source or Destination can process small packets; such
may further reduce the available throughput if small packets
used
10 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
Renwick Standards Track [Page 20]
RFC 2067 IP over HIPPI January 1997
11
[1] ANSI X3.183-1991, High-Performance Parallel Interface -
Mechanical, Electrical and Signalling Protocol
(HIPPI-PH).
[2] ANSI X3.210-1992, High-Performance Parallel Interface -
Protocol (HIPPI-FP).
[3] ANSI X3.218-1993, High-Performance Parallel Interface -
Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical
Control Protocol Data Units (802.2 Link Encapsulation) (HIPPI
LE).
[4] ANSI X3.222-1993, High-Performance Parallel Interface -
Switch Control (HIPPI-SC).
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/
Sciences Institute, September 1981.
[6] IEEE, "IEEE Standards for Local Area Networks: Logical
Control", IEEE, New York, New York, 1985.
[7] IEEE, "IEEE Standards for Local Area Networks: Logical
Control", IEEE, New York, New York, 1985.
[8] Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2,
1340, USC/Information Sciences Institute, July 1992.
[9] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191,
Stanford University, November, 1990.
12 Security
Security issues are not discussed in this memo
13 Author's
John K.
NetStar, Inc
10250 Valley View
Minneapolis, MN USA 55344
Phone: (612) 996-6847
EMail: jkr@NetStar.
Mailing List: hippi-ext@think.
Renwick Standards Track [Page 21]
RFC 2067 IP over HIPPI January 1997
14 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
+----------+ +----------+
| | | |
| +--------+ +--------+ |
| | HIPPI | Cable | HIPPI | |
| | +--------------------->| | |
| | Source | | Dest. | |
| System +--------+ +--------+ System |
| X +--------+ +--------+ Y |
| | HIPPI | Cable | HIPPI | |
| | |<---------------------+ | |
| | Dest. | | Source | |
| +--------+ +--------+ |
| | | |
+----------+ +----------+
A Simple HIPPI Duplex
Parallel copper cables may be up to 25 meters in length
In this document, all HIPPI connections are assumed to be
HIPPI channels
HIPPI-PH has a single optional feature: it can use a single cable
each direction for a 32 bit parallel channel with a maximum data
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
Renwick Standards Track [Page 22]
RFC 2067 IP over HIPPI January 1997
HIPPI Signal
HIPPI has the following hardware signals
Source to
INTERCONNECT
INTERCONNECT B (64 bit only
CLOCK (25 MHz
DATA (32 or 64 signals
PARITY (4 or 8 signals
Destination to
INTERCONNECT
INTERCONNECT B (64 bit only
The INTERCONNECT lines carry DC voltages that indicate that the
is connected and that the remote interface has power.
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
connections. A connection is always initiated by a Source as
asserts REQUEST. At the same time it puts 32 bits of data on
lines 0-31, called the I-field. The Destination samples the
lines and can complete a connection by asserting CONNECT.
can be transmitted only while both REQUEST and CONNECT are asserted
A Destination can also reject a connection by asserting CONNECT
only a short interval between 4 and 16 HIPPI clock periods (160-640
nanoseconds). The Source knows a connection has been accepted
CONNECT is asserted for more than 16 clocks or it receives a
pulse
Either Source or Destination can terminate a connection
deasserting REQUEST or CONNECT, respectively. Normally
are terminated by the Source after its last Packet has been sent.
Destination cannot terminate a connection without potential loss
data
Renwick Standards Track [Page 23]
RFC 2067 IP over HIPPI January 1997
+------+-------------------------+------+
| Idle | Connected | Idle | . . .
+------+-------------------------+------+
/ \
/ \
/ \
/ \
/ \
+-------+ +-------+ +-------+ +-------+
|I-field| |Packet | |Packet | |Packet |
+-------+ +-------+ +-------+ +-------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+-----+ +-----+ +-----+
|Burst| |Burst|...|Burst
+-----+ +-----+ +-----+
HIPPI Logical Framing
The Source asserts PACKET for the duration of a Packet transmission
deasserting it to indicate the end of a Packet. A sequence of
comprise a Packet. To send a burst, a Source asserts the
signal for 256 clock periods, during which it places 256 words
data on the DATA lines. The first or last Burst of a Packet may
less than 256 clock periods, allowing the transmission of
integral number of 32 or 64 bit words in a Packet
Renwick Standards Track [Page 24]
RFC 2067 IP over HIPPI January 1997
The READY signal is a pulse four or more clock periods long.
pulse signals the Source that the Destination can receive one Burst
The Destination need not wait for a burst before sending
READY if it has burst buffers available; up to 63 unanswered
may be sent, allowing HIPPI to operate at full speed over
of many kilometers. If a Source must wait for flow control,
inserts idle periods between Bursts
+------------------------------------------------+
REQUEST---+ +----
+--------------------------------------------+
CONNECT---------+ +--
+---------------------------------------+
PACKET-------------+ +----
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--
+-------+ +-------+ +-------+ +-----+
BURST--------------+ +-+ +-+ +-+ +--------
DATA------I-field----DATA------DATA------DATA-----DATA----------
HIPPI Signal Timing
Serial
There is no ANSI standard for HIPPI other than the parallel
cable version. However an implementors' agreement exists,
a serial protocol to extend HIPPI signals on optical fiber or
copper cable. Serial links may be used interchangeably with
links to overcome HIPPI distance limitations; they are transparent
the Source and Destination, except for the possibility of
propagation delays
Renwick Standards Track [Page 25]
RFC 2067 IP over HIPPI January 1997
I-Field and Switch
The REQUEST, CONNECT and I-field features of HIPPI-PH were
for the control of switches as described in HIPPI-SC. A switch is
hub with a number of input and output HIPPI ports. HIPPI Sources
cabled to switch input ports, and switch output ports are cabled
HIPPI Destinations. When a HIPPI Source requests a connection,
switch interprets the I-field to select an output port
electrically connects the HIPPI Source to the HIPPI Destination
that port. Once connected, the switch does not interact with
HIPPIs in any way until REQUEST or CONNECT is deasserted, at
time it breaks the physical connection and deasserts its
signals to both sides. Some existing switch implementations
switch connections in less than one microsecond. There is
potential for as many simultaneous connections, each
data at HIPPI speeds, as there are input or output ports on
switch. A switch offers much greater total throughput capacity
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
the lower 24 bits. This string specifies a route over a number
switches. A Destination's address may differ from one Source
another if multiple switches are used
The second format, called Logical Address Mode, defines two 12
fields, Source Address and Destination Address. A Destination's 12
bit Switch Address is the same for all Sources. Switches
have address lookup tables to map 12 bit logical addresses
physical ports. This mode is used for networking
Renwick Standards Track [Page 26]
RFC 2067 IP over HIPPI January 1997
Control fields in the I-field are
L The "Locally Defined" bit, when set, indicates that the I-
is not in the standard format. The meaning of bits 30-0
locally defined
W The Width bit, when set, requests a 64 bit connection
the switch. It is meaningless if Cable B is not installed
the Source. If W is set and either the Source or the
Destination has no Cable B to the switch, the switch
the connection. Otherwise the switch connects both Cable A
Cable B if W is set, or Cable A only if W is clear.
feature is useful if both Source and
implementations can selectively disable or enable Cable B
each new connection
D The Direction bit, when set, reverses the sense of the
Address and Destination Address fields. In other words, D=1
means that the Source Address is in bits 0-11 and
Destination Address is in bits 12-23. This bit was defined
give devices a simple way to route return messages. It is
useful for LAN operations
PS The Path Selection field determines whether the I-
contains Source Route or Address information, and in
Address mode, whether the switch may select from
possible routes to the destination. The value "01"
Logical Address mode and fixed routes
C The Camp-on bit requests the switch not to reject
connection if the selected Destination is busy (connected
another Source) but wait and make the connection when
Destination is free
15 Appendix B -- How to Build a Practical HIPPI
"IP on HIPPI" describes the network host's view of a HIPPI local
network without providing much information on the architecture of
network itself. Here we describe a network constructed
available HIPPI components, having the following characteristics
1. A tree structure with a central HIPPI-SC compliant hub
optional satellite
2. Each satellite is connected to the hub by just one
HIPPI link
Renwick Standards Track [Page 27]
RFC 2067 IP over HIPPI January 1997
3. Serial HIPPI or transparent fiber optic HIPPI extender
may be used in any link
4. Some satellites may be a particular switch product which is
HIPPI-SC compliant
5. Host systems are attached either directly to the hub or
satellites, by single bidirectional links in which both HIPPI
go to the same numbered switch port
Switch Address
Switch addresses use a flat address space. The 12-bit address
subdivided into 6 bits of switch number and 6 bits of port number
11 5 0
+-----------------------+-----------------------+
| Switch Number | Port Number |
+-----------------------+-----------------------+
Logical Address
Switches may be numbered arbitrarily. A given host's
consists of the number of the switch it is directly attached to
the physical port number on that switch to which its input channel
attached
In the singly-connected tree structure, there is exactly one
between any pair of hosts. Since each satellite must be
directly to the hub, the maximum length of this path is three hops
and the minimum length is one. Each HIPPI-SC compliant switch
programmed to map each of the host switch addresses to
appropriate output port: either the port to which the host
directly attached or a port that is linked to another switch in
path to it
Special Treatment of Nonstandard
There is one commercially available switch that was
before the drafting of HIPPI-SC and is not fully compliant. It
in common use, so it is worth making some special provisions
allow its use in a HIPPI LAN. This switch supports only
Source Route mode of addressing with a four bit right shift
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
from normal I-field usage by the hosts that are directly
Renwick Standards Track [Page 28]
RFC 2067 IP over HIPPI January 1997
to it. Hosts attached to standard switches are not affected
For a destination connected to a non compliant satellite,
satellite uses only the least significant four bits of the I-
as the address. Since the address contains the destination'
physical port number in the least significant bits, its port
be selected. Nonstandard switches should be set to disable I
field shifting at the input from the hub, so that the
host will see its correct switch address in the I-field
performing self-address discovery. I-field shifting must
enabled on the satellite for each input port to which a host
attached
Hosts attached to nonstandard satellites must deviate from
normal I-field usage when connecting to hosts on another switch
It is suggested that all host implementations have this
as long as the nonstandard switches remain in use. The host
know, by some manual configuration method, that it is connected
a nonstandard switch, and it must have its "link port" number
that is, the number of the port on the satellite that is
to the hub
The normal I-field format for a 32-bit connection, per
document, 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
and adding the link port number. Camp-on is optional, and the
field is set to 01 or 11 (the host's option) as if the
supported logical address mode. All other I-field bits are set
zero. When the host requests a connection with this I-field,
switch selects a connection through the link port to the hub,
shifts the lower 24 bits of the I-field right by four bits. The
port number is discarded and the I-field passed through to the hub
a proper HIPPI-SC I-field selecting logical address mode
Renwick Standards Track [Page 29]
RFC 2067 IP over HIPPI January 1997
A host on a nonstandard satellite may use the special I-field
for all connection requests. If connecting to another host on
same satellite, this will cause the connection to take
unnecessarily long path through the hub and back. If an
is desired, the host can be given additional information to allow
to use the standard I-field format when connecting to another host
the same switch. This information could consist of a list of
other hosts on the same switch, or the details of address formation
along with the switch number of the local satellite, which
allow the host to analyze the switch address to determine whether
not the destination is on the local switch. This optimization
fairly complicated and may not always be worthwhile
Renwick Standards Track [Page 30]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
