rfc1029.txt

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

Network Working Group                                           G. Parr
Request For Comments: 1029                         University of Ulster
                                                               May 1988


        A MORE FAULT TOLERANT APPROACH TO ADDRESS RESOLUTION FOR
                    A MULTI-LAN SYSTEM OF ETHERNETS

STATUS OF THIS MEMO

   This memo discusses an extension to a Bridge Protocol to detect and
   disclose changes in neighbouring host address parameters in a Multi-
   LAN system of Ethernets.  The problem is one which is appearing more
   and more regularly as the interconnected systems grow larger on
   Campuses and in Commercial Institutions.  This RFC suggests a
   protocol enhancement for the Internet community, and requests
   discussion and suggestions for improvements.  Distribution of this
   memo is unlimited.

ABSTRACT

   Executing a protocol P, a sending host S decides, through P's routing
   mechanism, that it wants to transmit to a target host T located
   somewhere on a connected piece of 10Mbit Ethernet cable which
   conforms to IEEE 802.3.  To actually transmit the Ethernet packet, a
   48 bit Ethernet/hardware address must be generated.  The addresses
   assigned to hosts within protocol P are not always compatible with
   the corresponding Ethernet address (being different address space
   byte orderings or values).  A protocol is presented which allows
   dynamic distribution of the information required to build tables that
   translate a host's address in protocol P's address space into a 48
   bit Ethernet address.  An extension is incorporated to allow such a
   protocol to be flexible enough to exist in a Transparent Bridge, or
   generic Host.  The capability of the Bridge to detect host reboot
   conditions in a multi-LAN environment is also discussed, emphasising
   particularly the effect on channel bandwidth.  To illustrate the
   operation of the protocol mechanisms, the Internet Protocol (IP) is
   used as a benchmark [6], [8].  Part 1 presents an introduction to
   Address Resolution, whilst Part 2 discusses a reboot detection
   process.

DEFINITIONS:

      CATENET: a group of IP networks linked together
      IP     : Internet Protocol






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


                                 PART 1

INTRODUCTION

   In the Ethernet, while all packets are broadcast, the hardware
   interface selects only those with either the explicit hardware
   broadcast address or the individual hardware address of this
   interface.  Packets which do not have one of these two addresses are
   rejected by the interface and do not get passed to the host software.
   This saves a great deal of otherwise wasted effort by the host
   software having to examine packets and reject them.  If the interface
   hardware selected packets to pass to the host software by means of
   the protocol address, there would be no need for any translation from
   protocol to Ethernet address.  Although it is very important to
   minimize the number of packets which each host must examine, so
   reducing especially needless inspections, use of the hardware
   broadcast address should be confined to those situations where it is
   uniquely beneficial.  Perhaps if one were designing a new local
   network one could eliminate the need for an address translation, but
   in the real world of existing networks it fills a very important
   purpose.  A rare use of the broadcast hardware address, which avoids
   putting any processing load on the other hosts of the Ethernet, is
   where hosts obtain the information they need to use the specific and
   individual hardware addresses to exchange most of their packets.

REASONING BEHIND ADDRESS RESOLUTION

   The process of converting from the logical host address to the
   physical Ethernet address has been termed ADDRESS RESOLUTION, and has
   prompted research into a method which can be easily interfaced,
   whilst at the same time remaining portable.

   The Ethernet requires 48 bit addresses on the physical cable [11] due
   to the fact that the manufacturers of the LAN interface controllers
   assign a unique 48 bit address during production.  Of course, Network
   Managers do not want to be bothered using this address to identify
   the destination at the higher-level.  Rather, they would prefer to
   assign their logical names to the hosts within their supervision, and
   allow some lower level protocol to perform a resolving operation.
   Most of these logical protocol addresses are not 48 bits long, nor do
   they necessarily have any relationship to the 48 bit address space.

   For example, IP addresses have a 32 bit address space [6], thus
   giving rise to the need to distribute dynamically the correspondences
   between a <PROTOCOLTYPE,PROTOCOL-ADDRESS> pair, and a 48 bit Ethernet
   address.





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


EXAMPLE ARP OPERATION

   Here is a review of the operation of ARP as defined in RFC-826 [5].
   Let hosts X and Y exist on the same Ethernet cable.  They have
   physical Ethernet addresses EA(X), and EA(Y), and DoD Internet
   addresses IPA(X), and IPA(Y).  Let the Ethernet type of Internet be
   ET(IP).  Host X begins an application, and sooner or later wishes to
   communicate an Internet packet to host Y.  Host X has knowledge of
   the Internet address of Y, i.e., (IPA(Y)), and informs the lower
   level that it wishes to talk to IPA(Y).  The lower-level subsequently
   consults the ARP Module (ARM) to convert <ET(IP),IPA(Y)> into a 48
   bit Ethernet address but because X has not talked to Y previously, it
   does not have this information in its Translation Cache (TC).  It
   discards (or queues) the Internet packet, and creates a new Address
   Resolution packet with:

       PACKET FIELD             VALUE ASSIGNED

        HRDTYP                   ETHERNET

        PROTYP                   ET(IP)

        HRDLEN                   length (EA(X))

        PROTLEN                  length (IPA(X))

        ARPOPC                   REQUEST

        SOURCE HWR               EA(X)

        SOURCE PROT              IPA(X)

        TARGET HWR               don't know

        TARGET PROT              IPA(Y)

   It then broadcasts this packet to all hosts on the connecting cable.
   Host Y picks up this packet and determines that it understands the
   hardware type (Ethernet), that it speaks the indicated protocol
   (Internet), and that the packet is for it, that is, TARGET PROTOCOL
   ADDRESS = IPA(Y).  Replacing any previous entry, it enters the
   information that <ET(IP),IPA(X) translates to EA(X).  It then learns
   that this is an ARREQ packet, so it swaps fields, placing EA(Y) in
   the new sender Ethernet address field SOURCE HARDWARE ADDRESS, EA(X)
   as TARGET HARDWARE ADDRESS, IPA(X) as TARGET PROTOCOL ADDRESS, IPA(Y)
   as SOURCE PROTOCOL ADDRESS, and sets the opcode to REPLY.  The packet
   is then sent with direct routing address information to EA(X).  Thus,
   Y now knows how to send to X, but X still doesn't know EA(Y).



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


   When X receives the ARREP packet from Y, it gets the address
   information into its translation cache ET(IP),IPA(Y)>-->EA(Y),
   notices that it is a REPLY, and discards the packet (i.e., disposes
   of the dynamic packet buffer).  However, if the original Internet
   Module packet had been queued, it could have been accessed and given
   the full addressing information from the translation cache.
   Alternatively, had it been discarded, the higher level would have
   succeeded on a subsequent attempt, and the Internet packet would be
   transmitted immediately.

OBTAINING GREATER NETWORKING RANGE

   There are many benefits to be gained in dividing a large multiuser
   network into smaller, more manageable networks.  These include : Data
   Security; Overall Network Reliability; Performance Enhancement; not
   to mention the most obvious: Greater Networking Range.  In some
   network technologies, cable length may be stipulated not to exceed a
   certain range due to electrical limitations.  By installing a Bridge,
   this restriction is effectively eliminated.  An important
   consideration is the effect the induced Bridge delays will have on
   the protocol timeouts in operation on each LAN/Subnet.  Careful
   analysis of upper bounds on timeouts would have to be made in order
   to gain full benefit from the increased range.  In the case of
   Ethernet the following system parameters exist [11], [12]:

        - the bus bandwidth is 10Mbit/s

        - the maximum node-to-node cable length is 1500 m

        - the maximum point-to-point link cable length is 1000 m

        - the maximum number of repeaters between two nodes is two

        - the worst case end-to-end bus propagation delay is 22.5 us

        - the jam time after collision is 32bit

        - the minimum interframe time is 9.6 us

        - the slot size is 512 bit = 51.2 us

   Once a decision has being taken to subnet, the resulting subLANs may
   be connected by including a Bridge to link them together and
   providing a protocol which makes the collection of subnets appear as
   a single network.  The basic idea of the Bridge providing 'repeater'
   facilities would not suffice in this application.  Moreover, the
   Bridge would have to have further 'intelligence' to enable it to
   select those packets which are destined for remote networks based on



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


   the protocol address of the target host.  Thereby preventing it from
   forwarding packets needlessly that will not be accepted.  If this
   procedure was not adhered to, the channel bandwidth on the remote
   networks would be inundated with packets, causing local valid traffic
   to backoff and the efficiency of the respective networks to rapidly
   decrease.

   One problem fundamental to the operation of the Bridge is how it
   discovers on which LAN a particular host is interfaced.  If there are
   only two LANs in the system, each will have a dedicated cache at the
   Bridge, and when a packet is received at the particular interface,
   the source host's address parameters are entered in the respective
   LAN cache.  However, when we consider a Multi-LAN environment, the
   procedure becomes more complicated.

   ___
    |
    |-----h3
    |                                            E4
    |-----hq                            |-----------------------|
    |                _                             |        |
    |-----hx        | | B1                         |        |
    |---------------| |                            |        |
    |-----h1        |_|                            |        |
    |                |     h19                     |        |      ______
    |                |    |                       | |        -----|______|  B4
    |                |    |                       | | B3              |
    |-----he       |-------------------| E2       |_|                 |
    |                    |                         |                  |
    |-----h5             |                         |                  |
    |                    |                         |                  |
    |                   ---                ---     |                  |
   ---                  | |                 |-------                  |
   E1                   | | B2              |                         |
                        | |-----------------|                         |
                        ---                 |                         |
                                            |          |---------------------
                                           ---                              |
                                            E3                              |
                                                                            |
                      FIGURE 1.  A MULTI-LAN TOPOLOGY


   In the normal set-up, whenever B3 or B4 would receive a packet on E4,
   they would both update the caches on their E4 interface.  In
   addition, a method must be provided to permit B4 to distinguish
   between packets arriving on E4 from E1, E2, E3, and those which
   actually originated on E4.



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


   This is so that packets can be categorized as being of remote or
   local source and processed accordingly.  The most obvious solution is
   for each Bridge to act as an AGENT and plug in its address as the
   source of any packets it cascades to a remote network, instead of the
   packet being cascaded with its original source address.  At Bridge
   boot, it may issue a broadcast request for all locally connected
   hosts/devices to return their local network protocol addresses.  On
   subsequent receipt of this information, the Bridge could then update
   the cache for each of its interfaces so that it would now have a base
   from which to perform future operations.

   The alternative to this automatic procedure is to permit manual
   intervention in the Bridge software which could be activated by the
   network manager in order to key in the addresses of the hosts
   connected to each LAN interface.

   Thus, having provided a means for the Bridge to obtain the original
   state of the LAN addresses when it boots, how then does the Bridge
   distinguish the arrival of a new host on the locally connected system
   from transmissions which were sent from a remote source and cascaded
   by an adjacent Bridge?  Two approaches are currently under
   consideration to solve this problem, namely Explicit Subnets, and
   Transparent Subnets [4], [7], [9], [14].

   In the Explicit Subnet approach, the location of the host in the
   system is important.  The address of the host in the protocol suite
   will reflect which subnet the host is interfaced to.  Consequently
   the protocol address space is divided into a three level hierarchy of
   <network,subnet,host>.  Within the Internet there are five addressing
   divisions in operation [10], classes A, B, C, D, and E.  Classes D
   and E relate to an addressing technique that will be used for
   management of multi-casting groups and will not be discussed here.
   With such a structure, it is possible to provide an address mask at
   each interface so that received packets may have their source address
   fields examined and compared with the address mask of this LAN.  In
   so doing, the component which is being verified is actually the
   subnet address.  If the masking operation is successful the source