Network Working Group K. Hardwick Request for Comments: 1044 NSC J. Lekashman NASA-Ames GE February 1988 Internet Protocol on Network Systems HYPERchannel Protocol Specification STATUS OF THIS MEMO The intent of this document is to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel [1] equipment. Distribution of this memo is unlimited. This document is intended for network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols. At the time of this first RFC edition, the contents of this document has already been reviewed by about a dozen vendors and users active in the use of TCP/IP on HYPERchannel media. Comments and suggestions are still welcome (and implementable,) however. Any comments or questions on this specification may be directed to: 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-4359 Hardwick & Lekashman [Page 1] RFC 1044 IP on Network Systems HYPERchannel February 1988 TABLE OF CONTENTS 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 . . . . . . . . . . . . 42 Hardwick & Lekashman [Page 2] RFC 1044 IP on Network Systems HYPERchannel February 1988 GOALS OF THIS DOCUMENT In this document, there are four major technical objectives: 1. To bless a "de facto" standard for IP on HYPERchannel that has been implemented by Tektronix, Cray, NASA Ames, and others. We are attempting to resolve some interoperability problems with this standard so as to minimize the changes to existing IP on HYPERchannel software. If any ambiguities remain in the de facto standard, we wish to assist in their resolution. 2. To address larger networks, NSC's newer network products are moving to a 32-bit address from the current 16-bit TO address. This document would introduce the addressing extension to the user community and specify how IP datagrams would work in the new addressing mode. 3. To define an Address Resolution Protocol for HYPERchannel and other NSC products. It is probably well known that current NSC products do not support the broadcast modes that make ARP particularly useful. However, many have expressed interest in "ARP servers" at a known network address. These servers could fade away as NSC products with broadcast capability come into existence. Host drivers that can generate and recognize this ARP protocol would be prepared to take advantage of it as the pieces fall into place. 4. Part of this effort is to standardize the unofficial "message type" field that reserves byte 8 of the HYPERchannel network message. To permit better interoperability, NSC will initiate a "network protocol registry" where any interested party may obtain a unique value in byte 8 (or bytes 8 and 9) for their own public, private, commercial or proprietary protocol. Lists of assigned protocol type numbers and their "owners" will be periodically published by NSC and would be available to interested parties. Hardwick & Lekashman [Page 3] RFC 1044 IP on Network Systems HYPERchannel February 1988 BASIC HYPERCHANNEL NETWORK MESSAGES Unlike most datagram delivery systems, the HYPERchannel network message consists of 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 in length. The first 10 bytes contain information required for the delivery of the entire message, and the remainder can be used by higher level protocols. The second part of the message, the "Associated Data," can be optionally included with the message proper. In most cases (transmission over HYPERchannel A trunks), the length of the associated data is literally unlimited. Others (such as HYPERchannel B or transmission within a local HYPERchannel A A400 adapter) limit the size of the Associated Data to 4K bytes. If the information sent can be contained within the Message Proper, then the Associated Data need not be sent. HYPERchannel lower link protocols treat messages with and without Associated Data quite differently; "Message only" transmissions are sent using abbreviated protocols and can be queued in the receiving network adapter, thus minimizing the elapsed time needed to send and receive the messages. When associated data is provided, the HYPERchannel A adapters free their logical resources towards driving the host interface and coaxial trunks. Hardwick & Lekashman [Page 4] RFC 1044 IP on Network Systems HYPERchannel February 1988 BASIC (16-BIT ADDRESS) MESSAGE PROPER HEADER The first 10 bytes of the network Message Proper are examined by the network adapters to control delivery of the network message. Its format is as follows: 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 Consists of two four bit masks indicating which of four possible HYPERchannel A coaxial data trunks are to be used to transmit the message and to return it. If a bit in the mask is ON, then the adapter firmware will logically AND it with the mask of installed trunk interfaces and use the result as a candidate list of interfaces. Whenever one of the internal "frames" are sent to communicate with the destination adapter, the transmission hardware electronically selects the first non-busy trunk out of the list of candidates. Thus, selection of a data trunk is best performed by the adapter itself rather than by the host. "Dedicating" trunks to specific applications only makes sense in very critical real time applications such as streaming data directly from high speed overrunnable peripherals. A second Trunk mask is provided for the receiving adapter when it sends frames back to the transmitter, as it is possible to build "asymmetric" configurations of data trunks where trunk 1 on one box Hardwick & Lekashman [Page 5] RFC 1044 IP on Network Systems HYPERchannel February 1988 is connected to the trunk 3 interface of a second. Such configurations are strongly discouraged, but the addressing structure supports it if needed. The "trunks to try" field is only used by HYPERchannel A. To assure maximum interoperability, a value of 0xFF should be placed in this field to assure delivery over any technology. Other values should only be used if the particular site hardware is so configured to not be physically connected via those trunks. MESSAGE FLAGS Contains options in message delivery. In 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. 0 if only a message proper is present in the network message. The value of this bit is enforced by the network adapter firmware. BURST MODE (BST) Enables a special mode for time critical transfers where a single HYPERchannel A coaxial trunk is dedicated during transmission of the network message. Not recommended for anything that won't cause peripheral device overruns if data isn't delivered once message transmission starts. EXCEPTION (EXC) Indicates to some channel programmed host interfaces that the message is "out of band" in some way and requires special processing. ACCESS CODE A feature to permit adapters to share use of a cable yet still permit an "access matrix" of which adapter boxes and physically talk to which others. Not currently in use by anyone, support is being discontinued. TO ADDRESS Consists of three parts. The high order 8-bits contains the physical address of the network adapter box which is to receive the message. The low order 8-bits are interpreted in different ways depending on the nature of the receiving network adapter. If the receiving adapter has different host "ports," then the low order bits of the TO field are used to designate which interface is to receive the message. On IBM data channels, the entire "logical" TO field is interpreted as the subchannel on which the incoming data is to be presented. Parts of the logical TO field that are not interpreted by Hardwick & Lekashman [Page 6] RFC 1044 IP on Network Systems HYPERchannel February 1988 the network adapter are passed to the host for further interpretation. FROM ADDRESS The FROM address is not physically used during the process of transmitting a network message, but is passed through to the receiving host so that a response can be returned to the point of origin. In general, reversing the TO and FROM 16-bit address fields and the TO and FROM trunk masks can reliably return a message to its destination. MESSAGE TYPE The following 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 as to not conflict with internal processing of messages by NSC firmware. In the past, this field has been loosely defined as carrying information of interest to NSC equipment carrying the message and not as a formal protocol type field. For example, 0xFF00 in bytes 8 and 9 of the message will cause the receiving adapter to "loop back" the message without delivering it to the attached host. Concurrent with this document, it is NSC's intent to use both bytes 8 and 9 as a formal "protocol type" designator. Major protocols will be assigned a unique value in byte 8 that will (among good citizens) not duplicate a value generated by a different protocol. Minor protocols will have 16-bit values assigned to them so that we won't run out when 256 protocols turn up. Any interested party could obtain a protocol number or numbers by application to NSC. In this document, protocol types specific to IP protocols are assigned. TO ADDRESSES AND OPEN DRIVER ARCHITECTURE Since not all 16-bits of the TO address are used for the physical delivery of the network message, the remainder are considered "logical" in that their meaning is physically determined by host computer software or (in cases such as the FIPS data channel) by hardware in the host interface. Since HYPERchannel is and will be used to support a large variety of general and special purpose protocols, it is desirable that several independent protocol servers be able to independently share the HYPERchannel network interface. The implementation of many of NSC's device drivers as well as those of other parties (such as Cray Research) support this service. Each protocol server that wishes to send or receive HYPERchannel network messages logically "connects" to a HYPERchannel device driver by specifying the complete 16-bit TO Hardwick & Lekashman [Page 7]