Zusammenfassung

  • RFC 2127 stellte physischen ISDN-Zugang, D-Kanal-Schichten, einzelne B-Kanäle und obere Schnittstellen als getrennte ifTable-Zeilen dar. ifStack beschrieb die lokale Schichtung, nicht die bewiesene Ende-zu-Ende-Verbindung.
  • Ein Hyperkanal konnte mehrere B-Kanäle belegen und in der Signalisierungsstatistik dennoch als ein Anruf zählen. Identische Werte in mehreren Bearer-Zeilen machten aus ihnen keine mehreren Anrufe.
  • Das Entfernen der lokalen ifStack-Bindung war der vorgesehene Trennvorgang. Ferne Freigabe, endgültige Abrechnung und Anwendungsergebnis brauchten eigene Nachweise.

Eine Adresse steht in einer Tabelle. Sie sieht präzise aus, kann aber den aktuellen oder den vorherigen Anruf bezeichnen. Ihre Schreibweise kann von Switch oder PBX abhängen; fehlt die Information, bleibt sie leer. Die RFC 2127 machte diese Begrenzung ausdrücklich und schuf darum kein einziges Objekt für die gesamte Verbindung.

Das im März 1997 veröffentlichte Modell zerlegte eine Basic- oder Primary-Rate-Schnittstelle in physischen Zugang, D-Kanal-Signalisierung, B-Kanäle und obere Kapselung. Im D-Kanal wurden LAPD-Datenverbindung und Netzschicht-Signalisierung nochmals unterschieden. Jede Schicht erhielt eine konzeptionelle Schnittstellenzeile; ifStack verband höher und tiefer liegende Zeilen.

Die Tabelle gehörte einer Schicht

Ein Eintrag in isdnBearerTable beschrieb genau einen B-Kanal. Sein Zustand unterschied frei, ausgehend im Aufbau, eingehend in Prüfung und aktiv. Damit ließ sich die lokale Belegung beobachten, ohne den gesamten physischen Zugang oder die Anwendungssitzung auf denselben Wert zu reduzieren.

Das allgemeine Modell stammte aus RFC 1573: eine ifTable-Zeile pro Teilschicht, dazu ifStackTable für die Beziehung zwischen oberer und unterer Schicht. Der lokale Agent meldete diesen Graphen. Auch ein syntaktisch korrekter Graph bestätigte nicht unabhängig den Zustand der entfernten Vermittlung oder die Zustellung der Nutzdaten.

Die erforderliche RFC 2128 hielt generische Wählverbindungsdaten getrennt: Gegenstellenkonfiguration, aktive Verbindungen und Historie. RFC 2127 blieb bei ISDN-spezifischer Physik, Signalisierung und Bearer-Zuordnung. Die Aufteilung verhinderte, dass Konfiguration, Nutzung und Historie dieselbe Autorität vortäuschten.

Der Hyperkanal widerlegte das Zeilenzählen

Bei einer Multirate-Verbindung lag eine obere Kapselung über mehreren B-Kanälen. Der Hersteller konnte dafür ein DS0Bundle oder mehrere ifStack-Einträge mit gleichem HigherLayer und verschiedenen LowerLayer-Werten verwenden.

Alle beteiligten Bearer-Zeilen enthielten identische Werte für Adresse und Subadresse, Ursprung, Informationstyp, Multirate, Aufbau- und Verbindungszeit sowie Gebühreneinheiten. Trotzdem zählte die Signalisierungsstatistik den Hyperkanal unabhängig von der Anzahl der B-Kanäle als einen Anruf.

Vier Zeilen konnten also einen Anruf bedeuten. Ein Anruf konnte vier Kanäle beanspruchen. Vier beanspruchte Kanäle belegten aber noch nicht vierfach nutzbaren Durchsatz. Topologie, Belegung, Signalisierung und gelieferte Leistung hatten verschiedene Messgrößen.

Die spätere RFC 2494 definierte DS0 und DS0Bundle 1999 endgültig. Sie erklärt die Bündeloption, darf aber nicht rückwirkend als Bestandsnachweis für jede 1997er Implementierung dienen.

Trennen hieß eine Kante entfernen

RFC 2127 beschrieb das aktive Trennen als Entfernen des ifStack-Eintrags zwischen oberer Schnittstelle und B-Kanal. Der Manager veränderte damit einen klar benannten Teil des lokalen Modells.

Eine erfolgreiche Änderung konnte die Annahme dieser lokalen Aktion belegen. Sie bestätigte nicht automatisch, dass die Gegenseite freigegeben, jedes Release-Signal abgeschlossen, das Gebührensystem geschlossen oder die Anwendung den Abbruch verarbeitet hatte. Aus einem lokalen Schreibvorgang einen globalen Abschluss zu machen, hätte die Schichten wieder vermischt.

Null war nicht immer nichts

Die Gegenstellenadresse bezog sich auf den laufenden oder letzten Anruf. Ihr Format war implementierungsabhängig, bevorzugt E.164, aber nicht garantiert. Sie war weder zwingend frisch noch normalisiert oder authentifiziert.

Auch isdnBearerChargedUnits gehörte zur aktuellen oder vorherigen Verbindung. Bei eingehenden Anrufen oder fehlender Gebühreninformation vom Switch war der Wert null. Diese Null konnte „nicht geliefert“ bedeuten und bewies keine Kostenfreiheit.

Wähl- und Mietkanäle unterschieden sich in der Kontrolle. Der gewählte B-Kanal stand unter einem Signalisierungskanal; beim gemieteten B-Kanal gab es keine solche Kontrolle. Eine vollständig gemietete PRI konnte allein über das DS1/E1-MIB verwaltet werden. Fehlende ISDN-Signalisierungszeilen waren dort kein Ausfallbeweis.

Speech, 3,1-kHz-Audio und das frühere 7-kHz-Audio waren Signalisierungsartefakte. Das Netz entschied über die Behandlung innerhalb der zugesagten Fähigkeit. Ein Speech-Bearer konnte Sprachqualität liefern und trotzdem ein Modem scheitern lassen. Das Label beschrieb nicht jeden Verarbeitungsschritt.

Die ausgesparte Sicherheit

Der offizielle RFC-Datensatz und der IETF-Verlauf führen den Text als Proposed Standard der ISDN-MIB-Arbeitsgruppe. Das Errata-Verzeichnis enthält eine bestätigte technische Korrektur der Konformitäts-OID und eine abgelehnte Meldung. Daraus folgt nichts über Marktdurchdringung oder Abrechnungsqualität.

Der Sicherheitsabschnitt sagte lediglich, Sicherheitsfragen würden nicht behandelt. Damit waren weder Manager-Authentisierung noch Vertraulichkeit oder sicherer Schreibzugriff zugesichert. Schweigen ist keine Sicherheitsfunktion.

Historisch war RFC 2127 stark, weil sie unterschiedliche Behauptungen an unterschiedliche Objekte band. Der Fehler entstünde erst, wenn spätere Systeme diese Trennung zugunsten einer scheinbar einfachen Gesamtampel aufgäben.

Quellen und Grenzen

Die offiziellen Quellen belegen Spezifikation und Semantik, nicht eine konkrete Installation oder einen gemessenen Anruf. Lu Hengs spätere Texte über Running-Code Primacy, Minimum Initial Specification und Reality Layers dienen nur als Interpretationsdisziplin: Spezifikation, lokaler ausführbarer Zustand und Betriebsergebnis sind getrennte Belege. Sie dokumentieren nicht die Absicht der RFC-Autoren.