Zusammenfassung

  • RFC 3936 teilte jeden Class-Num-Verhaltensbereich in Standards Action, Expert Review und Vendor Private auf.
  • Nur bei einer unbekannten Objektklasse bestimmten die oberen Bits Ablehnung, Objektverlust oder unveränderte Weitergabe; andere RSVP-Nummern brauchten eigene Regeln.

Gleiche Verwaltungssprache, verschiedene Drahtwirkung

RFC 2205 kodierte drei Reaktionen auf unbekannte Klassen. 0bbbbbbb verwirft die gesamte Nachricht und erzeugt Unknown Object Class. 10bbbbbb entfernt das Objekt ohne Weiterleitung oder Fehler. 11bbbbbb reicht es ungeprüft und unverändert weiter. Der offizielle Eintrag belegt den Dokumentstatus; die Ausführung folgt dem Byte.

RFC 3936, BCP 96 von 2004, setzte in jeden Korridor drei Zuteilungswege. Im Ablehnungsband lagen Standards Action 0–119, Expert Review 120–123 und Vendor Private 124–127. Im Objektverlustband: 128–183, 184–187 und 188–191. Im Weitergabeband: 192–247, 248–251 und 252–255.

Das heutige Register IANA RSVP Parameters zeigt diese Matrix. Die Zuteilungsspalte regelt Nachweis und Prüfung; das Bitmuster regelt Altsoftware. Ein privater Wert aus 252–255 kann daher über fremde alte Knoten wandern, obwohl sein Inhalt proprietär bleibt.

Der Eintrag zu RFC 3936 nennt RFC 2205 und RFC 3209 als aktualisierte Dokumente; Errata sind separat prüfbar. Der RFC-3209-Eintrag dokumentiert RSVP-TE, nicht dessen flächendeckenden Einsatz.

Sub-objects waren keine Class-Nums

RFC 3936 teilte auch die Typen von EXPLICIT_ROUTE und RECORD_ROUTE in Standards-, Experten- und Privatbereiche. Private Sub-objects begannen mit einer vier Oktett langen SMI-Unternehmensnummer. Dennoch besaß ihr Typfeld nicht automatisch die drei Class-Num-Reaktionen. Wer beide Tabellen nur als „RSVP private values“ zusammenfasst, verliert die Verarbeitungsebene.

RFC 3473 liefert den Kontext späterer GMPLS-Erweiterungen. RFC 2207 behandelt virtuelle Zielports für IPsec-Datenströme. Jeder Namensraum benötigt seine eigene Vergabe- und Verarbeitungsregel.

Auch der Privatwert war nicht anonym. Seine erste Datenwortposition trug eine Nummer aus IANA Private Enterprise Numbers. Mehrere Unternehmen konnten dieselbe private Nummer wiederverwenden, ohne ihre Formate zu verwechseln. Die Unternehmensnummer authentifizierte aber weder Absender noch Inhalt und schuf keine Interoperabilität.

Eine unbekannte Klasse unterschied sich zudem von einem unbekannten C-Type einer bekannten Klasse. Letzterer führte nach RFC 2205 im Allgemeinen zur Ablehnung. Neue Klassen mussten deshalb ihre künftige C-Type-Vergabe festlegen; alte Klassen blieben standardmäßig Standards Action.

Verfahrensänderungen folgten ebenfalls der Spur: Standards-Entitäten benötigten Standards Track, Expert-Review-Entitäten ein Experimental RFC. Die damalige allgemeine Terminologie stammte aus RFC 2434; später ersetzte RFC 8126 diese Leitlinie.

Ein IANA-Eintrag beweist keine Implementierung. Heng Lus Texte über minimale Anfangsspezifikation und laufenden Code helfen, Registrierung, Software und Betrieb getrennt zu halten.

RFC 3936 verwaltete somit nicht bloß knappe Zahlen. Es ordnete institutionelle Erlaubnis in Maschinenreaktionen ein, die bereits ohne Kenntnis der Erweiterung wirksam waren.