As per Relevance of the word broadcast, we have this rfc below:
Network Working Group K.
Request for Comments: 1044
J.
NASA-Ames
February 1988
Internet Protocol on Network Systems
Protocol
STATUS OF THIS
The intent of this document is to provide a complete discussion
the protocols and techniques used to embed DoD standard
Protocol datagrams (and its associated higher level protocols)
Network Systems Corporation's HYPERchannel [1] equipment
Distribution of this memo is unlimited
This document is intended for network planners and implementors
are already familiar with the TCP/IP protocol suite and
techniques used to carry TCP/IP traffic on common networks such
the DDN or Ethernet. No great familiarity with NSC products
assumed; an appendix is devoted to a review of NSC technologies
protocols
At the time of this first RFC edition, the contents of this
has already been reviewed by about a dozen vendors and users
in the use of TCP/IP on HYPERchannel media. Comments and
are still welcome (and implementable,) however
Any comments or questions on this specification may be directed to
Ken
Director, Software
Network Systems Corporation MS029
7600 Boone Avenue
Brooklyn Park, MN 55428
Phone: (612) 424-1607
John
Nasa Ames Research Center. NAS/
MS 258-6
Moffett Field, CA, 94035
lekash@orville.nas.nasa.
Phone: (415) 694-4359
Hardwick & Lekashman [Page 1]
RFC 1044 IP on Network Systems HYPERchannel February 1988
TABLE OF
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
In this document, there are four major technical objectives
1. To bless a "de facto" standard for IP on HYPERchannel that
been implemented by Tektronix, Cray, NASA Ames, and others
We are attempting to resolve some interoperability problems
this standard so as to minimize the changes to existing IP
HYPERchannel software. If any ambiguities remain in the de
standard, we wish to assist in their resolution
2. To address larger networks, NSC's newer network products
moving to a 32-bit address from the current 16-bit TO address
This document would introduce the addressing extension to
user community and specify how IP datagrams would work in
new addressing mode
3. To define an Address Resolution Protocol for HYPERchannel
other NSC products. It is probably well known that current
products do not support the broadcast modes that make
particularly useful. However, many have expressed interest
"ARP servers" at a known network address. These servers
fade away as NSC products with broadcast capability come
existence. Host drivers that can generate and recognize
ARP protocol would be prepared to take advantage of it as
pieces fall into place
4. Part of this effort is to standardize the unofficial "
type" field that reserves byte 8 of the HYPERchannel
message. To permit better interoperability, NSC will initiate
"network protocol registry" where any interested party
obtain a unique value in byte 8 (or bytes 8 and 9) for their
public, private, commercial or proprietary protocol. Lists
assigned protocol type numbers and their "owners" will
periodically published by NSC and would be available
interested parties
Hardwick & Lekashman [Page 3]
RFC 1044 IP on Network Systems HYPERchannel February 1988
BASIC HYPERCHANNEL NETWORK
Unlike most datagram delivery systems, the HYPERchannel
message consists of two parts
Message
+--------------------+
| |
| |
| 10-64 bytes |
| |
| |
+--------------------+
Associated
+----------------------------------------------------+
| |
| |
| |
| |
| Unlimited length |
| |
| |
| |
| |
+----------------------------------------------------+
The first part is a message header that can be up to 64 bytes
length. The first 10 bytes contain information required for
delivery of the entire message, and the remainder can be used
higher level protocols. The second part of the message,
"Associated Data," can be optionally included with the
proper. In most cases (transmission over HYPERchannel A trunks),
length of the associated data is literally unlimited. Others (
as HYPERchannel B or transmission within a local HYPERchannel A A400
adapter) limit the size of the Associated Data to 4K bytes. If
information sent can be contained within the Message Proper, then
Associated Data need not be sent
HYPERchannel lower link protocols treat messages with and
Associated Data quite differently; "Message only" transmissions
sent using abbreviated protocols and can be queued in the
network adapter, thus minimizing the elapsed time needed to send
receive the messages. When associated data is provided,
HYPERchannel A adapters free their logical resources towards
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
The first 10 bytes of the network Message Proper are examined by
network adapters to control delivery of the network message.
format is as follows
byte Message
+------------------------------+-----------------------------+
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
Consists of two four bit masks indicating which of four
HYPERchannel A coaxial data trunks are to be used to transmit
message and to return it. If a bit in the mask is ON, then
adapter firmware will logically AND it with the mask of
trunk interfaces and use the result as a candidate list
interfaces. Whenever one of the internal "frames" are sent
communicate with the destination adapter, the transmission
electronically selects the first non-busy trunk out of the list
candidates. Thus, selection of a data trunk is best performed by
adapter itself rather than by the host. "Dedicating" trunks
specific applications only makes sense in very critical real
applications such as streaming data directly from high
overrunnable peripherals
A second Trunk mask is provided for the receiving adapter when
sends frames back to the transmitter, as it is possible to
"asymmetric" configurations of data trunks where trunk 1 on one
Hardwick & Lekashman [Page 5]
RFC 1044 IP on Network Systems HYPERchannel February 1988
is connected to the trunk 3 interface of a second.
configurations are strongly discouraged, but the addressing
supports it if needed
The "trunks to try" field is only used by HYPERchannel A. To
maximum interoperability, a value of 0xFF should be placed in
field to assure delivery over any technology. Other values
only be used if the particular site hardware is so configured to
be physically connected via those trunks
MESSAGE
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
follows the Message Proper. 0 if only a message proper is present
the network message. The value of this bit is enforced by
network adapter firmware
BURST MODE (BST) Enables a special mode for time critical
where a single HYPERchannel A coaxial trunk is dedicated
transmission of the network message. Not recommended for
that won't cause peripheral device overruns if data isn't
once message transmission starts
EXCEPTION (EXC) Indicates to some channel programmed host
that the message is "out of band" in some way and requires
processing
ACCESS
A feature to permit adapters to share use of a cable yet still
an "access matrix" of which adapter boxes and physically talk
which others. Not currently in use by anyone, support is
discontinued
TO
Consists of three parts. The high order 8-bits contains the
address of the network adapter box which is to receive the message
The low order 8-bits are interpreted in different ways depending
the nature of the receiving network adapter. If the
adapter has different host "ports," then the low order bits of the
field are used to designate which interface is to receive
message. On IBM data channels, the entire "logical" TO field
interpreted as the subchannel on which the incoming data is to
presented. Parts of the logical TO field that are not interpreted
Hardwick & Lekashman [Page 6]
RFC 1044 IP on Network Systems HYPERchannel February 1988
the network adapter are passed to the host for
interpretation
FROM
The FROM address is not physically used during the process
transmitting a network message, but is passed through to
receiving host so that a response can be returned to the point
origin. In general, reversing the TO and FROM 16-bit address
and the TO and FROM trunk masks can reliably return a message to
destination
MESSAGE
The following two bytes are reserved for NSC. Users have
encouraged to put a zero in byte 8 and anything at all in byte 9
as to not conflict with internal processing of messages by
firmware. In the past, this field has been loosely defined
carrying information of interest to NSC equipment carrying
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
"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
be assigned a unique value in byte 8 that will (among good citizens
not duplicate a value generated by a different protocol.
protocols will have 16-bit values assigned to them so that we won'
run out when 256 protocols turn up. Any interested party
obtain a protocol number or numbers by application to NSC. In
document, protocol types specific to IP protocols are assigned
TO ADDRESSES AND OPEN DRIVER
Since not all 16-bits of the TO address are used for the
delivery of the network message, the remainder are
"logical" in that their meaning is physically determined by
computer software or (in cases such as the FIPS data channel)
hardware in the host interface
Since HYPERchannel is and will be used to support a large variety
general and special purpose protocols, it is desirable that
independent protocol servers be able to independently share
HYPERchannel network interface. The implementation of many of NSC'
device drivers as well as those of other parties (such as
Research) support this service. Each protocol server that wishes
send or receive HYPERchannel network messages logically "connects"
a HYPERchannel device driver by specifying the complete 16-bit
Hardwick & Lekashman [Page 7]
RFC 1044 IP on Network Systems HYPERchannel February 1988
address it will "own" in the sense that any network message with
TO address will be delivered to that protocol server
The logical TO field serves a function similar to the TYPE byte
the Ethernet 802.2 message header, but differs from it in that
width of the logical TO field varies from host to host, and that
values of the logical TO address are reserved for
protocols. On the other hand, it is possible to have
"identical" protocols (such as two independent copies of IP
different HYPERchannel addresses) sharing the same
HYPERchannel interface. This makes NSC's addressing
identical to the OSI concept that the protocol server to reach
embedded within the address, rather than the IP notion of
a "host" and identifying a server through a message type
Since the HYPERchannel header also has a "message type" field,
is some ambiguity concerning the respective roles of the message
and logical TO fields
o The logical TO field is always used to identify the
server which will receive the message. Once a server
specified the complete TO address for the messages it wishes
receive, the message will not be delivered to a
protocol server regardless of the contents of the message
field
o Although the "type" field cannot change the protocol server
the final destination of the message, the type field can be
by intermediate processes on the network to process the
before it reaches the server destination. An obvious example
the 0xFF00 message loopback type function, where
processing to loop back the message results in nondelivery
the TO address. In the future, intermediate nodes may
"in transit" messages based on the message type only
purposes such as security validation, aging of
datagrams, and network management
EXTENDED (32-BIT ADDRESS) MESSAGE PROPER
In the original days of HYPERchannel, the limitation of 256
"boxes" that could be addressed in a network message was
sufficient as 40 or so adapters was considered a "large" network.
with the Ethernet, more recent networks have resulted in a need
address larger networks. Although a few ad hoc modes have existed
address larger HYPERchannel networks for some years,
technologies of HYPERchannel equipment have logically extended
network message to support 32-bits of addressing, with 24 of
bits to designate a physical network adapter
Hardwick & Lekashman [Page 8]
RFC 1044 IP on Network Systems HYPERchannel February 1988
This 32-bit header has been designed so that existing
adapters are capable of sending and receiving these messages.
the network bridges need the intelligence to select
designated for them
Hardwick & Lekashman [Page 9]
RFC 1044 IP on Network Systems HYPERchannel February 1988
+------------------------------+-----------------------------+
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
+-----------------------------------------------------------------+
| |
| As with basic format network messages |
| |
+-----------------------------------------------------------------+
ADDRESS RECOGNITION AND MESSAGE
With the 32-bit form of addressing, NSC is keeping with the
that the native HYPERchannel address bears a direct relation to
position of the equipment in an extended HYPERchannel network
Each collection of "locally" attached NSC network adapters that
connected by coax or fiber optic cable (with the possible addition
nonselective repeaters such as the ATRn series) is considered
"network". Each network can have up to 256 directly
adapters attached to it which can be reached by the basic
Hardwick & Lekashman [Page 10]
RFC 1044 IP on Network Systems HYPERchannel February 1988
network message
Existing bridges or "link adapters" can be programmed to
"selective repeaters" in that they can receive network
containing a subset of network addresses send them over the
medium (if present) and reintroduce them on the other network.
interconnected local area networks are considered a single
from an addressing point of view
A large NSC network can have up to 64K networks which can
complexly interconnected by network bridges and/or "backbone
networks which distribute data between other networks. To
the mechanics of message forwarding, the 16-bit network field
divided into two eight quantities, a "network number"
which network is to receive the message and a "domain number"
specifies which network of networks is the recipient
The bridge technology adapters which move messages between
have address recognition hardware which examines all the 24-bits
bytes 2-5 of the network message header to determine if the
should accept the message for forwarding. At any given instant
time in the network, each bridge will have a list of networks
domains that it should accept for forwarding to a network at
other end of the bridge. Each Adapter (Including Newer
host adapters) contains in address recognition hardware
o domainmask -- a 256-bit mask of domain numbers that should
accepted for forwarding (not local processing) by this adapter
o MyDomain -- the value of the domain on which this
adapter or bridge end is installed
o NetworkMask -- a 256-bit mask of network numbers that should
accepted for forwarding by this adapter
o MyNetwork - the value of the network on which this
adapter or bridge end is installed
o AddressMask -- A 256-bit mask of the local network
that should be accepted by the adapter
o MyAddress -- the "base address" of the box, which must
supplied in any message that is directed to control
within the adapter, such as a loopback message
Address recognition takes place using the algorithm
IF Domain IN DomainMask
IF (Domain = MyDomain AND Network IN NetworkMask)
IF (Domain = MyDomain AND Network = MyNetwork
Address IN AddressMask) THEN accept-
ELSE ignore-message
Hardwick & Lekashman [Page 11]
RFC 1044 IP on Network Systems HYPERchannel February 1988
This algorithm means that an adapter's hardware address
logic will accept any messages to the box itself, any secondary
aliased local addresses owned by the adapter, and any
directed to a remote network or domain that that particular
is prepared to forward
32-BIT MESSAGE
TRUNK
Is as in the basic network message. Messages that are to
delivered outside the immediate network should have 0xFF in this
so that all possible trunks in intermediate networks should be tried
Locally delivered 32-bit messages may still contain
tailored trunk masks to satisfy local delivery needs
MESSAGE
The currently defined bits remain as before. Three new bits
been defined since that time
CRC (END-END MESSAGE INTEGRITY). Newer technology host adapters
capable of generating a 32-bit CRC for the entire network message
soon as it is received over the channel or bus interface from
host. This 32-bit CRC is appended to the end of the associated
block and is preserved through the entire delivery process until
is checked by the host adapter that is the ultimate recipient of
message, which removes it. This end to end integrity checking
designed to provide a high degree of assurance that data has
correctly moved through all intermediate LAN's, geographic links,
internal adapter hardware and processes
SRC (SOURCE FROM ADDRESS CORRECT). This bit is provided to
advantage of the physical nature of the network address to
verify that the 32-bit FROM address provided in the network
is in fact the location that the message originated. If the bit
not set by the transmitting host, no particular processing occurs
the message. If the bit is set, then all intermediate
involved in the delivery of the message have the privilege of
the bit off if the received message FROM address is not a TO
that would be delivered to the originator if the message were
the opposite direction
If the message is received by a host computer with this bit
set, then the FROM address is guaranteed correct in the sense
returning a message with TO and FROM information reversed will
in delivery of the message to the process that actually
Hardwick & Lekashman [Page 12]
RFC 1044 IP on Network Systems HYPERchannel February 1988
it. By careful attention to the physical security of adapters
intermediate links between networks, a high degree of security can
built into systems that simply examine the FROM address of a
to determine the legitimacy of its associated request
GNA (GLOBAL NETWORK ADDRESSING). This bit ON indicates that 32-
addressing is present in the message. When this bit is on, bytes 2-3
(Domain and Network numbers) should also be nonzero
TO
Four bytes contain the TO address, which is used to deliver
network message as described in "Address Recognition and
Forwarding" on page 8. The "logical" part of the TO address is
to designate a protocol server exactly as in the basic format
message header
The existing "address" field has its high order bit reserved as
outnet bit for compatibility with existing A-series network
equipment. Were it not for this bit, the A-series adapters
attempt to accept messages that were "passing through" the
network on their way elsewhere simply because the address
matched while the the Domain and Network numbers (ignored by the A
series adapters) were quite different
This "outnet" bit is used in the following way
o All network adapters (of any type) in an extended set
networks containing A-Series adapters that will ever use 32-
addressing must have their addresses in the range 00-7F (hex.)
o If a message is to be sent to a destination on a
network and domain on such an extended network, then
high order bit of the address field is turned on
o When the last bridge in the chain realizes that it is about
forward the message to its final destination (the Domain
Network numbers are local), then it turns the Outnet bit off
This will result in local delivery to the destination adapter
FROM
The FROM address follows the same logic as the TO address in that
message can be returned to its source by reversing the FROM and
fields of the message. Since so many protocols examine byte 8 of
message to determine its type, the FROM field has been split so
the Domain and Network numbers extend into bytes 10-11.
Hardwick & Lekashman [Page 13]
RFC 1044 IP on Network Systems HYPERchannel February 1988
MESSAGE
This field (informally defined in the past) has been extended to 16-
bits so that a unique value can be assigned to any present or
protocol which is layer on HYPERchannel messages for either
or public use
AGE
This field serves the same purpose as the IP "time to live" in
it prevents datagrams from endlessly circulating about in
improperly configured network. Each time a 32-bit message
through a bridge, the Age Count is decremented by one. When
result is zero, the message is discarded by the bridge
NEXT HEADER OFFSET AND HEADER END
These are used as fields to optionally provide "loose
routing", where a list of 32-bit TO addresses can be provided by
transmitter to explicitly determine the path of a message through
network. If this feature is not used, both these fields
contain the value 16 (decimal) to both indicate extra TO
are absent and that the beginning of protocol data following
HYPERchannel header is in byte 16.
Although it is conceivable that a HYPERchannel IP process could
this source routing capability to direct messages to hosts
gateways, this capability is not felt to be of sufficient value to
to build it into a HYPERchannel IP protocol
In the future, all higher level protocols should be able to
Header End Offset to determine the start of the higher level
information
NSC message forwarding protocols use low level link protocols
negotiate transmission of a message to its next destination on
network. Furthermore, NSC network boxes often "fan out" so
several hosts share the same network transmission equipment as in
A400 adapter. Both these characteristics mean that providing
genuine broadcast capability is not a trivial task, and in fact
current implementations of NSC technology support a
capability
The last several years have seen broadcast applications mature to
point where they have virtually unquestioned utility on a local
sometimes campuswide basis. Accordingly, new NSC technologies
Hardwick & Lekashman [Page 14]
RFC 1044 IP on Network Systems HYPERchannel February 1988
support a broadcast capability. Information on the use of
capability is included here as it is essential to the discussion
the Address Resolution Protocol later in this document
Broadcast capability will be supported only with the extended (32-
address) message format. A broadcast message will have the
general appearance
byte Message
+------------------------------+-----------------------------+
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
+-----------------------------------------------------------------+
| |
| As with basic format network messages |
| Maximum associated data size 1K bytes. |
| |
+-----------------------------------------------------------------+
Hardwick & Lekashman [Page 15]
RFC 1044 IP on Network Systems HYPERchannel February 1988
TRUNKS TO TRY AND MESSAGE
These fields are defined just as with a normal 32-bit message.
bits in the Message Flags field are valid with broadcast modes
BROADCAST
For Domain, Network and Adapter Address fields, the value 0xFF
reserved for use by the broadcast mechanism. A value of 0xFF in
adapter address field indicates to the local network hardware
this message is to be sent to all connected network equipment on
individual network
A value of 0xFF in the network or domain fields,
indicates a request that the scope of the broadcast exceed the
network. The bridging link adapters will receive the
message along with everyone else and will examine the "
Channel" field and their internal switches to determine if
message should be forwarded to other remote networks
If the Network and Domain fields contain the local network
domain, then the broadcast message will only be broadcast within
local network. If a remote Network and Domain is specified, then
message will be delivered as a single message to the remote
and broadcast there
BROADCAST
Since individual hosts and protocol servers generally are
interested in all broadcast messages that float about the network,
filtering mechanism is provided in the header and network
equipment so that only proper classes of broadcast messages
delivered to the end point
Broadcast channel numbers in the range 00-0xFF will be assigned
NSC much like the "message type" field. Host protocol
specify a specific TO address containing a channel number (such
0xFF04) when they bind themselves to the HYPERchannel device driver
The driver and the underlying equipment will deliver only
messages with the correct channel number to the protocol server.
a protocol server wishes to receive several different
messages, it must bind itself to the driver several times with
desired addresses
Link adapters that are prepared to handle multinetwork
messages may be equipped with switches to determine which
channels will be propagated into the next network.
multinetwork broadcast is an arrangement that must be configured
Hardwick & Lekashman [Page 16]
RFC 1044 IP on Network Systems HYPERchannel February 1988
care, these switches are off by default
FROM
The FROM address is constructed just as with a normal 32-bit
message. The Source Address Correct bit is processed just as with
normal message
MESSAGE
Message type is defined as with normal messages.
broadcast applications will have unique message types that are
generally found in normal messages
AGE
Age count is vitally important in a multinetwork broadcast as "loops
in the network can cause a great deal of activity until all
progeny of the original broadcast message die out
PROTOCOL
This section contains information on the technique used
encapsulate IP datagrams on the HYPERchannel network message.
contains three sections to describe three protocol packagings
o The technique used to encapsulate IP datagrams on the
16-bit network message. This is a de facto standard that
been in use for several years and is documented here to make
official
o The encapsulation technique for IP datagrams on 32 bit
messages
o The definition of an Address Resolution Protocol
HYPERchannel
Hardwick & Lekashman [Page 17]
RFC 1044 IP on Network Systems HYPERchannel February 1988
BASIC (16-BIT) MESSAGE
Message
+------------------------------+-----------------------------+
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
+------------------------------+-----------------------------+
| |
| Remainder of IP datagram |
| |
| No associated data is present if IP |
| datagram fits in the Message Proper |
| |
+------------------------------+-----------------------------+
TRUNK
From the vantage of an IP driver, any trunk mask is valid so long
it results in successful delivery of the HYPERchannel network
to its destination. There is no reason to check this field
validity on reception of the message. Specification of the
Mask on output is a local affair that could be specified by
transmitting driver's address resolution tables
Hardwick & Lekashman [Page 18]
RFC 1044 IP on Network Systems HYPERchannel February 1988
MESSAGE
No use is made of the Flags field (byte 1) other than
appropriately set the Associated Data bit. Burst Mode and
Exception bit should not be used with IP
ACCESS
Although some current implementations of IP on HYPERchannel
the access code, no one appears to be using it at the current time
Since this field is currently reserved for the use of 32-
addresses, no value other than 0000 should be placed in this field
TO
The TO field is generally obtained by a local IP driver through
table lookup algorithm where a 16-bit TO address is found
corresponds to the IP address of a local host or gateway. The
order bits of the TO address of course refer to the adapter
the adapter attached to the destination host
The logical TO field should contain the protocol server address
the HYPERchannel IP driver for that host as determined by the host'
system administrator. Many HYPERchannel TCP/IP drivers in the
today are not "open" in that any network message delivered to
host will be presumed to be an IP datagram regardless of the
TO field; however any transmitting IP process should be capable
generating the entire 16-bit TO field in order to generate a
capable of reaching a destination IP process
The process of determining which HYPERchannel address will receive
IP datagram based on its IP address is a major topic that is
in "Address Resolution".
FROM
The FROM address is filled in with the address that the local
expects to receive from the network, but no particular use is make
the FROM address
MESSAGE
Network Systems requests that a value of 5 (decimal) be placed
this byte to uniquely indicate that the network message is being
to carry IP traffic. No other well-behaved protocol
HYPERchannel should duplicate this value of 5.
Hardwick & Lekashman [Page 19]
RFC 1044 IP on Network Systems HYPERchannel February 1988
Many current implementations of IP on HYPERchannel place a zero
other values in this field simply because no value was reserved
IP usage. Transmitting versions of IP should always place a 5
this field; receiving IP's should presume a delivered message to
an IP datagram until proven otherwise regardless of the contents
the Message Type field
Developers should note that it is often convenient to
reception of the value 0xFF00 in bytes 8 and 9 of the IP datagram
Transmitting a message with this value will cause it to be
back at the destination adapter and returned to the protocol
designate in the FROM address. This permits the developer have
applications talk to others on the same host for purposes of
interface or other protocol debugging
IP HEADER
Byte 9 contains the offset to the start of the IP header within
message proper, such that the Message Proper address plus the
header offset generates the address of the first byte of the
header (at least on byte addressable machines.)
This field is redundant with the offset field in byte 11, and
present for cosmetic compatibility with 32-bit implementations.
reception, the value in byte 11 should take precedence
As part of the migration to larger HYPERchannel headers, this
will become significant with the 32-bit addressing format, as
length of the header is no longer 10 bytes and byte 11 is used
other purposes
IP TYPE
Early implementations of IP drivers on HYPERchannel wanted to
bytes 8 and 9 alone for NSC use and place a "message type" field
later in the message. A value of 0x34 had been selected by
developers for reasons that are now of only historical interest
Once again, implementations should generate this value
transmission, but not check it on input, assuming that an IP
is present in the message
IP HEADER
This value is used by a number of commercial implementations of IP
HYPERchannel to align the start of the IP header within the
message. This offset is relative to byte 12 of the network
so that a value of zero indicates that the IP header begins in
12. This value should be both correctly generated on transmission
and always respected on input processing
Hardwick & Lekashman [Page 20]
RFC 1044 IP on Network Systems HYPERchannel February 1988
The maximum permissible offset in this field is 52 indicating
the IP header begins at the start of the associated data block
IP DATAGRAM
Beginning at the offset designated in byte 11, the IP datagram
treated as a contiguous block of data that flows from byte 63 of
message proper into the first byte of associated data, so that
entire message plus data is treated as a single contiguous block
If the IP header is small enough to fit within the entire
message, then only the message proper is transmitted. The length
the message proper sent should always be 64 bytes, even if the
datagram and HYPERchannel header do not occupy all 64 bytes of
message proper
If the datagram flows over into the associated data, then
message and data are sent. Since a number of machines cannot send
length of data to the HYPERchannel that is an exact number of
(due to 16-64 bits on the channel bus,) the length of the
data received should not be used as a guide to the length of the
datagram -- this should be extracted from the IP header. A
should verify, of course, that the associated data received is
least as long as is needed to hold the entire IP datagram
COMPATIBILITY WITH EXISTING
The basic format described here is clearly a compromise
several implementations of IP on HYPERchannel. Not all
implementations are interoperable with the standard described above
Currently there are two known "families" of IP HYPERchannel
in existence
THE "CRAY-NASA AMES"
This protocol is in the widest production use and has the
number of supported drivers in existence. It is interoperable
identical with the standard described above with the sole
that bytes 8 and 9 are set to zero by these drivers. As these
are ignored by most implementations of this driver, they have
assigned values to formalize the use of the message type field and
make it consistent with the 32-bit protocol
THE "TEKTRONIX-BERKELEY"
This protocol was historically the first IP on
implementation developed (at Tektronix) and subsequently made its
to Berkeley and BSD UNIX. This protocol is not interoperable
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
starts on byte 12. Comments in some of these drivers designate
11 as an "IP header offset" field, but apparently this value is
processed
The major difference (and the incompatibility) concerns the
of the IP datagram into the network message. Due to
difficulties in the early 80's with the sending and receiving of
small blocks of associated data on VAXes, this protocol the takes
curious approach to the placement of the IP header and the headers
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
header in the 64 byte message proper. In this case,
associated data is sent; only a message proper is used to
the data. The length of the message proper transmitted is
exact length needed to enclose the IP datagram; no padding
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
their associated data fields) are placed in the
data block, with the TCP/UDP header beginning at the
of the associated data block
- On transmission, the length of the message
transmitted is set to the length of the HYPERchannel
plus the IP header -- it is not padded out to 64 bytes
The length of the associated data sent should be
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
several reasons
1. Cray Research has performed exemplary work in dealing with
vendors to provide IP on HYPERchannel from the Cray computers
other hosts. As a result, there are 4 or 5 vendor
implementations of IP on HYPERchannel that use this approach
2. The two part structure of the message proper has its uses when
machine wishes to make protocol decisions before staging
transfer of an immense block of associated data into memory
Many network coprocessors and intelligent I/O subsystems find
simpler to read in the entire network message before
what to do with it. Arbitrarily catenating the two
does this best and permits streaming of messages from
technology network adapters
3. Some TCP users (mostly secure DoD sites) intend to load up
datagrams with optional fields in the future.
Tektronix-Berkeley implementation has problems if the IP
length exceeds 54 bytes
Hardwick & Lekashman [Page 23]
RFC 1044 IP on Network Systems HYPERchannel February 1988
EXTENDED (32-BIT) MESSAGE
Message
+------------------------------+-----------------------------+
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
+------------------------------+-----------------------------+
| |
| Remainder of IP datagram |
| |
| No associated data is present if IP |
| datagram fits in the Message Proper |
| |
+------------------------------+-----------------------------+
TRUNK
From the vantage of an IP driver, any trunk mask is valid so long
Hardwick & Lekashman [Page 24]
RFC 1044 IP on Network Systems HYPERchannel February 1988
it results in successful delivery of the HYPERchannel network
to its destination. There is no reason to check this field
validity on reception of the message. Specification of the
Mask on output is a local affair that can be specified by
transmitting driver's address resolution tables
The use of 0xFF in this value is strongly encouraged for any
other than those using exotic trunk configurations on a single
network
MESSAGE
Several new bits have been defined here
EXTENDED ADDRESSING. This bit should be set ON whenever a 32-
address (Network and/or Domain numbers nonzero) is present in
message. It should always be OFF with the 16-bit message header.
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
a 32-bit CRC of the associated data at the end of the associated
block when this bit is on. Similarly equipped adapters will
the trailing 32-bits of associated data (when the bit is on)
determine if the message contents have been corrupted at any stage
the transmission
Transmitting device drivers should include the ability to set
bit on transmission as a configuration option similar to the
HYPERchannel device interface used. The bit should be generated
be turned ON if the HYPERchannel IP driver is attached to an
equipped to generated CRC information -- it should be left OFF in
other circumstances
If a message arrives at the host with the CRC bit still on,
indicates that the CRC information was placed at the end
associated data by the transmitting adapter and not removed by
receiving adapter; thus the associated data will be four bytes
than otherwise expected. Since the IP datagram length is
contained in the network message, this should not impact IP drivers
It is possible for host computers to both generate and check this
information to match the hardware assisted generation and
logic in newer network adapters. Contact NSC if there are
applications requiring exceptional data integrity that could
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
drivers who have endeavored to provide a completely correct
address that properly reflects the adapter interface used. No
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
should take if it detects a real or imagined "security violation
should a message arrive with this bit absent
TO
The TO address logically constitutes bytes 2-5 of the
message
NETWORK AND DOMAIN NUMBERS. The Network and Domain numbers
both be nonzero when 32-bit addressing is used. If the message
local in nature, then the local Network and Domain numbers should
placed in this field
ADAPTER ADDRESS. Contains the adapter address as in the
message. The high order bit of this eight bit field (the "outnet
bit) should be set to zero if the destination network and domain
the same as the transmitting host's. The high order bit should
set to one if the destination host is not in the local network
domain
LOGICAL TO AND SUBADDRESS. The logical TO field should contain
protocol server address of the HYPERchannel IP driver for that
as determined by the host's system administrator
FROM
The FROM address is filled in with the address that the local
expects to receive from the network, but no particular use is made
the FROM address
MESSAGE
The value 6 must be placed in this byte to uniquely indicate that
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
basic format network messages using the 16-bit
addresses. The driver can distinguish an incoming network message
the value of byte 8 -- 32-bit messages will always have a 6 in
8, while 16-bit messages should have a 5 here. For
with older drivers, a value of 0 here should be treated as 16
bit messages
Hardwick & Lekashman [Page 26]
RFC 1044 IP on Network Systems HYPERchannel February 1988
IP HEADER
Byte 9 contains the offset to the start of the IP header within
message proper, such that the Message Proper address plus the
header offset generates the address of the first byte of the
header (at least on byte addressable machines.)
Unlike the 16-bit header, receiving IP drivers should assume
this field contains a correct offset to the IP header and examine
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
the vast majority of IP datagrams can be made by examining only
message proper, as the basic IP datagram will fit into the
proper if it begins at an offset of 44.
IP DATAGRAM
The message and data are treated as logically contiguous
where the first byte of associated data immediately follows the 64
byte of the message proper
If the entire IP datagram is less than or equal to (64-offset)
in length it will fit into the Message Proper. If so, only a
proper containing the HYPERchannel header and IP datagram is sent
the network
If the IP datagram is greater than this length, the IP
spills over into the associated data. On transmission, a 64
message proper is sent followed by as many bytes of associated
as are needed to send the entire datagram
On reception, the message proper can be read into the start of an
input buffer and the associated data read into memory 64 bytes
the start of the message. If the received message is in fact a 32-
bit address message, no "shuffling" of the message will be
to build a contiguous IP datagram -- it's right there at buffer+16.
ADDRESS RESOLUTION
Address Resolution Protocol has achieved a great deal of success
the Ethernet as it permits a local IP network to configure
simply by having each node know its own IP address. Those
with the intent, protocol, and logic of the Address
Protocol should refer to RFC-826, "An Ethernet Address
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
target HYPERchannel address is to obtained given the destination's
address. The protocol is defined in this section for completeness
Message
+------------------------------+-----------------------------+
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
exercise given the standards of ARP and the 32-bit message header.
few fields are worth remarking upon
TO
The TO address of an ARP message will be one of two classes
address. A "normal" address indicates that the message is an
response, or that it is an ARP request directed at an ARP server at
well known address on the local network. For those
networks which are equipped to broadcast, a value of 0xFFFFFF07
the TO address will (by convention) be picked up only by
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
the Address Resolution section
FROM
Must be the correct FROM address of the user protocol server
an ARP request. The Source Correct bit in the Message Flags
should be set by this requesting server, as some ARP servers
someday choose to issue ARP information on an "need to know" basis
secure environments. With an ARP response, the FROM address
contain the "normal" HYPERchannel address of the protocol
responding to the ARP address, even if that server was reached
broadcast mechanisms
ARP responses are returned to the party specified in the FROM
specified in the message header, rather than the address in
"Source HYPERchannel Address" field within the body of the
message
MESSAGE
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
at an arbitrary offset within the message proper, so the value
byte 9 is an extension of the message type
HEADER END
ARP uses the 32-bit addressing convention that byte 15 contains
offset to the start of user protocol (and hence the end of
protocol information). Note that this is not a substitute for the
offset fields, as this field also serves as the end of
header information -- future NSC message processing code may
take exception to "garbage" between the actual header end and
start of user data
HYPERCHANNEL HARDWARE TYPE
This 16-bit number is assigned a formal ARP hardware type of 8.
HYPERCHANNEL PROTOCOL
On the Ethernet, this field is used to distinguish IP from all
protocols that may require address resolution. To be
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
This contains the value 6, a sufficient number of bytes
accommodate the four byte HYPERchannel address and 2 bytes
indicate the largest IP datagram size that source and destination
handle
SOURCE AND DESTINATION HYPERCHANNEL
This field contains the Domain, Network, and Adapter/port address
source and destination, respectively. A value of 0000 in the
and Network fields has special significance as this is interpreted
a request to send and receive 16-bit HYPERchannel headers rather
32-bit headers. If 32-bit headers are to be used within a
HYPERchannel network, then the local domain and network numbers
be specified
MAXIMUM TRANSMISSION
HYPERchannel LAN 