Zusammenfassung

  • RFC 3476 brachte OIF-Objekte für das optische UNI in öffentliche LDP- und RSVP-Namensräume, verwies für Inhalt und Gebrauch aber auf die OIF-Spezifikation.
  • Nicht verfügbare Diversität, ein nicht verfügbares Dienstniveau, eine unbekannte Verbindung sowie unberechtigte Sender oder Empfänger blieben mögliche Ergebnisse: Eine erkannte Nummer war nur der erste Beleg.

Ein Protokollregister verwaltet eine erstaunlich kleine Sache: die Bedeutung einer Zahl. Diese Arbeit ist unverzichtbar. Lesen zwei Implementierungen denselben Wert verschieden, stimmen zwar die Bits, nicht aber ihre Handlungen. Ein öffentlicher Eintrag verhindert die Kollision. Er baut keinen Lichtpfad und erteilt niemandem einen Auftrag.

RFC 3476 erschien im März 2003 als Informational, nicht als Internet Standard. Das Optical Internetworking Forum hatte Signalisierung für ein optisches User Network Interface entwickelt. Wo immer möglich, sollte dieses UNI LDP, RSVP, RSVP-TE und GMPLS wiederverwenden. Für wenige UNI-spezifische Anforderungen wurden dennoch neue Kennungen in IETF-Protokollen benötigt.

Für LDP führte das Dokument je drei Source-ID- und Destination-ID-TLVs für IPv4, IPv6 und NSAP auf. Hinzu kamen Egress Label, Local Connection ID, Diversity, Contract ID und UNI Service Level. Die Werte lagen zwischen 0x0960 und 0x0970. RSVP erhielt GENERALIZED_UNI mit Klassennummer 229 und C-Type 1 sowie UNI_IPv4_SESSION mit Klasse 1 und C-Type 11. Die Unterobjekte konnten Quell- und Ziel-TNA, Diversität, Ausgangslabel und Dienstniveau tragen.

Der Zahlenkatalog gab sich nicht als vollständige Dienstdokumentation aus. Immer wieder verwies RFC 3476 Inhalt und Verwendung an die UNI-Spezifikation des OIF. Die öffentliche Nummer schuf einen stabilen Anker. Das externe Abkommen erklärte die Semantik. Ein reales Netz musste danach Identität, Berechtigung, Richtlinie und Ressourcen prüfen.

Diese Trennung war institutionell. OIF beschrieb ein dienstnahes Implementierungsabkommen. IETF stellte wiederverwendbare Protokolle bereit. IANA hielt Zahlenräume kollisionsfrei. Hersteller implementierten die Zustandsautomaten, Betreiber kontrollierten Topologie und knappe optische Kapazität. Aus einer RFC-Veröffentlichung wurde kein IETF-Dienststandard; aus einem IANA-Eintrag keine Annahmepflicht für Betreiber.

Auch die Grenze zwischen öffentlich und privat blieb sichtbar. UNI-spezifische LDP-Statuswerte lagen im Private-Use-Raum 0x3Fxxxxxx und brauchten keine IANA-Verwaltung. Die zuvor definierten Nachrichten Status Enquiry und Status Response waren bereits überholt, weshalb keine Werte beantragt wurden. Das Register bildete also nicht jede Idee ab, sondern das Ergebnis einer Auswahl.

Die RSVP-Fehler benennen die eigentliche Grenze. Ein Netz konnte Diversity not available, Service level not available oder Invalid/Unknown connection ID melden. Unter Policy Control Failure gab es Unauthorized sender und Unauthorized receiver. In keinem Fall war die Zahl unverständlich. Die Ablehnung erfolgte, nachdem sie korrekt verstanden worden war.

Ein GENERALIZED_UNI-Objekt kann Klasse, C-Type, Länge und Unterobjekte korrekt codieren. Seine TNA können gültig aussehen. Das beweist weder die vertragliche Befugnis des Senders noch die Zustimmung des Empfängers. Es beweist auch nicht, dass zwei unabhängige Wege existieren oder Kapazität frei ist. Syntaktische Gültigkeit und operative Machbarkeit sind verschiedene Quittungen.

Der Codepunkt sagt: „Interpretiere diese Bits als diesen Objekttyp.“ Er sagt nicht: „Folge diesem Akteur“, „Akzeptiere diesen Vertrag“, „Reserviere diese Wellenlänge“ oder „Der Kunde ist versorgt.“ Werden diese Aussagen zusammengezogen, leiht sich ein einfacher Registertreffer die Autorität aller späteren Entscheidungen.

Die umliegenden RFCs hielten die Schichten getrennt. RSVP verwaltete Reservierungszustand, RSVP-TE ergänzte Tunnelsignalisierung, LDP verteilte Labels, GMPLS dehnte Labels auf Ressourcen jenseits von Paketen aus. RFC 3471 bis 3475 unterschieden Identität, Nachrichtenaustausch, Benachrichtigung, Call und Connection. RFC 3476 fügte die numerische Naht hinzu; es hob die anderen Schritte nicht auf.

RFC 3936 ordnete später Zuweisungsregeln für RSVP, RFC 8126 schärfte die Trennung zwischen IANA-Anweisungen und technischer Dokumentation. Diese späteren Texte dürfen nicht als vollständige Regeln des Jahres 2003 zurückprojiziert werden. Sie machen aber sichtbar, was RFC 3476 bereits tat: eine Referenz festlegen, ohne ihre Funktion auszuführen.

Die heutigen IANA-Register belegen Zuweisung und Referenz. Sie sind keine Feldtelemetrie. Sie zeigen nicht, ob eine Pfadberechnung Diversität fand, Kapazität reserviert, ein optischer Cross-Connect programmiert, Licht gemessen oder Verkehr übertragen wurde.

Heng Lus Disziplin der Realitätsschichten beginnt deshalb bei der Rohmeldung. Zu sichern sind Protokoll, Wert, Länge, U/F-Bits oder Klasse/C-Type und Parsergebnis. Danach wird die Nummer gegen einen datierten Registerstand aufgelöst und die genaue RFC- und OIF-Fassung geöffnet. Identität, Authentisierung, Autorisierung, Admission, Pfad, Reservierung, Hardwareprogrammierung, Signal, Verkehr und Dienstresultat folgen als getrennte Belege.

Eine lesbare Source ID ist keine authentisierte Vollmacht. Ein Diversity-Unterobjekt sind keine zwei unabhängigen Pfade. Ein Service-Level-Feld ist kein erfülltes SLA. Ein Egress Label ist keine physische Abnahme. Auch das Ausbleiben eines Fehlers beweist nicht den erfolgreichen Abschluss aller Folgearbeiten.

Ebenso sorgfältig ist der Ablehnungspfad zu sichern: Fehlerobjekt, Code, Subcode, sendender Knoten, Zeit und beantwortete Anfrage. „Diversity not available“ ist aussagekräftiger als ein allgemeiner Fehler, belegt aber weder die gesamte verborgene Topologie noch die Unmöglichkeit jeder Alternative.

RFC 3476 ist deshalb Institutionengeschichte in Tabellenform. Ein öffentliches Register lässt unabhängige Implementierungen dasselbe Objekt benennen. Diese Infrastruktur ist notwendig, aber weder Souverän über den Dienst noch Beweis seiner Existenz. Die Nummer eröffnet die Akte; nur die weiteren Belege können sie schließen.

Quellen