rfc1044.txt

RFC 的详细文档！

   BURST MODE (BST) Enables a special mode for time critical transfers
   where a single HYPERchannel A coaxial trunk is dedicated during
   transmission of the network message.  Not recommended for anything
   that won't cause peripheral device overruns if data isn't delivered
   once message transmission starts.

   EXCEPTION (EXC) Indicates to some channel programmed host interfaces
   that the message is "out of band" in some way and requires special
   processing.

ACCESS CODE

   A feature to permit adapters to share use of a cable yet still permit
   an "access matrix" of which adapter boxes and physically talk to
   which others.  Not currently in use by anyone, support is being
   discontinued.

TO ADDRESS

   Consists of three parts.  The high order 8-bits contains the physical
   address of the network adapter box which is to receive the message.
   The low order 8-bits are interpreted in different ways depending on
   the nature of the receiving network adapter.  If the receiving
   adapter has different host "ports," then the low order bits of the TO
   field are used to designate which interface is to receive the
   message.  On IBM data channels, the entire "logical" TO field is
   interpreted as the subchannel on which the incoming data is to be
   presented.  Parts of the logical TO field that are not interpreted by



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


   the network adapter are passed to the host for further
   interpretation.

FROM ADDRESS

   The FROM address is not physically used during the process of
   transmitting a network message, but is passed through to the
   receiving host so that a response can be returned to the point of
   origin.  In general, reversing the TO and FROM 16-bit address fields
   and the TO and FROM trunk masks can reliably return a message to its
   destination.

MESSAGE TYPE

   The following two bytes are reserved for NSC.  Users have been
   encouraged to put a zero in byte 8 and anything at all in byte 9 so
   as to not conflict with internal processing of messages by NSC
   firmware.  In the past, this field has been loosely defined as
   carrying information of interest to NSC equipment carrying the
   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 to
   "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 will
   be assigned a unique value in byte 8 that will (among good citizens)
   not duplicate a value generated by a different protocol.  Minor
   protocols will have 16-bit values assigned to them so that we won't
   run out when 256 protocols turn up.  Any interested party could
   obtain a protocol number or numbers by application to NSC.  In this
   document, protocol types specific to IP protocols are assigned.

TO ADDRESSES AND OPEN DRIVER ARCHITECTURE

   Since not all 16-bits of the TO address are used for the physical
   delivery of the network message, the remainder are considered
   "logical" in that their meaning is physically determined by host
   computer software or (in cases such as the FIPS data channel) by
   hardware in the host interface.

   Since HYPERchannel is and will be used to support a large variety of
   general and special purpose protocols, it is desirable that several
   independent protocol servers be able to independently share the
   HYPERchannel network interface.  The implementation of many of NSC's
   device drivers as well as those of other parties (such as Cray
   Research) support this service.  Each protocol server that wishes to
   send or receive HYPERchannel network messages logically "connects" to
   a HYPERchannel device driver by specifying the complete 16-bit TO



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 that
   TO address will be delivered to that protocol server.

   The logical TO field serves a function similar to the TYPE byte in
   the Ethernet 802.2 message header, but differs from it in that the
   width of the logical TO field varies from host to host, and that no
   values of the logical TO address are reserved for particular
   protocols.  On the other hand, it is possible to have several
   "identical" protocols (such as two independent copies of IP with
   different HYPERchannel addresses) sharing the same physical
   HYPERchannel interface.  This makes NSC's addressing approach
   identical to the OSI concept that the protocol server to reach is
   embedded within the address, rather than the IP notion of addressing
   a "host" and identifying a server through a message type.

   Since the HYPERchannel header also has a "message type" field, there
   is some ambiguity concerning the respective roles of the message type
   and logical TO fields:

    o   The logical TO field is always used to identify the protocol
        server which will receive the message.  Once a server has
        specified the complete TO address for the messages it wishes to
        receive, the message will not be delivered to a different
        protocol server regardless of the contents of the message type
        field.

    o   Although the "type" field cannot change the protocol server at
        the final destination of the message, the type field can be used
        by intermediate processes on the network to process the message
        before it reaches the server destination.  An obvious example is
        the 0xFF00 message loopback type function, where network
        processing to loop back the message results in nondelivery to
        the TO address.  In the future, intermediate nodes may process
        "in transit" messages based on the message type only for
        purposes such as security validation, aging of certain
        datagrams, and network management.

EXTENDED (32-BIT ADDRESS) MESSAGE PROPER HEADER

   In the original days of HYPERchannel, the limitation of 256 adapter
   "boxes" that could be addressed in a network message was deemed
   sufficient as 40 or so adapters was considered a "large" network.  As
   with the Ethernet, more recent networks have resulted in a need to
   address larger networks.  Although a few ad hoc modes have existed to
   address larger HYPERchannel networks for some years, newer
   technologies of HYPERchannel equipment have logically extended the
   network message to support 32-bits of addressing, with 24 of those
   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 network
   adapters are capable of sending and receiving these messages.  Only
   the network bridges need the intelligence to select messages
   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 Data
   +-----------------------------------------------------------------+
   |                                                                 |
   |     As with basic format network messages                       |
   |                                                                 |
   +-----------------------------------------------------------------+

ADDRESS RECOGNITION AND MESSAGE FORWARDING

   With the 32-bit form of addressing, NSC is keeping with the premise
   that the native HYPERchannel address bears a direct relation to the
   position of the equipment in an extended HYPERchannel network.

   Each collection of "locally" attached NSC network adapters that are
   connected by coax or fiber optic cable (with the possible addition of
   nonselective repeaters such as the ATRn series) is considered a
   "network".  Each network can have up to 256 directly addressable
   adapters attached to it which can be reached by the basic format



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


   network message.

   Existing bridges or "link adapters" can be programmed to become
   "selective repeaters" in that they can receive network messages
   containing a subset of network addresses send them over the bridge
   medium (if present) and reintroduce them on the other network.  Such
   interconnected local area networks are considered a single network
   from an addressing point of view.

   A large NSC network can have up to 64K networks which can be
   complexly interconnected by network bridges and/or "backbone"
   networks which distribute data between other networks.  To simplify
   the mechanics of message forwarding, the 16-bit network field is
   divided into two eight quantities, a "network number" identifying
   which network is to receive the message and a "domain number" which
   specifies which network of networks is the recipient.

   The bridge technology adapters which move messages between networks
   have address recognition hardware which examines all the 24-bits in
   bytes 2-5 of the network message header to determine if the bridge
   should accept the message for forwarding.  At any given instant of
   time in the network, each bridge will have a list of networks and
   domains that it should accept for forwarding to a network at the
   other end of the bridge.  Each Adapter (Including Newer Technology
   host adapters) contains in address recognition hardware:

    o   domainmask -- a 256-bit mask of domain numbers that should  be
        accepted for forwarding (not local processing) by this adapter.
    o   MyDomain  --  the  value  of the domain on which this host
        adapter or bridge end is installed.
    o   NetworkMask -- a 256-bit mask of network numbers that should be
        accepted for forwarding by this adapter.
    o   MyNetwork  -  the  value of the network on which this host
        adapter or bridge end is installed.
    o   AddressMask -- A 256-bit mask of the local network addresses
        that should be accepted by the adapter.
    o   MyAddress -- the "base address" of the box, which must be
        supplied in any message that is directed to control processes
        within the adapter, such as a loopback message.