Zusammenfassung

  • Zwei lokal gewählte 16-Bit-Referenzen bezeichneten eine Transport Connection unabhängig von der Network Connection, über die ihre TPDUs liefen.
  • Multiplexing legte mehrere Transport Connections auf einen Netzträger; splitting konnte in Klasse 4 einen Transportzustand auf mehrere Träger verteilen.
  • Netzqualität, pervasive Funktionen, CR/CC-Aushandlung und Klassenregeln begrenzten die Trennung. Der Pfad war nicht die Identität, blieb aber eine wirksame Abhängigkeit.

Eine Transport Connection in RFC 892 konnte erst benutzt werden, nachdem sie einer Network Connection zugeordnet war. Bei splitting durften es mehrere sein. Eine geeignete bestehende NC konnte wiederverwendet oder eine neue aufgebaut werden.

Zuordnung und Gleichsetzung sind verschiedene Aussagen. Die NC erbrachte den unteren Dienst. Die TC hielt den Zustand zwischen Transportnutzern. Ohne Träger kam kein TPDU an; ohne Transportreferenz erklärte der Träger nicht, zu welchem Gespräch das TPDU gehörte.

Auch der Text besaß eine Zuständigkeitsgrenze. RFC 892 wurde nur zur Information verteilt und war ausdrücklich kein Standard für das ARPA Internet. RFC 905 ersetzte sie mit einer neueren Fassung des ISO DP 8073, ebenfalls ohne ARPA-Standardstatus. Die RFC-Reihe dokumentierte eine fremde Normungsarbeit, statt sie durch Aufnahme zu ratifizieren.

Beide Enden vergaben den Namen, den das andere benutzte

Der Initiator schickte einen Connection Request TPDU (CR) mit einer source reference. Der Responder antwortete mit Connection Confirm (CC) und seiner Referenz. Fortan setzte jede Seite den Wert des Partners als destination reference ein.

Die 16-Bit-Werte waren lokal. Null, bereits belegte und noch eingefrorene Referenzen waren unzulässig. Der Wert war weder globale Identität noch Berechtigungsnachweis. Erst die Empfangstabelle verband ihn mit einer lebenden TC.

RFC 892 nannte das Verfahren symmetrisch. Es vermied eine Master/Slave-Rolle und löste Verbindungsidentifikation ohne zentralen Nummerngeber. Gerade deshalb konnte die TC unabhängig von der NC identifiziert werden.

Ein gültiger Wert durfte trotzdem nicht aus beliebigem Kontext übernommen werden. TPDU-Phase, Zuordnung und Netzadressen mussten dieselben Transportentitäten erkennen lassen. Die Referenz belegte Protokollzustand, nicht Betreiberidentität, Authentisierung oder Anwendungszustimmung.

Die Annahme des Rufers war noch kein Vertrag

Klasse 0 war einfach. Klasse 1 brachte elementare Fehlererholung. Klasse 2 multiplexte. Klasse 3 verband Erholung mit Multiplexing. Klasse 4 erkannte und korrigierte zusätzlich Verlust, Duplikation, Beschädigung und Fehlordnung aus einem schwachen Netzdienst.

Im CR nannte der Initiator preferred class und mögliche Alternativen; bei bevorzugter Klasse 0 waren Alternativen ausgeschlossen. Er durfte zunächst so arbeiten, als werde die Präferenz bestätigt. Der CC machte daraus erst eine Auswahl. Wählte der Responder eine erlaubte Alternative, musste der Initiator seine Funktionen umstellen.

Die maximale TPDU-Größe wurde separat verhandelt. Der Responder konnte den Vorschlag annehmen oder auf einen zulässigen kleineren Wert gehen. Auch proposed options wurden erst durch selected options verbindlich. Eine bestehende NC bewies weder Klasse noch Größe noch Optionen.

Die Qualität des unteren Dienstes begrenzte die Wahl. RFC 892 unterschied Netze nach Restfehlern und signalisierten Ausfällen; Nutzeranforderung und Kosten kamen hinzu. Eine erreichbare NC konnte ungeeignet sein, wenn ihre Qualität nicht reichte oder eine bereits pervasive genutzte Funktion mit der neuen TC kollidierte.

Gemeinsame Träger erzeugten gemeinsame Randbedingungen

Beim Multiplexing teilten mehrere TC eine NC. Die destination reference jedes TPDU wies zum richtigen Transportzustand. Aufbaukosten und Kapazität wurden geteilt, ohne Sequenzen und Verbindungszustände zu verschmelzen.

Pervasive Funktionen machten die Unabhängigkeit begrenzt. Wurde eine solche Funktion für die erste TC einer NC eingesetzt, galt sie während der NC-Lebenszeit für alle weiteren TC auf diesem Träger. Ein gemeinsamer Pfad war keine gemeinsame Identität, aber gemeinsame Konfiguration.

Splitting and recombining drehte die Beziehung um. Eine TC konnte mehrere NC für Resilienz oder Durchsatz verwenden. Die Funktionsmatrix beschränkte das auf Klasse 4. Daraus folgt kein allgemeines Multipath-Versprechen, sondern die Fähigkeit, einen Transportzustand über einer Trägermenge zu modellieren.

Reassignment erlaubte in den Klassen, die es aufriefen, nach einem providerseitigen Disconnect eine neue NC und anschließend Resynchronization. Der Partner erkannte die Zuordnung an einem gültigen TPDU, passenden Netzadressen und den bereits bestehenden Referenzen.

Klasse 0 zeigt die Gegenregel. Es gab keine unabhängige Transportfreigabe; die TC-Lebenszeit korrelierte direkt mit der NC-Lebenszeit. Schichtentrennung war eine nachweisbare Klassenfunktion, kein Architekturmarketing.

TCP übernahm später die Rolle des unteren Dienstes

RFC 983 schlug vor, ISO-TSAP-Dienste nach oben anzubieten und intern TCP/IP zu verwenden. ISO-Session-, Presentation- und Application-Schichten sollten den Trägerwechsel nicht kennen müssen. Ein vollständiger Übergangsplan blieb ausdrücklich außerhalb des Dokuments.

RFC 1006 ersetzte den Entwurf mit Version 3 und standardisierte ISO Transport Klasse 0 über TCP. TCP lieferte einen Oktettstrom; TP0 erwartete abgegrenzte Einheiten. Ein längenmarkiertes TPKT stellte die TPDU-Grenze wieder her. Es war kein Authentisierungs- oder Integritätsmechanismus.

TCP open wurde zum unteren Aufbau, TCP close zum Disconnect. Wegen Klasse 0 lagen die Lebenszeiten eng beieinander. Trotzdem blieben die ISO-Transport-Schnittstelle und TPDU-Form über einem anderen unteren Protokoll erhalten.

RFC 2126 verfeinerte das Modell für TCP über IPv4 oder IPv6 und beschrieb Klasse 0 und 2. Sie behielt die TPKT-Version zum Schutz der RFC-1006-Basis bei. TCP-Port 102 blieb reserviert, war aber nicht für jede konforme Verbindung vorgeschrieben.

Das aktuelle IANA-Register für Dienstnamen und Ports führt iso-tsap auf 102. Der Eintrag belegt Koordination, nicht eine Implementierung, ausgehandelte Klasse, lebende Referenz oder erfolgreiche Anwendung.

Quellen und Grenzen

Die Darstellung stützt sich auf RFC 892, RFC 905, RFC 983, RFC 1006, RFC 2126 und IANA. Sie belegen Mechanismen, Dokumentstatus und TCP-Abbildung. Sie belegen keine heutige Verbreitung, allgemeine OSI-Einführung, direkte Abstammung zu QUIC oder SCTP, universelles splitting, Peer-Authentisierung oder ein benanntes Produktverhalten.