Zusammenfassung

  • RFC 3332 legte die Anpassungsgrenze oberhalb von MTP3. Das Signalling Gateway terminierte MTP2 und MTP3 und übergab ISUP, SCCP und andere MTP3-Nutzerdaten gemäß Routing Key an IP-Anwendungen. Der Routing Context benannte diese Regel im Protokoll.
  • Registrierung, ASP-Aktivierung und SS7-Zielstatus waren getrennte Belege. Erfolg in einer Ebene bewies die anderen nicht. RFC 4666 löste RFC 3332 2006 ab; der ältere Text ist historische Quelle, keine aktuelle Normautorität.

Nicht mehr der Link, sondern die Zuständigkeit

Bei M2UA aus RFC 3331 blieben der physische SS7-Link und MTP2 im Gateway. Entferntes MTP3 bediente ihre Grenze über einen Interface Identifier. M3UA setzte den Schnitt eine Schicht höher. Das Gateway terminierte auch MTP3 und bot entfernten Anwendungen den Dienst, den ISUP, SCCP und andere MTP3-Nutzer erwarteten.

Damit erhielt eine Anwendung keinen bestimmten Draht. Sie erhielt Zuständigkeit für eine Klasse von Signalisierung. Das Gateway musste anhand der SS7-Merkmale bestimmen, welcher logische Application Server jede Nachricht verarbeiten sollte.

Der Routing Key beschrieb diese Klasse: Service Information Octet, Ziel- und Ursprungspunktcode, Circuit-Bereich oder SCCP-Subsystem konnten Teil der Auswahl sein. Ein Application Server diente genau einer solchen Schlüsseldefinition; ASPs führten ihn aus. Der Routing Context war der kompakte Verweis in den ausgetauschten Nachrichten.

Aus einer Route wurde damit zusätzlich eine Verwaltungsregel. Sie sagte nicht nur, wo ein Netzpfad verlief, sondern wem bestimmter Verkehr gehörte. Das Protokoll konnte die Regel zuverlässig ausführen. Ob sie sachlich richtig war, blieb Aufgabe der Betreiber.

Ein positives Registerergebnis war keine Vollmacht

Schlüssel konnten provisioniert oder über Routing Key Management registriert werden. Akzeptierte das SGP die Anfrage und lieferte einen Context, war damit die Annahme des Vorschlags belegt. Nicht belegt waren Berechtigung für die Punktcodes, Überschneidungsfreiheit, angemessene Reichweite oder Erreichbarkeit.

Network Appearance machte die lokale Bedeutung sichtbar. Gleiche Punktcodewerte konnten in getrennten SS7-Netzen vorkommen. Die Appearance ordnete sie einem Kontext zu, war aber weder globale Identität noch Besitznachweis.

Ein belastbarer Auswahlbeleg umfasst deshalb sämtliche Key-Felder, Network Appearance, Anfrage und Antwort, Context, Konfigurationsversion und Genehmigung. Ein Context in einem Mitschnitt beweist lediglich, dass ein lokaler Verweis benutzt wurde. Ohne die zugehörige Karte bleibt sein Inhalt unbekannt.

Breite Schlüssel sind bequem und riskant. Ein zu großer Circuit-Bereich kann korrekte Nachrichten an den falschen Dienst liefern, ohne dass SCTP einen Fehler meldet. Der Verkehr ist verfügbar, doch die Zuständigkeit ist falsch. Klassische Verfügbarkeitsmetriken entdecken diesen Schaden spät.

Drei Zustände erzählten drei Wahrheiten

SCTP beschrieb Assoziation und Streams. ASP-DOWN, ASP-INACTIVE und ASP-ACTIVE beschrieben die Einsatzfähigkeit eines Prozesses; AS-Zustände und Override, Loadshare oder Broadcast regelten die Verteilung. Diese Angaben sagten nichts über die Erreichbarkeit jedes SS7-Ziels im Schlüssel.

Dafür gab es SSNM. DUNA meldete Unerreichbarkeit, DAVA Erreichbarkeit, SCON Überlastung, DUPU die Nichtverfügbarkeit eines Nutzerteils, DAUD fragte den aktuellen Zustand ab. Bei mehreren Gateways musste M3UA Routen einzeln verfolgen und daraus den Gesamtzustand des Ziels ableiten.

Eine aufgebaute Assoziation, ein ACTIVE-ASP und ein DUNA-Ziel konnten deshalb gleichzeitig korrekt sein. Transport, Anwendungsbereitschaft und Signalisierungsroute waren unabhängig. Ein zusammengefasster Grünwert entfernte genau die Differenz, die den Vorfall erklärte.

Auch DAVA war kein Geschäftsabschluss. Die Meldung besagte, dass das Ziel aus einer Beobachtungsperspektive verfügbar erschien. Sie bewies weder einen verbundenen ISUP-Anruf noch eine abgeschlossene SCCP-Transaktion. Das Ergebnis brauchte Antwort-, Fehler- oder Timeoutbelege der Nutzerschicht.

Failover übernahm nicht automatisch das Wissen

Mehrere ASPs konnten denselben Server bedienen, und eine Anwendung konnte mehrere SGPs erreichen. Beim Ausfall wurde der Routing Context auf einen Ersatzprozess geschaltet. Seine Stabilität garantierte jedoch nicht, dass der Ersatz den neuesten Zielzustand kannte.

Ein neu aktiver ASP konnte eine DUNA-Meldung verpasst haben. Eine bestehende Assoziation konnte zu einem Gateway führen, dessen SS7-Routen sich geändert hatten. Ein DAUD-Ergebnis konnte vor Freigabe einer Warteschlange veralten. Wiederanlauf verlangte daher den Abgleich von Key-Mitgliedschaft, Autorisierung, Verkehrsmodus, Route je SGP, Überlastung und Restart.

Loadshare vervielfachte auch falsche Regeln. Mehr Prozesse machten einen zu breiten Schlüssel nicht richtig; sie erhöhten nur die Kapazität seiner Fehlzuordnung. Softwareverfügbarkeit und Wissensqualität mussten getrennt gemessen werden.

Auch ein RFC hat eine zeitliche Grenze

RFC 3332 erschien im September 2002. RFC 4666 erklärte ihn im September 2006 ausdrücklich für überholt. Für die Entstehungsgeschichte bleibt der erste Text zentral; aktuelle normative Aussagen gehören zum Nachfolger. Der Dokumentstatus ist Teil der Provenienz.

RFC 2719 liefert den SIGTRAN-Rahmen, RFC 9260 die heutige SCTP-Basis, RFC 3788 Sicherheitsbetrachtungen und RFC 4165 den M2PA-Kontrast. IANA-Register belegen zugewiesene Klassen und Kennungen, nicht Einsatz, Verkehr, Eigentum, Gesundheit oder Konformität.

Geschützter Transport legitimiert ebenfalls keinen Key. Ein authentisierter Peer kann für einen Bereich unberechtigt sein; eine genehmigte Konfiguration kann Fehler enthalten. Identität, Befugnis, Auswahl und Erreichbarkeit brauchen getrennte Nachweise.

Vier Belege statt einer Ampel

Der Auswahlbeleg enthält Key, Appearance, Context und Konfigurationsherkunft. Der Anwendungsbeleg enthält Assoziation, ASP/AS, Modus und aktive Mitglieder. Der Netzbeleg enthält SGP, Routenzustand, SSNM, Überlastung und Restart. Der Ergebnisbeleg enthält Antwort, Fehler oder Ablauf von ISUP/SCCP.

Der Schlüssel beantwortete, wer eine Nachricht bekommen sollte. Er beantwortete nicht, ob das Ziel erreichbar war oder die Operation gelang. RFC 3332 bleibt wichtig, weil es diese Fragen sichtbar trennte. Wer sie wieder in einer Ampel vereint, macht Auswahlpolitik zu vermeintlicher Netzrealität.

Quellen