rfc1044.txt

RFC 的详细文档！

        -   All higher level protocol information (TCP/UDP header and
            their associated  data fields) are placed in the associated
            data block, with the TCP/UDP header beginning at the start
            of the associated data block.

        -   On transmission, the length of the message proper
            transmitted is set to the length of the HYPERchannel header
            plus the IP header --  it is not padded out to 64 bytes.
            The length of the associated data sent should be sufficient
            to accommodate the TCP/UDP header and its data fields.

















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


WHICH PROTOCOL IS BEST?

   In choosing which to follow, the "Cray-Ames" approach was taken for
   several reasons:

    1.  Cray Research has performed exemplary work in dealing with other
        vendors to provide IP on HYPERchannel from the Cray computers to
        other hosts.  As a result, there are 4 or 5 vendor supported
        implementations of IP on HYPERchannel that use this approach.

    2.  The two part structure of the message proper has its uses when a
        machine wishes to make protocol decisions before staging the
        transfer of an immense block of associated data into memory.
        Many network coprocessors and intelligent I/O subsystems find it
        simpler to read in the entire network message before deciding
        what to do with it.  Arbitrarily catenating the two components
        does this best and permits streaming of messages from future
        technology network adapters.

    3.  Some TCP users (mostly  secure  DoD  sites) intend to load up IP
        datagrams with optional fields in the future.  The
        Tektronix-Berkeley implementation has problems if the IP header
        length exceeds 54 bytes.




























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


EXTENDED (32-BIT) MESSAGE ENCAPSULATION

           Message Proper
         +------------------------------+-----------------------------+
      0  |      Trunks to Try           |1|       Message Flags       |
         |   TO trunks  |  FROM trunks  |GNA|CRC|     |SRC|EXC|BST|A/D|
         +------------------------------+-----------------------------+
      2  |    Destination  Domain       |    Destination  Network     |
         |         Number               |           Number            |
         +------------------------------+-----------------------------+
      4  |O|     Physical addr of       |  Protocol server  |Dest Port|
         |N|  destination adapter       |  logical address  | number  |
         +------------------------------+-----------------------------+
      6  |O|     Physical addr of       |    Originating    | Src Port|
         |N|     source  adapter        |  server address   |  number |
         +------------------------------+-----------------------------+
      8  |    IP on HYPERchannel        |   Offset to start of IP     |
         |    type code  0x06           |      datagram header        |
         +------------------------------+-----------------------------+
      10 |    Source Domain Number      |   Source Network Number     |
         |                              |                             |
         +------------------------------+-----------------------------+
      12 |          - reserved -        |         Age Count           |
         +------------------------------+-----------------------------+
      14 |      Next Header Offset      |      Header End Offset      |
         |                              |       (usually 16)          |
         +------------------------------+-----------------------------+
      16 |         Padding to IP header start (usually 0 bytes)       |
         |                                                            |
         +------------------------------+-----------------------------+
      Off|     Entire IP datagram if datagram length <= (64-Offset)   |
         |                                                            |
         |        else first (64-Offset) bytes of IP datagram         |
         +------------------------------+-----------------------------+

           Associated Data
         +------------------------------+-----------------------------+
         |                                                            |
         |                   Remainder of IP datagram                 |
         |                                                            |
         |            No associated data is present if IP             |
         |            datagram fits in the Message Proper             |
         |                                                            |
         +------------------------------+-----------------------------+

TRUNK MASK

   From the vantage of an IP driver, any trunk mask is valid so long as



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


   it results in successful delivery of the HYPERchannel network message
   to its destination.  There is no reason to check this field for
   validity on reception of the message.  Specification of the Trunk
   Mask on output is a local affair that can be specified by the
   transmitting driver's address resolution tables.

   The use of 0xFF in this value is strongly encouraged for any message
   other than those using exotic trunk configurations on a single local
   network.

MESSAGE FLAGS

   Several new bits have been defined here.

   EXTENDED ADDRESSING.  This bit should be set ON whenever a 32-bit
   address (Network and/or Domain numbers nonzero) is present in the
   message.  It should always be OFF with the 16-bit message header.  If
   this bit is improperly set, delivery of the message to the (apparent)
   destination is unlikely.

   END-TO-END CRC.  Some newer technology adapters are equipped to place
   a 32-bit CRC of the associated data at the end of the associated data
   block when this bit is on.  Similarly equipped adapters will examine
   the trailing 32-bits of associated data (when the bit is on) to
   determine if the message contents have been corrupted at any stage of
   the transmission.

   Transmitting device drivers should include the ability to set this
   bit on transmission as a configuration option similar to the specific
   HYPERchannel device interface used.  The bit should be generated to
   be turned ON if the HYPERchannel IP driver is attached to an adapter
   equipped to generated CRC information -- it should be left OFF in all
   other circumstances.

   If a message arrives at the host with the CRC bit still on, this
   indicates that the CRC information was placed at the end of
   associated data by the transmitting adapter and not removed by the
   receiving adapter; thus the associated data will be four bytes longer
   than otherwise expected.  Since the IP datagram length is self
   contained in the network message, this should not impact IP drivers.

   It is possible for host computers to both generate and check this CRC
   information to match the hardware assisted generation and checking
   logic in newer network adapters.  Contact NSC if there are particular
   applications requiring exceptional data integrity that could benefit
   from host generation and checking.





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


   FROM ADDRESS CORRECT.  This bit should be set by all transmitting IP
   drivers who have endeavored to provide a completely correct FROM
   address that properly reflects the adapter interface used.  No action
   should be taken on this bit by the receiving IP driver at this time.
   Additional work needs to be done to determine the action an IP driver
   should take if it detects a real or imagined "security violation"
   should a message arrive with this bit absent.

TO ADDRESS

   The TO address logically constitutes bytes 2-5 of the network
   message.

   NETWORK AND DOMAIN NUMBERS.  The Network and Domain numbers should
   both be nonzero when 32-bit addressing is used.  If the message is
   local in nature, then the local Network and Domain numbers should be
   placed in this field.

   ADAPTER ADDRESS.  Contains the adapter address as in the basic
   message.  The high order bit of this eight bit field (the "outnet"
   bit) should be set to zero if the destination network and domain are
   the same as the transmitting host's.  The high order bit should be
   set to one if the destination host is not in the local network or
   domain.

   LOGICAL TO AND SUBADDRESS.  The logical TO field should contain the
   protocol server address of the HYPERchannel IP driver for that host
   as determined by the host's system administrator.

FROM ADDRESS

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

MESSAGE TYPE

   The value 6 must be placed in this byte to uniquely indicate that the
   network message is being used to carry IP traffic.  No other well-
   behaved protocol using HYPERchannel should duplicate this value of 6.

   Note that all IP drivers should be prepared to send and receive the
   basic format network messages using the 16-bit HYPERchannel
   addresses.  The driver can distinguish an incoming network message by
   the value of byte 8 -- 32-bit messages will always have a 6 in byte
   8, while 16-bit messages should have a 5 here.  For interoperability
   with older drivers, a value of 0 here should be treated as 16 address
   bit messages.



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


IP HEADER OFFSET

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

   Unlike the 16-bit header, receiving IP drivers should assume that
   this field contains a correct offset to the IP header and examine the
   information at that offset for conformance to an IP datagram header.

   Valid offsets are in the range of 16 through 44 bytes, inclusive.
   The limitation of 44 bytes is imposed so that routing decisions on
   the vast majority of IP datagrams can be made by examining only the
   message proper, as the basic IP datagram will fit into the message
   proper if it begins at an offset of 44.

IP DATAGRAM CONTENTS

   The message and data are treated as logically contiguous entities
   where the first byte of associated data immediately follows the 64th
   byte of the message proper.

   If the entire IP datagram is less than or equal to (64-offset) bytes
   in length it will fit into the Message Proper.  If so, only a message
   proper containing the HYPERchannel header and IP datagram is sent on
   the network.

   If the IP datagram is greater than this length, the IP datagram
   spills over into the associated data.  On transmission, a 64 byte
   message proper is sent followed by as many bytes of associated data
   as are needed to send the entire datagram.

   On reception, the message proper can be read into the start of an IP
   input buffer and the associated data read into memory 64 bytes from
   the start of the message.  If the received message is in fact a 32-
   bit address message, no "shuffling" of the message will be required
   to build a contiguous IP datagram -- it's right there at buffer+16.

ADDRESS RESOLUTION PROTOCOL

   Address Resolution Protocol has achieved a great deal of success on
   the Ethernet as it permits a local IP network to configure itself
   simply by having each nod