Zusammenfassung

  • RFC 2333 verstand NHRP als Adressauflösung auf Grundlage einer vorherigen Routingentscheidung, nicht als Routingprotokoll oder Ende-zu-Ende-Test.
  • Ob ein Shortcut sinnvoll war, hing von Topologie, Aufbaukosten, Anwendungsbedarf, NHRP-Abdeckung und Schleifensicherheit ab; Eignung war noch keine Ausführung.
  • Registrierungs-ACK, autoritative Resolution Reply und Cacheeintrag waren getrennte Kontrollzustände mit Herkunft, Policy, Holding Time und Widerrufspfad.
  • Bei ATM blieb nach der Auflösung der Aufbau der virtuellen Verbindung; danach waren Weiterleitung, Rückweg, entfernter Dienst und Anwendung gesondert nachzuweisen.
  • Betriebssicherheit verlangte eine Beweiskette aus Route, Einsatzentscheidung, Zuordnung, Verbindung, Datenverkehr, Dienst und Ergebnis.

Ein vollständiger Cacheeintrag beantwortete nur eine begrenzte Frage

NHRP-Zustand wirkt besonders überzeugend, weil er konkret ist.

Eine Protokolladresse steht neben einer NBMA-Adresse. Die Antwort kann autoritativ sein. Ein Timer zeigt, wie lange der Eintrag noch gelten soll. In einer Betriebsoberfläche wird daraus schnell die Aussage: „Der nächste Hop ist da.“

RFC 2333 war jedoch eine Anwendbarkeitserklärung. Sie fragte, wann NHRP für IP-Datagramme über NBMA-Netze wie ATM, SMDS und X.25 geeignet war und welche Bedingungen seine Aussage begrenzten.

Ein Netz konnte für NHRP geeignet sein, ohne einen aktiven Shortcut zu besitzen. Ein Client konnte eine richtige Zuordnung haben, ohne dass ATM eine Verbindung akzeptiert hatte. Eine Verbindung konnte bestehen, obwohl IP-Weiterleitung oder Rückweg gestört waren. Selbst erreichbares IP sagte nichts über den Anwendungsdienst.

Der Cache war ein Eingang für den nächsten Schritt, kein zusammengefalteter Ende-zu-Ende-Bericht.

Routing gab die Richtung vor

NHRP war kein Routingprotokoll.

Die Quellstation ermittelte ihren nächsten Hop mit den normalen Verfahren der Netzwerkschicht. Führte der Weg über eine NBMA-Schnittstelle und fehlte eine brauchbare Zuordnung, konnte sie eine Resolution Request senden. Für ein Ziel im logischen NBMA-Netz konnte die Antwort dessen eigene Adresse liefern, für ein externes Ziel die Adresse des aktuellen Ausgangsrouters.

Bei dynamischem Routing spiegelte dieser Ausgang die Entscheidung des Routingsystems wider.

Das machte ihn nicht unter allen Gesichtspunkten optimal. Weniger IP-Hops bedeuteten nicht automatisch geringere Latenz, weniger Überlastung, niedrigere Kosten oder getrennte Ausfallbereiche. Eine NHRP-Antwort beglaubigte auch nicht sämtliche Daten und Regeln, aus denen die Route entstand.

Änderte sich die Routingepoche, konnte die Zuordnung ihre Voraussetzung verlieren. Häufige Änderungen erzeugten kurzlebige Shortcuts. Bei Router-zu-Router-Nutzung konnte fehlende Information zur Schleifenunterdrückung sogar dauerhafte Weiterleitungsschleifen ermöglichen.

NHRP setzte eine Route um; es durfte sie nicht verewigen.

Der Shortcut musste seinen Aufwand rechtfertigen

Im klassischen IP-over-ATM-Modell begrenzte ein Logical IP Subnet den direkten Verkehr. ATMARP löste Adressen innerhalb der LIS auf. Stationen in verschiedenen LIS gingen über einen IP-Router, selbst wenn das ATM-Gewebe eine direkte virtuelle Verbindung technisch zugelassen hätte.

NHRP konnte diese logische Grenze innerhalb eines NBMA-Netzes überbrücken. Dadurch ließen sich Zwischenrouter umgehen und Eigenschaften des Mediums, etwa QoS-Optionen, direkter nutzen.

RFC 2333 machte daraus keinen Automatismus.

Ein verbindungsorientierter Shortcut kostete Signalisierung, Schnittstellenressourcen, Speicher und Zustandsverwaltung. Für eine kurze Übertragung ohne besondere Qualitätsanforderung konnte Hop-by-Hop-Routing günstiger sein.

Die Anwendungsanforderung entschied mit. „NHRP ist in dieser Umgebung einsetzbar“ war eine Aussage über die Architektur. „Dieser Datenstrom soll jetzt einen Shortcut erhalten“ blieb eine konkrete Policyentscheidung.

Die Initiatorregel begrenzte Zustandswachstum

Vor dem Aufbau eines Shortcuts konnte ein Paket mehrere Router passieren. Würde jeder NHRP-fähige Punkt reagieren, könnten mehrere direkte Wege für denselben Datenstrom entstehen.

Die Anwendbarkeitserklärung empfahl deshalb, nur den Ursprungshost, den ersten Router mit über NBMA erreichbarem nächsten Hop oder einen zwingenden Policyrouter initiieren zu lassen.

Das war eine Zuständigkeitsregel.

Sie versprach dem Initiator keinen Erfolg. Sie bestimmte, wer neue Zuordnungs- und Verbindungszustände erzeugen durfte. Ohne diese Grenze konnte eine Optimierung ihre eigenen Ressourcen vervielfachen.

Router-zu-Router verlangte eine klare Stopplinie

Host-zu-Host, Host-zu-Router und Router-zu-Host gehörten zum allgemeinen Einsatzbild. Zwischen Routern war die Ausgangslage riskanter.

Basis-NHRP konnte Routinginformation verlieren, die zur Vermeidung von Schleifen erforderlich war, etwa bei Metrikänderungen über Grenzen autonomer Systeme.

Ein sichererer Sonderfall lag vor, wenn der Zielhost stabil direkt an der Nicht-NBMA-Schnittstelle des Ausgangsrouters lag. Kam eine durch das Q-Bit gekennzeichnete Routeranfrage ohne diese Voraussetzung an, konnte der Ausgangsrouter mit einem NAK antworten. Die Pakete blieben auf dem gerouteten Weg.

Dieses NAK war nicht gleichbedeutend mit Unerreichbarkeit. Es verweigerte einen nicht hinreichend abgesicherten Shortcut und bewahrte die vorhandene Konnektivität.

Eine angenommene Registrierung war keine Lebensprobe

RFC 2332 erlaubte einem NHC, seine Protokoll-zu-NBMA-Zuordnung bei einem zuständigen NHS einzutragen.

Der Server prüfte Fehler und Policy. Er konnte ablehnen, wenn er die Adresse nicht bedienen konnte, Ressourcen fehlten, administrative Regeln widersprachen oder ein Eindeutigkeitskonflikt bestand.

Eine erfolgreiche Registration Reply bedeutete, dass der NHS die Zuordnung unter den damaligen Bedingungen angenommen hatte.

Sie prüfte keinen entfernten Anwendungsprozess. Sie richtete nicht automatisch eine Ende-zu-Ende-Verbindung ein. Sie garantierte weder vollständige Serversynchronisation noch unverändertes Routing.

Registrierungen besaßen eine Holding Time und mussten rechtzeitig erneuert werden. Der Protokollentwurf behandelte Alterung also als Bestandteil der Bedeutung.

Ein ACK war eine Annahmequittung, kein dauerhafter Präsenznachweis.

Autorität bezog sich auf die Zuordnung

RFC 2332 unterschied autoritative von nicht autoritativen Antworten aus Transit-Caches.

Ein Client konnte eine Antwort des NHS verlangen, der das Ziel bediente. Ein Transitserver durfte unter bestimmten Bedingungen aus seinem Cache antworten. Die Unterscheidung zeigte, wer sprach und in welcher Beziehung er zum Ziel stand.

Auch die autoritative Antwort blieb auf die Adresszuordnung begrenzt.

Sie konnte keine SVC-Ressourcen versprechen, keine Adressfilter oder geschlossenen Nutzergruppen übergehen, keinen Rückweg prüfen und keinen Anwendungsdienst testen.

„Autoritativ“ bedeutete zuständig für diese Antwort, nicht allwissend über die spätere Übertragung.

Im Cache lagen unterschiedliche Herkunftsketten

Ein NHS konnte Daten aus Registrierung, Resolution Request/Reply, vorkonfigurierten Tabellen, ARP oder externen Verfahren gewinnen. Ein NHC konnte Antworten, manuelle Konfiguration oder andere Quellen verwenden.

Eine reine Präsenzanzeige verwischte diese Herkunft.

RFC 2677 machte Cachetyp, Quelle, Verwendung, Gültigkeit der Holding Time, Restzeit und ausgehandelte MTU beobachtbar. Ein gelernter Eintrag sollte bei null Sekunden gelöscht werden. Für administrativ hinzugefügte Zeilen konnte die Zeit undefiniert sein, weil nichtflüchtige Konfiguration sie trug.

Dieselbe Adresspaarung konnte deshalb unterschiedliche Entscheidungen rechtfertigen. Eine frische autoritative Antwort, eine synchronisierte Kopie, ein manueller Wert und ein negativer Cacheeintrag waren nicht gleichwertig.

Der Cache speicherte Behauptungen mit Herkunft, keine laufenden Paketmessungen.

Synchronisation war keine verteilte Erreichbarkeitsmessung

SCSP und die NHRP-Anwendung aus RFC 2335 halfen mehreren NHS, ihre Bestände abzugleichen.

Das war für einen konsistenten Dienst wichtig. Eine Anfrage an verschiedene Server sollte nicht allein wegen interner Verteilung völlig unterschiedliche Ausgangsdaten erhalten.

Synchronisation beobachtete das Endsystem jedoch nicht erneut.

War die Quelle veraltet, konnten mehrere Server vollkommen übereinstimmend eine vergangene Wirklichkeit wiedergeben. Ihre Einigkeit bewies Replikation, nicht Paketzustellung.

RFC 2332 definierte daher Purge-Nachrichten und Fehler für Schleifen, unerreichbare Protokolladressen, ungültige Antworten, Authentifizierungsfehler und überschrittene Hopzahl. Zustand musste widerrufbar bleiben.

Nach der Auflösung begann der Verbindungsaufbau

In einem verbindungsorientierten NBMA wie ATM konnte die Quelle nach der Auflösung erst noch eine Verbindung mit gewünschter Bandbreite einrichten.

„Resolved“ war damit ausdrücklich nicht „connected“.

Signalisierung konnte an Ressourcen oder Policy scheitern. Eine Verbindung konnte mit unpassenden Eigenschaften entstehen. Daten konnten in nur einer Richtung fließen. Ein Host konnte auf IP reagieren, während der eigentliche Dienst ausgefallen war.

Jede dieser Aussagen gehörte zu einer anderen Stufe und brauchte einen eigenen Beobachter.

Der geroutete Weg sicherte Kontinuität

Löste ein Datenpaket die Auflösung aus, konnte die Quelle es verwerfen, zwischenspeichern oder auf dem normalen Weg weiterleiten. RFC 2332 empfahl die geroutete Weiterleitung als Standard, damit Daten während der Suche fließen konnten.

Ein nicht NHRP-fähiger Router konnte die Anfrage still verwerfen. Dann entstand kein Shortcut, doch Hop-by-Hop-Konnektivität konnte bestehen bleiben.

Die Architektur trennte Optimierung vom Grunddienst.

NHRP konnte scheitern, während die Anwendung funktionierte. NHRP konnte gesund erscheinen, während die Anwendung ausfiel. Ein brauchbares Betriebsbild musste beide Fälle zeigen.