home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1374 < prev    next >
Text File  |  1992-10-28  |  101KB  |  2,412 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         J. Renwick
  8. Request for Comments: 1374                                  A. Nicholson
  9.                                                      Cray Research, Inc.
  10.                                                             October 1992
  11.                           IP and ARP on HIPPI
  12.  
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC specifies an IAB standards track protocol for the Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    The ANSI X3T9.3 committee has drafted a proposal for the
  26.    encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on
  27.    HIPPI.  Another X3T9.3 draft describes the operation of HIPPI
  28.    physical switches.  X3T9.3 chose to leave HIPPI networking issues
  29.    largely outside the scope of their standards; this document discusses
  30.    methods of using of ANSI standard HIPPI hardware and protocols in the
  31.    context of the Internet, including the use of HIPPI switches as LANs
  32.    and interoperation with other networks.  
  33.  
  34.  
  35. Table of Contents
  36.  
  37.       Introduction                                                   2
  38.       Scope                                                          2
  39.       Definitions                                                    3
  40.       Equipment                                                      4
  41.       Protocol                                                       6
  42.  
  43.          Packet Format                                               6
  44.          48 bit Universal LAN MAC addresses                         10
  45.          I-Field Format                                             11
  46.          Rules For Connections                                      13
  47.          MTU                                                        15
  48.  
  49.       Camp-on                                                       16
  50.       Address Resolution                                            16
  51.  
  52.          ARP and RARP Message Format                                17
  53.          ARP Procedure                                              21
  54.          ARP Implementation Methods                                 22
  55.  
  56.  
  57.  
  58. Renwick & Nicholson                                             [Page 1]
  59.  
  60. RFC 1374                  IP and ARP on HIPPI               October 1992
  61.  
  62.  
  63.          ARP Example                                                23
  64.          Discovery of One's Own Switch Address                      25
  65.  
  66.       Path MTU Discovery                                            27
  67.       Channel Data Rate Discovery                                   27
  68.       Performance                                                   29
  69.       Sharing the Switch                                            31
  70.       Appendix A -- HIPPI Basics                                    31
  71.       Appendix B -- How to Build a Practical HIPPI LAN              37
  72.       References                                                    41
  73.       Security Considerations                                       42
  74.       Authors' Addresses                                            42
  75.  
  76. Introduction
  77.  
  78.    The ANSI High-Performance Parallel Interface (HIPPI) is a simplex
  79.    data channel.  Configured in pairs, HIPPI can send and receive data
  80.    simultaneously at nearly 800 megabits per second.  (HIPPI has an
  81.    equally applicable 1600 megabit/second option.) Between 1987 and
  82.    1991, the ANSI X3T9.3 HIPPI working group drafted four documents that
  83.    bear on the use of HIPPI as a network interface.  They cover the
  84.    physical and electrical specification (HIPPI-PH [1]), the framing of
  85.    a stream of octets (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC
  86.    (HIPPI-LE [3]), and the behavior of a standard physical layer switch
  87.    (HIPPI-SC [4]).  HIPPI-LE also implies the encapsulation of Internet
  88.    Protocol[5].  The reader should be familiar with the ANSI HIPPI
  89.    documents, copies of which are archived at the site
  90.    "nsco.network.com" in the directory "hippi," and may be obtained via
  91.    anonymous FTP until they become published standards.
  92.  
  93.    HIPPI switches can be used to connect a variety of computers and
  94.    peripheral equipment for many purposes, but the working group stopped
  95.    short of describing their use as Local Area Networks.  This memo
  96.    takes up where the working group left off, using the guiding
  97.    principle that except for length and hardware header, Internet
  98.    datagrams sent on HIPPI should be identical to the same datagrams
  99.    sent on a conventional network, and that any datagram sent on a
  100.    conventional 802 network[6] should be valid on HIPPI.
  101.  
  102. Scope
  103.  
  104.    This memo describes the HIPPI interface between a host and a
  105.    crosspoint switch that complies with the HIPPI-SC draft standard.
  106.    Issues that have no impact on host implementations are outside the
  107.    scope of this memo.  Host implementations that comply with this memo
  108.    are believed to be interoperable on a network composed of a single
  109.    HIPPI-SC switch.  They are also interoperable on a simple point-to-
  110.    point, two-way HIPPI connection with no switch between them.  They
  111.  
  112.  
  113.  
  114. Renwick & Nicholson                                             [Page 2]
  115.  
  116. RFC 1374                  IP and ARP on HIPPI               October 1992
  117.  
  118.  
  119.    may as well be interoperable on more complex networks, depending on
  120.    the internals of the switches and how they are interconnected;
  121.    however, these details are implementation dependent and outside the
  122.    scope of this memo.  To the extent that a gateway acts as a host on a
  123.    HIPPI-SC LAN, its behavior is within the scope of this memo.
  124.  
  125.    Within the scope of this memo are:
  126.  
  127.    1.  Packet format and header contents, including HIPPI-FP, HIPPI-LE,
  128.        IEEE 802.2 LLC[7], SNAP and ARP
  129.  
  130.    2.  I-Field contents
  131.  
  132.    3.  HIPPI switch address resolution, including self discovery
  133.  
  134.    4.  Rules for the use of connections.
  135.  
  136.    Outside of the scope are
  137.  
  138.    1.  Vendor dependent solutions for multicast or third party ARP
  139.  
  140.    2.  Network configuration and management
  141.  
  142.    3.  Host internal optimizations
  143.  
  144.    4.  The interface between a host and an outboard protocol processor.
  145.  
  146. Definitions
  147.  
  148.    Conventional
  149.       Used with respect to networks, this refers to Ethernet, FDDI and
  150.       802 LAN types, as distinct from HIPPI-SC LANs.
  151.  
  152.    Destination
  153.       The HIPPI implementation that receives data from a HIPPI Source.
  154.  
  155.    Node
  156.       An entity consisting of one HIPPI Source/Destination pair that is
  157.       connected by parallel or serial HIPPI to a HIPPI-SC switch and
  158.       that transmits and receives ARP and IP datagrams.  A node may be
  159.       an Internet host, bridge, router or gateway.  This memo uses the
  160.       term node in place of the usual "host" to indicate that a host
  161.       might be connected to the HIPPI LAN not directly, but through an
  162.       external adaptor that does some of the protocol processing for the
  163.       host.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Renwick & Nicholson                                             [Page 3]
  171.  
  172. RFC 1374                  IP and ARP on HIPPI               October 1992
  173.  
  174.  
  175.    Serial HIPPI
  176.       An implementation of HIPPI in serial fashion on coaxial cable or
  177.       optical fiber, informally standardized by implementor's agreement
  178.       in the Spring of 1991.
  179.  
  180.    Switch Address
  181.       A value used as the address of a node on a HIPPI-SC network.  It
  182.       is transmitted in the I-field.  HIPPI-SC switches may map Switch
  183.       Addresses to physical port numbers.
  184.  
  185.    Source
  186.       The HIPPI implementation that generates data to send to a HIPPI
  187.       Destination.
  188.  
  189.    Universal LAN Address (ULA)
  190.       A 48 bit globally unique address, administered by the IEEE,
  191.       assigned to each node on an Ethernet, FDDI, 802 network or HIPPI-
  192.       SC LAN.
  193.  
  194. Equipment
  195.  
  196.    A HIPPI network can be composed of nodes with HIPPI interfaces, HIPPI
  197.    cables or serial links, HIPPI-SC switches, gateways to other networks
  198.    and, possibly, proprietary equipment that multicasts or responds to
  199.    ARP requests on behalf of the real nodes.
  200.  
  201.    Each HIPPI interconnection between a node and a switch shall consist
  202.    of a pair of HIPPI links, one in each direction.
  203.  
  204.    If a link between a node and the switch is capable of the 1600
  205.    Megabit/second data rate option (i.e. Cable B installed for 64 bit
  206.    wide operation) in either direction, the node's HIPPI-PH
  207.    implementation shall also be capable of 32 bit operation (Cable B
  208.    data suppressed) and shall be able to select or deselect the 1600Mb/s
  209.    data rate option at the establishment of each new connection.
  210.  
  211.    The following figure shows a sample HIPPI switch configuration.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Renwick & Nicholson                                             [Page 4]
  227.  
  228. RFC 1374                  IP and ARP on HIPPI               October 1992
  229.  
  230.  
  231.                                                    +-----+
  232.    |                                               | H 4 |
  233.    |                                               +--+--+
  234.    |                   +----+    +----+    +----+     |
  235.    |                   | H1 |    | H2 |    | H3 |   +-++
  236.    |   +--+            +-++-+    +-++-+    +-++-+   |PP|
  237.    +---+H5|              ||        ||        ||     ++++
  238.    |   +--+              ||        ||        ||      ||
  239.    |                 +---++--------++--------++------++----+
  240.    |                 |                                     |    +---+
  241.    |   +----+        |              HIPPI-SC               +----+ARP|
  242.    +---+ G1 +--------+                                     +----+   |
  243.    |   |    +--------+               Switch                |    +---+
  244.    |   +----+        |                                     |
  245.    |                 +---++--------++--------++------++----+
  246.    |   +--+              ||        ||        ||      ||
  247.    +---+H6|              ||                         ++++
  248.    |   +--+            +-++-+                       |PP|
  249.    |                   |    |                       +-++
  250.    |                   | G2 |                         |
  251.    |                   |    |                      +--+--+
  252.    |                   +--+-+                      | H 7 |
  253.    |                      |                        +-----+
  254.                           |
  255.         -----+------------+-------+-----------+-------------+------
  256.              |                    |           |             |
  257.              |                    |           |             |
  258.           +--+--+              +--+--+     +--+--+       +--+--+
  259.           | H 8 |              | H 9 |     | H10 |       | H11 |
  260.           +-----+              +-----+     +-----+       +-----+
  261.  
  262.    Legend:  ---+---+---+--  =  802 network, Ethernet or FDDI
  263.                         ||  =  Paired HIPPI link
  264.                          H  =  Host computer
  265.                         PP  =  Outboard Protocol Processor
  266.                          G  =  Gateway
  267.                        ARP  =  ARP Agent
  268.  
  269.                     A possible HIPPI configuration
  270.  
  271.    A single HIPPI-SC switch has a "non-blocking" characteristic, which
  272.    means there is always a path available from any Source to any
  273.    Destination.  If the network consists of more than one switch, the
  274.    path from a Source to a Destination may include a HIPPI link between
  275.    switches.  If this link is used by more than one Source/Destination
  276.    pair, a "blocking" network is created: one Source may be blocked from
  277.    access to a Destination because another Source is using the link it
  278.    shares.  Strategies for establishing connections may be more
  279.  
  280.  
  281.  
  282. Renwick & Nicholson                                             [Page 5]
  283.  
  284. RFC 1374                  IP and ARP on HIPPI               October 1992
  285.  
  286.  
  287.    complicated on blocking networks than on non-blocking ones.
  288.  
  289.    This memo ignores blocking issues, assuming that the HIPPI LAN
  290.    consists of one HIPPI-SC switch or, if the network is more complex
  291.    than that, it presents no additional problems that a node must be
  292.    aware of.
  293.  
  294. Protocol
  295.  
  296.    Packet Format
  297.  
  298.    The HIPPI packet format for Internet datagrams shall conform to the
  299.    HIPPI-FP and HIPPI-LE draft standards.  The HIPPI-FP D1_Area shall
  300.    contain the HIPPI-LE header.  The HIPPI-FP D2_Area, when present,
  301.    shall contain one IEEE 802.2 Type 1 LLC Unnumbered Information (UI)
  302.    PDU.  Support of IEEE 802.2 XID, TEST and Type 2 PDUs is not required
  303.    on HIPPI, and Destinations that receive these PDUs may either ignore
  304.    them or respond correctly according to IEEE 802.2 requirements.
  305.  
  306.    The length of a HIPPI packet, including trailing fill, shall be a
  307.    multiple of eight octets as required by HIPPI-LE.
  308.  
  309.    +----------+-----------+---------------------+-----------   ------+
  310.    |          |           |                     | IP . . .     0 - 7 |
  311.    | HIPPI-FP | HIPPI-LE  | IEEE 802.2 LLC/SNAP |              octets|
  312.    |(8 octets)|(24 octets)|     (8 octets)      | ARP . . .     fill |
  313.    +----------+-----------+---------------------+-----------   ------+
  314.  
  315.                         HIPPI Packet Structure
  316.  
  317.  
  318.       HIPPI-FP Header
  319.  
  320.          ULP-id (8 bits) shall contain 4.
  321.  
  322.          D1_Data_Set_Present (1 bit) shall be set.
  323.  
  324.          Start_D2_on_Burst_Boundary (1 bit) shall be zero.
  325.  
  326.          Reserved (11 bits) shall contain zero.
  327.  
  328.          D1_Area_Size (8 bits) should be sent as 3.  Destinations shall
  329.          accept any value that HIPPI-FP defines as legal: from 3 to 127
  330.          (32 bit HIPPI) or 3 to 255 (64 bit HIPPI).
  331.  
  332.          D2_Offset (3 bits) may be any value from 0 to 7.
  333.  
  334.          D2_Size (32 bits) Shall contain the number of octets in the
  335.  
  336.  
  337.  
  338. Renwick & Nicholson                                             [Page 6]
  339.  
  340. RFC 1374                  IP and ARP on HIPPI               October 1992
  341.  
  342.  
  343.          IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present.  It
  344.          shall not exceed 65,288 (decimal).  This value includes the
  345.          IEEE 802.2 LLC/SNAP header and the IP datagram.  It does not
  346.          include trailing fill octets.  (See "MTU," below.)
  347.  
  348.          The first octet of the IEEE 802.2 LLC PDU (SSAP) shall be
  349.          located at offset "n" of the packet, where
  350.  
  351.              n = 8 + (D1_Area_Size*8) + D2_Offset
  352.  
  353.          as specified in HIPPI-FP.
  354.  
  355.       HIPPI-LE Header
  356.  
  357.          FC (3 bits) shall contain zero unless otherwise defined by
  358.          local administration.
  359.  
  360.          Double_Wide (1 bit) shall contain one if the Destination
  361.          associated with the sending Source supports 64 bit HIPPI
  362.          operation.  Otherwise it shall contain zero.
  363.  
  364.          Message_Type (4 bits) contains a code identifying the type of
  365.          HIPPI-LE PDU.  Defined values (binary) are:
  366.  
  367.             0  Data PDU
  368.             1  Address Resolution Request PDU (AR_Request)
  369.             2  Address Resolution Response PDU (AR_Response)
  370.             3  Self Address Resolution Request PDU (AR_S_Request)
  371.             4  Self Address Resolution Response PDU (AR_S_Response)
  372.             5-11 Reserved by the ANSI X3T9.3 committee
  373.             12-15 Locally Assigned
  374.  
  375.          Destination_Switch_Address is a 24-bit field containing the
  376.          Switch Address of the Destination if known, otherwise zero.  If
  377.          the address comprises less than 24 bits, it shall be right
  378.          justified (occupying the least significant bits) in the field.
  379.  
  380.          Destination_Address_Type (4 bits) and Source_Address_Type (4
  381.          bits) contain codes identifying the type of addresses in the
  382.          Destination_Switch_Address and Source_Switch_Address fields
  383.          respectively.  Defined values (binary) are:
  384.  
  385.             0  Unspecified
  386.             1  HIPPI-SC Source Route (24 bits)
  387.             2  HIPPI-SC Address (12 bits)
  388.             3-11 Reserved by the ANSI X3T9.3 committee
  389.             12-15 Locally Assigned
  390.  
  391.  
  392.  
  393.  
  394. Renwick & Nicholson                                             [Page 7]
  395.  
  396. RFC 1374                  IP and ARP on HIPPI               October 1992
  397.  
  398.  
  399.          Source_Switch_Address is a 24-bit field containing the Switch
  400.          Address of the Source.  If the address comprises less than 24
  401.          bits, it shall be right justified (occupying the least
  402.          significant bits) in the field.
  403.  
  404.          Reserved (16 bits) shall contain zero.
  405.  
  406.          Destination_IEEE_Address (48 bits) shall contain the 48 bit
  407.          Universal LAN MAC Address of the Destination if known,
  408.          otherwise zero.
  409.  
  410.          LE_Locally_Administered (16 bits) shall contain zero unless
  411.          otherwise defined by local administration.
  412.  
  413.          Source_IEEE_Address (48 bits) shall contain the 48 bit
  414.          Universal LAN MAC Address of the Source if known, otherwise
  415.          zero.
  416.  
  417.       IEEE 802.2 LLC
  418.  
  419.          The IEEE 802.2 LLC Header shall begin in the first octet of the
  420.          HIPPI-FP D2_Area.
  421.  
  422.          SSAP (8 bits) shall contain 170 (decimal).
  423.  
  424.          DSAP (8 bits) shall contain 170 (decimal).
  425.  
  426.          CTL (8 bits) shall contain 3 (Unnumbered Information).
  427.  
  428.       SNAP
  429.  
  430.          Organization Code (24 bits) shall be zero.
  431.  
  432.          EtherType (16 bits) shall be set as defined in Assigned Numbers
  433.          [8] (IP = 2048, ARP = 2054, RARP = 32,821).
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Renwick & Nicholson                                             [Page 8]
  451.  
  452. RFC 1374                  IP and ARP on HIPPI               October 1992
  453.  
  454.  
  455.       31    28        23  21          15        10     7         2   0
  456.       +-----+---------+-+-+-----------+---------+-----+---------+-----+
  457.     0 |      04       |1|0|       Reserved      |      03       |  0  |
  458.       +---------------+-+-+---------------------+---------------+-----+
  459.     1 |                             (n+8)                             |
  460.       +-----+-+-------+-----------------------------------------------+
  461.     2 |[LA] |W|M_Type |          Destination_Switch_Address           |
  462.       +-----+-+-------+-----------------------------------------------+
  463.     3 | D_A_T | S_A_T |             Source_Switch_Address             |
  464.       +-------+-------+---------------+-------------------------------+
  465.     4 |            Reserved           |  [Destination_IEEE_Address]   |
  466.       +-------------------------------+                               |
  467.     5 |                                                               |
  468.       +-------------------------------+-------------------------------+
  469.     6 |             [LA]              |     [Source_IEEE_Address]     |
  470.       +-------------------------------+                               |
  471.     7 |                                                               |
  472.       +===============+===============+===============+===============+
  473.     8 |       AA      |      AA       |       03      |       00      |
  474.       +---------------+---------------+---------------+---------------+
  475.     9 |       00      |      00       |         [EtherType]           |
  476.       +---------------+---------------+---------------+---------------+
  477.    10 |Message octet 0|Message octet 1|Message octet 2| . . .         |
  478.       +---------------+---------------+---------------+---            |
  479.       |                            .  .  .
  480.                                                                       |
  481.       |        -------+---------------+---------------+---------------+
  482.       |         . . . |  octet (n-2)  |  octet (n-1)  |     FILL      |
  483.       +---------------+---------------+---------------+---------------+
  484.    N-1|      FILL     |     FILL      |     FILL      |     FILL      |
  485.       +---------------+---------------+---------------+---------------+
  486.  
  487.                            HIPPI Packet Format
  488.  
  489.       Words 0-1:  HIPPI-FP Header
  490.       Words 2-7:  D1 Area (HIPPI-LE Header)
  491.       Words 8-9:  D2 Area (IEEE 802.2 LLC/SNAP)
  492.       Words 10-(N-1):  D2 Area (IP or ARP message)
  493.       (n) is the number of octets in the IP or ARP message.
  494.       +====+ denotes the boundary between D1 and D2 areas.
  495.       [LA] fields are zero unless used otherwise locally.
  496.       Abbreviations:  "W"      = Double_Wide field;
  497.                       "M_Type" = Message_Type field;
  498.                       "D_A_T"  = Destination_Address_Type;
  499.                       "S_A_T"  = Source_Address_Type;
  500.       [FILL] octets complete the HIPPI packet to an even
  501.       number of 32 bit words.  The number of fill octets
  502.       is not counted in the data length.
  503.  
  504.  
  505.  
  506. Renwick & Nicholson                                             [Page 9]
  507.  
  508. RFC 1374                  IP and ARP on HIPPI               October 1992
  509.  
  510.  
  511.    IEEE 802.2 Data
  512.  
  513.       The IEEE 802.2 Data shall follow the EtherType field immediately.
  514.       Fill octets shall be used following the Data as necessary to make
  515.       the number of octets in the packet a multiple of 8.  In accordance
  516.       with HIPPI-FP, the amount of this fill is not included in the
  517.       D2_Size value in the HIPPI-FP Header.
  518.  
  519.       The order of the octets in the data stream is from higher numbered
  520.       to lower numbered data signal (left to right) within the HIPPI
  521.       word, as specified in HIPPI-FP Clause 7, "Word and byte formats."
  522.       With the 1600 megabit/second data rate option (64 bit) bits 32
  523.       through 63 are on Cable B, so that the four octets on Cable B come
  524.       logically before those on Cable A.  Within each octet, the most
  525.       significant bit is the highest numbered signal.
  526.  
  527. 48 bit Universal LAN MAC Addresses
  528.  
  529.    IEEE Standard 802.1A specifies the Universal LAN MAC Address.  The
  530.    globally unique part of the 48 bit space is administered by the IEEE.
  531.    Each node on a HIPPI-SC LAN should be assigned a ULA.  Multiple ULAs
  532.    may be used if a node contains more than one IEEE 802.2 LLC protocol
  533.    entity.
  534.  
  535.    The format of the address within its 48 bit HIPPI-LE fields follows
  536.    IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order:
  537.  
  538.    31              23              15               7              0
  539.    +-------------------------------+---------------+---------------+
  540.    |      (not used for ULA)       |ULA octet 0|L|G|  ULA octet 1  |
  541.    +---------------+---------------+---------------+---------------+
  542.    |  ULA octet 2  |  ULA octet 3  |  ULA octet 4  |  ULA octet 5  |
  543.    +---------------+---------------+---------------+---------------+
  544.  
  545.                     Universal LAN MAC Address Format
  546.  
  547.       L (U/L bit) = 1 for Locally administered addresses, 0 for
  548.       Universal.
  549.       G (I/G bit) = 1 for Group addresses, 0 for Individual.
  550.  
  551.    The use of ULAs is optional, but encouraged.  Although ULAs are not
  552.    used by HIPPI-SC switches, they are helpful for HIPPI Switch Address
  553.    resolution, and for distinguishing between multiple logical entities
  554.    that may exist within one node.  They may also be used by gateway
  555.    devices that replace HIPPI hardware headers with the MAC headers of
  556.    other LANs.  Carrying the ULAs in the HIPPI header may simplify these
  557.    devices, and it may also help if HIPPI is used as an interface to
  558.    some future HIPPI based LAN that uses ULAs for addressing.
  559.  
  560.  
  561.  
  562. Renwick & Nicholson                                            [Page 10]
  563.  
  564. RFC 1374                  IP and ARP on HIPPI               October 1992
  565.  
  566.  
  567. Recommended HIPPI-FP Options
  568.  
  569.    HIPPI-FP allows some flexibility in the construction of a HIPPI
  570.    packet, including placement of short bursts, optional fill and offset
  571.    octets between the D1 and D2 areas and fill following the D2 data.
  572.    For efficiency, Sources should limit the use of these options:
  573.  
  574.    1.  Send the short burst as the last burst of the packet rather than
  575.        the first.
  576.  
  577.    2.  Do not place fill octets between the HIPPI-LE header and the
  578.        start of the D2_Area.
  579.  
  580.    3.  Use no more than seven octets after the D2 Data, as needed to
  581.        make the total packet length a multiple of 8 octets.
  582.  
  583. One HIPPI-FP option is forbidden: setting the Start_D2_on_Burst_Boundary
  584. flag to one.  This places no limitation on the formation of packets into
  585. a series of bursts; a Source may segment the packet in any legal manner
  586. according to HIPPI-FP, including forcing the D2_Area to start on a burst
  587. boundary.  The purpose of the Start_D2_on_Burst_Boundary flag is to help
  588. preserve the segmentation of the packet for some device-control
  589. protocols that use the first burst boundary to separate command and data
  590. areas within the packet.  Requiring this flag to be clear means that
  591. when a packet arrives at the Destination its burst boundaries might not
  592. be exactly as the Source sent them.  This may occur if a HIPPI packet
  593. passes over some other medium in the route between HIPPI LANs.
  594.  
  595. Notwithstanding these recommendations, each Destination shall accept any
  596. well-formed HIPPI packet within the definitions in HIPPI-FP.
  597.  
  598. Note that neither HIPPI-FP nor HIPPI-LE limits the number of fill bytes
  599. placed between the end of the IP packet and the end of the HIPPI-PH
  600. packet.  Some source implementations may add fill sufficient to overflow
  601. a destination input buffer.  To avoid interpreting valid packets as
  602. errors, destinations should ignore overflow conditions and verify that
  603. at least the number of bytes indicated by the IP header actually
  604. arrived.
  605.  
  606. I-Field format
  607.  
  608.    The I-field bits, as defined in HIPPI-SC, shall be set as follows:
  609.  
  610.       Locally Administered (bit 31) shall be zero.
  611.  
  612.       Reserved (bits 30, 29) should be zero.  Destinations shall accept
  613.       any value for these bits.
  614.  
  615.  
  616.  
  617.  
  618. Renwick & Nicholson                                            [Page 11]
  619.  
  620. RFC 1374                  IP and ARP on HIPPI               October 1992
  621.  
  622.  
  623.       Double wide (bit 28) shall be set when Source Cable B is connected
  624.       and the Source wants a 64 bit connection.  It shall be zero
  625.       otherwise.
  626.  
  627.       Direction (bit 27) should be sent as zero, however Destinations
  628.       shall accept either zero or one and interpret the Routing Control
  629.       field accordingly, per HIPPI-SC.
  630.  
  631.       Path Selection (bits 26, 25) shall be 00, 01, or 11 (binary) at
  632.       the Source's option.  00 (source route mode) indicates that the
  633.       I-field bits 23-00 contain a 24 bit source route; 01 or 11
  634.       (logical address mode) indicate that bits 23-00 contain 12 bit
  635.       Source and Destination Addresses.  The value 11 is meaningful when
  636.       more than one route exists from a Source to a Destination; it
  637.       allows the switch to choose the route.  Use of 01 forces the
  638.       switch always to use the same route for the same
  639.       Source/Destination pair.
  640.  
  641.       Camp-on (bit 24) may be 1 or 0; however, a Source shall not make
  642.       consecutive requests without Camp-on to the same Destination while
  643.       the requests are being rejected.  The purpose of this restriction
  644.       is to prevent a node from circumventing the fair share arbitration
  645.       mechanism of the switch by repeating requests at a very high rate.
  646.  
  647.       If logical address mode is used:
  648.  
  649.          Source Address (bits 23-12) is not used.
  650.  
  651.          Destination Address (bits 11-0) shall contain the Switch
  652.          Address of the Destination.
  653.  
  654.       If source route mode is used:
  655.  
  656.          Routing control (bits 23-00) shall contain the route to the
  657.          Destination.
  658.  
  659.       Note:  the outcome of Switch Address Resolution (see "Address
  660.       Resolution" below) determines whether to use logical address mode
  661.       or source route mode.  If source route mode is used with multiple
  662.       interconnected switches, different sources may use different
  663.       addresses to reach the same destination, and multicast-based
  664.       address resolution may not be possible because a target node may
  665.       not know the route to itself from a given remote source.
  666.       Regardless of this difficulty, it may be possible to use source
  667.       route mode if the network consists of a single switch, or if
  668.       address resolution is supported by an ARP agent that is able to
  669.       deliver correct routes to each node.  The nodes themselves need
  670.       not be concerned with these problems if they use the addressing
  671.  
  672.  
  673.  
  674. Renwick & Nicholson                                            [Page 12]
  675.  
  676. RFC 1374                  IP and ARP on HIPPI               October 1992
  677.  
  678.  
  679.       mode suggested by the value of the Source_Address_Type field in a
  680.       HIPPI-LE Address Resolution Response packet.
  681.  
  682. Rules For Connections
  683.  
  684.    The following rules for connection management by Source and
  685.    Destination are intended to insure frequent, fair share access to
  686.    Destinations for which multiple Sources are contending.  If possible,
  687.    nodes should transfer data at full HIPPI speeds and hold connections
  688.    no longer than necessary.
  689.  
  690.    A source may hold a connection for as long as it takes to send 68
  691.    HIPPI bursts at what ever speed the two connected nodes can achieve
  692.    together.  The number of packets sent in one connection is not
  693.    limited, except that the number of bursts over all the packets should
  694.    not exceed 68.  This is not a recommendation to send as many packets
  695.    as possible per connection; one packet per connection is acceptable.
  696.    The purpose of this limit is to give each Source an fair share of a
  697.    common Destination's bandwidth.  Without a limit, if there is a
  698.    Destination that is constantly in demand by multiple Sources, the
  699.    Source that sends the most data per connection wins the greatest
  700.    share of bandwidth.
  701.  
  702.    The limit of 68 bursts is not absolute.  An implementation may check
  703.    the burst count after transmission of a packet and end the connection
  704.    if it is greater than or equal to some threshold.  If this is done,
  705.    the threshold should be less than 68 depending on the typical packet
  706.    size, to ensure that the 68 burst limit is not normally exceeded.
  707.    For instance, a Source sending 64K packets would send two per
  708.    connection (130 bursts) if it checked for 68 at the end of each
  709.    packet.  In this situation the Source is required to check for a
  710.    value small enough that it will not send a second packet in the same
  711.    connection.
  712.  
  713.    Destinations shall accept all packets that arrive during a
  714.    connection, and may discard those that exceed its buffering capacity.
  715.    A Destination shall not abort a connection (deassert CONNECT) simply
  716.    because too many bursts were received; however a Destination may
  717.    abort a connection whose duration has exceeded a time period of the
  718.    Destination's choosing, as long as the Source is allowed ample time
  719.    to transmit its quota of bursts.
  720.  
  721.    The rules admonish the node to do certain things as fast as it can,
  722.    however there is no absolute measure of compliance.  Nodes that
  723.    cannot transfer data at full HIPPI speeds can still interoperate but
  724.    the faster the implementation, the better the performance of the
  725.    network will be.
  726.  
  727.  
  728.  
  729.  
  730. Renwick & Nicholson                                            [Page 13]
  731.  
  732. RFC 1374                  IP and ARP on HIPPI               October 1992
  733.  
  734.  
  735.    Assuming that bursts flow at the maximum rate, the most important
  736.    factor in network throughput is the connection switching time,
  737.    measured from the deassertion of REQUEST by the Source at the end of
  738.    one connection to its first assertion of BURST after the
  739.    establishment of the new connection.  Implementations should keep
  740.    this time as short as possible.  For a guideline, assuming parallel
  741.    HIPPI and a single HIPPI-SC switch, ten microseconds permits nearly
  742.    full HIPPI throughput with full-sized packets, and at 60 microseconds
  743.    the available throughput is reduced by about 10%.  (See
  744.    "Performance," below.)
  745.  
  746.    All HIPPI electrical signaling shall comply with HIPPI-PH.  In every
  747.    case, the following rules go beyond what HIPPI-PH requires.
  748.  
  749.    Rules for the Source
  750.  
  751.       1.  Do not assert REQUEST until a packet is ready to send.
  752.  
  753.       2.  Transmit bursts as quickly as READYs permit.  Except for the
  754.           required HIPPI Source Wait states, there should be no delay in
  755.           the assertion of BURST whenever the Source's READY counter is
  756.           nonzero.
  757.  
  758.       3.  Make a best effort to ensure that connection durations do not
  759.           exceed 68 bursts.
  760.  
  761.       4.  Deassert REQUEST immediately when no packet is available for
  762.           immediate transmission or the last packet of the connection
  763.           has been sent.
  764.  
  765.    Rules for the Destination
  766.  
  767.       1.  Reject all connections if unable to receive packets.  This
  768.           frees the requesting Source to connect to other Destinations
  769.           with a minimum of delay.  Inability to receive packets is not
  770.           a transient condition, but is the state of the Destination
  771.           when its network interface is not initialized.
  772.  
  773.       2.  A HIPPI node should be prepared to efficiently accept
  774.           connections and process incoming data packets.  While this may
  775.           be best achieved by not asserting connect unless 68 bursts
  776.           worth of buffers is available, it may be possible to meet this
  777.           requirement with fewer buffers.  This may be due to a priori
  778.           agreement between nodes on packet sizes, the speed of the
  779.           interface to move buffers, or other implementation dependent
  780.           considerations.
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Renwick & Nicholson                                            [Page 14]
  787.  
  788. RFC 1374                  IP and ARP on HIPPI               October 1992
  789.  
  790.  
  791.       3.  Accept a connection immediately when buffers are available.
  792.           The Destination should never delay the acceptance of a
  793.           connection unnecessarily.
  794.  
  795.       4.  Once initialized, a Destination may reject connection requests
  796.           only for one of the following reasons:
  797.  
  798.           1.  The I-field was received with incorrect parity.
  799.  
  800.           2.  The I-field contents are invalid, e.g. the "W" bit set
  801.               when the Destination does not support the 1600 megabit
  802.               data rate option, the "Locally Administered" bit is set,
  803.               the Source is not permitted to send to this Destination,
  804.               etc.
  805.  
  806.           Transient conditions within the Destination, such as temporary
  807.           buffer shortages, must never cause rejected connections.
  808.  
  809.       5.  Ignore aborted connection sequences.  Sources may time out and
  810.           abandon attempts to connect; therefore aborted connection
  811.           sequences are normal events.
  812.  
  813.    MTU
  814.  
  815.       Maximum Transmission Unit (MTU) is defined as the length of the IP
  816.       packet, including IP header, but not including any overhead below
  817.       IP.  Conventional LANs have MTU sizes determined by physical layer
  818.       specification.  MTUs may be required simply because the chosen
  819.       medium won't work with larger packets, or they may serve to limit
  820.       the amount of time a node must wait for an opportunity to send a
  821.       packet.
  822.  
  823.       HIPPI has no inherent limit on packet size.  The HIPPI-FP header
  824.       contains a 32 bit D2_Size field that, while it may limit packets
  825.       to about 4 gigabytes, imposes no practical limit for networking
  826.       purposes.  Even so, a HIPPI-SC switch used as a LAN needs an MTU
  827.       so that Destination buffer sizes can be determined.
  828.  
  829.       The MTU for HIPPI-SC LANs is 65280 (decimal) octets.
  830.  
  831.       This value was selected because it allows the IP packet to fit in
  832.       one 64K octet buffer with up to 256 octets of overhead.  The
  833.       overhead is 40 octets at the present time; there are 216 octets of
  834.       room for expansion.
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Renwick & Nicholson                                            [Page 15]
  843.  
  844. RFC 1374                  IP and ARP on HIPPI               October 1992
  845.  
  846.  
  847.          HIPPI-FP Header                  8 octets
  848.          HIPPI-LE Header                 24 octets
  849.          IEEE 802.2 LLC/SNAP Headers      8 octets
  850.          Maximum IP packet size (MTU) 65280 octets
  851.                                       ------------
  852.                            Total      65320 octets (64K - 216)
  853.  
  854.  
  855. Camp-on
  856.  
  857.    When several Sources contend for a single Destination, the Camp-on
  858.    feature allows the HIPPI-SC switch to arbitrate and ensure that all
  859.    Sources have fair access.  (HIPPI-SC does not specify the method of
  860.    arbitration.)  Without Camp-on, the contending Sources would simply
  861.    have to retry the connection repeatedly until it was accepted, and
  862.    the fastest Source would usually win.  To guarantee fair share
  863.    arbitration, Sources are prohibited from making repeated requests to
  864.    the same Destination without Camp-on in such a way as to defeat the
  865.    arbitration.
  866.  
  867.    There is another important reason to use Camp-on: when a connection
  868.    without Camp-on is rejected, the Source cannot determine whether the
  869.    rejection came from the requested Destination or from the switch.
  870.    The Source also cannot tell the reason for the rejection, which could
  871.    be either that the Destination was off line or not cabled, or the I-
  872.    field was erroneous or had incorrect parity.  Sources should not
  873.    treat a rejection of a request without Camp-on as an error.  Camp-on
  874.    prevents rejection due to the temporary busy case; with one
  875.    exception, rejection of a Camp-on request indicates an error
  876.    condition, and an error event can be recorded.  The exception occurs
  877.    when a 64 bit connection is attempted to a Destination that does not
  878.    have Cable B connected, resulting in a reject.  This case is covered
  879.    in "Channel Data Rate Discovery," below.
  880.  
  881. Address Resolution
  882.  
  883.    The Internet Address Resolution Protocol (ARP) is defined in RFC 826
  884.    [9].  Ethernet, FDDI and 802 networks use ARP to discover another
  885.    host's ULA knowing the Internet address.  Reverse ARP [10] is used to
  886.    discover the Internet address, knowing the ULA.  ARP can be used in
  887.    the conventional way on HIPPI-SC LANs equipped with a multicast
  888.    capability or third party ARP agent.
  889.  
  890.    HIPPI-LE defines similar lower-level address resolution between ULAs
  891.    and switches.  HIPPI-LE adds a self-address resolution mechanism not
  892.    defined for Internet ARP, which allows a node to discover its own
  893.    switch address dynamically.
  894.  
  895.  
  896.  
  897.  
  898. Renwick & Nicholson                                            [Page 16]
  899.  
  900. RFC 1374                  IP and ARP on HIPPI               October 1992
  901.  
  902.  
  903.    ARP for the purpose of discovering ULAs is not necessary for the
  904.    operation of a HIPPI-SC LAN, but it serves as the vehicle for
  905.    discovery of HIPPI-SC Switch Addresses, without which the HIPPI-SC
  906.    LAN cannot function.  In other words, at the same time a node is
  907.    using ARP to map another node's IP address to its ULA, it is also
  908.    mapping the ULA to the 12 bit HIPPI Switch Address, from which it
  909.    will construct the I-field value for sending messages to that node.
  910.    This additional level of hardware addressing uses the address fields
  911.    in the HIPPI-LE header.
  912.  
  913.    In the following discussion, the terms "requester" and "target" are
  914.    used to identify the node requesting address resolution and the node
  915.    whose address it wishes to discover, respectively.  In third party
  916.    ARP (see "ARP Implementation Methods," below) the source of a reply
  917.    is an ARP agent node, not the target node.
  918.  
  919.    ARP and RARP Message Format
  920.  
  921.       The HIPPI ARP/RARP protocol uses the same packet format as ARP for
  922.       Ethernet.  ARP packets shall be transmitted with a hardware type
  923.       code of 1 (as for Ethernet).  Furthermore, ARP packets shall be
  924.       accepted if received with hardware type codes of either 1 or 6
  925.       (IEEE 802 networks).
  926.  
  927.       ar$hrd (16 bits) shall contain 1.
  928.  
  929.       ar$pro (16 bits) shall contain the IP protocol code 2048
  930.       (decimal).
  931.  
  932.       ar$hln (8 bits) shall contain 6.
  933.  
  934.       ar$pln (8 bits) shall contain 4.
  935.  
  936.       ar$op  (16 bits) shall contain 1 for requests, 2 for responses.
  937.  
  938.       ar$sha (48 bits) in requests shall contain the requester's ULA.
  939.       In replies it shall contain the target node's ULA.
  940.  
  941.       ar$spa (32 bits) in requests shall contain the requester's IP
  942.       address if known, otherwise zero.  In replies it shall contain the
  943.       target node's IP address.
  944.  
  945.       ar$tha (48 bits) in requests shall contain the target's ULA if
  946.       known, otherwise zero.  In replies it shall contain the
  947.       requester's ULA.
  948.  
  949.       ar$tpa (32 bits) in requests shall contain the target's IP address
  950.       if known, otherwise zero.  In replies it shall contain the
  951.  
  952.  
  953.  
  954. Renwick & Nicholson                                            [Page 17]
  955.  
  956. RFC 1374                  IP and ARP on HIPPI               October 1992
  957.  
  958.  
  959.       requester's IP address.
  960.  
  961.       The format of the six octets of the ULA shall be the same as
  962.       required in the HIPPI-LE header (see "48 bit Universal LAN MAC
  963.       Addresses" above), except for the alignment of the Source ULA with
  964.       respect to the 32 bit HIPPI word, which is different between ARP
  965.       and HIPPI-LE.  No bit reversal is necessary as is required with
  966.       FDDI [11].
  967.  
  968.       31    28        23  21          15        10     7         2   0
  969.       +-----+---------+-+-+-----------+---------+-----+---------+-----+
  970.     0 |      04       |1|0|         000         |      03       |  0  |
  971.       +---------------+-+-+---------------------+---------------+-----+
  972.     1 |                              36                               |
  973.       +-----+-+-------+-----------------------+-----------------------+
  974.     2 |[LA] |W|   1   |          000          |   Target Switch Addr  |
  975.       +-----+-+-------+-----------------------+-----------------------+
  976.     3 |   2   |   2   |          000          |Requester's Switch Addr|
  977.       +---------------+---------------+-------+-----------------------+
  978.     4 |             00 00             |                               |
  979.       +-------------------------------+                               |
  980.     5 |                           Target ULA                          |
  981.       +-------------------------------+-------------------------------+
  982.     6 |             [LA]              |                               |
  983.       +-------------------------------+                               |
  984.     7 |                        Requester's ULA                        |
  985.       +===============+===============+===============+===============+
  986.     8 |       AA      |      AA       |       03      |       00      |
  987.       +---------------+---------------+---------------+---------------+
  988.     9 |       00      |      00       |        EtherType (2054)       |
  989.       +---------------+---------------+-------------------------------+
  990.    10 |            hrd (1)            |           pro (2048)          |
  991.       +---------------+---------------+-------------------------------+
  992.    11 |    hln (6)    |    pln (4)    |            op (1)             |
  993.       +---------------+---------------+-------------------------------+
  994.    12 |                 Requester's ULA octets 0 - 3                  |
  995.       +-------------------------------+-------------------------------+
  996.    13 | Requester's ULA octets 4 - 5  | Requester's IP Address upper  |
  997.       +-------------------------------+-------------------------------+
  998.    14 | Requester's IP Address lower  |    Target ULA octets 0 - 1    |
  999.       +-------------------------------+-------------------------------+
  1000.    15 |                   Target ULA octets 2 - 5                     |
  1001.       +---------------------------------------------------------------+
  1002.    16 |                       Target IP Address                       |
  1003.       +---------------------------------------------------------------+
  1004.  
  1005.                 HIPPI ARP/RARP Request (logical address mode)
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Renwick & Nicholson                                            [Page 18]
  1011.  
  1012. RFC 1374                  IP and ARP on HIPPI               October 1992
  1013.  
  1014.  
  1015.    All ARP requests shall be sent with the I-field bit 28 set to zero,
  1016.    i.e. requesting a 32 bit connection.
  1017.  
  1018.    Unless another convention is locally defined for ARP requests, the
  1019.    I-field Path Selection bits may be set to binary 01 or 11 (logical
  1020.    address mode), and Destination Address field set to the HIPPI-SC
  1021.    address reserved for traffic conventionally directed to the IEEE
  1022.    802.1[12] broadcast address (which HIPPI-SC defines as FE0, hex).
  1023.  
  1024.    Reply packets shall be sent with I-field Path Selection and Routing
  1025.    Control fields set according to the Source_Address_Type and
  1026.    Source_Switch_Address fields in the request.
  1027.  
  1028.    In the HIPPI-LE header of ARP/RARP requests and replies the following
  1029.    fields shall be set:
  1030.  
  1031.    Double-Wide should be 1 if the HIPPI Destination at the sending node
  1032.    can accept 64 bit HIPPI connections.
  1033.  
  1034.    Message_Type shall contain an address resolution type code as defined
  1035.    in HIPPI-LE.  It shall be set appropriately to the value of the ARP
  1036.    operation code (ar$op) in piggybacked ARP messages:
  1037.  
  1038.          +-----------------------+-----------------------+
  1039.          |       ARP ar$op       | HIPPI-LE Message_Type |
  1040.          +=======================+=======================+
  1041.          |ARP Request (1)        |AR_Request (1)         |
  1042.          |ARP Reply (2)          |AR_Response (2)        |
  1043.          +-----------------------+-----------------------+
  1044.          |Reverse ARP Request (3)|AR_Request (1)         |
  1045.          |Reverse ARP Reply (4)  |AR_Response (2)        |
  1046.          +-----------------------+-----------------------+
  1047.  
  1048.    There is no ARP message corresponding to HIPPI-LE self address
  1049.    discovery; these packets are sent without ULP data.
  1050.  
  1051.    Destination_Switch_Address in requests shall be the Switch Address of
  1052.    the target node if known, otherwise zero.  In replies it shall be the
  1053.    requesting node's Switch Address
  1054.  
  1055.    Destination_Address_Type shall be 1 if the Destination_Switch_Address
  1056.    is a source route, 2 if it is a 12 bit address.
  1057.  
  1058.    Source_Address_Type shall be 1 if the Source_Switch_Address is a
  1059.    source route, 2 if it is a 12 bit address.
  1060.  
  1061.    Source_Switch_Address in requests shall be the Switch Address of the
  1062.    requesting node if known, otherwise zero.  In replies it shall be the
  1063.  
  1064.  
  1065.  
  1066. Renwick & Nicholson                                            [Page 19]
  1067.  
  1068. RFC 1374                  IP and ARP on HIPPI               October 1992
  1069.  
  1070.  
  1071.    target node's Switch Address.
  1072.  
  1073.    Destination_IEEE_Address shall be the same as the ar$tha field in the
  1074.    ARP message.
  1075.  
  1076.    Source_IEEE_Address shall be the same as the ar$sha field in the ARP
  1077.    message.
  1078.  
  1079.       31    28        23  21          15        10     7         2   0
  1080.       +-----+---------+-+-+-----------+---------+-----+---------+-----+
  1081.     0 |      04       |1|0|         000         |      03       |  0  |
  1082.       +---------------+-+-+---------------------+---------------+-----+
  1083.     1 |                              36                               |
  1084.       +-----+-+-------+-----------------------+-----------------------+
  1085.     2 |[LA] |W|   2   |          000          |Requester's Switch Addr|
  1086.       +-----+-+-------+-----------------------+-----------------------+
  1087.     3 |   2   |   2   |          000          | Target Switch Address |
  1088.       +---------------+---------------+-------+-----------------------+
  1089.     4 |             00 00             |                               |
  1090.       +-------------------------------+                               |
  1091.     5 |                        Requester's ULA                        |
  1092.       +-------------------------------+-------------------------------+
  1093.     6 |             [LA]              |                               |
  1094.       +-------------------------------+                               |
  1095.     7 |                           Target ULA                          |
  1096.       +===============+===============+===============+===============+
  1097.     8 |       AA      |      AA       |       03      |       00      |
  1098.       +---------------+---------------+---------------+---------------+
  1099.     9 |       00      |      00       |        EtherType (2054)       |
  1100.       +---------------+---------------+-------------------------------+
  1101.    10 |            hrd (1)            |           pro (2048)          |
  1102.       +---------------+---------------+-------------------------------+
  1103.    11 |    hln (6)    |    pln (4)    |            op (2)             |
  1104.       +---------------+---------------+-------------------------------+
  1105.    12 |                    Target ULA octets 0 - 3                    |
  1106.       +-------------------------------+-------------------------------+
  1107.    13 |    Target ULA octets 4 - 5    |    Target IP Address upper    |
  1108.       +-------------------------------+-------------------------------+
  1109.    14 |    Target IP Address lower    | Requester's ULA octets 0 - 1  |
  1110.       +-------------------------------+-------------------------------+
  1111.    15 |                 Requester's ULA octets 2 - 5                  |
  1112.       +---------------------------------------------------------------+
  1113.    16 |                    Requester's IP Address                     |
  1114.       +---------------------------------------------------------------+
  1115.  
  1116.                      HIPPI ARP/RARP Reply (logical address mode)
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Renwick & Nicholson                                            [Page 20]
  1123.  
  1124. RFC 1374                  IP and ARP on HIPPI               October 1992
  1125.  
  1126.  
  1127. ARP procedure
  1128.  
  1129.    The combined HIPPI-LE/ARP packet contains six addresses, three each
  1130.    for the requester and the target:
  1131.  
  1132.       Requester's IP Address          (ARP)
  1133.       Requester's ULA                 (ARP and HIPPI-LE)
  1134.       Requester's Switch Address      (HIPPI-LE)
  1135.  
  1136.       Target's IP Address             (ARP)
  1137.       Target's ULA                    (ARP and HIPPI-LE)
  1138.       Target's Switch Address         (HIPPI-LE)
  1139.  
  1140.    Internet ARP concerns the IP Address and ULA; HIPPI-LE address
  1141.    resolution concerns the ULA and Switch Address.  Thus the ULA appears
  1142.    in both parts of the packet.
  1143.  
  1144.    Successful ARP results in tables in each node that map remote nodes'
  1145.    IP addresses to ULAs and ULAs to Switch Addresses, so that when an
  1146.    application requests a connection to a remote node by its IP address,
  1147.    both the remote ULA and Switch Address can be determined, a correct
  1148.    HIPPI-LE header can be built, and a connection to the node can be
  1149.    established using the correct Switch Address in the I-field.  Any
  1150.    recipient of an ARP request or reply may use information in the
  1151.    packet to augment its tables, even if it is neither the target node
  1152.    nor the requester.
  1153.  
  1154.    Note that the use of ULAs with HIPPI is not required.  In both the
  1155.    HIPPI-LE header and the Internet ARP message, the fields that contain
  1156.    ULAs should be set to zero when the ULA is not known.  Address
  1157.    resolution consists of two separate protocols, HIPPI-LE address
  1158.    resolution and Internet ARP, neither of which can function
  1159.    independently without ULAs.  However HIPPI Switch Address resolution
  1160.    can work without ULAs if the two protocols are piggybacked and
  1161.    treated as one operation in which Internet addresses are mapped
  1162.    directly to switch addresses.  With the exception of the optional
  1163.    self-address resolution request, which has no analogous Internet
  1164.    protocol, HIPPI-LE address resolution and Internet ARP messages
  1165.    should be sent together as a single HIPPI packet.
  1166.  
  1167.    If ULAs are used, the HIPPI-LE address resolution request can be sent
  1168.    without a piggybacked 802.2 LLC PDU, so it is possible to map ULAs to
  1169.    HIPPI Switch Addresses without using ARP.  Nodes shall accept both
  1170.    piggybacked and non-piggybacked forms of HIPPI-LE address resolution
  1171.    messages.
  1172.  
  1173.    The recipient of an address resolution request, having first updated
  1174.    its address mapping tables with any new information it can find in
  1175.  
  1176.  
  1177.  
  1178. Renwick & Nicholson                                            [Page 21]
  1179.  
  1180. RFC 1374                  IP and ARP on HIPPI               October 1992
  1181.  
  1182.  
  1183.    the request, checks to see if it is the target node.  If it is, it
  1184.    generates a reply by filling in the unknown target address fields
  1185.    according to the HIPPI-LE message type and the ARP operation code,
  1186.    and swapping the four pairs of source/target address fields.  Then it
  1187.    connects to the requesting node with the Source Switch Address from
  1188.    the request, and sends the reply packet.
  1189.  
  1190.    A node is the target of an address resolution request if the request
  1191.    contains one of the following:
  1192.  
  1193.    1.  the node's ULA in the Destination_IEEE_Address field of a HIPPI-
  1194.        LE AR_Request message
  1195.  
  1196.    2.  the node's IP address in the target protocol address field
  1197.        (ar$tpa) of a piggybacked Internet ARP message
  1198.  
  1199.    If two target fields are known but are not mapped together in the
  1200.    recipient's address mapping tables, it may do one of three things:
  1201.  
  1202.    1.  treat the request as having two targets, and send correct replies
  1203.        for both to the requester.
  1204.  
  1205.    2.  assume its own tables are invalid and ignore the request.
  1206.  
  1207.    3.  assume one of the "known" target fields is correct and respond as
  1208.        if the other had been unknown.
  1209.  
  1210.    The best choice depends on which fields conflict and the nature of
  1211.    the implementation.  Choice 3 is probably best for ordinary nodes,
  1212.    but third party ARP agents may have reason to use one of the other
  1213.    two.  Future experience may shed light on this.
  1214.  
  1215. ARP Implementation Methods
  1216.  
  1217.    The requirements for nodes to handle address resolution messages
  1218.    depend on the means by which address resolution is implemented on the
  1219.    LAN.
  1220.  
  1221.    In conventional networks ARP is a distributed function. ARP requests
  1222.    are broadcast; each host may update its address mappings with any ARP
  1223.    request or reply it sees, and responds to ARP requests that contain
  1224.    its own address in the target protocol address field.  HIPPI-SC
  1225.    switches are not required to provide multicast service, although some
  1226.    do.  Even if the switches do not multicast, one or more nodes can act
  1227.    as multicast servers, receiving packets sent to the HIPPI-SC
  1228.    broadcast address and repeating them to each other node in turn.
  1229.    Either way, if multicast exists on a HIPPI-SC LAN, ARP can be a
  1230.    distributed function.  In this situation each node is required to
  1231.  
  1232.  
  1233.  
  1234. Renwick & Nicholson                                            [Page 22]
  1235.  
  1236. RFC 1374                  IP and ARP on HIPPI               October 1992
  1237.  
  1238.  
  1239.    respond correctly to address resolution requests for which it is the
  1240.    target.
  1241.  
  1242.    Third party ARP is a second method that does not depend on multicast.
  1243.    The switches can map the HIPPI ARP multicast address to a node that
  1244.    acts as an ARP agent, replying to ARP requests on behalf of the real
  1245.    target nodes.  Ordinary nodes never receive ARP requests or generate
  1246.    replies and never have the opportunity to update mapping tables based
  1247.    on ARP requests from other nodes, as usually happens on conventional
  1248.    networks.  Each node must request any address information it needs,
  1249.    but never has to process ARP information it doesn't need.  Under
  1250.    third party ARP a node should not receive address resolution
  1251.    requests, and each node that is not an ARP agent should ignore those
  1252.    that it does receive.
  1253.  
  1254.    As a third possibility, one can omit the implementation of ARP
  1255.    entirely, choosing instead to build address mapping tables in each
  1256.    node from information available to a network administrator.  Such a
  1257.    technique is implementation dependent and outside the scope of this
  1258.    memo.  It may be helpful in prototype networks without multicast
  1259.    where no ARP agent is yet implemented.  In this case, nodes are not
  1260.    required to respond to address resolution requests, but must accept
  1261.    any they may receive.
  1262.  
  1263. ARP Example
  1264.  
  1265.    Assume a HIPPI-SC switch is installed with two nodes, X and Y,
  1266.    connected.  Each node has a unique Switch Address.  Both nodes have
  1267.    access to the host data base (e.g. /etc/hosts) in which the network
  1268.    administrator has configured the network and given the two nodes IP
  1269.    addresses.  There is an ARP agent connected to a switch port that is
  1270.    mapped to the address FE0 (hex).  The ARP agent contains no mappings
  1271.    of any IP, IEEE or Switch addresses.  Both nodes know their own ULAs
  1272.    and Switch Addresses.  They want to talk to each other; each knows
  1273.    the other's IP address (from the host data base) but neither knows
  1274.    the other's ULA or Switch Address.  Node X starts:
  1275.  
  1276.    1.  Node X connects to FE0 and sends a piggyback ARP Request
  1277.        requesting addresses for Y:
  1278.  
  1279.            HIPPI-LE Message_Type is 1, AR_Request
  1280.            HIPPI-LE Destination_Switch_Address = 0
  1281.            HIPPI-LE Source_Switch_Address = X's Switch Address
  1282.            HIPPI-LE Destination_IEEE_Address = 0
  1283.            HIPPI-LE Source_IEEE_Address = X's ULA
  1284.            ARP ar$op = 1 (request)
  1285.            ARP ar$sha = X's ULA
  1286.            ARP ar$spa = X's IP Address
  1287.  
  1288.  
  1289.  
  1290. Renwick & Nicholson                                            [Page 23]
  1291.  
  1292. RFC 1374                  IP and ARP on HIPPI               October 1992
  1293.  
  1294.  
  1295.            ARP ar$tha = 0
  1296.            ARP ar$tpa = Y's IP Address
  1297.  
  1298.    2.  The ARP agent receives the ARP request and adds an entry for X to
  1299.        its address mapping table.  It does not know about Y, so it does
  1300.        not generate a reply.
  1301.  
  1302.    3.  Node X waits for a reply.  It may set a timer to retransmit the
  1303.        request periodically, but its requests will be ignored until node
  1304.        Y sends an ARP request.
  1305.  
  1306.    4.  Node Y connects to FE0 and sends an ARP request requesting
  1307.        addresses for X:
  1308.  
  1309.            HIPPI-LE Message_Type is 1, AR_Request
  1310.            HIPPI-LE Destination_Switch_Address = 0
  1311.            HIPPI-LE Source_Switch_Address = Y's Switch Address
  1312.            HIPPI-LE Destination_IEEE_Address = 0
  1313.            HIPPI-LE Source_IEEE_Address = Y's ULA
  1314.            ARP ar$op = 1 (request)
  1315.            ARP ar$sha = Y's ULA
  1316.            ARP ar$spa = Y's IP Address
  1317.            ARP ar$tha = 0
  1318.            ARP ar$tpa = X's IP Address
  1319.  
  1320.    5.  The ARP agent receives Y's request and adds an entry for Y to its
  1321.        address mapping table.  It knows about the target node, X, so it
  1322.        connects to Y (using the Source_Switch_Address given in the
  1323.        request) and sends an ARP Reply:
  1324.  
  1325.            HIPPI-LE Message_Type is 2, AR_Reply
  1326.            HIPPI-LE Destination_Switch_Address = Y's Switch Address
  1327.            HIPPI-LE Source_Switch_Address = X's Switch Address
  1328.            HIPPI-LE Destination_IEEE_Address = Y's ULA
  1329.            HIPPI-LE Source_IEEE_Address = X's ULA
  1330.            ARP ar$op = 2 (reply)
  1331.            ARP ar$sha = X's ULA
  1332.            ARP ar$spa = X's IP Address
  1333.            ARP ar$tha = Y's ULA
  1334.            ARP ar$tpa = Y's IP Address
  1335.  
  1336.    6.  Node Y receives the ARP reply and builds its address mapping
  1337.        table entry for Node X.
  1338.  
  1339.    7.  Node Y connects to node X and transmits an IP packet with the
  1340.        following information in the HIPPI-LE header:
  1341.  
  1342.            HIPPI-LE Message_Type is 0, AR_Data
  1343.  
  1344.  
  1345.  
  1346. Renwick & Nicholson                                            [Page 24]
  1347.  
  1348. RFC 1374                  IP and ARP on HIPPI               October 1992
  1349.  
  1350.  
  1351.            HIPPI-LE Destination_Switch_Address = X's Switch Address
  1352.            HIPPI-LE Source_Switch_Address = Y's Switch Address
  1353.            HIPPI-LE Destination_IEEE_Address = X's ULA
  1354.            HIPPI-LE Source_IEEE_Address = Y's ULA
  1355.  
  1356.    8.  Node X receives the IP packet.  Since the ARP agent now knows
  1357.        about node Y, node X can retransmit its ARP request (repeating
  1358.        step 1) and receive an ARP reply:
  1359.  
  1360.            HIPPI-LE Message_Type is 2, AR_Reply
  1361.            HIPPI-LE Destination_Switch_Address = X's Switch Address
  1362.            HIPPI-LE Source_Switch_Address = Y's Switch Address
  1363.            HIPPI-LE Destination_IEEE_Address = X's ULA
  1364.            HIPPI-LE Source_IEEE_Address = Y's ULA
  1365.            ARP ar$op = 2 (reply)
  1366.            ARP ar$sha = Y's ULA
  1367.            ARP ar$spa = Y's IP Address
  1368.            ARP ar$tha = X's ULA
  1369.            ARP ar$tpa = X's IP Address
  1370.  
  1371.    Address resolution is now complete for both nodes.
  1372.  
  1373.    If there had been a multicast facility instead of the ARP agent in
  1374.    the configuration, the target nodes themselves would have received
  1375.    the requests and responded to them in the same way the ARP agent did.
  1376.  
  1377. Discovery of One's Own Switch Address
  1378.  
  1379.    The ARP example above assumed that each node had prior knowledge of
  1380.    its own switch address.  This may be manually configured, by means
  1381.    that are outside the scope of this memo, when each node is connected
  1382.    to the switch.  If a multicast capability exists, the node may
  1383.    discover its own address automatically when it starts up, using a
  1384.    protocol defined in HIPPI-LE.
  1385.  
  1386.    In the self-address discovery protocol, a node connects to a
  1387.    multicast address and sends a HIPPI-LE message containing its own
  1388.    ULA.  It receives a multicast copy of its own message, and learns its
  1389.    own switch address from the destination address field of the received
  1390.    I-field.
  1391.  
  1392.    HIPPI-LE self address resolution uses the same HIPPI-LE message
  1393.    format described in "ARP and RARP Message Format," above, with the
  1394.    AR_S_Request and AR_S_Response message type codes and no piggybacked
  1395.    ULP data.  The HIPPI-LE header contents for the request are:
  1396.  
  1397.        Message_Type is 3, AR_S_Request
  1398.        Destination_Address_Type = 0 (undefined)
  1399.  
  1400.  
  1401.  
  1402. Renwick & Nicholson                                            [Page 25]
  1403.  
  1404. RFC 1374                  IP and ARP on HIPPI               October 1992
  1405.  
  1406.  
  1407.        Destination_Switch_Address = 0 (unknown)
  1408.        Source_Address_Type = 0 (undefined)
  1409.        Source_Switch_Address = 0 (unknown)
  1410.        Destination_IEEE_Address = my ULA
  1411.        Source_IEEE_Address = my ULA
  1412.  
  1413.    There is no D2 data; the packet contains only the HIPPI-FP header and
  1414.    D1_Area containing the HIPPI-LE header.
  1415.  
  1416.    The node that wants to discover its address connects to the multicast
  1417.    address for this purpose (hex FE0 in HIPPI-SC) and transmits the
  1418.    request packet.  What happens next depends on the particular network:
  1419.  
  1420.    With multicast:
  1421.  
  1422.       The node receives its own request and can learn its own switch
  1423.       address from the I-field it receives.  This is the only time a
  1424.       node should use an address from a received I-field.
  1425.  
  1426.    With an ARP agent:
  1427.  
  1428.       The node may receive an AR_S_Response message with its own ULA in
  1429.       the Destination_IEEE_Address field and its own switch address in
  1430.       the Destination_Switch_Address field.  This address may be
  1431.       different from the address contained in the I-field, and should be
  1432.       used instead.
  1433.  
  1434.    The ARP agent response alternative requires that the agent have prior
  1435.    knowledge of the node's location and ULA through some process not
  1436.    specified by this memo.  The node may receive both its request and
  1437.    the agent's response if both an ARP agent and multicast are active.
  1438.    In this case the address it learns from the I-field is later replaced
  1439.    by the address given by the ARP agent in the response.  Agents may
  1440.    assign new addresses to nodes and inform them by sending unsolicited
  1441.    AR_S_Response messages.  Any node whose switch address is updated in
  1442.    this way should invalidate the switch addresses it has saved for
  1443.    other nodes, and use ARP to rediscover them.
  1444.  
  1445.    If the node reacts correctly to either the multicast request or
  1446.    agent-generated response, it can discover its address without having
  1447.    to know whether or not an ARP agent is active.  The full procedure
  1448.    is:
  1449.  
  1450.    1.  Transmit the AR_S_Request
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Renwick & Nicholson                                            [Page 26]
  1459.  
  1460. RFC 1374                  IP and ARP on HIPPI               October 1992
  1461.  
  1462.  
  1463.    2.  When a connection arrives, accept it and save the I-field for
  1464.        later analysis.
  1465.  
  1466.    3.  Receive the message and look at the HIPPI-LE header.  If the
  1467.        message is Message Type AR_S_Request, analyze the I-field to
  1468.        discover the node's own switch address.  HIPPI-SC I-field formats
  1469.        suggest the following:
  1470.  
  1471.           if bit 25 == 1
  1472.                   Address type is HIPPI-SC logical address.
  1473.                   if bit 27 == 1
  1474.                           take address from bits 23-12
  1475.                   else
  1476.                           take address from bits 11-00
  1477.                   endif
  1478.           else
  1479.                   Address is unusable (source route)
  1480.           endif
  1481.  
  1482.        This is a one-time operation.  Once the node knows an address for
  1483.        itself, it should not take any new address from a received I-
  1484.        field.
  1485.  
  1486.    4.  If a message of type AR_S_Response arrives and the
  1487.        Destination_IEEE_Address field contains the node's own ULA, take
  1488.        the new switch address from the Destination_Switch_Address field
  1489.        and its type from the Destination_Address_Type field.
  1490.  
  1491.    5.  The node should invalidate its ARP tables when an AR_S_Response
  1492.        changes its own switch address, to force retransmission of ARP
  1493.        requests containing its new address to all the remote nodes with
  1494.        which it communicates.
  1495.  
  1496.  
  1497. Path MTU Discovery
  1498.  
  1499.    RFC 1191 [13] describes the method of determining MTU restrictions on
  1500.    an arbitrary network path between two hosts.  HIPPI nodes may use
  1501.    this method without modification to discover restrictions on paths
  1502.    between HIPPI-SC LANs and other networks.  Gateways between HIPPI-SC
  1503.    LANs and other types of networks should implement RFC 1191.
  1504.  
  1505. Channel Data Rate Discovery
  1506.  
  1507.    HIPPI exists in two data rate options (800 megabit/second and 1600
  1508.    megabit/second).  The higher data rate is achieved by making the
  1509.    HIPPI 64 bits parallel instead of 32, using an extra cable containing
  1510.    32 additional data bits and four parity bits.  HIPPI-SC switches can
  1511.  
  1512.  
  1513.  
  1514. Renwick & Nicholson                                            [Page 27]
  1515.  
  1516. RFC 1374                  IP and ARP on HIPPI               October 1992
  1517.  
  1518.  
  1519.    be designed to attach to both.  Source and Destination HIPPI
  1520.    implementations can be designed to operate at either rate, selectable
  1521.    at the time a connection is established.  The "W" bit (bit 28) of the
  1522.    I-field controls the width of the connection through the switch.
  1523.    Sources with both cables A and B attached to the switch may set the
  1524.    "W" bit to request a 1600 megabit/second connection.  If the
  1525.    requested destination also has both cables attached, the switch can
  1526.    connect Source to Destination on both cables.  If the requested
  1527.    Destination has only Cable A, the switch rejects the request.
  1528.    Sixty-four bit Sources can connect to 32 bit Destinations by
  1529.    requesting with the "W" bit clear and not using Cable B.  Sixty-four
  1530.    bit Destinations must examine the "W" bit in the received I-field and
  1531.    use or ignore Cable B accordingly.  Note that both INTERCONNECT
  1532.    signals stay active while a 64 bit HIPPI is used in 32 bit mode.
  1533.  
  1534.    The following table summarizes the possible combinations, the
  1535.    switch's action for each, and the width of the resulting connection.
  1536.  
  1537.                                      Destination
  1538.                       +-------------------+-------------------+
  1539.                       |        32         |        64         |
  1540.            +----+-----+-------------------+-------------------+
  1541.            |    | W=0 |     Accept 32     |     Accept 32     |
  1542.            | 32 +-----+-------------------+-------------------+
  1543.            |    | W=1 |        N/A        |        N/A        |
  1544.    Source  +----+-----+-------------------+-------------------+
  1545.            |    | W=0 |     Accept 32     |     Accept 32     |
  1546.            | 64 +-----+-------------------+-------------------+
  1547.            |    | W=1 |      Reject       |     Accept 64     |
  1548.            +----+-----+-------------------+-------------------+
  1549.  
  1550.                       HIPPI Connection Combinations
  1551.  
  1552.    If the path between a 64 bit Source and a 64 bit Destination includes
  1553.    more than one switch, and the route between switches uses a link that
  1554.    is only 32 bits wide, the switch rejects 64 bit connection requests
  1555.    as if the Destination did not have 64 bit capability.
  1556.  
  1557.    In a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to
  1558.    know the data rates available at each Destination and on the path to
  1559.    it.  This can be known a priori by manual configuration, or it can be
  1560.    discovered dynamically.  The only reliable method of discovery is
  1561.    simply to attempt a 64 bit connection with Camp-on.  As long as 64
  1562.    bit connections succeed, the Source knows the Destination and path
  1563.    are double width.  If a 64 bit connection is rejected, the Source
  1564.    tries to connect for 32 bits.  If the 32 bit connection succeeds, the
  1565.    Source assumes that the Destination or path is not capable of double
  1566.    width operation, and uses only 32 bit requests after that.  If the 32
  1567.  
  1568.  
  1569.  
  1570. Renwick & Nicholson                                            [Page 28]
  1571.  
  1572. RFC 1374                  IP and ARP on HIPPI               October 1992
  1573.  
  1574.  
  1575.    bit request is rejected, the Source assumes that the Destination or
  1576.    path is down and makes no determination of its capability.
  1577.  
  1578.    The Double_Wide bit in the HIPPI-LE header, if nonzero, gives the
  1579.    node that receives it a hint that the 64 bit connection attempt may
  1580.    be worthwhile when sending on the return path.
  1581.  
  1582.    Note that Camp-on must be used at least in the 64 bit attempt,
  1583.    because it removes some ambiguity from the meaning of rejects.  If
  1584.    the request is made with the "W" bit and no Camp-on, a reject could
  1585.    mean either that the Destination has no Cable B or that it is simply
  1586.    busy, and no conclusion can be drawn as to its status for 64 bit
  1587.    connections.
  1588.  
  1589. Performance
  1590.  
  1591.    The HIPPI connection rules are designed to permit best utilization of
  1592.    the available HIPPI throughput under the constraint that each
  1593.    Destination must be made available frequently to receive packets from
  1594.    different Sources.  This discipline asks both Sources and
  1595.    Destinations to minimize connection setup overhead to deliver high
  1596.    performance.  Low connection setup times are easily achieved by
  1597.    hardware implementations, but overhead may be too high if software is
  1598.    required to execute between the initial request of a connection and
  1599.    the beginning of data transfer.  Hardware implementations in which
  1600.    connection setup and data transfer proceed from a single software
  1601.    action are very desirable.
  1602.  
  1603.    HIPPI connections are controlled by HIPPI Sources; a Destination,
  1604.    being unable to initiate a disconnect without the possibility of data
  1605.    loss, is a slave to the Source once it has accepted a connection.
  1606.    Optimizations of connection strategy are therefore the province of
  1607.    the HIPPI Source, and several optimizations are permitted.
  1608.  
  1609.    If the rate of available message traffic is less than the available
  1610.    HIPPI throughput and Destinations are seldom busy when a connection
  1611.    is requested, connection optimizations do not pay off and the
  1612.    simplest strategy of waiting indefinitely for each connection to be
  1613.    made and sending messages strictly in the order queued cannot be
  1614.    improved upon.  However if some nodes are slow, or network
  1615.    applications can send or receive messages at a higher aggregate rate
  1616.    than the available HIPPI bandwidth, Sources may frequently encounter
  1617.    a busy Destination.  In these cases, certain host output queuing
  1618.    strategies may enhance channel utilization.  Sources may maintain
  1619.    separate output queues for different HIPPI Destinations, and abandon
  1620.    one Destination in favor of another if a connection attempt without
  1621.    Camp-on is rejected or a connection request with Camp-on is not
  1622.    accepted within a predetermined interval.  Such a strategy results in
  1623.  
  1624.  
  1625.  
  1626. Renwick & Nicholson                                            [Page 29]
  1627.  
  1628. RFC 1374                  IP and ARP on HIPPI               October 1992
  1629.  
  1630.  
  1631.    aborted connection sequences (defined in HIPPI-PH:  REQUEST is
  1632.    deasserted before any data is sent).  Destinations must treat these
  1633.    as normal events, perhaps counting them but otherwise ignoring them.
  1634.  
  1635.    Two components of connection setup time are out of the control of
  1636.    both Source and Destination.  One is the time required for the switch
  1637.    to connect Source to Destination, currently less than four
  1638.    microseconds in the largest commercially available (32 port) switch.
  1639.    The second component is the round trip propagation time of the
  1640.    REQUEST and CONNECT signals, negligible on a standard 25 meter copper
  1641.    HIPPI cable, but contributing a total of about 10 microseconds per
  1642.    kilometer on fiber optic links.  HIPPI-SC LANs spanning more than a
  1643.    few kilometers will have reduced throughput.  Limited span networks
  1644.    with buffered gateways or bridges between them may perform better
  1645.    than long serial HIPPI links.
  1646.  
  1647.    A Source is required to drop its connection after the transmission of
  1648.    68 HIPPI bursts.  This number was chosen to allow the transmission of
  1649.    one maximum sized packet or a reasonable number of smaller sized
  1650.    packets.  The following table lists some possibilities, with
  1651.    calculated maximum burst and throughput rates in millions (10**6) of
  1652.    bytes per second:
  1653.  
  1654.                      Maximum HIPPI Throughput Rates
  1655.  
  1656.         Number  Number  Hold  Burst  ------Max throughput MB/sec-------
  1657.    User   of      of    Time  Rate    Connection Setup Overhead (usec)
  1658.    Data Packets Bursts (usec) MB/sec  10    30    60    90   120   150
  1659.    ---- ------- ------ ------ ------ ----  ----  ----  ----  ----  ----
  1660.    63K     1      64    654    98.7  97.2  94.4  90.4  86.8  83.4  80.3
  1661.    32K     2      66    665    98.6  97.1  94.3  90.4  86.8  83.5  80.4
  1662.    16K     4      68    667    98.3  96.8  94.1  90.2  86.6  83.3  80.2
  1663.     8K     7      63    587    97.8  96.1  93.0  88.7  84.8  81.2  77.8
  1664.     4K    13      65    551    96.7  95.0  91.7  87.2  83.1  79.4  76.0
  1665.     2K    22      66    476    94.6  92.7  89.0  84.0  79.6  75.6  72.0
  1666.     1K    34      68    384    90.8  88.5  84.2  78.5  73.5  75.8  65.3
  1667.  
  1668.    These calculations are based 259 40 ns clock periods to transmit a
  1669.    full burst and 23 clock periods for a short burst.  (HIPPI-PH
  1670.    specifies three clock periods of overhead per burst.) A packet of "n"
  1671.    kilobytes of user data consists of "n" full bursts and one short
  1672.    burst equal in length to the number of bytes in the HIPPI, LLC, IP
  1673.    and TCP headers.  "Hold Time" is the minimum connection duration
  1674.    needed to send the packets.  "Burst Rate" is the effective transfer
  1675.    rate for the duration of the connection, not counting connection
  1676.    switching time.  Throughput rates are in megabytes/second, accounting
  1677.    for connection switching times of 10, 30, 60, 90, 120 and 150
  1678.    microseconds.  These calculations ignore any limit on the rate at
  1679.  
  1680.  
  1681.  
  1682. Renwick & Nicholson                                            [Page 30]
  1683.  
  1684. RFC 1374                  IP and ARP on HIPPI               October 1992
  1685.  
  1686.  
  1687.    which a Source or Destination can process small packets; such limits
  1688.    may further reduce the available throughput if small packets are
  1689.    used.
  1690.  
  1691. Sharing the Switch
  1692.  
  1693.    Network interconnection is only one potential application of HIPPI
  1694.    and HIPPI-SC switches.  While network applications need very frequent
  1695.    transient connections, other applications may favor longer term or
  1696.    even permanent connections between Source and Destination.  Since the
  1697.    switch can serve each Source or Destination with hardware paths
  1698.    totally separate from every other, it is quite feasible to use the
  1699.    same switch to support LAN interconnects and computer/peripheral
  1700.    applications simultaneously.
  1701.  
  1702.    Switch sharing is no problem when unlike applications do not share a
  1703.    HIPPI cable on any path.  However if a host must use a single input
  1704.    or output cable for network as well as other kinds of traffic, or if
  1705.    a link between switches must be shared, care must be taken to ensure
  1706.    that all applications are compatible with the connection discipline
  1707.    described in this memo.  Applications that hold connections too long
  1708.    on links shared with network traffic may cause loss of network
  1709.    packets or serious degradation of network service.
  1710.  
  1711.  
  1712. Appendix A -- HIPPI Basics
  1713.  
  1714.    This section is included as an aid to readers who are not completely
  1715.    familiar with the HIPPI standards.
  1716.  
  1717.    HIPPI-PH describes a parallel copper data channel between a Source
  1718.    and a Destination.  HIPPI transmits data in one direction only, so
  1719.    that two sets are required for bidirectional flow.  The following
  1720.    figure shows a simple point-to-point link between two computer
  1721.    systems:
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Renwick & Nicholson                                            [Page 31]
  1739.  
  1740. RFC 1374                  IP and ARP on HIPPI               October 1992
  1741.  
  1742.  
  1743.    +----------+                                        +----------+
  1744.    |          |                                        |          |
  1745.    |          +--------+                      +--------+          |
  1746.    |          | HIPPI  |        Cable         | HIPPI  |          |
  1747.    |          |        +--------------------->|        |          |
  1748.    |          | Source |                      | Dest.  |          |
  1749.    |  System  +--------+                      +--------+  System  |
  1750.    |    X     +--------+                      +--------+    Y     |
  1751.    |          | HIPPI  |        Cable         | HIPPI  |          |
  1752.    |          |        |<---------------------+        |          |
  1753.    |          | Dest.  |                      | Source |          |
  1754.    |          +--------+                      +--------+          |
  1755.    |          |                                        |          |
  1756.    +----------+                                        +----------+
  1757.  
  1758.                       A Simple HIPPI Duplex Link
  1759.  
  1760.    Parallel copper cables may be up to 25 meters in length.
  1761.  
  1762.    In this document, all HIPPI connections are assumed to be paired
  1763.    HIPPI channels.
  1764.  
  1765.    HIPPI-PH has a single optional feature: it can use a single cable in
  1766.    each direction for a 32 bit parallel channel with a maximum data rate
  1767.    of 800 megabit/second, or two cables for 64 bits and 1600
  1768.    megabit/second.  Cable A carries bits 0-31 and is used in both modes;
  1769.    Cable B carries bits 32-63 and is use only with the 1600
  1770.    megabit/second data rate option.
  1771.  
  1772.    HIPPI Signal Hierarchy
  1773.  
  1774.       HIPPI has the following hardware signals:
  1775.  
  1776.       Source to Destination
  1777.  
  1778.          INTERCONNECT A
  1779.          INTERCONNECT B (64 bit only)
  1780.          CLOCK (25 MHz)
  1781.          REQUEST
  1782.          PACKET
  1783.          BURST
  1784.          DATA (32 or 64 signals)
  1785.          PARITY (4 or 8 signals)
  1786.  
  1787.       Destination to Source
  1788.  
  1789.          INTERCONNECT A
  1790.          INTERCONNECT B (64 bit only)
  1791.  
  1792.  
  1793.  
  1794. Renwick & Nicholson                                            [Page 32]
  1795.  
  1796. RFC 1374                  IP and ARP on HIPPI               October 1992
  1797.  
  1798.  
  1799.          CONNECT
  1800.          READY
  1801.  
  1802.       The INTERCONNECT lines carry DC voltages that indicate that the
  1803.       cable is connected and that the remote interface has power.
  1804.       INTERCONNECT is not used for signaling.
  1805.  
  1806.       The CLOCK signal is a continuous 25 MHz (40 ns period) square
  1807.       wave.  All Source-to-Destination signals are synchronized to the
  1808.       clock.
  1809.  
  1810.       The REQUEST and CONNECT lines are used to establish logical
  1811.       connections.  A connection is always initiated by a Source as it
  1812.       asserts REQUEST.  At the same time it puts 32 bits of data on DATA
  1813.       lines 0-31, called the I-field.  The Destination samples the DATA
  1814.       lines and can complete a connection by asserting CONNECT.  Packets
  1815.       can be transmitted only while both REQUEST and CONNECT are
  1816.       asserted.
  1817.  
  1818.       A Destination can also reject a connection by asserting CONNECT
  1819.       for only a short interval between 4 and 16 HIPPI clock periods
  1820.       (160-640 nanoseconds).  The Source knows a connection has been
  1821.       accepted when CONNECT is asserted for more than 16 clocks or it
  1822.       receives a READY pulse.
  1823.  
  1824.       Either Source or Destination can terminate a connection by
  1825.       deasserting REQUEST or CONNECT, respectively.  Normally
  1826.       connections are terminated by the Source after its last Packet has
  1827.       been sent.  A Destination cannot terminate a connection without
  1828.       potential loss of data.
  1829.  
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Renwick & Nicholson                                            [Page 33]
  1851.  
  1852. RFC 1374                  IP and ARP on HIPPI               October 1992
  1853.  
  1854.  
  1855.                 +------+-------------------------+------+
  1856.                 | Idle |        Connected        | Idle | . . .
  1857.                 +------+-------------------------+------+
  1858.                      /                           \
  1859.                     /                             \
  1860.                    /                               \
  1861.                   /                                 \
  1862.                  /                                   \
  1863.                 +-------+ +-------+ +-------+ +-------+
  1864.                 |I-field| |Packet | |Packet | |Packet |
  1865.                 +-------+ +-------+ +-------+ +-------+
  1866.                          /         \
  1867.                         /           \
  1868.                        /             \
  1869.                       /               \
  1870.                      /                 \
  1871.                     /                   \
  1872.                    /                     \
  1873.                   +-----+ +-----+   +-----+
  1874.                   |Burst| |Burst|...|Burst|
  1875.                   +-----+ +-----+   +-----+
  1876.  
  1877.                    HIPPI Logical Framing Hierarchy
  1878.  
  1879.       The Source asserts PACKET for the duration of a Packet
  1880.       transmission, deasserting it to indicate the end of a Packet.  A
  1881.       sequence of Bursts comprise a Packet.  To send a burst, a Source
  1882.       asserts the BURST signal for 256 clock periods, during which it
  1883.       places 256 words of data on the DATA lines.  The first or last
  1884.       Burst of a Packet may be less than 256 clock periods, allowing the
  1885.       transmission of any integral number of 32 or 64 bit words in a
  1886.       Packet.
  1887.  
  1888.       The READY signal is a pulse four or more clock periods long.  Each
  1889.       pulse signals the Source that the Destination can receive one
  1890.       Burst.  The Destination need not wait for a burst before sending
  1891.       another READY if it has burst buffers available; up to 63
  1892.       unanswered READYs may be sent, allowing HIPPI to operate at full
  1893.       speed over distances of many kilometers.  If a Source must wait
  1894.       for flow control, it inserts idle periods between Bursts.
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Renwick & Nicholson                                            [Page 34]
  1907.  
  1908. RFC 1374                  IP and ARP on HIPPI               October 1992
  1909.  
  1910.  
  1911.                 +------------------------------------------------+
  1912.       REQUEST---+                                                +----
  1913.                       +--------------------------------------------+
  1914.       CONNECT---------+                                            +--
  1915.                          +---------------------------------------+
  1916.       PACKET-------------+                                       +----
  1917.  
  1918.                        +-+   +-+   +-+   +-+   +-+   +-+   +-+   +-+
  1919.       READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--
  1920.  
  1921.                          +-------+ +-------+ +-------+ +-----+
  1922.       BURST--------------+       +-+       +-+       +-+     +--------
  1923.  
  1924.       DATA------I-field----DATA------DATA------DATA-----DATA----------
  1925.  
  1926.                         HIPPI Signal Timing Diagram
  1927.  
  1928.    Serial HIPPI
  1929.  
  1930.       There is no ANSI standard for HIPPI other than the parallel copper
  1931.       cable version.  However an implementors' agreement exists,
  1932.       specifying a serial protocol to extend HIPPI signals on optical
  1933.       fiber or coaxial copper cable.  Serial links may be used
  1934.       interchangeably with parallel links to overcome HIPPI distance
  1935.       limitations; they are transparent to the Source and Destination,
  1936.       except for the possibility of longer propagation delays.
  1937.  
  1938.    I-Field and Switch Control
  1939.  
  1940.       The REQUEST, CONNECT and I-field features of HIPPI-PH were
  1941.       designed for the control of switches as described in HIPPI-SC.  A
  1942.       switch is a hub with a number of input and output HIPPI ports.
  1943.       HIPPI Sources are cabled to switch input ports, and switch output
  1944.       ports are cabled to HIPPI Destinations.  When a HIPPI Source
  1945.       requests a connection, the switch interprets the I-field to select
  1946.       an output port and electrically connects the HIPPI Source to the
  1947.       HIPPI Destination on that port.  Once connected, the switch does
  1948.       not interact with the HIPPIs in any way until REQUEST or CONNECT
  1949.       is deasserted, at which time it breaks the physical connection and
  1950.       deasserts its output signals to both sides.  Some existing switch
  1951.       implementations can switch connections in less than one
  1952.       microsecond.  There is the potential for as many simultaneous
  1953.       connections, each transferring data at HIPPI speeds, as there are
  1954.       input or output ports on the switch.  A switch offers much greater
  1955.       total throughput capacity than broadcast or ring media.
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Renwick & Nicholson                                            [Page 35]
  1963.  
  1964. RFC 1374                  IP and ARP on HIPPI               October 1992
  1965.  
  1966.  
  1967.       31    28  26    23                      11                     0
  1968.       +-+---+-+-+---+-+-----------------------+-----------------------+
  1969.       |L|   |W|D|PS |C|    Source Address     |  Destination Address  |
  1970.       +-+---+-+-+---+-+-----------------------+-----------------------+
  1971.  
  1972.                   HIPPI-SC I-field Format (Logical Address Mode)
  1973.  
  1974.            L  = Locally defined (1 => entire I-field is locally defined)
  1975.            W  = Width (1 => 64 bit connection)
  1976.            D  = Direction (1 => swap Source and Destination Address)
  1977.            PS = Path Selection (01 => Logical Address Mode)
  1978.            C  = Camp-on (1 => wait until Destination is free)
  1979.  
  1980.       HIPPI-SC defines I-field formats for two different addressing
  1981.       modes.  The first, called Source Routing, encodes a string of port
  1982.       numbers in the lower 24 bits.  This string specifies a route over
  1983.       a number of switches.  A Destination's address may differ from one
  1984.       Source to another if multiple switches are used.
  1985.  
  1986.       The second format, called Logical Address Mode, defines two 12 bit
  1987.       fields, Source Address and Destination Address.  A Destination's
  1988.       12 bit Switch Address is the same for all Sources.  Switches
  1989.       commonly have address lookup tables to map 12 bit logical
  1990.       addresses to physical ports.  This mode is used for networking.
  1991.  
  1992.       Control fields in the I-field are:
  1993.  
  1994.  
  1995.       L  The "Locally Defined" bit, when set, indicates that the I-field
  1996.          is not in the standard format.  The meaning of bits 30-0 are
  1997.          locally defined.
  1998.  
  1999.       W  The Width bit, when set, requests a 64 bit connection through
  2000.          the switch.  It is meaningless if Cable B is not installed at
  2001.          the Source.  If W is set and either the Source or the requested
  2002.          Destination has no Cable B to the switch, the switch rejects
  2003.          the connection.  Otherwise the switch connects both Cable A and
  2004.          Cable B if W is set, or Cable A only if W is clear.  This
  2005.          feature is useful if both Source and Destination
  2006.          implementations can selectively disable or enable Cable B on
  2007.          each new connection.
  2008.  
  2009.       D  The Direction bit, when set, reverses the sense of the Source
  2010.          Address and Destination Address fields.  In other words, D=1
  2011.          means that the Source Address is in bits 0-11 and the
  2012.          Destination Address is in bits 12-23.  This bit was defined to
  2013.          give devices a simple way to route return messages.  It is not
  2014.          useful for LAN operations.
  2015.  
  2016.  
  2017.  
  2018. Renwick & Nicholson                                            [Page 36]
  2019.  
  2020. RFC 1374                  IP and ARP on HIPPI               October 1992
  2021.  
  2022.  
  2023.       PS The Path Selection field determines whether the I-field
  2024.          contains Source Route or Address information, and in Logical
  2025.          Address mode, whether the switch may select from multiple
  2026.          possible routes to the destination.  The value "01" selects
  2027.          Logical Address mode and fixed routes.
  2028.  
  2029.       C  The Camp-on bit requests the switch not to reject the
  2030.          connection if the selected Destination is busy (connected to
  2031.          another Source) but wait and make the connection when the
  2032.          Destination is free.
  2033.  
  2034.  
  2035. Appendix B -- How to Build a Practical HIPPI LAN
  2036.  
  2037.    "IP and ARP on HIPPI" describes the network host's view of a HIPPI
  2038.    local area network without providing much information on the
  2039.    architecture of the network itself.  Here we describe a network
  2040.    constructed from available HIPPI components, having the following
  2041.    characteristics:
  2042.  
  2043.    1.  A tree structure with a central HIPPI-SC compliant hub and
  2044.        optional satellite switches
  2045.  
  2046.    2.  Each satellite is connected to the hub by just one bidirectional
  2047.        HIPPI link.
  2048.  
  2049.    3.  Serial HIPPI or transparent fiber optic HIPPI extender devices
  2050.        may be used in any link.
  2051.  
  2052.    4.  Some satellites may be a particular switch product which is not
  2053.        HIPPI-SC compliant.
  2054.  
  2055.    5.  Host systems are attached either directly to the hub or to
  2056.        satellites, by single bidirectional links in which both HIPPI
  2057.        cables go to the same numbered switch port.
  2058.  
  2059.    6.  A server system is attached to the hub.  It provides multicast
  2060.        and ARP services.
  2061.  
  2062.    7.  All options of the Internet Draft are supported.  Hosts may use
  2063.        any form of address resolution: manual configuration, ARP with
  2064.        multicast, or ARP with a server.
  2065.  
  2066.    Switch Address Management
  2067.  
  2068.       Switch addresses use a flat address space.  The 12-bit address is
  2069.       subdivided into 6 bits of switch number and 6 bits of port number.
  2070.  
  2071.  
  2072.  
  2073.  
  2074. Renwick & Nicholson                                            [Page 37]
  2075.  
  2076. RFC 1374                  IP and ARP on HIPPI               October 1992
  2077.  
  2078.  
  2079.       11                       5                     0
  2080.       +-----------------------+-----------------------+
  2081.       |     Switch Number     |      Port Number      |
  2082.       +-----------------------+-----------------------+
  2083.  
  2084.                  Logical Address Construction
  2085.  
  2086.       Switches may be numbered arbitrarily.  A given host's address
  2087.       consists of the number of the switch it is directly attached to
  2088.       and the physical port number on that switch to which its input
  2089.       channel is attached.
  2090.  
  2091.       In the singly-connected tree structure, there is exactly one path
  2092.       between any pair of hosts.  Since each satellite must be connected
  2093.       directly to the hub, the maximum length of this path is three
  2094.       hops, and the minimum length is one.  Each HIPPI-SC compliant
  2095.       switch is programmed to map each of the host switch addresses to
  2096.       the appropriate output port: either the port to which the host is
  2097.       directly attached or a port that is linked to another switch in
  2098.       the path to it.
  2099.  
  2100.    Special Treatment of Nonstandard Switches
  2101.  
  2102.       There is one commercially available switch that was designed
  2103.       before the drafting of HIPPI-SC and is not fully compliant.  It is
  2104.       in common use, so it is worth making some special provisions to
  2105.       allow its use in a HIPPI LAN.  This switch supports only the
  2106.       Source Route mode of addressing with a four bit right shift that
  2107.       can be disabled by a hardware switch on each input port.
  2108.       Addresses cannot be mapped.  The switch does not support the "W,"
  2109.       "D," or "PS" fields of the I-field; it ignores their contents.
  2110.       Use of this switch as a satellite will require a slight deviation
  2111.       from normal I-field usage by the hosts that are directly attached
  2112.       to it.  Hosts attached to standard switches are not affected.
  2113.  
  2114.       For a destination connected to a non compliant satellite, the
  2115.       satellite uses only the least significant four bits of the I-field
  2116.       as the address.  Since the address contains the destination's
  2117.       physical port number in the least significant bits, its port will
  2118.       be selected.  Nonstandard switches should be set to disable I-
  2119.       field shifting at the input from the hub, so that the destination
  2120.       host will see its correct switch address in the I-field when
  2121.       performing self-address discovery.  I-field shifting must be
  2122.       enabled on the satellite for each input port to which a host is
  2123.       attached.
  2124.  
  2125.       Hosts attached to nonstandard satellites must deviate from the
  2126.       normal I-field usage when connecting to hosts on another switch.
  2127.  
  2128.  
  2129.  
  2130. Renwick & Nicholson                                            [Page 38]
  2131.  
  2132. RFC 1374                  IP and ARP on HIPPI               October 1992
  2133.  
  2134.  
  2135.       It is suggested that all host implementations have this capability
  2136.       as long as the nonstandard switches remain in use.  The host must
  2137.       know, by some manual configuration method, that it is connected to
  2138.       a nonstandard switch, and it must have its "link port" number;
  2139.       that is, the number of the port on the satellite that is connected
  2140.       to the hub.
  2141.  
  2142.       The normal I-field format for a 32-bit connection, per the
  2143.       Internet Draft, is this:
  2144.  
  2145.       31        26    23                      11                     0
  2146.       +---------+---+-+-----------------------+-----------------------+
  2147.       |0 0 0 0 0|x 1|C|        Unused         |  Destination Address  |
  2148.       +---------+---+-+-----------------------+-----------------------+
  2149.  
  2150.       The special I-field format is:
  2151.  
  2152.       31        26  24                15                     4 3     0
  2153.       +---------+---+-+---------------+-----------------------+-------+
  2154.       |0 0 0 0 0|x 1|C|    Unused     |  Destination Address  | Link  |
  2155.       +---------+---+-+---------------+-----------------------+-------+
  2156.  
  2157.       This I-field is altered by shifting the lower 24 bits left by four
  2158.       and adding the link port number.  Camp-on is optional, and the PS
  2159.       field is set to 01 or 11 (the host's option) as if the switch
  2160.       supported logical address mode.  All other I-field bits are set to
  2161.       zero.  When the host requests a connection with this I-field, the
  2162.       switch selects a connection through the link port to the hub, and
  2163.       shifts the lower 24 bits of the I-field right by four bits.  The
  2164.       link port number is discarded and the I-field passed through to
  2165.       the hub is a proper HIPPI-SC I-field selecting logical address
  2166.       mode.
  2167.  
  2168.       A host on a nonstandard satellite may use the special I-field
  2169.       format for all connection requests.  If connecting to another host
  2170.       on the same satellite, this will cause the connection to take an
  2171.       unnecessarily long path through the hub and back.  If an
  2172.       optimization is desired, the host can be given additional
  2173.       information to allow it to use the standard I-field format when
  2174.       connecting to another host on the same switch.  This information
  2175.       could consist of a list of the other hosts on the same switch, or
  2176.       the details of address formation, along with the switch number of
  2177.       the local satellite, which would allow the host to analyze the
  2178.       switch address to determine whether or not the destination is on
  2179.       the local switch.  This optimization is fairly complicated and may
  2180.       not always be worthwhile.
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186. Renwick & Nicholson                                            [Page 39]
  2187.  
  2188. RFC 1374                  IP and ARP on HIPPI               October 1992
  2189.  
  2190.  
  2191.    Server Algorithm
  2192.  
  2193.       Different host implementations may take any of three approaches to
  2194.       address resolution:
  2195.  
  2196.       1.  Manual configuration, no ARP
  2197.  
  2198.       2.  Send ARP requests but expect a server to reply on its behalf
  2199.  
  2200.       3.  Send ARP requests and expect to receive them via multicast.
  2201.  
  2202.       If the network includes a server that is capable of both multicast
  2203.       and ARP service, and that knows the services expected by each
  2204.       host, all can coexist on the same net.
  2205.  
  2206.       The HIPPI-SC compliant switches are programmed to route the
  2207.       HIPPI-SC "broadcast" address FE0 (hex) to the server's port.  It
  2208.       is initially given the following information by a human network
  2209.       administrator:
  2210.  
  2211.       1.  The list of all addresses eligible to be used by network hosts
  2212.  
  2213.       2.  The list of addresses that should not receive multicast
  2214.           messages (a subset of list 1).  This is also the list of all
  2215.           hosts that either do manual configuration or expect a server
  2216.           to answer ARP requests.
  2217.  
  2218.       3.  The list of addresses of hosts that do manual configuration
  2219.           and do not send ARP requests (a subset of list 2) with the IP
  2220.           address corresponding to each one.
  2221.  
  2222.       The server maintains an address resolution cache that it
  2223.       initializes from list 3 (the manually configured hosts).  It will
  2224.       add to its cache as other hosts send ARP requests.
  2225.  
  2226.       When the server receives a message sent to the broadcast address
  2227.       FE0, it
  2228.  
  2229.       1.  Repeats the message to all addresses in list 1 but not in list
  2230.           2
  2231.  
  2232.       2.  If the message is a HIPPI-LE AR_Request with a piggybacked ARP
  2233.           Request, update the cache with information about the sender.
  2234.  
  2235.       3.  If the message is a HIPPI-LE AR_Request with a piggybacked ARP
  2236.           Request, the target system has an entry in the cache and the
  2237.           target is in list 2, respond to the ARP request.
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Renwick & Nicholson                                            [Page 40]
  2243.  
  2244. RFC 1374                  IP and ARP on HIPPI               October 1992
  2245.  
  2246.  
  2247.       Server Optimizations
  2248.  
  2249.          1.  The server could be given a topological map of the hub and
  2250.              satellites from which it could construct list 1.
  2251.  
  2252.          2.  If all the hosts in list 2 ignore ARP messages as required
  2253.              in the Internet Draft, list 2 may be eliminated and the
  2254.              server can respond to all ARP requests (redundant replies
  2255.              may be sent).
  2256.  
  2257.  
  2258.    Sharing Switch Hardware With Other Devices
  2259.  
  2260.       Some host channels and peripheral devices that are connected to
  2261.       the switches may use protocols other than IP, and not participate
  2262.       in the LAN.  Since connections in a switch are independent, these
  2263.       applications can share switch hardware with no effect on LAN
  2264.       operation.  To ensure success:
  2265.  
  2266.          The server's lists of addresses should not include addresses
  2267.          for ports that are not used by LAN links or hosts.
  2268.  
  2269.          If non-LAN applications use paths between switches, separate
  2270.          links should be installed for them so that they do not use the
  2271.          same inter-switch links the LAN does.
  2272.  
  2273. References
  2274.  
  2275.  
  2276. [1]  ANSI X3.183-1991, High-Performance Parallel Interface - Mechanical,
  2277.      Electrical and Signalling Protocol Specification (HIPPI-PH).
  2278.  
  2279. [2]  ANSI X3.210-199X, High-Performance Parallel Interface - Framing
  2280.      Protocol (HIPPI-FP).
  2281.  
  2282. [3]  ANSI X3.218-199X, High-Performance Parallel Interface -
  2283.      Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link Control
  2284.      Protocol Data Units (802.2 Link Encapsulation) (HIPPI-LE).
  2285.  
  2286. [4]  ANSI X3.222-199X, High-Performance Parallel Interface - Physical
  2287.      Switch Control (HIPPI-SC).
  2288.  
  2289. [5]  Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences
  2290.      Institute, September 1981.
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Renwick & Nicholson                                            [Page 41]
  2299.  
  2300. RFC 1374                  IP and ARP on HIPPI               October 1992
  2301.  
  2302.  
  2303. [6]  Postel, J., and Reynolds, J., "A Standard for the Transmission of
  2304.      IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
  2305.      Sciences Institute, February 1988.
  2306.  
  2307. [7]  IEEE, "IEEE Standards for Local Area Networks: Logical Link
  2308.      Control", IEEE, New York, New York, 1985.
  2309.  
  2310. [8]  Reynolds, J.K., and Postel, J., "Assigned Numbers", RFC 1340,
  2311.      USC/Information Sciences Institute, July 1992.
  2312.  
  2313. [9]  Plummer, D., "An Ethernet Address Resolution Protocol - or -
  2314.      Converting Network Protocol Addresses to 48.bit Ethernet Address
  2315.      for Transmission on Ethernet Hardware", RFC 826, MIT, November
  2316.      1982.
  2317.  
  2318. [10] Finlayson, R., Mann, T., Mogul, J., and  Theimer, M., "A Reverse
  2319.      Address Resolution Protocol", RFC 903, Stanford University, June
  2320.      1984.
  2321.  
  2322. [11] Katz, D., "A Proposed Standard for the Transmission of IP Datagrams
  2323.      over FDDI Networks", RFC 1188, Merit/NSFNET, October, 1990.
  2324.  
  2325. [12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
  2326.  
  2327. [13] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191,
  2328.      Stanford University, November, 1990.
  2329.  
  2330.  
  2331. Security Considerations
  2332.  
  2333.    Security issues are not discussed in this memo.
  2334.  
  2335. Authors' Addresses
  2336.  
  2337.    John K. Renwick
  2338.    Cray Research, Inc.
  2339.    655F Lone Oak Drive
  2340.    Eagan, MN 55121
  2341.  
  2342.    Phone: (612) 683-5573
  2343.  
  2344.    Mailing List: (none)
  2345.    EMail: jkr@CRAY.COM
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354. Renwick & Nicholson                                            [Page 42]
  2355.  
  2356. RFC 1374                  IP and ARP on HIPPI               October 1992
  2357.  
  2358.  
  2359.    Andy Nicholson
  2360.    Cray Research, Inc.
  2361.    655F Lone Oak Drive
  2362.    Eagan, MN 55121
  2363.  
  2364.    Phone: (612) 683-5473
  2365.  
  2366.    Mailing List: (none)
  2367.    EMail: droid@CRAY.COM
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.  
  2381.  
  2382.  
  2383.  
  2384.  
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410. Renwick & Nicholson                                            [Page 43]
  2411.  
  2412.