rfc1374.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,520 行 · 第 1/5 页

   The requirements for nodes to handle address resolution messages
   depend on the means by which address resolution is implemented on the
   LAN.

   In conventional networks ARP is a distributed function. ARP requests
   are broadcast; each host may update its address mappings with any ARP
   request or reply it sees, and responds to ARP requests that contain
   its own address in the target protocol address field.  HIPPI-SC
   switches are not required to provide multicast service, although some
   do.  Even if the switches do not multicast, one or more nodes can act
   as multicast servers, receiving packets sent to the HIPPI-SC
   broadcast address and repeating them to each other node in turn.
   Either way, if multicast exists on a HIPPI-SC LAN, ARP can be a
   distributed function.  In this situation each node is required to



Renwick & Nicholson                                            [Page 22]

RFC 1374                  IP and ARP on HIPPI               October 1992


   respond correctly to address resolution requests for which it is the
   target.

   Third party ARP is a second method that does not depend on multicast.
   The switches can map the HIPPI ARP multicast address to a node that
   acts as an ARP agent, replying to ARP requests on behalf of the real
   target nodes.  Ordinary nodes never receive ARP requests or generate
   replies and never have the opportunity to update mapping tables based
   on ARP requests from other nodes, as usually happens on conventional
   networks.  Each node must request any address information it needs,
   but never has to process ARP information it doesn't need.  Under
   third party ARP a node should not receive address resolution
   requests, and each node that is not an ARP agent should ignore those
   that it does receive.

   As a third possibility, one can omit the implementation of ARP
   entirely, choosing instead to build address mapping tables in each
   node from information available to a network administrator.  Such a
   technique is implementation dependent and outside the scope of this
   memo.  It may be helpful in prototype networks without multicast
   where no ARP agent is yet implemented.  In this case, nodes are not
   required to respond to address resolution requests, but must accept
   any they may receive.

ARP Example

   Assume a HIPPI-SC switch is installed with two nodes, X and Y,
   connected.  Each node has a unique Switch Address.  Both nodes have
   access to the host data base (e.g. /etc/hosts) in which the network
   administrator has configured the network and given the two nodes IP
   addresses.  There is an ARP agent connected to a switch port that is
   mapped to the address FE0 (hex).  The ARP agent contains no mappings
   of any IP, IEEE or Switch addresses.  Both nodes know their own ULAs
   and Switch Addresses.  They want to talk to each other; each knows
   the other's IP address (from the host data base) but neither knows
   the other's ULA or Switch Address.  Node X starts:

   1.  Node X connects to FE0 and sends a piggyback ARP Request
       requesting addresses for Y:

           HIPPI-LE Message_Type is 1, AR_Request
           HIPPI-LE Destination_Switch_Address = 0
           HIPPI-LE Source_Switch_Address = X's Switch Address
           HIPPI-LE Destination_IEEE_Address = 0
           HIPPI-LE Source_IEEE_Address = X's ULA
           ARP ar$op = 1 (request)
           ARP ar$sha = X's ULA
           ARP ar$spa = X's IP Address



Renwick & Nicholson                                            [Page 23]

RFC 1374                  IP and ARP on HIPPI               October 1992


           ARP ar$tha = 0
           ARP ar$tpa = Y's IP Address

   2.  The ARP agent receives the ARP request and adds an entry for X to
       its address mapping table.  It does not know about Y, so it does
       not generate a reply.

   3.  Node X waits for a reply.  It may set a timer to retransmit the
       request periodically, but its requests will be ignored until node
       Y sends an ARP request.

   4.  Node Y connects to FE0 and sends an ARP request requesting
       addresses for X:

           HIPPI-LE Message_Type is 1, AR_Request
           HIPPI-LE Destination_Switch_Address = 0
           HIPPI-LE Source_Switch_Address = Y's Switch Address
           HIPPI-LE Destination_IEEE_Address = 0
           HIPPI-LE Source_IEEE_Address = Y's ULA
           ARP ar$op = 1 (request)
           ARP ar$sha = Y's ULA
           ARP ar$spa = Y's IP Address
           ARP ar$tha = 0
           ARP ar$tpa = X's IP Address

   5.  The ARP agent receives Y's request and adds an entry for Y to its
       address mapping table.  It knows about the target node, X, so it
       connects to Y (using the Source_Switch_Address given in the
       request) and sends an ARP Reply:

           HIPPI-LE Message_Type is 2, AR_Reply
           HIPPI-LE Destination_Switch_Address = Y's Switch Address
           HIPPI-LE Source_Switch_Address = X's Switch Address
           HIPPI-LE Destination_IEEE_Address = Y's ULA
           HIPPI-LE Source_IEEE_Address = X's ULA
           ARP ar$op = 2 (reply)
           ARP ar$sha = X's ULA
           ARP ar$spa = X's IP Address
           ARP ar$tha = Y's ULA
           ARP ar$tpa = Y's IP Address

   6.  Node Y receives the ARP reply and builds its address mapping
       table entry for Node X.

   7.  Node Y connects to node X and transmits an IP packet with the
       following information in the HIPPI-LE header:

           HIPPI-LE Message_Type is 0, AR_Data



Renwick & Nicholson                                            [Page 24]

RFC 1374                  IP and ARP on HIPPI               October 1992


           HIPPI-LE Destination_Switch_Address = X's Switch Address
           HIPPI-LE Source_Switch_Address = Y's Switch Address
           HIPPI-LE Destination_IEEE_Address = X's ULA
           HIPPI-LE Source_IEEE_Address = Y's ULA

   8.  Node X receives the IP packet.  Since the ARP agent now knows
       about node Y, node X can retransmit its ARP request (repeating
       step 1) and receive an ARP reply:

           HIPPI-LE Message_Type is 2, AR_Reply
           HIPPI-LE Destination_Switch_Address = X's Switch Address
           HIPPI-LE Source_Switch_Address = Y's Switch Address
           HIPPI-LE Destination_IEEE_Address = X's ULA
           HIPPI-LE Source_IEEE_Address = Y's ULA
           ARP ar$op = 2 (reply)
           ARP ar$sha = Y's ULA
           ARP ar$spa = Y's IP Address
           ARP ar$tha = X's ULA
           ARP ar$tpa = X's IP Address

   Address resolution is now complete for both nodes.

   If there had been a multicast facility instead of the ARP agent in
   the configuration, the target nodes themselves would have received
   the requests and responded to them in the same way the ARP agent did.

Discovery of One's Own Switch Address

   The ARP example above assumed that each node had prior knowledge of
   its own switch address.  This may be manually configured, by means
   that are outside the scope of this memo, when each node is connected
   to the switch.  If a multicast capability exists, the node may
   discover its own address automatically when it starts up, using a
   protocol defined in HIPPI-LE.

   In the self-address discovery protocol, a node connects to a
   multicast address and sends a HIPPI-LE message containing its own
   ULA.  It receives a multicast copy of its own message, and learns its
   own switch address from the destination address field of the received
   I-field.

   HIPPI-LE self address resolution uses the same HIPPI-LE message
   format described in "ARP and RARP Message Format," above, with the
   AR_S_Request and AR_S_Response message type codes and no piggybacked
   ULP data.  The HIPPI-LE header contents for the request are:

       Message_Type is 3, AR_S_Request
       Destination_Address_Type = 0 (undefined)



Renwick & Nicholson                                            [Page 25]

RFC 1374                  IP and ARP on HIPPI               October 1992


       Destination_Switch_Address = 0 (unknown)
       Source_Address_Type = 0 (undefined)
       Source_Switch_Address = 0 (unknown)
       Destination_IEEE_Address = my ULA
       Source_IEEE_Address = my ULA

   There is no D2 data; the packet contains only the HIPPI-FP header and
   D1_Area containing the HIPPI-LE header.

   The node that wants to discover its address connects to the multicast
   address for this purpose (hex FE0 in HIPPI-SC) and transmits the
   request packet.  What happens next depends on the particular network:

   With multicast:

      The node receives its own request and can learn its own switch
      address from the I-field it receives.  This is the only time a
      node should use an address from a received I-field.

   With an ARP agent:

      The node may receive an AR_S_Response message with its own ULA in
      the Destination_IEEE_Address field and its own switch address in
      the Destination_Switch_Address field.  This address may be
      different from the address contained in the I-field, and should be
      used instead.

   The ARP agent response alternative requires that the agent have prior
   knowledge of the node's location and ULA through some process not
   specified by this memo.  The node may receive both its request and
   the agent's response if both an ARP agent and multicast are active.
   In this case the address it learns from the I-field is later replaced
   by the address given by the ARP agent in the response.  Agents may
   assign new addresses to nodes and inform them by sending unsolicited
   AR_S_Response messages.  Any node whose switch address is updated in
   this way should invalidate the switch addresses it has saved for
   other nodes, and use ARP to rediscover them.

   If the node reacts correctly to either the multicast request or
   agent-generated response, it can discover its address without having
   to know whether or not an ARP agent is active.  The full procedure
   is:

   1.  Transmit the AR_S_Request







Renwick & Nicholson                                            [Page 26]

RFC 1374                  IP and ARP on HIPPI               October 1992


   2.  When a connection arrives, accept it and save the I-field for
       later analysis.

   3.  Receive the message and look at the HIPPI-LE header.  If the
       message is Message Type AR_S_Request, analyze the I-field to
       discover the node's own switch address.  HIPPI-SC I-field formats
       suggest the following:

          if bit 25 == 1
                  Address type is HIPPI-SC logical address.
                  if bit 27 == 1
                          take address from bits 23-12
                  else
                          take address from bits 11-00
                  endif
          else
                  Address is unusable (source route)
          endif

       This is a one-time operation.  Once the node knows an address for
       itself, it should not take any new address from a received I-
       field.

   4.  If a message of type AR_S_Response arrives and the
       Destination_IEEE_Address field contains the node's own ULA, take
       the new switch address from the Destination_Switch_Address field
       and its type from the Destination_Address_Type field.

   5.  The node should invalidate its ARP tables when an AR_S_Response
       changes its own switch address, to force retransmission of ARP
       requests containing its new address to all the remote nodes with
       which it communicates.


Path MTU Discovery

   RFC 1191 [13] describes the method of determining MTU restrictions on
   an arbitrary network path between two hosts.  HIPPI nodes may use
   this method without modification to discover restrictions on paths
   between HIPPI-SC LANs and other networks.  Gateways between HIPPI-SC
   LANs and other types of networks should implement RFC 1191.

Channel Data Rate Discovery

   HIPPI exists in two data rate options (800 megabit/second and 1600
   megabit/second).  The higher data rate is achieved by making the
   HIPPI 64 bits parallel instead of 32, using an extra cable containing
   32 additional data bits and four parity bits.  HIPPI-SC switches can



Renwick & Nicholson                                            [Page 27]

RFC 1374                  IP and ARP on HIPPI               October 1992


   be designed to attach to both.  Source and Destination HIPPI