Diplomarbeit DIP-1773

Bibliograph.
Daten
Rinklef, Michael: Fault Tolerant Routing Service.
Universität Stuttgart, Fakultät Informatik, Diplomarbeit Nr. 1773 (1999).
103 Seiten, englisch.
CR-Klassif.C.2.1 (Network Architecture and Design)
C.2.2 (Network Protocols)
C.2.4 (Distributed Systems)
C.2.5 (Local and Wide-Area Networks)
C.2.6 (Internetworking)
C.4 (Performance of Systems)
E.2 (Data Storage Representations)
Keywordsfault-rolerance; routing; Fehlertoleranz; Leitwegbestimmung
Kurzfassung

The subject of this thesis is to find a solution for the problem of possible router failures within an untypical network structure. The intranet discussed here consists of two Ethernets with a number of hosts being connected to either both or only one network. TCP/IP is the communication protocol used in this intranet and each Ethernet represents a subnet in the IP address domain. Since hosts being only connected to one network must be able to communicate with each other, a router is necessary. Each host having two running interfaces can be a potential router between both subnets, i.e. it can relay datagrams from one network to the other. In contrast to the Internet, it is not desired to select only one specific host as a router. The reason is, that the system has to cope with failures, especially with router failures. If a router fails for some reason, the Fault Tolerant Routing Service must find another host with two running interfaces which then becomes the new router.

Since TCP/IP offers several solutions for routing and even to cope with router failures, the most interesting possibilities are discussed first. After this overview of the capabilities of TCP/IP concerning routing, a strategy for realizing datagram relaying in the Fault Tolerant Routing Service is selected.

Another task is to find a host with two running interfaces. This is not trivial since a host itself doesn’t reliably know whether both of its interfaces are running correctly. Two protocols are developed which both enable a host to determine its own and each other host’s link state. The first solution described here is the one which was finally implemented because it causes less network overhead than the second one. It is based on each host periodically broadcasting LINK STATE messages on each network it is connected to. The content of these messages is a list of hosts the sender has a connection to on the respective other network. Thus, on receipt of a message, the receiver knows that it has a connection to the sender on the receiving network, and learns about the sender’s connection on the respective other network. With one message per interface from each host the receiver can now determine if there are hosts with two running interfaces. Among all router candidates, hosts with only one connection select a router and update their routing table

Volltext und
andere Links
PDF (282580 Bytes)
PostScript (3704167 Bytes)
Zugriff auf studentische Arbeiten aufgrund vorherrschender Datenschutzbestimmungen nur innerhalb der Fakultät möglich
Abteilung(en)Universität Stuttgart, Institut für Parallele und Verteilte Höchstleistungsrechner, Verteilte Systeme
Eingabedatum22. November 2000
   Publ. Informatik