RFC 2067
IP over HIPPI
IP over HIPPI 🎀
Okay bestie, this is RFC 2067 and it's giving standards track realness ✨. It's from the Network Working Group, written by J. Renwick at NetStar, Inc., and dated January 1997 🦋. It's a Standards Track document and it obsoletes RFC 1374 💅, so this one officially replaces that older version.
Status of This Memo 💌
Okay so this part is the legal-ish bit 🙈. This document specifies an Internet standards track protocol for the Internet community, and it's requesting discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Abstract 🍓
ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines how IEEE 802.2 LLC PDUs get encapsulated and, by implication, how IP rides on HIPPI 🚀. ANSI X3.222-1993 (HIPPI-SC[4]) describes how HIPPI physical switches behave. The ANSI committee in charge of these standards chose to leave HIPPI networking issues mostly outside their scope, so this document describes using HIPPI switches as IP local area networks 💜.
This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and it's meant to replace that doc on the Standards Track 👑. RFC 1374 has been a Proposed Standard since November, 1992, with at least 10 implementations of IP encapsulation and HIPPI switch discipline 🔥. No major changes are required to it. The ARP part of RFC 1374, though, hasn't had enough implementation experience to move up to Draft Standard 😭. So this document has everything from RFC 1374 except the ARP description, which got moved into its own separate document ✨.
Table of Contents 🧚
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
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......... 271 Introduction 🌸
The ANSI High-Performance Parallel Interface (HIPPI) is a simplex data channel 💖. You set it up in pairs, and then HIPPI can send and receive data at the same time at nearly 800 megabits per second 🔥. (There's also an equally applicable 1600 megabit/second option, which is so iconic.) Between 1987 and 1991, the ANSI X3T9.3 HIPPI working group drafted four documents that matter for using HIPPI as a network interface 📚. They cover the physical and electrical spec (HIPPI-PH [1]), the framing of a stream of bytes (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC (HIPPI-LE [3]), and how a standard physical layer switch behaves (HIPPI-SC [4]). HIPPI-LE also implies encapsulation of Internet Protocol[5] 🦋. You should be familiar with the ANSI HIPPI documents, which are archived at the site ftp.network.com in the directory hippi and can be grabbed through anonymous FTP 🧚.
HIPPI switches can connect all kinds of computers and peripheral gear for lots of purposes, but the working group stopped short of describing them as Local Area Networks 🙈. This memo picks up exactly where the working group left off 💅. The guiding principle is this: apart from length and hardware header, Internet datagrams sent on HIPPI should be identical to the same datagrams sent on a conventional network, and any datagram sent on a conventional 802 network[6] should be valid on HIPPI 🫶. That's main character energy for compatibility ✨.
2 Scope 🎀
This memo describes the HIPPI interface between a host and a crosspoint switch that complies with the HIPPI-SC draft standard 💜. Issues with no impact on host implementations are outside the scope of this memo. Host implementations that comply with this memo are believed to be interoperable on a network made of a single HIPPI-SC switch 🌈. They're also interoperable on a simple point-to-point, two-way HIPPI connection with no switch between them ⭐. They may be interoperable on more complex networks too, depending on the internals of the switches and how they're interconnected. But those details are implementation dependent and outside the scope of this memo, so we're not going there 🙈.
Within the scope of this memo are:
- Packet format and header contents, including HIPPI-FP, HIPPI-LE, IEEE 802.2 LLC[7] and SNAP.
- I-Field contents
- Rules for the use of connections.
Outside of the scope are:
- Address Resolution (ARP)
- Network configuration and management
- Host internal optimizations
- The interface between a host and an outboard protocol processor.
2.1 Changes from RFC 1374 🍓
RFC 1374 described using ARP on HIPPI. But because there wasn't enough implementation experience, the ARP description got separated from IP encapsulation and moved to an Informational memo 😭. It may return to the standards track in the future if there's enough interest and implementations to justify it 🔮.
RFC 1374's specification of IP over HIPPI has changed in this document. Some packet format options that RFC 1374 permitted are no longer allowed 🚫:
- Optional short burst first;
- D1 fill bytes;
- Nonzero D2 offset.
In other words, the header format is no longer variable and is required to be the one that RFC 1374 recommends 💅.
With these changes, it's possible to send packets that conform to the ANSI standards but not to this memo 👀. Because no RFC 1374 implementations in use ever used these options, we believe all existing RFC 1374 implementations are compliant with the requirements of this memo. So there should be no interoperability problems associated with these changes 🫶.
2.2 Terminology 📖
In this document, the use of the word SHALL in capital letters indicates mandatory points of compliance 👑.
3 Definitions 💖
Conventional Used with respect to networks, this refers to Ethernet, FDDI and 802 LAN types, as distinct from HIPPI-SC LANs 🌸.
Destination The HIPPI implementation that receives data from a HIPPI Source 🦋.
Node An entity made up of one HIPPI Source/Destination pair that's connected by parallel or serial HIPPI to a HIPPI-SC switch, and that transmits and receives IP datagrams 🧚. A node may be an Internet host, bridge, router or gateway. This memo uses the term node in place of the usual "host" 💅, because a host might be connected to the HIPPI LAN not directly, but through an external adaptor that does some of the protocol processing for the host ✨.
Serial HIPPI An implementation of HIPPI in serial fashion on coaxial cable or optical fiber, informally standardized by implementor's agreement in the Spring of 1991 🌈.
Switch Address A value used as the address of a node on a HIPPI-SC network 🍓. It's transmitted in the I-field. HIPPI-SC switches may map Switch Addresses to physical port numbers 🔥.
Source The HIPPI implementation that generates data to send to a HIPPI 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. Equipment 🧚
okay so a HIPPI network can be built from nodes with HIPPI interfaces, HIPPI cables or serial links, HIPPI-SC switches, and gateways to other networks 🌸
Each HIPPI interconnection between a node and a switch SHALL consist of a pair of HIPPI links, one in each direction. two lanes, one going each way, no cap 🛣️
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 bit wide operation) in either direction, the node's HIPPI-PH implementation SHALL also be capable of 32 bit operation (Cable B data suppressed) and SHALL be able to select or deselect the 1600Mb/s data rate option at the establishment of each new connection. the node gets to pick the speed for each new connection, and that's iconic ✨
Here's a sample HIPPI switch configuration, and honestly it's giving very detailed 😭
+-----+
| 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 FDDI
|| = Paired HIPPI link
H = Host computer
PP = Outboard Protocol Processor
G = Gateway
A possible HIPPI configurationA single HIPPI-SC switch is "non-blocking", which basically means there's always a path free from any Source to any Destination 💖 If the network has more than one switch, the path from a Source to a Destination may include a HIPPI link between switches. If that link is shared by more than one Source/Destination pair, you get a "blocking" network 💀: one Source might be blocked from reaching a Destination because another Source is using the link they share. Connection strategies can get more complicated on blocking networks than on non-blocking ones 🙈
This memo does not take blocking issues into account. It assumes the HIPPI LAN is one HIPPI-SC switch or, if the network is more complex than that, that it presents no additional problems a node must be aware of 🫶
5. Protocol 🎀
5.1. Packet Format 💅
The HIPPI packet format for Internet datagrams SHALL conform to the HIPPI-FP and HIPPI-LE draft standards, with further restrictions as imposed by this memo. Because this memo is stricter than the ANSI standards, it's possible to send encapsulated IP datagrams that follow the ANSI standards but are illegal according to this memo. Destinations may either accept or ignore such datagrams 👀
Here are the extra restrictions on top of the ANSI standards, bestie:
- Any short burst must be the last burst of the packet.
- Leading short bursts are not permitted.
- Nonzero values for the HIPPI-FP
D2_Offsetfield are not permitted. - The
D1_AreaSizeSHALL be 3 (64-bit words). No D1 Fill is permitted.
Note: this document is for IP over HIPPI, but the encapsulation below accommodates ARP as well 🦋
The HIPPI-FP D1_Area SHALL contain the HIPPI-LE header. The HIPPI-FP D2_Area, when present, SHALL contain one IEEE 802.2 Type 1 LLC Unnumbered Information (UI) PDU. Support of IEEE 802.2 XID, TEST and Type 2 PDUs is not required on HIPPI, and Destinations that receive these PDUs may either ignore them or respond correctly according to IEEE 802.2 requirements 🌈
The length of a HIPPI packet, including trailing fill, SHALL be a 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 StructureNow the HIPPI-FP fields, and yes they are very particular 🫠
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 the IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present. It SHALL NOT exceed 65,288. This value includes the IEEE 802.2 LLC/SNAP header and the IP datagram. It does not include trailing fill bytes. (See "MTU", below.)
HIPPI-LE Header ✨
FC(3 bits) SHALL contain zero unless otherwise defined by local administration.Double_Wide(1 bit) SHALL contain one if the Destination associated with the sending Source supports 64 bit HIPPI operation. Otherwise it SHALL contain zero.Message_Type(4 bits) contains a code identifying the type of HIPPI-LE PDU. Defined values are:
0 Data PDU
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)Destination_Switch_Addressis a 24-bit field containing the Switch Address of the Destination if known, otherwise zero. If the address comprises less than 24 bits, it SHALL be right justified (occupying the least significant bits) in the field.Destination_Address_Type(4 bits) andSource_Address_Type(4 bits) contain codes identifying the type of addresses in theDestination_Switch_AddressandSource_Switch_Addressfields respectively. Defined values (binary) are:
0 Unspecified
1 HIPPI-SC Source Route (24 bits)
2 HIPPI-SC Address (12 bits)Source_Switch_Addressis a 24-bit field containing the Switch Address of the Source. If the address comprises less than 24 bits, it SHALL be right justified (occupying the least significant bits) in the field.Reserved(16 bits) SHALL contain zero.Destination_IEEE_Address(48 bits) SHALL contain the 48 bit Universal LAN MAC Address of the Destination if known, otherwise zero.LE_Locally_Administered(16 bits) SHALL contain zero UNLESS otherwise defined by local administration.Source_IEEE_Address(48 bits) SHALL contain the 48 bit Universal LAN MAC Address of the Source if known, otherwise zero.
IEEE 802.2 LLC 🌸
The IEEE 802.2 LLC Header SHALL begin in the first byte of the 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).
SNAP 🧁
Organization Code(24 bits) SHALL be zero.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).
Here's the full packet layout, and it's giving a whole puzzle 🧩
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 |
+---------------+---------------+---------------+---------------+
HIPPI Packet Format Words 0-1: HIPPI-FP Header
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 even
number of 32 bit words. The number of fill bytes
is not counted in the data length.IEEE 802.2 Data ✨
okay so the IEEE 802.2 Data SHALL begin in the byte right after the EtherType field 💖 then fill bytes SHALL be used after the Data as needed to make the packet a multiple of 8 bytes 🎀 and here's the tea: per HIPPI-FP, that fill is NOT counted in the D2_Size value in the HIPPI-FP Header 🙈
the byte order is from higher numbered to lower numbered data signal (left to right) inside the HIPPI word, as laid out in HIPPI-FP Clause 7, "Word and byte formats." 🦋 with the 1600 megabit/second option (64 bit), bits 32 through 63 live on Cable B, so the four bytes on Cable B come logically before the ones on Cable A. and within each byte, the most significant bit is the highest numbered signal ✨
5.2. 48 bit Universal LAN MAC Addresses
okay bestie, the IEEE Standard 802.1A is where the Universal LAN MAC Address lives 🌸 the globally unique part of that 48 bit space is handled by the IEEE 👑 every node on a HIPPI-SC LAN should be assigned a ULA, and a node with more than one IEEE 802.2 LLC protocol entity can use multiple ULAs 🧚
the address sits inside its 48 bit HIPPI-LE fields following IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order, and it looks like this 💜
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 Format
L (U/L bit) = 1 for Locally administered addresses, 0 for
Universal.
G (I/G bit) = 1 for Group addresses, 0 for Individual.ULAs are optional, but encouraged 🫶 even though HIPPI-SC switches don't use them, they can be super helpful for HIPPI Switch Address resolution and for telling apart multiple logical entities living in one node 💅 they can also be used by gateway devices that swap HIPPI hardware headers for the MAC headers of other LANs. carrying ULAs in the HIPPI header may make those devices simpler, and it may help if HIPPI gets used as an interface to some future HIPPI based LAN that uses ULAs for addressing 🔥
5.3. I-Field format
the I-field bits (as defined in HIPPI-SC) SHALL be set like this, and yes, I'm going to explain every single one 😭
- Locally Administered (bit 31) SHALL be zero.
- Reserved (bits 30, 29) should be zero. Destinations SHALL accept any value for these bits.
- Double wide (bit 28) SHALL be set when Source Cable B is connected and the Source wants a 64 bit connection. It SHALL be zero otherwise.
- Direction (bit 27) should be sent as zero, however Destinations SHALL accept either zero or one and interpret 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 is source route mode, meaning I-field bits 23-00 hold a 24 bit source route. 01 or 11 is logical address mode, meaning bits 23-00 hold 12 bit Source and Destination Addresses. the value 11 is meaningful when more than one route exists from a Source to a Destination, because it lets the switch choose the route. using 01 forces the switch to always use the same route for the same Source/Destination pair 🧚
- Camp-on (bit 24) may be 1 or 0. however, a Source SHALL NOT make consecutive requests without Camp-on to the same Destination while those requests are being rejected 🚫 the reason is to stop a node from dodging the switch's fair share arbitration by spamming requests at a super high rate 💀
if logical address mode is used:
- Source Address (bits 23-12) is not used.
- Destination Address (bits 11-0) SHALL contain the Switch Address of the Destination.
if source route mode is used:
- Routing control (bits 23-00) SHALL contain the route to the Destination.
5.4. Rules For Connections
okay this section is about fairness, and it's giving main character energy 👑 the rules for connection management by Source and Destination are meant to insure frequent, fair share access to Destinations that multiple Sources are fighting over. if possible, nodes should transfer data at full HIPPI speeds and hold connections no longer than necessary 🌈
a Source may hold a connection for as long as it takes to send 68 HIPPI bursts, at whatever speed the two connected nodes can manage together. the number of packets in one connection is not limited, except that the number of bursts over all the packets should not exceed 68. this is NOT a recommendation to cram as many packets as possible into each connection, and one packet per connection is totally acceptable 🍓 the point of the limit is to give each Source a fair share of a common Destination's bandwidth. without it, if a Destination is constantly in demand by several Sources, the Source that sends the most data per connection wins the biggest share 😤
the limit of 68 bursts is not absolute. an implementation may check the burst count after sending a packet and end the connection if the count is greater than or equal to some threshold. if it does that, the threshold should be less than 68 depending on the typical packet size, so the 68 burst limit isn't normally exceeded 🙈 for example, a Source sending 64K packets would send two per connection (130 bursts) if it checked for 68 at the end of each packet. in that situation the Source is required to check for a value small enough that it won't send a second packet in the same connection 💅
Destinations SHALL accept all packets that arrive during a connection, and they may discard the ones that go over their buffering capacity. a Destination SHALL NOT abort a connection (deassert CONNECT) just because too many bursts arrived. however, a Destination may abort a connection whose duration has gone past a time period of the Destination's choosing, as long as the Source gets ample time to send its quota of bursts ⏰
these rules tell nodes to do certain things as fast as they can, but there's no absolute measure of compliance 🫠 nodes that can't transfer data at full HIPPI speeds can still interoperate, but the faster the implementation, the better the network performance will be ✨
assuming bursts flow at the maximum rate, the biggest factor in network throughput is the connection switching time. that's measured from the deassertion of REQUEST by the Source at the end of one connection to its first assertion of BURST after the new connection is established 🦋 implementations should keep this time as short as possible. as a guideline, assuming parallel HIPPI and a single HIPPI-SC switch, ten microseconds permits nearly full HIPPI throughput with full-sized packets, and at 60 microseconds the available throughput drops by about 10%. (See "Performance", below.) 📈
all HIPPI electrical signaling SHALL comply with HIPPI-PH. in every case, the following rules go beyond what HIPPI-PH requires 💜
Rules for the Source
- Do not assert
REQUESTuntil a packet is ready to send. - Transmit bursts as quickly as
READYs permit. Except for the required HIPPI Source Wait states, there should be no delay in the assertion ofBURSTwhenever the Source'sREADYcounter is nonzero. - Make a best effort to ensure that connection durations do not exceed 68 bursts.
- Deassert
REQUESTimmediately when no packet is available for immediate transmission or the last packet of the connection has been sent.
Rules for the Destination
- Reject all connections if unable to receive packets. this frees the requesting Source to connect to other Destinations with minimal delay. inability to receive packets is not a transient condition; it's the state of the Destination when its network interface is not initialized 🛑
- A HIPPI node should be prepared to efficiently accept connections and process incoming data packets. while this may be best achieved by not asserting connect unless 68 bursts worth of buffers is available, it may be possible to meet this requirement with fewer buffers. this may be due to an a priori agreement between nodes on packet sizes, the speed of the interface to move buffers, or other implementation dependent considerations 🧚
- Accept a connection immediately when buffers are available. the Destination should never delay the acceptance of a connection unnecessarily ⚡
- Once initialized, a Destination may reject connection requests only for one of the following reasons:
- The I-field was received with incorrect parity.
- The I-field contents are invalid, e.g. the "W" bit set when the Destination does not support the 1600 megabit data rate option, the "Locally Administered" bit is set, the Source is not permitted to send to this Destination, etc.
transient conditions within the Destination, such as temporary buffer shortages, must never cause rejected connections 🥺
- Ignore aborted connection sequences. Sources may time out and abandon attempts to connect, so aborted connection sequences are normal events 🌸
5.5. MTU
okay the Maximum Transmission Unit (MTU) is defined as the length of the IP packet, including the IP header, but NOT including any overhead below IP 🎀 conventional LANs have MTU sizes set by the physical layer specification. MTUs may be required simply because the chosen medium won't work with larger packets, or they may limit how long a node has to wait for a chance to send a packet ⏳
HIPPI has no inherent limit on packet size 🦋 the HIPPI-FP header has a 32 bit D2_Size field that could limit packets to about 4 gigabytes, but that imposes no practical limit for networking purposes. even so, a HIPPI-SC switch used as a LAN needs an MTU so that Destination buffer sizes can be determined 🧠
the MTU for HIPPI-SC LANs is 65280 bytes 💖 this value was picked because it lets the IP packet fit in one 64K byte buffer with up to 256 bytes of overhead. right now the overhead is 40 bytes, which leaves 216 bytes of room for expansion 🌈
HIPPI-FP Header 8 bytes
HIPPI-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes
------------
Total 65320 bytes (64K - 216)part 3 done, bestie 💜 keep going for the next part! 🧚
6. Camp-on 💅
okay so when a bunch of Sources are all trying to reach the same Destination, Camp-on is what lets the HIPPI-SC switch referee and make sure everyone gets a fair shot 🎀 (HIPPI-SC doesn't say how the arbitrating has to happen, fr). Without it, the losing Sources would just keep retrying the connection until one got through, and the fastest Source would basically always win 🏃♀️💨 that's not it, bestie. So to keep arbitration fair, Sources are prohibited from hammering the same Destination with repeated requests (without Camp-on) in a way that defeats the arbitration. no cap, that's a whole no-no 🙅♀️
there's another super important reason to use Camp-on too 👀 if a connection without Camp-on gets rejected, the Source can't tell whether the no came from the Destination or from the switch. it also can't figure out why. maybe the Destination was off line or not cabled, or maybe the I-field was erroneous or had incorrect parity 😭 so Sources should not treat a rejection of a request without Camp-on as an error. Camp-on stops rejections caused by the temporary busy situation. with one exception, a rejected Camp-on request means something is actually wrong, and an error event can be recorded 📝 the exception is when a 64 bit connection is attempted to a Destination that doesn't have Cable B connected, which results in a reject. we'll cover that in "Channel Data Rate Discovery", below ✨
7. Path MTU Discovery 🦋
RFC 1191 [9] describes how to figure out the MTU restrictions on any network path between two hosts. it's giving "figure it out for yourself" energy, and HIPPI nodes may use this method without modification to discover restrictions on paths between HIPPI-SC LANs and other networks 🌸 gateways between HIPPI-SC LANs and other types of networks should implement RFC 1191, periodt 💜
8. Channel Data Rate Discovery 🌈
okay this one is iconic. HIPPI comes in two data rate options: 800 megabit/second and 1600 megabit/second 🔥 the higher rate works by making the HIPPI 64 bits parallel instead of 32, using an extra cable that carries 32 additional data bits and four parity bits. HIPPI-SC switches can be designed to attach to both. Source and Destination HIPPI implementations can be designed to run at either rate, and you pick which one when the connection is established 🫶 the "W" bit (bit 28) of the I-field controls the width of the connection through the switch. Sources with both cables A and B attached to the switch may set the "W" bit to request a 1600 megabit/second connection. if the requested Destination also has both cables attached, the switch can connect Source to Destination on both cables. but if the requested Destination only has Cable A, the switch rejects the request 💀
64 bit Sources can connect to 32 bit Destinations by requesting with the "W" bit clear and not using Cable B ✨ 64 bit Destinations must examine the "W" bit in the received I-field and use or ignore Cable B accordingly. also, both INTERCONNECT signals stay active while a 64 bit HIPPI is used in 32 bit mode 🧚 here's the full tea:
Destination
+-------------------+-------------------+
| 32 | 64 |
+----+-----+-------------------+-------------------+
| | W=0 | Accept 32 | Accept 32 |
| 32 +-----+-------------------+-------------------+
| | W=1 | N/A | N/A |
Source +----+-----+-------------------+-------------------+
| | W=0 | Accept 32 | Accept 32 |
| 64 +-----+-------------------+-------------------+
| | W=1 | Reject | Accept 64 |
+----+-----+-------------------+-------------------+HIPPI Connection Combinations
if the path between a 64 bit Source and a 64 bit Destination goes through more than one switch, and the route between switches uses a link that's only 32 bits wide, the switch rejects 64 bit connection requests as if the Destination didn't have 64 bit capability 🙈
in a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to know the data rates available at each Destination and on the path to it 😭 this can be known a priori by manual configuration, or it can be discovered dynamically. the only reliable method of discovery is simply to attempt a 64 bit connection with Camp-on. as long as 64 bit connections succeed, the Source knows the Destination and path are double width 🙌 if a 64 bit connection is rejected, the Source tries to connect for 32 bits. if the 32 bit connection succeeds, the Source assumes that the Destination or path isn't capable of double width operation, and only uses 32 bit requests after that. if the 32 bit request is rejected, the Source assumes the Destination or path is down and makes no determination of its capability 💅
the Double_Wide bit in the HIPPI-LE header, if nonzero, gives the node that receives it a hint that the 64 bit connection attempt may be worthwhile when sending on the return path 🍓
and note that Camp-on must be used at least in the 64 bit attempt, because it removes some ambiguity from the meaning of rejects. if the request is made with the "W" bit and no Camp-on, a reject could mean either that the Destination has no Cable B or that it's simply busy, and no conclusion can be drawn about its status for 64 bit connections 🤯
9. Performance 🚀
the HIPPI connection rules are designed to make the best use of the available HIPPI throughput, under the constraint that each Destination has to be made available frequently to receive packets from different Sources 💖 this asks both Sources and Destinations to keep connection setup overhead low for high performance. low connection setup times are easily achieved by hardware implementations, but overhead may be too high if software has to run between the initial request of a connection and the start of data transfer 😤 hardware implementations where connection setup and data transfer proceed from a single software action are very desirable 👑
HIPPI connections are controlled by HIPPI Sources. a Destination can't initiate a disconnect without the possibility of data loss, so once it has accepted a connection, it's a slave to the Source 🥺
optimizing the connection strategy is therefore the province of the HIPPI Source, and several optimizations are permitted ✨
if the rate of available message traffic is less than the available HIPPI throughput, and Destinations are seldom busy when a connection is requested, connection optimizations don't pay off. the simplest strategy of waiting indefinitely for each connection to be made and sending messages strictly in the order queued cannot be improved upon 🌸 however, if some nodes are slow, or network applications can send or receive messages at a higher aggregate rate than the available HIPPI bandwidth, Sources may frequently run into a busy Destination 😩 in these cases, certain host output queuing strategies may enhance channel utilization. Sources may maintain separate output queues for different HIPPI Destinations, and abandon one Destination in favor of another if a connection attempt without Camp-on is rejected or a connection request with Camp-on isn't accepted within a predetermined interval. this kind of strategy results in aborted connection sequences (defined in HIPPI-PH: REQUEST is deasserted before any data is sent). Destinations must treat these as normal events, perhaps counting them but otherwise ignoring them 🫧
two components of connection setup time are totally out of the control of both Source and Destination 🙃 the first is the time required for the switch to connect Source to Destination, currently less than four microseconds in the largest commercially available (32 port) switch. the second is the round trip propagation time of the REQUEST and CONNECT signals. it's negligible on a standard 25 meter copper HIPPI cable, but contributes a total of about 10 microseconds per kilometer on fiber optic links. HIPPI-SC LANs spanning more than a few kilometers will have reduced throughput. limited span networks with buffered gateways or bridges between them may perform better than long serial HIPPI links 🦋
a Source is required to drop its connection after the transmission of 68 HIPPI bursts. this number was chosen to allow the transmission of one maximum sized packet or a reasonable number of smaller packets 💜 the following table lists some possibilities, with calculated maximum burst and throughput rates in millions (10**6) of bytes per second:
Maximum HIPPI Throughput Rates
Number Number Hold Burst ------Max throughput MB/sec-------
User of of Time Rate Connection Setup Overhead (usec)
Data Packets Bursts (usec) MB/sec 10 30 60 90 120 150
---- ------- ------ ------ ------ ---- ---- ---- ---- ---- ----
63K 1 64 654 98.7 97.2 94.4 90.4 86.8 83.4 80.3
32K 2 66 665 98.6 97.1 94.3 90.4 86.8 83.5 80.4
16K 4 68 667 98.3 96.8 94.1 90.2 86.6 83.3 80.2
8K 7 63 587 97.8 96.1 93.0 88.7 84.8 81.2 77.8
4K 13 65 551 96.7 95.0 91.7 87.2 83.1 79.4 76.0
2K 22 66 476 94.6 92.7 89.0 84.0 79.6 75.6 72.0
1K 34 68 384 90.8 88.5 84.2 78.5 73.5 75.8 65.3these calculations are based on 259 40 ns clock periods to transmit a full burst and 23 clock periods for a short burst. (HIPPI-PH specifies three clock periods of overhead per burst.) a packet of "n" kilobytes of user data consists of "n" full bursts and one short burst equal in length to the number of bytes in the HIPPI, LLC, IP and TCP headers 🧮 "Hold Time" is the minimum connection duration needed to send the packets. "Burst Rate" is the effective transfer rate for the duration of the connection, not counting connection switching time. Throughput rates are in megabytes/second, accounting for connection switching times of 10, 30, 60, 90, 120 and 150 microseconds. these calculations ignore any limit on the rate at which a Source or Destination can process small packets. such limits may further reduce the available throughput if small packets are used 🌈
10. Sharing the Switch 🎀
network interconnection is only one potential application of HIPPI and HIPPI-SC switches 💅 while network applications need very frequent transient connections, other applications may favor longer term or even permanent connections between Source and Destination. since the switch can serve each Source or Destination with hardware paths totally separate from every other, it's quite feasible to use the same switch to support LAN interconnects and computer/peripheral applications at the same time ✨
switch sharing is no problem when unlike applications don't share a HIPPI cable on any path. however, if a host must use a single input or output cable for network as well as other kinds of traffic, or if a link between switches must be shared, care must be taken to ensure that all applications are compatible with the connection discipline described in this memo 🙏 applications that hold connections too long on links shared with network traffic may cause loss of network packets or serious degradation of network service 😭🔥
11 References 📚
[1]ANSI X3.183-1991, High-Performance Parallel Interface - Mechanical, Electrical and Signalling Protocol Specification (HIPPI-PH).[2]ANSI X3.210-1992, High-Performance Parallel Interface - Framing Protocol (HIPPI-FP).[3]ANSI X3.218-1993, High-Performance Parallel Interface - Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link Control Protocol Data Units (802.2 Link Encapsulation) (HIPPI-LE).[4]ANSI X3.222-1993, High-Performance Parallel Interface - Physical Switch Control (HIPPI-SC).[5]Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.[6]IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.[7]IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.[8]Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2, RFC 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 Considerations 🔒
Okay so, bestie, this one is short and sweet: security issues are not discussed in this memo. 🫶
13 Author's Address 💌
John K. Renwick NetStar, Inc. 10250 Valley View Road Minneapolis, MN USA 55344
Phone: (612) 996-6847 EMail: jkr@NetStar.com
Mailing List: hippi-ext@think.com
14 Appendix A -- HIPPI Basics 🧚
This section is here as a little helper for anyone who isn't totally fluent in the HIPPI standards yet. No judgment, we've all been there 🌸
HIPPI-PH describes a parallel copper data channel between a Source and a Destination. HIPPI only transmits data in one direction, so you need two sets for bidirectional flow. Here's a simple point-to-point link between two computer systems, lowkey the best visual in the whole doc ✨
+----------+ +----------+
| | | |
| +--------+ +--------+ |
| | HIPPI | Cable | HIPPI | |
| | +--------------------->| | |
| | Source | | Dest. | |
| System +--------+ +--------+ System |
| X +--------+ +--------+ Y |
| | HIPPI | Cable | HIPPI | |
| | |<---------------------+ | |
| | Dest. | | Source | |
| +--------+ +--------+ |
| | | |
+----------+ +----------+A Simple HIPPI Duplex Link
Parallel copper cables may be up to 25 meters in length. 📏
In this document, all HIPPI connections are assumed to be paired HIPPI channels. 💅
HIPPI-PH has a single optional feature: it can use a single cable in each direction for a 32 bit parallel channel with a maximum data rate of 800 megabit/second, or two cables for 64 bits and 1600 megabit/second. Cable A carries bits 0-31 and is used in both modes. Cable B carries bits 32-63 and is used only with the 1600 megabit/second data rate option. 🔥
HIPPI Signal Hierarchy 🌈
HIPPI has the following hardware signals:
Source to Destination
INTERCONNECT A
INTERCONNECT B (64 bit only)
CLOCK (25 MHz)
REQUEST
PACKET
BURST
DATA (32 or 64 signals)
PARITY (4 or 8 signals)
Destination to Source
INTERCONNECT A
INTERCONNECT B (64 bit only)
CONNECT
READYThe INTERCONNECT lines carry DC voltages that indicate that the cable is connected and that the remote interface has power. INTERCONNECT is not used for signaling. ⚡
The CLOCK signal is a continuous 25 MHz (40 ns period) square wave. All Source-to-Destination signals are synchronized to the clock. ⏰
The REQUEST and CONNECT lines are used to establish logical connections. A connection is always initiated by a Source as it asserts REQUEST. At the same time it puts 32 bits of data on DATA lines 0-31, called the I-field. The Destination samples the DATA lines and can complete a connection by asserting CONNECT. Packets can be transmitted only while both REQUEST and CONNECT are asserted. 🤝
A Destination can also reject a connection by asserting CONNECT for only a short interval between 4 and 16 HIPPI clock periods (160-640 nanoseconds). The Source knows a connection has been accepted when CONNECT is asserted for more than 16 clocks or it receives a READY pulse. 🙅♀️
Either Source or Destination can terminate a connection by deasserting REQUEST or CONNECT, respectively. Normally connections are terminated by the Source after its last Packet has been sent. A Destination cannot terminate a connection without potential loss of data. 💀
+------+-------------------------+------+
| Idle | Connected | Idle | . . .
+------+-------------------------+------+
/ \
/ \
/ \
/ \
/ \
+-------+ +-------+ +-------+ +-------+
|I-field| |Packet | |Packet | |Packet |
+-------+ +-------+ +-------+ +-------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+-----+ +-----+ +-----+
|Burst| |Burst|...|Burst|
+-----+ +-----+ +-----+HIPPI Logical Framing Hierarchy
The Source asserts PACKET for the duration of a Packet transmission, deasserting it to indicate the end of a Packet. A sequence of Bursts comprise a Packet. To send a burst, a Source asserts the BURST signal for 256 clock periods, during which it places 256 words of data on the DATA lines. The first or last Burst of a Packet may be less than 256 clock periods, allowing the transmission of any integral number of 32 or 64 bit words in a Packet. 📦
The READY signal is a pulse four or more clock periods long. Each pulse signals the Source that the Destination can receive one Burst. The Destination need not wait for a burst before sending another READY if it has burst buffers available; up to 63 unanswered READYs may be sent, allowing HIPPI to operate at full speed over distances of many kilometers. If a Source must wait for flow control, it inserts idle periods between Bursts. 🚀
+------------------------------------------------+
REQUEST---+ +----
+--------------------------------------------+
CONNECT---------+ +--
+---------------------------------------+
PACKET-------------+ +----
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--
+-------+ +-------+ +-------+ +-----+
BURST--------------+ +-+ +-+ +-+ +--------
DATA------I-field----DATA------DATA------DATA-----DATA----------HIPPI Signal Timing Diagram
Serial HIPPI 🧵
There is no ANSI standard for HIPPI other than the parallel copper cable version. However, an implementors' agreement exists, specifying a serial protocol to extend HIPPI signals on optical fiber or coaxial copper cable. Serial links may be used interchangeably with parallel links to overcome HIPPI distance limitations. They are transparent to the Source and Destination, except for the possibility of longer propagation delays. 🌍
I-Field and Switch Control 🎀
The REQUEST, CONNECT and I-field features of HIPPI-PH were designed for the control of switches as described in HIPPI-SC. A switch is a hub with a number of input and output HIPPI ports. HIPPI Sources are cabled to switch input ports, and switch output ports are cabled to HIPPI Destinations. When a HIPPI Source requests a connection, the switch interprets the I-field to select an output port and electrically connects the HIPPI Source to the HIPPI Destination on that port. Once connected, the switch does not interact with the HIPPIs in any way until REQUEST or CONNECT is deasserted, at which time it breaks the physical connection and deasserts its output signals to both sides. Some existing switch implementations can switch connections in less than one microsecond. There is the potential for as many simultaneous connections, each transferring data at HIPPI speeds, as there are input or output ports on the switch. A switch offers much greater total throughput capacity than broadcast or ring media. 👑
31 28 26 23 11 0
+-+---+-+-+---+-+-----------------------+-----------------------+
|L| |W|D|PS |C| Source Address | Destination Address |
+-+---+-+-+---+-+-----------------------+-----------------------+
HIPPI-SC I-field Format (Logical Address Mode)
L = Locally defined (1 => entire I-field is locally defined)
W = Width (1 => 64 bit connection)
D = Direction (1 => swap Source and Destination Address)
PS = Path Selection (01 => Logical Address Mode)
C = Camp-on (1 => wait until Destination is free)HIPPI-SC defines I-field formats for two different addressing modes. The first, called Source Routing, encodes a string of port numbers in the lower 24 bits. This string specifies a route over a number of switches. A Destination's address may differ from one Source to another if multiple switches are used. 🗺️
The second format, called Logical Address Mode, defines two 12 bit fields, Source Address and Destination Address. A Destination's 12 bit Switch Address is the same for all Sources. Switches commonly have address lookup tables to map 12 bit logical addresses to physical ports. This mode is used for networking. 🌸
okay so the control fields in the I-field are basically the little flags that tell the switch what you're asking for 💅
Lis the "Locally Defined" bit 🔮 When it's set, your I-field isn't in the standard format, and the meaning of bits30-0is up to whoever's local setup you're in.Wis the Width bit 🌈 Setting it asks for a 64 bit connection through the switch. It does nothing if Cable B isn't installed at the Source. IfWis set but either the Source or the requested Destination doesn't have a Cable B to the switch, the switch says no and rejects the connection 🙅♀️ Otherwise,Wset means the switch hooks up both Cable A and Cable B, andWclear means just Cable A. This is super handy if both the Source and Destination can turn Cable B on or off for each new connection ✨Dis the Direction bit 🔁 When it's set, it flips the Source Address and Destination Address fields. SoD=1means the Source Address lives in bits0-11and the Destination Address lives in bits12-23. It was made so devices had an easy way to route return messages 💖 It's not really useful for LAN operations, so don't stress about it bestie.PSis the Path Selection field 🛣️ It decides whether the I-field carries Source Route or Address info, and in Logical Address mode, whether the switch can pick from multiple possible routes to the destination. The value"01"picks Logical Address mode with fixed routes 🦋Cis the Camp-on bit 🏕️ It asks the switch not to reject the connection if the selected Destination is busy (already connected to another Source). Instead, the switch waits and makes the connection once the Destination is free. Very patient, very iconic 🫶
15. Appendix B -- How to Build a Practical HIPPI LAN 🏗️
"IP on HIPPI" explains what a network host sees of a HIPPI local area network, but it doesn't really say much about how the network itself is built 🙈 So here we go! We describe a network made from HIPPI parts you can actually get, with these vibes:
- A tree structure, with a central HIPPI-SC compliant hub and optional satellite switches 🌳
- Each satellite is connected to the hub by just one bidirectional HIPPI link 🔗
- Serial HIPPI or transparent fiber optic HIPPI extender devices may be used in any link 🧚
- Some satellites may be a particular switch product that isn't HIPPI-SC compliant 💀
- Host systems attach either directly to the hub or to satellites, using single bidirectional links where both HIPPI cables go to the same numbered switch port 🍓
Switch Address Management ✨
Switch addresses live in a flat address space. The 12-bit address is split into 6 bits of switch number and 6 bits of port number 💜
11 5 0
+-----------------------+-----------------------+
| Switch Number | Port Number |
+-----------------------+-----------------------+Logical Address Construction 🧩
Switches can be numbered however you like 🔢 A given host's address is made of the number of the switch it's directly attached to, plus the physical port number on that switch where its input channel plugs in.
In the singly-connected tree structure, there's exactly one path between any pair of hosts. Since each satellite has to be connected directly to the hub, the longest that path can be is three hops, and the shortest is one 🛤️ Each HIPPI-SC compliant switch is programmed to map each host's switch address to the right output port. That's either the port the host is directly attached to, or a port linked to another switch on the way to it 🎀
Special Treatment of Nonstandard Switches 🙃
There's one commercially available switch that was designed before HIPPI-SC was drafted, so it isn't fully compliant. It's pretty popular in the wild, so it's worth making some special provisions so it can be used in a HIPPI LAN 🌸 This switch only supports the Source Route mode of addressing, with a four bit right shift that can be disabled by a hardware switch on each input port. Addresses can't be mapped. The switch doesn't support the W, D, or PS fields of the I-field, so it just ignores what's in them 🙈 Using this switch as a satellite takes a slight deviation from normal I-field usage by the hosts directly attached to it. Hosts attached to standard switches aren't affected at all 🫶
For a destination connected to a non compliant satellite, the satellite only uses the least significant four bits of the I-field as the address. Because the address holds the destination's physical port number in its least significant bits, that's the port that gets selected 👑 Nonstandard switches should have I-field shifting disabled at the input from the hub, so the destination host sees its correct switch address in the I-field when it does self-address discovery. I-field shifting must be enabled on the satellite for each input port a host is attached to 🔥
Hosts attached to nonstandard satellites must deviate from normal I-field usage when connecting to hosts on another switch. It's suggested that all host implementations have this capability as long as the nonstandard switches stay in use 💅 The host must know, through some manual configuration method, that it's connected to a nonstandard switch, and it must have its "link port" number. That's the number of the port on the satellite that connects to the hub 🔌
The normal I-field format for a 32-bit connection, per the document, looks like 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 gets altered by shifting the lower 24 bits left by four and adding the link port number ✨ Camp-on is optional, and the PS field is set to 01 or 11 (the host's option), as if the switch supported logical address mode. All other I-field bits are set to zero 🧸 When the host requests a connection with this I-field, the switch picks a connection through the link port to the hub, and shifts the lower 24 bits of the I-field right by four bits. The link port number gets discarded, and the I-field passed on to the hub is a proper HIPPI-SC I-field selecting logical address mode 🦋
⚠️ A host on a nonstandard satellite can use the special I-field format for all connection requests. But if it's connecting to another host on the same satellite, that means the connection takes an unnecessarily long path through the hub and back 😭
If you want an optimization, the host can be given extra info so it can use the standard I-field format when connecting to another host on the same switch 🌈 That info could be a list of the other hosts on the same switch, or the details of how addresses are formed, along with the switch number of the local satellite. That would let the host analyze the switch address and figure out whether the destination is on the local switch 🧚 This optimization is fairly complicated and may not always be worthwhile, so only go there if you really need it 💖
📦 where this page comes from
- ietf: rfc2067 1997-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms