Internet Protocol on Network System's HYPERchannel: Protocol Specification
RFC 1044
also known as STD 45
| Document | Type |
RFC
- Internet Standard
(February 1988)
Updated by RFC 5494
|
|
|---|---|---|---|
| Authors | |||
| Last updated | 2013-03-02 | ||
| RFC stream | Legacy stream | ||
| Formats | |||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 1044
quot; 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 is interoperable and identical with the standard described above with the sole exception that bytes 8 and 9 are set to zero by these drivers. As these bytes are ignored by most implementations of this driver, they have been assigned values to formalize the use of the message type field and to 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) and subsequently made its way to Berkeley and BSD UNIX. This protocol is not interoperable with Hardwick & Lekashman [Page 21] RFC 1044 IP on Network Systems HYPERchannel February 1988 the standard described above due to several distinct differences. First, bytes 8 through 11 are always zero. The IP header always starts on byte 12. Comments in some of these drivers designate byte 11 as an "IP header offset" field, but apparently this value is never processed. The major difference (and the incompatibility) concerns the packaging of the IP datagram into the network message. Due to historical difficulties in the early 80's with the sending and receiving of very small blocks of associated data on VAXes, this protocol the takes a curious approach to the placement of the IP header and the headers of higher level protocols (such as TCP or UDP.) o If the entire length of the IP datagram is 54 bytes or less, it is possible to fit the entire datagram and the HYPERchannel header 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; no padding bytes are sent at the end of the message. o If the length of the IP header is greater than 54 bytes, then: - All higher level protocol information (TCP/UDP header and their associated data fields) are 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 sufficient to accommodate the TCP/UDP header and its data fields. Hardwick & Lekashman [Page 22] RFC 1044 IP on Network Systems HYPERchannel February 1988 WHICH PROTOCOL IS BEST? In choosing which to follow, the "Cray-Ames" approach was taken for several reasons: 1. Cray Research has performed exemplary work in dealing with other vendors to provide IP on HYPERchannel from the Cray computers to other hosts. As a result, there are 4 or 5 vendor supported implementations of IP on HYPERchannel that use this approach. 2. The two part structure of the message proper has its uses when a machine wishes to make protocol decisions before staging the transfer of an immense block of associated data into memory. Many network coprocessors and intelligent I/O subsystems find it simpler to read in the entire network message before deciding what to do with it. Arbitrarily catenating the two components does this best and permits streaming of messages from future technology network adapters. 3. Some TCP users (mostly secure DoD sites) intend to load up IP datagrams with optional fields in the future. The Tektronix-Berkeley implementation has problems if the IP header length exceeds 54 bytes. Hardwick & Lekashman [Page 23] RFC 1044 IP on Network Systems HYPERchannel February 1988 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 the vantage of an IP driver, any trunk mask is valid so long as Hardwick & Lekashman [Page 24] RFC 1044 IP on Network Systems HYPERchannel February 1988 it results in successful delivery of the HYPERchannel network message to its destination. There is no reason to check this field for validity on reception of the message. Specification of the Trunk Mask on output is a local affair that can be specified 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 Several new bits have been defined here. 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 are equipped to place a 32-bit CRC of the associated data at the end of the associated data block when this bit is on. Similarly equipped adapters will examine the trailing 32-bits of associated data (when the bit is on) to determine if the message contents have been corrupted at any stage of the transmission. 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, this indicates that the CRC information was placed at the end of associated data by the transmitting adapter and not removed by the receiving adapter; thus the associated data will be four bytes longer than otherwise 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 to match 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. Hardwick & Lekashman [Page 25] RFC 1044 IP on Network Systems HYPERchannel February 1988 FROM ADDRESS CORRECT. This bit should be set by all transmitting IP drivers who have endeavored 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 determine the 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 constitutes 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. Contains the adapter address 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 determined by the host's system administrator. FROM ADDRESS The FROM address is 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. 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 distinguish an incoming network message 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. Hardwick & Lekashman [Page 26] RFC 1044 IP on Network Systems HYPERchannel February 1988 IP HEADER OFFSET Byte 9 contains the offset to the start of the IP header within the message proper, such that the Message Proper address plus the IP header offset generates 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 examine 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 imposed so that routing decisions on the vast majority of IP datagrams can be made by examining only the message proper, as 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 greater than this length, the IP datagram 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 will be required to build a contiguous IP datagram -- it's right there at buffer+16. ADDRESS RESOLUTION PROTOCOL Address Resolution Protocol has achieved a great deal of success on the Ethernet as it permits a local IP network to configure itself simply by having each node know its own IP address. Those unfamiliar with the intent, protocol, and logic of the Address Resolution Protocol should refer to RFC-826, "An Ethernet Address Resolution Protocol" [2]. Hardwick & Lekashman [Page 27] RFC 1044 IP on Network Systems HYPERchannel February 1988 A later section of this document describes four techniques where a target HYPERchannel address is to obtained 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) | +------------------------------+-----------------------------+ Hardwick & Lekashman [Page 28] RFC 1044 IP on Network Systems HYPERchannel February 1988 +------------------------------+-----------------------------+ 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 | | +------------------------------+-----------------------------+ Layout of the fields of this ARP message is a fairly straightforward exercise given the standards of ARP and the 32-bit message header. A few fields are worth remarking upon: TO ADDRESS The TO address of an ARP message will be one of two classes of address. A "normal" address indicates that the message is an ARP response, or that it is an ARP request directed at an ARP server at a well known address on the local network. For those HYPERchannel networks which are equipped to broadcast, a value of 0xFFFFFF07 in the TO address will (by convention) be picked up only by those protocol servers prepared to interpret and respond to ARP messages. Hardwick & Lekashman [Page 29] RFC 1044 IP on Network Systems HYPERchannel February 1988 The issue of which address to use in an ARP request is discussed in the Address Resolution section. FROM ADDRESS Must be the correct FROM address of the user protocol server issuing an ARP request. The Source Correct bit in the Message Flags byte should be set by this requesting server, as some ARP servers may someday choose to issue ARP information on an "need to know" basis in secure environments. With an ARP response, the FROM address will contain the "normal" HYPERchannel address of the protocol server responding to the ARP address, even if that server was reached via broadcast mechanisms. ARP responses are returned to the party specified in the FROM address specified in the message header, rather than the address in the "Source HYPERchannel Address" field within the body of the ARP message. MESSAGE TYPE The 16-bit value 0x0700 is reserved for the exclusive use of ARP. Unlike IP messages, no provision is made for the ARP message to begin at an arbitrary offset within the message proper, so the value in byte 9 is an extension of the message type. HEADER END OFFSET ARP uses the 32-bit addressing convention that byte 15 contains the offset to the start of user protocol (and hence the end of user protocol information). Note that this is not a substitute for the IP offset fields, as this field also serves as the end of HYPERchannel header information -- future NSC message processing code may well take exception to "garbage" between the actual 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. HYPERCHANNEL PROTOCOL TYPE On the Ethernet, this field is used to distinguish IP from all other protocols that may require address resolution. To be logically consistent, this field is identical to bytes 8 and 9 0x0600 in a 32- bit address HYPERchannel message carrying an IP datagram. Hardwick & Lekashman [Page 30] RFC 1044 IP on Network Systems HYPERchannel February 1988 HYPERCHANNEL ADDRESS LENGTH This contains the value 6, a sufficient number of bytes to accommodate the four byte HYPERchannel address and 2 bytes to indicate the largest IP datagram size that source and destination can handle. SOURCE AND DESTINATION HYPERCHANNEL ADDRESS This field contains the Domain, Network, and Adapter/port address of source and destination, respectively. A value of 0000 in the Domain and Network fields has special significance as this is interpreted as a request to send and receive 16-bit HYPERchannel headers rather than 32-bit headers. If 32-bit headers are to be used within a single HYPERchannel network, then the local domain and network numbers may be specified. MAXIMUM TRANSMISSION UNIT HYPERchannel LAN technology is such that messages of unlimited length may be sent between hosts. Since host throughput on a network is generally limited by the rate the network equipment can be functioned, larger transmission sizes result in higher bulk transfer performance. Since not every host will be able to handle the maximum size IP datagram, a more flexible means of MTU (maximum transmission unit) size negotiation than simply wiring the same value into every network host is needed. With this field, each host declares the maximum IP datagram size (not the associated data block size) it is prepared to receive. Transmitting IP drivers should be prepared to send the minimum of the source and destination IP sizes negotiated at ARP time. The MTU size sent refers to the maximum size of IP header + data. It does not include the length of the HYPERchannel Hardware header or any offset between the header and the start of the IP datagram. Since it is the option of the transmitting hosts 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 is 64 - 44, or the length of the basic IP header). An example of a typical 16-bit packet is: 12 bytes hardware header. 12 bytes offset. 40 bytes IP/TCP header. 4096 bytes of data. This gives an MTU of 4136. Hardwick & Lekashman [Page 31] RFC 1044 IP on Network Systems HYPERchannel February 1988 An example of a typical 32-bit packet is: 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 offset values are chosen so that the typical packet causes user data to be page aligned at the start of the associated data area. This is an implementation decision, which can certainly be modified as required. The maximum maximum transmission unit is 65536, the current largest size IP datagram. In order to allow this value to fit into a 16-bit field, the offset length is not included in the MTU. This MTU size is not a requirement that a local host be equipped to send or receive datagrams of that size; it simply indicates the maximum capacity of the receiving host. A note on trunk masks: There is no field for specifying trunk masks. This is intentional, as new NSC hardware will contain trunk reachability information, eliminating the need for the host to maintain 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 describes techniques used by an IP driver to determine the HYPERchannel address and header that a message should contain given an IP datagram containing an IP address. It describes techniques that are local to specific hosts (and hence can be modified without regard to the activities or techniques of other hosts) as well as techniques to use the Address Resolution Protocol on existing HYPERchannel equipment to better manage IP addresses. It also discusses the migration of name resolution on one of four steps. 1. Truncation of the IP address to form a HYPERchannel address. 2. Local resolution of HYPERchannel addresses through configuration files. 3. Centralized resolution of HYPERchannel addresses through an "ARP server" driven by a configuration file. Hardwick & Lekashman [Page 32] RFC 1044 IP on Network Systems HYPERchannel February 1988 4. Distributed resolution of HYPERchannel addresses using a "real" address Resolution Protocol on future HYPERchannel media supporting a broadcast mode. IP ADDRESS TRUNCATION A number of IP on HYPERchannel implementations support modes where the HYPERchannel address is generated by placing the low order 16- bits of the IP address in the TO address of the message proper. This more or less treats a set of HYPERchannel boxes addressable through 16-bit HYPERchannel addresses as a Class B IP network. This approach certainly offers simplicity: IP addresses are simply chosen to match HYPERchannel addresses and no IP address "configuration files" need be kept. Although this approach works in an environment where the HYPERchannel completely constitutes a Class B network, or where connection to a larger IP network is not a concern, its long term use is discouraged for several reasons: o It simply will not work with any Class C address (the physical TO address is not controllable) or a Class A address (where host addresses are generally carefully administered.) In addition, it will not support subnetworks. It is quite incompatible with 32-bit HYPERchannel addresses. o By decoupling the IP and HYPERchannel addresses through more complex address resolution, the characters of the two addresses allow greater site flexibility: the IP address becomes "logical" in character so that an address can move about a site with the user or host; the HYPERchannel address maintains its physical character so that a HYPERchannel address carefully identifies the physical location of the source and destination within the extended HYPERchannel network. LOCAL ADDRESS RESOLUTION The current state of address resolution art with IP on HYPERchannel works as follows: given an arbitrary IP address, the IP HYPERchannel driver looks up an entry with that address in a (generally hashed) table. If found, the table entry contains the first 6 bytes of the HYPERchannel header that is used to send the IP datagram to the next IP node on the internet. Since implementations such as the 4.3BSD UNIX IP are clever enough to provide its lower level drivers with the IP address of the next gateway as well as the destination address on the internet (assuming the message is not delivered locally on the HYPERchannel,) the number of entries in this table is more or less manageable, as it must only contain the IP hosts and gateway addresses that are directly accessible on the HYPERchannel. Hardwick & Lekashman [Page 33] RFC 1044 IP on Network Systems HYPERchannel February 1988 CONFIGURATION FILE FORMAT So long as this technique of address resolution is used, the techniques used are exclusively local to the host in the sense that the techniques used to generate and store the information in the table are irrelevant to other hosts. Shown here is a typical file format. This file should probably be program generated from a database, as asymmetric trunk configurations and multiply homed hosts can cause differences in physical routing and trunk usage. This format is documented here to illustrate what sort of information must be kept at the link layer. The file consists of source lines each with the form: <type> <hostname> <trunks/flags> <domain/net> <addr> <MTU> 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 7F07 Comments may begin with either # or ;. Case is not significant in any field. <type> indicates the type of entity to be defined. Currently defined types are "host," "ahost", "loop," "address," and "arpserver". host This token indicates an IP host. The following field is expected to be a name that can be resolved to an IP address. ahost This field indicates an additional network interface to the same host. This may be used for performance enhancements. Hardwick & Lekashman [Page 34] RFC 1044 IP on Network Systems HYPERchannel February 1988 loop Sets a flag in the entry for that host so that 0xFF00 is placed in bytes 8 and 9 of the message. This will cause the IP datagram to be directed towards the specified host (which must still be a valid host name) and looped back within the remote adapter. This facility serves both as a debugging aid and as a crude probe of the availability of the remote network adapter. arpserver This indicates an address to use for directing ARP requests to the network. If several arpserver addresses are specified, they will be tried in turn until a response is received (or we run out of servers.) An arpserver with the appropriate broadcast address of FFFF FF07 would cause an ARP broadcast to take place when broadcasting becomes available. Broadcast and specific addresses may be used in combination. <hostname> This field is the logical name of the destination. For a host it is the logical name to be given to the local naming service to determine the associated IP address. This field may contain four decimal numbers separated by dots, in which case it is assumed to be the explicit IP address. <trunks/flags> This field is the value to be placed in bytes 0 and 1 of the message header when sending to this host. The associated data bit need not be supplied as the driver must control it. All other bits are sent as provided. This field is a hexidecimal number. <domain/net> This field is the value to be placed in the Domain and Network number field of the message. A value of 0000 in this field indicates that the destination should be reached by constructing a 16-bit HYPERchannel header, rather than a 32-bit header. <address> This field is the value to be placed in the 16-bit TO field to reach <hostname>. This field is a hexidecimal number. <MTU> This field contains the largest size IP datagram that the destination host is prepared to receive. This field is a decimal number. This field is optional. If not present, a value of 4148 is assumed. See the earlier discussion on Maximum Transmission Unit for more detail. ARP SERVERS The primary problem with local host address resolution is that changes or additions to hosts on the local net must be replicated to every HYPERchannel host in that network. While this is manageable for up to half a dozen hosts, it becomes quite unmanageable for Hardwick & Lekashman [Page 35] RFC 1044 IP on Network Systems HYPERchannel February 1988 larger networks. An approach that can be implemented using existing HYPERchannel technology is to have a server on the HYPERchannel network provide the HYPERchannel destination address that is associated with an IP address. Although this is strictly a point-to-point request/response dialogue between two network nodes, the Address Resolution Protocol which was originally designed for Ethernet (but thoughtfully constructed to work with any pair of link and network addresses) performs an excellent job. ARP servers can be reached simply by placing the address of the server 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 do not respond to ARP broadcast messages. Properly equipped IP drivers should respond to the broadcast messages when they appear. If an ARP server receives a message containing an IP address it does not know how to resolve, it ignores the message so that another ARP server might be addressed at the source's next attempt. If the address is resolvable, it places the known HYPERchannel address and MTU size in the response and returns it to the location in the HYPERchannel header FROM address. Unlike a broadcast ARP, the ARP server will be required to service two requests when two hosts that are initially unknown to one another attempt to get in touch. Since the destination did not receive the ARP request, it must contact the ARP server when its higher level protocols first generate a datagram to respond to the the source's first IP datagram to go through to the destination. The source configuration file described in the previous section was explicitly designed so that it could be sufficient as a data base for an ARP server as well as an individual host. BROADCAST ARP When a local HYPERchannel network contains a broadcast capability, any IP driver wishing to perform HYPERchannel address resolution may be configured to emit the ARP message on a broadcast instead of a well known address. IP drivers on other hosts are presumed to know if their local HYPERchannel interface can send broadcast messages; if so, they arrange to "listen" on the FF07 broadcast TO address for ARP. Processing of a received ARP broadcast message is otherwise identical Hardwick & Lekashman [Page 36] RFC 1044 IP on Network Systems HYPERchannel February 1988 to RFC-826: o Messages are responded to if and only if the destination IP driver is authoritative for the designated IP address. o Whenever an ARP message is processed, the IP driver takes the source HYPERchannel address and MTU size and adds it to its address resolution tables. Thus the driver is equipped to turn around the IP datagram that arrives from the destination host when contact is made. Each IP driver may have address resolutions that are set through a static routing table (the configuration file specified above). If ARP information arrives that contradicts a static entry (as opposed to previously set dynamic ARP information) then the ARP information should be ignored. This decision is made on the premise that the only useful purpose of static routing in a broadcast ARP environment is to add authentication, as it's easy to lie with ARP. Hardwick & Lekashman [Page 37] RFC 1044 IP on Network Systems HYPERchannel February 1988 APPENDIX A. NSC PRODUCT ARCHITECTURE AND ADDRESSING This section is intended to be a concise review of the state of the art in NSC networks and the techniques they provide for the delivery of messages. Those who are thoroughly familiar with HYPERchannel may wish to only skim this section; however, there is material on new technologies and addressing formats that are not yet generally known to most of NSC's customers. NETWORK SYSTEMS HYPERCHANNEL TECHNOLOGIES Network Systems manufactures several different network technologies that use very different media and link controls, but still provide a common host interface in both the protocol and hardware sense of the term. These four technologies are: o 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," providing 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 is principally used to interconnect larger mainframe computers and high speed mainframe peripherals such as tape drives and laser printers. o HYPERchannel B -- a 10-megabit, baseband, CSMA with collision avoidance network using a single coaxial cable bus. This technology is used for direct host to host communications under the name HYPERchannel B, and for terminal connections under the name HYPERbus. It is currently used for three major applications -- local networks of ASCII terminals, networks of IBM 3270 terminals, and host to host communications of smaller computers. o DATAPIPE[3] -- a 275-megabit fiber optic "backbone" network that interconnects lower speed local area networks within a 20 mile range, and to provide 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. o Bridges and Network Distance Extensions -- NSC quickly discovered that its customers wanted very high speeds over geographic areas, not just within the range of several miles that is conceivable with a coaxial cable network. Starting in 1978, NSC began to build a series of "link adapters" that are integral bridges between local area networks. These link Hardwick & Lekashman [Page 38] RFC 1044 IP on Network Systems HYPERchannel February 1988 adapters support common high speed communications media such as 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 in order to achieve 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 +------------+ | | | | | | | | | | | | | | | | +-----------+-------+ The network adapter contains interface boards and firmware to be cabled to the manufacturer's data channel, such as would be done with a disk or tape controller. Mainframe network adapters do not emulate an existing manufacturer's device (such as a tape drive) but are supported by software which functions the channel and adapter to send and receive network messages. Models of HYPERchannel adapters are available for essentially all large scale computers worldwide. Hardwick & Lekashman [Page 39] RFC 1044 IP on Network Systems HYPERchannel February 1988 MINICOMPUTER AND WORKSTATION ATTACHMENT Since the network adapter contains lots of expensive, high speed logic, a different technique is used to provide attachment to 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 to a channel cable that is connected to one of four ports on a "general purpose computer adapter." This adapter multiplexes transmissions to and from the HYPERchannel trunks from up to four attached processors. Hardwick & Lekashman [Page 40] RFC 1044 IP on Network Systems HYPERchannel February 1988 NETWORK COPROCESSORS For about 10 different bus systems, Network systems provides a "smart" DMA controller containing 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 are placed in a common "mailbox" area and extracted by the coprocessor. The coprocessor reads and writes system memory as required to service network requests in the proper order. The coprocessors currently provide a service to read or write network messages (called Driver service as it is more or less identical to HYPERchannel dumb DMA drivers) and a service for NETEX, which is NSC's OSI-like communications protocol. Hardwick & Lekashman [Page 41] RFC 1044 IP on Network Systems HYPERchannel February 1988 APPENDIX B. NETWORK SYSTEMS HYPERCHANNEL PROTOCOLS The protocols implemented by NSC within its own boxes are designed for the needs of the different technologies. A compact summation of these protocols is: 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: o 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. o 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 Hardwick & Lekashman [Page 42] RFC 1044 IP on Network Systems HYPERchannel February 1988 load over several coax cables -- a feat that has proven very difficult on, for example, Ethernet. o 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. Hardwick & Lekashman [Page 43]