This chapter is an introduction to the High-Performance Parallel Interface (HIPPI) protocol. The chapter provides an brief introduction to HIPPI, a description of the HIPPI protocol, some common configurations of HIPPI equipment, and how to obtain official HIPPI documentation.
This section provides a brief introduction to HIPPI.
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. 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):
A-source transmitting to A-destination (itself), B-destination, or C-destination
B-source transmitting to A-destination, B-destination (itself), or C-destination
C-source transmitting to A-destination, B-destination, or C-destination (itself)
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):
The destination is malfunctioning.
The destination refuses to accept the requested connection.
The connection request has an error.
Asection of the physical link to the destination is busy (currently engaged in another connection).
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. 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). 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.
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).|
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.
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
Number of Addresses
xxxx x0xx xxxx
1111 110x xxxx
Local assignment to network services
1111 111x xxxx
Reserved for global assignment
1111 1111 1111
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.
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.
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.
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.
A Routing Control field in source address format is interpreted as a series of “stepping stones” leading to the destination in the following manner:
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).
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.
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.
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.
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.
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
Maximum Number of Port Identifiers Possible in
This section describes the format for the HIPPI I-field and FP header.
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.
Table 1-3. Fields of the HIPPI I-field
Local or Standard Format:
0=Bits 30:0 of I-field conform to the usage described in this table.
1=Bits 30:0 are implemented in conformance to a private (locally-defined) protocol.
Vendor Unique Bits:
Vendors of end-system HIPPI equipment may use these bits for any purpose. Switches do not alter or interpret these bits.
0=The data bus of the transmitting (source) HIPPI is 32 bits wide for 800 megabits/second transmission.
1=Source's data bus is 64 bits wide for 1600 megabits/second transmission.
0=Least significant bits of Routing Control field contain the destination address for the current switch to use.
1=Most significant bits of Routing Control field contain the destination address for the current switch to use.
01=Logical routing. Switch must select first route from a list of routes.
11=Logical routing. Switch selects any (or best) route from its list.
0=Switch rejects connection request immediately if port to destination is busy.
1=Switch holds connection request if port to destination is busy and establishes connection when the port becomes free or when source aborts the request.
This field contains addressing/routing information. The contents are in source routing or logical routing format, as indicated by the PS field.
For source routing, the field contains a list of switch port identifiers that, when followed, lead to the destination.
For logical addressing, the field contains two 12-bit addresses (receiver's and sender's) that are used by the intermediate switches to select a route from a table.
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).
Framing Protocol header:
This area contains the 64-bit HIPPI-FP header, described in more detail in Table 1-4 on page 19.
This optional area, if present, must be completely contained in the first burst. It may contain control information (the D1 data set), it may be defined for padding purposes only, or it may serve both of these functions. The D1 area can be 0 to 255 words in size; however, regardless of the word size used by a HIPPI implementation, the D1 area must contain an integral number of 64-bit words. So, for a 64-bit implementation, the D1 area can have up to 255 words. For a 32-bit implementation, the D1 area can have up to 254 words.
The D1 data set (located within the D1 area) is optional. The maximum size of any D1 data set is 1016 bytes (that is, 254 32-bit words), thus allowing the FP header (8 bytes) and D1 data to fit in the first burst of any HIPPI implementation (for example, a burst made of 32-bit words). The content and format of the D1 data is locally defined and the data must be self-defining. For example, each upper layer application (with its own ULP-id) could use a different format and length for its D1 data.
The optional D2 area contains the user/application data. This area can be 0 to 4-gigabytes minus 1-byte in size, or it can be defined as indeterminate. The size of this area must be an integral number of 64-bit words. The area may contain padding (an offset and possibly filler).
The 64-bit FP header describes the HIPPI packet using six fields, illustrated in Figure 1-12 and described in Table 1-4.
Table 1-4. Fields of the HIPPI-FP Header
The 8-bit upper layer protocol identification field identifies a system's upper layer protocols. A transmitting application uses this number to specify the upper layer protocol of the intended recipient of the packet. A receiving HIPPI subsystem can use this number to demultiplex incoming packets among a number of upper layer protocols (or applications) and to determine whether an intended recipient is known or not.
The 1-bit present bit indicates whether or not the packet contains D1 data. Note that the D1_Area may be present, even when there is no D1 data.
The 1-bit burst boundary bit indicates which burst contains the first byte of D2 data. D2 data can be included in the first burst or it can start with the first word of the second burst.
D1 Area Size
The 8-bit D1 area size field indicates the number of 64-bit words in the D1_Area of this packet. The area does not necessarily contain valid data; that is, the area may be defined for padding purposes only. Note that the size is always stated in 64-bit words, regardless of the implementation's word size.
The 3-bit D2 offset field indicates the number of bytes between the last byte of D1 data and the first byte of D2 data.
D2 Data Size
The 32-bit D2 data size field indicates the number of bytes of D2 data included in this packet. Bytes of offset or fill are not included in this count.
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.
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.
Generated by the source
on this physical link
When asserted, indicates source is attached and ready for action. This signal is sometimes referred to as SDIC.
When asserted, indicates source is requesting a connection to be opened. This signal is accompanied by an I-field.
When deasserted, indicates the source is closing the connection (if one is open) or aborting the connection request (if no connection is currently open).
When asserted, indicates a packet is in progress.
When deasserted, indicates the end of a packet.
This signal does not indicate that any data is being sent; it only delineates the boundaries of a packet.
When asserted, indicates data is being sent. This signal is accompanied by one burst of data.
When deasserted, no data is being sent.
Generated by the
destination on this
When asserted, indicates destination is attached and ready for action. This signal is sometimes referred to as DSIC.
When asserted, indicates destination is accepting the connection (opening a connection in response to a REQUEST signal).
When deasserted, indicates destination is closing the connection (if one is open) and is now available for a new connection.
When pulsed, indicates destination can accept (has buffer space available) one burst of data. Destination can send any number of these to source; however, the source is required by the HIPPI-PH standard to queue only 63.
This section describes some of the common configurations of HIPPI equipment. Because HIPPI is a simplex point-to-point protocol, only one source can transmit data onto the transport medium (cable) between two endpoints. Two physical links (one cable for each source) are required for bidirectional communication. This aspect of HIPPI makes it quite different from protocols such as Ethernet, FDDI, or 802.5 Token Ring.
A basic (non–networked) HIPPI configuration consists of two endpoints, one sending and the other receiving, as shown in Figure 1-16.
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.
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:
A and D could be exchanging TCP/IP traffic. There would be two connections open between them. C and D could be doing the same. This scenario opens all four possible connections.
A could be transmitting to B, while B transmitted to C, C to D, and D to A. This scenario also opens four connections.
A and C could be exchanging bidirectional traffic. D could be transmitting to B. Only three connections are open in this scenario.
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.
The maximum number of switches and endpoints within a LAN is limited by three factors:
When logical routing is used, the 12-bit HIPPI address (half of the Routing Control field) limits the number of unique endpoint addresses to 4096. It is possible for a site to implement this number of networked HIPPI endpoints; however, to be compliant with the HIPPI-SC standard, 64 reserved addresses should not be assigned to local endpoints (that is, hosts). This limits the number of endpoints to 4032 per LAN. There is no limit to the number of switches when logical routing is used.
When source routing is used, the I-field's 24-bit Routing Control field limits the number of port identifiers that can be included in the list. The exact number depends on the sizes of the port identifiers used by the switches along the specific endpoint-to-endpoint path, as explained in “Source Addressing.” Each port identifier in the Routing Control field represents one switch along the path. Table 1-6 summarizes the maximum number of switches along any point-to-point path within a HIPPI LAN, assuming that all switches along that path use port identifiers of the same size. (This assumption does not reflect actual site configuration practices, but is useful here for illustration of a point.) When source routing is used, the number of switches and endpoints that are possible is not limited; however, the number of switches between any two endpoints within the LAN is limited. This limit affects the configuration of the LAN.
If a LAN is built according to the guidelines in Appendix B of RFC 1374, the recommended maximum number of hops (switches) between any two endpoints is three. This limit has major implications for the structure and size of a HIPPI LAN. The structure is limited to a single hub switch with satellite switches attached to the hub's ports, but no switches attached to any satellite ports. Figure 1-19 shows an example of an RFC 1374–compliant LAN. Table 1-7 summarizes the maximum number of switches and endpoints possible for a LAN in which switches of only one size are used throughout the LAN.
Table 1-6. Maximum Number of Switches Along Any Single Point-to-PointPath When Using Source Addressing
Number of Bits Used for All Port IDs in Routing Control Field
Max. Number of Switches Along Any Single Point-to-Point Path
Table 1-7. Maximum Number of Switches and Endpoints on a LAN Built in Accordance With RFC 1374, Appendix B Guidelines
Size of All Switches Within LAN
4 x 4
16 x 16
32 x 32
64 x 64
5 switches /
9 switches /
17 switches /
33 switches /
65 switches /
The documents listed below provide the official definitions of what HIPPI is and how it works.
The HIPPI Mechanical, Electrical, and Signalling document defines the standard for the physical layer: electrical and mechanical aspects of HIPPI cables, as well as the behavior of HIPPI physical interfaces (including the HIPPI signals, like SDIC, DSIC, REQUEST, CONNECT, READY, PACKET, and BURST).
The HIPPI Physical Switch Control document defines the standard for switch behavior, routing methods, and connection management. The HIPPI I-field is defined by this standard.
The HIPPI Framing Protocol document defines the standard for data framing issues: how a packet is formed, how its data contents are described and interpreted. The HIPPI-FP packet (FP header, D1_Data, and D2_Data) is defined by this standard.
The HIPPI Encapsulation of ISO 8802-2 (IEEE 802.2) Logical Link Control Protocol Data Units (HIPPI-LE) standard defines the method for encapsulating (and thus interoperating with) 802.2 compliant data link layers such as FDDI, 802.5 Token Ring, and CSMA/CD (Ethernet).
ANSI HIPPI-IPI-3 for Disk
The HIPPI Intelligent Peripheral Interface—Device Generic Command Set for Magnetic and Optical Disk Drives standard defines an upper–layer protocol for interfacing disks to the HIPPI subsystem.
ANSI HIPPI-IPI-3 for Tape
The HIPPI Intelligent Peripheral Interface—Device Generic Command Set for Magnetic Tape Drives standard defines an upper–layer protocol for interfacing tapes to the HIPPI subsystem.
IP and ARP on HIPPI, by J. Renwick and A. Nicholson (October 1992) defines the protocol for using the IP suite of network and transport layer protocols over HIPPI.
The ANSI documentation for HIPPI standards is maintained by the American National Standard of Accredited Standards Committee (ANSI X3T9.3). Copies of the ANSI standards listed above can be obtained by writing or calling the following address:
Don Tolmie, Chairperson
Los Alamos National Laboratory
Los Alamos, NM 87545
Internet email: [email protected]
This section describes some of the details of the Silicon Graphics implementation of the HIPPI protocol.
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.
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
0=HIPPI-SC compliant; 1=local format for I-field.
A site may use any value.
A site may use any value.
0=32 data bus.
0=Least significant bits contain address for next
hop; 1=address is placed in most significant bits.
A site may use any of the addressing formats.
1= camp-on; 0=do not camp-on.
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.
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
4 = HIPPI-LE
As defined by HIPPI-FP.
1 = D1 area is included in this FP header
D1 area contains the HIPPI-LE header as defined by HIPPI-LE.
0 = D2 data is included in first burst
As specified by RFC 1374.
3 = three 64-bit words (that is, 24 bytes)
As defined by HIPPI-LE.
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
As defined by HIPPI-LE and restated in RFC 1374.
0 = 32 bit data bus
0 = data
Destination Switch Address
Destination Address Type
Source Address Type
Source Switch Address
Destination IEEE Address
LE Locally Administered
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
As defined by IEEE 802.2 standard for Logical Link Control and restated in RFC 1374.
Same as above.
Same as above.
Same as above.
Same as above.
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
0 = HIPPI-SC compliant
Content is ignored.
Content is ignored.
0 = 32 data bus
Content is ignored.
Content is ignored.
Content is ignored.
Content is ignored.
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.
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
Values Accepted Without Generating an Error
4 = HIPPI-LE
As defined by HIPPI-FP. For other ULP-ids, see the IRIS HIPPI API Programmer's Guide for details.
If set to 1, the driver interprets the D1
area as a HIPPI-LE header.
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.
3 = three 64-bit words /
As defined by HIPPI-LE.
up to 64 kilobytes
As defined by Internet Protocol.
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
Values Accepted Without Generating an Error
As defined by HIPPI-LE.
0 = 32 bit data bus
If set to 1, an error is generated.
0 = data
If not 0 (data), an error is generated.
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
As defined by the IEEE 802.2 standard and restated by RFC 1374. If the received value is different, an error is generated.
Same as above.
Same as above.
Same as above.
Same as above.