Zusammenfassung

  • Ein TALI-2.0-Peer musste die Gegenstelle zunächst als Version 1.0 behandeln, bis eine moni-Nachricht Version 2.0 meldete; neue Opcodes waren an diesen Nachweis gebunden.
  • RFC 3094 war ein Informational-Vorschlag von Tekelec. Der IESG-Hinweis sagte ausdrücklich, dass er eine Alternative zur SIGTRAN-Arbeit darstellte und das IETF seine technische Solidität und Vollständigkeit nicht geprüft hatte.

Die Grenze liegt noch vor dem ersten SS7-Austausch. RFC 3094 beschreibt TALI, die Transport Adapter Layer Interface, als Tekelecs Vorschlag für Signalübertragung zwischen einem leitungsvermittelten Netz und IP. Ein Signaling Gateway sollte SCCP-, ISUP- und MTP-bezogene Nachrichten über TCP/IP transportieren können, ergänzt um Verwaltungsfunktionen und dynamische Circuit-Registrierung. Die Spezifikation ist detailliert: Nachrichtenformate, Timer, Peer-Zustände und getrennte Abläufe für TALI 1.0 und 2.0. Detailtiefe macht daraus jedoch weder einen Internetstandard noch einen Nachweis für den Einsatz.

Die Einleitung der RFC sagt das ausdrücklich.

Der IESG-Hinweis ordnet TALI als Herstelleralternative zu Standards-Track-Technologien ein, die die SIGTRAN-Arbeitsgruppe des IETF damals entwickelte. Das IETF habe die technische Solidität und Vollständigkeit nicht geprüft; potenzielle Anwender sollten vor einer Entscheidung auch die SIGTRAN-Arbeit untersuchen. Dort steht nicht, TALI sei für unsolide befunden, zurückgewiesen oder nachweislich nie eingesetzt worden. Der Hinweis begrenzt den Prüfstatus und empfiehlt einen Vergleich.

Das deutlichste technische Problem innerhalb von TALI ist die Rückwärtskompatibilität. Version 1.0 hatte keine einfache Methode zur Versionsbestimmung. Version 2.0 verwendet die bestehende moni-Nachricht erneut: Zwölf feste Oktette im Datenfeld tragen das Versionslabel, der folgende Bereich bleibt implementierungsspezifisch; insgesamt darf das Datenfeld 200 Oktette nicht überschreiten. moni behält zugleich seine Echo-Funktion, etwa für Laufzeitmessungen oder lokale Zwecke.

Beim Verbindungsaufbau setzt eine 2.0-Implementierung far_end_version auf 1.0. Sie kann ihre eigene Version mitteilen, darf aber nicht unterstellen, dass die Gegenseite dieselben Fähigkeiten hat. Sie muss eine empfangene moni-Nachricht auswerten und ein bekanntes Versionslabel erkennen. Kommt keine solche Meldung an oder ist das Label unbekannt, bleibt der Peer eine 1.0-Gegenstelle.

Dieser Zustand sperrt oder erlaubt drei neue Opcodes: mgmt, xsrv und spcl. Ein 1.0-Empfänger würde sie als ungültig ansehen und den Socket sofort schließen. Deshalb darf ein 2.0-Knoten sie erst senden, wenn die Gegenseite als 2.0 oder höher erkannt wurde. Bei einem 1.0-Peer fällt er auf 1.0-Funktionen zurück. Laut Spezifikation können 1.0-Implementierungen zusätzliche moni-Daten ignorieren und den üblichen Monitor-/Bestätigungsdialog fortsetzen. Kompatibilität heißt nicht, dass beide Seiten jede Funktion verstehen. Sie verhindert, dass der Sender einen Opcode verschickt, den der ältere Peer ablehnt.

Das ist eine beobachtbare Kontrollfläche, kein abstrakter Kompatibilitätsspruch. Die lokale Implementierung meldet eine Version; die Gegenstelle liefert einen Hinweis; die Zustandsmaschine speichert diese Beobachtung; und die Opcode-Sperre entscheidet, welche Funktion den Socket passieren darf. Eine Versionsnummer im Dokument oder die lokale Konfiguration ersetzt nicht die empfangene Peer-Angabe.

Auch die umgebende Standardisierungsgeschichte verlangt Zurückhaltung. RFC 2719 hatte die SIGTRAN-Architektur bereits beschrieben. Spätere Standards-Track-Dokumente definierten Anpassungsschichten wie M2UA, M3UA und SUA; SCTP wurde in dieser Arbeit ebenfalls als Transport verwendet. RFC 3094 erörtert selbst einen alternativen SCTP-Protokollstapel. Diese Dokumente belegen verwandte parallele und spätere Spezifikationsarbeit, nicht aber, dass TALI ersetzt wurde, ein bestimmtes Netz migrierte oder zwei Implementierungen interoperierten.

RFC 3094 ist auf April 2001 datiert, als Informational klassifiziert und erklärt, keinen Internetstandard festzulegen. Veröffentlichung, spezifizierter Mechanismus und Prüfgrenze sind getrennte Tatsachen. Eine ausführliche Zustandsmaschine belegt keinen Einsatz; ein IESG-Hinweis belegt kein technisches Scheitern. Dafür wären laufende Implementierungen, Tests, Betriebsunterlagen oder beobachteter Verkehr nötig.

Quellen