Zusammenfassung

  • ATM UNI konnte die QoS eines laufenden VC nicht ändern. Der alte Kanal blieb aktiv, während der Ersatz entstand; erst dessen Fertigstellung erlaubte Umschaltung und Abbau.
  • Scheiterte der Ersatz, führte eine Erhöhung zum Fehler, eine Verringerung konnte aber trotz größerer Altbelegung als erfolgreich gelten.

Erfolg ohne passende Physik

RSVP ließ Reservierungen jederzeit ändern, ATM UNI 3.x/4.0 nicht. RFC 2380 verlangte daher Ersatz: alten VC unverändert betreiben, neuen aufbauen, Verkehr erst nach Fertigstellung verlagern und dann den alten schließen. Scheiterte der Aufbau, blieb der alte VC.

Bei einer Erhöhung fehlten zusätzliche Ressourcen, also musste ein Fehler folgen. Bei einer Verringerung erfüllte der größere Altkanal die kleinere Forderung bereits; die Änderung galt als gelungen. Das war ineffizient, sicherte aber Dienst und RSVP-Fehlerlogik. Die Antwort bewies keine Freigabe von Kapazität. Sollwert und installierte Belegung brauchten getrennte Belege.

Stille durfte nichts abbauen

Gewöhnliche IP-over-ATM-VCs konnten bei Inaktivität verfallen. RSVP besaß eigene Nachrichten und Fristen für die Lebensdauer. Der Initiator brauchte deshalb einen praktisch unendlichen Timer, und der Empfänger durfte eine RSVP-Verbindung nicht wegen Stille löschen. Verkehrsstille war Messung, kein Freigabebefehl.

Empfänger fordert, Sender baut

RSVP war empfängerorientiert, ATM-Steuerung senderorientiert. Der Subnetzsender initiierte QoS-VCs, der Empfänger nahm sie an. RESV war keine Quittung für einen fertigen Kanal.

Kontrolle und Daten durften den zugehörigen QoS-VC nicht teilen. Unbehebbarer Daten-VC-Ausfall war Allokationsfehler; unbehebbarer Kontroll-VC-Ausfall erforderte die Freigabe der QoS-VCs, damit Weiterleitung nicht ohne Reservierungszustand fortbestand.

Multicast bevorzugte kurze Duplikate

Alter und neuer VC zugleich konnten duplizieren; ein unvollständiger neuer VC konnte Empfänger auslassen. Ein neuer Multicast-VC wartete auf alle Teilnehmer. Beim Umzug eines Endpunkts in einen bestehenden QoS-VC galt add before drop: erst hinzufügen, dann vom Best-Effort-Pfad entfernen. Kurze Duplikate verhinderten eine Lücke.

Kleinere Anforderung, positive Antwort, größerer Kanal, unveränderte Kosten und kontinuierlicher Dienst konnten gleichzeitig wahr sein.