RFC 1044
Internet Protocol on Network System's HYPERchannel: Protocol Specification
Part 1 of 9 🎀
RFC 1044: Internet Protocol on Network Systems HYPERchannel Protocol Specification 💖
Okay bestie, this one is a February 1988 RFC from the Network Working Group 🦋 It's by Ken Hardwick (NSC, Network Systems Corporation) and John Lekashman (NASA-Ames GE). The title block doesn't list a category, and it doesn't say what this RFC obsoletes or updates, so there's nothing to add there. The whole point is getting IP datagrams running on HYPERchannel hardware, which is giving main character energy 👑
Status of This Memo ✨
Okay so the goal of this doc is to fully explain how the DoD standard Internet Protocol datagrams (plus the higher level protocols that ride on them) get packed into Network Systems Corporation's HYPERchannel [1] gear. Distribution is unlimited, so share it with everyone 💅
This is written for network planners and implementors who already know TCP/IP and how it runs on common networks like the DDN or Ethernet. You don't need to be an NSC expert, because there's an appendix that walks through NSC's technologies and protocols 🧚
Also, at the time of this first RFC edition, about a dozen vendors and users who actually use TCP/IP on HYPERchannel media had already reviewed it. Comments and suggestions are still super welcome (and implementable!) 🫶
Here's who to contact:
Ken Hardwick
Director, Software Technology
Network Systems Corporation MS029
7600 Boone Avenue North
Brooklyn Park, MN 55428
Phone: (612) 424-1607
John Lekashman
Nasa Ames Research Center. NAS/GE
MS 258-6
Moffett Field, CA, 94035
lekash@orville.nas.nasa.gov
Phone: (415) 694-4359Table of Contents 🦋
Here's the full map of the doc so you don't get lost 🗺️
Status of this memo . . . . . . . . . . . . . . . . . . . . . . 1
Goals of this document . . . . . . . . . . . . . . . . . . . . 3
Basic HYPERchannel network messages . . . . . . . . . . . . . . 4
Basic (16-bit address) Message Proper header . . . . . . . . . 5
TO addresses and open driver architecture . . . . . . . . . . 7
Extended (32-bit address) Message Proper header . . . . . . . . 8
Address Recognition and message forwarding . . . . . . . . . . 10
32-bit message fields . . . . . . . . . . . . . . . . . . . . 12
Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . 14
PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 17
Basic (16-bit) Message Encapsulation . . . . . . . . . . . . 18
Compatibility with existing implementations . . . . . . . . . . 21
Extended (32-bit) Message Encapsulation . . . . . . . . . . . 24
Address Resolution Protocol . . . . . . . . . . . . . . . . . 27
Maximum Transmission Unit . . . . . . . . . . . . . . . . . . . 31
ADDRESS RESOLUTION . . . . . . . . . . . . . . . . . . . . . . 32
Local Address Resolution . . . . . . . . . . . . . . . . . . . 33
Configuration file format . . . . . . . . . . . . . . . . . . 34
ARP servers . . . . . . . . . . . . . . . . . . . . . . . . . 35
Broadcast ARP . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A.
NSC Product Architecture and Addressing . . . . . . . . . . . . 38
Appendix B.
Network Systems HYPERchannel protocols . . . . . . . . . . . . 42Goals of This Document 🎯
Okay so there are four big technical goals in this doc, and they're all iconic:
- Bless a "de facto" standard for IP on HYPERchannel that Tektronix, Cray, NASA Ames, and others have already implemented. We're trying to fix some interoperability problems with that standard so we don't have to change existing IP on HYPERchannel software too much. If any ambiguities are still floating around in the de facto standard, we want to help sort them out 💖
- Handle larger networks 🌐 NSC's newer products are moving from the current 16-bit TO address to a 32-bit address. This doc introduces that addressing extension to the user community and explains how IP datagrams work in the new addressing mode ✨
- Define an Address Resolution Protocol for HYPERchannel and other NSC products. It's pretty well known that current NSC products don't support the broadcast modes that make ARP especially useful. But lots of people have been asking for "ARP servers" at a known network address. These servers could fade away once NSC products with broadcast capability show up. Host drivers that can generate and recognize this ARP protocol will be ready to use it as the pieces fall into place 🧩
- Standardize the unofficial "message type" field that reserves byte 8 of the HYPERchannel network message. For better interoperability, NSC will start a "network protocol registry" where any interested party can get a unique value in byte 8 (or bytes 8 and 9) for their own public, private, commercial, or proprietary protocol. NSC will periodically publish lists of assigned protocol type numbers and their "owners," and those lists will be available to anyone who's interested 📜
Basic HYPERchannel Network Messages 🌸
Okay so this is the part that's kind of unique. Unlike most datagram delivery systems, a HYPERchannel network message has two parts:
Message Proper
+--------------------+
| |
| |
| 10-64 bytes |
| |
| |
+--------------------+
Associated Data
+----------------------------------------------------+
| |
| |
| |
| |
| Unlimited length |
| |
| |
| |
| |
+----------------------------------------------------+The first part is a message header that can be up to 64 bytes long. The first 10 bytes hold the info needed to deliver the entire message, and the rest is free for higher level protocols to use 🎀 The second part, the "Associated Data," is optional and can ride along with the Message Proper. Over HYPERchannel A trunks, the Associated Data is basically unlimited in length 🤯 Other setups (like HYPERchannel B, or transmission inside a local HYPERchannel A A400 adapter) cap the Associated Data at 4K bytes. If what you're sending fits inside the Message Proper, you don't need to send the Associated Data at all 💅
Also, HYPERchannel's lower link protocols treat messages with and without Associated Data really differently. "Message only" transmissions use abbreviated protocols and can be queued in the receiving network adapter, which cuts down the time it takes to send and receive them 🚀 When Associated Data is included, the HYPERchannel A adapters free up their logical resources so they can keep driving the host interface and coaxial trunks.
Basic (16-bit Address) Message Proper Header 🍓
Okay so the first 10 bytes of the network Message Proper are what the network adapters look at to control delivery. The layout looks like this:
byte Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks | |EXC|BST|A/D|
+--------------+---------------+-----------------+---+---+---+
2 | Access code |
| |
+------------------------------+-----------------------------+
4 | Physical addr of | | TO Port |
| destination adapter (TO) | | number |
+------------------------------+-----------------------------+
6 | Physical addr of source | |FROM port|
| adapter (FROM) | | number |
+------------------------------+-----------------------------+
8 | Message type |
| |
+------------------------------+-----------------------------+
10 | |
| Available for higher level protocols |
| |
| |
+------------------------------+-----------------------------+Trunks to Try 🔌
This field has two four-bit masks that say which of the four possible HYPERchannel A coaxial data trunks should be used to send the message and to bring it back. If a bit in a mask is ON, the adapter firmware ANDs that mask with the mask of installed trunk interfaces, and the result becomes a list of candidate interfaces. Every time one of the internal "frames" gets sent to talk to the destination adapter, the transmission hardware electronically picks the first non-busy trunk on the candidate list. So picking a data trunk is best done by the adapter itself, not the host 🙌 Dedicating trunks to specific apps only makes sense for really critical real time stuff, like streaming data straight from high speed overrunnable peripherals.
There's also a second Trunk mask for the receiving adapter when it sends frames back to the transmitter. That's because it's possible to build "asymmetric" trunk setups, where trunk 1 on one box is wired to the trunk 3 interface on another. These setups are strongly discouraged, but the addressing structure supports them if you really need one 🙈
The "trunks to try" field is only used by HYPERchannel A. For maximum interoperability, 0xFF should go in this field so delivery works over any technology. Any other value should only be used if the site hardware is configured so it isn't physically connected through those trunks 🧃
Message Flags 🚩
This field holds options for delivering the message. For the basic type of message, three bits are used:
ASSOCIATED DATA PRESENT (A/D) is ON if an Associated Data block follows the Message Proper, and it's 0 if only a Message Proper is in the network message. The network adapter firmware enforces this bit, so it's always accurate 💖
BURST MODE (BST) turns on a special mode for time-critical transfers, where one HYPERchannel A coaxial trunk is dedicated for the whole time the network message is sending. Not recommended for anything that would cause peripheral device overruns if the data didn't get delivered once transmission started 😭
EXCEPTION (EXC) tells certain channel programmed host interfaces that the message is "out of band" in some way and needs special processing ⭐
ACCESS CODE 🔐
This is a feature that lets adapters share one cable while still letting an "access matrix" decide which adapter boxes can physically talk to which others. 💅 Nobody's using it right now, so support is being discontinued. 🥲
TO ADDRESS 🎯
It's got three parts, bestie. The high order 8-bits hold the physical address of the network adapter box that's supposed to get the message. The low order 8-bits get read differently depending on what kind of adapter is receiving it. If the receiving adapter has different host "ports," then the low order bits of the TO field pick out which interface gets the message. On IBM data channels, the whole "logical" TO field is treated as the subchannel the incoming data gets presented on. Any part of the logical TO field the network adapter doesn't interpret gets passed up to the host for further interpretation. 🧠✨
FROM ADDRESS 🦋
The FROM address doesn't do anything physical while the network message is being sent. It just rides along and gets passed to the receiving host so a response can find its way back to where it started. 🔁 Basically, if you swap the TO and FROM 16-bit address fields, and also swap the TO and FROM trunk masks, you can reliably send a message back to its destination. Main character return route, no cap. 🫶
MESSAGE TYPE 🌈
The next two bytes are reserved for NSC. Users have been encouraged to put a zero in byte 8 and anything at all in byte 9, so they don't clash with the internal message processing done by NSC firmware. 🙈 Back in the day this field was loosely defined as carrying info that mattered to the NSC equipment carrying the message, and it wasn't really a formal protocol type field. For example, 0xFF00 in bytes 8 and 9 of the message will make the receiving adapter "loop back" the message without delivering it to the attached host. Iconic little trick. 🔄
Here's the glow-up, though. At the same time as this document, NSC plans to use both bytes 8 and 9 as a formal "protocol type" designator. 👑 Major protocols will get a unique value in byte 8, and (among good citizens) that value won't duplicate one generated by a different protocol. Minor protocols will get 16-bit values, so we won't run out when 256 protocols show up. 😭 Any interested party can get a protocol number or numbers by applying to NSC. And in this document, protocol types specific to IP protocols get assigned. 🌸
TO ADDRESSES AND OPEN DRIVER ARCHITECTURE 🧚
Not all 16-bits of the TO address are used for physical delivery of the network message, so the rest are considered "logical." Their meaning gets decided physically by host computer software or (in cases like the FIPS data channel) by hardware in the host interface. 🛠️
HYPERchannel is used to support a huge variety of general and special purpose protocols, and it's going to keep being that way. So it's desirable that several independent protocol servers can share the HYPERchannel network interface at the same time. 💜 Lots of NSC's device drivers do this, and so do the ones from other parties (like Cray Research). Each protocol server that wants to send or receive HYPERchannel network messages "connects" to a HYPERchannel device driver by specifying the complete 16-bit TO address it will "own." Any network message with that TO address gets delivered to that protocol server. Very territorial, very organized. 🏰
The logical TO field does a job similar to the TYPE byte in the Ethernet 802.2 message header. But it's different, because the width of the logical TO field changes from host to host, and no values of the logical TO address are reserved for particular protocols. 🎀 On the flip side, you can have several "identical" protocols (like two independent copies of IP with different HYPERchannel addresses) sharing the same physical HYPERchannel interface. This makes NSC's addressing approach identical to the OSI concept, where the protocol server to reach is embedded within the address. The IP way is different: it addresses a "host" and identifies a server through a message type. ✨
Since the HYPERchannel header also has a "message type" field, the roles of the message type and logical TO fields can get a little confusing. Here's how it shakes out:
- The logical TO field is always used to identify the protocol server that receives the message. Once a server has specified the complete TO address for the messages it wants, the message won't be delivered to a different protocol server, no matter what's in the message type field. 🙅♀️
- The "type" field can't change the protocol server at the final destination. But it can be used by intermediate processes on the network to handle the message before it reaches the server. The obvious example is the
0xFF00loopback type, where network processing loops the message back, so it never gets delivered to the TO address. 🔁 Down the road, intermediate nodes might process "in transit" messages based on the message type only for things like security validation, aging of certain datagrams, and network management. 🔐
EXTENDED (32-BIT ADDRESS) MESSAGE PROPER HEADER 👑
Back in the original days of HYPERchannel, being able to address 256 adapter "boxes" in a network message was considered enough, since 40 or so adapters counted as a "large" network. 😂 Then, just like with Ethernet, bigger networks showed up and needed more addresses. A few ad hoc modes have existed for years to address larger HYPERchannel networks. But newer HYPERchannel equipment has logically extended the network message to support 32-bits of addressing, with 24 of those bits designating a physical network adapter. Glow-up unlocked. 🌟
This 32-bit header was designed so existing network adapters can still send and receive these messages. Only the network bridges need the smarts to pick out the messages meant for them. 🌉
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+--------------+---------------+---+---+--+--+---+---+---+---+
2 | TO Domain # | TO Network # |
| | |
+------------------------------+-----------------------------+
4 |O| Physical addr of | | TO Port |
|N| destination adapter (TO) | | number |
+------------------------------+-----------------------------+
6 |O| Physical addr of source | |FROM port|
|N| adapter (FROM) | | number |
+------------------------------+-----------------------------+
8 | Message type |
| |
+------------------------------+-----------------------------+
10 | FROM Domain # | FROM Network # |
| | |
+------------------------------+-----------------------------+
12 | - reserved - | age count |
| | |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| (normally 16) | (normally 16) |
+------------------------------+-----------------------------+
16 | Start of user protocol |
| bytes 16 - 64 of message proper |
| |
+------------------------------+-----------------------------+
Associated Data
+-----------------------------------------------------------------+
| |
| As with basic format network messages |
| |
+-----------------------------------------------------------------+ADDRESS RECOGNITION AND MESSAGE FORWARDING 🎀
okay so with the 32-bit form of addressing, NSC is still sticking to the idea that the native HYPERchannel address is directly related to where the equipment sits in an extended HYPERchannel network 🗺️✨
Each group of "locally" attached NSC network adapters that are connected by coax or fiber optic cable is called a "network" 🔌. You can also add nonselective repeaters, like the ATRn series, to the mix. Each network can have up to 256 directly addressable adapters attached, and they can all be reached by the basic format network message 💅.
Existing bridges or "link adapters" can be programmed to act as "selective repeaters" 🌉. They receive network messages that contain a subset of network addresses, send them over the bridge medium (if one is present), and reintroduce them on the other network. From an addressing point of view, these interconnected local area networks count as a single network 🫶.
A big NSC network can have up to 64K networks 🌈. They can be interconnected in complicated ways using network bridges and/or "backbone" networks, which distribute data between other networks. To keep message forwarding simple, the 16-bit network field is split into two eight-bit quantities: a "network number", which identifies the network that should receive the message, and a "domain number", which specifies the network of networks that is the recipient 🧚.
The bridge adapters that move messages between networks have address recognition hardware 🔍. That hardware checks all 24 bits in bytes 2-5 of the network message header to decide whether the bridge should accept the message for forwarding. At any moment, each bridge has a list of networks and domains it should accept for forwarding to a network on its other end. Every Adapter (including Newer Technology host adapters) contains the following in its address recognition hardware 💖:
- domainmask -- a 256-bit mask of domain numbers that should be accepted for forwarding (not local processing) by this adapter.
- MyDomain -- the value of the domain on which this host adapter or bridge end is installed.
- NetworkMask -- a 256-bit mask of network numbers that should be accepted for forwarding by this adapter.
- MyNetwork -- the value of the network on which this host adapter or bridge end is installed.
- AddressMask -- a 256-bit mask of the local network addresses that should be accepted by the adapter.
- MyAddress -- the "base address" of the box, which must be supplied in any message that is directed to control processes within the adapter, such as a loopback message.
Address recognition works using this algorithm 🧠:
IF Domain IN DomainMask OR
IF (Domain = MyDomain AND Network IN NetworkMask) OR
IF (Domain = MyDomain AND Network = MyNetwork AND
Address IN AddressMask) THEN accept-message
ELSE ignore-message.This algorithm means an adapter's hardware address recognition logic will accept any messages to the box itself 🏠, any secondary or aliased local addresses owned by the adapter 🦋, and any message directed to a remote network or domain that this particular adapter is prepared to forward 🚀.
32-BIT MESSAGE FIELDS 💜
TRUNK MASK
This is the same as in the basic network message 📦. Messages that are going to be delivered outside the immediate network should have 0xFF in this byte, so that all possible trunks in intermediate networks get tried. Locally delivered 32-bit messages can still contain specially tailored trunk masks to meet local delivery needs 💅.
MESSAGE FLAGS
The currently defined bits stay as they were before 🎀. Three new bits have been defined since then ✨.
CRC (END-END MESSAGE INTEGRITY) 🔐: Newer technology host adapters can generate a 32-bit CRC for the entire network message as soon as it arrives over the channel or bus interface from the host. This 32-bit CRC is attached to the end of the associated data block and stays with the message through the entire delivery process. It gets checked, and then removed, by the host adapter that is the ultimate recipient of the message. This end-to-end integrity checking is designed to give a high degree of assurance that data has been correctly moved through all intermediate LANs, geographic links, and internal adapter hardware and processes. It's giving reliability 🫶.
SRC (SOURCE FROM ADDRESS CORRECT) 🕵️♀️: This bit takes advantage of the physical nature of the network address. It lets you optionally verify that the 32-bit FROM address in the network message really is the location the message came from. If the transmitting host doesn't set this bit, no particular processing happens to the message. If the bit is set, then any intermediate adapter involved in delivering the message has the privilege of turning the bit off, if the received message's FROM address isn't a TO address that would be delivered to the originator when the message goes the opposite direction 🙈.
If a host computer receives the message with this bit still set, the FROM address is guaranteed correct, in the sense that sending back a message with TO and FROM reversed will get delivered to the process that actually originated it 💘. With careful attention to the physical security of adapters and intermediate links between networks, a high degree of security can be built into systems that simply look at a message's FROM address to decide whether its request is legit 🔥.
GNA (GLOBAL NETWORK ADDRESSING) 🌍: When this bit is ON, it means 32-bit addressing is present in the message. When this bit is on, bytes 2-3 (Domain and Network numbers) should also be nonzero 🍓.
TO ADDRESS
Four bytes hold the TO address 📬. It's used to deliver the network message, as described in "Address Recognition and Message Forwarding" on page 8. The "logical" part of the TO address designates a protocol server, exactly like it does in the basic format network message header 🧚♀️.
The existing "address" field has its high order bit reserved as an outnet bit, for compatibility with existing A-series network adapter equipment 🦋. Without this bit, A-series adapters would try to accept messages that were just "passing through" the local network on their way somewhere else. They'd do that simply because the address field matched, even though the Domain and Network numbers (which A-series adapters ignore) were totally different 😭.
This "outnet" bit gets used like this 👑:
- All network adapters (of any type) in an extended set of networks that contains A-Series adapters and will ever use 32-bit addressing must have their addresses in the range 00-7F (hex.).
- If a message is going to a destination on a nonlocal network and domain of such an extended network, the high order bit of the address field is turned on.
- When the last bridge in the chain realizes it's about to forward the message to its final destination (the Domain and Network numbers are local), it turns the Outnet bit off. That results in local delivery to the destination adapter 🎯.
FROM ADDRESS
The FROM address follows the same logic as the TO address. Any message can be sent back to its source by reversing the FROM and TO fields 🔁. Since so many protocols look at byte 8 of the message to figure out its type, the FROM field has been split, so the Domain and Network numbers extend into bytes 10-11 💫.
MESSAGE TYPE
This field used to be informally defined 🤷♀️. It's now been extended to 16 bits, so a unique value can be assigned to any present or future protocol that layers on top of HYPERchannel messages, whether for private or public use 🌸.
AGE COUNT
This field does the same job as the IP "time to live" ⏳. It stops datagrams from endlessly circulating around an improperly configured network. Each time a 32-bit message passes through a bridge, the Age Count is decremented by one. When the result is zero, the bridge discards the message 🗑️.
NEXT HEADER OFFSET AND HEADER END OFFSET
These fields can optionally provide "loose source routing" 🗺️. That's where the transmitter supplies a list of 32-bit TO addresses to explicitly control the path a message takes through the network. If this feature isn't used, both fields contain the value 16 (decimal). That tells you no extra TO addresses are present, and that the protocol data following the HYPERchannel header begins in byte 16 🥰.
Although a HYPERchannel IP process could use this source routing capability to direct messages to hosts or gateways, it isn't felt to be valuable enough to IP to build into a HYPERchannel IP protocol 🙃.
In the future, all higher level protocols should be able to examine Header End Offset to find where their higher level protocol information starts 🧚✨.
BROADCASTING 📡✨
okay so NSC message forwarding protocols use low level link protocols to negotiate getting a message to its next stop on the network 🛰️. and NSC network boxes often "fan out," so a bunch of hosts share the same transmission gear (like the A400 adapter) 🤯. both of these things make real broadcast support a not-so-trivial task, and honestly no current NSC implementations support broadcast at all 😭.
BUT broadcast apps have matured SO much over the last few years that they're basically unquestionable on a local, and sometimes campuswide, basis 💅. so new NSC techs will support broadcast! this info lives here because it's essential for the Address Resolution Protocol we'll get to later 🦋.
broadcast is only supported with the extended (32-bit address) message format. a broadcast message looks like this:
byte Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+--------------+---------------+---+---+--+--+---+---+---+---+
2 | TO Domain Number | TO Network Number |
| or 0xFF | or 0xFF |
+------------------------------+-----------------------------+
4 | 0xFF | Broadcast channel number |
| | |
+------------------------------+-----------------------------+
6 |O| Physical addr of source | |FROM port|
|N| adapter (FROM) | | number |
+------------------------------+-----------------------------+
8 | Message type |
| |
+------------------------------+-----------------------------+
10 | FROM Domain Number | FROM Network Number |
| | |
+------------------------------+-----------------------------+
12 | - reserved - | age count |
| | |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| (normally 16) | (normally 16) |
+------------------------------+-----------------------------+
16 | Start of user protocol |
| bytes 16 - 64 of message proper |
| |
+------------------------------+-----------------------------+
Associated Data
+-----------------------------------------------------------------+
| |
| As with basic format network messages |
| Maximum associated data size 1K bytes. |
| |
+-----------------------------------------------------------------+TRUNKS TO TRY AND MESSAGE FLAGS 🍓
these fields work exactly like a normal 32-bit message, no twists! 🙌 every bit in the Message Flags field is valid in broadcast modes too.
BROADCAST ADDRESS 📢
for the Domain, Network and Adapter Address fields, the value 0xFF is reserved for the broadcast mechanism. ✨ a 0xFF in the adapter address field tells the local network hardware to send this message to all connected network equipment on that individual network.
a 0xFF in the network or domain field means "hey, I want this broadcast to go beyond my local network" 🌍. the bridging link adapters receive the broadcast along with everyone else, then check the "Broadcast Channel" field and their internal switches to decide if it should get forwarded to other remote networks 🧚.
if the Network and Domain fields have your local network and domain, the broadcast stays within the local network only 🏠. if a remote Network and Domain is specified, the message gets delivered as a single message to that remote network and broadcast there 💌.
BROADCAST CHANNEL 🎀
okay so individual hosts and protocol servers usually aren't into every broadcast message floating around, right? 🙄 so there's a filtering mechanism in the header and network adapter equipment, meaning only the right classes of broadcast messages reach the end point 💖.
broadcast channel numbers in the range 00-0xFF get assigned by NSC, kind of like the "message type" field 📋. host protocol servers specify a specific TO address containing a channel number (like 0xFF04) when they bind themselves to the HYPERchannel device driver 🔥. the driver and underlying equipment will only deliver broadcast messages with the correct channel number to that protocol server. and if a protocol server wants to receive several different broadcast messages, it must bind itself to the driver several times, once for each desired address 👑.
link adapters that can handle multinetwork broadcast messages may have switches that decide which broadcast channels get propagated into the next network. multinetwork broadcast needs to be configured with real care, so these switches are off by default 🫶.
FROM ADDRESS 💜
the FROM address gets built just like a normal 32-bit network message. and the Source Address Correct bit is processed just like it is in a normal message ✨.
MESSAGE TYPE 💅
message type works the same way as normal messages. presumably broadcast apps will have their own unique message types that you don't usually find in normal messages 🦋.
AGE COUNT ⏳
age count is vitally important in a multinetwork broadcast 😭. "loops" in the network can cause a huge amount of activity until all the progeny of the original broadcast message die out 🌀.
PROTOCOL SPECIFICATION 🧚
this section covers how IP datagrams get encapsulated on the HYPERchannel network message 📦. it has three sections describing three protocol packagings:
- The technique used to encapsulate IP datagrams on the basic 16-bit network message. this is a de facto standard that's been in use for several years, and it's documented here to make it official 📜.
- The encapsulation technique for IP datagrams on 32 bit network messages 🌸.
- The definition of an Address Resolution Protocol on HYPERchannel 🔍.
BASIC (16-BIT) MESSAGE ENCAPSULATION 🍰
Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+------------------------------+-----------------------------+
2 | Access code 0000 |
| (no longer supported) |
+------------------------------+-----------------------------+
4 | Physical addr of | Protocol server |Dest Port|
| destination adapter | logical address | number |
+------------------------------+-----------------------------+
6 | Physical addr of | Originating | Src Port|
| source adapter | server address | number |
+------------------------------+-----------------------------+
8 | IP on HYPERchannel | Offset to start of IP |
| type code 0x05 | header from message start |
+------------------------------+-----------------------------+
10 | IP type designator | Offset to start of IP |
| 0x34 | header from byte 12 |
+------------------------------+-----------------------------+
12 | Padding (variable length incl. zero bytes) |
| |
+------------------------------+-----------------------------+
Off | First (64-Offset) bytes of IP datagram |
| |
| |
| |
+------------------------------+-----------------------------+
Associated Data
+------------------------------+-----------------------------+
| |
| Remainder of IP datagram |
| |
| No associated data is present if IP |
| datagram fits in the Message Proper |
| |
+------------------------------+-----------------------------+TRUNK MASK 🎭
from an IP driver's point of view, any trunk mask is valid as long as it results in successful delivery of the HYPERchannel network message to its destination 🎯. there's no reason to check this field for validity when the message is received 🙅♀️. specifying the Trunk Mask on output is a local thing, and the transmitting driver's address resolution tables could be what sets it 🗂️.
MESSAGE FLAGS 🚩
no use is made of the Flags field (byte 1) other than to set the Associated Data bit appropriately 💖. Burst Mode and the Exception bit should not be used with IP ⚠️.
ACCESS CODE 🔒
some current implementations of IP on HYPERchannel support the access code, but nobody really seems to be using it right now 🤷♀️. since this field is currently reserved for the use of 32-bit addresses, no value other than 0000 should go in this field 💀.
TO ADDRESS 📬
a local IP driver usually gets the TO field through a table lookup algorithm, where a 16-bit TO address that matches the IP address of a local host or gateway gets found 🔎. the high order bits of the TO address refer to the adapter number of the adapter attached to the destination host 🌟.
the logical TO field should contain the protocol server address of the HYPERchannel IP driver for that host, as set by the host's system administrator 👑. a lot of HYPERchannel TCP/IP drivers in the field today aren't "open," meaning any network message delivered to that host gets presumed to be an IP datagram no matter what the logical TO field says 🙃. still, any transmitting IP process should be able to generate the entire 16-bit TO field, so it can make a message that actually reaches a destination IP process 🦋.
the process of figuring out which HYPERchannel address will receive an IP datagram based on its IP address is a major topic, covered in "Address Resolution" 🔮✨
FROM ADDRESS 💌
okay so the FROM address gets filled in with whatever address the local driver expects to receive from the network. but honestly, nobody really uses the FROM address for anything in particular 🤷♀️
MESSAGE TYPE 🎀
Network Systems wants a value of 5 (decimal) in this byte so the network message clearly says it's carrying IP traffic. No other well-behaved protocol using HYPERchannel should duplicate this value of 5 🙅♀️
Lowkey, a lot of current IP-on-HYPERchannel implementations put a zero or some other random value here, because nobody reserved a number for IP back in the day 😭 Transmitting versions of IP should always put a 5 in this field. Receiving IPs should presume a delivered message is an IP datagram until proven otherwise, no matter what's in the Message Type field 💅
Devs, pay attention to this one 👀 It's often convenient to permit reception of the value 0xFF00 in bytes 8 and 9 of the IP datagram. If you transmit a message with this value, it gets looped back at the destination adapter and returned to the protocol server designate in the FROM address. That lets host applications talk to others on the same host, which is iconic for debugging network interfaces or other protocols 🧚
IP HEADER OFFSET 🦋
Byte 9 holds the offset to the start of the IP header within the message proper. So the Message Proper address plus the IP header offset gives you the address of the first byte of the IP header (at least on byte addressable machines) 🌸
This field is redundant with the offset field in byte 11. It's only here for cosmetic compatibility with 32-bit implementations. On reception, the value in byte 11 should take precedence 👑
As part of the move to bigger HYPERchannel headers, this field will become significant with the 32-bit addressing format. The header is no longer 10 bytes long and byte 11 gets used for other stuff, so byte 9 is about to have its main character moment ✨
IP TYPE DESIGNATOR 🍓
Early IP drivers on HYPERchannel wanted to leave bytes 8 and 9 alone for NSC use, so they put a "message type" field later in the message. A value of 0x34 was picked by earlier devs for reasons that are now only of historical interest 📜 Once again, implementations should generate this value on transmission, but not check it on input. They just assume an IP datagram is in the message 🫶
IP HEADER OFFSET 🌈
This value is used by a bunch of commercial IP-on-HYPERchannel implementations to align the start of the IP header within the network message. The offset is relative to byte 12 of the network message, so a value of zero means the IP header begins in byte 12 🎯 This value should be generated correctly on transmission, and always respected on input processing.
The maximum permissible offset in this field is 52, which means the IP header begins at the start of the associated data block 💜
IP DATAGRAM CONTENTS 💖
Starting at the offset given in byte 11, the IP datagram is treated as one contiguous block of data. It flows from byte 63 of the message proper into the first byte of associated data, so the entire message plus data is treated as a single contiguous block 🧩
If the IP header is small enough to fit in the entire network message, then only the message proper gets transmitted. The length of the message proper sent should always be 64 bytes, even if the IP datagram and HYPERchannel header don't fill all 64 bytes of the message proper 🙈
If the datagram flows over into the associated data, then both the message and the data are sent. Some machines can't send a length of data to the HYPERchannel that's an exact number of bytes (because of 16-64 bits on the channel bus), so the length of the associated data received should not be used as a guide to the length of the IP datagram. Extract the length from the IP header instead 🔥 A driver should verify, of course, that the associated data received is at least as long as is needed to hold the entire IP datagram.
COMPATIBILITY WITH EXISTING IMPLEMENTATIONS 🫧
The basic format described here is clearly a compromise between several IP-on-HYPERchannel implementations. Not all existing implementations are interoperable with the standard described above. Right now there are two known "families" of IP HYPERchannel drivers in existence 👯♀️
THE "CRAY-NASA AMES" PROTOCOL 🚀
This protocol is in the widest production use and has the largest number of supported drivers in existence 👑 It's interoperable and identical with the standard described above, with one sole exception: these drivers set bytes 8 and 9 to zero. Since most implementations of this driver ignore those bytes, they've been assigned values to formalize the use of the message type field and make it consistent with the 32-bit protocol 💅
THE "TEKTRONIX-BERKELEY" PROTOCOL 🧁
This protocol was historically the first IP-on-HYPERchannel implementation, developed at Tektronix. It later made its way to Berkeley and BSD UNIX. It is not interoperable with the standard described above, because of several distinct differences 🙃
First, bytes 8 through 11 are always zero. The IP header always starts on byte 12. Some comments in these drivers label byte 11 as an "IP header offset" field, but apparently that value is never processed 🤭
The big difference (and the incompatibility) is how the IP datagram gets packaged into the network message. Back in the early 80's, sending and receiving very small blocks of associated data on VAXes was historically difficult, so this protocol takes a curious approach to placing the IP header and the headers of higher level protocols (like TCP or UDP) 😭
- If the entire length of the IP datagram is 54 bytes or less, the datagram and the HYPERchannel header can fit in the 64 byte message proper. In this case, no associated data is sent. Only a message proper is used to carry the data. The length of the message proper transmitted is the exact length needed to enclose the IP datagram, so no padding bytes get sent at the end of the message 🌷
- If the length of the IP header is greater than 54 bytes, then:
- All higher level protocol information (the TCP/UDP header and their associated data fields) is placed in the associated data block, with the TCP/UDP header beginning at the start of the associated data block 📦
- On transmission, the length of the message proper transmitted is set to the length of the HYPERchannel header plus the IP header. It is not padded out to 64 bytes. The length of the associated data sent should be enough to accommodate the TCP/UDP header and its data fields 🫠
WHICH PROTOCOL IS BEST? 🏆
okay so when it came to choosing which one to follow, the "Cray-Ames" approach won, and it's giving for a few good reasons 💖
- Cray Research did seriously exemplary work dealing with other vendors to bring IP on HYPERchannel from Cray computers to other hosts. As a result, there are 4 or 5 vendor supported implementations of IP on HYPERchannel that use this approach 🤝
- The two part structure of the message proper is super useful when a machine wants to make protocol decisions before staging the transfer of an immense block of associated data into memory. Lots of network coprocessors and intelligent I/O subsystems find it simpler to read in the entire network message before deciding what to do with it. Just catenating the two components does this best, and it allows streaming of messages from future technology network adapters 🧠
- Some TCP users (mostly secure DoD sites) plan to load up IP datagrams with optional fields in the future. The Tektronix-Berkeley implementation has problems if the IP header length goes past 54 bytes 🚨
EXTENDED (32-BIT) MESSAGE ENCAPSULATION 🧩
Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try |1| Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+------------------------------+-----------------------------+
2 | Destination Domain | Destination Network |
| Number | Number |
+------------------------------+-----------------------------+
4 |O| Physical addr of | Protocol server |Dest Port|
|N| destination adapter | logical address | number |
+------------------------------+-----------------------------+
6 |O| Physical addr of | Originating | Src Port|
|N| source adapter | server address | number |
+------------------------------+-----------------------------+
8 | IP on HYPERchannel | Offset to start of IP |
| type code 0x06 | datagram header |
+------------------------------+-----------------------------+
10 | Source Domain Number | Source Network Number |
| | |
+------------------------------+-----------------------------+
12 | - reserved - | Age Count |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| | (usually 16) |
+------------------------------+-----------------------------+
16 | Padding to IP header start (usually 0 bytes) |
| |
+------------------------------+-----------------------------+
Off| Entire IP datagram if datagram length <= (64-Offset) |
| |
| else first (64-Offset) bytes of IP datagram |
+------------------------------+-----------------------------+
Associated Data
+------------------------------+-----------------------------+
| |
| Remainder of IP datagram |
| |
| No associated data is present if IP |
| datagram fits in the Message Proper |
| |
+------------------------------+-----------------------------+TRUNK MASK 🦋
From an IP driver's point of view, any trunk mask is valid as long as it results in successful delivery of the HYPERchannel network message to its destination. There's no reason to check this field for validity on reception of the message. Specifying the Trunk Mask on output is a local thing that can be set by the transmitting driver's address resolution tables 🗺️
The use of 0xFF in this value is strongly encouraged for any message other than those using exotic trunk configurations on a single local network 💜
MESSAGE FLAGS 🎀
okay bestie, so a few brand new bits got added here and they're lowkey iconic ✨
EXTENDED ADDRESSING. This bit SHOULD be set ON whenever a 32-bit address (Network and/or Domain numbers nonzero) is present in the message. It SHOULD always be OFF with the 16-bit message header. If this bit is improperly set, delivery of the message to the (apparent) destination is unlikely. 💀
END-TO-END CRC. Some newer technology adapters can put a 32-bit CRC of the associated data at the end of that data block when this bit is on. Those same adapters will check the trailing 32 bits of associated data (when the bit is on) to see if the message contents got corrupted at any point during transmission. the data integrity is giving main character energy 🦋
Transmitting device drivers SHOULD include the ability to set this bit on transmission as a configuration option, similar to the specific HYPERchannel device interface used. The bit SHOULD be generated to be turned ON if the HYPERchannel IP driver is attached to an adapter equipped to generated CRC information. It SHOULD be left OFF in all other circumstances. 🌸
If a message arrives at the host with the CRC bit still on, that means the CRC information was placed at the end of the associated data by the transmitting adapter and never got removed by the receiving adapter. So the associated data will be four bytes longer than expected. Since the IP datagram length is self contained in the network message, this SHOULD NOT impact IP drivers. 🫶
It is possible for host computers to both generate and check this CRC information, so it matches the hardware assisted generation and checking logic in newer network adapters. Contact NSC if there are particular applications requiring exceptional data integrity that could benefit from host generation and checking. ngl that's a whole vibe 💖
FROM ADDRESS CORRECT. This bit SHOULD be set by all transmitting IP drivers who have tried their best to provide a completely correct FROM address that properly reflects the adapter interface used. No action SHOULD be taken on this bit by the receiving IP driver at this time. Additional work needs to be done to figure out what action an IP driver should take if it detects a real or imagined "security violation" should a message arrive with this bit absent. 🔥
TO ADDRESS 💜
The TO address logically makes up bytes 2-5 of the network message. 🍓
NETWORK AND DOMAIN NUMBERS. The Network and Domain numbers SHOULD both be nonzero when 32-bit addressing is used. If the message is local in nature, then the local Network and Domain numbers SHOULD be placed in this field. ✨
ADAPTER ADDRESS. This contains the adapter address, same as in the basic message. The high order bit of this eight bit field (the "outnet" bit) SHOULD be set to zero if the destination network and domain are the same as the transmitting host's. The high order bit SHOULD be set to one if the destination host is not in the local network or domain. 🧚
LOGICAL TO AND SUBADDRESS. The logical TO field SHOULD contain the protocol server address of the HYPERchannel IP driver for that host, as decided by the host's system administrator. 👑
FROM ADDRESS 🌈
The FROM address gets filled in with the address that the local driver expects to receive from the network, but no particular use is made of the FROM address. It's giving "just vibes, no job" 💅
MESSAGE TYPE 🦋
The value 6 MUST be placed in this byte to uniquely indicate that the network message is being used to carry IP traffic. No other well-behaved protocol using HYPERchannel SHOULD duplicate this value of 6. 🔒
Note that all IP drivers SHOULD be prepared to send and receive the basic format network messages using the 16-bit HYPERchannel addresses. The driver can tell an incoming network message apart by the value of byte 8. 32-bit messages will always have a 6 in byte 8, while 16-bit messages SHOULD have a 5 here. For interoperability with older drivers, a value of 0 here SHOULD be treated as 16 address bit messages. 🌸
IP HEADER OFFSET 🎀
Byte 9 contains the offset to the start of the IP header within the message proper, so that the Message Proper address plus the IP header offset gives the address of the first byte of the IP header (at least on byte addressable machines.) 🧚
Unlike the 16-bit header, receiving IP drivers SHOULD assume that this field contains a correct offset to the IP header, and check the information at that offset for conformance to an IP datagram header. 💖
Valid offsets are in the range of 16 through 44 bytes, inclusive. The limitation of 44 bytes is there so that routing decisions on the vast majority of IP datagrams can be made by looking only at the message proper. The basic IP datagram will fit into the message proper if it begins at an offset of 44. ✨
IP DATAGRAM CONTENTS 🌷
The message and data are treated as logically contiguous entities, where the first byte of associated data immediately follows the 64th byte of the message proper. 🦋
If the entire IP datagram is less than or equal to (64-offset) bytes in length, it will fit into the Message Proper. If so, only a message proper containing the HYPERchannel header and IP datagram is sent on the network. 🍓
If the IP datagram is longer than this, it spills over into the associated data. On transmission, a 64 byte message proper is sent, followed by as many bytes of associated data as are needed to send the entire datagram. 📦
On reception, the message proper can be read into the start of an IP input buffer, and the associated data read into memory 64 bytes from the start of the message. If the received message is in fact a 32-bit address message, no "shuffling" of the message is required to build a contiguous IP datagram. It's right there at buffer+16. no cap, that's so efficient 🌿
ADDRESS RESOLUTION PROTOCOL 🌟
Address Resolution Protocol has had a ton of success on the Ethernet, since it lets a local IP network configure itself just by having each node know its own IP address. Anyone who isn't familiar with the intent, protocol, and logic of the Address Resolution Protocol SHOULD refer to RFC-826, "An Ethernet Address Resolution Protocol" [2]. 📚
A later section of this document describes four techniques for getting a target HYPERchannel address when you're given the destination's IP address. The protocol is defined in this section for completeness. 🫶
Message Proper
+------------------------------+-----------------------------+
0 | Trunks to Try |1| Message Flags |
| TO trunks | FROM trunks |GNA|CRC| |SRC|EXC|BST|A/D|
+------------------------------+-----------------------------+
2 | Server Domain or | Server Network or |
| 0xFF | 0xFF |
+------------------------------+-----------------------------+
4 | Server Adapter Address or | Server logical addr/port or |
| 0xFF | 07 |
+------------------------------+-----------------------------+
6 |O| Physical addr of | Originating | Src Port|
|N| source adapter | server address | number |
+------------------------------+-----------------------------+
8 | NSC ARP type code |
| 07 | 00 |
+------------------------------+-----------------------------+
10 | Source Domain | Source Network |
+------------------------------+-----------------------------+
12 | - reserved - | Age Count |
+------------------------------+-----------------------------+
14 | Next Header Offset | Header End Offset |
| (usually 16) | (usually 16) |
+------------------------------+-----------------------------+
16 | Padding to start of IP info (usually 0 bytes) |
+------------------------------+-----------------------------+
+------------------------------+-----------------------------+
Off | ARP hardware address type for HYPERchannel |
| 8 |
+------------------------------+-----------------------------+
+2 | HYPERchannel protocol type |
| 06 00 |
+------------------------------+-----------------------------+
+4 | HYPERchannel address length | IP address length |
| 6 | 4 |
+------------------------------+-----------------------------+
+6 | ARP opcode (request or reply) |
+------------------------------+-----------------------------+
+8 | Domain | Network |
+- Sender's 32-bit HYPERchannel address -+
+10 | Adapter address | Logical addr/port |
+------------------------------+-----------------------------+
+12 | Source's MTU size |
+------------------------------+-----------------------------+
+14 | | |
+- Sender's 32-bit IP address -+
+16 | |
+------------------------------+-----------------------------+
+18 | Domain | Network |
+- Destination's 32-bit HYPERchannel address -+
+20 | (to be determined on request) |
| Adapter address | Logical addr/port |
+------------------------------+-----------------------------+
+22 | Destination's MTU size |
| (to be determined on request) |
+------------------------------+-----------------------------+
+24 | | |
+- Destination's 32-bit IP address -+
+26 | |
+------------------------------+-----------------------------+Laying out the fields of this ARP message is a pretty straightforward exercise if you know the standards of ARP and the 32-bit message header. A few fields are worth remarking on: 🤓
TO ADDRESS 💜
The TO address of an ARP message will be one of two classes of address. A "normal" address means the message is an ARP response, or an ARP request aimed at an ARP server at a well known address on the local network. For those HYPERchannel networks that are equipped to broadcast, a value of 0xFFFFFF07 in the TO address will (by convention) only get picked up by those protocol servers that are set up to interpret and respond to ARP messages. 🎀
The issue of which address to use in an ARP request is discussed in the Address Resolution section. 🌈
FROM ADDRESS 💖
okay so the FROM address MUST be the correct one for the user protocol server that's sending out the ARP request 📮. the requesting server SHOULD set the Source Correct bit in the Message Flags byte 🔐, because some ARP servers might someday only hand out ARP info on a need-to-know basis in secure environments. 🕵️♀️
for an ARP response, the FROM address holds the server's normal HYPERchannel address, even if that server was reached through broadcast 📡. ARP responses go back to whoever is listed in the FROM address in the message header, not to the address in the "Source HYPERchannel Address" field inside the ARP body 🙅♀️
MESSAGE TYPE 🧚
the 16-bit value 0x0700 is reserved just for ARP, no sharing 🫶. unlike IP messages, ARP can't start at some random offset inside the message proper, so byte 9 is basically an extension of the message type. it's giving "the type is bigger than it looks" energy 💅
HEADER END OFFSET 🌸
ARP uses the 32-bit addressing convention, where byte 15 holds the offset to the start of user protocol. that's also where the user protocol info ends. ngl this is NOT a stand-in for the IP offset fields 🙈. this field also marks the end of the HYPERchannel header, so future NSC message processing code might be extra suspicious of any "garbage" between the real header end and the start of user data 👀
HYPERCHANNEL HARDWARE TYPE CODE 🎀
this 16-bit number is assigned a formal ARP hardware type of 8. iconic 👑
HYPERCHANNEL PROTOCOL TYPE 🦋
on the Ethernet, this field tells IP apart from every other protocol that might need address resolution. to keep things logically consistent, it's identical to bytes 8 and 9, which is 0x0600, in a 32-bit address HYPERchannel message carrying an IP datagram ✨
HYPERCHANNEL ADDRESS LENGTH 🍓
this contains the value 6. that's enough room for the four-byte HYPERchannel address plus 2 bytes to show the largest IP datagram size that source and destination can handle 💖
SOURCE AND DESTINATION HYPERCHANNEL ADDRESS 🫶
this field holds the Domain, Network, and Adapter/port address of the source and destination, in that order 🗺️. a value of 0000 in the Domain and Network fields is special 🌈. it means "please send and receive 16-bit HYPERchannel headers instead of 32-bit ones." if you want 32-bit headers inside a single HYPERchannel network, you MAY specify the local domain and network numbers 🧁
MAXIMUM TRANSMISSION UNIT 🌟
okay this one is a whole vibe 🥹. HYPERchannel LAN tech lets messages of unlimited length get sent between hosts. host throughput is usually capped by how fast the network gear can be functioned, so bigger transmissions mean better bulk transfer performance 🚀. not every host can handle the biggest IP datagram, so instead of hardcoding one value into every host, we need a more flexible MTU (maximum transmission unit) negotiation 🤝. each host declares the maximum IP datagram size it can receive (not the associated data block size). transmitting IP drivers SHOULD be prepared to send the smaller of the source and destination IP sizes negotiated at ARP time 💅
the MTU refers to the maximum size of IP header plus data. it does NOT include the HYPERchannel hardware header or any offset between the header and the start of the IP datagram 🙃. since it's up to the transmitting hosts whether to use an offset of up to 44 bytes, a receiving host MUST in any event be prepared to receive a 64 byte Message Proper and an Associated Data block of MTU-20 (that's 64 - 44, aka the basic IP header length) 🫠
here's a typical 16-bit packet 🎀:
12 bytes hardware header.
12 bytes offset.
40 bytes IP/TCP header.
4096 bytes of data.
This gives an MTU of 4136.and a typical 32-bit packet 🌷:
16 bytes hardware header.
8 bytes offset.
40 bytes IP/TCP header.
4096 bytes of associated data,
This also gives an MTU of 4136.the offsets are picked so that the typical packet makes user data page aligned at the start of the associated data area 📄✨. that's an implementation decision, and it can totally be changed if needed 💖
the maximum maximum transmission unit is 65536, which is the current largest IP datagram size 🏋️♀️. to make that value fit in a 16-bit field, the offset length is left out of the MTU. this MTU isn't a rule that a local host has to be able to send or receive datagrams that big 🙅♀️. it just shows how much the receiving host can handle 🧁
A note on trunk masks 🦋:
there's no field for trunk masks, and that's on purpose 🎯. new NSC hardware will carry trunk reachability info itself, so hosts don't have to keep track of hardware configuration layouts 🧠. all HYPERchannel messages generated as a result of an ARP response SHOULD use 0xFF in the trunk mask 💅
ADDRESS RESOLUTION 🗺️
this section walks through the techniques an IP driver uses to figure out the HYPERchannel address and header a message needs to include, given an IP datagram with an IP address 🎀. some of these are local to specific hosts, so they can be changed without caring what other hosts are doing 🫶. others use the Address Resolution Protocol on existing HYPERchannel equipment to manage IP addresses better 🔧
it also covers how name resolution migrates across four steps:
- Truncation of the IP address to form a HYPERchannel address.
- Local resolution of HYPERchannel addresses through configuration files.
- Centralized resolution of HYPERchannel addresses through an "ARP server" driven by a configuration file.
- Distributed resolution of HYPERchannel addresses using a "real" address Resolution Protocol on future HYPERchannel media supporting a broadcast mode.
IP ADDRESS TRUNCATION ✂️
a bunch of IP on HYPERchannel implementations have modes where the HYPERchannel address comes from the low order 16 bits of the IP address, placed in the TO address of the message proper 🧸. that more or less treats a group of HYPERchannel boxes addressable through 16-bit HYPERchannel addresses as a Class B IP network 🌈
this approach is super simple 💖. IP addresses just get picked to match HYPERchannel addresses, and you don't need IP address configuration files. but it only works where the HYPERchannel is basically a Class B network, or where connecting to a bigger IP network isn't a concern. its long term use is discouraged for a few reasons 🙈:
- it simply won't work with any Class C address (the physical TO address isn't controllable) or a Class A address (where host addresses are usually carefully administered). it also won't support subnetworks, and it's pretty incompatible with 32-bit HYPERchannel addresses 💀
- by decoupling IP and HYPERchannel addresses through more complex address resolution, you get more site flexibility 🦋. the IP address becomes "logical," so an address can move around a site with the user or host 🧳. the HYPERchannel address keeps its physical character, so it pins down exactly where the source and destination sit within the extended HYPERchannel network 📍
LOCAL ADDRESS RESOLUTION 📖
here's how address resolution currently works with IP on HYPERchannel 🧠. given any IP address, the IP HYPERchannel driver looks it up in a (usually hashed) table. if it's found, the entry holds the first 6 bytes of the HYPERchannel header used to send the IP datagram to the next IP node on the internet 📬. 4.3BSD UNIX IP is clever enough to hand its lower level drivers both the IP address of the next gateway and the destination address on the internet (as long as the message isn't delivered locally on the HYPERchannel) 🧁. so the table stays pretty manageable, because it only MUST hold the IP hosts and gateway addresses that are directly accessible on the HYPERchannel 🫶✨
CONFIGURATION FILE FORMAT ✨
okay bestie, as long as we're using this address resolution trick, everything stays super local to the host 💅. How the info gets generated and stored in the table doesn't matter to other hosts at all, so each machine can handle its own business 🦋
Here's a typical file format 🎀. Honestly, this file should probably be program generated from a database 🧠, because asymmetric trunk configs and multiply homed hosts can make the physical routing and trunk usage look different. We're showing it so you can see what kind of info needs to live at the link layer 💖
The file is made of source lines, each one shaped like this:
<type> <hostname> <trunks/flags> <domain/net> <addr> <MTU>Here's an example:
<type> <hostname> <t/f> <dom/net> <addr> <MTU>
# Random front end
host hyper.nsco.com FF88 0103 3702 4148
# because we want to show the 4 byte format
host 192.12.102.1 FF00 0000 2203 1024
# Small packets, interactive traffic.
host cray-b.nas.nasa.gov FF88 0103 4401 4148
# The other interface, for big packets.
ahost cray-b.nas.nasa.gov FF88 0103 4501 32768
# A loopback interface, (What else)
loop loop37.nsco.com FF00 0000 3700 4148
# And of course an example of arp service.
arpserver hcgate.nsco.com FF88 0103 7F07Comments can start with either # or ; 🌸. Case is not significant in any field 🙈
<type> tells you what kind of entity you're defining. The currently defined types are "host," "ahost", "loop," "address," and "arpserver" 📝.
host💻 means this is an IP host. The field after it should be a name that can be resolved to an IP address.ahost🔁 means this is an extra network interface to the same host. It can be used for performance boosts 🚀.loop🌀 sets a flag in the entry for that host so that0xFF00gets placed in bytes 8 and 9 of the message. This makes the IP datagram head toward the specified host (which still has to be a valid host name) and get looped back within the remote adapter 🔄. It's useful as a debugging aid and as a crude way to check whether the remote network adapter is available 🛠️.arpserver📡 is an address used for directing ARP requests to the network. If several arpserver addresses are listed, they get tried in turn until a response comes back (or we run out of servers 😭). An arpserver with the broadcast addressFFFF FF07makes an ARP broadcast happen once broadcasting is available. Broadcast and specific addresses can be mixed together 💜.
<hostname> is the logical name of the destination 🎯. For a host, it's the logical name handed to the local naming service so it can work out the matching IP address. This field can also be four decimal numbers separated by dots, in which case it's taken as the explicit IP address 🔢.
<trunks/flags> is the value that goes into bytes 0 and 1 of the message header when sending to this host. You don't need to supply the associated data bit, because the driver takes care of that. Every other bit gets sent exactly as you provide it 🎀. This field is a hex number.
<domain/net> is the value that goes into the Domain and Network number field of the message. A value of 0000 here means the destination should be reached by building a 16-bit HYPERchannel header, not a 32-bit one 🧩.
<address> is the value that goes into the 16-bit TO field to reach <hostname> 📬. This field is a hex number.
<MTU> is the largest IP datagram the destination host is ready to receive 📏. This field is a decimal number and it's optional 🫶. If it isn't there, 4148 gets assumed. Check the earlier discussion on Maximum Transmission Unit for more detail 🌈.
ARP SERVERS 🖥️
okay so the main problem with local host address resolution is that any changes or additions to hosts on the local net have to be copied to every HYPERchannel host on that network 😩. For half a dozen hosts, that's manageable. For bigger networks, it gets totally unmanageable 💀. The fix that works with existing HYPERchannel tech is to have a server on the HYPERchannel network hand out the HYPERchannel destination address that goes with an IP address 👑.
This is technically a point-to-point request/response conversation between two network nodes 💬. Still, the Address Resolution Protocol, which was originally designed for Ethernet (but thoughtfully built to work with any pair of link and network addresses), does an excellent job 🌟.
ARP servers can be reached just by putting the server's address in the 32-bit TO address of the network message 🎯. ARP servers only "listen" to messages that arrive on their well-known normal address 👂. They don't respond to ARP broadcast messages. Properly equipped IP drivers should respond to broadcast messages when they show up 📣.
If an ARP server gets a message with an IP address it doesn't know how to resolve, it ignores the message 🙈. That way, another ARP server might get addressed on the source's next try 🔄.
If the address is resolvable, the server puts the known HYPERchannel address and MTU size in the response, then sends it back to the location in the HYPERchannel header FROM address 💌.
Unlike a broadcast ARP, the ARP server has to handle two requests when two hosts that don't know each other yet try to connect 🤯. The destination never got the ARP request, so it has to contact the ARP server when its higher-level protocols first generate a datagram to respond to the source's first IP datagram that made it through to the destination 📨.
The source configuration file from the previous section was specifically designed to work as a database for an ARP server as well as for an individual host 🗂️. Iconic multitasking 💅.
BROADCAST ARP 📢
When a local HYPERchannel network has a broadcast capability, any IP driver that wants to do HYPERchannel address resolution can be configured to send the ARP message on a broadcast instead of a well-known address 🔊. IP drivers on other hosts are assumed to know whether their local HYPERchannel interface can send broadcast messages. If it can, they set up to "listen" on the FF07 broadcast TO address for ARP 👂✨.
Processing a received ARP broadcast message works the same way as RFC-826, with these twists:
- Messages get responded to if and only if the destination IP driver is authoritative for the designated IP address 👑.
- Whenever an ARP message is processed, the IP driver takes the source HYPERchannel address and MTU size and adds them to its address resolution tables 📒. That way the driver is ready to turn around the IP datagram that arrives from the destination host once contact is made 🔁.
Each IP driver can have address resolutions set through a static routing table (the configuration file from above) 🗃️. If ARP info shows up that contradicts a static entry (as opposed to previously set dynamic ARP info), then the ARP info should be ignored 🚫. The reasoning is that the only useful purpose of static routing in a broadcast ARP environment is to add authentication, since it's super easy to lie with ARP 🕵️♀️. no cap, that's a whole mood 💀.
APPENDIX A. NSC PRODUCT ARCHITECTURE AND ADDRESSING 🌸
This section is a concise review of the state of the art in NSC networks and the techniques they provide for delivering messages 📚. If you're already super familiar with HYPERchannel, you can just skim it 👀. There's still stuff on new technologies and addressing formats that most of NSC's customers don't know about yet 🫢.
NETWORK SYSTEMS HYPERCHANNEL TECHNOLOGIES 🌐
Network Systems makes several different network technologies that use very different media and link controls, but they all give you a common host interface in both the protocol and hardware sense of the term 🧩. These four technologies are:
- HYPERchannel A 🔥 -- A 50-megabit, baseband, CSMA with collision avoidance network using a coaxial cable bus. Individual HYPERchannel "network adapters" can control up to 4 of these coaxial cable "trunks," giving you up to 200 megabits of capacity on a fully interconnected network 💪. HYPERchannel A is NSC's earliest product and has been in production since 1977 🕰️. It's mainly used to connect larger mainframe computers and high-speed mainframe peripherals like tape drives and laser printers 🖨️.
- HYPERchannel B 💜 -- A 10-megabit, baseband, CSMA with collision avoidance network using a single coaxial cable bus. This tech is used for direct host-to-host communication under the name HYPERchannel B, and for terminal connections under the name HYPERbus 🖥️. It's currently used for three major applications: local networks of ASCII terminals, networks of IBM 3270 terminals, and host-to-host communication for smaller computers 🫶.
- DATAPIPE[3] 🦋 -- a 275-megabit fiber optic "backbone" network that connects lower-speed local area networks within a 20 mile range, and gives you an ultra-high-performance network for the next generation of supercomputers and optical storage systems ✨. A prototype version of DATApipe is currently under development at a customer site 🧪.
- Bridges and Network Distance Extensions 🌈 -- NSC quickly figured out that its customers wanted very high speeds over geographic areas, not just the several-mile range you can get with a coaxial cable network 🗺️. Starting in 1978, NSC began building a series of "link adapters" that act as integral bridges between local area networks 🌉. These link adapters support common high-speed communication media like Telco T1 circuits, private microwave, high-speed satellite links, and fiber optic point-to-point connections 🛰️.
ATTACHMENT TO HOST COMPUTERS 🖇️
Network Systems' high-speed interfaces use the attachment techniques of the manufacturer's highest-speed peripheral controllers 🏎️. That's how they reach burst transfer rates of tens of megabits per second 🚀. These attachment techniques fall into three categories:
"MAINFRAME" DATA CHANNEL ATTACHMENT 💖
+-----------+-------+ +------------+ | | | |
| | | |HYPERchannel+--+ | | |
| | +-------------------+ Network +--|-+ | |
| Host | I/O +-------------------+ Adapter +--|-|-+ |
| | | Standard host | +--|-|-|-+
| Computer |Control| data channel +------------+ | | | |
| | |
| | |
| | |
| | |
+-----------+-------+Okay so the network adapter is basically a box of interface boards and firmware that gets cabled to the manufacturer's data channel 🔌. It's the same way you'd hook up a disk or tape controller, bestie 🧚. Mainframe network adapters don't pretend to be an existing manufacturer's device (like a tape drive) 🙈. Instead, software makes the channel and adapter work together to send and receive network messages ✨. And ngl, models of HYPERchannel adapters are available for essentially all large scale computers worldwide 🌈.
MINICOMPUTER AND WORKSTATION ATTACHMENT 🦋
Since the network adapter is packed with lots of expensive, high speed logic, a different technique is used to attach minicomputers and workstations 💅.
+-------------+ +---------------+ +--------------+
| | | | | |
| Minicomputer| | Supermini | | Workstation |
| | | | | |
+-----+-------+ +-------+-------+ +-------+------+
| | DMA | | | DMA | | DMA | |
| |control| | |control| |control| |
+-----+---++--+ +-------+--++---+ +--++---+------+
|| || ||
|| || ||
|+----------+ || +---------+|
+----------+| || |+---------+
|| || ||
+-++--+-----+--++-+--++-+
| | | | |
+-----+-----+-----+-----+
| x400 |
| Network Adapter |
| |
+-------+-+-+-+---------+
| | | |
------------------|-|-|-+----------------
------------------|-|-+------------------
------------------|-+--------------------
------------------+----------------------In this case NSC provides a DMA controller designed for direct connection to that minicomputer's backplane bus 🔥. These DMA controllers accept functions and burst blocks of data from host memory and send them to a channel cable that plugs into one of four ports on a "general purpose computer adapter" 💜. That adapter multiplexes transmissions to and from the HYPERchannel trunks from up to four attached processors, which is giving multitasking queen energy 👑.
NETWORK COPROCESSORS 🎀
For about 10 different bus systems, Network systems provides a "smart" DMA controller with onboard memory and a Motorola 68010 protocol processor 🍓.
+------------+-----+---------------+-------+
| | | Coprocessor | | +--------+
| |Host | MC 68010 |Adapter+--------+ x400 |
| HOST |DMA | 256K memory | DMA +--------+ Adapter|
| | | | | +--------+
| Memory +-----+---------------+-------+
| |
+------------+This class of interface works through the network coprocessor's direct access to host memory 🧠. Network transmit and receive request packets get placed in a common "mailbox" area and then extracted by the coprocessor 📬. The coprocessor reads and writes system memory as required to service network requests in the proper order ⭐. Right now the coprocessors provide a service to read or write network messages (called Driver service, since it's more or less identical to HYPERchannel dumb DMA drivers) 🫶. They also provide a service for NETEX, which is NSC's OSI-like communications protocol 💅.
APPENDIX B. NETWORK SYSTEMS HYPERCHANNEL PROTOCOLS 🌸
The protocols NSC implements within its own boxes are designed for the needs of the different technologies 🔧. Here's a compact summary, so you can see the whole family at once 👀:
HYPERchannel B HYPERchannel A DATApipe
10 Mbits/second 50-200 Mbits/second 275 Mbits/second
+----------------------+----------------------+---------------------+
| |
| HYPERchannel network message |
| connectionless datagram protocol |
| |
+----------------------+----------------------+---------------------+
| "HYPERchannel | | |
| compatibility mode" | HYPERchannel A | DATApipe |
| Virtual circuit | reservation and | acknowledgment |
| estab. & control | flow control | & flow control |
+----------------------+ protocol | protocol |
| | | |
| Virtual Circuits | | |
| Flow Control | | |
+----------------------+----------------------+---------------------+
| CSMA / VT | CSMA / CA | |
| frame (datagram) | frame (datagram) | TDMA packet delivery|
| delivery and | delivery and | |
| acknowledgment | acknowledgment | |
+----------------------+----------------------+---------------------+
| | | Fiber optics |
| 75 ohm coax | 1-4 75 ohm coax | (various cable sizes|
| cable | cables | and xmission modes)|
+----------------------+----------------------+---------------------+Without getting into great detail on these internal protocols, a few points are particularly interesting to system designers 🧁:
- All three technologies supply the same interface to the host computer or network coprocessor: a service to send and receive network messages that are datagrams from the host's vantage, in that each contains sufficient information to deliver the message in and of itself 📦. Since this datagram and its header fields are of paramount interest to the host implementor, it is discussed in detail below 🤓.
- All technologies use acknowledgments at a very low level to determine if packets have been successfully delivered 🎯. In addition to permitting a highly tuned contention mechanism for the coax medium, it also permits HYPERchannel A to balance the load over several coax cables, a feat that has proven very difficult on, for example, Ethernet 🙌.
- All boxes go to some lengths to assure that resources exist in the receiving box before actual transmission takes place 🛟. HYPERchannel B uses a virtual circuit that endures for several seconds of inactivity after one host first attempts to send a message to the other. Traffic over this "working virtual circuit" is flow controlled from source to destination, and buffer resources are reserved for the path 🛤️.
HYPERchannel A exchanges frames at very high rates to determine that the receiver is ready to receive data and to control its flow as data moves through the network 🏎️.
DATApipe propagation time is relatively long compared to the time needed to send an internal packet of 2K-4K bytes 🐢. As a result, DATApipe controllers use a streamlined TP4-like transport protocol to assure delivery of frames between DATApipe boxes 💌.
REFERENCES 📚
[1] HYPERchannel is a trademark of Network Systems Corporation. 💅
[2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, Symbolics, September 1982. 🫶
[3] DATApipe is a registered trademark of Network Systems Corporation. ✨
📦 where this page comes from
- ietf: rfc1044 1988-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms