Zusammenfassung

  • RFC 9790 verwirft für neue Implementierungen und Deployments die Bestimmung des MPLS-Payloads allein aus den ersten vier Bits nach dem Label-Stack. 0x4 und 0x6 können IPv4/IPv6 anzeigen, aber ebenso zu einem Nicht-IP-Frame oder Post-Stack Header gehören.
  • Die korrekte Bedeutung stammt aus dem Kontroll- oder Managementkontext der vorhergehenden Labels. Für Lastverteilung sind Entropy Label oder FAT Pseudowire Label belastbarer als Felder aus einem nur vermuteten Format.
  • Registry-Eintrag, Control Word und Entropie-Label begrenzen jeweils Unklarheit. Keines beweist Implementierung, Pfadwahl, Gleichverteilung, Paketreihenfolge oder Kundenergebnis.

Die Forwarding-Engine findet das Ende des MPLS-Stacks. Das nächste Nibble lautet 0100. Alte Logik nennt es IPv4, liest an erwarteten Offsets Adressen und Ports und berechnet daraus ein ECMP-Mitglied.

Tatsächlich folgt ein Ethernet-Frame in einem Pseudowire. 0100 ist nur der Beginn der Ziel-MAC-Adresse. Der Router hat IP nicht erkannt. Er hat Ähnlichkeit mit Identität verwechselt und diese Vermutung in eine reale Wegentscheidung übersetzt.

RFC 9790 ordnet nur sechzehn mögliche Werte. Operativ zieht es eine größere Grenze: Beobachtung, Bedeutung und Wirkung brauchen unterschiedliche Belege.

Das Nibble belegt nur sich selbst

Ein MPLS-Paket enthält einen Layer-2-Header, mehrere vier Oktett große Label Stack Entries, gegebenenfalls einen Post-Stack Header und danach einen optionalen eingebetteten Frame. Das Bottom-of-Stack-Bit markiert das letzte Label. Über die folgende Struktur sagt es nichts.

Der PFN sind die oberen vier Bits des ersten Oktetts hinter dem Stack. Bei nacktem IPv4 überschneiden sie sich mit Versionswert 4, bei IPv6 mit 6. Beginnt dort Ethernet, ein Pseudowire-Control-Word oder ein anderer PSH, gehören die Bits zu diesem Format.

Der MPLS-Stack besitzt keinen allgemeinen Payload-Typ. RFC 9790 verlangt den Kontext, den Control- oder Management-Plane dem vorhergehenden LSE oder der LSE-Gruppe zugeordnet haben. Ein Mitschnitt belegt 0x4; IPv4 belegt er damit nicht.

In Heng Lus Realitätsschichten ist die Rollenverteilung klar: Bits sind Messung, die Servicebindung ist Kontext, der Parser ist Interpretation und die Forwarding-Tabelle erzeugt eine Wirkung. Wer daraus eine einzige Aussage macht, versteckt die Stelle, an der Gewissheit endete.

Aus einer Abkürzung wurde verdeckte Forwarding-Politik

Die alte Heuristik hatte einen Nutzen. Der IP-Fünfertupel verteilt Flows feiner als ein einzelnes Top-Label. Geräte behandelten deshalb 4 als IPv4 und 6 als IPv6, lasen vermeintliche Felder und fielen sonst auf einen Label-Stack-Hash zurück.

Bei falscher Voraussetzung wird die zusätzliche Präzision erfunden. Ethernet-MAC-Adressen können mit 4 oder 6 beginnen. RFC 8469 verweist auf entsprechende Zuweisungen und auf randomisierte lokale MACs. Ohne PW Control Word kann ein Transitgerät Ethernet als IP sezieren.

Beliebige Bytes werden zu Flow-Schlüsseln. Pakete eines geordneten Flows können auf unterschiedliche Pfade geraten oder eine unpassende Klassifizierung erhalten. Der Irrtum bleibt nicht in Telemetrie: Er entscheidet über die Leitung.

Der Kontext steht vor dem gelesenen Feld

RFC 9790 dreht die Frage um. Nicht „Woran erinnern diese Bits?“, sondern „Was darf laut Label-Bindung folgen?“ Für jeden Payload, der weder IPv4 noch IPv6 ist, ist ein PSH mit einem PFN ungleich 0x4 und 0x6 erforderlich.

Ein PW Control Word dient alten Engines als Trennzeichen. Es authentifiziert keinen Absender und bestätigt keinen Inhalt. Es verhindert genau eine vorhersehbare Verwechslung. Seine enge Reichweite macht die Aussage belastbar.

Die IANA-Registry verwendet Werte absichtlich mehrfach. 0x0 gehört zu DetNet-, NSH- und PW-Formaten; 0x1 zu mehreren Associated Channels. Das vorherige Service-Label löst die Mehrdeutigkeit auf. Ein global eindeutiger Typcode ist der PFN gerade nicht.

Das ist Minimum Initial Specification praktisch angewandt: Die gemeinsame Schicht hält Werte, Quellen und knappe Regeln. Jeder Knoten prüft mit seinem lokalen Zustand. Die Registry koordiniert Semantik; sie sieht weder Paket noch Ergebnis.

Zwei Registries, zwei Geltungsbereiche

IP Version Numbers erfasst Versionswerte in einem IP-Header. Post-Stack First Nibble erfasst PSH-Typen. Nur 4 und 6 überschneiden sich aus Gründen der Rückwärtskompatibilität.

Die PFN-Registry dokumentiert alle sechzehn Werte und verlangt Standards Action für neue Zuweisungen. Ein Eintrag beweist, dass eine Spezifikation einen Wert beschreibt. Er beweist nicht, dass dieses Paket dem Format entspricht, eine Linecard es implementiert oder der Betreiber es aktiviert hat.

Publikation verändert Normtext, nicht laufenden Code. Die Registry darf nicht als Zeuge für einen Datenpfad behandelt werden, den sie nie beobachtet hat.

Entropie gehört an den informierten Rand

RFC 9790 empfiehlt dedizierte Lastverteilungs-Labels: das Entropy Label aus RFC 6790 oder das FAT Pseudowire Label aus RFC 6391. Am Ingress sind Dienst und ursprüngliches Paket noch bekannt. Dort werden legitime Flow-Felder gewählt, ein Wert berechnet und in den Stack gelegt.

In RFC 6790 steht das reservierte Label 7 als Entropy Label Indicator unmittelbar vor dem Entropy Label. Transit-LSRs können den Stack verwenden, ohne den eingebetteten Payload zu erraten. Der wissende Rand erzeugt die Information; der kontextarme Kern verarbeitet das explizite Signal.

Explizit heißt nicht erfolgreich. Capability-Signalisierung, Stack-Tiefe und Hashqualität bleiben relevant. Große Flows können kollidieren. Das Label belegt einen transportierten Wert, nicht gleichmäßige Auslastung, zugesagte Latenz oder Reihenfolge.

FAT-Pseudowires sind optional, der Einzelpfad bleibt Standard. Endpunkte signalisieren Sende- und Empfangsfähigkeit oder werden statisch identisch provisioniert. Ein Flow Label beweist daher weder beidseitige Zustimmung noch seine Verwendung an jedem Transitknoten.

Deprecated ist kein Bestandsbericht

RFC 9790 aktualisiert RFC 4928 und verbietet die PFN-Ableitung in neuen Implementierungen und Deployments. Legacy-Router dürfen ihr bestehendes Verhalten fortsetzen. Vor einer späteren vollständigen Ablösung verlangt der Text Evidenz über vermarktete und installierte Implementierungen.

Die Norm setzt eine Richtung. Sie programmiert vorhandene ASICs nicht um. Ein Dienstpfad kann Hardware und Softwaregenerationen mit verschiedenem Verhalten enthalten. „Deprecated“ beweist keine Stilllegung; „Legacy“ erteilt keine Dauererlaubnis.

Ein belastbarer Beleg hält Stack und BoS, Folgeoktett, Label-Bindung, Format und Registry, Hardware und Parser, Entropy/FAT Label oder Ersatzinputs, ausgewähltes Mitglied, Ordnung/Verlust/Latenz sowie Kundenergebnis getrennt. Capture, Control-Plane-Snapshot, Konfiguration und wiederholte Datenpfadtests haben jeweils eigene Aufgaben.

RFC 9790 macht vier Bits nicht mächtiger, sondern bescheidener. Ein verlässliches System lässt kein Symbol über den Payload herrschen. Es verlangt für jede Schlussfolgerung einen eigenen Beleg.

Quellen

  1. RFC 9790 — IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack
  2. RFC 4928 — Avoiding Equal Cost Multipath Treatment in MPLS Networks
  3. RFC 3032 — MPLS Label Stack Encoding
  4. RFC 4385 — Pseudowire Emulation Edge-to-Edge Control Word
  5. RFC 6790 — The Use of Entropy Labels in MPLS Forwarding
  6. RFC 6391 — Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
  7. RFC 8469 — Recommendation to Use the Ethernet Control Word
  8. IANA — Post-Stack First Nibble
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile