Zusammenfassung

  • RFC 2215 trennte den lokalen Beitrag eines Netzelements vom über den Pfad komponierten Wert und bezog Charakterisierungen konzeptionell auf den nächsten Hop.
  • Unterschiedliche Aussagen erhielten unterschiedliche Algebra: ODER, Inkrement, Minimum oder begrenzte Summe.
  • Das Ergebnis war eine qualifizierte Pfadbeschreibung, keine Reservierung, Zulassung, Leistungsmessung oder Zustellbestätigung.

Vier Fragen an denselben Pfad

Ein Router konnte zugleich erfahren, ob zuvor die Dienstkette unterbrochen war, wie viele Integrated-Services-fähige Elemente mitgewirkt hatten, welche geringste Bandbreite gemeldet wurde und welche minimale Laufzeit sich summiert hatte. Ein gemeinsamer Mittelwert wäre bedeutungslos gewesen.

RFC 2215 band deshalb die Rechenregel an die Behauptung. Eine einzige Unterbrechung genügte und verlangte logisches ODER. Ein bekannter Teilnehmer erhöhte den Zähler. Ein Engpasswert konnte nur gleich bleiben oder sinken. Ein Verzögerungsbeitrag musste hinzukommen.

Diese Werte charakterisierten die QoS-Umgebung vor einer konkreten Reservierung. Sie halfen bei einer Entscheidung; sie dokumentierten nicht deren Ausführung.

Lokal und komponiert blieben getrennt

Der lokale Wert beschrieb ein Element. Der komponierte Wert verband den bisherigen Pfad mit diesem Beitrag und wanderte weiter. Die Komposition konnte zum Empfänger oder zum Sender laufen.

Die Parameter galten konzeptionell per-next-hop. Ein gemeinsam genutztes Medium oder eine große Cloud konnte für zwei Ausgänge verschiedene Werte brauchen. Eine Geräteeigenschaft ohne Next-Hop-Kontext hätte die Routingentscheidung gelöscht. Eigene Kennungen für lokale und komponierte Werte hielten beide Ebenen sichtbar.

Der Endwert allein konnte seine Quellen nicht wiederherstellen: Ein Minimum verrät den Ort des Engpasses nicht, eine Summe nicht ihre Summanden und ein ODER-Bit nicht die Bruchstelle.

Der Default war kein Alleinanspruch

Service 1 bezeichnete den globalen Wert. Ein bestimmter Dienst durfte einen Override exportieren. Kam ein dienstspezifischer Zweig an, wurde er mit dem lokalen Override oder ersatzweise mit dem lokalen Globalwert komponiert und blieb dienstspezifisch. Traf ein globaler Zweig auf einen Override, entstand zusätzlich ein Dienstzweig; der globale Zweig lief weiter.

So konnte allgemeine Weiterleitung 1.500 Byte MTU tragen, während Guaranteed Service auf 250 Byte begrenzt war. Der kleinere Wert änderte nicht die Physik des Geräts, sondern die ausführbare Grenze des Dienstes. Eine einzige Zahl hätte eine der beiden Aussagen verfälscht.

Ein Bruch blieb wahr

NON_IS_HOP wurde gesetzt, wenn ein Element den betreffenden QoS-Dienst nicht unterstützte oder eine Lücke kannte. Die ODER-Komposition war monoton. Spätere fähige Router konnten eine frühere Lücke nicht rückwirkend beheben.

Bei einem Tunnel musste der Eintritt fehlende QoS-Kontrolle annehmen, solange kein Gegenbeweis vorlag. Das nicht unterstützende Gerät konnte das Bit jedoch gerade nicht selbst setzen. Nachbar, Signalisierungsprotokoll oder Konfiguration mussten die Lücke erkennen. Das Bit war keine selbstauthentisierende Aussage des fehlenden Geräts.

Ein globaler Bruch machte auch die übrigen Parameter möglicherweise ungenau. Ein Dienstbruch schwächte die Werte dieses Dienstes. RFC 2210 transportierte diese Warnung im ADSPEC; korrekte Übertragung war keine Heilung.

Gezählt wurden bekannte Mitwirkende

NUMBER_OF_IS_HOPS stieg an jedem fähigen Element um eins. Der Zähler nannte bekannte Beiträge, nicht zwingend alle physischen oder logischen Abschnitte. Ein unbekanntes Element konnte sich nicht mitzählen.

Hopzahl und Break-Bit gehörten deshalb zusammen. Fünf gezählte Teilnehmer bewiesen keinen ausschließlich fünfhoppigen Pfad. Fehlende Erfassung war nicht Nichtexistenz.

Bandbreite war ein Minimum von Vorabschätzungen

Der lokale Bandbreitenwert berücksichtigte Ressourcen, Administration und Policy; die Komposition nahm das Minimum. Doch die Eingaben entstanden vor einer konkreten QoS-Anfrage. Ziel, Dienst und Reservierungspolitik konnten noch unbekannt sein. RFC 2215 erlaubte daher sogar erhebliche Überschätzung, wenn keine bessere Angabe möglich war.

Ein beschränkter Dienst konnte einen kleineren Override liefern. Null bedeutete unbekannt, nicht null Kapazität. MIN hielt diese Null auf dem restlichen Pfad fest. Spätere positive Zahlen durften die Beweislücke nicht überschreiben.

Latenz summierte sich bis zur Unbestimmtheit

Die lokale Mindestlatenz umfasste die kleinste Ausbreitungs- und Verarbeitungszeit, nicht variable Warteschlangen. Sie war eine Basis für RFC 2212, aber weder beobachtete RTT noch dessen C/R + D-Grenze.

In einer Cloud waren Next-Hop-Werte vorzuziehen. Ein gemeinsamer Wert musste den kürzesten möglichen Weg nehmen und konnte den tatsächlichen Weg unterschätzen. Alternativ blieb „unbestimmt“.

Mikrosekunden wurden addiert und bei (2**32)-1 geklemmt. Dieser Wert bedeutete Unwissen – wegen eines fehlenden Beitrags oder wegen Überlauf. Er war keine extrem große präzise Messung.

MTU verwendete ebenfalls MIN, aber strengere Eingaben

Der lokale MTU war das größte IP-Paket ohne Fragmentierung, mit IP- und höheren Headern, ohne Link-Header. Jedes fähige Element musste einen korrekten Wert liefern. Ein Dienst-Override durfte den globalen MTU nur senken.

Der komponierte Wert blieb dennoch an Route und Dienstzweig gebunden. Er bewies weder Versand noch vollständige Tunnelerfassung, unveränderte Route oder Zustellung.

Ein TSpec wurde nicht komponiert

Parameter 127 definierte den Token-Bucket-TSpec. Zwischenknoten exportierten dafür keine lokalen Charakterisierungswerte. Ein Verkehrsvertrag im selben RFC war keine fünfte Pfadalgebra und keine Messung tatsächlicher Konformität.

Der Pfadwert blieb eine Zwischenstufe

RFC 1633, RFC 2205, RFC 2211, RFC 2212 und RFC 2216 beschrieben Architektur, RSVP, Dienste und Spezifikationsform. Keine Ebene machte die Charakterisierung automatisch zur Betriebswirklichkeit.

Ein prüfbarer Datensatz bewahrt ID, globalen oder spezifischen Zweig, Next Hop, Routepoche, lokale Quelle, Methode, Rechenregel, Unbestimmtheit, Anfrage, Zulassung, installierten Zustand, Beobachtung und Anwendungsergebnis getrennt.

Quellen und Grenzen

Primärquelle ist RFC 2215, ergänzt durch RFC Editor und IETF Datatracker. RFC 2815 zeigte später für IEEE 802, dass MTU und Break-Bits genau sein mussten, Bandbreite aber grob geschätzt werden durfte. Diese Texte beweisen keine heutige Verbreitung, Implementierung, Live-Reservierung, Leistung oder Störung.

Heng Lus Texte über Running-Code-Primat, minimale Regeln und lokale Entscheidung sowie Realitätsebenen liefern den redaktionellen Blick: Eine strukturierte Aussage kann leiten, aber nicht ausführen. Das ist keine Kausalbehauptung über 1997.