rfc2835.txt

RFC 的详细文档！

   If all switches in the LIS support broadcast, then the source address
   in the reply will be the target's source address.  If all switches in
   the LIS do not support broadcast, then a HARP server MUST be used to
   provide the address resolution service, and the source address in the
   reply will be the HARP server's source address.

5.1 HARP Algorithm

   This section defines the behavior and requirements for HARP
   implementations on both broadcast and non-broadcast capable HIPPI-
   6400-SC networks. HARP creates a table in each port which maps remote
   ports' IP addresses to ULAs, so that when an application requests a
   connection to a remote port by its IP address, the remote ULA can be
   determined, a correct HIPPI-6400-PH header can be built, and a
   connection to the port can be established using the ULA.

   HARP is a two phase protocol. The first phase is the registration
   phase and the second phase is the operational phase. In the
   registration phase the port detects if it is connected to broadcast
   hardware or not. The InHARP protocol is used in the registration
   phase.  In case of non-broadcast capable hardware, the InHARP
   Protocol will register and establish a table entry with the server.
   The operational phase works much like conventional ARP with the
   exception of the message format.

5.1.1 Selecting the authoritative HARP service

   Within the HIPPI LIS, there SHALL be an authoritative HARP service.
   To select the authoritative HARP service, each port needs to
   determine if it is connected to a broadcast network. At each point in
   time there is only one authoritative HARP service.

   The port SHALL send an InHARP_REQUEST to the first address in the
   HRAL (FF:FF:FF:FF:FF:FF). If the port sees its own InHARP_REQUEST,
   then it is connected to a broadcast capable network. In this case,
   the rest of the HRAL is ignored and the authoritative HARP service is
   the broadcast entry.

   If the port is connected to a non-broadcast capable network, then the
   port SHALL send the InHARP_REQUEST to all of the remaining entries in
   the HRAL. Every address which sends an InHARP_REPLY is considered to
   be a responsive HARP server. The authoritative HARP service SHALL be
   the HARP server which appears first in the HRAL.

   The order of addresses in the HRAL is only important for deciding
   which address will be the authoritative one. On a non-broadcast
   network, the port is REQUIRED to keep "registered" with all HARP
   server addresses in the HRAL (NOTE: not the broadcast address since



Pittet                      Standards Track                    [Page 12]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


   it is not a HARP server address). If for instance the authoritative
   HARP service is non-responsive,  then the port will consider the next
   address in the HRAL as a candidate for the authoritative address and
   send an InHARP_REQUEST.

   The authoritative HARP server SHOULD be considered non-responsive
   when it has failed to reply to: (1) one or more registration requests
   by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs
   in the last 120 seconds or (3) if an external agent has detected
   failure of the authoritative HARP server. The details of such an
   external agent and its interaction with the HARP client are beyond
   the scope of this document. Should an authoritative HARP server
   become non-responsive, then the registration process SHOULD be
   restarted. Alternative methods for choosing an authoritative HARP
   service are not prohibited.

5.1.2  HARP registration phase

   HARP clients SHALL initiate the registration phase by sending an
   InHARP_REQUEST message using the HRAL addresses in order. The client
   SHALL terminate the registration phase and transition into the
   operational phase, when either: (1) it receives its own
   InHARP_REQUEST, or (2) when it receives an InHARP_REPLY from at least
   one of the HARP servers and it has determined the authoritative HARP
   service as described in 5.1.1.

   When ports are initiated they send an InHARP_REQUEST to the
   authoritative HRAL address. The first address to be tried will be the
   broadcast address "FF:FF:FF:FF:FF:FF". There are two outcomes:

   1. The port sees its own InHARP_REQUEST: then the port is connected
      to a broadcast capable network. The first address becomes, and
      remains, the authoritative address for the HARP service.

   2. The port does not receive its InHARP_REQUEST: then the port is
      connected to a non-broadcast capable network.

      The port SHALL choose the next address in the HRAL as a candidate
      for a HARP server and send an InHARP_REQUEST to that address:
      (00:10:3B:FF:FF:E0).

      The port SHALL continue to retry each non-broadcast HARP server
      address in the HRAL at least once every 5 seconds until one of the
      following termination criteria are met for each address.

      a. If the port receives its own message, then the port itself is
         the HARP server and the port is REQUIRED to provide broadcast
         services using the PIBES (see section 7).



Pittet                      Standards Track                    [Page 13]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


      b. If the port receives an InHARP_REPLY, then it is a HARP client
         and not a HARP server. In both cases, the current candidate
         address becomes the authoritative HARP service address.

   InHARP is an application of the InARP protocol for a purpose not
   originally intended.  The purpose is to accomplish registration of
   port IP address mappings with a HARP server if one exists or detect
   hardware broadcast capability.

   If the HIPPI-6400-SC LAN supports broadcast, then the client will see
   its own InHARP_REQUEST message and SHALL complete the registration
   phase. The client SHOULD further note that it is connected to a
   broadcast capable network and use this information for aging the HARP
   server entry and for IP broadcast emulation as specified in sections
   5.4 and 5.6 respectively.

   If the client doesn't see its own InHARP_REQUEST it SHALL await an
   InHARP_REPLY before completing the registration phase. This will also
   provide the client with the protocol address by which the HARP server
   is addressable.  This will be the case when the client happens to be
   connected to a non-broadcast capable HIPPI-6400-SC network.

5.1.3 HARP operational phase

   Once a HARP client has completed its registration phase it enters the
   operational phase. In this phase of the protocol, the HARP client
   SHALL gain and refresh its own HARP table information about other IP
   members by sending of HARP_REQUESTs to the authoritative address in
   the HRAL and by receiving of HARP_REPLYs. The client is fully
   operational during the operational phase.

   In the operational phase, the client's behavior for requesting HARP
   resolution is the same for broadcast or non-broadcast HIPPI-6400-SC
   switched networks.

   The target of an address resolution request updates its address
   mapping tables with any new information it can find in the request.
   If it is the target port it SHALL formulate and send a reply message.
   A port is the target of an address resolution request if at least ONE
   of the following statements is true of the request:

   1. The port's IP address is in the target protocol address field
      (ar$tpa) of the HARP message.

   2. The port's ULA, is in the ULA part of the Target Hardware Address
      field (ar$tha) of the message.

   3. The port is a HARP server.



Pittet                      Standards Track                    [Page 14]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


   NOTE: It is REQUIRED to have a HARP server run on a port that has a
   non-zero ULA.

5.2 HARP Client Operational Requirements

   The HARP client is responsible for contacting the HARP server(s) to
   have its own HARP information registered and to gain and refresh its
   own HARP entry/information about other IP members. This means, as
   noted above, that HARP clients MUST be configured with the hardware
   address  of the HARP server(s) in the HRAL.

   HARP clients MUST:

   1. When an interface is enabled (e.g. "ifconfig <interface> up" with
      an IP address) or assigned the first or an additional IP address
      (i.e. an IP alias), the client SHALL initiate the registration
      phase.

   2. In the operational phase the client MUST respond to HARP_REQUEST
      and InHARP_REQUEST messages if it is the target port.  If an
      interface has multiple IP addresses (e.g., IP aliases) then the
      client MUST cycle through all the IP addresses and generate an
      InHARP_REPLY for each such address. In that case an InHARP_REQUEST
      will have multiple replies. (Refer to Section 7, "Protocol
      Operation" in RFC-1293 [5].)

   3. React to address resolution reply messages appropriately to build
      or refresh its own client HARP table entries. All solicited and
      unsolicited HARP_REPLYs from the authoritative HARP server SHALL
      be used to update and refresh its own client HARP table entries.

      Explanation: This allows the HARP server to update the clients
      when one of server's mappings change, similar to what is
      accomplished on Ethernet with gratuitous ARP.

   4. Generate and transmit InHARP_REQUEST messages as needed and
      process InHARP_REPLY messages appropriately (see section 5.1.3 and
      5.6). All InHARP_REPLY messages SHALL be used to build/refresh its
      client HARP table entries.  (Refer to Section 7, "Protocol
      Operation" in [5].)

   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.



Pittet                      Standards Track                    [Page 15]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


   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 showed that the underlying network supports
   broadcast, then the refresh sequence is 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-6400 connections from other HIPPI-
   6400 ports. The HARP server expects an InHARP_REQUEST as the first
   message from the client. A server examines the IP address, the
   hardware address of the InHARP_REQUEST and adds or updates its HARP
   table entry <IP address(es), ULA> as well as the time stamp.

   A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on
   the information which it has in its table. The HARP server replies
   SHALL contain the hardware type and corresponding format of the
   request (see also sec. 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.

      +---+----------+----------+------------+---------------------+
      | # | 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



Pittet                      Standards Track                    [Page 16]

RFC 2835            IP and ARP over HIPPI-6400 (GSN)            May 2000


      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

      The result will be a table with: IPb <-> HWa <-> IPb  If IPb was
      the only IP address referred to by the HWb entry, then delete the
      HWb entry.

   3: move IP address to a new interface