rfc1223.txt

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

Network Working Group                                         J. Halpern
Request for Comments: 1223                                           NSC
                                                                May 1991


      OSI CLNS and LLC1 Protocols on Network Systems HYPERchannel

Status of this Memo

   The intent of this document is to provide a complete discussion of
   the protocols and techniques used to transmit OSI CLNS and LLC1
   datagrams (and any associated higher level protocols) on Network
   Systems Corporation's HYPERchannel equipment.  This document is
   intended for network planners and implementers who are already
   familiar with the OSI protocol suite and the techniques used to carry
   OSI traffic on standard networks such as 802.3.

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Table of Contents

     Goals of this Document   . . . . . . . . . . . . . . . . . . . . . 1
     HYPERchannel Network Messages  . . . . . . . . . . . . . . . . . . 2
       Message Proper Header  . . . . . . . . . . . . . . . . . . . . . 3
       TO Addresses and Open Driver Architecture  . . . . . . . . . . . 8
     Broadcasting   . . . . . . . . . . . . . . . . . . . . . . . . . . 9
       ES-IS  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
       IS-IS  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     References   . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Security Considerations  . . . . . . . . . . . . . . . . . . . .  12
     Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  12

Goals of this Document

   In this document, we have three major technical objectives:

   1.  To standardize the encapsulation of LLC1 packets over
       HYPERchannel.  The format will be used for OSI CLNS and for
       any other protocols using LLC1 over HYPERchannel.  (Note
       that if one desires to use the LLC1/SNAP combination for
       TCP/IP, this is the format to use.  This represents an
       alternative to the native mode for TCP/IP over HYPERchannel,
       allowing for sharing the medium at the LLC1 layer.)






Halpern                                                         [Page 1]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


   2.  To describe how multicast protocols such as ES-IS and IS-IS shall
       operate over HYPERchannel.  As a medium, HYPERchannel does not
       support either broadcast or multicast.  Therefore, special
       techniques are needed to handle these protocols.  Note that these
       techniques do not allow general multicast, although any specific
       problem may be solved by a generalization of these methods.

   3.  To make use of a standardized "message type" field in bytes
       8 and 9 of the HYPERchannel network message.  To permit better
       interoperability, NSC maintains 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" would be periodically published by NSC and
       are available to interested parties.

HYPERchannel Network Messages

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

           Message Proper
          +--------------------+
          |                    |
          |                    |
          |                    |
          |     16-64 bytes    |
          |                    |
          |                    |
          |                    |
          +--------------------+

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



Halpern                                                         [Page 2]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991



   The first part is a message header that can be up to 64 bytes in
   length.  The first 16 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-50 trunks) the
   length of the associated data is literally unlimited.  Others (such
   as HYPERchannel-10 or transmission within a local HYPERchannel-50
   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-50 adapters free their logical resources towards driving
   the host interface and coaxial trunks at maximum speed, so that data
   can flow through the transmitting channel, the coaxial cable, and the
   receiving channel concurrently.  Thus HYPERchannel-50 can approach
   the nominal burst speed of the computer host interface when sending
   large data blocks over an extended period.

Message Proper Header

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





















Halpern                                                         [Page 3]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


  byte   Message Proper
       +------------------------------------------------------------+
    0  |      Trunks to Try           |        Message Flags        |
       |   TO trunks  |  FROM trunks  |                         |A/D|
       +--------------+---------------+-------------------------+---+
    2  |         TO Domain #          |         TO Network #        |
       |                              |                             |
       +------------------------------+-----------------------------+
    4  |         TO Unit #            |        Logical To           |
       |                              |         (port number)       |
       +------------------------------+-----------------------------+
    6  |        From Unit #           |        Logical From         |
       |                              |         (port number)       |
       +------------------------------+-----------------------------+
    8  |                         Message type                       |
       |                           0x0B01                           |
       +------------------------------+-----------------------------+
    10 |          FROM Domain #       |       FROM Network #        |
       |                              |                             |
       +------------------------------+-----------------------------+
    12 |          True Unit           |         age count           |
       |                              |                             |
       +------------------------------+-----------------------------+
    14 |      Header End Offset       |      Next Header Offset     |
       |        (16)                  |        (16)                 |
       +------------------------------+-----------------------------+
    16 |   LLC1 destination SAP       |   LLC1 source SAP           |
       |      (0xFE for CLNP)         |      (0xFE for CLNP)        |
       +------------------------------+-----------------------------+
    18 |   LLC1 function code         |                             |
       |      (0x03 for normal data)  |Start of upper layer protocol|
       +------------------------------+                             +
    20 |        from bytes 19-63 of the message proper              |
       |        and continuing in the associated data               |
       |        (For OSI this is CLNP, then transport etc.)         |
       +------------------------------+-----------------------------+


Trunks to Try

   Consists of two four bit masks indicating which of four possible
   HYPERchannel-50 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



Halpern                                                         [Page 4]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


   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 overrunable 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 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-50.  To assure
   maximum interoperability, a value of 0xFF should be placed in this
   field to assure delivery over any technology.  The newer DX series
   units determine the trunk mask on their own, but this field is
   preserved for use with A series equipment.

Message Flags

   Contains options in message delivery.  There are several bits defined
   by the hardware.  However, only the A/D bit will be described here.
   Other bits are used only for special diagnostic or management
   purposes.  If there is a need to set them, check the specific Network
   Systems manuals on their meanings.  In the absence of such need, all
   bits other than A/D shall be set to zero on transmission, and not
   examined upon receipt of a message.

   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.

TO Domain Number

   This is the most significant byte of the four byte hyperchannel
   address.  It selects an NSC addressing domain, among a set of
   domains.  If this and the network number both refer to the local
   domain and network, they may be set to 0.

TO Network Number

   This is the destination network number.  It identifies the network
   within the selected domain, where the destination unit resides.  If
   the destination is in the local domain and network, both the TO
   domain and TO network numbers may be set to zero.



Halpern                                                         [Page 5]

RFC 1223              OSI and LLC1 on HYPERchannel              May 1991


TO Unit

   Upon arrival at the destination domain and network, this is the unit
   number of the destination HYPERchannel adapter.  The combination of
   Domain, Network, and Unit uniquely identify a single adapter in a
   HYPERchannel network.  For compatibility with existing HYPERchannel
   equipment, when sending a message to a destination outside the local
   domain and network, set this byte to 0, and store the actual
   destination unit number in the True Unit field.

Logical To

   This field further identifies which process the message is intended
   for.  With some hardware, the bottom bits select a machine from among
   several.  When sending a message to an N400, the bottom two bits of
   this field select which of four attached hosts the message is
   destined for.  Within a host, the logical to field selects a
   destination process.  This is used in conjunction with the Message
   Type field to insure that messages are delivered to the correct
   place.  The Logical TO field identifies a process, which then checks
   the Message Type to insure that it understands the message.  This
   also allows for running two processes, both of which understand the
   same protocol.

From Unit

   This identifies the Unit number from which this message was sent.

Logical From

   This identifies the host and process who originated this message.

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, an
   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.

   NSC now uses 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



Halpern                                                         [Page 6]