rfc2067.txt

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

5.3  I-Field format

   fi The I-field bits, as defined in HIPPI-SC, SHALL be set as follows:

         Locally Administered (bit 31) SHALL be zero.

         Reserved (bits 30, 29) should be zero.  Destinations SHALL
         accept any value for these bits.

         Double wide (bit 28) SHALL be set when Source Cable B is
         connected and the Source wants a 64 bit connection.  It SHALL
         be zero otherwise.

         Direction (bit 27) should be sent as zero, however
         Destinations SHALL accept either zero or one and interpret
         the Routing Control field accordingly, per HIPPI-SC.

         Path Selection (bits 26, 25) SHALL be 00, 01, or 11 (binary)
         at the Source's option.  00 (source route mode) indicates
         that the I-field bits 23-00 contain a 24 bit source route; 01
         or 11 (logical address mode) indicate that bits 23-00 contain
         12 bit Source and Destination Addresses.  The value 11 is



Renwick                     Standards Track                    [Page 12]

RFC 2067                     IP over HIPPI                  January 1997


         meaningful when more than one route exists from a Source to a
         Destination; it allows the switch to choose the route.  Use
         of 01 forces the switch always to use the same route for the
         same Source/Destination pair.

         Camp-on (bit 24) may be 1 or 0; however, a Source SHALL NOT
         make consecutive requests without Camp-on to the same
         Destination while the requests are being rejected.  The
         purpose of this restriction is to prevent a node from
         circumventing the fair share arbitration mechanism of the
         switch by repeating requests at a very high rate.

         If logical address mode is used:

            Source Address (bits 23-12) is not used.

            Destination Address (bits 11-0) SHALL contain the Switch
            Address of the Destination.

        If source route mode is used:

            Routing control (bits 23-00) SHALL contain the route to
            the Destination.

5.4  Rules For Connections

   The following rules for connection management by Source and
   Destination are intended to insure frequent, fair share access to
   Destinations for which multiple Sources are contending.  If possible,
   nodes should transfer data at full HIPPI speeds and hold connections
   no longer than necessary.

   A source may hold a connection for as long as it takes to send 68
   HIPPI bursts at what ever speed the two connected nodes can achieve
   together.  The number of packets sent in one connection is not
   limited, except that the number of bursts over all the packets should
   not exceed 68.  This is not a recommendation to send as many packets
   as possible per connection; one packet per connection is acceptable.
   The purpose of this limit is to give each Source an fair share of a
   common Destination's bandwidth.  Without a limit, if there is a
   Destination that is constantly in demand by multiple Sources, the
   Source that sends the most data per connection wins the greatest
   share of bandwidth.

   The limit of 68 bursts is not absolute.  An implementation may check
   the burst count after transmission of a packet and end the connection
   if it is greater than or equal to some threshold.  If this is done,
   the threshold should be less than 68 depending on the typical packet



Renwick                     Standards Track                    [Page 13]

RFC 2067                     IP over HIPPI                  January 1997


   size, to ensure that the 68 burst limit is not normally exceeded.
   For instance, a Source sending 64K packets would send two per
   connection (130 bursts) if it checked for 68 at the end of each
   packet.  In this situation the Source is required to check for a
   value small enough that it will not send a second packet in the same
   connection.

   Destinations SHALL accept all packets that arrive during a
   connection, and may discard those that exceed its buffering capacity.
   A Destination SHALL NOT abort a connection (deassert CONNECT) simply
   because too many bursts were received; however a Destination may
   abort a connection whose duration has exceeded a time period of the
   Destination's choosing, as long as the Source is allowed ample time
   to transmit its quota of bursts.

   The rules admonish the node to do certain things as fast as it can,
   however there is no absolute measure of compliance.  Nodes that
   cannot transfer data at full HIPPI speeds can still interoperate but
   the faster the implementation, the better the performance of the
   network will be.

   Assuming that bursts flow at the maximum rate, the most important
   factor in network throughput is the connection switching time,
   measured from the deassertion of REQUEST by the Source at the end of
   one connection to its first assertion of BURST after the
   establishment of the new connection.

   Implementations should keep this time as short as possible.  For a
   guideline, assuming parallel HIPPI and a single HIPPI-SC switch, ten
   microseconds permits nearly full HIPPI throughput with full-sized
   packets, and at 60 microseconds the available throughput is reduced
   by about 10%.  (See "Performance", below.)

   All HIPPI electrical signaling SHALL comply with HIPPI-PH.  In every
   case, the following rules go beyond what HIPPI-PH requires.

   Rules for the Source

   1.  Do not assert REQUEST until a packet is ready to send.

   2.  Transmit bursts as quickly as READYs permit.  Except for
       the required HIPPI Source Wait states, there should be no
       delay in the assertion of BURST whenever the Source's READY
       counter is nonzero.

   3.  Make a best effort to ensure that connection durations do
       not exceed 68 bursts.




Renwick                     Standards Track                    [Page 14]

RFC 2067                     IP over HIPPI                  January 1997


   4.  Deassert REQUEST immediately when no packet is available
       for immediate transmission or the last packet of the
       connection has been sent.

   Rules for the Destination

   1.   Reject all connections if unable to receive packets.
        This frees the requesting Source to connect to other
        Destinations with a minimum of delay.  Inability to receive
        packets is not a transient condition, but is the state of the
        Destination when its network interface is not initialized.

   2.  A HIPPI node should be prepared to efficiently accept
       connections and process incoming data packets.  While this
       may be best achieved by not asserting connect unless 68
       bursts worth of buffers is available, it may be possible to
       meet this requirement with fewer buffers.  This may be due to
       a priori agreement between nodes on packet sizes, the speed
       of the interface to move buffers, or other implementation
       dependent considerations.

   3.  Accept a connection immediately when buffers are
       available.  The Destination should never delay the acceptance
       of a connection unnecessarily.

   4.  Once initialized, a Destination may reject connection
       requests only for one of the following reasons:

     1.  The I-field was received with incorrect parity.

     2.  The I-field contents are invalid, e.g. the "W" bit set when the
         Destination does not support the 1600 megabit data rate option,
         the "Locally Administered" bit is set, the Source is not
         permitted to send to this Destination, etc.

     Transient conditions within the Destination, such as temporary
     buffer shortages, must never cause rejected connections.

   5.  Ignore aborted connection sequences.  Sources may time
       out and abandon attempts to connect; therefore aborted
       connection sequences are normal events.

5.5  MTU

   Maximum Transmission Unit (MTU) is defined as the length of the IP
   packet, including IP header, but not including any overhead below IP.
   Conventional LANs have MTU sizes determined by physical layer
   specification.  MTUs may be required simply because the chosen medium



Renwick                     Standards Track                    [Page 15]

RFC 2067                     IP over HIPPI                  January 1997


   won't work with larger packets, or they may serve to limit the amount
   of time a node must wait for an opportunity to send a packet.

   HIPPI has no inherent limit on packet size.  The HIPPI-FP header
   contains a 32 bit D2_Size field that, while it may limit packets to
   about 4 gigabytes, imposes no practical limit for networking
   purposes.  Even so, a HIPPI-SC switch used as a LAN needs an MTU so
   that Destination buffer sizes can be determined.

   The MTU for HIPPI-SC LANs is 65280 bytes.

   This value was selected because it allows the IP packet to fit in one
   64K byte buffer with up to 256 bytes of overhead.  The overhead is 40
   bytes at the present time; there are 216 bytes of room for expansion.

         HIPPI-FP Header                  8 bytes
         HIPPI-LE Header                 24 bytes
         IEEE 802.2 LLC/SNAP Headers      8 bytes
         Maximum IP packet size (MTU) 65280 bytes
                                      ------------
                           Total      65320 bytes (64K - 216)

6  Camp-on

   When several Sources contend for a single Destination, the Camp-on
   feature allows the HIPPI-SC switch to arbitrate and ensure that all
   Sources have fair access.  (HIPPI-SC does not specify the method of
   arbitration.)  Without Camp-on, the contending Sources would simply
   have to retry the connection repeatedly until it was accepted, and
   the fastest Source would usually win.  To guarantee fair share
   arbitration, Sources are prohibited from making repeated requests to
   the same Destination without Camp-on in such a way as to defeat the
   arbitration.

   There is another important reason to use Camp-on: when a connection
   without Camp-on is rejected, the Source cannot determine whether the
   rejection came from the requested Destination or from the switch.
   The Source also cannot tell the reason for the rejection, which could
   be either that the Destination was off line or not cabled, or the I-
   field was erroneous or had incorrect parity.  Sources should not
   treat a rejection of a request without Camp-on as an error.  Camp-on
   prevents rejection due to the temporary busy case; with one
   exception, rejection of a Camp-on request indicates an error
   condition, and an error event can be recorded.  The exception occurs
   when a 64 bit connection is attempted to a Destination that does not
   have Cable B connected, resulting in a reject.  This case is covered
   in "Channel Data Rate Discovery", below.




Renwick                     Standards Track                    [Page 16]

RFC 2067                     IP over HIPPI                  January 1997


7  Path MTU Discovery

   RFC 1191 [9] describes the method of determining MTU restrictions on
   an arbitrary network path between two hosts.  HIPPI nodes may use
   this method without modification to discover restrictions on paths
   between HIPPI-SC LANs and other networks.  Gateways between HIPPI-SC
   LANs and other types of networks should implement RFC 1191.

8  Channel Data Rate Discovery

   HIPPI exists in two data rate options (800 megabit/second and 1600
   megabit/second).  The higher data rate is achieved by making the
   HIPPI 64 bits parallel instead of 32, using an extra cable containing
   32 additional data bits and four parity bits.  HIPPI-SC switches can
   be designed to attach to both.  Source and Destination HIPPI
   implementations can be designed to operate at either rate, selectable
   at the time a connection is established.  The "W" bit (bit 28) of the
   I-field controls the width of the connection through the switch.
   Sources with both cables A and B attached to the switch may set the
   "W" bit to request a 1600 megabit/second connection.  If the
   requested destination also has both cables attached, the switch can
   connect Source to Destination on both cables.  If the requested
   Destination has only Cable A, the switch rejects the request.
   Sixty-four bit Sources can connect to 32 bit Destinations by
   requesting with the "W" bit clear and not using Cable B.  Sixty-four
   bit Destinations must examine the "W" bit in the received I-field and
   use or ignore Cable B accordingly.  Note that both INTERCONNECT
   signals stay active while a 64 bit HIPPI is used in 32 bit mode.

   The following table summarizes the possible combinations, the
   switch's action for each, and the width of the resulting connection.

                                     Destination
                      +-------------------+-------------------+
                      |        32         |        64         |
           +----+-----+-------------------+-------------------+
           |    | W=0 |     Accept 32     |     Accept 32     |
           | 32 +-----+-------------------+-------------------+
           |    | W=1 |        N/A        |        N/A        |
   Source  +----+-----+-------------------+-------------------+
           |    | W=0 |     Accept 32     |     Accept 32     |
           | 64 +-----+-------------------+-------------------+
           |    | W=1 |      Reject       |     Accept 64     |
           +----+-----+-------------------+-------------------+







Renwick                     Standards Track                    [Page 17]

RFC 2067                     IP over HIPPI                  January 1997


HIPPI Connection Combinations

   If the path between a 64 bit Source and a 64 bit Destination includes
   more than one switch, and the route between switches uses a link that
   is only 32 bits wide, the switch rejects 64 bit connection requests
   as if the Destination did not have 64 bit capability.

   In a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to
   know the data rates available at each Destination and on the path to
   it.  This can be known a priori by manual configuration, or it can be
   discovered dynamically.  The only reliable method of discovery is
   simply to attempt a 64 bit connection with Camp-on.  As long as 64
   bit connections succeed, the Source knows the Destination and path
   are double width.  If a 64 bit connection is rejected, the Source