Zusammenfassung

  • RFC 9658 macht {MT-ID, IPA} zum Bestandteil des mLDP-Multipoint-FEC und unterscheidet damit Bäume nach Topologie und Berechnungsalgorithmus.
  • Eindeutige FECs und lokale Labels beweisen weder eine gemeinsame Algorithmusrevision noch korrekte Upstream-Auflösung, zulässige Downstream-Interfaces, installierte Replikation oder Empfang.
  • Ein belastbarer Nachweis verbindet Definition, Capability, FEC-Bytes, Root Lookup, Branch-Entscheidungen, Labels, Hardware, OAM und Receiver-Ergebnis.

Eindeutigkeit löst das Namensproblem

RFC 9658 erweitert Multipoint LDP für Multi-Topology Routing und Flexible Algorithm. MT-ID bezeichnet die Topologie, IPA den IGP Algorithm. Das Tupel wird Teil des FEC; gleiche Root-Adresse und gleicher Opaque Value sind bei anderem Tupel andere MP LSPs.

Das verhindert, dass zwei logisch verschiedene Trees als dasselbe Forwarding Object behandelt werden. Weil jeder FEC eindeutig ist, verlangt die Spezifikation keine separate Label Forwarding Table je Topologie. Jeder MP LSP erhält sein eigenes lokales Label.

Ein Label belegt jedoch nur einen installierten oder signalisierten Bezug auf das Objekt. Es sagt nicht, mit welcher Topology Database der Root aufgelöst wurde, welche Interfaces zugelassen wurden oder ob die Hardware repliziert. Identität ist die Voraussetzung für Korrelation, nicht deren Ergebnis.

Acht Bits tragen den Algorithmus

RFC 7307 definierte MT IP und MT IPv6 für Multi-Topology LDP. RFC 9658 nutzt acht Bits eines zuvor reservierten 16-Bit-Felds für IPA. Das verbleibende Reserved-Octet muss beim Senden null sein und beim Empfang ignoriert werden.

RFC 9350 beschreibt Flexible Algorithm als constraint-basierte Subtopologie. Das IANA-Register für IGP Parameters ordnet die Werte. Der Wert transportiert aber nicht die aktuelle Definition, Link Attributes oder deren Revision.

Darum gehören FEC-Bytes, Algorithmusdefinition, Topology Epoch, Empfangszeit und lokales Berechnungsergebnis zusammen. Zwei Router können dieselbe Zahl korrekt encodieren und trotzdem verschiedene Graphen berechnen.

Capability beweist Unterstützung, nicht Installation

MT Multipoint Capability hat im IANA-LDP-Register den Wert 0x0510. Sie kann beim Session-Aufbau oder nach erfolgreicher Dynamic-Announcement-Aushandlung gemäß RFC 5561 dynamisch gesendet werden. Das S-Bit kündigt an oder zieht zurück.

Nach erfolgreicher Aushandlung muss ein Speaker topology-scoped FECs und Forwarding Setup unterstützen. Das ist ein klarer Vertrag über Verfahren. Es ist kein Beleg für einen bestimmten Tree, ein Label oder einen ASIC-Eintrag.

Protokolliert werden Peer, Session Epoch, Build und Transition. Bei Withdrawal muss das System zeigen, was mit bestehendem State geschah. Capability und Label Lifetime dürfen nicht stillschweigend gleichgesetzt werden.

Upstream und Downstream brauchen denselben Scope

RFC 6388 liefert P2MP und MP2MP. Für die Upstream-Auswahl verlangt RFC 9658, den besten Pfad zur Root-Adresse in der signalisierten Subtopologie zu suchen. Erst dessen Next Hop bestimmt den LDP Peer.

Downstream ist nicht jedes Interface zum Nachbarn zulässig. Es muss Teil derselben {MT-ID, IPA}-Subtopologie sein. Physische Erreichbarkeit, LDP Adjacency und Policy Eligibility sind verschiedene Aussagen.

Der Receipt enthält Kandidaten, Membership, Zulassungsgrund, Local Label, Replication Entry und Hardware Commit. Gerade ein partieller Tree kann lange verborgen bleiben: Die Mehrheit der Receiver funktioniert, während ein ausgeschlossener oder fehlender Branch im Aggregate verschwindet.

Wildcard und End-of-LIB bleiben lokal

RFC 5918 definiert Typed Wildcard FEC. RFC 9658 versieht Multipoint-Wildcards mit MT IP/MT IPv6, IPA und MT-ID. Bulk-Operationen können damit auf eine Subtopologie begrenzt werden.

RFC 5919 definiert End-of-LIB. Über den scoped Wildcard kann ein Speaker Konvergenz je Subtopologie signalisieren. Der Marker schließt Label Distribution in einer Peer-Session, nicht die gesamte Datenebene.

Eine veraltete Algorithmusdefinition, ein abgewiesener Hardware Write oder ein später Receiver bleiben möglich. Ein Bericht muss Peer, Session, Scope und Revision nennen, bevor er das Wort „konvergiert“ verwendet.

Scoped Ping begrenzt auch das Urteil

RFC 6425 erweitert LSP Ping für Multipoint; RFC 8029 liefert MPLS Echo. RFC 9658 nutzt MT IP oder MT IPv6 und fügt das Tupel zur Root LSR Address hinzu.

Der Probe adressiert damit den richtigen FEC. Ein Erfolg gilt dennoch nur für den getesteten Branch und Zeitpunkt. Andere Leaves, dauerhafte Replikation, Application Acceptance und Kundenwirkung benötigen eigene Evidenz.

Tree-weite Aussagen brauchen Branch Inventory, Probe Coverage, Counter und Receiver Observation. Ein Fehler kann fehlender FEC, divergente Topologie, unzulässiges Interface, fehlendes Label, Hardware oder Data Plane sein. Der Scope hilft, diese Ursachen auseinanderzuhalten.

Service Identity ist noch kein Service Result

RFC 6514 trägt mLDP FECs im MVPN PMSI Tunnel Attribute. Bei RFC 9658 muss der Tunnel Identifier die MT-scoped Form verwenden. Service Route und Transport Tree können dadurch exakt korreliert werden.

Die Route kann aber früher existieren als die Branches. Man muss PMSI, FEC, Root Lookup, Labels, Replikation, Probes und Receiver verknüpfen. Erst die letzten Ebenen erlauben eine Delivery-Aussage.

RFC 5036 ist die LDP-Basis, RFC 5920 der MPLS Security Framework. Authentifizierung zeigt, welcher Peer sprach; sie aktualisiert nicht dessen Topologie und programmiert keine Hardware.

Heng Lus Minimum Initial Specification stützt ein kleines gemeinsames Vokabular aus Tupel, Revision, Peer, Interface, Label und Result. Reality Layers trennen Identität, Versprechen, State und Outcome. Running-Code-Primacy gibt installierter Replikation und beobachtetem Empfang das letzte Wort.

RFC 9658 sorgt dafür, dass zwei Labels für dieselbe Root nicht verwechselt werden. Führung muss zusätzlich beweisen, dass jedes Label seinen eigenen, korrekt berechneten und vollständig beobachteten Tree repräsentiert.

Sources