Zusammenfassung

  • RFC 3477 koppelte eine stabile Router ID mit einer endpunktlokalen Interface ID, damit RSVP-TE unnummerierte Punkt-zu-Punkt-Links vorgeben und aufzeichnen konnte.
  • Die Enden durften voneinander unabhängige Werte wählen; ERO-Absicht, IF_ID-Auflösung, RRO-Aufzeichnung und tatsächliche Weiterleitung blieben getrennte Belege.

„Unnummeriert“ klingt nach fehlender Identität. Der Link in RFC 3477 hatte jedoch zwei Namen. Jeder LSR an einem Ende vergab einen eigenen, und keiner der Werte durfte außerhalb des vergebenden Systems für sich allein als Identität des ganzen Links gelten.

Der Link musste Punkt zu Punkt sein. Jeder LSR wählte einen von null verschiedenen 32-Bit-Wert, der nur in seinem eigenen Geltungsbereich eindeutig sein musste. Zwischen den Werten beider Enden bestand ausdrücklich keine vorgegebene Beziehung. Von A aus war As Wert lokal und Bs Wert entfernt; von B aus wechselten die Bezeichnungen. Der Blickwinkel gehörte zur Bedeutung.

Der verwendbare Name war daher ein Tupel. Zur Interface ID kam die Router ID des LSR, der sie vergeben hatte. Diese Router ID sollte eine stabile IP-Adresse sein, meist ein Loopback, die erreichbar blieb, solange überhaupt Konnektivität zum LSR vorhanden war. Erst der Geltungsbereich machte aus einer lokalen Zahl eine transportierbare Referenz.

Damit konnten zwei Router dieselbe Zahl wiederverwenden, ohne zu kollidieren, weil ihre Router IDs verschieden waren. Zugleich durfte derselbe physische Link an beiden Enden verschiedene Zahlen tragen. Eine Datenbank, die diese Abweichung auf einen erfundenen Normalwert reduziert, beseitigt keine Unordnung. Sie löscht die Herkunft der Namen.

Die Endpunkte mussten ihre Vergaben austauschen. RFC 3477 nannte Konfiguration, LMP, RSVP oder CR-LDP bei einer Forwarding Adjacency sowie IS-IS- oder OSPF-Erweiterungen. Unterstützte das IGP Traffic Engineering, mussten sich seine Module und RSVP im selben LSR über die Kennungen einig sein. Ein korrektes Tupel konnte eine veraltete Nachbartabelle nicht heilen.

Der erste Beleg betraf die Routenabsicht. Dem Explicit Route Object wurde ein Unnumbered Interface ID Subobject mit Typ 4 und Länge 12 hinzugefügt. Es enthielt Router ID und Interface ID. Im ERO bezeichnete das Tupel den unnummerierten Link, den der geplante Pfad benutzen sollte. Es belegte nicht, dass der Link bereits durchlaufen worden war.

Darauf folgte die lokale Auflösung. Wählte ein Knoten einen unnummerierten Ausgang, trug er seine Router ID und lokale Kennung in IF_ID RSVP_HOP ein. Der empfangende LSR benötigte Wissen über die von seinen Nachbarn vergebenen Werte und suchte nach einer Übereinstimmung. Fand er keine, empfahl RFC 3477 IF_ID ERROR_SPEC mit Code 24 und Wert 16: „Unknown Interface Index“.

Der Fehler beweist nur, dass dieser Empfänger dieses nachbarschaftlich begrenzte Tupel mit seinem damaligen Wissen nicht auflösen konnte. Er beweist weder das Fehlen der Leitung noch Täuschung, einen insgesamt fehlerhaften IGP oder das Fehlen jedes Alternativwegs. Für die Ursache braucht man Quelle, Version und Zeitpunkt der Zuordnung sowie Nachrichtenrichtung und Adjazenzzustand.

Das Record Route Object verwendete ebenfalls Typ 4 und Länge 12, aber für eine andere Aussage. Das ERO formulierte den beabsichtigten Pfad; das RRO sammelte den von RSVP aufgezeichneten Pfadzustand. Gleiches Format machte aus einer Absicht keine Beobachtung und aus einer Kontrollaufzeichnung keine unabhängige physische Telemetrie.

Die RRO-Schutzbits hielten eine weitere Grenze fest. Ein Bit bedeutete, lokaler Schutz sei verfügbar. Das andere bedeutete, lokaler Schutz sei im Einsatz, typischerweise weil eine Reparatur den Tunnel nach einem Ausfall aufrechterhielt. Schutzfähigkeit und Schutzumschaltung waren unterschiedliche Ereignisse. Ein pauschaler Zustand „geschützt“ vernichtet die entscheidende Zeitachse.

Auch unnummerierte Forwarding Adjacencies folgten dem Modell. Ein als Link beworbener LSP erhielt am Head-End und am Tail-End je eine Kennung. Das Objekt LSP_TUNNEL_INTERFACE_ID, Klasse 193 und C-Type 1, konnte die Vorwärtsidentität in Path und die Rückwärtsidentität in Resv tragen. Selbst ein konstruierter Link behielt zwei administrative Perspektiven.

Spätere Dokumente zu GMPLS, OSPF, IS-IS und Link Bundling erweiterten die Bekanntmachung und Nutzung dieses Modells. RFC 6107 aktualisierte RFC 3477 später für Path Keys. Diese Texte erklären die Entwicklung, belegen aber weder Funktionen einer Implementierung im Januar 2003 noch den Betrieb eines bestimmten Pfads.

Die Realitätsebenen aus Heng Lus Notizen liefern die passende Prüfmethode. Eine Router ID begrenzt den Namen, beweist aber keine aktuelle Erreichbarkeit. Ein ERO beschreibt Absicht, nicht Durchquerung. Ein RRO hält RSVP-Zustand fest, nicht physische Kontinuität. Eine Label-Zuweisung ist keine Hardwareprogrammierung, und Hardwareprogrammierung ist noch keine Verkehrszustellung.

Eine Prüfung bewahrt die rohe RSVP-Nachricht, Session, Absender, Richtung und Zeit. Sie erhält ERO-Reihenfolge, IF_ID-Tupel, Quelle der Nachbarabbildung, Suchergebnis, Path- und Resv-Zustand, Label-Operation, RRO-Reihenfolge und Flags. Erst danach werden Inventar, Adjazenz, Forwarding-Tabelle, Alarme und Verkehrszähler mit eigener Provenienz verbunden.

Die wichtigste Regel lautet: Eine Interface ID darf nie von der Router ID getrennt werden, die sie vergeben hat. Ebenso wenig dürfen die Werte beider Enden in eine erfundene kanonische Zahl gepresst werden. Ihre Verschiedenheit ist kein Rauschen, sondern der Beleg dafür, wie Benennungsmacht verteilt war.

RFC 3477 ist Internetgeschichte, weil es Pluralität koordinierte, ohne sie zu beseitigen. Ein verteiltes System brauchte keinen einzigen Weltnamen. Es musste den Geltungsbereich mitführen, beide Sichtweisen erhalten und Absicht, Auflösung, Aufzeichnung sowie operative Wirklichkeit auseinanderhalten. Der unnummerierte Link war nicht namenlos; seine Namen waren richtigerweise lokal.

Quellen