Zusammenfassung

  • In einer Aggregationsregion ignorierten innere Router die Ende-zu-Ende-RSVP-Nachrichten; DSCP-bezogene Aggregate trugen viele Flüsse. Gespart wurde Zustand im Kern, nicht der Einzelnachweis am Rand.
  • Der Deaggregator wählte die Zuordnung, meldete den DSCP in DCLASS zurück und rechnete den Token Bucket gegen die Kapazität. Erst danach klassifizierte und markierte der Aggregator die Daten.
  • Blockweise, prognostizierte Kapazität blieb absichtlich ungenau. Ein fehlgeleiteter RSVP-E2E-IGNORE-Path konnte zudem unbemerkt verschwinden. Ein grünes Aggregat reichte daher nie als Dienstbeleg.

Jeder Fluss belastete jeden beteiligten Router

Die Genauigkeit von RSVP beruhte auf Zuständen pro Reservierung. Nachrichtenaustausch, Berechnung und Speicher fielen an jedem beteiligten Knoten an. Mit der Zahl der Sitzungen wuchs damit auch die Steuerlast des gemeinsamen Kerns.

RFC 3175 verschob die Detailgrenze. Reservierungen mit gleichem Eintritt und Austritt konnten eine größere Reservierung teilen. Der erste Router wurde Aggregator, der letzte Deaggregator; dazwischen behandelten Router eine Klasse statt einzelner Kundenzusagen.

Das Ende-zu-Ende-Ziel blieb bestehen. Nur die gemeinsame Schicht wurde dünner. Die Ränder mussten weiterhin festhalten, welcher Wunsch welchen Anteil des Blocks beanspruchte.

Protokoll 134 war eine begrenzte Nichtzuständigkeit

Am Eingang änderte der Aggregator RSVP in RSVP-E2E-IGNORE, bei IANA als IP-Protokoll 134 registriert. Innere Router leiteten den Path weiter, ohne per-flow RSVP state anzulegen. Am vorgesehenen Ausgang stellte der Deaggregator RSVP wieder her.

Die Zahl bestätigte keine erfolgreiche Reservierung. Sie wies bestimmte Router an, die Nachricht nicht zu verarbeiten. Fehlte der richtig konfigurierte Ausgang, konnte der Path bis zum Ziel gelangen und dort als unbekannt verworfen werden. Im Inneren blieb der Fehler möglicherweise geräuschlos.

Darum brauchte der Eintritt einen korrelierbaren Ausgangsnachweis. Schweigen im Kern war Effizienz; Schweigen am Deaggregator war ein Bruch der Kette.

DCLASS übermittelte Politik, nicht Dienstqualität

DSCPs kennzeichneten aggregierten Verkehr, PHBs beschrieben die Behandlung pro Hop. Die Zuordnungspolitik blieb beim Betreiber. Der Deaggregator entschied, weil er zuerst den Resv des Empfängers und den verlangten IntServ-Typ sah.

Er sandte den gewählten DSCP in DCLASS zurück. Der Aggregator speicherte die Zuordnung, entfernte DCLASS vor der Weitergabe des Resv und markierte passende Pakete am Eingang.

Ein beobachteter DSCP beweist nur die Bits an dieser Stelle. DCLASS beweist die Übermittlung einer Wahl. Keines beweist richtige Klassifikation, freie Kapazität, die PHB-Konfiguration jedes Routers oder das Ergebnis der Anwendung.

Zulassung blieb eine Rechnung des Ausgangs

Bei ausreichender Kapazität addierte der Deaggregator den Token Bucket des E2E Resv zu seinem internen Verbrauch. Dieses Mitgliederkonto durfte nicht mit dem Kernzustand verschwinden.

Ein vorhandener Block nahm die nächste Anfrage nicht automatisch an. Session, bestehende Verpflichtungen, Politik und Restkapazität mussten geprüft werden. Fehlte aggregate Resv state, musste er entstehen; reichte die Kapazität nicht, musste sie wachsen oder die Zusage warten bzw. scheitern.

Die Skalierung war asymmetrisch: Der innere Zustand konnte nahezu unabhängig von der Zahl der Mitglieder sein, das Randkonto nicht.

Exakte Anpassung hätte den Gewinn zurückgenommen

Nach jedem Eintritt oder Austritt neu zu signalisieren, hätte den Aufwand wieder erhöht. Deshalb beschrieb RFC 3175 größere Blöcke und seltenere Änderungen. Tageszyklen und jüngste Trends konnten die Prognose steuern.

Feine Anpassung sparte Reserven und erzeugte mehr Signalisierung. Grobe Anpassung verringerte Änderungen, erhöhte aber Überschuss, Prognosefehler und Wiederherstellungsbedarf. Die Spezifikation machte daraus keinen universellen Algorithmus.

Prognose, konfigurierte Kapazität, belegte Kapazität, Zulassungsentscheidung, Schedulerzustand und Lieferung benötigen getrennte Messwerte. Ein gemeinsames Grün würde Unsicherheit in vermeintliche Gewissheit verwandeln.

Mit der Effizienz wuchs der Schadensradius

Aggregierte Flüsse waren weniger streng isoliert; Bursts konnten einander beeinflussen. Die im RFC zitierten Verzögerungsergebnisse gelten für untersuchte Bedingungen, nicht automatisch für heutige unbekannte Netze.

Der Verlust eines Aggregats traf viele Mitglieder. Überreservierung entzog anderen Klassen Mittel. Fehlklassifikation gab falschem Verkehr Vorrang. Weniger Steuerobjekte konzentrierten mehr Folgen in jedem Objekt.

Auch Integrität blieb begrenzt. Für versteckte E2E-Nachrichten erschienen Aggregator und Deaggregator als logische RSVP-Nachbarn; Aggregate wurden innerhalb der Region hop-by-hop geschützt. Ein gültiger Digest bewies Nachricht und Schlüsselbesitz im jeweiligen Scope, nicht Zuordnung, Kapazität oder Dienst.

Register und Erweiterungen belegen keine Nutzung

RFC 4804 behandelte Aggregation über MPLS-TE/DS-TE-Tunnel. RFC 4860 führte generische Aggregate ein, weil RFC 3175 mehrere Aggregate mit gleicher Quelladresse, Zieladresse und PHB nicht ausdrücken konnte. RFC 5350 änderte Router-Alert-Zuweisungen. IANA führt weiterhin 134 und die Aggregate-C-Types.

Damit ist die Normgeschichte belegt, keine Installation. Der bleibende Entwurfssatz lautet: Detail darf aus einer gemeinsamen Schicht verschwinden, wenn eine zurechenbare Schicht seine Beweiskette bewahrt.

Lu Hengs spätere Perspektiven auf Running Code, minimale gemeinsame Regeln und Realitätsebenen sind offengelegte Interpretation. Sie trennen Registrierung, lokale Regel, Konfiguration, Ausführung und Ergebnis. Aggregation ist dann Staatskompression, nicht Wahrheitskompression.

Quellen und Grenzen

Die Belege wurden am 2. Oktober 2026 in der Zeitzone Asia/Shanghai eingefroren. Sie stützen Mechanismus, IANA-Zuweisungen und spätere Spezifikationen, aber keine Implementierung, Verbreitung, gemessene Zustandsersparnis, Leistung, Störung, Betreiberhandlung oder gelieferte Qualität.