Zusammenfassung

  • Eine Transport Class bündelt Tunnel, die der Betreiber für ausreichend ähnlich hält. Ihre 32-Bit-Color bezeichnet diese lokale Klasse, definiert aber kein universelles SLA.
  • Treffen TEA Color sub-TLV, Transport Class RT und Service-Route-Color zusammen, gilt die Priorität genau in dieser Reihenfolge.
  • TRDB-Import, Next-Hop-Auflösung, Fallback, FIB-Programmierung, Paketweiterleitung und Serviceergebnis sind eigene Zustände.

Private Zahl, lokale Aussage

RFC 9832 erlaubt, unterschiedliche Tunnelmechanismen wie RSVP-TE, SR-TE und Flex-Algo nach gemeinsamen TE-Eigenschaften zu gruppieren. Niedrige Latenz, Schutz oder das Meiden bestimmter Knoten können solche Eigenschaften sein. Die genaue Klassifizierung bleibt implementationsspezifisch; der Betreiber entscheidet, welche Ähnlichkeit genügt.

Die Klasse erhält einen 32-Bit Transport Class ID, auch Color genannt. Null steht für Best Effort, alle anderen Werte sind Private Use. Daraus folgt keine weltweite Semantik. Color 100 kann in zwei Netzen andere Latenzgrenzen, Verlustbudgets und Schutzbedingungen bedeuten.

Ein Herkunftsbeleg muss deshalb Zahl, administrative Domäne, messbare Definition, Eigentümer, Geltungsbereich und Version verbinden. Eine nackte Zahl bestätigt nur Syntax.

Vorrang braucht Eingangsbelege

Im Tunnel Encapsulation Attribute bezieht sich Color auf die jeweilige Kapselung. Der Transport Class RT einer BGP-CT-Route steuert als Route Target den Import und kann als Mapping Community ein Resolution Scheme wählen. Die Color Extended Community einer Service-Route trägt die Overlay-Anforderung.

Abschnitt 7.10 bevorzugt die spezifischere Angabe: zuerst TEA Color sub-TLV, dann Transport Class RT, zuletzt Service-Route-Color. Die Regel macht einen Konflikt deterministisch, aber nicht von selbst auditierbar.

Zu speichern sind alle empfangenen Werte, Trägerattribute, Peer, Policy-Version und Ergebnis. Wer nur „effective Color 100“ festhält, kann später nicht zeigen, ob eine Kapselungsangabe die Serviceanforderung verdrängte.

TRDB ist noch kein Forwarding

Zu jeder Transport Class gehört eine logische Transport Route Database. Eine BGP-CT-Route enthält RD:Endpoint, Transport Class RT sowie MPLS-Label oder ein vergleichbares Forwarding-Kennzeichen. Ist die Klasse lokal provisioniert, weist die Route-Target-Rolle die Route ihrer TRDB zu.

Der RFC erlaubt eine TRDB als reine Control-Plane-Tabelle zur Next-Hop-Erreichbarkeit. Tunnelrouten benötigen keinen Forwarding-Footprint, solange sie keinen Next Hop auflösen. Richtiger Import belegt deshalb weder Nutzung durch eine Service-Route noch einen Hardwareeintrag.

Als Mapping Community führt der RT zu einem lokalen Resolution Scheme. Es enthält eine oder mehrere geordnete TRDBs. Longest Prefix Match sucht den Endpoint; eine spätere Datenbank wird nur genutzt, wenn die vorherigen nichts finden. Fehlt ein Scheme für die Klasse, greift Best Effort. Fehlt die Mapping Community, wird ebenfalls Best Effort genutzt, und die BGP-CT-Route kommt in keine Klassen-TRDB.

Erreichbarkeit kann so fortbestehen, obwohl die zugesagte Behandlung verschwunden ist.

Fallback ist eine Zustandsänderung

Ein Treffer in der zweiten TRDB sagt nicht, warum die erste keinen Endpoint enthielt. Tunnelstörung, Import-Policy, RTC-Filter, falscher Endpoint, veraltete Provisionierung oder inkompatible Forwarding-Technik sind verschiedene Ursachen. Der RFC ordnet die Suche, nicht die Diagnose.

Der Auflösungsbeleg nennt empfangene Route und Peer, sämtliche Color-Felder, wirksame Mapping Community, Scheme-Version, TRDB-Reihenfolge, Treffer, Tunnel und Fallback. Ohne Treffer ist die Route unauflösbar. Eine unbrauchbare Best-Effort-BGP-CT-Route darf nicht weiter propagiert werden.

Route Target Constraint beeinflusst die Verteilung. Beim Aufbau des Ausgangsfilters sind mehrere externe RTC-Pfade zu betrachten, nicht nur der Best Path. Eine fehlende Route kann daher zuerst ein Verteilungsproblem sein.

Grenzen übersetzen, sie beglaubigen nicht

Im Beispiel nicht übereinstimmender Color-Domänen bleibt die Service-Community color:0:100500 bestehen. Lokale Schemes führen sie zu TRDB 500, 300 und 100. An den Grenzen wird der Transport Class RT von 500 auf 300 und danach auf 100 umgeschrieben.

Das reduziert Koordination auf benachbarte Domänen. Es bestätigt nicht, dass deren „Gold“-Klassen dasselbe SLA haben. Ein Mapping-Beleg muss empfangenen und gesendeten RT, beide Definitionen, Vereinbarung, Policy-Commit, ausführenden Router, Zeitpunkt und Rollback erhalten. Nur der Endwert löscht die Autorisierung der Übersetzung.

Auflösung, FIB, Paket, SLA

Ein MPLS-Border Node, der eine BGP-CT-Route mit Next Hop Self weitergibt, vergibt ein Label und installiert eine Route zum Swap oder Pop des eingehenden Labels, bevor der Verkehr in den aufgelösten Tunnel gelangt. Implementierungen dürfen BGP CT selektiv für Control-Plane-Peering in die FIB aufnehmen.

Danach sind Hardwarezustand, gemeinsame Kapselung und Paketpfad zu prüfen. Die Interoperabilitätsbeispiele zeigen, dass ein reiner MPLS- und ein reiner SRv6-Knoten ohne gemeinsame Technik ihre BGP-CT-Routen nicht direkt nutzen können. Erst Verlust, Latenz, Verfügbarkeit und Messfenster am Serviceabschluss belegen das SLA.

RFC 9832 ist Experimental. Veröffentlichung beweist keine Einführung oder Leistung. Erratum 8583 ist verifiziert und redaktionell; es ersetzt dreimal SN1 durch SN11. Sitzungsschutz und Filter begrenzen Transport und Reichweite, bestätigen aber nicht die Betreibersemantik.

Heng Lus Gedanke eines „farblosen“ Internets stellt beobachtbare Effizienz über Etiketten. Hier bleibt Color ein Index, dessen Wert durch Ausführung belegt wird. Running-Code Primacy verlangt reproduzierbare Attribute, Policy und FIB; Reality Layers trennt Kennung, Bedeutung, Control Plane, Forwarding und Kundenergebnis. Das sind BTW-Lesarten, keine zusätzlichen IETF-Regeln.

Quellen