Zusammenfassung

  • RFC 3332s M3UA verwendete den Routing Key für einen Verkehrsbereich, den Routing Context zur Bezeichnung dieses Schlüssels und Network Appearance zur Unterscheidung eines lokalen SS7-Netzkontexts. Die Begriffe hingen zusammen, waren aber nicht austauschbar.
  • Ein ASP konnte über eine gemeinsame SCTP-Assoziation mehrere Application Server bedienen; sein Zustand wurde je AS geführt. Ein aktiver Transport belegte daher weder die Freigabe des betreffenden Verkehrs noch die Erreichbarkeit eines SS7-Ziels oder den Empfang einer Nachricht durch den MTP3-User.

Drei Bezeichnungen, drei verschiedene Fragen

Die Terminologie von M3UA wirkt wie eine Wortwahlfrage, bis ein Point Code wiederverwendet wird. Ein SS7-Netz kann einen Signalpunktcode vergeben, der auch in einem anderen Netz vorkommt. Trägt ein Signalisierungs-Gateway beide Netze über eine gemeinsame Assoziation, verrät die Zahl allein nicht, zu welchem Netzbereich eine Nachricht gehört. M3UA trennte deshalb Netzkontext, Verkehrsauswahlregel und den Verweis auf diese Regel.

Die Trennung beginnt an der Protokollgrenze. RFC 3332 erschien im September 2002 und definierte eine Anpassung, um MTP3-User-Signalisierung wie ISUP oder SCCP über IP zu übertragen. Einem entfernten Application Server Process stellt M3UA die von solchen Benutzern erwarteten Primitiven bereit; selbst wird es dadurch nicht zur SS7-Schicht MTP3. Das Signalisierungs-Gateway kann SS7 empfangen, während die entfernte Anwendung den User-Part über die Anpassung nutzt. Die Steuerungsebene muss sowohl das Ziel einer Nachricht als auch den SS7-Kontext festlegen, in dem ihre Felder Bedeutung haben.

Ein Application Server ist ein logischer Dienst für einen bestimmten Routing Key. Dieser Schlüssel ist die Auswahlregel: eine Menge von SS7-Parametern, die den Verkehrsbereich für den Dienst beschreibt. Dazu können Ziel- und Ursprungs-Point-Code sowie der Service Indicator gehören; eine Anwendung kann User-Part-Felder wie ISUP Circuit Identification Code oder SCCP Subsystem Number ergänzen. Das sind Beispiele, keine allgemeingültige Formel. Ein Schlüssel kann nicht zusammenhängende Bereiche beschreiben; welche Felder zählen, hängt von Anwendung und Netz ab.

Der Routing Context ist keine Kurzform dieser Kriterien, sondern ein Wert, der den Routing Key bezeichnet. Die Verteilungsfunktion im SGP prüft den Verkehr anhand des Schlüssels; Steuernachrichten verwenden den zugehörigen Context, um auf die zu aktivierende, zu stoppende oder zu registrierende Verkehrsmenge zu verweisen. Der Schlüssel ist die Regel, der Context ihr Referenzgriff und der Application Server der dadurch ausgewählte Dienst. Wer einen Begriff durch den anderen ersetzt, verliert entweder die Match-Kriterien oder den Verweis für Steueroperationen.

Network Appearance ist lokal, nicht universell

Network Appearance beantwortet eine andere Frage: In welchem SS7-Netzkontext ist eine Signalisierungsnachricht zu interpretieren? Ein Signalpunktcode identifiziert zusammen mit diesem Kontext einen Signalisierungsknoten. Das ist wichtig, wenn ein Gateway an mehreren nationalen oder privaten SS7-Netzen teilnimmt, die Point Codes wiederverwenden. Ohne die Netzdimension kann eine scheinbar genaue Adresse dennoch auf unterschiedliche Knoten zeigen.

Network Appearance ist jedoch keine globale Internet-Netznummer. RFC 3332 führte es als lokale Referenz ein, die zwischen Signalling Gateway Process und Application Server abgestimmt wird. RFC 4666, das RFC 3332 2006 ablöste, hält fest, dass dasselbe zugrunde liegende SS7-Netz bei verschiedenen SGPs unterschiedliche Network-Appearance-Werte haben kann. Ohne Zuordnungstabelle beweist ein Vergleich der Ganzzahlen zwischen Gateways nicht, dass sie dasselbe Netz bezeichnen.

In begrenzten Konfigurationen kann das Feld entfallen: etwa wenn ein Gateway nur ein SS7-Netz bedient oder eine Assoziation einem Netzkontext vorbehalten ist. Die Auslassung ist dann eine Eigenschaft der eingerichteten Topologie, kein Beleg dafür, dass alle Netze identisch sind. Auch der Routing Context kann in manchen eingeschränkten Einzel-Schlüssel-Konfigurationen implizit sein. Das Protokoll erlaubt eine Auslassung, wenn die Konfiguration den Wert eindeutig macht; warum, zeigt erst die Konfiguration.

Eine Assoziation, mehrere Anwendungszustände

Beim Failover wird die Unterscheidung erneut operativ. Ein ASP ist eine Prozessinstanz, nicht die Dienstdefinition. Er kann für mehr als einen Application Server eingerichtet sein; eine SCTP-Assoziation kann Verkehr für mehrere ASs transportieren. Daher führt RFC 3332 den ASP-Zustand getrennt je Application Server. ACTIVE ist keine Eigenschaft eines Sockets oder Rechners allein, sondern bezeichnet den Verkehrszustand des Prozesses in einem bestimmten Anwendungsdienst.

Die Traffic Modes bestimmen die Auswahl. Override kann einen aktiven ASP auswählen und andere als Standby belassen; Loadshare verteilt Verkehr auf aktive Prozesse; Broadcast sendet an alle geeigneten aktiven Prozesse. Welches Verfahren passt, hängt von der Anwendung ab. Bei der Zielauswahl muss das SGP Zustandswechsel, Routing Context und konfigurierten Schlüssel gemeinsam betrachten. „ASP aktiv“ ohne AS oder Context ist ungenau; „SCTP-Assoziation steht“ sagt noch weniger über die Dienstberechtigung.

Vor dem entfernten Benutzer gibt es eine weitere Prüfebene. M3UA kann DATA sowie Meldungen über unerreichbare, erreichbare, eingeschränkte oder überlastete Ziele transportieren. Eine Transportassoziation belegt die Kommunikationsfähigkeit der Endpunkte. Sie beweist weder, dass Point Code und Network Appearance richtig zusammen interpretiert wurden, noch dass eine autorisierte Routing Key getroffen wurde, der ASP für den betreffenden AS ACTIVE war oder der entfernte ISUP/SCCP-Prozess seine Arbeit beendet hat. Jede Aussage braucht einen Nachweis aus der jeweiligen Schicht.

Warum die Revision von 2006 zur Geschichte von 2002 gehört

Historischer Gegenstand ist RFC 3332, nicht die Behauptung, ihr Text sei die heutige Spezifikation. Im September 2006 löste RFC 4666 sie ab. Die Revision bewahrte die grundlegenden Rollen: Routing Key wählt Verkehr, Routing Context bezeichnet diesen Schlüssel, Network Appearance liefert den lokalen SS7-Netzkontext. Die Nachfolgespezifikation erklärt den aktuellen normativen Stand; der Vergleich zeigt, welche Designgrenzen fortbestanden.

Das aktuelle IANA-SCTP-Parameterregister führt für M3UA den Payload Protocol Identifier 3 und verweist auf RFC 4666. Im Dienstnamen- und Portregister steht m3ua auf SCTP-Port 2905. Das sind Zuweisungen, keine Belege für den Einsatz bei einem Carrier, Standardkonformität einer Implementierung oder eine konkrete Verbindung, über die ein Anruf lief. Ebenso beweist RFC 9260 als aktuelle SCTP-Spezifikation nicht, dass ein installiertes M3UA-System sie übernommen hat.

RFC 3331 zu M2UA behandelt eine benachbarte, aber andere Grenze: Sie transportiert die MTP2-User-Schnittstelle, während die physische Leitung am Gateway verbleibt. M3UA transportiert dagegen MTP3-User-Signalisierung, darunter möglicherweise ISUP oder SCCP. IUA (RFC 4233) und M2PA (RFC 4165) besitzen ebenfalls eigene Anpassungsgrenzen. SIGTRAN-Abstammung oder SCTP als gemeinsamer Transport machen Protokollnamen und Zustandsmodelle nicht gleichbedeutend.

Für eine Prüfung sind vier Fragen getrennt zu beantworten: Welche SS7-Parameter wählten diesen Verkehr? Welcher Routing Context bezeichnete die Auswahl? Welche lokale Network Appearance gab dem Point Code für dieses SGP/ASP-Paar Bedeutung? Welcher ASP-Zustand je AS erlaubte die Zustellung? Erst danach wird die SCTP-Assoziation als Transportweg ergänzt. RFC 3332s bleibende Lehre lautet: Referenz auf eine Regel, die Regel selbst, Netzbereich und Leitung für die Nachricht sind verschiedene Dinge.

Quellen