rfc1029.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 950 行 · 第 1/3 页

   must exist on this LAN, otherwise it must be remote.

   With the Transparent scheme, the first time a newly booted host
   'speaks' it will be looking for addressing information (probably
   using BOOTSTRAP [1], RARP [2] or ARP [5]).  Accordingly, the Bridge
   will detect these respective requests and be in a position to perform
   operations on the address parameters.  The current approach in
   Transparent Subnetting is that before any such requests can be
   cascaded by the Bridge to an adjacent LAN, that Bridge will place its
   interface address parameters into the source address fields, thus
   acting as the AGENT.  Therefore, this Bridge will 'see' either



Parr                                                            [Page 6]

RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988


   packets arriving from the remote Bridge address, or local packets.
   By virtue of the RARP/ARP operation, which hosts perform when they
   first come up, any hi-level packets received on to the network not
   having the bridge address, and not having a mapping in the cache for
   that LAN, can be considered as being remote.

   Currently, there is a move toward the Transparent subnet proposal
   originally described by Postel [7].  This has been due mainly to
   practical problems of incompatible implementations from different
   vendors, and the restrictions that the Explicit address space place
   on the adaptability of the system to change (class C addresses are
   not flexible enough for the Explicit scheme).  It is also the opinion
   of the Author of this paper that the Agent technique adopted by the
   Bridges could have shortcomings in a dynamic environment which would
   be detrimental to its operation; for example, where the bridges
   themselves relocate or crash, or in the management of the "Agent For
   Who" cache at the bridge.  Insofar as Loop Resolution and
   SelfStabilization after failure are Bridge problems that need to be
   addressed, it is strongly felt their satisfactory solution will be
   supported by elimination of the Agent technique [13].

BRIDGE OPERATIONS

   Referring to figure 1, assume that at some stage during its
   processing [E1H3] wishes to communicate with [E2H19].  [E1H3] obtains
   knowledge of the Internet address of [E2H19] from its translation
   cache, but will not require the knowledge that [E2H19] exists on a
   completely different subnet.  [E1H3] calls its Internet Module to
   transmit the packet.  As detailed, the usual procedure of passing
   control to its ARM is performed in an attempt to obtain a
   translation.  If we assume that [E1H3], and [E2H19] have not talked
   before, the ARM in [E1H3] will not be able to resolve the addresses
   on the first attempt.

   In such a case, an ARREQ packet is assembled and broadcast to all
   hosts on the network [E1].  The packet traverses the cable and is
   eventually picked up by the (B1) Bridge Address Resolution Module
   (BARM), whereupon it determines whether or not it should intervene in
   the request.  If the target is determined as remote (i.e., having no
   match in the local cache), the BARM examines its Global Translation
   Cache (GTC) to determine if it has an entry for <protocol,[E2H19]>.
   Should a mapping be obtained at the Bridge, there is no need for the
   broadcast REQUEST packet to be cascaded on to the remote network
   [E2].  It is therefore assumed that the entries in the GTC reflect
   the most current addressing information.  A match thus obtained, the
   original ARREQ packet buffer is adapted as required and returned
   directly to [E1H3] via the Bridges hardware interface IFE1.




Parr                                                            [Page 7]

RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988


   On the other hand, should the Bridges' GTC have no information on
   [E2H19], the BARM would have to perform the following steps:

      1.  drop the current ARREQ from [E1H3],

      2.  create its own ARREQ using the Bridge source addresses
          and copy the target_internet_addr from the original
          [E1H3] ARREQ packet,

      3.  broadcast the ARREQ on network E2 via network interface
          IFE2, and go into a timeout awaiting a REPLY.

   Should this timeout period expire, a number of retries will be
   permitted under control of the BARM.  Alternatively, if a REPLY is
   received within the timeout interval, then the BARM will update its
   GTC.  The ARM of [E1H3] next will attempt to transmit another ARREQ,
   but this time a mapping will be obtained at the BARM'S GTC, and the
   appropriate REPLY will be returned.

   Part 1 has described the state of the art of the behaviour of Address
   Resolution.  Part 2 now extends the study to the more serious problem
   of rebooting hosts in a multi-LAN system of Ethernets, and the
   effects such changes have on the integrity of state information held
   in ARP caches and routing tables.

                                 PART 2

THE CAPTURE OF REBOOTS

   Because Address Resolution packets are broadcast, all hosts on the
   connecting cable including the Transparent Bridge will pick them up
   and determine what they are.  Referring to figure 1, it may well be
   the case that a host on E1 wishes to communicate with a fellow host
   on the same physical ether.  Hence, if Hx wishes to talk to Hw on the
   same ether, but has not done so previously, it will broadcast an
   Address Resolution packet in the normal fashion.  The Bridge will
   also 'see' the packet as it passes by, and will act as described
   above, unless that is, there is some method of preventing it doing
   so; there is no point in the Bridge invoking its ARM, and wasting
   processing time if the problem is going to be resolved locally.

   It may occur however, that H1 wants to communicate with H5.  If
   however, H5 has not talked with anyone before (i.e., it has been
   "dormant"), H1 will issue an ARREQ.  The Bridge will not know that H5
   is local because it won't have been entered in the local address
   cache from previous conversations.  To avoid broadcasting an ARREQ to
   all networks/subnets, one way around this problem is to set up the
   contents of the local cache at Bridge startup time.  Therefore, the



Parr                                                            [Page 8]

RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988


   Bridge will already know not to intervene.  Thus, if the Bridge (with
   2 nets) finds that a particular IP destination address is not in the
   local cache of interface 1, it would have to examine its GTC and scan
   it for a mapping.  Should no mapping be obtained at interface 2, one
   of two possibilities exist:

        1. the target host doesn't exist locally

        2. the caches are corrupt (the eventuality of this should
           be negligible!)

   If it is assumed that each of the translation caches contains have
   the most recent addressing information regarding its own domain of
   the network then, in this example, if the Bridge does not get a
   mapping at the GTC it would appear that the host must exist remotely
   from E1, and E2.

   Such a conclusion would ignore cases in which a host unplugs from a
   particular hardware interface and plugs into another hardware
   interface, or where logical names are reassigned to different
   interfaces due to host user change.  Either of these events could
   happen had the host being accessed on E2, which would mean that a
   REBOOT has taken place.

   Anticipating these possiblities local caches are essential.  In
   normal operation, the Bridge will process and forward IP packets
   received from one network, and destined for another.  If the Bridge
   picks up an ARREQ, it will first look for a mapping in its GTC before
   discarding the original ARREQ, and transmitting its own to the remote
   network.  In any case, the Bridge will always examine the local cache
   entries at the receiving interface, so that it may determine if the
   target address is local or remote.  When the Bridge first scans the
   local cache, it does so with the source IP address as the key.  If no
   mapping is retrieved, it then scans the GTC with the same key.
   Should a mapping now be obtained, it remains for the Bridge to insert
   the source IP into the local cache, where it has either been
   previously deleted or corrupted.

   However, if the source IP exists in the respective local cache, the
   validity of the source Ethernet address should also be verified by
   examining the respective entry in the GTC.  A scan of the GTC is then
   performed with <protocol,source_prot_addr> as the key.  If a mapping
   is retrieved, the respective <et_addr> should be checked against the
   source Ethernet address in the packet header.  If the addresses do
   not match, then we have uncovered a Hardware Reboot condition (i.e.,
   a change in Ethernet ID).  On the other hand, should the scan of the
   GTC with <protocol,source_prot_addr> fail to obtain a mapping, then
   the Bridge would scan the GTC with the current Ethernet address in



Parr                                                            [Page 9]

RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988


   the packet header.  If this obtains a mapping, then a Protocol Reboot
   condition (i.e., change in logical ID) has been detected.

   In the next section, the implications of these forms of 'Reboot' are
   discussed.

REBOOT SCENARIO

   In normal operation, packets will uneventfully traverse each subnet
   either as complete Internet packets, broadcast ARREQ's, or direct
   ARREP's.  The Bridge attached to each subnet will 'hear', and 'see'
   all packets as they travel past its connected interfaces.  Because of
   the existence of the local caches at each interface, the Bridge can
   decide whether or not to intervene.  In general circumstances, each
   host on the Catenet will have a translation cache containing
   <protocol,source_prot_addr,source_et_addr> entries for all packets it
   has observed.  Most of these entries will have been due to processing
   ARREQ packets, which were broadcast, and by receiving REPLY packets.
   In accordance with the foregoing , the Bridge will have a cache
   attached to each subnet interface containing entries for protocol
   addresses.

   Within the Bridge's Global Translation Cache (GTC) will be entries of
   all <protocol,source_prot_addr,source_hrd_addr> triplets relating to
   valid hosts which have been recognised.  If we assume that we have
   just connected up a Catenet such as that illustrated in figure 1,
   then at power-up no stations will have knowledge about their
   neighbours.  If the Bridges are to remain transparent, the
   translation caches at each host will be totally empty.  The only
   addressing details that will be in existence will be the protocol
   addresses stored in the local caches of the Bridges.

   The hosts subsequently begin to run applications and will want to
   communicate with one another.  The first ARREQ is broadcast on the
   respective subnet and all hosts, including the Bridge's interface to
   the subnet, will pick it up and store the details.  If, for example,
   Hx issues an ARREQ for Hq, the Bridge will not intervene since there
   is no need (providing no reboot has occurred at Hq).  However, if Hx
   wishes to talk with Hz, B1 will determine that the target IP in the
   respective ARREQ does not exist in the local cache of IFE1, so it
   will examine the GTC, with the <protocol,target_prot_addr> of Hw as
   the key.

   It is assumed that there will be a timeout mechanism in operation at
   the source of any packet.  In addition, the Bridge may also place the
   target address in a 'search list' of currently sought hosts, so as to
   prevent ARREQs from different sources being cascaded for the same
   target.  Under these conditions, Hx may re-issue its original ARREQ,



Parr                                                           [Page 10]

RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988


   but will be ignored until the host Hw has replied to the ARREQ
   transmitted by the Bridge.

NORMAL RUNNING STATE

   Assuming that a few ARP's have been issued, IP packets will start
   traversing the Catenet with full addressing information.  Again, the
   Bridges will 'see' all the packets.  If we extend the situation one
   step further, and assume that several conversations have taken place
   across the Catenet, there will be entries in the translation caches
   of the hosts concerned, regarding the
   <protocol,target_prot_addr,target_hrd_addr> triplets of those hosts
   with which the conversations took place.  The Bridges also, will have
   details in their GTC's for packets which they cascaded.

   If a host is relocated, any connections initiated by that host will
   still work, provided that its own translation cache is cleared when
   it does physically move.  However, any connections subsequently
   initiated to it by other hosts on the Catenet will have no particular
   reason to know to discard their old translation for that host.
   Ideally, 48 bit Ethernet addresses will be unique and fixed for all
   time.

RECOGNITION OF THESE REBOOT CONDITIONS

   With reference to figure 1, assume that for some reason a fault
   occurs on the hardware interface of <E1He>.  The result of this is
   that a new interface is installed with a newly acquired hardware
   address.  When <E1He> is powered up, the previous contents of its
   translation cache are cleared and it has no recollection of local, or
   remote host addresses.  Accordingly, <E1He> begins to issue ARREQ's
   to hosts it requires.  Whenever <E1He> transmits its first ARREQ, it
   could be termed a 'HELLO PACKET', since everyone on the subnet can
   pick up the packet, and store the relevant information in their
   translation caches.  Within hosts, a mapping will be found on the old
   <protocol,source_prot_addr> pair, and the current <et_addr> of the
   packet header will replace whatever is entered in the translation
   cache.

   At this point it would be easy for each host with an entry to
   recognise the Hardware Reboot situation and inform the subnet with a
   respective broadcast reboot packet.  But allowing such a procedure
   would be extremly inefficient on the broadcast medium, and would
   drastically outweigh any improvements in performance which might be
   obtained in the long term.  In any case, given the fact that the
   ARREQ is broadcast, all stations on the subnet will recognise the
   reboot.  The important point to consider is the effect such a reboot
   will have on subsequent conversations which are initiated remotely.



Parr                                                           [Page 11]

RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988


   Can redundant transmissions be thwarted before they tie up processing
   time on hosts en-route to the rebooted target?  How these
   difficulties are resolved is critical to the level of performance
   obtained in a Catenet configuration.  Since it is not optimal for
   hosts to inform the system of a reboot, it is left to the Bridge.
   Whenever the Bridge receives a packet, be it IP, or ARP, it examines
   the source address parameters in the packet header, in the hope of
   detecting any incompatibilities between them and the entries in its
   caches.  There are three distinct possibilities, namely, a difference
   in the 48 bit hardware address only, a difference in the protocol
   address, and two completely new addresses.  If an incompatibility is
   discovered, a "REBOOT" packet is constructed and issued on all remote
   interfaces containing the appropiate information, allowing Bridges to
   update their GTC's and generic hosts their ARP caches.

   The structure of the Reboot packet is as depicted in figure 2.

    0                   1                   2                   3