Zusammenfassung

  • SENDER_TSPEC, ADSPEC und FLOWSPEC stammten von unterschiedlichen Akteuren: Der Sender deklarierte, der Pfad komponierte eine Anzeige, der Empfänger formulierte eine Reservierungsanforderung.
  • Das allgemeine Break-Bit zeigte mindestens ein Element ohne RSVP/Integrated-Services-Unterstützung an; dann waren sämtliche anderen ADSPEC-Parameter als durchgängige Pfadzusammenfassung unzuverlässig.
  • Dienstspezifische Break-Bits markierten einen engeren Mangel: Ein RSVP-fähiges Element stellte den betreffenden Dienst nicht bereit.
  • PATH_MTU wurde auf dem Pfad und bei Zusammenführungen verkleinert, ohne die ursprüngliche Maximalgröße im Sender-TSpec umzuschreiben; größere Pakete konnten nur Best-Effort-Behandlung erhalten.
  • Werbung, Anfrage, Zulassung, Zusammenführung und berechnete Schranke belegten jeweils nur ihre eigene Stufe—nicht Routenstabilität, Konformität, beobachtete Zustellung oder Anwendungserfolg.

Verdichtung brauchte eine sichtbare Bruchstelle

RFC 2210 ließ den ADSPEC nicht mit jedem Router wachsen.

Im One-Pass-With-Advertising-Verfahren aktualisierten beteiligte Netzelemente komponierte Werte, während die PATH-Nachricht zum Empfänger lief. Der Empfänger erhielt einen annähernd konstant großen Bericht statt eines vollständigen Hop-Protokolls.

Diese Konstruktion war effizient, aber nicht detailtreu.

Ein Bandbreitenwert bewahrte nicht alle lokalen Werte. Das PATH_MTU behielt das relevante Minimum, ohne zwingend dessen Ort zu nennen. Die Fehlerterme von Guaranteed Service wurden nach den Kompositionsregeln zusammengeführt, nicht als Liste jedes einzelnen Elements.

Die Verdichtung durfte daher eine bestimmte Information nicht verlieren: ob die gesamte erforderliche Kette an der Berechnung teilgenommen hatte.

Fehlte einem Element RSVP/IntServ-Unterstützung, setzte das allgemeine Break-Bit die Gültigkeitsgrenze. Die übrigen Zahlen konnten auf Teilstrecken korrekt sein. Sie konnten nur nicht mehr belegen, was über den gesamten Pfad galt.

Spätere Unterstützung heilte keinen früheren Ausfall

Hinter einer Lücke konnten wieder vollständig fähige Router stehen. Sie durften ihre lokalen Beiträge korrekt verarbeiten, aber das Break-Bit nicht so behandeln, als wäre die Lücke nie vorhanden gewesen.

Ein lokaler Erfolg nach dem Bruch stellt die Ende-zu-Ende-Kette nicht wieder her.

Damit war das Bit mehr als ein aktueller Fähigkeitsstatus. Es war Herkunftsinformation über die Pfadkomposition. Es sagte dem Empfänger, dass die Zusammenfassung einen Punkt durchlaufen hatte, an dem ihre Grundannahme nicht galt.

Gerade weil der genaue Hop-Verlauf nicht im ADSPEC erhalten blieb, musste diese negative Information klebrig sein.

Deklaration, Anzeige und Anfrage

Der SENDER_TSPEC wurde vom Sender erzeugt und downstream transportiert.

Er beschrieb den möglichen Datenverkehr mit Token-Bucket-Parametern und der maximalen Paketgröße M. Zwischenelemente reichten den ursprünglichen TSpec weiter. Sie korrigierten die Senderaussage nicht auf ihre eigenen Grenzen.

Der ADSPEC lief ebenfalls downstream, hatte aber einen anderen Urheber. Teilnehmende Netzelemente bauten die Pfadzusammenfassung auf.

Der FLOWSPEC entstand beim Empfänger und lief upstream in der RESV-Nachricht. Er beschrieb die angeforderte Dienstleistung und konnte durch Reservierungszusammenführung oder lokale Kontrollverarbeitung verändert werden.

Diese drei Objekte waren kein einziger Reservierungsbeleg.

Ein TSpec belegte eine Deklaration, nicht die tatsächliche Einhaltung. Ein ADSPEC belegte eine Werbung über den durchlaufenen Pfad, nicht die Zulassung. Ein FLOWSPEC belegte eine Anforderung oder einen zusammengeführten Kontrollzustand, nicht bereits erbrachte Paketbehandlung.

Ein sauberes ADSPEC blieb zeitgebunden

Ein nicht gesetztes Break-Bit war ein brauchbares positives Signal: Die betreffende Anzeige hatte die definierte Fähigkeitslücke nicht aufgezeichnet.

Es fror den Pfad nicht ein.

Routing konnte sich nach der PATH-Nachricht ändern. Ressourcen und Richtlinien konnten vor Eintreffen von RESV anders aussehen. Ein weiterer Empfänger konnte den zusammengeführten Zustand verändern. Soft State konnte aktualisiert oder verloren werden.

Darum gehörten Route und Zeitpunkt zur Aussage des ADSPEC, auch wenn sie nicht als vollständiges Protokoll im Objekt standen.

Wer nur den aktuellen Bitwert speichert und einen Next-Hop-Wechsel ignoriert, macht aus historisch zutreffender Evidenz eine gegenwärtige Garantie. Das Problem liegt dann nicht im ursprünglichen Signal, sondern in seiner Anwendung auf einen anderen Sachverhalt.

Drei Paketgrößen waren gleichzeitig wahr

Die Behandlung der Paketgröße zeigt besonders klar, warum die Objekte getrennt blieben.

M im Sender-TSpec bezeichnete das größte Paket, das der Sender erzeugen konnte. PATH_MTU wurde auf das kleinste relevante MTU entlang des beworbenen Pfads reduziert. Bei mehreren Sendern oder zusammenlaufenden Empfängerzweigen setzte sich ebenfalls die kleinere akzeptable Größe durch.

Der ursprüngliche SENDER_TSPEC blieb unverändert.

Der Sender konnte somit größere Pakete erzeugen, als der Pfad oder alle Empfängerzweige reserviert behandelten. Das war kein Datenwiderspruch. Die Werte beschrieben Erzeugungsfähigkeit, Pfadabdeckung und gemeinsame Akzeptanz.

Pakete oberhalb der abgedeckten Größe konnten laut RFC 2210 lediglich Best-Effort-Behandlung erhalten. Eine Reservierung war keine pauschale Eigenschaft jedes Pakets eines Flows.

Der Empfänger traf eine Wahl

Aus der PATH-Information baute der Empfänger einen FLOWSPEC.

Er berücksichtigte Anwendungsanforderungen, Senderprofil, ADSPEC und lokale Richtlinie. Für Guaranteed Service konnte er die komponierten Terme verwenden, um eine zu einem gewünschten Verzögerungsziel passende Reservierung abzuleiten. Für Controlled-Load stellte er eine Anfrage nach dessen eigener Dienstdefinition.

Der Schritt wandelte Evidenz in Absicht um.

An jedem RSVP-fähigen Element wurden TSpec und FLOWSPEC dem passenden Traffic-Control-Dienst vorgelegt. Richtlinie und Admission Control konnten weiterhin ablehnen. Mehrere Reservierungen konnten zusammengeführt werden, sodass das upstream weitergereichte Objekt nicht mehr exakt dem Wunsch eines einzelnen Empfängers entsprach.

Eine erfolgreiche Zusammenführung war ein Kontrollereignis. Sie war keine Messung der späteren Datenebene.

Allgemeiner Bruch und Dienstbruch

Das allgemeine Bit bezog sich auf die Fähigkeit des Pfads, an RSVP und Integrated Services teilzunehmen. Ein einziger nicht teilnehmender Abschnitt entzog der gesamten Zusammenfassung ihre Ende-zu-Ende-Grundlage.

Dienstspezifische Bits beantworteten eine andere Frage.

Ein Router konnte RSVP verstehen und allgemeine Parameter verarbeiten, ohne Guaranteed Service anzubieten. Dann blieb die allgemeine Architektur sichtbar, während genau dieser Dienst als unterbrochen markiert wurde.

Die Trennung verhinderte, dass RSVP-Fähigkeit mit Unterstützung jedes QoS-Dienstes gleichgesetzt wurde. Ebenso verhinderte sie, dass das Fehlen eines Dienstes fälschlich als völliges Fehlen der Signalisierung beschrieben wurde.

Controlled-Load war keine numerische Garantie

RFC 2211 definierte Controlled-Load als Dienst, der einem konformen Flow die Erfahrung eines unbelasteten Best-Effort-Netzes annähern sollte. Admission Control gehörte dazu, eine feste numerische Verlust- oder Verzögerungsgarantie jedoch nicht.

Sein ADSPEC-Teil benötigte deshalb nicht die zusammengesetzten Guaranteed-Terme. Er benötigte aber ein eigenes Break-Bit, um fehlende Dienstunterstützung offenzulegen.

Ein Monitoring-System durfte aus dem Dienstnamen keine nicht spezifizierte Zielzahl erfinden.

Guaranteed war streng innerhalb seiner Voraussetzungen

Für Guaranteed Service führte der ADSPEC Ctot, Dtot, Csum und Dsum. RFC 2212 bestimmte ihre Komposition. Zusammen mit den Verkehrsparametern konnte der Empfänger eine Warteschlangen-Verzögerungsgrenze berechnen.

Die mathematische Aussage blieb an Voraussetzungen gebunden.

Der Flow musste seinem Profil entsprechen. Der Dienst musste auf den relevanten Elementen verfügbar sein. Die Reservierung musste zugelassen werden. Der beworbene Pfad musste weiter anwendbar sein. Und die Grenze sagte nichts darüber, ob eine entfernte Anwendung ihre Aufgabe erledigt hatte.

Eine präzise Formel macht ihre Eingangsbedingungen nicht entbehrlich.

Signalisierung und Dienst waren absichtlich getrennt

RSVP konnte QoS-Objekte transportieren, ohne deren gesamte Semantik selbst zu besitzen. Dienstmodule interpretierten die Parameter, während das Setup-Protokoll PATH-, RESV- und Soft-State-Verhalten behandelte.

RFC 2205 definierte RSVP, RFC 2211 und 2212 die Dienste, RFC 2215 lokale und komponierte Parameter, RFC 2216 den Dienst eines einzelnen Netzelements. RFC 2210 beschrieb die Verbindung.

Damit blieb auch Verantwortung verteilt. Signalisierungserfolg war kein Dienstnachweis. Lokale Dienstfähigkeit war keine Pfadgarantie. Ein syntaktisch korrekter FLOWSPEC ersetzte weder Richtlinie noch Authentifizierung für den Zugang zu knappen Ressourcen.

Standardsyntax, nicht Einsatzstatistik

RFC 2210 erschien im September 1997 als Proposed Standard. Die Primärquellen tragen Aussagen über Objektbedeutung und Komposition.

Sie belegen keine heutige Verbreitung, keine korrekte Produktimplementierung, keine Betreiberleistung und keinen Anwendungserfolg. Historisch belastbar ist die Architekturidee: Ein kompaktes Kontrollobjekt durfte seine eigene Ungültigkeitsbedingung nicht verbergen.