rfc1044.txt

RFC 的详细文档！

   Address recognition takes place using the algorithm:

           IF Domain IN DomainMask OR
              IF (Domain = MyDomain AND Network IN NetworkMask) OR
                 IF (Domain = MyDomain AND Network = MyNetwork AND
                    Address IN AddressMask) THEN accept-message
                                            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 recognition
   logic will accept any messages to the box itself, any secondary or
   aliased local addresses owned by the adapter, and any message
   directed to a remote network or domain that that particular adapter
   is prepared to forward.


32-BIT MESSAGE FIELDS

TRUNK MASK

   Is as in the basic network message.  Messages that are to be
   delivered outside the immediate network should have 0xFF in this byte
   so that all possible trunks in intermediate networks should be tried.
   Locally delivered 32-bit messages may still contain specially
   tailored trunk masks to satisfy local delivery needs.

MESSAGE FLAGS

   The currently defined bits remain as before.  Three new bits have
   been defined since that time.

   CRC (END-END MESSAGE INTEGRITY).  Newer technology host adapters are
   capable of generating a 32-bit CRC for the entire network message as
   soon as it is received over the channel or bus interface from the
   host.  This 32-bit CRC is appended to the end of the associated data
   block and is preserved through the entire delivery process until it
   is checked by the host adapter that is the ultimate recipient of the
   message, which removes it.  This end to end integrity checking is
   designed to provide a high degree of assurance that data has been
   correctly moved through all intermediate LAN's, geographic links, and
   internal adapter hardware and processes.

   SRC (SOURCE FROM ADDRESS CORRECT).  This bit is provided to take
   advantage of the physical nature of the network address to optionally
   verify that the 32-bit FROM address provided in the network message
   is in fact the location that the message originated.  If the bit is
   not set by the transmitting host, no particular processing occurs on
   the message.  If the bit is set, then all intermediate adapters
   involved in the delivery of the message have the privilege of turning
   the bit off if the received message FROM address is not a TO address
   that would be delivered to the originator if the message were going
   the opposite direction.

   If the message is received by a host computer with this bit still
   set, then the FROM address is guaranteed correct in the sense that
   returning a message with TO and FROM information reversed will result
   in delivery of the message to the process that actually originated



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


   it.  By careful attention to the physical security of adapters and
   intermediate links between networks, a high degree of security can be
   built into systems that simply examine the FROM address of a message
   to determine the legitimacy of its associated request.

   GNA (GLOBAL NETWORK ADDRESSING).  This bit ON indicates that 32-bit
   addressing is present in the message.  When this bit is on, bytes 2-3
   (Domain and Network numbers) should also be nonzero.

TO ADDRESS

   Four bytes contain the TO address, which is used to deliver the
   network message as described in "Address Recognition and Message
   Forwarding" on page 8.  The "logical" part of the TO address is used
   to designate a protocol server exactly as in the basic format network
   message header.

   The existing "address" field has its high order bit reserved as an
   outnet bit for compatibility with existing A-series network adapter
   equipment.  Were it not for this bit, the A-series adapters would
   attempt to accept messages that were "passing through" the local
   network on their way elsewhere simply because the address field
   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 of
        networks containing A-Series adapters that will ever use 32-bit
        addressing must have their addresses in the range 00-7F (hex.)

    o   If a message is to be sent to a destination on a nonlocal
        network and domain on such an extended network, then the
        high order bit of the address field is turned on.

    o   When the last bridge in the chain realizes that it is about to
        forward the message to its final destination (the Domain and
        Network numbers are local), then it turns the Outnet bit off.
        This will result in local delivery to the destination adapter.

FROM ADDRESS

   The FROM address follows the same logic as the TO address in that any
   message can be returned to its source by reversing the FROM and TO
   fields of the message.  Since so many protocols examine byte 8 of the
   message to determine its type, the FROM field has been split so that
   the Domain and Network numbers extend into bytes 10-11.




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


MESSAGE TYPE

   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 future
   protocol which is layer on HYPERchannel messages for either private
   or public use.

AGE COUNT

   This field serves the same purpose as the IP "time to live" in that
   it prevents datagrams from endlessly circulating about in an
   improperly configured network.  Each time a 32-bit message passes
   through a bridge, the Age Count is decremented by one.  When the
   result is zero, the message is discarded by the bridge.

NEXT HEADER OFFSET AND HEADER END OFFSET

   These are used as fields to optionally provide "loose source
   routing", where a list of 32-bit TO addresses can be provided by the
   transmitter to explicitly determine the path of a message through the
   network.  If this feature is not used, both these fields would
   contain the value 16 (decimal) to both indicate extra TO addresses
   are absent and that the beginning of protocol data following the
   HYPERchannel header is in byte 16.

   Although it is conceivable that a HYPERchannel IP process could use
   this source routing capability to direct messages to hosts or
   gateways, this capability is not felt to be of sufficient value to IP
   to build it into a HYPERchannel IP protocol.

   In the future, all higher level protocols should be able to examine
   Header End Offset to determine the start of the higher level protocol
   information.

BROADCASTING

   NSC message forwarding protocols use low level link protocols to
   negotiate transmission of a message to its next destination on the
   network.  Furthermore, NSC network boxes often "fan out" so that
   several hosts share the same network transmission equipment as in the
   A400 adapter.  Both these characteristics mean that providing a
   genuine broadcast capability is not a trivial task, and in fact no
   current implementations of NSC technology support a broadcast
   capability.

   The last several years have seen broadcast applications mature to the
   point where they have virtually unquestioned utility on a local and
   sometimes campuswide basis.  Accordingly, new NSC technologies will



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


   support a broadcast capability.  Information on the use of this
   capability is included here as it is essential to the discussion of
   the Address Resolution Protocol later in this document.

   Broadcast capability will be supported only with the extended (32-bit
   address) message format.  A broadcast message will have the following
   general appearance:

    byte   Message Proper
         +------------------------------+-----------------------------+
      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 Data
    +-----------------------------------------------------------------+
    |                                                                 |
    |     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 FLAGS

   These fields are defined just as with a normal 32-bit message.  All
   bits in the Message Flags field are valid with broadcast modes.

BROADCAST ADDRESS

   For Domain, Network and Adapter Address fields, the value 0xFF is
   reserved for use by the broadcast mechanism.  A value of 0xFF in the
   adapter address field indicates to the local network hardware that
   this message is to be sent to all connected network equipment on the
   individual network.

   A value of 0xFF in the network or domain fields, respectively
   indicates a request that the scope of the broadcast exceed the local
   network.  The bridging link adapters will receive the broadcast
   message along with everyone else and will examine the "Broadcast
   Channel" field and their internal switches to determine if the
   message should be forwarded to other remote networks.

   If the Network and Domain fields contain the local network and
   domain, then the broadcast message will only be broadcast within the
   local network.  If a remote Network and Domain is specified, then the
   message will be delivered as a single message to the remote network
   and broadcast there.

BROADCAST CHANNEL

   Since individual hosts and protocol servers generally are not
   interested in all broadcast messages that float about the network, a
   filtering mechanism is provided in the header and network adapter
   equipment so that only proper classes of broadcast messages are
   delivered to the end point.

   Broadcast channel numbers in the range 00-0xFF will be assigned by
   NSC much like the "message type" field.  Host protocol servers
   specify a specific TO address containing a channel number (such as
   0xFF04) when they bind themselves to the HYPERchannel device driver.
   The driver and the underlying equipment will deliver only broadcast
   messages with the correct channel number to the protocol server.  If
   a protocol server wishes to receive several different broadcast
   messages, it must bind itself to the driver several times with the
   desired addresses.

   Link adapters that are prepared to handle multinetwork broadcast
   messages may be equipped with switches to determine which broadcast
   channels will be propagated into the next network.  Since
   multinetwork broadcast is an arrangement that must be configured with



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


   care, these switches are off by default.

FROM ADDRESS