rfc2834.txt

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

      The HRAL MUST contain at least two HIPPI HW addresses identifying
      the individual HARP service(s) that have authoritative
      responsibility for resolving HARP requests of all IP members
      located within the LIS.

      By default the first address MUST be the reserved address for
      broadcast, i.e. the address for "IP traffic conventionally
      directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The ULA
      for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF.

      It is REQUIRED that the second address be the address for
      "Messages pertaining to (the) ... address  resolution requests:
      0xFE0" [4]. The ULA for this HARP server entry is
      00:00:00:00:00:00.







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


Therefore, the HRAL entries are sorted in the following order:
  1st **  : broadcast address            (0x07000FE1 FF:FF:FF:FF:FF:FF),
  2nd **  : official HARP server address (0x07000FE0 00:00:00:00:00:00),
  3rd & on: any additional HARP server addresses will be sorted in
            decreasing order of the 12bit destination switch
            address portion of their I-Field (see section 6.2).
  ** REQUIRED

   Within the restrictions mentioned above and in Section 6.2.2, local
   administration choose address(es) for the additional HARP services
   which they will put into the HRAL.

   An example of such a list:
      1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF
      2nd entry: 0x07000FE0 00:00:00:00:00:00
      3rd entry: 0x07000001 <Alternate-HARP-server-ula>
      ...

   Manual configuration of the addresses and address lists presented in
   this section is implementation dependent and beyond the scope of this
   memo.

5. HIPPI Address Resolution Protocol - HARP

   Address resolution within the HIPPI LIS SHALL make use of the HIPPI
   Address Resolution Protocol (HARP) and the Inverse HIPPI Address
   Resolution Protocol (InHARP). HARP provides the same functionality as
   the Internet Address Resolution Protocol (ARP). HARP is based on ARP
   which is defined in RFC-826 [13]. Knowing the Internet address,
   conventional networks use ARP to discover another port's hardware
   address. HARP presented in this section further specifies the
   combination of the original protocol definitions to form a coherent
   address resolution service that is independent of the hardware's
   broadcast capability.

   InHARP is based on the original Inverse ARP (InARP) protocol
   presented in [7].  Knowing its hardware address, InARP is used to
   discover the other party's Internet address.

   This memo further REQUIRES the PIBES (see section 7 below) extension
   to the HARP protocol, guaranteeing broadcast service to upper layer
   protocols like IP.

   Internet addresses are assigned independent of ULAs and switch
   addresses.  Before using HARP, each port MUST know its IP and its
   hardware addresses. The ULA is optional but is RECOMMENDED if
   bridging to conventional networks is desired.




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


5.1 HARP Algorithm

   This section defines the behavior and requirements for HARP
   implementations on both broadcast and non-broadcast capable HIPPI-SC
   networks. HARP creates a table in each port which maps the IP address
   of each port to a hardware address, so that when an application
   requests a connection to a remote port by its IP address, the
   hardware address can be determined, a correct HIPPI-LE header can be
   built, and a connection to the port can be established using the
   correct Switch Address in the I-field.

   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.
   At each point in time there is only one authoritative HARP service.

   To select the authoritative HARP service, each port needs to
   determine if it is connected to a broadcast network.

   The port SHALL send an InHARP_REQUEST to the first address in its
   HRAL (0x07000FE1 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 sequence of 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 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.



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


   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 addresses in the HRAL in order. The
   client SHALL terminate the registration phase and transition into the
   operational phase, either when it receives its own InHARP_REQUEST or
   when it receives an InHARP_REPLY from at least one of the HARP
   servers and when it has determined the authoritative HARP service as
   described in section 5.1.1.

   When ports are initiated they send an InHARP_REQUEST to the
   authoritative address as described in section 5.1.2. The first
   address to be tried will be the broadcast address "0x07000FE1
   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.

   In the second case, the port SHALL choose the next address in the
   HRAL as a candidate for a authoritative address and send an
   InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).

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

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





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


   If the client determines it is connected to a non-broadcast capable
   network then the client SHALL continue to retry each non-broadcast
   HARP server address in the HRAL at least once every 5 seconds until
   one of these two termination criteria are met for each 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-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, then 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-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 which contains the IP to HW
   address mapping of IP members by sending HARP_REQUESTS to the
   authoritative address in the HRAL and receiving 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 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 (if non-zero), is in the ULA part of the Target
      Hardware Address field (ar$tha) of the message.





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


   3. The port's switch address is in the Target Switch Address field of
      Target Hardware Address field (ar$tha) of the message (see section
      6.2.2).

   4. The port is a HARP server.

   NOTE: It is RECOMMENDED that all HARP servers run on a ports which
   each have 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  [7].)

   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.2 and
      5.6). All InHARP_REPLY messages SHALL be used by the client to
      build or refresh its HARP table entries.  (Refer to Section 7,
      "Protocol Operation" in [7].)





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