Zusammenfassung

  • RFC 3387 zeigte die fehlende Managementschicht zwischen differenzierter Paketbehandlung und einem eindeutig definierten, zugelassenen, prüfbaren und abrechenbaren Dienst.
  • Die erforderlichen Belege lagen am Zugang, im Kern und an Verwaltungsgrenzen; kein Klassenmerkmal, Policy-Eintrag oder Zähler durfte das Endergebnis vertreten.

Der Verkäufer zeigt einen Zähler für bevorzugte Pakete. Der Netztechniker zeigt die aktive Scheduler-Konfiguration. Der Kunde zeigt eine Anwendung, die ihr Zeitfenster verpasst hat. Diese drei Aussagen widersprechen sich nicht. Sie beobachten unterschiedliche Stufen einer Leistungskette.

RFC 3387 untersuchte genau diese Trennung. Das im September 2002 als Informational veröffentlichte Papier aus dem IRTF Service Management Research Group definierte weder ein neues Protokoll noch eine fertige Einführung. Es stellte fest, dass Mechanismen für IntServ, DiffServ, Policy und Traffic Engineering weiter waren als die Dienstverwaltung um sie herum.

Best Effort passte zur frühen Vorliebe des IP für Einfachheit und verteilte Kontrolle. Differenzierung fügte eine knappe Ressource und damit eine Zuteilungsentscheidung hinzu. Wer eine bessere Behandlung versprach, musste erklären, was „besser“ bedeutete, wer sie anfordern durfte und wie mehrere unabhängige Netze gemeinsam dafür einstanden.

Das Dokument trennte Dienstdefinition und Dienstinstanz. Eine Definition musste eindeutig sein und sich auf reale Netzfähigkeiten abbilden lassen. Die Instanz musste diese Definition durch Ressourcen und Steuerung verkörpern. Ein Informationsmodell beschrieb Absicht; ein Policy-Objekt bewies weder installierte Konfiguration noch Pfadzulassung oder gemessene Wirkung.

Am Zugang gehörten Authentisierung, Autorisierung und Admission Control zu getrennten Entscheidungen. Hinzu kamen Parameterprüfung, Abrechnungsschnittstellen, Dienstprüfung, Fehlermeldung, Wiederherstellung und Beendigung. Eine erlaubte Anfrage konnte an fehlenden Ressourcen scheitern. Eine zugelassene Ressource sagte noch nichts über korrekte Paketklassifikation.

Im Kern lagen Traffic Engineering, Gerätekonfiguration, Ressourcenmeldung, Fehlererkennung und Wiederherstellung. RFC 3387 erwog zentralere Berechnung, weil ein einzelner Hop nicht alle für eine Pfadentscheidung nötigen Daten kannte. Zugleich stellte es die Architekturfrage: Überwiegt der Nutzen einer mittleren Dienstfunktion ihre Komplexität und ihr Destabilisierungspotenzial?

An Verwaltungsgrenzen trafen Technik und Wettbewerb zusammen. Anbieter brauchten Dienstsignalisierung, Accounting, Verifikation, Verkehrsmessung und den Austausch von Abrechnungsdaten, wollten aber interne Kapazitäten nicht offenlegen. Ein bilaterales SLA regelte eine Grenze. Viele bilaterale Verträge erzeugten ohne gemeinsame Metriken, Uhren und Fehlerregeln keine quantitative Ende-zu-Ende-Garantie.

Bandwidth Broker und vertrauenswürdige Dritte waren mögliche Antworten, keine Vorschrift. Sie konnten Zulassung, Preise, Zahlung oder Prüfung vermitteln. Ihre Aufgabe, Belege zu transportieren, gab ihnen jedoch nicht automatisch Entscheidungsgewalt über gleichrangige Domänen.

Abrechnung musste laut RFC 3387 schon bei der Dienstentstehung zusammen mit Sicherheit geplant werden. RFC 2975 trennt Accounting als Sammlung von Nutzungsdaten, Charging als Anwendung einer Preisregel und Billing als Zahlungsforderung. Zahlung ist wiederum ein eigener Zustand. Ein richtiger Zähler kann mit einem falschen Tarif verbunden sein; eine richtige Rechnung kann offen bleiben; eine Zahlung beweist keine technische Erfüllung.

Für DiffServ galt dieselbe Grenze. Ein PHB beschreibt lokales Verhalten pro Hop oder Domäne. RFC 3387 sagte ausdrücklich, dass eine Klassenbehandlung pro Hop keine Ende-zu-Ende-Garantie ist. Ein Kunde erwartet Bandbreite, Verzögerung oder Fehlerrate über den Pfad, nicht nur die korrekte Abfahrt aus einer Warteschlange.

Auch Best-Effort-Verkehr trug ein Risiko. Reservierte Kapazität konnte ungenutzt bleiben und trotzdem nicht allgemein verfügbar sein. Höherer Umsatz schuf einen Anreiz, Premiumverkehr zu bevorzugen. Das Papier behauptete keinen gemessenen Schaden; es machte den Interessenkonflikt prüfbar.

Lu Hengs Running-Code Primacy begrenzt die gemeinsame Schicht. Gemeinsam sein sollen nur deterministische Regeln für Interoperabilität, Identität, Autorisierung, Messung und Sicherheit. Interne Ressourcen- und Preisentscheidungen bleiben lokal. Ein Verzeichnis, Prüfer oder Broker kann Nachweise austauschen, ohne zur Quelle ihrer Gültigkeit zu werden.

RFC 3387 lieferte keine fertige Architektur. Sein historischer Wert besteht darin, die Abkürzungen zu verbieten: Markierung ist keine Berechtigung, Policy keine Kapazität, Behandlung kein Dienst, Accounting keine Zahlung und ein lokaler Erfolg kein Anwendungsergebnis. Die Warteschlange konnte unterscheiden; der Betreiber musste noch eine verantwortbare Leistung daraus machen.

Quellen