Zusammenfassung

  • Im SDP von RFC 3108 zeigte vorwärts vom beschriebenen ATM-Knoten weg. In der Bearer-Signalisierung begann vorwärts dagegen am Absender des Setup. Beim rückwärts aufgebauten SVC wechselte derselbe Parameter zwischen den Schichten die Richtung.
  • Die vier Byte große eecid verband einen Service-Call mit einer späteren Bearer-Anfrage. Sie war ein lokaler Korrelationsschlüssel, keine Identität, Authentisierung, globale Verbindungsnummer oder Medienmessung.

Ein richtiger Wert im falschen Bezugssystem

Für ein Gateway ist ausgehender Verkehr vorwärts. Für ein Signalisierungsprotokoll ist vorwärts der Weg vom Initiator des Verbindungsaufbaus zum Empfänger. Beginnt die entfernte Seite den Bearer, kann derselbe ausgehende PCR im ersten System vorwärts und im zweiten rückwärts heißen. Beide Definitionen sind intern richtig.

RFC 3108 erschien im Mai 2001 auf dem Standards Track. Es übertrug die SDP-Syntax aus RFC 2327 auf ATM- und AAL2-Bearer und ergänzte Attribute für Adressen, Adaptionsschichten, Traffic Descriptor, QoS, Bearer-Typen, Kanäle und Dienste. SIP, MGCP oder Megaco/H.248 konnten solche Beschreibungen transportieren.

Entscheidend war die Trennung zwischen Service-Call und Bearer-Aufbau. Das Gateway, das den Dienstanruf begann, musste nicht das SVC beginnen. RFC 3108 definierte die SDP-Richtung relativ zum betrachteten ATM-Knoten: weg war vorwärts, hin war rückwärts, unabhängig von beiden Initiatoren.

ATM/AAL2-Signalisierung nahm dagegen den Absender der Setup-Anfrage als Ursprung. Im Backward-Setup empfing das service-originierende Gateway den Bearer-Aufbau. Sein ausgehender Traffic Descriptor war im SDP vorwärts und im ATM-Setup rückwärts. Das Gateway musste die Zuordnung tauschen.

Ein unverändertes Kopieren konnte deshalb semantisch falsch sein. Rate, Verzögerung oder Verlustgrenze landeten auf dem anderen Flow, obwohl Syntax und Zahl gültig blieben.

Richtung gehörte zum Zustand

Attribute wie atmQOSparms und atmTrfcDesc trugen ein directionFlag mit f, b oder fb. Dieses Feld war vorgeschrieben. Andere Parameter durften sein, wenn sie unbestimmt, nicht anwendbar, implizit oder anderweitig bekannt waren.

Die Werte beschrieben Spitzen- und nachhaltige Zellraten, Burst-Größen, Delay Variation, Transit Delay und zulässigen Verlust. Zur Auswertung brauchte man daher den Referenzknoten, den Call-Initiator, den Bearer-Initiator und das Protokoll. „Vorwärts“ ohne diesen Kontext war kein vollständiger Befund.

Das Zeichen $ überließ in manchen Feldern dem Empfänger die Auswahl. Es belegte keine installierte Ressource. Auch war kein universeller Nullwert. Grammatik konnte eine Aussage zulassen, während Policy, Hardware oder Anwendung sie ablehnten.

Der Schlüssel kam zum künftigen Empfänger zurück

Ein Service-Kontext konnte zuerst über Controller eintreffen, die ATM-Setup-Anfrage später direkt über das Netz. RFC 3108 verband beide mit eecid, dem end-to-end connection identifier, in den genannten Zusammenhängen gleichbedeutend mit der vier Byte großen bnc-id.

Beim Forward-Aufbau wählte das call-terminierende Gateway den Wert, sandte ihn im SDP zur Ursprungsseite und erhielt ihn im von dort initiierten Setup zurück. Beim Backward-Aufbau wählte das call-originierende Gateway, übermittelte den Wert zur Gegenseite und erhielt ihn in deren Setup zurück.

Damit erzeugte der künftige Setup-Empfänger seinen eigenen Suchschlüssel. Eindeutigkeit war nur innerhalb dieses Knotens nötig. Der Zuteiler verwaltete Freigabe und Wiederverwendung; empfohlen wurde die Aufbewahrung bis zum Verbindungsende.

Ein Treffer belegte nur die Zuordnung. eecid identifizierte keinen Menschen, authentisierte keinen Peer, schuf keinen Circuit und bewies keinen Medienfluss. Setup/connect belegte Bearer-Zustand; bidirektionale Pakete und Anwendungsmessungen belegten das Ergebnis.

Auch die Kodierung im Bearer-Protokoll blieb dessen Sache. RFC 3108 nannte mögliche Information Elements, machte aber aus dem SDP keine Autorität über die Signalisierung. Gemeinsamer Schlüssel bedeutete nicht gemeinsames Register.

Beschreiben, aufbauen, beobachten

In den Abläufen tauschten Controller Service-Informationen aus und wiesen Gateways an. Danach schickte ein Gateway das ATM-Setup samt eecid; der Empfänger fand den Kontext und antwortete connect. Erst danach konnte der Bearer Medien tragen.

SDP belegte Beschreibung. Ein Control-Ack belegte die Annahme einer Anweisung. Setup belegte einen Versuch, connect einen logischen Zustand. Keiner dieser Datensätze bewies allein Verkehr in beiden Richtungen, reale Verzögerung, Verlust oder Nutzerqualität.

Das Attribut chain verband getrennte SDP-Beschreibungen verschiedener Schichten derselben Verbindung, etwa IP und ATM, und unterschied sie von Alternativen. Die Verknüpfung hielt Dokumente sauber, materialisierte aber keine Schicht.

Spätere RFCs dürfen nicht rückwirkend als Betriebsbeleg dienen. RFC 3264 definierte Offer/Answer 2002; RFC 4566 und RFC 8866 revidierten SDP später. Sie zeigen Dokumentgeschichte, nicht die Verbreitung von RFC 3108.

Sicherheit lag in der Hülle

RFC 3108 stellte fest, dass Verschlüsselung von ATM/AAL2-Bearern und Authentisierung ihrer Signalisierung nicht wie bei RTP-Payloads konventionalisiert waren. Eine SDP-Zeile k= konnte einen Schlüssel oder dessen Bezug beschreiben, bewies aber keinen Schutz.

Beschreibungen konnten aus nicht vertrauenswürdiger Teilnehmerausrüstung stammen. Sicherheit sollte aus dem kapselnden Protokoll oder unteren Schichten kommen. SIP, MGCP und Megaco konnten IPsec-Authentisierung und optional Verschlüsselung nutzen. Eine verfügbare Konstruktion war keine Aussage über einen konkreten Betrieb.

Die Beweiskette benötigt getrennt: Original-SDP, Sender und Referenzknoten; Call- und Bearer-Rollen; Richtung vor und nach Übersetzung; Zuteiler, Scope und Lebensdauer der eecid; setup/connect/release; Security Association; installierte QoS; Zähler; Pakete beider Richtungen und Anwendungsergebnis.

Die Warnung betrifft transportierbare Wörter

ATM wirkt historisch, der Fehler nicht. Verteilte Systeme verwenden Wörter wie lokal, aktiv, primär, Eigentümer oder vorwärts in mehreren Schichten. Das Wort bleibt, sein Koordinatensystem wechselt. Eine signierte, unveränderte Nachricht kann dadurch in der nächsten Kontrollfläche falsch sein.

Das Gateway konnte keine der beiden Spezifikationen zur alleinigen Wahrheit erklären. Beide waren in ihrer Schicht autoritativ. Es musste übersetzen, Provenienz erhalten und mit dem Schlüssel verbinden, ohne die Register zu verschmelzen. Laufzustand und beobachteter Verkehr blieben weitere Tatsachen.

Beide Schichten sagten vorwärts. Sie stritten nicht über die Leitung, sondern über den Ursprung des Pfeils. RFC 3108 zeigt, warum dieser Ursprung bis zur Messung des echten Mediums erhalten bleiben muss.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3108.html
  2. https://www.rfc-editor.org/info/rfc3108
  3. https://datatracker.ietf.org/doc/rfc3108/
  4. https://www.rfc-editor.org/rfc/rfc2327.html
  5. https://www.rfc-editor.org/info/rfc2327
  6. https://datatracker.ietf.org/doc/rfc2327/
  7. https://www.rfc-editor.org/rfc/rfc2543.html
  8. https://www.rfc-editor.org/info/rfc2543
  9. https://www.rfc-editor.org/rfc/rfc2705.html
  10. https://www.rfc-editor.org/rfc/rfc2805.html
  11. https://www.rfc-editor.org/rfc/rfc3015.html
  12. https://www.rfc-editor.org/rfc/rfc3264.html
  13. https://www.rfc-editor.org/rfc/rfc4566.html
  14. https://www.rfc-editor.org/rfc/rfc8866.html