rfc2835.txt

RFC 的详细文档！

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

   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.





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


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

   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 the
   invalidated entry prior to transmitting any non-address resolution
   traffic to the port referred to by this entry.





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


   The client revalidates the entry by querying the HARP server.  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 another type of IEEE 802 payload as described in
   section 4.1.3 above. The HIPPI-6400 HARP SHALL support two packet
   formats, both the generic Ethernet ARP packet and the HIPPI-800 HARP
   packet format defined in [13]. HARP messages SHALL be transmitted
   with a hardware type code of 28 on non-broadcast capable hardware or
   1 in either case.

   The ar$hrd field SHALL be used to differentiate between the two
   packet formats. The reply SHALL be in the format of the request.

6.1 Generic IEEE 802 ARP Message Format

   This is the ARP packet format used by conventional IEEE 802 networks
   (i.e. Ethernet, etc). The packet format is described in RFC-826 [14]
   and is given here only for completeness purpose.

     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$hln   8 bits  byte length of each hardware address
     ar$pln   8 bits  byte length of each protocol address
     ar$op   16 bits  opcode (ares_op$REQUEST | ares_op$REPLY)
     ar$sha  48 bits  Hardware address of sender of this packet
     ar$spa  32 bits  Protocol address of sender of this packet
     ar$tha  48 bits  Hardware address of target of this
     ar$tpa  32 bits  Protocol address of target.

   Where:
     ar$hrd  - SHALL contain 1. (Ethernet)

     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).

     ar$hln  - SHALL contain 6.

     ar$pln  - SHALL contain 4.




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


     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK

     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.

     ar$sha  - in requests and NAKs it SHALL contain the requester's ULA
               In replies it SHALL contain the target port's ULA.

     ar$spa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.

     ar$tha  - in requests and NAKs it SHALL contain the target's ULA
               if known, otherwise zero.
               In other replies it SHALL contain the requester's ULA.

     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.
               In other replies it SHALL contain the requester's
               IP address.























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


   |31             |23             |15             |7             0|
   +---------------+---------------+---------------+---------------+-----
 0 |                                                               |
   |         D_ULA                 +-------------------------------+HIPPI
 1 |                               |                               |6400
   +-------------------------------+            S_ULA              |MAC
 2 |                                                               |hdr
   +---------------------------------------------------------------+
 3 |                             M_len                             |
   +---------------+---------------+---------------+---------------+-----
 4 |      AA       |       AA      |       03      |      00       |IEEE
   +---------------+---------------+---------------+---------------+802
 5 |       00      |       00      |  Ethertype  =  0x0800 = 2048  |LLC/
   +------------+------------------+-------------------------------+SNAP
 6 |            hrd (1)            |           pro (2048)          |
   +---------------+---------------+---------------+---------------+
 7 |     hln (6)   |   phl (4)     |             op (ar$op)        |
   +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
 8 |              Source Hardware Address  0 - 3                   |
   +-------------------------------+-------------------------------+
 9 | Source ULA bytes 4 - 5        | Source IP Address bytes 0 - 1 |
   +-------------------------------+-------------------------------+
10 | Source IP Address bytes 2 - 3 |    Target ULA bytes 0 - 1     |
   +-------------------------------+-------------------------------+
11 |           Target Hardware Address (ULA) bytes 2 - 5           |
   +---------------------------------------------------------------+
12 |                         Target IP Address                     |
   +---------------+---------------+---------------+---------------+
13 |     FILL      |     FILL      |      FILL     |     FILL      |
   +---------------+---------------+---------------+---------------+
14 |     FILL      |     FILL      |      FILL     |     FILL      |
   +><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+

6.2 HIPARP Message Formats

   The HARP protocols further SHALL support the HIPARP hardware type
   (ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation code
   (ar$op) data formats as the ARP, and InARP protocols [14,7]. In
   addition, HARP makes use of an additional operation code for ARP_NAK
   introduced with [11]. The remainder of the HIPARP message format
   (defined in [13]) is different than the ARP/InARP message format
   defined in [14,7,10] and it is also different from the format defined
   in the first "IP and ARP on HIPPI" RFC-1374 [16].

   The HARP message has several fields that have the following format
   and values:





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


   Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qbytes   requester's HIPPI Hardware address
     ar$tha  xbytes   target's HIPPI Hardware address

   Where :
     ar$hrd  - SHALL contain 28. (HIPARP)

     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).

     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK

     ar$pln  - SHALL contain 4.

     ar$rln  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.

     ar$thl  - SHALL contain 10 IF this is a HIPPI-800 HW address
               ELSE, for HIPPI-6400, it SHALL contain 6.

     ar$rha  - in requests and NAKs it SHALL contain the requester's
               HW address.
               In replies it SHALL contain the target port's HW address.

     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
               address if known, otherwise zero.
               In other replies it SHALL contain the target
               port's IP address.

     ar$tha  - in requests and NAKs it SHALL contain the target's
               HW address if known, otherwise zero.

               In other replies it SHALL contain the requester's
               HW address.





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


     ar$tpa  - in requests and NAKs it SHALL contain the
               target's IP address if known, otherwise zero.