rfc1029.txt

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

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | P A C K E T     O P C O D E   |REB OPC|      S O U R C E      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        H A R D W A R E            A D D R E S S               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       S O U R C E   P R O T O C O L     A D D R E S S         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     M U L T I C A S T   T A R G E T    H A R D W A R E        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    A D D R E S S      |   M U L T I C A S T     T A R G E T   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   P R O T O C O L     |
   +-+-+-+-+-+-+-+-+-+-+-+-+

          ---------> NEXT FOLLOWS A VARIANT FIELD ON REBOOT  OPCODE

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  O L D         S O U R C E        H A R D W A R E             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  A D D R E S S        |
   +-+-+-+-+-+-+-+-+-+-+-+-+

    OR

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  O L D     S O U R C E    P R O T O C O L      A D D R E S S  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          FIGURE 2. REBOOT PACKET



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


   The following definitions apply:

        PACKET FIELD              VALUE

        OPCODE                    REBOOT

        REBOOT OPCODE             HARDWARE

        REBOOT OPCODE             PROTOCOL

   The format is then as follows:

        48 bit broadcast Ethernet address for the destination,

        48 bit Ethernet address of source Bridge,

        16 bit Protocol type = PACKET OPCODE - REBOOT.


   For completeness and error checking it may be an advantage to have a
   field which specifies the length of addresses in the Ethernet and
   protocol address spaces.  Thus, the Reboot packet structure contains
   the following:

   FIELD          FIELD SIZE                    DESCRIPTION

   HRDLEN          4 bit             byte length of Ethernet address

   PROTLEN         4 bit             byte length of Protocol address


   SOURCE
   PROTOCOL
   ADDRESS        32 bit            current protocol address of host

   TARGET
   PROTOCOL
   ADDRESS        32 bit           broadcast target protocol address

   REBOOT
   OPCODE          4 bit            will be either PROTOCOL or HARDWARE


   if   PROTOCOL       32 bit         old protocol address

   else HARDWARE       48 bit         old hardware  address





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


   As shown, depending on the REBOOT-OPCODE, the structure will continue
   with either the 48 bit old hardware address or the 32 bit old
   protocol address.  The choice of a variant packet structure is for
   reasons of curtailing the size of the packet to the fields that are
   truely necessary in each situation.  From this Reboot packet
   structure, the process of generating such a packet can be considered.
   When the Bridge algorithm detects a reboot, it should create a reboot
   packet structure containing the relevant addressing information and
   subsequently multicast it on the interface(s) which access(es) the
   remote subnet(s).  The decision as to which interface(s) is/are
   local, and which is/are remote, can be resolved automatically
   whenever a packet is received.  With respect to this packet transfer
   the receive interface at the Bridge becomes local, and all others are
   tagged as remote.

   Thus, hosts on the subnet remote from the reboot are informed of the
   situation immediately as it is detected by the Bridge.  In the
   Catenet configuration illustrated in fig 1, this will have the effect
   of updating the Translation Cache within each host, whenever it
   receives the packet.  If for example, <E4Hw> reboots under hardware,
   B3 will detect this occurance.  There is no reason for the subnets
   E1, E2, E3 to be aware of this episode.  In normal operation, B3 will
   recognise the reboot from the first ARREQ issued from <E4Hw>.  With
   this reboot detection facility, B3 will be in a position to inform
   the hosts on E1, E2, and E3.  B3 can then create and issue the Reboot
   packet via its interface with E3.  When B3 picks it up, it will
   update its own caches and subsequently cascade the packet onto E2,
   where it will be passed on to E1 via B1.

ARGUMENTS FOR REBOOT PACKETS

   It is envisaged that introducing Reboot packets, will serve to
   enhance the bandwidth achievable within a Catenet system.  Problems
   of addressing 'dead' hosts will no longer exist in a correctly
   functioning configuration.  Translation Caches will have on hand the
   most recent addressing information available, which should also serve
   to enhance the performance of the routing strategy in operation.
   Multiple, redundant processing of packets destined for 'dead' hosts
   will be avoided.  Weighing this against the processing involved with
   a single multicast of Reboot packets, it is expected that the latter
   will be is the most economically viable in relation to the long-term
   traffic presented to the system.

CONCLUSION

   It appears that reboots are becoming increasingly common on internet
   networks.  Many sites use Personal Computers (PC) as terminals and
   the typical way to finish a session is to switch them off!  With the



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


   increasing popularity of multitasking Operating Systems on these
   types of machines, problems are more likely to occur, particularly
   when the PCs are diskless, or participating in a distributed file
   system of some kind.  Given the importance of correct addressing in
   communications networks running Ethernet, it is anticipated the
   reboot mechanism described will serve to improve the correctness and
   validity of the protocol/network address mappings which may be stored
   in the translation caches.  To this degree, simulation is expected to
   show that the volume of invalid traffic will decrease, to the benefit
   of hosts, Bridges and servers alike.  Likewise, ratification of the
   routing policy is anticipated and since redundant/obsolete packets
   will be thwarted, the efficient utilization of available channel
   bandwidth across the catenet is also expected to improve.  Thus,
   effectively increasing Catenet throughput for 'valid' packets, and
   therefore enhancing the level of service provided to the end users.

   It is obvious that the proposed scheme implies the alteration of the
   packet processing code in Bridges/Gateways.  The point to remember is
   the increased favour with which larger, more complex Multi-LAN
   systems of Ethernets are being received.  The recent adaption of
   extra telephone cables to serve as the transmission media for the
   Ethernet can only result in installation costs being reduced, therein
   making the Ethernet more attractive within large corporate buildings,
   etc.  It is sensible to suggest that the probability of host address
   re-assignment shall increase in proportion to the number of physical
   systems attached, component failure rate (for whatever reason),
   relocation of resources, and the size and turnover of the workforce
   (i.e., people moving from one room to another).  Simulation
   experiments are currently being developed to analyse the resultant
   traffic patterns under this scheme, and it is hoped to highlight
   thresholds where adoption of the scheme becomes a necessity.

   In addition, the Author is currently extending the boundaries of this
   problem to encompass the reboot, or relocation of Bridges themselves.
   Involved with this are the phenomena of loop resolution, load sharing
   and duplicate packet suppression.  It is envisaged that a Self-
   Stabilizationg Bridge Protocol will result that will be more "light-
   weight" than those adhering to the Spanning Tree Algorithm.

   The Author would appreciate feedback/comments on this RFC.  My
   network address is: [e-mail].

ACKNOWLEDGEMENTS

   The Author acknowledges with gratitute the help and comments
   contributed by Mr. Piotr Bielkowitz (Supervisor) of the Computing
   Science Department, and the time devoted my Mr. Raymond Robinson for
   painstakingly preparing the first draft of this paper on 'Pagemaker'.



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


   Thanks are due also to Dr. M. W. A. Smith of Information Systems for
   his assistance.  Finally, this work was supported under a grant from
   the Department of Education for Northern Ireland of which the Author
   is extremely grateful.

REFERENCES

   [1]  Croft, Bill, and John Gilmore, "Bootstrap Protocol", RFC-951,
        Stanford University, September 1985.

   [2]  Finlayson, Mann, Mogul, and Theimer, "A Reverse Address
        Resolution Protocol", RFC-903, Computer Science Dept, Stanford
        University, June 1984.

   [3]  Lorimer, Alan, and Jim Reid, "ARP Information Communique",
        Computer Science Dept, Strathclyde University, 1987.

   [4]  Mogul, Jeffrey, "Internet Subnets", RFC-917, Computer Science
        Dept, Stanford University, October 1984.

   [5]  Plummer, David, "An Ethernet Address Resolution Protocol", RFC-
        826, MIT, November 1982.

   [6]  Postel, Jon, "DARPA Internet Program Protocol Specification",
        RFC-791, USC/Information Sciences Institute, September 1981.

   [7]  Postel, Jon, "Multi-LAN Address Resolution", RFC-925,
        USC/Information Sciences Institute, October 1984.

   [8]  Postel, Jon, Carl Sunshine, and Danny Cohen, "The ARPA Internet
        Protocol", Computer Networks, no. 5, pp. 261-271, 1981.

   [9]  Postel, Jon, and Jeff Mogul, "Internet Standard Subnetting
        Procedure", RFC-950, USC/Information Sciences Institute and
        Stanford University, August 1985.

   [10] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC-1010,
        USC/Information Sciences Institute, May 1987.

   [11] "The Ethernet: a local area network, data link layer and
        physical layer specification", Version 1.0 DEC, Intel and Xerox
        Corporations, USA 30 September 1980).

   [12] Hughes, H.D., and L. Li, "Simulation model of an Ethernet",
        Computer Performance, Vol 3, no. 4, December 1982.

   [13] Parr, Gerald P., "Address Resolution For An Intelligent
        Filtering Bridge Running On A Subnetted Ethernet System", ACM



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


        SIGCOMM Computer Communication Review, (July/August 1987), vol.
        17, no. 3.

   [14] Smoot, Carl-Mitchell, and John S. Quarterman, "Using ARP to
        Implement Transparent Subnet Gateways", RFC-1027, Texas Internet
        Consulting, October 1987.













































Parr                                                           [Page 17]