Zusammenfassung

  • Upstream Label Assignment ist optional und darf erst verwendet werden, wenn die Unterstützung des Downstream-LSR bekannt ist. Wie dieses Wissen entsteht, liegt außerhalb RFC 5331.
  • Selbst bei beiderseitiger Capability muss der Empfänger den richtigen Kontext erhalten; bei MPLS-Tunneln darf PHP die root-identifizierenden äußeren Labels nicht entfernen.

Capability ist eine Eigenschaft, Wissen eine Beziehung

Ein lokaler Softwaretest kann zeigen, dass der Knoten Upstream-Labels erzeugt oder verarbeitet. Er sagt nichts darüber, ob der konkrete Peer, Tunnel und Anwendungsfall denselben Modus akzeptieren.

RFC 5331 macht die Funktion optional und verbietet Nutzung ohne bekanntes Downstream-Support. Das Verfahren zum Erlangen dieses Wissens überlässt es Anwendung und Label-Distribution. Die Lücke ist kein Freibrief für Annahmen, sondern eine externe Beweispflicht.

Ein Capability-Receipt braucht Peer, Root, Anwendung, Tunnel, Quelle, Zeitpunkt und Ablauf. Ein früheres Signal darf nicht unbegrenzt alle späteren Tunnel autorisieren. Ein lokaler Registry-Eintrag ist kein Remote-Receipt.

Auch die Wahl zwischen upstream und downstream assignment gehört zur Anwendung. Zwischen zwei benachbarten LSRs darf für dieselbe Beziehung nicht beides zugleich als bindende Richtung gelten.

Der richtige Modus braucht noch die richtige Tabelle

Upstream-assigned Labels werden immer in einem context-specific label space gesucht. Derselbe Zahlenwert kann in der Platform-Tabelle oder in einer anderen Root-Tabelle eine andere FEC bezeichnen.

Der Beleg supports=true sagt deshalb nicht, welche Tabelle ausgewählt wurde. Lookup muss Root, Mechanismus, Ingress, Table-ID, Generation, Label und FEC ausgeben.

Dies unterscheidet die Arbeit vom RFC-9573-Artikel über gemeinsamen Service-Sinn. RFC 5331 behandelt den früheren Schritt: Welcher Root- und Tunnelkontext wählt überhaupt die Tabelle für das innere Label?

PHP kann trotz beiderseitiger Unterstützung scheitern

Bei MPLS-Tunneln liefern die äußeren Labels die Tunnelidentität. Entfernt der vorletzte Hop das letzte äußere Label, kann der Egress das Upstream-Label erkennen und dennoch seinen Kontext verlieren.

RFC 5331 verlangt in diesem Fall deaktiviertes PHP. Capability beider Seiten repariert keinen verschwundenen Selector. Fallback auf per-platform semantics kann eine gültige, aber falsche FEC treffen.

Bewahren Sie den Stack vor und nach Pop, die PHP-Policy, die Root-Zuordnung und das Ergebnis der Tabellenwahl auf.

Root und Assigner müssen dieselbe Adresse nennen

Der Downstream hält einen Raum pro eindeutiger head-end IP. Verschiedene Adressen desselben Routers bedeuten getrennte Räume. Tunnel-Setup und Label-Distribution müssen Root und Assigner mit derselben IP benennen.

CMDB-Aliase dürfen diese Protokollidentität nicht vorzeitig vereinheitlichen. Zwei valide Control-Plane-Meldungen können beim Join widersprechen.

Für GRE ohne Signalisierung wird die Source-IP zur Root. Das erklärt Lookup, nicht Authentisierung oder organisatorische Berechtigung.

LAN-Scope entscheidet über Kollision

EtherType zeigt Upstream Assignment, nicht den konkreten Nachbarn. Ein Context Label über dem Service-Label und die Eingangs-LAN-Schnittstelle wählen den Nachbarraum.

Context Labels müssen auf demselben LAN eindeutig sein. Gleiche Werte auf unterschiedlichen Interfaces sind erlaubt. Das IPv4-basierte Verfahren setzt eindeutige niedrige 20 Bits voraus; eine Kollision auf demselben LAN kann Fehlleitung verursachen.

Ein globaler Duplicate-Check erzeugt falsche Alarme, wenn er das Interface verliert, und verpasst reale Probleme, wenn er den LAN-Teilnehmerkreis nicht kennt.

Quellen und Evidenzgrenze

Die Quellen belegen Regeln, Historie und Register, nicht aktuelle Implementierung, Tunnel, PHP, Root, Tabelle, Kollision, Fehlleitung, Multicast, Forwarding oder Delivery.