rfc2067.txt

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

   tries to connect for 32 bits.  If the 32 bit connection succeeds, the
   Source assumes that the Destination or path is not capable of double
   width operation, and uses only 32 bit requests after that.  If the 32
   bit request is rejected, the Source assumes that the Destination or
   path is down and makes no determination of its capability.

   The Double_Wide bit in the HIPPI-LE header, if nonzero, gives the
   node that receives it a hint that the 64 bit connection attempt may
   be worthwhile when sending on the return path.

   Note that Camp-on must be used at least in the 64 bit attempt,
   because it removes some ambiguity from the meaning of rejects.  If
   the request is made with the "W" bit and no Camp-on, a reject could
   mean either that the Destination has no Cable B or that it is simply
   busy, and no conclusion can be drawn as to its status for 64 bit
   connections.

9  Performance

   The HIPPI connection rules are designed to permit best utilization of
   the available HIPPI throughput under the constraint that each
   Destination must be made available frequently to receive packets from
   different Sources.  This discipline asks both Sources and
   Destinations to minimize connection setup overhead to deliver high
   performance.  Low connection setup times are easily achieved by
   hardware implementations, but overhead may be too high if software is
   required to execute between the initial request of a connection and
   the beginning of data transfer.  Hardware implementations in which
   connection setup and data transfer proceed from a single software
   action are very desirable.

   HIPPI connections are controlled by HIPPI Sources; a Destination,
   being unable to initiate a disconnect without the possibility of data
   loss, is a slave to the Source once it has accepted a connection.



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


   Optimizations of connection strategy are therefore the province of
   the HIPPI Source, and several optimizations are permitted.

   If the rate of available message traffic is less than the available
   HIPPI throughput and Destinations are seldom busy when a connection
   is requested, connection optimizations do not pay off and the
   simplest strategy of waiting indefinitely for each connection to be
   made and sending messages strictly in the order queued cannot be
   improved upon.  However if some nodes are slow, or network
   applications can send or receive messages at a higher aggregate rate
   than the available HIPPI bandwidth, Sources may frequently encounter
   a busy Destination.  In these cases, certain host output queuing
   strategies may enhance channel utilization.  Sources may maintain
   separate output queues for different HIPPI Destinations, and abandon
   one Destination in favor of another if a connection attempt without
   Camp-on is rejected or a connection request with Camp-on is not
   accepted within a predetermined interval.  Such a strategy results in
   aborted connection sequences (defined in HIPPI-PH:  REQUEST is
   deasserted before any data is sent).  Destinations must treat these
   as normal events, perhaps counting them but otherwise ignoring them.

   Two components of connection setup time are out of the control of
   both Source and Destination.  One is the time required for the switch
   to connect Source to Destination, currently less than four
   microseconds in the largest commercially available (32 port) switch.
   The second component is the round trip propagation time of the
   REQUEST and CONNECT signals, negligible on a standard 25 meter copper
   HIPPI cable, but contributing a total of about 10 microseconds per
   kilometer on fiber optic links.  HIPPI-SC LANs spanning more than a
   few kilometers will have reduced throughput.  Limited span networks
   with buffered gateways or bridges between them may perform better
   than long serial HIPPI links.

   A Source is required to drop its connection after the transmission of
   68 HIPPI bursts.  This number was chosen to allow the transmission of
   one maximum sized packet or a reasonable number of smaller sized
   packets.  The following table lists some possibilities, with
   calculated maximum burst and throughput rates in millions (10**6) of
   bytes per second:












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


                     Maximum HIPPI Throughput Rates

        Number  Number  Hold  Burst  ------Max throughput MB/sec-------
   User   of      of    Time  Rate    Connection Setup Overhead (usec)
   Data Packets Bursts (usec) MB/sec  10    30    60    90   120   150
   ---- ------- ------ ------ ------ ----  ----  ----  ----  ----  ----
   63K     1      64    654    98.7  97.2  94.4  90.4  86.8  83.4  80.3
   32K     2      66    665    98.6  97.1  94.3  90.4  86.8  83.5  80.4
   16K     4      68    667    98.3  96.8  94.1  90.2  86.6  83.3  80.2
    8K     7      63    587    97.8  96.1  93.0  88.7  84.8  81.2  77.8
    4K    13      65    551    96.7  95.0  91.7  87.2  83.1  79.4  76.0
    2K    22      66    476    94.6  92.7  89.0  84.0  79.6  75.6  72.0
    1K    34      68    384    90.8  88.5  84.2  78.5  73.5  75.8  65.3

   These calculations are based 259 40 ns clock periods to transmit a
   full burst and 23 clock periods for a short burst.  (HIPPI-PH
   specifies three clock periods of overhead per burst.) A packet of "n"
   kilobytes of user data consists of "n" full bursts and one short
   burst equal in length to the number of bytes in the HIPPI, LLC, IP
   and TCP headers.  "Hold Time" is the minimum connection duration
   needed to send the packets.  "Burst Rate" is the effective transfer
   rate for the duration of the connection, not counting connection
   switching time.  Throughput rates are in megabytes/second, accounting
   for connection switching times of 10, 30, 60, 90, 120 and 150
   microseconds.  These calculations ignore any limit on the rate at
   which a Source or Destination can process small packets; such limits
   may further reduce the available throughput if small packets are
   used.

10 Sharing the Switch

   Network interconnection is only one potential application of HIPPI
   and HIPPI-SC switches.  While network applications need very frequent
   transient connections, other applications may favor longer term or
   even permanent connections between Source and Destination.  Since the
   switch can serve each Source or Destination with hardware paths
   totally separate from every other, it is quite feasible to use the
   same switch to support LAN interconnects and computer/peripheral
   applications simultaneously.

   Switch sharing is no problem when unlike applications do not share a
   HIPPI cable on any path.  However if a host must use a single input
   or output cable for network as well as other kinds of traffic, or if
   a link between switches must be shared, care must be taken to ensure
   that all applications are compatible with the connection discipline
   described in this memo.  Applications that hold connections too long
   on links shared with network traffic may cause loss of network
   packets or serious degradation of network service.



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


11 References

   [1]  ANSI X3.183-1991, High-Performance Parallel Interface -
        Mechanical, Electrical and Signalling Protocol Specification
        (HIPPI-PH).

   [2]  ANSI X3.210-1992, High-Performance Parallel Interface - Framing
        Protocol (HIPPI-FP).

   [3]  ANSI X3.218-1993, High-Performance Parallel Interface -
        Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link
        Control Protocol Data Units (802.2 Link Encapsulation) (HIPPI-
        LE).

   [4]  ANSI X3.222-1993, High-Performance Parallel Interface - Physical
        Switch Control (HIPPI-SC).

   [5]  Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
        Sciences Institute, September 1981.

   [6]  IEEE, "IEEE Standards for Local Area Networks: Logical Link
        Control", IEEE, New York, New York, 1985.

   [7]  IEEE, "IEEE Standards for Local Area Networks: Logical Link
        Control", IEEE, New York, New York, 1985.

   [8]  Reynolds, J.K., and Postel, J., "Assigned Numbers", STD 2, RFC
        1340, USC/Information Sciences Institute, July 1992.

   [9]  Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191,
        Stanford University, November, 1990.

12 Security Considerations

   Security issues are not discussed in this memo.

13 Author's Address

   John K. Renwick
   NetStar, Inc.
   10250 Valley View Road
   Minneapolis, MN USA 55344

   Phone: [phone]
   EMail: [e-mail]

   Mailing List: [e-mail]




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


14 Appendix A -- HIPPI Basics

   This section is included as an aid to readers who are not completely
   familiar with the HIPPI standards.

   HIPPI-PH describes a parallel copper data channel between a Source
   and a Destination.  HIPPI transmits data in one direction only, so
   that two sets are required for bidirectional flow.  The following
   figure shows a simple point-to-point link between two computer
   systems:

   +----------+                                        +----------+
   |          |                                        |          |
   |          +--------+                      +--------+          |
   |          | HIPPI  |        Cable         | HIPPI  |          |
   |          |        +--------------------->|        |          |
   |          | Source |                      | Dest.  |          |
   |  System  +--------+                      +--------+  System  |
   |    X     +--------+                      +--------+    Y     |
   |          | HIPPI  |        Cable         | HIPPI  |          |
   |          |        |<---------------------+        |          |
   |          | Dest.  |                      | Source |          |
   |          +--------+                      +--------+          |
   |          |                                        |          |
   +----------+                                        +----------+

A Simple HIPPI Duplex Link

   Parallel copper cables may be up to 25 meters in length.

   In this document, all HIPPI connections are assumed to be paired
   HIPPI channels.

   HIPPI-PH has a single optional feature: it can use a single cable in
   each direction for a 32 bit parallel channel with a maximum data rate
   of 800 megabit/second, or two cables for 64 bits and 1600
   megabit/second.  Cable A carries bits 0-31 and is used in both modes;
   Cable B carries bits 32-63 and is use only with the 1600
   megabit/second data rate option.












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


HIPPI Signal Hierarchy

   HIPPI has the following hardware signals:

      Source to Destination

         INTERCONNECT A
         INTERCONNECT B (64 bit only)
         CLOCK (25 MHz)
         REQUEST
         PACKET
         BURST
         DATA (32 or 64 signals)
         PARITY (4 or 8 signals)

      Destination to Source

         INTERCONNECT A
         INTERCONNECT B (64 bit only)
         CONNECT
         READY

   The INTERCONNECT lines carry DC voltages that indicate that the cable
   is connected and that the remote interface has power.  INTERCONNECT
   is not used for signaling.

   The CLOCK signal is a continuous 25 MHz (40 ns period) square wave.
   All Source-to-Destination signals are synchronized to the clock.

   The REQUEST and CONNECT lines are used to establish logical
   connections.  A connection is always initiated by a Source as it
   asserts REQUEST.  At the same time it puts 32 bits of data on DATA
   lines 0-31, called the I-field.  The Destination samples the DATA
   lines and can complete a connection by asserting CONNECT.  Packets
   can be transmitted only while both REQUEST and CONNECT are asserted.

   A Destination can also reject a connection by asserting CONNECT for
   only a short interval between 4 and 16 HIPPI clock periods (160-640
   nanoseconds).  The Source knows a connection has been accepted when
   CONNECT is asserted for more than 16 clocks or it receives a READY
   pulse.

   Either Source or Destination can terminate a connection by
   deasserting REQUEST or CONNECT, respectively.  Normally connections
   are terminated by the Source after its last Packet has been sent.  A
   Destination cannot terminate a connection without potential loss of
   data.




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


                  +------+-------------------------+------+
                  | Idle |        Connected        | Idle | . . .