rfc1044.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        K. Hardwick
Request for Comments:  1044                                          NSC
                                                            J. Lekashman
                                                            NASA-Ames GE
                                                           February 1988


           Internet Protocol on Network Systems HYPERchannel
                         Protocol Specification

STATUS OF THIS MEMO

   The intent of this document is to provide a complete discussion of
   the protocols and techniques used to embed DoD standard Internet
   Protocol datagrams (and its associated higher level protocols) on
   Network Systems Corporation's HYPERchannel [1] equipment.
   Distribution of this memo is unlimited.

   This document is intended for network planners and implementors who
   are already familiar with the TCP/IP protocol suite and the
   techniques used to carry TCP/IP traffic on common networks such as
   the DDN or Ethernet.  No great familiarity with NSC products is
   assumed; an appendix is devoted to a review of NSC technologies and
   protocols.

   At the time of this first RFC edition, the contents of this document
   has already been reviewed by about a dozen vendors and users active
   in the use of TCP/IP on HYPERchannel media.  Comments and suggestions
   are still welcome (and implementable,) however.

   Any comments or questions on this specification may be directed to:

      Ken Hardwick
      Director, Software Technology
      Network Systems Corporation MS029
      7600 Boone Avenue North
      Brooklyn Park, MN 55428

      Phone: [phone]

      John Lekashman
      Nasa Ames Research Center. NAS/GE
      MS 258-6
      Moffett Field, CA, 94035
      [e-mail]

      Phone: [phone]




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


TABLE OF CONTENTS

    Status of this memo  . . . . . . . . . .  . . . . . . . . . . . .  1
    Goals of this document   . . . . . . . .  . . . . . . . . . . . .  3
    Basic HYPERchannel network messages  . .  . . . . . . . . . . . .  4
      Basic (16-bit address) Message Proper header  . . . . . . . . .  5
      TO addresses and open driver architecture   . . . . . . . . . .  7
      Extended (32-bit address) Message Proper header . . . . . . . .  8
      Address Recognition and message forwarding .  . . . . . . . . . 10
      32-bit message fields   . . . . . . . . . . . . . . . . . . . . 12
    Broadcasting   . . . . . . . . . . . . . . . . . .  . . . . . . . 14

    PROTOCOL SPECIFICATION .  .  .  . . . . . . . . . . . . . . . . . 17
      Basic (16-bit) Message Encapsulation    . . . . . . . . . . . . 18
      Compatibility with existing implementations . . . . . . . . . . 21
      Extended (32-bit) Message Encapsulation   . . . . . . . . . . . 24
      Address Resolution Protocol   . . . . . . . . . . . . . . . . . 27
      Maximum Transmission Unit . . . . . . . . . . . . . . . . . . . 31

    ADDRESS RESOLUTION    . . . . . . . . . . . . . . . . . . . . . . 32
      Local Address Resolution  . . . . . . . . . . . . . . . . . . . 33
      Configuration file format   . . . . . . . . . . . . . . . . . . 34
      ARP servers   . . . . . . . . . . . . . . . . . . . . . . . . . 35
      Broadcast ARP   . . . . . . . . . . . . . . . . . . . . . . . . 36

    Appendix A.
    NSC Product Architecture and Addressing   . . . . . . . . . . . . 38

    Appendix B.
    Network Systems HYPERchannel protocols    . . . . . . . . . . . . 42





















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


GOALS OF THIS DOCUMENT

   In this document, there are four major technical objectives:

   1.  To bless a "de facto" standard for IP on HYPERchannel that  has
       been implemented by Tektronix, Cray, NASA Ames, and others.
       We are attempting to resolve some interoperability problems with
       this standard so as to minimize the changes to existing IP on
       HYPERchannel software.  If any ambiguities remain in the de facto
       standard, we wish to assist in their resolution.

   2.  To address larger networks, NSC's newer network products are
       moving to a 32-bit address from the current 16-bit TO address.
       This document would introduce the addressing extension to the
       user community and specify how IP datagrams would work in the
       new addressing mode.

   3.  To define an Address Resolution Protocol for HYPERchannel and
       other NSC products.  It is probably well known that current NSC
       products do not support the broadcast modes that make ARP
       particularly useful.  However, many have expressed interest in
       "ARP  servers" at a known network address.  These servers could
       fade away as NSC products with broadcast capability come into
       existence.  Host drivers that can generate and recognize this
       ARP protocol would be prepared to take advantage of it as the
       pieces fall into place.

   4.  Part of this effort is to standardize the unofficial "message
       type" field that reserves byte 8 of the HYPERchannel network
       message.  To permit better interoperability, NSC will initiate a
       "network protocol registry" where any interested party may
       obtain a unique value in byte 8 (or bytes 8 and 9) for their own
       public, private, commercial or proprietary protocol.  Lists of
       assigned protocol type numbers and their "owners" will be
       periodically published by NSC and would be available to
       interested parties.















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


BASIC HYPERCHANNEL NETWORK MESSAGES

   Unlike most datagram delivery systems, the HYPERchannel network
   message consists of two parts:

             Message Proper
            +--------------------+
            |                    |
            |                    |
            |     10-64 bytes    |
            |                    |
            |                    |
            +--------------------+

             Associated Data
            +----------------------------------------------------+
            |                                                    |
            |                                                    |
            |                                                    |
            |                                                    |
            |           Unlimited length                         |
            |                                                    |
            |                                                    |
            |                                                    |
            |                                                    |
            +----------------------------------------------------+

   The first part is a message header that can be up to 64 bytes in
   length.  The first 10 bytes contain information required for the
   delivery of the entire message, and the remainder can be used by
   higher level protocols.  The second part of the message, the
   "Associated Data," can be optionally included with the message
   proper.  In most cases (transmission over HYPERchannel A trunks), the
   length of the associated data is literally unlimited.  Others (such
   as HYPERchannel B or transmission within a local HYPERchannel A A400
   adapter) limit the size of the Associated Data to 4K bytes.  If the
   information sent can be contained within the Message Proper, then the
   Associated Data need not be sent.

   HYPERchannel lower link protocols treat messages with and without
   Associated Data quite differently; "Message only" transmissions are
   sent using abbreviated protocols and can be queued in the receiving
   network adapter, thus minimizing the elapsed time needed to send and
   receive the messages.  When associated data is provided, the
   HYPERchannel A adapters free their logical resources towards driving
   the host interface and coaxial trunks.





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


BASIC (16-BIT ADDRESS) MESSAGE PROPER HEADER

   The first 10 bytes of the network Message Proper are examined by the
   network adapters to control delivery of the network message.  Its
   format is as follows:

    byte   Message Proper
         +------------------------------+-----------------------------+
      0  |      Trunks to Try           |        Message Flags        |
         |   TO trunks  |  FROM trunks  |                 |EXC|BST|A/D|
         +--------------+---------------+-----------------+---+---+---+
      2  |                        Access code                         |
         |                                                            |
         +------------------------------+-----------------------------+
      4  |       Physical addr of       |                   | TO Port |
         |     destination adapter (TO) |                   | number  |
         +------------------------------+-----------------------------+
      6  |  Physical addr of source     |                   |FROM port|
         |        adapter (FROM)        |                   |  number |
         +------------------------------+-----------------------------+
      8  |                        Message type                        |
         |                                                            |
         +------------------------------+-----------------------------+
     10  |                                                            |
         |            Available for higher level protocols            |
         |                                                            |
         |                                                            |
         +------------------------------+-----------------------------+

TRUNKS TO TRY

   Consists of two four bit masks indicating which of four possible
   HYPERchannel A coaxial data trunks are to be used to transmit the
   message and to return it.  If a bit in the mask is ON, then the
   adapter firmware will logically AND it with the mask of installed
   trunk interfaces and use the result as a candidate list of
   interfaces.  Whenever one of the internal "frames" are sent to
   communicate with the destination adapter, the transmission hardware
   electronically selects the first non-busy trunk out of the list of
   candidates.  Thus, selection of a data trunk is best performed by the
   adapter itself rather than by the host.  "Dedicating" trunks to
   specific applications only makes sense in very critical real time
   applications such as streaming data directly from high speed
   overrunnable peripherals.

   A second Trunk mask is provided for the receiving adapter when it
   sends frames back to the transmitter, as it is possible to build
   "asymmetric" configurations of data trunks where trunk 1 on one box



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


   is connected to the trunk 3 interface of a second.  Such
   configurations are strongly discouraged, but the addressing structure
   supports it if needed.

   The "trunks to try" field is only used by HYPERchannel A.  To assure
   maximum interoperability, a value of 0xFF should be placed in this
   field to assure delivery over any technology.  Other values should
   only be used if the particular site hardware is so configured to not
   be physically connected via those trunks.

MESSAGE FLAGS

   Contains options in message delivery.  In the basic type of message,
   three bits are used:

   ASSOCIATED DATA PRESENT (A/D) is ON if an Associated Data block
   follows the Message Proper.  0 if only a message proper is present in
   the network message.  The value of this bit is enforced by the
   network adapter firmware.

   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.