Zusammenfassung

  • RFC 3033 wies den Informationsfeldern von Q.2941 Generic Identifier und Q.2957 User-to-user Signaling Internet-Bedeutungen zu und unterschied damit Sitzungs- und Ressourcenkennungen von transportierten Einrichtungsdaten.
  • Eine korrekte Kennung war nur ein Koordinationsinput. Erfolgreicher VC-Aufbau, Interpretation auf der angerufenen Seite, Benachrichtigung der IP-Schicht und tatsächliche Migration mussten jeweils gesondert belegt werden.

Der SETUP-Nachricht liegen Quell- und Zieladresse, Protokollnummer und beide Ports bei. Die Gegenseite kann damit genau erkennen, welche Sitzung gemeint ist. Trotzdem können die Pakete weiterhin mit anderen Sitzungen über die Standard-VC zwischen den Routern laufen. Die Nachricht beweist weder, dass eine neue VC existiert, noch dass die IP-Schicht ihren Zustand geändert hat.

RFC 3033 erschien im Januar 2001 als Proposed Standard. Es ordnete Werte den Informationsfeldern zweier optionaler ATM-Signalisierungselemente zu. Schon der Titel zieht die Grenze: Zuweisung eines Informationsfelds und eines Protokollbezeichners. Für lang laufende und QoS-sensitive Sitzungen über ATM nannte das Dokument den Rahmen unverzichtbar, warnte aber zugleich, er müsse nicht das vollständige, interoperable Implementierungsprotokoll sein. Dieses lag außerhalb des Umfangs.

Der Sitzungswechsel war an Erfolg gebunden

Im Beispiel teilen sich neue Sitzungen zunächst eine Standard-VC zwischen Routern. Erkennt ein Router eine lang laufende Sitzung, richtet er eine neue VC für sie ein. RFC 3033 formuliert die Bedingung ausdrücklich: Erst nach erfolgreichem Aufbau der neuen VC wird die Sitzung dorthin verlegt.

Auf der angerufenen Seite muss die B-ISDN-Signalisierungseinheit erkennen, dass der eingehende Ruf einer Sitzung des Internet-Protokolls entspricht, und diese Information an die IP-Einheit melden. Die IP-Schicht führt den Wechsel aus. Die Kennung bietet beiden Ebenen einen gemeinsamen Bezugspunkt; sie erkennt nicht die Sitzungsdauer, baut keine Verbindung auf, garantiert keine Zustellung der Meldung und ändert keinen Weiterleitungszustand.

„Kennung empfangen“, „VC aufgebaut“, „Sitzung migriert“ und „Pakete auf dem neuen Pfad beobachtet“ sind daher verschiedene Nachweise. Der erste ersetzt die übrigen nicht. Ein einzelnes Erfolgsbit würde einer Kontrollnachricht eine Ausführungsautorität zuschreiben, die sie nicht besitzt.

Zwei Informationselemente, zwei Aufgaben

Der Generic Identifier nach Q.2941 war für den Transport von Kennungen zwischen Steuerungsebenen gedacht. Das ATM-Netz durfte seinen Inhalt prüfen; ein Element konnte mehrere typisierte Kennungen enthalten. User-to-user Signaling (UUS) nach Q.2957 transportierte dagegen Nutzerdaten durch die Steuerungsebenen, deren Inhalt das ATM-Netz nicht prüfte. Auch Ausnahmebehandlung und Interworking unterschieden sich. Die Höchstlängen betrugen 63 Oktette für Generic Identifier und 133 für UUS.

„Transparenter Transport“ bezeichnete eine Transporteigenschaft für ein Element ohne Kodierungsfehler. Daraus folgten weder die Wahrheit der Werte noch die Authentizität des Senders oder die Ausführung des angeforderten Vorgangs. Eine intakt zugestellte Nachricht konnte weiterhin nur ein Koordinationsvorschlag sein.

Typen sagen, was die Bytes bezeichnen sollen

RFC 3033 ordnete Anwendungswerte IPv4, ST2+, IPv6 und MPLS zu. Der Bezeichnertyp 0x01 bedeutete Session, 0x02 Resource; ein Bereich blieb IANA-Zuweisungen vorbehalten und 0xFE experimentellen oder organisationsspezifischen Verwendungen.

Die IPv4-Sitzungskennung hatte 13 Oktette: zwei Adressen, Protokoll und zwei Ports. Die entsprechende IPv6-Form umfasste 37 Oktette. Beide waren für explizite Reservierungen gedacht; Wildcard-Zuordnungen brauchten einen anderen Typ. Eine MPLS-VCID war eine vier Oktette lange Ressourcenkennung, nicht die Einrichtung von Labelweiterleitung.

Die Typisierung beantwortete eine notwendige Frage — welchen Gegenstand sollen diese Bytes benennen? — ließ aber andere offen. RFC 3033 legte weder die Reihenfolge mehrerer Kennungen noch die Bedeutung wiederholter gleicher Typen oder eines leeren Generic-Identifier-Elements fest. Eine CONNECT- oder ADD-PARTY-ACK-Antwort musste unter der beschriebenen Bedingung mindestens ein Generic-Identifier-Element enthalten, musste aber nicht dieselben Kennungen zurücksenden. So wurde Verhandlung ermöglicht, ohne ihr detailliertes Verfahren festzulegen.

Ein ATM-Netz ohne Unterstützung durfte den Ruf auslösen, das Element entfernen oder die Signalisierungsnachricht verwerfen.

RSVP-Transport beweist keine QoS

Bei UUS stand der Diskriminator 0x06 für Internet-Protokoll/Anwendung, die Anwendungskennung 0x02 für eine RSVP-Nachricht. RFC 3033 ordnete Resv SETUP, ResvConf CONNECT sowie ResvErr und ResvTear RELEASE zu. Einrichtungsdaten konnten so in der B-ISDN-Signalisierung mitgeführt werden.

Das Dokument verglich ein sequenzielles Verfahren, bei dem das Einrichtungsprotokoll über eine Standard- oder bestimmte VC lief, mit einem gleichzeitigen Verfahren, das die Nachricht als Informationselement in der Signalisierung trug. Das gleichzeitige Verfahren konnte Admission Control und Timer vereinfachen, unterstützte aber zumindest PVC nicht. Beide Wege blieben erforderlich. Eine RSVP-Nachricht beweist weder Annahme noch installierte QoS, Verkehr auf der gewünschten VC oder einen Anwendungserfolg.

RFC 3033 ließ Sitzungsaggregation, Wildcard-Kennungen, IPv6-Flow-Labels und Traffic Classes offen. Auch die Sicherheitsgrenze blieb eng: Eine verifizierte oder vom Netz gelieferte Rufnummer konnte zur Authentisierung beitragen; die Sitzungskennung selbst war weder Authentikator noch Autorisierung oder Leistungsnachweis. Der Standard machte den Gegenstand der Koordination lesbar. Ausführung, VC-Zustand, Migration und beobachtete Wirkung blieben getrennte Tatsachen. Standards-Track-Status und IANA-Register belegen keine Verbreitung.

Quellen

Heng Lu verfasste oder billigte RFC 3033 und die ITU-T-Empfehlungen nicht; seine Texte dienen als spätere analytische Perspektiven.