rfc1044.txt

RFC 的详细文档！

   The FROM address is constructed just as with a normal 32-bit network
   message.  The Source Address Correct bit is processed just as with a
   normal message.

MESSAGE TYPE

   Message type is defined as with normal messages.  Presumably
   broadcast applications will have unique message types that are not
   generally found in normal messages.

AGE COUNT

   Age count is vitally important in a multinetwork broadcast as "loops"
   in the network can cause a great deal of activity until all the
   progeny of the original broadcast message die out.

PROTOCOL SPECIFICATION

   This section contains information on the technique used to
   encapsulate IP datagrams on the HYPERchannel network message.  It
   contains three sections to describe three protocol packagings:

    o   The technique used to encapsulate IP datagrams on the basic
        16-bit network message.  This is a de facto standard that has
        been in use for several years and is documented here to make it
        official.

    o   The encapsulation technique for IP datagrams on 32 bit network
        messages.

    o   The definition of an Address Resolution Protocol on
        HYPERchannel.















Hardwick & Lekashman                                           [Page 17]

RFC 1044           IP on Network Systems HYPERchannel      February 1988


BASIC (16-BIT) MESSAGE ENCAPSULATION

           Message Proper
         +------------------------------+-----------------------------+
      0  |      Trunks to Try           |        Message Flags        |
         |   TO trunks  |  FROM trunks  |GNA|CRC|     |SRC|EXC|BST|A/D|
         +------------------------------+-----------------------------+
      2  |                      Access code 0000                      |
         |                   (no longer supported)                    |
         +------------------------------+-----------------------------+
      4  |       Physical addr of       |  Protocol server  |Dest Port|
         |     destination adapter      |  logical address  | number  |
         +------------------------------+-----------------------------+
      6  |       Physical addr of       |    Originating    | Src Port|
         |       source  adapter        |  server address   |  number |
         +------------------------------+-----------------------------+
      8  |    IP on HYPERchannel        |   Offset to start of IP     |
         |    type code  0x05           |  header from message start  |
         +------------------------------+-----------------------------+
     10  |      IP type designator      |   Offset to start of IP     |
         |           0x34               |    header from byte 12      |
         +------------------------------+-----------------------------+
     12  |          Padding (variable length incl. zero bytes)        |
         |                                                            |
         +------------------------------+-----------------------------+
     Off |          First (64-Offset) bytes of IP datagram            |
         |                                                            |
         |                                                            |
         |                                                            |
         +------------------------------+-----------------------------+
           Associated Data
         +------------------------------+-----------------------------+
         |                                                            |
         |                Remainder of IP datagram                    |
         |                                                            |
         |            No associated data is present if IP             |
         |            datagram fits in the Message Proper             |
         |                                                            |
         +------------------------------+-----------------------------+

TRUNK MASK

   From the vantage of an IP driver, any trunk mask is valid so long as
   it results in successful delivery of the HYPERchannel network message
   to its destination.  There is no reason to check this field for
   validity on reception of the message.  Specification of the Trunk
   Mask on output is a local affair that could be specified by the
   transmitting driver's address resolution tables.



Hardwick & Lekashman                                           [Page 18]

RFC 1044           IP on Network Systems HYPERchannel      February 1988


MESSAGE FLAGS

   No use is made of the Flags field (byte 1) other than to
   appropriately set the Associated Data bit.  Burst Mode and the
   Exception bit should not be used with IP.

ACCESS CODE

   Although some current implementations of IP on HYPERchannel support
   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-bit
   addresses, no value other than 0000 should be placed in this field.

TO ADDRESS

   The TO field is generally obtained by a local IP driver through a
   table lookup algorithm where a 16-bit TO address is found that
   corresponds to the IP address of a local host or gateway.  The high
   order bits of the TO address of course refer to the adapter number
   the adapter attached to the destination host.

   The logical TO field should contain the protocol server address of
   the HYPERchannel IP driver for that host as determined by the host's
   system administrator.  Many HYPERchannel TCP/IP drivers in the field
   today are not "open" in that any network message delivered to that
   host will be presumed to be an IP datagram regardless of the logical
   TO field; however any transmitting IP process should be capable of
   generating the entire 16-bit TO field in order to generate a message
   capable of reaching a destination IP process.

   The process of determining which HYPERchannel address will receive an
   IP datagram based on its IP address is a major topic that is covered
   in "Address Resolution".

FROM ADDRESS

   The FROM address is filled in with the address that the local driver
   expects to receive from the network, but no particular use is make of
   the FROM address.

MESSAGE TYPE

   Network Systems requests that a value of 5 (decimal) be placed in
   this byte to uniquely indicate that the network message is being used
   to carry IP traffic.  No other well-behaved protocol using
   HYPERchannel should duplicate this value of 5.





Hardwick & Lekashman                                           [Page 19]

RFC 1044           IP on Network Systems HYPERchannel      February 1988


   Many current implementations of IP on HYPERchannel place a zero or
   other values in this field simply because no value was reserved for
   IP usage.  Transmitting versions of IP should always place a 5 in
   this field; receiving IP's should presume a delivered message to be
   an IP datagram until proven otherwise regardless of the contents of
   the Message Type field.

   Developers should note that it is often convenient to permit
   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 looped
   back at the destination adapter and returned to the protocol server
   designate in the FROM address.  This permits the developer have host
   applications talk to others on the same host for purposes of network
   interface or other protocol debugging.
IP HEADER OFFSET

   Byte 9 contains the offset to the start of the IP header within the
   message proper, such that the Message Proper address plus the IP
   header offset generates the address of the first byte of the IP
   header (at least on byte addressable machines.)

   This field is redundant with the offset field in byte 11, and is
   present for cosmetic compatibility with 32-bit implementations.  On
   reception, the value in byte 11 should take precedence.

   As part of the migration to larger HYPERchannel headers, this field
   will become significant with the 32-bit addressing format, as the
   length of the header is no longer 10 bytes and byte 11 is used for
   other purposes.

IP TYPE DESIGNATOR

   Early implementations of IP drivers on HYPERchannel wanted to leave
   bytes 8 and 9 alone for NSC use and place a "message type" field in
   later in the message.  A value of 0x34 had been selected by earlier
   developers for reasons that are now of only historical interest.
   Once again, implementations should generate this value on
   transmission, but not check it on input, assuming that an IP datagram
   is present in the message.

IP HEADER OFFSET

   This value is used by a number of commercial implementations of IP on
   HYPERchannel to align the start of the IP header within the network
   message.  This offset is relative to byte 12 of the network message
   so that a value of zero indicates that the IP header begins in byte
   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 that
   the IP header begins at the start of the associated data block.

IP DATAGRAM CONTENTS

   Beginning at the offset designated in byte 11, the IP datagram is
   treated as a contiguous block of data that flows from byte 63 of the
   message proper into the first byte of associated data, so that the
   entire message plus data is treated as a single contiguous block.

   If the IP header is small enough to fit within the entire network
   message, then only the message proper is transmitted.  The length of
   the message proper sent should always be 64 bytes, even if the IP
   datagram and HYPERchannel header do not occupy all 64 bytes of the
   message proper.

   If the datagram flows over into the associated data, then both
   message and data are sent.  Since a number of machines cannot send a
   length of data to the HYPERchannel that is an exact number of bytes
   (due to 16-64 bits on the channel bus,) the length of the associated
   data received should not be used as a guide to the length of the IP
   datagram -- this should be extracted from the IP header.  A driver
   should verify, of course, that the associated data received is at
   least as long as is needed to hold the entire IP datagram.

COMPATIBILITY WITH EXISTING IMPLEMENTATIONS

   The basic format described here is clearly a compromise between
   several implementations of IP on HYPERchannel.  Not all existing
   implementations are interoperable with the standard described above.
   Currently there are two known "families" of IP HYPERchannel drivers
   in existence:

THE "CRAY-NASA AMES" PROTOCOL

   This protocol is in the widest production use and has the largest
   number of supported drivers in existence.  It is interoperable and
   identical with the standard described above with the sole exception
   that bytes 8 and 9 are set to zero by these drivers.  As these bytes
   are ignored by most implementations of this driver, they have been
   assigned values to formalize the use of the message type field and to
   make it consistent with the 32-bit protocol.

THE "TEKTRONIX-BERKELEY" PROTOCOL

   This protocol was historically the first IP on HYPERchannel
   implementation developed (at Tektronix) and subsequently made its way
   to Berkeley and BSD UNIX.  This protocol is not interoperable with



Hardwick & Lekashman                                           [Page 21]

RFC 1044           IP on Network Systems HYPERchannel      February 1988


   the standard described above due to several distinct differences.

   First, bytes 8 through 11 are always zero.  The IP header always
   starts on byte 12.  Comments in some of these drivers designate byte
   11 as an "IP header offset" field, but apparently this value is never
   processed.

   The major difference (and the incompatibility) concerns the packaging
   of the IP datagram into the network message.  Due to historical
   difficulties in the early 80's with the sending and receiving of very
   small blocks of associated data on VAXes, this protocol the takes a
   curious approach to the placement of the IP header and the headers of
   higher level protocols (such as TCP or UDP.)

    o   If the entire length of the IP datagram is 54 bytes or less,
        it is possible to fit the entire datagram and the HYPERchannel
        header in the 64 byte message proper.  In this case, no
        associated data is sent; only a message proper is used to carry
        the data.  The length of the message proper transmitted is the
        exact length needed to enclose the IP datagram; no padding bytes
        are sent at the end of the message.

    o   If the length of the IP header is greater than 54 bytes, then: