HIPPI uses source to refer to the transmitting endpoint, host, network interface, or program.

It uses destination to refer to the receiving endpoint, host, network interface, or program.

A word in the HIPPI environment can be either 4 bytes (32 bits) or 8 bytes (64 bits), depending on the HIPPI implementation. When not clarified, both definitions apply. For example, “A burst consists of 256 words” means that a burst can be either 1024 bytes (256 words times 4 bytes) or 2048 bytes (256 words times 8 bytes).

HIPPI is an extremely fast, simplex point-to-point protocol. HIPPI provides for transmission at 800 or 1600 megabits per second.^[1] Before data can be sent from one HIPPI network interface (endpoint) to another, there must be both a physical link and an open connection between them. The physical link is made up of one or more 25-meter sections of copper cable. Each section connects two HIPPI nodes. The nodes can be endpoints or intermediate HIPPI switches. The open connection is an agreement for data transfer from one endpoint to another, and is arranged with an exchange of signals. Once a connection is open, the entire physical link is dedicated to one-way communication from the source to the destination.

Figure 1-1 illustrates a configuration of HIPPI equipment with nine endpoint-to-endpoint links (listed below) of which three can be simultaneously active (engaged in open connections):

An open connection consists of an exchange of signals between a source and a destination. During this exchange, the destination agrees to accept data exclusively from the source. Each endpoint-to-endpoint link supports one connection (that is, HIPPI is point to point). It is common for an interface's source and destination channels to have open connections with different hosts (for example, A-source connected to B-destination while A-destination is connected to C-source). To move data in both directions between two hosts, two endpoint-to-endpoint links and two connections are needed between the two hosts.

Unlike Ethernet, 802.5 Token Ring, or FDDI, HIPPI does not use a shared medium. Once a connection is established, the cable between the two HIPPI interfaces contains only packets transmitted by the source (that is, HIPPI connections are simplex). HIPPI packets may be seen by intermediate switches but not by other host interfaces. When one packet has been sent, the connection may be closed or kept open so that additional packets can be sent; however, each endpoint may not participate in another connection until the current one has been closed.

HIPPI communication is controlled by three basic functions: connection control, packet and flow control, and routing control (pertinent only when one or more switches are involved). Each of these is discussed separately in the subsections that follow.

One of the first things any HIPPI endpoint does upon startup is to assert its two outgoing INTERCONNECT signals and to look for assertion of its two incoming INTERCONNECT signals. Each channel (the source and the destination) has both incoming and outgoing INTERCONNECT signals. When both signals on a channel are asserted, the physical link between the local system and the system at the other end is ready for use. When the other system is a switch, the exchange of INTERCONNECT signals occurs between the endpoint and the switch, not between endpoints.

Before a source (transmitting) HIPPI network interface can send a packet, it must open a connection to one destination HIPPI endpoint. The source interface is always the initiator for opening the connection. To open a connection, the sender issues a connection request by asserting the REQUEST signal on the link. Each connection request includes an I-field (described in the section “The I-field”). The I-field mainly contains routing information, used by any switches encountered along the path to the destination.

The destination endpoint accepts a connection by asserting its CONNECT signal in response to the request. If the destination endpoint is unwilling to accept the connection or if there is a problem with the connection request (for example, bad parity on the I-field or incompatible word size), the connection request is denied (that is, acknowledged, then rejected). The transmitter must wait and try again later or forgo the communication. If the destination is unreachable (for example, a broken physical link, a powered-down or dysfunctional network interface), there is no response and the source program times out.

When a switch exists between the source and destination, the source receives its connection rejections from the switch, not directly from the destination. The rejection can be caused by any of the following conditions, and it is not possible to distinguish among them (except as explained below):

A feature is available that allows the source to be informed of rejections that are due to error conditions (items 1-3 above) but not to be bothered when the rejection is due to a busy link (item 4). This feature is called camp-on. By setting the camp-on bit in the I-field, the source can program the switches to hold onto the connection request until the busy link to the destination becomes available.

When the camp-on bit is set, the first switch enqueues the connection request if it finds any link along the path to the destination busy. The switch periodically checks to see if the link has become available. When the link becomes available, it sends the connection request. A switch continues to wait until it sends the REQUEST to the ultimate destination endpoint or until the source aborts the connection request. If a number of sources are all trying to send data through the same link, the camp-on feature ensures fair (first come, first served) access to the link.

Once opened, a HIPPI connection may be kept open for as long as the two endpoints maintain it. Either endpoint may terminate the connection at any time; however, the source network interface is usually the initiator.

Once a connection is open, one or multiple packets may be sent. The destination indicates it is ready to receive data by sending a READY signal to the source endpoint. Each READY allows the source to transmit one HIPPI burst (as explained below). All HIPPI source endpoints are required to be capable of enqueuing a minimum of 63 READYs. There is no minimum requirement for a destination's ability to generate READYs.^[2] By sending ahead and enqueuing READYs, the two endpoints can optimize the throughput on their connection.

The source delineates its packets with the PACKET signal: at the beginning it asserts the PACKET signal, and at the end it deasserts the signal. A HIPPI packet consists of one or more bursts, as illustrated in Figure 1-2. Each burst contains 256 words, except in the case where the burst is short (as described below). The size of each word depends on the source's data bus (32 or 64 bits, as indicated by a bit in the I-field).^[3] At the end of each burst, the source generates a checksum (LLRC) so that the destination can detect any errors in the received data; in addition, each word has four bits of parity for error checking.

Figure 1-2. HIPPI Packets and Bursts

The HIPPI protocol requires very small waiting periods between packets and between bursts. These required periods are counted in nanoseconds and are imperceptible to the user; however, in normal operation there may be noticeable pauses between bursts (for example, when the source is waiting to receive a READY).

As long as the source has READYs, it can transmit data as fast as it is capable of transmitting (but no faster than the protocol allows: 25 million words per second). When the sender has sent all the data for one packet, it indicates the end of the packet, using the PACKET signal. Indicating the end of the packet is necessary because HIPPI allows packet size to be undefined (indeterminate) at the start of the packet. A sender could essentially send an infinite–sized packet by keeping the PACKET signal asserted at all times.

A packet's first burst often contains some kind of header (for example, a HIPPI-FP header as described in “The FP Header”). The first burst can contain header only, or header and user data. In other words, the first words of user data can be in the first burst or the second. If the source program is generating HIPPI-FP packets, it can indicate the location of the packet's first word of user data by setting the B bit in the HIPPI-FP header.

Either the first or the last burst of a packet (but not both) can be less than 256 words. This burst is referred to as a short burst. Usually, the last burst is the short one. When the first burst is the short one, it contains only the header and, optionally, control information. The first word of the packet's user data is, in this case, located in the second burst, and the final burst may be padded to meet the 256-word length requirement. When the last burst is the short one, the packet's final burst never needs to be padded and the first word of user data may be included in the first burst.

Once the end of the packet has been indicated, the source has the option of keeping the connection open to transmit additional packets or of closing the connection.

The I-field contains HIPPI routing information in its 24-bit Routing Control field. This information is interpreted only by intermediate systems (switches); the Routing Control information does not need to be interpreted when the connection is directly between two endpoints.

The addresses in a Routing Control field can be in “logical addressing” or “source addressing” format. The format is indicated by the Path Selection bits of the I-field. The two formats cannot be used simultaneously in one I-field; however, both formats can be used simultaneously in one HIPPI local area network (LAN).

---

Note: The word source in “source addressing format” does not mean that the address is the source's address; it refers to the fact that the address, supplied by the source endpoint, defines the complete path (route).

---

Logical Addressing

With logical addressing, the Routing Control field contains two 12-bit addresses: a destination (receiver's) address and the source (sender's) address, as illustrated in Figure 1-3. The order in which the addresses are placed within the field is defined by the I-field's Direction bit, as illustrated in Figure 1-3.

Figure 1-3. Routing Control Field With Logical Addressing

When a HIPPI LAN uses logical addressing, each HIPPI network interface (endpoint) within the LAN is assigned an address that is unique within that LAN. One address can be used for both the source and destination channels of a network interface, if desired. Assignment of these addresses is a local matter; the addresses do not need to be unique outside the particular HIPPI network. Logical addresses have the formats described in Table 1-1. Some of the addresses are reserved for special purposes. 

Table 1-1. Logical Addressing Formats

Logical Address (binary)	Number of Addresses	Usage
xxxx x0xx xxxx	4032	Endpoint addresses
1111 110x xxxx	32	Local assignment to network services
1111 111x xxxx	32	Reserved for global assignment
1111 1111 1111	1	Address is unknown

Each switch maintains a “map” of its LAN and uses a routing table to select the path along which to open a connection for each request. For example, Figure 1-4 illustrates a scenario where two paths are available between endpoints A and B. When endpoint A requests a connection to endpoint B, switch 1 can select either of these paths.

Figure 1-4. Routing With Logical Addressing

The 12 bits make it possible to create 4096 unique addresses. The HIPPI-SC standard reserves 64 of these addresses, leaving 4032 addresses available for local assignment to HIPPI end points. 4032 is the maximum number of destination endpoints that can exist on one HIPPI LAN using logical addressing.

Source Addressing

The addresses used for source addressing are of variable lengths, from 1 to 24 bits. When the Path Selection bits in the I-field indicate that source addressing is being used, the Routing Control field contains a list of port identifiers, as illustrated in Figure 1-5. The I-field's Direction bit determines the order in which the port identifiers are placed within the field and the alignment of (placement for) the addresses, as illustrated in Figure 1-5.

Figure 1-5. Routing Control Field (As Created by Sender) With Source Addressing

Each port identifier uniquely identifies one port within a switch. A port is a pair of physical links: both a source and a destination. For example, a 4x4 switch has 8 physical links to 4 systems, and for this it uses 4 port identifiers, as illustrated in Figure 1-6. Port identifiers are unique among all the ports on the same switch, but not among all the ports within the LAN. For example, a LAN with 5 switches might easily have 5 port identifiers of “1.” Figure 1-6 is an example of the port identifiers used in a LAN with 2 switches.

Figure 1-6. Switches and Port Identifiers

A Routing Control field in source address format is interpreted as a series of “stepping stones” leading to the destination in the following manner:

1. The first switch (the one attached to the source endpoint) reads the first port identifier, opens a connection at that outgoing port, and sends the I-field (that is, the connection request).

2. If the system at the end of that physical link is another switch, it reads the second port identifier, opens a connection at that outgoing port, and sends the I-field.

3. And so on, until the receiving system is the destination endpoint.

When the port identifiers are followed sequentially, they create the path between the two endpoints. Each path (address) consists of a list of all the outgoing ports through which the connection request must pass in order to reach the destination. For example, in the simplest configuration, where one switch exists between two network interfaces, the address consists of one port identifier: the one to which the receiving interface is connected, as illustrated by Example 1 in Figure 1-7. When two switches exist between the interfaces, the address consists of two port identifiers, as illustrated by Example 2 of Figure 1-7.

Figure 1-7. Port Identifiers for Source Addressing

The Direction bit in the I-field defines whether each port identifier should be read from the most significant or least significant end of the Routing Control field. For example, Figure 1-8 illustrates two addresses that endpoint A might use to open a connection with B.

Figure 1-8. Routing With Source Addressing

Each HIPPI host within the LAN maintains a table of paths (addresses in source addressing format) for reaching each of the other endpoints. With each of its connection requests, a source attaches one of these paths, thus indicating how to reach the destination. The path is completely defined by the sending endpoint.

Unlike logical addresses (which are not altered enroute to the destination), addresses in source addressing format are changed by each switch that handles the I-field. The source program creates a list of outgoing port numbers that define a path from the sender to the receiver. By the time the packet arrives at its destination, the address has been altered so that it defines the return path (that is, the path from the receiver back to the sender). This change is brought about by each switch removing the outgoing port identifier that it reads, shifting the remaining bits into alignment, and adding an incoming port identifier (that is, the port through which the I-field just arrived), as illustrated in Figure 1-9.

Figure 1-9. How Switches Alter Source Addresses

A destination program can copy a received Routing Control field into its own I-field and simply change the setting of the Direction bit to open a return connection, thus bypassing the table lookup procedure. Normally, the source that first creates the Routing Control field sets the D bit to zero and places the address bits in the least significant positions of the Routing Control field. The receiver changes the setting for the D bit and uses the received Routing Control field exactly as it is received. In this manner, the port identifier labeled Last Incoming Port # in Figure 1-9 becomes the First Outgoing Port # for the return connection.

Port identifiers can be one to six bits in length. The number of bits varies from switch to switch. The size of the port identifier is the number of bits needed to uniquely identify all the possible ports on a switch. For example, a 4x4 switch has four ports and requires at least two–bit port identifiers (binary port identifiers 00, 01, 10, and 11). If a switch is capable of being enlarged, it may use large–sized port identifiers (for example, five or six bits) to avoid a reconfiguration of all the LAN's routing tables when the switch is upgraded.

The I-field's 24-bit Routing Control field limits the number of port identifiers that can be contained in an address, as summarized in Table 1-2.  

Table 1-2. Maximum Number of Port Identifiers in Routing Control Field

Number of Bits Used in Port Identifier	Maximum Number of Port Identifiers Possible in Routing Control Field
1	24
2	12
3	8
4	6
5	4
6	4

The I-field is defined by the HIPPI-SC standard. The format for the 32-bit HIPPI I-field (also called CCI) is shown in Figure 1-10, and its fields are explained in Table 1-3.

Figure 1-10. I-field Format

The FP header is defined by the HIPPI-FP standard. When a HIPPI endpoint is HIPPI-FP conformant, all the packets it transmits and/or receives (without error) are HIPPI-FP packets. The first burst of each of its transmitted packets contains an FP header, and it looks for an FP header in the first burst of each received packet. A HIPPI-FP packet consists of three segments, listed below and illustrated in Figure 1-11. Each segment is eight-byte aligned (that is, contains an integral number of 64-bit words).

The 64-bit FP header describes the HIPPI packet using six fields, illustrated in Figure 1-12 and described in Table 1-4.

Figure 1-12. FP Header Format

Figure 1-13 illustrates a HIPPI-FP packet with D1 data where the first burst of the packet contains only the FP header and the D1 data. Figure 1-14 illustrates some of the HIPPI-FP packets that are commonly created. Examples 2, 3, and 4 in Figure 1-14 illustrate how the D1 area can be used to position the D2 data in the second burst.

Figure 1-13. Sample HIPPI-FP Packet

Figure 1-14. Some Common HIPPI-FP Packets

The signals at the HIPPI-PH layer of each physical link are used for controlling the connection, packet boundaries, and data flow. These signals are described in Table 1-5 and illustrated in Figure 1-15. Within the figure, the signals are numbered to represent the order in which they are asserted when power is first applied at the two endpoints. The two INTERCONNECT signals are not dependent on any other signal; they are asserted as the HIPPI hardware receives power and becomes active. Each of the other signals is asserted only when all the signals before it have been observed.

Figure 1-15. HIPPI Signals Used on Each Point-to-Point Link

A basic (non–networked) HIPPI configuration consists of two endpoints, one sending and the other receiving, as shown in Figure 1-16.

Figure 1-16. Basic HIPPI Configuration

To exchange data in both directions, two physical links and two connections are required between the two endpoints, as illustrated by the examples in Figure 1-17. Each endpoint's source channel must open a connection with the destination of the other endpoint.

Figure 1-17. Three Variations of the Basic Configuration

The IRIS HIPPI network interface board has two channels (visible at the I/O panel). It treats each one as a separate entity, so each IRIS HIPPI network interface supports two autonomous, simultaneous connections: one sending and one receiving. The two connections can be to two different endpoints (as shown by the examples on the right in Figure 1-17) or to the same endpoint (as illustrated by the example on the left in Figure 1-17). IP communication over HIPPI requires the latter configuration.

One or more HIPPI switches may be placed along the endpoint-to-endpoint link, making it possible to configure a number of endpoints into a HIPPI local area network (LAN, or fabric). Configuring the endpoints in this way does not alter the fact that each communication is a point-to-point connection. The switches are cross switches, not “routers.”

When a switch is included in a HIPPI configuration, each endpoint has a number of hosts with which it can communicate (one at a time). Figure 1-18 illustrates a HIPPI LAN with one switch. The switch in this illustration is a 4 x 4, meaning that the switch can have four systems (8 HIPPI channels) attached to it. The switch supports four simultaneous connections. For example, in Figure 1-18, any one of the following connection scenarios could be occurring at any single point in time:

Figure 1-19 illustrates a LAN with multiple switches, and Figure 1-20 illustrates a complex HIPPI LAN including a long-distance fiber optic link and multiple ports between switches to improve connection setup time by reducing the probability of encountering a busy link.

Figure 1-19. HIPPI LAN Configurations With Multiple Switches

Figure 1-20. Complex HIPPI LAN Configuration

The maximum number of switches and endpoints within a LAN is limited by three factors:

The IRIS HIPPI driver provides access and control of the HIPPI subsystem to upper-layer applications. The upper layer-applications that are shipped with the IRIS HIPPI product are the IRIS HIPPI-LE module serving the IP network stack, and the IRIS HIPPI utilities. Upper-layer programs can also be developed by customers, using the IRIS HIPPI application programming interface.

Customer-developed applications can define their own upper-layer protocol (ULP) and can program the IRIS HIPPI driver to implement HIPPI-FP, or they can bypass the HIPPI-FP layer and access the HIPPI protocol directly at the HIPPI-PH layer. Refer to the IRIS HIPPI API Programmer's Guide for complete details.

The rest of this section describes the IRIS HIPPI-LE upper-layer protocol implementation.

This section describes how the IRIS HIPPI driver and the HIPPI-LE module handle HIPPI I-fields, HIPPI-FP headers, and 802.2 encapsulation items. There are separate sections for transmission and reception.

On Transmission

The HIPPI-LE module obtains the I-field for each destination from a lookup table that is initialized at startup time from the /usr/etc/hippi.imap file. It obtains this I-field value before programming the IRIS HIPPI driver to make a connection request. The hippi.imap file maps IP addresses (or host names) to 32-bit values that are used as I-fields. The software uses each I-field value exactly as read from the file, as summarized in Table 1-8. It is the responsibility of the system administrator to ensure that the values in the lookup table are appropriate for the site's configuration.

Table 1-8. I-field Recommended for Use With IRIS HIPPI-LE

Field	Value Recommended for HIPPI-LE	Comments
L	0	0=HIPPI-SC compliant; 1=local format for I-field. A site may use any value.
VU	0	A site may use any value.
W	0	0=32 data bus. No other setting is supported by the IRIS HIPPI board.
D	0	0=Least significant bits contain address for next hop; 1=address is placed in most significant bits. A site may use any setting.
PS	any setting	A site may use any of the addressing formats.
C	1	1= camp-on; 0=do not camp-on. This setting makes the HIPPI network more efficient; however, a site may use any setting.
Routing Control	any setting	A site may use any settings.

Once the connection has been opened, the HIPPI-LE module creates a HIPPI packet in the format illustrated in Figure 1-21. This packet conforms with the HIPPI-FP standard and the RFC 1374 guidelines.

Figure 1-21. HIPPI Packet Created by IRIS HIPPI-LE

The IRIS HIPPI-LE module creates the HIPPI-FP header with the values summarized in Table 1-9. 

Table 1-9. FP Header Created by IRIS HIPPI-LE ULP

Field	Value Used	Comments
ULP-id	4 = HIPPI-LE	As defined by HIPPI-FP.
P bit	1 = D1 area is included in this FP header	D1 area contains the HIPPI-LE header as defined by HIPPI-LE.
B bit	0 = D2 data is included in first burst	As specified by RFC 1374.
D1 Size	3 = three 64-bit words (that is, 24 bytes)	As defined by HIPPI-LE.
D2 Offset	0
D2 Size	Up to 64 kilobytes.	Maximum IP packet as defined by the Internet Protocol.

The IRIS HIPPI-LE module creates the HIPPI-LE header with the values summarized in Table 1-10. The HIPPI-LE header becomes the D1 data set for the HIPPI packet. 

Table 1-10. D1 Data (HIPPI-LE Header) Created by IRIS HIPPI-LE

Field	Size	Value Used	Comments
FC	3 bits	0	As defined by HIPPI-LE and restated in RFC 1374.
Double Wide	1 bit	0 = 32 bit data bus
Message Type	4 bits	0 = data
Destination Switch Address	24 bits	0
Destination Address Type	4 bits	0
Source Address Type	4 bits	0
Source Switch Address	24 bits	0
Reserved	16 bits	0
Destination IEEE Address	48 bits	0
LE Locally Administered	16 bits	0

The IRIS HIPPI-LE module creates the 802.2 headers (LLC and SNAP) with the values summarized in Table 1-11. This information occupies the initial bytes of the D2 data within the HIPPI packet. 

Table 1-11. IEEE 802.2 Header (First Bytes of D2) Created by IRIS HIPPI-LE

Field	Size (bits)	Value Used	Comments
SSAP	8	170 decimal	As defined by IEEE 802.2 standard for Logical Link Control and restated in RFC 1374.
DSAP	8	170 decimal	Same as above.
CTL	8	3	Same as above.
Organization Code	24	0	Same as above.
EtherType	16	2048 decimal	Same as above.

On Reception

The IRIS HIPPI driver accepts all connection requests, and accepts all packets containing FP headers with known ULP-ids, thus supporting customer-developed, upper-layer applications. The I-field for the connection request is not interpreted. This process is summarized in Table 1-12. 

Table 1-12. I-field Accepted by IRIS HIPPI Driver for HIPPI-LE ULP

Field	Recommended Values	Comments
L	0 = HIPPI-SC compliant	Content is ignored.
VU	any value	Content is ignored.
W	0 = 32 data bus	Content is ignored.
D	any value	Content is ignored.
PS	any value	Content is ignored.
C	any value	Content is ignored.
Routing Control	any value	Content is ignored.

Once a connection has been opened, the IRIS HIPPI driver places each incoming HIPPI packet on the input queue for the ULP-id indicated in the FP header. Incoming HIPPI packets must have the format illustrated in Figure 1-22. If the ULP-id is not known to the driver, the packet is dropped (that is, accepted then discarded). Packets with a ULP-id of 4 are enqueued for the HIPPI-LE module.

Figure 1-22. HIPPI Packets that IRIS HIPPI Driver Passes to HIPPI-LE

The HIPPI driver interprets only the FP header. All further processing of the HIPPI packet (including the various protocol headers) is done by the reader of the input queue (for example, HIPPI-LE).

On reception, the IRIS HIPPI driver handles HIPPI-FP headers as summarized in Table 1-13. 

Table 1-13. FP Header Accepted by IRIS Driver for HIPPI-LE ULP

Field	Values Accepted Without Generating an Error	Comments
ULP-id	4 = HIPPI-LE	As defined by HIPPI-FP. For other ULP-ids, see the IRIS HIPPI API Programmer's Guide for details.
P bit	1	If set to 1, the driver interprets the D1 area as a HIPPI-LE header. If set to 0, the packet is discarded.
B bit	any value	For applications using the HIPPI-FP access method, the IRIS HIPPI driver passes the D1 data to the input queue reader as a separate item from the D2 data.
D1 Size	3 = three 64-bit words /    24 bytes	As defined by HIPPI-LE. If the value is different, the packet is discarded.
D2 Offset	any value
D2 Size	up to 64 kilobytes	As defined by Internet Protocol. If size is greater than 64 kBytes, the packet is discarded.

The IRIS HIPPI-LE upper layer program handles received D1 data (the HIPPI-LE header) as summarized in Table 1-14. 

Table 1-14. D1 Data Accepted by IRIS HIPPI-LE ULP

Field	Values Accepted Without Generating an Error	Comments
FC	0	As defined by HIPPI-LE. If the value is different, an error is generated.
DW	0 = 32 bit data bus	If set to 1, an error is generated.
MT	0 = data	If not 0 (data), an error is generated.
Dest_Sw_Addr	any value
Dest_Addr_Type	any value
Src_Addr_Type	any value
Src_Sw_Addr	any value
Dst_IEEE_Addr	any value
LE_Locally_Adm	any value
Src_IEEE_Addr	any value

The IRIS HIPPI-LE module also handles the 802.2 headers as summarized in Table 1-15. 

Table 1-15. IEEE 802.2 Headers Accepted by HIPPI-LE ULP

Field	Size (bits)	HIPPI-LE Default	Comments
SSAP	8	170 decimal	As defined by the IEEE 802.2 standard and restated by RFC 1374. If the received value is different, an error is generated.
DSAP	8	170 decimal	Same as above.
CTL	8	3	Same as above.
Organization Code	24	0	Same as above.
EtherType	16	2048 decimal	Same as above.