Linkstate und Distance-Vector

Muß wirklich jeder Node den Zustand des gesamten Netzes kennen? Nein! Es genügt, wenn jeder Node alle Ziele im Netz kennt und den nächsten Nachbarn in die entsprechende Richtung des Ziels. Dies spart unheimlich Verwaltungsaufwand, denn bei einer Änderung an einer Seite des Netzes muß nicht sofort das gesamte Netz informiert werden. Anstelle dieses Linkstate-Routings kommt im Packet-Radio Netz dieses vereinfachte Distance-Vector Routing zum Einsatz.

Hierbei hat jeder Node eine Tabelle, in der alle Ziele des Netzes stehen und die dazugehörige Laufzeit (Qualität) sowie der Nachbar, in dessen Richtung die Pakete geschickt werden sollen. Node A in unserem Bild hätte z.B. folgenden Eintrag:

B 16s über E (weil das kürzer ist als direkt)
C 05s über C
D 06s über C
E 12s über E
F 15s über E

Soll A also eine Nachricht an B schicken, so wird er die Verbindung über E wählen, weil diese schneller ist als direkt an B zu senden. (z.B. weil A und B zu weit entfernt stehen) Knoten E erhält die Nachricht und schaut in seiner Tabelle nach, wohin eine Nachricht zum Ziel B gesendet werden muß. Er erkennt, daß er sie direkt bei B abliefern kann.

Fällt z.B. der Link zwischen E und B aus, so weiß E, daß es eine Ersatzverbindung über F gibt. A braucht davon garnichts zu erfahren, denn die Laufzeit von E nach B bleibt weiterhin 4 Sekunden.

Um Änderungen im Netz zu verbreiten, senden alle Nodes ihre gesamte Tabelle in regelmässigen Abständen aus. Die Nachbarn hören diese und fügen die neuen Informationen in ihre eigene Tabelle ein. Kommt ein neuer Node ans Netz, so sendet dieser zunächst eine leere Tabelle und ist damit den Nachbarn bekannt. Sobald er jedoch selbst die ersten Nachbarn gehört hat, fügt er sie und alle Ziele in seine Tabelle ein.

zähle bis unendlich

Dieses Distance-Vektor Verfahren hat aber auch einen entscheidenen Nachteil: Durch die unvollständigen Informationen, die jeder Node nur besitzt, können sich Schleifen oder Ping-Pongs bilden. Dies bedeutet, daß Nachrichten im Kreis geschickt werden oder immer zwischen zwei Nodes hin- und herspringen und niemals ihr Ziel erreichen. Ein bekanntes Problem ist das sogenannte count-to-infinity Problem.

Der Einfachheit halber sei die Qualität der Verbindung durch die Anzahl der Funkstrecken dorthin angegeben. Mit den Laufzeiten würde sich das gleiche Bild ergeben. Das Ziel ist hier das "Internet". Node A braucht 3 Verbindungen dorthin, Node B braucht 2 und Node C nur eine.

C`s Verbindung ins Internet reißt ab. C hört nun eine Rundsendung von B, die sagt "Ich habe eine Verbindung ins Internet in 2 Sprüngen". Da C nicht weiß, daß damit die Verbindung über ihn gemeint ist, setzt er in seiner eigenen Tabelle eine Route ins Internet über B in 3 Sprüngen.

B hört die neue Rundsendung von C und setzt seine Tabelle auf: "Internet in 4 Sprüngen über C". A weiß noch nicht was passiert ist.

A und C setzen ihre Tabellen auf jeweils 5 Funkstrecken bis zum Internet. Als nächstes würde B auf 6 erhöhen und es geht immer so weiter bis ins "Unendliche". Pakete wären ewig im Ping-Pong zwischen B und C gefangen.

Das Problem führt dazu daß sich "gute" Nachrichten schnell verbeiten, "schlechte" jedoch nur sehr langsam. Das Count-to-Infinity Problem tritt vor allem bei TheNet X1J4 auf. Längst nicht mehr erreichbare Nodes bleiben noch über Stunden in den Routingtabellen. Dies tritt vor allem bei zeitweise betriebenen Internetlinks oder Überreichweiten auf Kurzwelle auf.

Zu diesem Problem gibt es verschiedene Lösungsansätze:

Diese und weitere Änderungen wurden in die Software XNet integriert, die ein wesentlich besseres Verhalten im Netz zeigt als das veraltete TheNet X1J4. Dennoch trifft man immernoch auf X1J4 Nodes, da diese nur einen preiswerten 8-Bit TNC benötigen.

Doch auch die modernste Nodesoftware steht vor einem Problem. Weiter>>