Zusammenfassung

  • RFC 2379 empfahl, RSVP-Kontrollnachrichten über den bereits vorhandenen Best-Effort-Datenpfad zu befördern, obwohl diese Nachrichten separate ATM-Verbindungen mit festgelegten Dienstgüteparametern auslösen sollten.
  • PATH oder RESV, RSVP-Zustand, Zulassung, konfigurierter VC und gemessene Anwendungserfahrung sind aufeinanderfolgende Belege; keiner ersetzt die anderen.

Eine Garantie über einen ungarantierten Weg bestellen

RSVP sollte Ressourcen reservieren, ATM konnte virtuelle Verbindungen mit bestimmten Dienstmerkmalen aufbauen. Trotzdem verlangte RFC 2379 keinen geschützten Signalisierungskanal als ersten Schritt. Bei Unicast liefen RSVP-Nachrichten über den VC zum Ziel, bei Multicast über den vorhandenen Best-Effort-Pfad zur Gruppe.

Der Grund war die Zahl der Verbindungen. Noch bevor eine Sitzung eingerichtet und eine Reservierung angestoßen werden konnte, musste ein gewöhnlicher Pfad vorhanden sein. Ihn auch für die Kontrolle zu nutzen, vermied zusätzliche ATM-VCs, die nur dazu gedient hätten, weitere VCs zu bestellen. Die Kontrollebene durfte also einen stärkeren Datendienst über einen schwächeren Transport anfordern.

Der Text erklärte Best Effort nicht nachträglich für zuverlässig. Er räumte ein, dass ein solcher VC nicht die gesamte Zuverlässigkeit bieten könnte, die RSVP-Kontrolle wünschte. Die Toleranz entstand aus der Zeitstruktur: RSVP hielt Soft State, der regelmäßig erneuert wurde. Der Verlust eines Pakets musste die Synchronisation nicht beenden, wenn eine spätere Auffrischung den Zustand bewahrte oder wiederherstellte.

Verlust war damit nicht bedeutungslos. Ob eine fehlende Nachricht schwer wog, zeigte sich an späteren Auffrischungen, Ablauf, Zulassungsentscheidung und Fortbestand der Verbindung. Umgekehrt bewies eine gesendete Nachricht keine erfolgreiche Reservierung. Zuverlässigkeit entstand aus der Folge von Beobachtungen.

Für jede Reservierung ein eigener VC

ATM legte Aggregation nahe. Mehrere RSVP-Sitzungen hätten sich theoretisch eine Verbindung teilen können. Doch Aggregation war noch Forschungsgegenstand. RFC 2379 empfahl deshalb einen unabhängigen VC pro RSVP-Reservierung.

Diese Vorsicht machte die Umwandlung sichtbar. Eine RSVP-Sitzung war noch keine ATM-Verbindung. Die Reservierung musste in ATM-Dienstparameter übersetzt, zugelassen oder abgewiesen, einem VC zugeordnet und durch einen Klassifizierer mit Verkehr gefüllt werden. Der vorhandene VC wiederum bewies nicht, dass die Pakete den verlangten Dienst erhielten.

Die Begleitdokumente teilten die Aufgaben bewusst: RFC 2380 beschrieb Implementierungsanforderungen; RFC 2381 ordnete Controlled Load und Guaranteed Service aus Integrated Services ATM zu; RFC 2382 lieferte den Rahmen. So konnte kein einzelnes erfolgreiches Signal als Erfolg der gesamten Kette gelten.

Der Shortcut erbte seinen Endpunkt

ATM-Shortcuts konnten Grenzen logischer IP-Subnetze überspringen. PATH und RESV konnten dadurch asymmetrische Routen nehmen. RFC 2379 stützte sich auf vorhandenes RSVP-Verhalten—das NHOP-Objekt und das Weiterleiten einer Nachricht, die an der falschen Schnittstelle eintraf—um damit umzugehen.

Entscheidend war die Autorität über den Endpunkt. Ein QoS-Shortcut sollte sein Ziel nicht selbstständig entdecken. Hatte Best-Effort-Verkehr bereits einen Shortcut-Endpunkt ausgewählt, sollte der von RSVP ausgelöste QoS-VC denselben Punkt verwenden. Ohne Best-Effort-Shortcut entstand im empfohlenen Modell auch kein subnetzübergreifender QoS-Shortcut.

Hop-by-Hop-QoS-VCs blieben möglich. Die Regel betraf die Herkunft der Shortcut-Entscheidung: Der Best-Effort-Kontext wählte zuerst, die QoS-Konfiguration folgte. Der resultierende VC belegte eine Konfiguration, nicht rückwirkend erfolgreiche Entdeckung, Zulassung und Lieferung.

Multicast ließ sich nicht vereinheitlichen

In einer Multicast-Sitzung konnten Empfänger unterschiedliche QoS-Stufen oder gar keine verlangen. Der Begleitrahmen unterschied vollständige Heterogenität, begrenzte Heterogenität, Homogenität und modifizierte Homogenität. RFC 2379 erklärte kein Modell für allgemeingültig. Mindestens begrenzte Heterogenität oder modifizierte Homogenität sollte unterstützt werden, vorzugsweise beide samt Auswahlmechanismus.

Diese Zurückhaltung ist historisch wichtig. Die Best Practice löschte betriebliche Vielfalt nicht zugunsten eines hübscheren Schaubilds. Sie setzte ein umsetzbares Minimum und ließ Unterschiede zwischen Empfängern sichtbar.

Vier getrennte Quittungen

Eine belastbare Lesart unterscheidet den Best-Effort-Pfad, der Kontrolle transportierte; den RSVP-Zustand samt Auffrischungen; das Zulassungsergebnis und den konfigurierten ATM-VC; sowie Zähler und Anwendungsbeobachtungen zum erhaltenen Dienst.

Gesendetes PATH ist nicht empfangenes RESV. RESV ist keine Zulassung. Ein lebender VC ist keine korrekte Klassifizierung. Ein QoS-Etikett misst weder Verzögerung noch Verlust noch Zustellung. Die Architektur verband diese Ebenen, ohne sie gleichzusetzen.