Zusammenfassung

  • Ein ST-II-Zwischenagent durfte CONNECT bestätigen, einen lokalen Hop Identifier genehmigen und Ressourcen anfordern, bevor die Zielanwendung entschieden hatte.
  • Das getrennte ACCEPT des Ziels brachte die auf diesem Ast tatsächlich erreichte FlowSpec zurück; sie konnte vom ursprünglichen Wunsch abweichen.
  • Bei mehreren Zielen musste der Ursprung alle Ergebnisse zusammenführen. Auch danach bewies der Zustand weder Datenlieferung noch nutzbare Medienausgabe.

Die Bestätigung gehörte dem Nachbarn

RFC 1190 erschien im Oktober 1990 als Experimental Internet Stream Protocol Version 2, ST-II. Es war ein Limited-Use Experimental Protocol und kein Internet Standard. Die Einträge bei RFC Editor und IETF Datatracker dokumentieren die spätere Ablösung durch RFC 1819, nicht den Betrieb eines konkreten Streams.

Wenn ein Zwischenagent CONNECT empfing, sollte er zügig mit ACK, HID-REJECT oder HID-APPROVE antworten. HID bezeichnete einen lokalen Kurznamen für schnelles Weiterleiten. Danach rief der Agent Routing und Ressourcenverwaltung auf und schickte neue CONNECT-Nachrichten zu den nächsten Ästen.

Ein positives HID-APPROVE sagte deshalb etwas Reales und Enges: Diese benachbarten Agenten konnten den vorgeschlagenen handle für ihren Hop verwenden. Die Nachricht sagte nicht, ob der restliche Pfad genügte, ob das Zielprogramm existierte oder ob es teilnehmen wollte. Der Besitzer lokalen Weiterleitungszustands vertrat nicht den entfernten Prozess.

Der Stream war Zustand, Pfad und Ressource

ST-II lag auf derselben Schicht wie IP. Seine Datenpakete waren nicht unabhängig. Vor ihnen entstand ein gerichteter simplex tree von einem origin zu einem oder mehreren targets. Zu einem Stream gehörten die Pfade, die reservierten Ressourcen und der in jedem Agenten geführte Zustand.

Die Architektur verlagerte Aufwand in die setup phase. TargetList wurde nach next hops geteilt. Der globale Name hielt den Stream zusammen; Virtual Link Identifier adressierte den Kontrollautomaten; HID beschleunigte den späteren data path. Multicast konnte Kopien sparen, erforderte aber gemeinsame Bezeichnerabstimmung.

Diese technischen Identifikatoren waren weder Personenidentität noch Vollmacht. Ein Name identifizierte Protokollzustand, eine TargetList Blätter, ein HID den lokalen Zugriff und ein SAP die höhere Anwendung. Ihre Existenz schloss keine Entscheidung der jeweils anderen Ebene.

Desired und Limits waren keine Synonyme

Die FlowSpec enthielt gewünschte Werte und unveränderliche Mindestgrenzen. Bekam ein Ast nicht die volle gewünschte Bandbreite, fügte mehr Verzögerung hinzu oder brauchte kleinere PDUs, durfte ein Agent Desired auf die tatsächlich erhaltenen Werte setzen, solange die Limits eingehalten blieben.

Ressourcen bedeuteten außerdem forwarding information, switch processing, buffer space, network bandwidth und multicast identifiers. RFC 1190 schrieb kein einheitliches Verfahren für alle darunterliegenden Netze vor. Es stellte offen fest, dass damals nur wenige Netze Reservierung boten und keines den vollständigen Katalog bereitstellte.

Eine belastbare Reservierungsakte braucht daher Agent, lokalen Ressourcenentscheider, Ast, Ziel, angefragte und erhaltene Parameter, Zeit und Preemption-Regel. „Reserviert“ ohne diese Koordinaten macht aus einem bedingten lokalen Schritt einen globalen Leistungsbeleg.

Das Ziel sah erst die unterwegs veränderten Bedingungen

Am Ziel beendete der host agent zunächst die HID-Verhandlung. Dann legte er Name, FlowSpec, Options, Group und Anwendungsselektor dem bezeichneten Prozess vor. Die Anwendung durfte annehmen, ablehnen oder den gewünschten Dienst weiter verringern.

Erst diese Entscheidung erzeugte ACCEPT oder REFUSE. ACCEPT erhielt eine eigene Reference und verwies über LnkReference auf das frühere CONNECT. Jeder Zwischenagent prüfte den Zusammenhang, bestätigte seinem nächsten Nachbarn und leitete eine neue Antwort auf dem Rückweg weiter.

Damit blieben die Zuständigkeiten sichtbar. Routing wählte den Ast. Der lokale Manager stellte Ressourcen. Nachbarn einigten sich über einen handle. Das Ziel entschied Teilnahme. Der Ursprung entschied, ob er die zurückgekehrten Bedingungen annahm. Kein früherer Erfolg konnte die spätere Instanz binden.

Mehrere Ziele ergaben kein automatisches Gesamtversprechen

Der Ursprung erwartete für jedes target ein ACCEPT, REFUSE oder einen Fehler. Er konnte jede Antwort einzeln melden, durfte setup aber erst nach allen Ergebnissen und Identifier-Verhandlungen abschließen.

Die FlowSpecs verschiedener Äste konnten nicht zusammenpassen. Ein Pfad erlaubte große Pakete bei kleiner Rate, ein anderer kleine bei hoher Rate. Der Ursprung musste möglicherweise Ziele löschen, den Stream abbrechen oder einen zweiten aufbauen. Mit CHANGE gab er anschließend überschüssige Ressourcen frei.

Das ACCEPT eines Ziels war also kein Mehrheitsentscheid für den Baum. Es beschrieb genau diesen Ast. Die aggregierte Konfiguration entstand erst durch eine weitere Entscheidung am Ursprung.

Annahme blieb vorläufig gegenüber Störung und Ergebnis

Auch die Rückmeldung musste bestätigt werden. Erhielt ein Agent trotz Wiederholung kein ACK für sein ACCEPT, ersetzte er es durch REFUSE zum Ursprung und DISCONNECT zum Ziel. Ein höher priorisierter Stream konnte Ressourcen verdrängen. NOTIFY meldete eine verringerte Garantie. Ein fehlgeschlagenes CHANGE konnte nur teilweise vollzogen sein und recovery erzwingen.

ST bot zudem selbst keine Sicherheitsdienste. Weder Hop-ACK noch ACCEPT authentisierten einen Menschen, erteilten Geschäftsberechtigung oder rechtfertigten eine Rechnung. Gelieferte Pakete, decodierte Sprache und die Wahrnehmung eines Teilnehmers lagen hinter weiteren Evidenzgrenzen.

Die Nachfolgeversion entfernte gerade den genehmigten Bezeichner

RFC 1819 überarbeitete ST-II 1995 zu ST2+. RFC Editor und Datatracker bewahren den Datensatz. Der IESG-Hinweis sagt ausdrücklich, dass weder alte noch neue Version Internet Standard war oder dafür erwogen wurde.

ST2+ behielt CONNECT, lokalen resource manager, Zielentscheidung und zurückkehrendes ACCEPT. HIDs verschwanden hingegen, weil ihre Komplexität die Interoperabilität behinderte. Auch subset implementations entfielen: Die erlaubte Teilmenge hatte keine gemeinsame Fähigkeit garantiert.

Die lokale Kennung war also austauschbar; die Entscheidungshoheit des Ziels nicht. Revisionserfahrung trennte wire format, Implementierungsfähigkeit, Reservierung und Teilnahme noch deutlicher.

RFC 1077 hatte Hochgeschwindigkeit schon als Systemproblem statt bloße Medienrate behandelt. Spätere RFC 1633 und RFC 2212 beschrieben andere Reservierungs- und Garantiedienstmodelle. Ähnliche Fragen belegen weder direkte Abstammung noch allgemeine Einführung.

Quellen