rfc1374.txt

中、英文RFC文档大全打包下载完全版 .

      Locally Administered (bit 31) shall be zero.

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




Renwick & Nicholson                                            [Page 11]

RFC 1374                  IP and ARP on HIPPI               October 1992


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

      Note:  the outcome of Switch Address Resolution (see "Address
      Resolution" below) determines whether to use logical address mode
      or source route mode.  If source route mode is used with multiple
      interconnected switches, different sources may use different
      addresses to reach the same destination, and multicast-based
      address resolution may not be possible because a target node may
      not know the route to itself from a given remote source.
      Regardless of this difficulty, it may be possible to use source
      route mode if the network consists of a single switch, or if
      address resolution is supported by an ARP agent that is able to
      deliver correct routes to each node.  The nodes themselves need
      not be concerned with these problems if they use the addressing



Renwick & Nicholson                                            [Page 12]

RFC 1374                  IP and ARP on HIPPI               October 1992


      mode suggested by the value of the Source_Address_Type field in a
      HIPPI-LE Address Resolution Response packet.

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




Renwick & Nicholson                                            [Page 13]

RFC 1374                  IP and ARP on HIPPI               October 1992


   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.

      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.





Renwick & Nicholson                                            [Page 14]

RFC 1374                  IP and ARP on HIPPI               October 1992


      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.

   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 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 (decimal) octets.

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







Renwick & Nicholson                                            [Page 15]

RFC 1374                  IP and ARP on HIPPI               October 1992


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


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.

Address Resolution

   The Internet Address Resolution Protocol (ARP) is defined in RFC 826
   [9].  Ethernet, FDDI and 802 networks use ARP to discover another
   host's ULA knowing the Internet address.  Reverse ARP [10] is used to
   discover the Internet address, knowing the ULA.  ARP can be used in
   the conventional way on HIPPI-SC LANs equipped with a multicast
   capability or third party ARP agent.

   HIPPI-LE defines similar lower-level address resolution between ULAs
   and switches.  HIPPI-LE adds a self-address resolution mechanism not
   defined for Internet ARP, which allows a node to discover its own
   switch address dynamically.




Renwick & Nicholson                                            [Page 16]

RFC 1374                  IP and ARP on HIPPI               October 1992


   ARP for the purpose of discovering ULAs is not necessary for the
   operation of a HIPPI-SC LAN, but it serves as the vehicle for
   discovery of HIPPI-SC Switch Addresses, without which the HIPPI-SC
   LAN cannot function.  In other words, at the same time a node is
   using ARP to map another node's IP address to its ULA, it is also
   mapping the ULA to the 12 bit HIPPI Switch Address, from which it
   will construct the I-field value for sending messages to that node.
   This additional level of hardware addressing uses the address fields
   in the HIPPI-LE header.