Zum Hauptinhalt springen

5. Konzeptmodell eines Hosts (Conceptual Model of a Host)

Obwohl es nicht erforderlich ist, dass Implementierungen einem bestimmten konzeptionellen Modell eines Hosts entsprechen, beschreibt dieser Abschnitt ein konzeptionelles Modell, das von Hosts verwendet werden kann, um Neighbor Discovery zu verstehen. Ein Host verwaltet konzeptionell eine Reihe von Datenstrukturen:

Neighbor Cache - Eine Menge von Einträgen über einzelne Nachbarn, an die kürzlich Verkehr gesendet wurde. Einträge sind nach der On-Link-Unicast-IP-Adresse des Nachbarn indiziert und enthalten Informationen wie seine Link-Layer-Adresse, ein Flag, das anzeigt, ob der Nachbar ein Router oder ein Host ist (in diesem Dokument IsRouter genannt), einen Zeiger auf alle gepufferten Pakete, die auf den Abschluss der Adressauflösung warten, usw. Ein Neighbor Cache-Eintrag enthält auch Informationen, die vom Neighbor Unreachability Detection-Algorithmus verwendet werden, einschließlich des Erreichbarkeitszustands, der Anzahl unbeantworteter Probes und der Zeit, zu der das nächste Neighbor Unreachability Detection-Ereignis stattfinden soll.

Destination Cache - Eine Menge von Einträgen über Ziele, an die kürzlich Verkehr gesendet wurde. Der Destination Cache umfasst sowohl On-Link- als auch Off-Link-Ziele und bietet eine Indirektionsebene in den Neighbor Cache; der Destination Cache bildet eine Ziel-IP-Adresse auf die IP-Adresse des Next-Hop-Nachbarn ab. Im Gegensatz zum Neighbor Cache enthält der Destination Cache Einträge sowohl für On-Link- als auch für Off-Link-Ziele. Die Pflege eines vom Neighbor Cache getrennten Destination Cache erfüllt mehrere Zwecke. Erstens kann der Destination Cache Einträge für Ziele enthalten, die auf dem Link nicht benachbart sind. Zweitens kann der Destination Cache Einträge enthalten, die Path MTU Discovery, Redirect-Nachrichten usw. unterliegen.

Prefix List - Eine Liste der Präfixe, die eine Menge von Adressen definieren, die on-link sind. Prefix List-Einträge werden aus Informationen erstellt, die in Router Advertisements empfangen wurden. Jeder Eintrag hat einen zugehörigen Invalidierungstimerwert (aus der Ankündigung extrahiert), der zum Ablauf von Präfixen verwendet wird. Ein Prefix List-Eintrag enthält auch ein Flag, das anzeigt, ob das Präfix für die On-Link-Bestimmung und/oder Adress-Autokonfiguration verwendet werden kann, wie in [ADDRCONF] spezifiziert.

Default Router List - Eine Liste von Routern, an die Pakete gesendet werden können. Default Router List-Einträge zeigen auf Einträge im Neighbor Cache; der Algorithmus zur Auswahl eines Standard-Routers bevorzugt Router, die bekanntermaßen erreichbar sind, gegenüber solchen, deren Erreichbarkeit zweifelhaft ist. Jeder Eintrag hat auch einen zugehörigen Invalidierungstimerwert (aus Router Advertisements extrahiert), der zum Löschen von Einträgen verwendet wird, die nicht mehr angekündigt werden.

Die oben beschriebenen konzeptionellen Datenstrukturen sind funktional getrennt; Implementierungen können einige oder alle von ihnen auf die bequemste Weise kombinieren. Die Anforderungen dieses Protokolls können auf einfache Weise durch die Verwendung der obigen Datenstrukturen im Pseudocode in den folgenden Abschnitten erfüllt werden. Eine Implementierung kann jedoch alternative Datenstrukturen verwenden, solange das externe Verhalten der Implementierung unverändert bleibt.

5.1. Konzeptionelle Datenstrukturen (Conceptual Data Structures)​

Obwohl es nicht notwendig ist, dass Hosts alle unten beschriebenen Datenstrukturen pflegen, beschreibt dieser Abschnitt eine Reihe von Datenstrukturen, die für die Implementierung von Neighbor Discovery ausreichend sind.

5.2. Konzeptioneller Sendealgorithmus (Conceptual Sending Algorithm)​

Wenn ein Knoten ein Paket zu senden hat, untersucht er zunächst den Destination Cache. Wenn kein Eintrag für das Ziel existiert, erstellt der Knoten einen und initialisiert seine Next-Hop-Adresse durch Aufruf des Next-Hop-Bestimmungsalgorithmus (Abschnitt 5.2). Sobald ein Destination Cache-Eintrag erstellt wurde, untersucht der Knoten dann den Zustand des Neighbor Cache-Eintrags für den Next-Hop.

Ein Neighbor Cache-Eintrag kann sich in einem von fünf Zuständen befinden:

INCOMPLETE (unvollständig) - Adressauflösung wird derzeit für den Eintrag durchgeführt. Insbesondere wurde eine Neighbor Solicitation an die Solicited-Node-Multicast-Adresse des Ziels gesendet, aber das entsprechende Neighbor Advertisement wurde noch nicht empfangen.

REACHABLE (erreichbar) - Der Eintrag ist bekanntermaßen kürzlich (innerhalb von einigen zehn Sekunden) erreichbar gewesen. Innerhalb der letzten ReachableTime Millisekunden wurde eine positive Bestätigung empfangen, dass der Vorwärtspfad zum Nachbarn ordnungsgemäß funktioniert. Während REACHABLE findet keine besondere Aktion statt, wenn Pakete gesendet werden.

STALE (veraltet) - Der Eintrag ist bekanntermaßen kürzlich erreichbar gewesen, aber kürzlich wurde keine Bestätigung empfangen. Während STALE findet keine Aktion statt, bis ein Paket gesendet wird. Wenn ein Paket gesendet wird, überführt ein Knoten den Eintrag je nach Implementierung entweder in DELAY oder PROBE.

DELAY (verzögert) - Der Eintrag ist bekanntermaßen kürzlich erreichbar gewesen, und ein Paket wurde innerhalb der letzten DELAY_FIRST_PROBE_TIME Sekunden gesendet. Wenn innerhalb von DELAY_FIRST_PROBE_TIME Sekunden nach Eintritt in den DELAY-Zustand keine Erreichbarkeitsbestätigung empfangen wird, senden Sie eine Neighbor Solicitation und ändern Sie den Zustand auf PROBE. Die Verzögerung der Übertragung des Probes gibt Protokollen der oberen Schicht die Möglichkeit, eine Erreichbarkeitsbestätigung bereitzustellen.

PROBE (Probe) - Eine Erreichbarkeitsbestätigung wird aktiv gesucht, indem Neighbor Solicitations alle RetransTimer Millisekunden erneut übertragen werden, bis eine Erreichbarkeitsbestätigung empfangen wird.

Der Neighbor Cache enthält auch Informationen, die zum Ausführen des Neighbor Unreachability Detection-Algorithmus erforderlich sind, einschließlich verschiedener Timer, Zähler usw.

Beim Senden eines Pakets an einen Nachbarn verwendet ein Knoten die im Neighbor Cache-Eintrag enthaltenen Zustandsinformationen, um zu bestimmen, was gegebenenfalls getan werden muss, bevor Verkehr an diesen Nachbarn gesendet wird. Der folgende Pseudocode veranschaulicht den Sendealgorithmus:

if (Destination Cache-Eintrag existiert) {
    next hop = Destination Cache next_hop;
} else {
    next hop = Next-Hop-Bestimmung (Abschnitt 5.2);
    Destination Cache-Eintrag erstellen;
}

if (Neighbor Cache-Eintrag für next hop existiert) {
    if (Neighbor Cache-Eintragszustand == INCOMPLETE) {
        Paket im Neighbor Cache-Eintrag in Warteschlange stellen;
        /* Adressauflösung läuft bereits */
    }
    if (Neighbor Cache-Eintragszustand == REACHABLE) {
        Paket senden;
    }
    if (Neighbor Cache-Eintragszustand == STALE) {
        Paket senden;
        Neighbor Cache-Eintragszustand auf DELAY setzen;
        Neighbor Cache-Eintrags-Timer auf DELAY_FIRST_PROBE_TIME setzen;
    }
    if (Neighbor Cache-Eintragszustand == DELAY) {
        Paket senden;
        /* Timer ist bereits gesetzt */
    }
    if (Neighbor Cache-Eintragszustand == PROBE) {
        Paket senden;
        /* Neighbor Unreachability Detection läuft */
    }
} else {
    Neighbor Cache-Eintrag erstellen;
    Neighbor Cache-Eintragszustand auf INCOMPLETE setzen;
    if (Link-Layer-Adresse ist leicht verfügbar) {
        Link-Layer-Adresse setzen;
        Neighbor Cache-Eintragszustand auf STALE setzen;
        Paket senden;
    } else {
        Paket im Neighbor Cache-Eintrag in Warteschlange stellen;
        Adressauflösung starten;
    }
}

5.3. Garbage Collection und Timeout-Anforderungen (Garbage Collection and Timeout Requirements)​

Der Neighbor Cache, Destination Cache und Prefix List müssen einer Garbage Collection unterzogen werden und ablaufen. Die spezifischen Timeout-Perioden sind jedoch absichtlich nicht spezifiziert. Timeout-Perioden müssen so gewählt werden, dass sie ein vernünftiges Gleichgewicht zwischen der Aufrechterhaltung veralteter Informationen und den Kosten für die Aktualisierung dieser Informationen bieten. Im Allgemeinen sollten Timeout-Perioden großzügig genug sein, um Thrashing des Cache-Inhalts zu verhindern, aber kurz genug, um langfristige Veralterung zu verhindern.

Eine konzeptionelle Implementierung könnte die folgenden Regeln verwenden:

  • Neighbor Cache-Einträge sollten (SHOULD) mindestens für eine durch ReachableTime angegebene Zeit verbleiben, nachdem sie in den STALE-Zustand übergegangen sind. Sie können jedoch länger verbleiben, wenn die Implementierung eine Form von Garbage Collection-Algorithmus verwendet, um Einträge zurückzugewinnen. Einträge im INCOMPLETE-Zustand müssen nicht für einen solch verlängerten Zeitraum verbleiben.

  • Destination Cache-Einträge sollten (SHOULD) so lange wie möglich (d. h. unbegrenzt) im Cache verbleiben. Die spezifische Zeitperiode ist jedoch implementierungsabhängig. Implementierungen SOLLTEN (SHOULD) einen Destination Cache-Eintrag ungültig machen, wenn eine Redirect-Nachricht empfangen wird, die eine bessere Route zum Ziel angibt.

  • Einträge in der Prefix List laufen gemäß der in Router Advertisements angegebenen Lebenszeit ab. Die Lebenszeit eines Eintrags wird aktualisiert, wenn ein neues Router Advertisement eintrifft.

  • Einträge in der Default Router List laufen gemäß der in Router Advertisements angegebenen Router-Lebenszeit ab. Empfangene Router Advertisements mit einer Router-Lebenszeit von Null zeigen an, dass der Router sofort aus der Default Router List entfernt werden sollte.

Letztes Update am