RFC-826 , "An Ethernet Address Resolution Protocol" [2]. A later section of this document describes four techniques where a target HYPERchannel address is to obtained given the destination's IP addre
RFC-826, "An Ethernet Address Resolution
Protocol" [2].
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) |
+------------------------------+-----------------------------+
+------------------------------+-----------------------------+
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.
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.
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.
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.
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.
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.
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
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
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.
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
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.
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.
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.
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
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.