rfc2834.txt

RFC 的详细文档！

Pittet                      Standards Track                    [Page 11]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   If the registration phase showed that the hardware does not support
   broadcast, then the client MUST refresh its own entry for the HARP
   server, created during the registration phase, at least once every 15
   minutes. This can be accomplished either through the exchange of a
   HARP request/reply with the HARP server or by repeating step 1. To
   decrease the redundant network traffic, this timeout SHOULD be reset
   after each HARP_REQUEST/HARP_REPLY exchange.

   Explanation: The HARP_REQUEST shows the HARP server that the client
   is still alive. Receiving a HARP_REPLY indicates to the client that
   the server must have seen the HARP_REQUEST.

   If the registration phase shows that the underlying network supports
   broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of
   step 4 are NOT REQUIRED.

5.3 Receiving Unknown HARP Messages

   If a HARP client receives a HARP message with an operation code
   (ar$op) that it does not support, it MUST gracefully discard the
   message and continue normal operation.  A HARP client is NOT REQUIRED
   to return any message to the sender of the undefined message.

5.4 HARP Server Operational Requirements

   A HARP server MUST accept HIPPI connections from other HIPPI ports.
   The HARP server expects an InHARP_REQUEST as the first message from
   the client. A server examines the IP source address, the hardware
   source address of the InHARP_REQUEST and adds or updates its HARP
   table entry <IP address(es), switch address, ULA>  as well as the
   time stamp.

   A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs based
   on the information which it has in its HARP table.  The HARP server
   SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has the
   requested information in its tables; otherwise it SHALL reply with a
   HARP_NAK. The HARP server replies SHALL contain the hardware type and
   corresponding format of the request (see also section 6).

   The following table shows all possible source address combinations on
   an incoming message and the actions to be taken. "linked" indicates
   that an existing "IP entry" is linked to a "hardware entry". It is
   possible to have an existing "IP entry" and to have an existing
   "hardware entry" but neither is linked to the other.







Pittet                      Standards Track                    [Page 12]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


      +---+----------+----------+------------+---------------------+
      | # | IP entry | HW entry |  misc      |      Action         |
      +---+----------+----------+------------+---------------------+
      | 1 |  exists  |  exists  |     linked | *                   |
      | 2 |  exists  |  exists  | not linked | *, a, b,       e, f |
      | 3 |  exists  |    new   | not linked | *, a, b,    d, e, f |
      | 4 |   new    |  exists  | not linked | *,       c,    e, f |
      | 5 |   new    |    new   | not linked | *,       c, d, e, f |
      +---+----------+----------+------------+---------------------+
      Actions:
      *: update timeout value
      a: break the existing IP -> hardware (HW) - old link
      b: delete HW(old) -> IP link and decrement HW(old) refcount, if
         refcount = 0, delete HW(old)
      c: create new IP entry
      d: create new HW entry
      e: add new IP -> HW link to IP entry
      f: add new HW -> IP link to HW entry

   Examples of when this could happen (Numbers match lines in above
   table):

   1: supplemental message

      Just update timer.

   2: move an IP alias to an existing interface

      If the IP source address of the InHARP_REQUEST duplicates a table
      entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST
      hardware source address matches a hardware address entry (e.g. HWb
      <-> IPb), but they are not linked together, then:
      -  HWa entry needs to have its reference to the current IPa
         address removed.
      -  HWb needs to have a new reference to IPa added
      -  IPa needs to be linked to HWb

   3: move IP address to a new interface

      If the InHARP_REQUEST requester's IP source address duplicates a
      table entry IP address and the InHARP_REQUEST hardware source
      address does not match the table entry hardware address, then a
      new HW entry SHALL be created. The requestor's IP address SHALL be
      moved from the original HW entry to the new one (see above).







Pittet                      Standards Track                    [Page 13]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   4: add  IP alias to table

      If the InHARP_REQUEST requester's hardware source address
      duplicates a hardware source address entry, but there is no IP
      entry matching the received IP address, then the IP address SHALL
      be added to the hardware entries previous IP address(es). (E.g.
      adding an IP alias).

   5: fresh entry, add it

      Standard case, create both entries and link them.

   A server MUST update the HARP table entry's timeout for each
   HARP_REQUEST. Explanation: if the client is sending HARP requests to
   the server, then the server SHOULD note that the client is still
   "alive" by updating the timeout on the client's HARP table entry.

   A HARP server SHOULD use the PIBES (see section 7) to send out
   HARP_REPLYs to all hardware addresses in its table when the HARP
   server table changes mappings. This feature decreases the time of
   stale entries in the clients.

   If there are multiple addresses in the HRAL, then a server needs to
   act as a client to the other servers.

5.5 HARP and Permanent ARP Table Entries

   An IP station MUST have a mechanism (e.g. manual configuration) for
   determining what permanent entries it has. The details of the
   mechanism are beyond the scope of this memo.  The permanent entries
   allow interoperability with legacy HIPPI adapters which do not yet
   implement dynamic HARP and use a table-based static ARP. Permanent
   entries are not aged.

   The HARP server SHOULD use the static entries to resolve incoming
   HARP_REQUESTs from the clients. This feature eliminates the need for
   maintaining a static HARP table on the client ports.

5.6 HARP Table Aging

   HARP table aging MUST be supported since IP addresses, especially IP
   aliases and also interfaces (with their ULA), are likely to move.
   When so doing the mapping in the clients own HARP table/cache becomes
   invalid and stale.

   o  When a client's HARP table entry ages beyond 15 minutes, a HARP
      client MUST invalidate the table entry.




Pittet                      Standards Track                    [Page 14]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   o  When a server's HARP table entry ages beyond 20 minutes, the HARP
      server MUST delete the table entry.

   NOTE: the client SHOULD revalidate a HARP table entry before it ages,
   thus restarting the aging time when the table entry is successfully
   revalidated.  The client MAY continue sending traffic to the port
   referred to by this entry while revalidation is in progress, as long
   as the table entry has not aged. The client MUST revalidate an aged
   entry prior to transmitting any non-address-resolution traffic to the
   port referred to by this entry.

   The client revalidates the entry by querying the HARP server with a
   HARP_REQUEST.  If a valid reply is received (e.g. HARP_REPLY), the
   entry is updated.  If the address resolution service cannot resolve
   the entry (e.g. HARP_NAK, "host not found"), the associated table
   entry is removed.  If the address resolution service is not available
   (i.e. "server failure") the client MUST attempt to revalidate the
   entry by transmitting an InHARP_REQUEST to the hardware address of
   the entry in question and updating the  entry on receipt of an
   InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an
   InHARP_REPLY, the associated table entry is removed.

6. HARP Message Encoding

   The HARP Message is encapsulated over HIPPI-FP and HIPPI-LE headers.
   The HARP FP header values are to be set as defined in RFC-2067 "IP
   over HIPPI" [15]. The following sections detail the HIPPI-LE field
   contents and HARP message structure and contents. In a broadcast
   capable network the client MAY also support Type 1 and 6, Ethernet
   and IEEE 802 ARP packet formats.

6.1 HIPPI-LE Header of HARP Messages

   The HIPPI message format for Internet datagrams shall conform to the
   HIPPI-FP [2] and HIPPI-LE [3] standards.  The length of a HIPPI
   message, including trailing fill, shall be a multiple of eight bytes
   as required by HIPPI-LE.  The HIPPI-LE header fields of HARP and
   InHARP requests and replies SHALL be:

   FC (3 bits) SHALL contain zero.

   Double-wide SHOULD be set according to HIPPI-LE [3]. This memo does
   NOT address the implications on HARP when this bit is set to 1
   indicating the possibility of a port being able to accept 64-bit
   HIPPI connections.






Pittet                      Standards Track                    [Page 15]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


   Message_Type SHALL contain 0 to indicate a data message. HARP
   messages are identified using the Ethertype and the message type in
   the ar$op field of the HARP message.

   Destination_Switch_Address, SHALL be the Switch Address of the
   destination port.

   Destination_IEEE_Address SHALL be the ULA of the destination port, if
   known, otherwise zero.

   Destination_Address_Type SHALL be 2, a 12-bit logical address.  The
   behavior with type = 1, source routing, is NOT defined in this
   specification.

   Source_Switch_Address in requests SHALL be the sender's Switch
   Address.

   Source_IEEE_Address SHALL be the sender's ULA if known, otherwise
   zero.

   Source_Address_Type SHALL be 2, a 12-bit logical address. The
   behavior with type = 1, source routing, is NOT defined in this
   specification.

6.1.1 IEEE 802.2 LLC

   The IEEE 802.2 LLC Header SHALL begin in the first byte of the
   HIPPI-FP D2_Area.

   The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes)
   indicating the presence of a SNAP header.

6.1.2 SNAP

   The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
   indicating that the following two-bytes is an Ethertype.

   The Ethertype value SHALL be set as defined in Assigned Numbers [16]:
   InHARP = InARP = HARP = ARP = 2054 = 0x0806.

   The total size of the LLC/SNAP header is fixed at 8-bytes.










Pittet                      Standards Track                    [Page 16]

RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000


6.1.3 HIPPI-LE header Diagram

                   HIPPI-LE header for HARP/InHARP PDUs:

      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 | 04 = IP ULP   |1|0|         000         |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                            n + 8                              |
      +-----+-+-------+-----------------------+-----------------------+
    2 |[LA] |W|M_Type |          000          |  Dest. Switch Addr    |
      +-----+-+-------+-----------------------+-----------------------+
    3 | D_A_T | S_A_T |          000          | Source Switch Addr    |
      +-------+-------+---------------+-------+-----------------------+
    4 |             00 00             |                               |
      +-------------------------------+                               |
    5 |                         Destination ULA                       |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |                               |
      +-------------------------------+                               |
    7 |                           Source ULA                          |
      +===============+===============+===============+===============+