Zusammenfassung

  • RFC 3057 trennte den physischen Abschluss des ISDN-D-Kanals vom Ort der Q.931-Rufverarbeitung: Das Signaling Gateway beendete Q.921, und IUA transportierte die Q.921-User-Schnittstelle über SCTP zu einem Application Server.
  • ASP-Failover konnte Signalisierung an einen anderen Prozess umlenken, doch die Wiederherstellung des Transports stellte keinen Rufzustand wieder her. Der Nachfolger RFC 4233 hält fest, dass Rufe im Übergang scheitern können, sofern die Prozesse ihren Zustand nicht außerhalb von IUA teilen.

Die obere Schicht verlagern, nicht die Leitung

Im klassischen ISDN transportiert der D-Kanal die Signalisierung, mit der Endgeräte leitungsvermittelte Gespräche aufbauen und steuern. Auf der unteren Schicht stellt Q.921 den Sicherungsdienst bereit. Q.931 und QSIG nutzen ihn als Q.921-User. RFC 3057 setzte genau an dieser Protokollgrenze an, um die Zuständigkeiten aufzuteilen.

Das Signaling Gateway (SG) nahm die Signalisierung über eine standardisierte ISDN-Schnittstelle entgegen und terminierte Q.921. Auf der IP-Seite stellte ein Media Gateway Controller (MGC) die Gegenstelle für Q.931 und die Rufverarbeitung bereit. Dazwischen transportierte die ISDN-Q.921-User-Adaptation-Schicht – IUA – die Schnittstellenprimitiven über SCTP. Damit wurde weder behauptet, die Teilnehmerschleife oder der D-Kanal sei nun ein IP-Objekt, noch dass alle Stromkreise migriert wären. IUA bot einen Rücktransport der höheren Signalisierungsfunktion, während das SG die ältere Schnittstelle weiter bediente.

Das war für den Betrieb entscheidend. Ein Q.921-DL-DATA-Primitiv kann eine Q.931-Nachricht übermitteln; Aufbau-, Freigabe- und Unit-Data-Primitiven melden jeweils andere Zustände der Verbindung. IUA musste deshalb sowohl die Schnittstellenidentität als auch die Bedeutung dieser Grenze bewahren. Das Gateway blieb für den physischen Signalisierungskanal und sein lokales Q.921-Verhalten verantwortlich. Der entfernte Controller konnte Rufnachrichten verarbeiten, ohne so zu tun, als hätte er den D-Kanal selbst übernommen.

Eine Schnittstellenkennung, eine lokale Zuordnung

Die IUA Interface Identifier ordnete eine Nachricht einer physischen Schnittstelle am SG zu. Je nach Implementierung konnte die Kennung numerisch oder textuell sein; ihre Bedeutung blieb lokal und musste zwischen SG und Application Server abgestimmt werden. Der RFC machte sie ausdrücklich nicht zu einer gatewayübergreifenden Kennung. Was wie ein netzweit gültiger Name aussah, war tatsächlich ein lokaler Verknüpfungsschlüssel für einen Signalisierungskontext.

Diese lokale Zuordnung trug den Rücktransport. Das SG verknüpfte eine Schnittstellenkennung mit einem Application Server und einem aktiven Application Server Process (ASP). Ein Application Server musste nicht einem einzelnen Rechner entsprechen: Er konnte ein logischer Dienst sein, der durch eine geordnete Gruppe von ASP-Prozessen – etwa primärer und sekundärer Controller – repräsentiert wurde. Für jede Signalisierungsschnittstelle musste das Gateway wissen, welcher Prozess aktiv war; bei einem Failover konnte sich diese Zuordnung ändern.

RFC 3057 empfahl SCTP und, um Pufferung und Verzögerungen zwischen unabhängigen D-Kanälen zu begrenzen, einen eigenen SCTP-Stream je D-Kanal. Der Stream war Transportmechanik; die Interface Identifier sagte dem Gegenüber weiterhin, um welche physische Signalisierungsschnittstelle es ging. Zustand von Association und Stream, die lokale Schnittstellenzuordnung und der Aktivzustand eines ASP hingen zusammen, waren aber nicht austauschbar.

Failover ist kein gemeinsames Rufgedächtnis

Das Redundanzmodell blieb eine Betreiberentscheidung. Bei 1+0 gab es keine ASP-Redundanz. In einer 1+1-Konfiguration bearbeitete ein aktiver Prozess den Verkehr, während ein Standby übernehmen konnte. Das allgemeinere n+k-Modell sah n für die Last nötige Prozesse und k Reserveprozesse vor, die ausgefallene Prozesse ersetzen konnten. IUA-Nachrichten ermöglichten den ASPs und dem SG, Prozesszustände auszutauschen und festzulegen, wohin neue Signalisierung geleitet wurde.

Eine intakte SCTP-Verbindung zu einem Reserveprozess bedeutete jedoch nicht, dass dieser den Zustand eines gerade eingerichteten Gesprächs kannte. RFC 4233, der 2006 veröffentlichte Nachfolger, der RFC 3057 ablöste, formulierte diese Grenze ausdrücklich. In netzbetreibertauglichen Netzen SOLLTEN stabile Gespräche beim Ausfall eines ASP nicht abbrechen; dafür kann es nötig sein, dass ASPs den Rufzustand gemeinsam halten. Bei einem Failover KÖNNEN Gespräche scheitern, deren Aufbau oder Abbau noch läuft. Gemeinsamer Speicher oder ein ASP-zu-ASP-Protokoll konnten das Risiko mindern, letzteres lag aber außerhalb des IUA-Umfangs.

Das war kein verdeckter SCTP-Mangel. SCTP kann den Zustand einer Association melden, Nutzernachrichten je Stream ordnen und Mehrfachanbindung unterstützen. Das sind Transporteigenschaften. Daraus folgt nicht, welche Rufentscheidungen der ausgefallene Controller bereits getroffen hatte, welche Nachricht die Gegenseite erreichte oder ob ein Ruf stabil oder noch im Übergang war. IUA konnte den Signalisierungspfad verschieben; für Anwendungskontinuität blieb eine andere Schicht zuständig.

Was die Norm änderte – und was nicht

RFC 3057 erschien im Februar 2001 und ergänzte die SIGTRAN-Architektur um eine definierte Adaptation für ISDN-Q.921-User. Verteilte Rufverarbeitung über einen IP-Rücktransport wurde möglich, während ein standardisierter Übergang ins leitungsvermittelte Netz erhalten blieb. 2006 löste RFC 4233 das Dokument ab und präzisierte dieselbe Adaptation. Diese Normenfolge belegt Protokollentwicklung, nicht für sich genommen den Einsatz bei bestimmten Betreibern, deren Beschaffung oder die Zahl der bei realen Ausfällen geretteten Gespräche.

Die bleibende technische Lehre ist enger als „Telefonie wechselte zu IP“. Eine Dienstgrenze kann wandern, obwohl die physische Schnittstelle an einem anderen Ort bleibt. Gateway, das die Leitung terminiert, Adaptation der Nutzerprimitiven, Transport-Association, empfangender Prozess und der Rufzustand, der eine Nachrichtensequenz zu einem Gespräch macht, benötigen jeweils eigene Nachweise. Eine grüne SCTP-Association oder ein aktiver ASP ist keine Bestätigung eines erfolgreich abgeschlossenen Rufs.

Quellen