Zusammenfassung

  • RFC 3331 verlegte keinen SS7-Link in einen IP-Endpunkt. MTP1 und MTP2 blieben am Signalling Gateway; M2UA transportierte die MTP2-Nutzerschnittstelle, sodass entferntes MTP3 den Link verwenden konnte.
  • SCTP-Assoziation, aktiver ASP und physischer Linkzustand sind drei verschiedene Tatsachen. Eine explizite Zuordnung und Zustandsabfrage verbinden sie; eine grüne Verbindungsanzeige genügt nicht.

„Nutzer“ bezeichnete eine Protokollschicht

Der Name MTP2 User Adaptation kann so klingen, als ginge es um Telefonkunden. Gemeint ist jedoch die nächsthöhere Protokollschicht: MTP3 ist der einzige Nutzer von MTP2. Beim Backhaul enden der physische SS7-Kreis, MTP1 und MTP2 in einem Signalling Gateway Process (SGP). MTP3 läuft dagegen in einem Application Server Process (ASP) auf dem Media Gateway Controller. M2UA überträgt per SCTP die Primitiven, die sonst eine lokale Schnittstelle zwischen MTP2 und MTP3 überqueren würden.

Diese Trennung ist der Kern der Architektur. Eine Signaleinheit kommt über eine reale Leitung am Gateway an; dort übernimmt MTP2 die Linkfunktionen. Das entfernte MTP3 erhält keine zweite virtuelle Leitung. Es empfängt Daten und Zustandsmeldungen des vorhandenen Links und sendet Grenzanforderungen zurück. Aufbau, Freigabe, Überlast, lokale und entfernte Prozessorausfälle, Wiederherstellung und Datentransfer werden so zu Nachrichten über eine verteilte Schnittstelle.

RFC 2719 hatte den SIGTRAN-Rahmen gesetzt: Das Gateway trifft auf das leitungsvermittelte Signalisierungsnetz, während der Controller höhere Steuerungslogik andernorts bündeln kann. RFC 3331 legte innerhalb dieses Modells eine konkrete Trennstelle fest. Es war kein beliebiger Tunnel für „SS7 über IP“, sondern die Verteilung einer Schichtgrenze.

Das verändert die Fehleranalyse. Der Draht bewegte sich nicht; auch sein MTP2-Endpunkt blieb am Gateway. Verteilt wurde die operative Möglichkeit der höheren Schicht, den Link zu nutzen. Die Flexibilität hatte einen Preis: Der Nachweis des Dienstzustands lag nun über mehrere Systeme verteilt.

Eine Kennung verband eine physische Leitung mit einem beweglichen Pfad

Das Gateway ordnet eine Interface Identifier einer physischen Schnittstelle zu, etwa einer V.35-Leitung oder einer T1-/E1-Leitung mit Zeitschlitz. Dieselbe Kennung wird außerdem einer SCTP-Assoziation und einem Stream zugeordnet. Diese Beziehungen sind unterschiedlich stabil. Die physische Zuordnung ist provisioniert; die dynamische Zuordnung zu Assoziation und Stream kann sich ändern, wenn ein ASP aktiviert, deaktiviert oder bei einem Failover ersetzt wird.

Die Interface Identifier ist zwischen Gateway und ASP abgestimmt und nur lokal aussagekräftig. Sie ist kein weltweit eindeutiger Name für einen Schaltkreis. Der Wert 17 in einem Paketmitschnitt beweist, dass ein Peer ihn in einem bestimmten Kontext gesendet hat. Ohne Konfigurationsbeleg beweist er nicht, welche Buchse, Leitung oder welcher Zeitschlitz gemeint war.

SCTP-Streams begrenzen, dass Verzögerungen auf einem Link zwangsläufig andere Links blockieren. Sie ersetzen die Kennung aber nicht. Streams sind unidirektional; aus dem Eingangs-Stream lässt sich der Rückweg nicht ableiten. RFC 3331 nahm daher die Interface Identifier in den M2UA-Header auf. Managementverkehr nutzte einen gemeinsamen Stream, MAUP-Verkehr die den Daten zugeordneten Streams.

Die prüfbare Kette führt vom physischen Link zur Kennung, von dort zum Application Server und vom ausgewählten ASP weiter zur SCTP-Assoziation samt Stream. Fehlt ein Glied, ist es veraltet oder mehrdeutig, kann der entfernte MTP3-Zustand von der Realität am Gateway abweichen.

Verbindung, Prozess und Link hatten drei Zustände

SCTP kann eine etablierte Assoziation melden. M2UA führt ASP-Zustände DOWN, INACTIVE und ACTIVE für einen Application Server. MTP2 meldet unabhängig davon, ob der physische Link in Betrieb, außer Betrieb, überlastet oder von einem entfernten Prozessorausfall betroffen ist. Die Ebenen beantworten unterschiedliche Fragen.

Eine SCTP-Assoziation im Zustand UP belegt, dass die Transportendpunkte kommunizieren können. Sie belegt nicht, dass der ASP für die betreffende Kennung aktiviert wurde. ASP ACTIVE heißt, der Prozess wurde für einen Traffic-Modus ausgewählt; es bestätigt nicht den Zustand des physischen Links. Umgekehrt garantiert ein gesunder SS7-Link am Gateway nicht, dass ein entfernter Controller seine Nachrichten verarbeiten kann.

RFC 3331 modelliert auch Zustände des Application Servers und eine PENDING-Phase bei der Wiederherstellung. Override, Loadshare und Broadcast verändern, wie aktive Prozesse Verkehr erhalten. Da die dynamische Zuordnung während eines Failovers vorübergehend ungültig werden kann, muss das Gateway AS- und ASP-Zustände bei der Weiterleitung berücksichtigen. Für einen SS7-Link sollte laut Spezifikation nur ein SGP den Linkabschluss bereitstellen, damit nicht zwei aktive Instanzen dieselbe physische Ressource beanspruchen.

Wer diese Ebenen zu einer einzigen „gesund“-Anzeige zusammenzieht, macht Wiederherstellung riskanter. Verkehr kann zu einem ASP wechseln, der den Linkzustand noch nicht abgeglichen hat. Eine grüne Anwendung kann Nachrichten vor einer toten Leitung sammeln. Ein gesunder Link kann ungenutzt bleiben, weil kein Controller bereit ist.

Eine Abfrage glich die Gegenwart ab, nicht die gesamte Vergangenheit

Mit STATUS_AUDIT kann ein ASP den aktuellen Linkzustand beim Gateway erfragen. Die Antwort kann außer Betrieb, in Betrieb, Überlast oder entfernten Prozessorausfall anzeigen. Nach Neustart einer Assoziation oder einer Lücke in den Meldungen erhält das entfernte MTP3 so einen expliziten Ausgangspunkt.

Ein Audit ist ein zeitgebundener Abgleichsbeleg. Es beweist weder, dass unmittelbar danach kein Zustandswechsel stattfand, noch rekonstruiert es jedes verlorene Ereignis. Ein belastbarer Vorfallbericht verknüpft Anfrage und Antwort mit Zeitpunkt, Interface Identifier, Assoziationsidentität, ASP-Zustand und nachfolgenden Meldungen. „Das Audit zeigte Betrieb“ gilt nur für diesen Zeitpunkt und Beobachtungspunkt.

Auch dynamische Registrierung hat eine eigene Grenze. Ein Link Key kann autorisiert und einer Interface Identifier zugeordnet werden. Eine erfolgreiche Registrierung zeigt, dass das Gateway diese Steuerungszuordnung annahm. Sie beweist weder einen gesunden physischen Link noch einen aktiven ASP oder tatsächlichen Verkehr.

Backhaul ist kein Peer-Ersatz wie M2PA

RFC 4165 stellt den Unterschied klar. Bei M2PA haben beide Peers MTP3; M2PA ersetzt MTP2 zwischen ihnen. Bei M2UA verwendet das MTP3 des Controllers das reale MTP2 am Gateway, indem Grenzprimitive übertragen werden. Beide können SCTP verwenden, doch Link-Eigentum und Fehlerbilder sind verschieden.

M3UA aus RFC 4666 und IUA aus RFC 4233 teilen ASP-Verwaltungszustände und Nachrichtengruppen. Das macht die von ihnen adaptierten Schnittstellen nicht austauschbar. Ein gemeinsamer Header begründet keine gemeinsame Betriebssemantik.

RFC 3331 verwies auf die 2002 aktuelle SCTP-Spezifikation. RFC 9260 ist heute die SCTP-Protokollspezifikation. Das beweist nicht, dass ein bestimmtes M2UA-Netz aktualisiert wurde. Ebenso führt IANA für M2UA weiterhin SCTP-Payload-Protokollkennung 2 sowie die MAUP- und Interface-Identifier-Management-Klassen. Das belegt Zuweisungen, nicht Einsatz, Verkehrsvolumen, Betriebszustand oder Konformität.

Auch Sicherheit hat eine eigene Grenze. SCTP macht aus einer lokalen Kennung keinen authentisierten Nachweis über eine physische Leitung. RFC 3788 behandelte SIGTRAN-Sicherheitsaspekte; Betreiber brauchen weiterhin Peer-Autorisierung, Richtlinien und geeigneten Schutz. Eine funktionierende Assoziation belegt nicht, dass ein Peer den damit verknüpften Link bedienen darf.

Belege getrennt halten und gezielt verknüpfen

Die dauerhafte Lehre von M2UA liegt weniger im Nachrichtenkatalog als darin, Aussagen über verteilte Infrastruktur sauber zu prüfen. Die physische Verankerung blieb erhalten, obwohl die Nutzungsschnittstelle remote zugänglich wurde.

Fünf Belegarten sollten getrennt bleiben: SCTP-Assoziation und Stream; ASP- und AS-Steuerzustände; provisionierte Interface-Identifier-Zuordnung; physischer MTP2-Linkzustand; sowie die Grenzmeldung, die Beobachtung oder Befehl transportierte. Bei Autorisierungsfragen kommt Sicherheits- und Richtlinienkontext hinzu. Erst dann lässt sich ein aktiver Prozess ohne Schlussfolgerungssprung einem bestimmten Link zuordnen.

RFC 3331 ermöglichte Fernsteuerung, indem er präzise benannte, was blieb, was über IP ging und was beide Seiten verbinden musste. Werden diese Unterschiede eingeebnet, wird eine IP-Verbindung zum falschen Beleg für Telefondienst. Bleiben sie erhalten, lassen sich Failover und Audit erklären, ohne so zu tun, als hätte das Paketnetz den Draht selbst bewegt.

Quellen