Zusammenfassung
- Der PIM-Entwurf vom 6. September bündelt Topologie, Algorithmus und Dataplane in einem TAD, damit Multicast-Bäume Constraint-Pfade statt nur den normalen kürzesten Pfad nutzen. Revision 01 aktualisiert gegenüber 00 lediglich Daten und Referenzen.
- TAD ist ein Vertrag des gesamten Baums: Alle Router müssen am selben TAD teilnehmen, die Zahlen dürfen ihre IGP-Domäne nicht verlassen, und widersprüchliche Joins können PIM oder die Weiterleitung am First-Hop stoppen.
- An einer Capability-Grenze geht die Pfadabsicht verloren. Unterstützt ein Nachbar das neue GSI nicht, wird auf GSH zurückgestuft; dabei verschwinden alle Sub-TLVs und damit TAD.
Für einen Multicast-Stream kann der kürzeste Pfad der falsche sein. Ein längerer Pfad bietet vielleicht die nötige Bandbreite oder vermeidet eine unerwünschte Ressource. Flex-Algorithm kann ihn berechnen. PIM muss anschließend sicherstellen, dass alle beteiligten Router denselben Rückweg aufbauen.
Der aktuelle Entwurf Multi-Topology in PIM beschreibt diese Kopplung. Revision 01 ist ein aktives PIM-WG-Dokument mit angestrebtem Standards Track, aber Status I-D Exists. Sie ist weder RFC noch Einsatznachweis. Der Vergleich von Revision 01 und Revision 00 zeigt nur aktualisierte Daten, Ablaufzeit und Referenzstände.
Das Tupel bestimmt die Routingtabelle
Nach RFC 7761 laufen PIM-Joins Hop für Hop zur Quelle oder zum RP und erzeugen Baumzustand; Daten laufen in Gegenrichtung. TAD ergänzt Topology, Algorithm und Dataplane.
Topology wählt eine IGP-Sicht. Algorithm kann die Constraint-Berechnung aus RFC 9350 benennen. Dataplane unterscheidet Segment Routing, IP Flex nach RFC 9502 oder eine vorgeschlagene Soft-Dataplane. Zusammen bestimmen sie, welche MRIB den Upstream-Nachbarn liefert.
Der FHR kündigt Source, Group und TAD-Sub-TLV über PFM an. Der LHR übernimmt die Ankündigung oder nutzt lokale Policy und setzt TAD in Join/Prune. Zwischenrouter schlagen in der passenden Tabelle nach. Deshalb fordert der Entwurf denselben TAD für jeden Router eines Baums.
Ein Parser-Erfolg beweist nichts über das Ergebnis. Dieselben Definitionen müssen installiert sein, der Upstream muss erreichbar sein, der TIB-Zustand muss in die MFIB gelangen, und Empfänger müssen Pakete ohne unerwarteten Verlust oder Duplikate sehen.
Dieselbe Zahl verliert an der Domänengrenze ihre Eindeutigkeit
Der Entwurf verbietet PIM-Nachrichten mit lokalem TAD außerhalb der IGP-Domäne. MT-IDs sind protokollspezifisch. OSPF nach RFC 4915 und IS-IS nach RFC 5120 teilen nicht automatisch dasselbe betriebliche Wörterbuch.
Die Domäne ist damit eine Autoritätsgrenze. Gültige Bytes haben nur dort Bedeutung, wo Definitionen und Konfiguration geteilt werden.
Auch intern bleibt lokale Auswahl. Zwei FHRs mit verschiedenen TADs für dieselbe Source/Group werden nach Originator-Adresse geordnet, standardmäßig gewinnt die höhere. Widerspricht die LHR-Konfiguration seiner Ankündigung, darf es keinen TAD-Join senden. Treffen TAD und RPF Vector zusammen, entscheidet lokale Policy, welcher ignoriert wird. Bei mehreren TAD-Attributen wird das erste empfohlen.
Jede einzelne Regel kann korrekt laufen, während zwei Geräte verschiedene Regeln wählen. Lokale Konformität schafft noch keinen gemeinsamen Baum.
Fail-closed braucht erklärende Telemetrie
Erhält ein Router für denselben Zustand Joins mit verschiedenen TADs oder findet keinen erreichbaren Upstream, soll er PIM stoppen und den Administrator informieren. Der FHR soll nicht weiterleiten, bis alle Joins denselben TAD tragen.
Das verhindert einen stillen Fehlbaum, konzentriert aber den Ausfall: Ein Zweig kann bereite Empfänger mit blockieren. Ein Alarm muss Rohwerte, Nachbarn, Capability, Policy und letzten Forwarding-Zustand enthalten. „PIM stopped“ vernichtet die Ursache.
Die Security Considerations nennen Schleifen und fehlendes Forwarding bei unterschiedlichen lokalen Topologie-/Algorithmuswahlen. Auch ein gefälschter Router kann falsche TAD-Informationen ankündigen. Das neue Feld ist daher ein privilegierter Eingang, kein Herkunftsnachweis.
Rückwärtskompatibilität entfernt die Auswahl
Die Source-Ankündigung nutzt GSI aus PIM Flooding Mechanism and Source Discovery Enhancements, einem Experimental-Dokument in der RFC-Editor-Queue. GSI-Fähigkeit wird pro Interface in PIM Hello signalisiert.
Unterstützen alle Nachbarn GSI, wird es unverändert weitergegeben. Fehlt die Fähigkeit bei einem Nachbarn, konvertiert der Router in GSH aus RFC 8364. Source, Group und Holdtime bleiben; Sub-TLVs werden verworfen. TAD verschwindet.
Das Netz kann die Quelle weiter entdecken und für klassisches PIM gesund aussehen, obwohl die Constraint-Auswahl nicht mehr durchgängig ist. Eine Endpunktprüfung reicht deshalb nicht.
Heng Lus Reality Layers trennen Dokument, Konfiguration, Ankündigung, TIB, MFIB und Paketresultat. Running-Code Primacy verlangt den beobachteten Empfang als letzte Instanz.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
