Zusammenfassung

  • RFC 2386 suchte mit Ressourceninformationen und Flussanforderungen nach geeigneten Pfaden, stellte aber klar, dass die Berechnung die dargestellten Ressourcen nicht reservierte.
  • Innerhalb eines autonomen Systems durfte die Lösung detailliert und experimentell sein; zwischen Systemen sollte die Information sparsam und stabil bleiben, während jeder Knoten bei der Einrichtung selbst entschied.

Der Unterschied zwischen Finden und Bekommen

Best-Effort-Routing brauchte vor allem Erreichbarkeit und eine bevorzugte Kostenmetrik. Ein Dienst mit Qualitätsanforderungen brachte verbrauchbare Eigenschaften ins Spiel. War genügend Bandbreite frei? Blieben Verzögerung und Jitter innerhalb einer Grenze? Der kürzeste Pfad konnte ungeeignet sein, während eine längere Alternative die Anforderung erfüllte.

QoS-basiertes Routing verband im RFC das Wissen über Ressourcen mit dem Bedarf eines Flusses. Es fand einen Pfad, der die Anforderung mit guter Wahrscheinlichkeit aufnehmen konnte. Diese vorsichtige Formulierung war wesentlich. Die Berechnung reservierte keine Bandbreite. RSVP konnte Ressourcen entlang eines Pfades anfordern, fand aber nicht automatisch den passenden Pfad. Routing und Reservierung ergänzten einander, ohne dieselbe Autorität zu besitzen.

Dazwischen lag eine Beweiskette. Ein Link maß lokalen Zustand. Das Routing kodierte, verteilte und aggregierte ihn. Der Empfänger berechnete mit einem Bild, das bereits gealtert oder vergröbert sein konnte. Während der Einrichtung prüfte jeder Knoten seine gegenwärtigen Ressourcen. Eine übergeordnete Zulassung durfte aus Gründen von Kosten, Fairness oder Priorität selbst dann ablehnen, wenn alle lokalen Prüfungen Kapazität fanden. Erst Zuweisung, kohärentes Forwarding und Messung belegten das Ergebnis.

Die Karte sagte, wo ein Versuch sinnvoll war. Sie bestätigte nicht dessen Annahme.

Eine verbrauchbare Metrik veränderte sich durch ihre Nutzung

Freie Bandbreite ist kein dauerhafter Name. Wird ein Pfad gewählt, weil er leer wirkt, verändert der neue Verkehr genau diese Eigenschaft. Reagiert das Routing auf jede kleine Verbesserung, kann Last zwischen Alternativen pendeln. Der RFC verband solche Bewegungen mit Oszillation, zusätzlichem Steuerverkehr sowie wechselnder Verzögerung und Jitter.

Frische hatte daher einen Preis. Häufige Meldungen verbrauchten Bandbreite und Rechenzeit. Seltene Meldungen ließen die Karte veralten. Grobe Quantisierung sparte Aktualisierungen und löschte womöglich den für die Zulassung entscheidenden Unterschied. Glättung dämpfte Rauschen und konnte eine kurze reale Überlast verschleiern.

Der Auslöser einer Meldung gehörte zum Stabilitätsentwurf. Routen-Pinning hielt einen zugelassenen Fluss für eine Zeit auf seinem Pfad, statt jeder scheinbaren Verbesserung nachzulaufen. Es machte den Pfad nicht unfehlbar. Es trennte die Kontinuität einer getroffenen Entscheidung von der Bewegung der umgebenden Karte.

Feiner Zustand war eine zusätzliche Ausfallfläche

Routing konnte nach Ziel, nach Quelle und Ziel oder je Fluss entscheiden. Je feiner die Einheit, desto genauer ließ sich eine Anforderung zuordnen und desto mehr Zustand musste bestehen bleiben.

Verlor ein Router den flussspezifischen Eintrag und fiel auf gewöhnliches Zielrouting zurück, während ein anderer Router weiter dem Sonderpfad folgte, konnte eine Schleife entstehen. Zwei Knoten führten dann verschiedene Fassungen der Route aus.

Zusätzlicher Zustand war somit nicht nur zusätzliches Wissen. Er war Speicher, Synchronisationspflicht und eine neue Fehlerart. Eine Route einmal auszurechnen genügte nicht; jede davon abhängige Weiterleitungsentscheidung musste über die Lebenszeit des Flusses konsistent bleiben.

Aggregation tauschte Genauigkeit gegen Größenordnung

Hierarchie fasste viele interne Links und Pfade in einer kleineren Darstellung zusammen. Ohne diese Verdichtung wäre ein großes Netz kaum zu verwalten; mit ihr gingen Einzelheiten verloren.

RFC 2386 beschrieb den möglichen Widerspruch: Der aggregierte Zustand ließ einen Fluss zulässig erscheinen, doch kein konkreter interner Pfad konnte ihn tragen. Die Zusammenfassung musste nicht falsch sein. Sie war nur zu verlustbehaftet für die präzise Frage, die man ihr stellte.

Crankback machte daraus ein Verfahren. Scheiterte die Einrichtung an einem Knoten, ging sie zu einem früheren Punkt zurück, der eine Alternative wählen konnte. Das korrigierte eine Prognose, verlängerte jedoch die Einrichtung und konnte unter hoher Last die Leistung verschlechtern. Crankback war begrenzte Suche, keine Garantie, irgendwo Kapazität zu finden.

Das System blieb glaubwürdig, weil ein Kandidat scheitern durfte. Die Aggregation verkleinerte den Suchraum, lokale Zulassung prüfte die Gegenwart und Ablehnung blieb ein gültiges Ergebnis.

Zwei Geschwindigkeiten der Autonomie

Der RFC schrieb innerhalb eines autonomen Systems keine einzige Methode vor. Link-State, Sonden, statisch bereitgestellte Pfade oder Berechnung bei Bedarf konnten unabhängig entstehen. Zwischen Systemen verlangte er einfache, einheitliche und stabile Interaktion.

Hochdynamischer Zustand über Domänengrenzen hätte schlecht skaliert, interne Details offengelegt und entfernten Rechnern ein bereits aggregiertes, nicht überprüfbares Bild gegeben. Deshalb sollten interdomainale Angaben eher aus geplanter Topologie und Kapazität stammen. Ausfälle oder konzentrierte Überlast konnten Änderungen auslösen; jeder gewöhnliche Fluss innerhalb der Auslegung sollte es nicht.

Im Inneren lief eine schnelle Uhr. Nach außen galt eine langsamere Aussage über Erreichbarkeit, bereitgestellte Fähigkeit und Richtlinie. Die gemeinsame Schicht koordinierte Erwartungen, ohne die lokale Wirklichkeit kopieren zu wollen.

Damit blieb auch die Entscheidungsgewalt lokal. Eine Domäne erklärte, was sie unter bestimmten Annahmen unterstützen konnte. Der Eingangsrouter zählte weiterhin die Gesamtnachfrage und durfte Überschuss ablehnen, als Best Effort behandeln oder einer anderen Regel unterwerfen. Eine externe Berechnung erhielt durch eine Metrik keinen Besitz an internen Warteschlangen.

Ein Preis brauchte einen Liefernachweis

Das Dokument betrachtete Geldkosten als mögliche Auswahlregel. Anbieter könnten Kosten verschiedener Dienstklassen weitergeben und über mehrere Domänen zusammensetzen. Dann stellte sich die Frage, was zu berechnen sei, wenn die zugesagte QoS nicht tatsächlich geliefert wurde.

Eine Anzeige belegte entworfene Fähigkeit. Eine Reservierung belegte Zuweisung. Keine von beiden maß allein Ende-zu-Ende-Verzögerung, Jitter, Verlust und Durchsatz. Eine Zusage konnte einen Preis haben, bevor es einen Beleg für ihre Erfüllung gab.

Der Sicherheitsabschnitt spiegelte dieselbe Grenze. Eine QoS-Anforderung durfte sich nicht selbst berechtigen. Beliebige Forderungen konnten Ressourcen erschöpfen und legitime Flüsse verdrängen. Prüfung, Richtlinie, Bepreisung und Policing bestimmten, wer eine knappe Ressource binden durfte.

Spätere Mechanismen bewahrten die Arbeitsteilung

RFC 2205 definierte die Reservierungssignalisierung von RSVP. RFC 2210, 2211 und 2212 verbanden sie mit Integrated Services, Controlled Load und Guaranteed Service. RFC 2676 dokumentierte QoS-Routing und OSPF-Erweiterungen. RFC 3272 ordnete Routing in Messung, Modellierung, Steuerung und Auswertung des Traffic Engineering ein; RFC 3630 beschrieb zusätzliche Linkattribute für OSPF.

Diese Texte beweisen keine flächendeckende Umsetzung des Rahmens. Sie zeigen, weshalb die funktionale Trennung Bestand hatte. Eine Anzeige speist die Berechnung. Die Berechnung schlägt vor. Signalisierung fordert an. Zulassung entscheidet. Reservierung verändert Zustand. Messung beurteilt das Resultat.

RFC 2386 führte adaptives Routing auf zwei Grundakte zurück: Netzzustand sammeln und daraus Routen berechnen. Seine historische Stärke liegt in den Grenzen um diese Akte. Zustand hat ein Alter, eine Anzeige einen Geltungsbereich, eine Berechnung liefert einen Kandidaten, Zulassung prüft die Gegenwart, Reservierung verändert Ressourcen und laufender Verkehr liefert den Nachweis.

Wo die Karte keine Verfügungsgewalt hatte, musste der Pfad um Erlaubnis bitten.

Quellen