Zusammenfassung

  • Upstream-assigned Labels sind nach RFC 5332 optional und dürfen nur verwendet werden, wenn der Support des downstream LSR bekannt ist. Wie dieses Wissen entsteht, definiert das RFC nicht; ein lokales Feature-Flag reicht deshalb nicht.
  • 0x8848 signalisiert in den festgelegten Multicast-Kontexten die Zuweisungsrichtung des Top-Labels. Es beweist weder gültigen Peer-Support noch richtigen Label-Space, Replikation, Empfang oder Serviceerfolg.

Eine Capability wurde in eine Beziehung umgeschrieben

Nehmen wir an, ein Controller inventarisiert Router A. Das Betriebssystem unterstützt upstream-assigned Labels. Der Controller schreibt daraufhin für jede Nachbarschaft von A peer_support = true. Router B wird später durch ein älteres System ersetzt; die Zeile bleibt bestehen.

RFC 5332 fordert Wissen über den downstream LSR, nicht nur die Fähigkeit des Senders. Das Wissen kann aus Konfiguration, Signalisierung, Provisionierung oder einem anderen Verfahren stammen, doch seine Methode liegt außerhalb der Spezifikation. Gerade deshalb muss die Betriebsplattform Herkunft und Gültigkeit erhalten.

Ein brauchbarer Capability Receipt nennt Peer-Identität, Link oder Tunnel, Quelle, Softwarestand, Beobachtungszeit, Ablaufbedingung und den Entscheider, der ihn akzeptiert hat. Ohne diese Felder ist „bekannt“ nur eine Behauptung.

Der ehemalige Multicast-Codepoint wechselte die Aufgabe

RFC 3032 führte zwei Data-Link-Codepoints ein, die als MPLS unicast und multicast beschrieben wurden. RFC 5332 hält fest, dass der Multicast-Gebrauch nie ausgerollt wurde und spätere Verfahren eine andere Trennung verlangten. Die alte Bedeutung wurde verworfen.

Auf einem Multicast-Ethernet-Frame wird 0x8847 verwendet, wenn das Top-Label downstream-assigned ist. 0x8848 wird verwendet, wenn es upstream-assigned ist. Beide Werte können also Multicast MPLS transportieren.

Ob ein Label Multicast-Semantik besitzt, ergibt sich aus seiner NHLFE in einem bestimmten Kontext. Die NHLFE legt Replikation zu einer Menge von Next Hops fest; auch eine aktuell einelementige Menge kann diese Semantik tragen. Der EtherType beschreibt Zuweisungsprovenienz, nicht den vollständigen Forwarding-Plan.

Zuweisungsrichtung ist noch kein Label-Space

Bei downstream assignment erzeugt der Empfänger das Label-FEC-Binding und kündigt es dem Sender an. Bei upstream assignment erzeugt es der Sender oder ein Dritter. Upstream Labels müssen nicht aus demselben Label Space stammen.

RFC 5331 definiert die Kontextregeln. 0x8848 weist den Empfänger darauf hin, dass die Upstream-Interpretation gebraucht wird, liefert aber nicht automatisch Root-, Interface- oder Tunnelkontext. Ein korrekter Codepoint kann deshalb mit einem falschen Lookup kombiniert werden.

Der bereits veröffentlichte RFC-5331-Beitrag behandelt diesen Kontextmechanismus. Für RFC 5332 ist die Grenze wichtig: Der Encapsulation Receipt muss an den Context Receipt angeschlossen werden, darf ihn aber nicht ersetzen.

Jedes Medium trägt eine andere Menge an Beweisen

Ethernet kann auf einem Multicast Frame zwischen 0x8847 und 0x8848 unterscheiden. PPP verwendet beim Transport von MPLS immer Protocol 0x0281. Native IP Encapsulation verwendet immer Protocol Number oder Next Header 137, unabhängig von Multicast-Semantik.

GRE mit Unicast-IP-Ziel nutzt immer 0x8847. Bei Multicast-Ziel steht 0x8847 für downstream und 0x8848 für upstream. Ist durch ein externes Verfahren bekannt, dass der Multicast-Tunnel upstream verwenden muss, ist 0x8847 ein Fehler und das Paket muss verworfen werden.

Ein einheitliches Datenmodell muss diese Asymmetrie abbilden. Die Zuweisungsrichtung kann wire-observed, contract-derived, normative-defaulted oder unknown sein. Wer alle vier Zustände in einen Wert presst, verliert die Beweiskette.

Eine frische Capability kann trotzdem falsch gebunden sein

Zeitstempel allein löst das Problem nicht. Ein aktueller Scan von Router A sagt weiterhin nichts über Router B, wenn der Scan nicht die Beziehung geprüft hat. Ebenso kann ein Peer-Nachweis aktuell sein, aber für ein anderes Interface oder einen anderen Tunnel gelten.

Monitoring muss deshalb Schlüssel und Scope vergleichen: lokale Instanz, remote Identität, Adjazenz, Richtung, Encapsulation, Assignment Mode und Contract Epoch. Ein Peer-Austausch oder Interface-Move invalidiert Relation Evidence, selbst wenn beide Geräte einzeln unverändert wirken.

Das ist eine allgemeine Governance-Frage. Zentralisierung neigt dazu, Objektattribute leichter zu sammeln als Beziehungszustände. Dann wird das leicht verfügbare Attribut zur Autorität über die schwerer beobachtbare Beziehung.

Der MAC-Suffix ist ebenfalls eine lokale Wahl

Für Ethernet Multicast MPLS definiert RFC 5332 01-00-5e-8v-wx-yz. vwxyz darf null sein oder den Wert eines Labels aus dem Stack übernehmen. Bei mehreren Labels ist das zweite der Default, wobei Konfiguration ein anderes wählen darf; bei einem Label wird dieses verwendet.

Beide Verfahren müssen interoperieren. Ein LSR darf nicht alle Nullwerte filtern und nicht pauschal alle Nichtnullwerte abweisen. Der label-derived Suffix kann mehr LSP-spezifische Information sichtbar machen, doch die Nutzung des Filters bleibt außerhalb des RFC.

Damit ist der Suffix kein Peer-Support-Beweis. Er ist auch keine Receiver-ID. Er muss zusammen mit Derivation Policy, Stack und Filterentscheidung gespeichert werden, bevor eine Anomalie bewertet wird.

Security braucht den tatsächlichen Entscheider

Das RFC warnt, dass böswillige Änderung des Codepoints Verlust oder Fehlleitung verursachen kann. Es grenzt die Aussage sofort ein: Wird nur der Codepoint, nicht aber das Label geändert, ist der Effekt nicht vorhersehbar. Änderung der MAC DA kann die Zustellung an Dritte bewirken.

Eine inkonsistente Beobachtung beweist daher zunächst nur die Inkonsistenz. Für Intent braucht es Akteursbelege. Für Misrouting braucht es Lookup und Ausgang. Für Dritt-Empfang braucht es eine unabhängige Empfangsbeobachtung. Für Business Impact braucht es Servicezuordnung und Ergebnis.

Das gilt auch für MUST-discard im GRE-Fall. Die Norm schreibt die Receiver-Aktion vor; Telemetrie muss zeigen, ob diese Software sie ausführte und was danach geschah.

Semantic Versioning gehört in die Telemetrie

Die Nummern 0x8847 und 0x8848 blieben erhalten, aber die alte unicast/multicast-Erzählung wurde ersetzt. Parser müssen deshalb nicht nur eine Lookup-Tabelle, sondern eine semantische Version besitzen: Autoritätsdokument, Medienbedingung, Adressbedingung, alte Bedeutung, neue Bedeutung, Defaults und ungültige Kombinationen.

Rollouts sollten identische Captures vor und nach dem Parserwechsel auswerten. Jede Änderung an Alarmen, Filtern und Reports wird als Migration behandelt. Raw Frames bleiben verfügbar, damit spätere Korrekturen historische Daten neu interpretieren können.

Ohne diese Disziplin wird ein stabiler Codepoint zur Falle. Die Organisation glaubt, ihr Datenmodell sei stabil, obwohl sich die Proposition darunter geändert hat.

Wissen muss einen Eigentümer haben

Der Standards Owner verantwortet die Semantik. Der Network Owner verantwortet Assignment Contracts und Peer-Support. Telemetrie verantwortet Raw Evidence und Lookup-Entscheidungen. Security und Service Owner verantworten Anomalie beziehungsweise Auswirkung.

Diese Trennung schwächt Automation nicht. Sie gibt ihr überprüfbare Eingaben. Ein Automationsschritt darf auf upstream assignment reagieren, wenn er zeigen kann, woher das Wissen stammt, welcher Context gilt und welche Version entscheidet.

Der gemeinsame Standard bleibt minimal; lokale Wahl bleibt möglich; Running Code liefert Wirklichkeit. Was vermieden wird, ist die nachträgliche Behauptung, ein einzelnes installierbares Feature habe all diese Ebenen autorisiert.

Quellen