Zusammenfassung

  • Ein gemeinsamer VC sparte Leitungen und Aufbauzeit, setzte RSVP-Aktualisierungen aber denselben Verwerfungen aus wie nicht vertragskonforme Daten.
  • Ein getrennter Signalisierungs-VC bot einen eigenen Verkehrsvertrag, jedoch keinen Gesamtnachweis: Zulassung, Transport, rechtzeitige Zustandsaktualisierung und Datendienst blieben getrennte Ergebnisse.

Die Entscheidung wirkte sparsam. RSVP hielt Reservierungen mit periodischen PATH- und RESV-Nachrichten aufrecht. ATM transportierte Pakete über virtuelle Verbindungen mit Verkehrsverträgen. Lief die Steuerung über den zugehörigen Daten-VC, musste weder eine zusätzliche Verbindung aufgebaut noch auf deren Signalisierung gewartet werden.

Sobald Daten den Vertrag verletzten, änderte sich die Rechnung. Die Verwerfung nicht konformen Verkehrs konnte auch die darin mitgeführte RSVP-Nachricht treffen. Gelegentliche Verluste waren einkalkuliert. Anhaltende Verluste konnten Soft State auslaufen lassen, den QoS-VC abbauen und einen neuen Aufbau auslösen. Eine Maßnahme zur Verringerung von Signalisierung erzeugte so zusätzliche Signalisierung.

Soft State brauchte einen rechtzeitigen Empfang

RFC 2205 machte RSVP-Zustand absichtlich vergänglich. PATH und RESV erzeugten und erneuerten ihn. Traf vor Ablauf des Cleanup Timeout keine passende Aktualisierung ein, wurde er gelöscht. So verschwanden überholte Reservierungen nach Routen- oder Gruppenänderungen auch ohne vollkommen zuverlässigen Löschvorgang.

Wiederholung half gegen einzelne Verluste, nicht gegen dauerhafte Aushungerung. RFC 2205 empfahl deshalb eine Mindestbandbreite, um RSVP-Nachrichten vor Überlastungsverlusten zu schützen.

Ein Sendezähler belegte nur die Emission. Für das Ergebnis zählten gewählter VC, Vertrag, Zulassung, Überquerung des ATM-Abschnitts, Empfangszeit und neue Zustandsfrist. Ein aktiver VC konnte mit abgelaufenem RSVP-Zustand existieren. RSVP-Zustand konnte ohne zugelassenen Daten-VC bestehen. Beides zusammen bewies noch keine Anwendungsleistung.

Vier Varianten verteilten den Fehlerbereich

RFC 2382 ordnete vier Familien: Signalisierung auf dem Daten-VC; ein paralleler RSVP-VC je Reservierung; ein gemeinsam genutzter Point-to-Multipoint-VC für Sitzungen mit identischem Ingress und Egress-Satz; oder mehrere zwischen Sitzungen multiplexierte Point-to-Point-VCs.

Das gemeinsame Modell minimierte die Zahl der VCs und vermied zusätzlichen Aufbau vor PATH. Dafür erbte die Steuerung die Behandlung des Daten-VC. Das RFC warnte, dass nicht konforme Daten RSVP-Nachrichten verlieren lassen und übermäßige Verluste wiederholten Abbau und Neuaufbau von QoS-VCs verursachen konnten.

Ein Best-Effort-Pfad trennte die Steuerung von der Nichtkonformität auf dem QoS-VC, nicht aber von ATM-Überlastung. RFC 2382 verlangte eine bevorzugte Klasse. Priorisierung im IP-Scheduler vor ATM erschien aussichtsreich, war jedoch schwierig und noch zu untersuchen.

Ein eigener Signalisierungs-VC kaufte Isolation durch einen separaten Vertrag. Konforme Steuerpakete wurden nicht wegen des Datenverkehrs auf dem anderen VC verworfen. Die Kosten waren doppelt so viele Mindest-VCs, zusätzliche ATM-Signalisierung und Aufbauverzögerung.

Multiplexing vergrößerte den nötigen Kontext

Ein Point-to-Multipoint-Steuer-VC passte nur, solange Sitzungen denselben Eingang und dieselbe Ausgangsmenge teilten. Änderungen der Teilnehmer erforderten einen passenden vorhandenen VC, einen neuen VC, eine Änderung des bestehenden oder fortgesetzte Sendungen an nicht mehr benötigte Ziele.

Der Nutzen hing damit von Topologie und Verkehrsmuster ab. Langlebige Point-to-Point-VCs im Kern konnten Aufbaukosten verteilen und Rückkanäle nutzen, ihre Zahl folgte weiterhin den beteiligten Knoten. Die Wiederverwendung eines Best-Effort-VC sparte eine Verbindung und erhöhte das Verlustrisiko.

Auch der Nachweis musste dynamisch sein. Zu Nachricht, VC und Vertrag kamen bei Multiplexing die damalige Session-Zuordnung und Egress-Menge. Eine bloße VC-Liste zeigte nicht, welche Reservierungen von einem ausgefallenen Steuerpfad abhingen.

Zu viel Steuer-QoS konnte die Zulassung verhindern

Eine große QoS-Zuteilung war keine kostenlose Lösung. RSVP-Nachrichten waren selten, typischerweise etwa alle dreißig Sekunden, sodass eine kleine Zuteilung reichen sollte. Eine überhöhte Anforderung konnte den Steuer-VC bei knappen Ressourcen selbst scheitern lassen.

Best Effort als Rückfall enthielt denselben Widerspruch. Scheiterte der QoS-Aufruf an ATM-Überlastung, musste das Rückfallpaket dieses überlastete Netz mit weniger Schutz durchqueren. Verfügbarkeit eines Fallbacks bewies keinen Transport.

RFC 1755 hatte bereits Connection Thrashing durch Verbindungsverwaltung verhindern wollen. RFC 2382 zeigte eine weitere Ursache: Verlust des Steuertransports, Ablauf des Zustands, Abbau des Dienstes und zusätzliche Arbeit für den Neuaufbau.

Eine belastbare Kette umfasste Nachrichtenerzeugung, VC- und Behandlungswahl, Zulassung, ATM-Transport, Erneuerung vor Ablauf, Fortbestand des Daten-VC und gemessenen Dienst. Der Erfolg einer Stufe galt nicht für die nächste.

RFC 2382 schrieb keine universelle Topologie vor. Es machte gemeinsame, getrennte und multiplexierte Pfade vergleichbar, ohne ihre unterschiedlichen Kosten und Belege zu verwischen. Die Mindestanforderung war ein ausreichend geschützter und beobachtbarer Weg, der den von ihm behaupteten Soft State tatsächlich erhielt.