Zusammenfassung

  • Eine aktivierte PLI verarbeitet Join/Prune ohne vorheriges Hello des Absenders. Sie erhält dadurch keine gewöhnliche Nachbarerkennung, DR-Wahl oder Assert-Verarbeitung.
  • Der Vertreter, der eine Empfängeranforderung über die Grenze weiterleitet, und die Auswahl eines einzigen wirksamen Datenstroms sind getrennte Entscheidungen.
  • Attributausnahmen, Fehlerfolgen für die OIF und die Adressen und Rollen von TCP PORT brauchen ausdrückliche Bedingungen. Die RFC-Beispiele sind keine gemessenen Betriebsergebnisse.

Analyse

„Redundant“ ist an einer Multicast-Grenze keine hinreichende Funktionsbeschreibung. Zwei Router können dieselbe Empfängeranforderung kennen. Zwei andere können den dazugehörigen Datenstrom liefern. Wer den Join weitergeben darf und wer schließlich eine wirksame Kopie liefert, sind verschiedene Fragen. Eine erfolgreiche Wahl auf der ersten Seite beantwortet die zweite nicht.

Diese Anordnung ist ein gedankliches Entwurfsproblem, kein berichteter Ausfall. Sie macht die Veränderung in RFC 9739 sichtbar. Der im März 2025 auf dem Standardisierungspfad veröffentlichte Text definiert die PIM Light Interface, PLI, für Medien, auf denen eine vollständige PIM-Nachbarschaft nicht möglich oder nicht erwünscht ist. Eine solche Schnittstelle nimmt Multicast-Zustand ohne vorangehenden Hello-Austausch an. Die fehlenden Verfahren verschwinden jedoch nicht als Anforderungen an das Gesamtsystem.

DR und Assert lösen nicht dieselbe Aufgabe

Das BIER-Beispiel in RFC 9739 behält eine normale PIM-Adjazenz zwischen redundanten Grenzroutern innerhalb der PIM-Domäne bei. Dort muss die Wahl des Designated Router stattfinden. Nur der DR leitet den erhaltenen Join/Prune in den BIER-Tunnel weiter. Die PLI wählt keinen DR, weil sie keine Hello-Nachrichten austauscht. Eine Nachbarschaft über den Kern einzusparen heißt daher nicht, auch den Ort der lokalen Vertretungsentscheidung abzuschaffen.

Die normale PIM-Architektur besitzt daneben Assert. Abschnitt 4.6 von RFC 7761 behandelt damit doppelte Weiterleitung auf einem gemeinsam genutzten Medium und die Auswahl eines einzigen Weiterleiters. Ein Assert-Gewinner erfüllt eine andere Rolle als der DR.

PIM Light verarbeitet Assert nicht. RFC 9739 verlangt, Paketduplikate durch die Anwendung oder die Netzarchitektur zu vermeiden. Die PLI verspricht keine nachträgliche Entdeckung und Bereinigung doppelter Datenströme.

Im BIER-Beispiel kann die empfangsseitige Grenze anhand der Topologie geeignete Grenzrouter in Richtung Quelle erkennen und mit einer eindeutigen Regel einen auswählen, etwa über die kleinste oder größte IP-Adresse. Ein Ersatzalgorithmus bei Verlust des Gewählten liegt außerhalb der detaillierten Festlegung. Die Illustration ist weder eine universell vorgeschriebene Umschaltstrategie noch ein Nachweis für unterbrechungsfreien Verkehr.

Ein vorgeschlagener Abnahmetest würde den DR intakt lassen und den ausgewählten quellseitigen Grenzrouter ausfallen lassen, dann den umgekehrten Fall prüfen. Auch die Rückkehr verdient eine eigene Beobachtung. Eine eindeutige Regel beweist nicht, dass alte und neue Auswahl während der Wiederherstellung nie gleichzeitig wirksam werden. Solche Tests wurden für diesen Beitrag nicht durchgeführt; die Quellen liefern keine entsprechenden Ergebnisse eines bestimmten Betreibers.

Zustand ohne Nachbar bleibt an eine Eingangsgrenze gebunden

Der allgemeine PIM-SM-Fall ist anders. RFC 7761, Abschnitt 4.5, empfiehlt grundsätzlich, Join/Prune zu verwerfen, wenn noch kein Hello von der Quelladresse empfangen wurde. Eine begrenzte Ausnahme für ältere Punkt-zu-Punkt-Implementierungen soll nicht standardmäßig aktiviert sein.

PLI erlaubt dagegen ausdrücklich den unbekannten Router. Sie erzeugt Zustand in der Multicast-Routingtabelle, keine gewöhnliche Nachbardatenbank, aus der Fähigkeiten, Entdeckung oder Wahlergebnisse abgeleitet werden könnten. RFC 9739 verlangt, Join/Prune ohne bekannten Nachbarn zu verwerfen, sofern PLI auf der Eingangsschnittstelle nicht aktiviert ist.

Ein darunterliegender Mechanismus kann eine logische PLI automatisch aktivieren. Die autorisierte Beziehung, Kapselung und Schnittstelleninstanz müssen dennoch bestimmbar sein. Automatisierung macht nicht jede Schnittstelle zu einem erlaubten Eingang. Ein vorgeschlagener Vergleich mit denselben Nachrichten auf einer vorgesehenen PLI und einer Nicht-PLI würde diese Zulassungsgrenze prüfen, nicht eine allgemeine Nachbarbeziehung.

Auch der Protokollumfang ist präzise. Unterstützt werden Register (1), Register Stop (2), Join/Prune (3), Candidate RP Advertisement (8), Packed Null-Register (13.0), Packed Register-Stop (13.1) sowie künftige Typen mit einer Unicast-IP-Zieladresse. Andere Typen dürfen nicht verarbeitet werden. Das IANA-Register bestätigt die Nummern, aber keine Produkteigenschaften.

PIM Light ist deshalb nicht insgesamt ein reiner Join/Prune-Transport, nur weil das BIER-Beispiel diese Nachrichten nutzt. Der Geltungsbereich ist PIM-SM einschließlich PIM-SSM, nicht PIM-DM oder BIDIR-PIM. Sparse-Mode-Verfahren enthalten (*,G), (S,G) und (S,G,rpt). Ein SSM-Ergebnis darf nicht als Beleg für alle Zustände eines gemeinsamen Baums gelten.

Attributkenntnis wird zum gepflegten Vorwissen

RFC 5384 trennt das gemeinsame Join-Attributes-Format von der Bedeutung einzelner Attribute. Quelladressen mit Kodierungstyp 1 lesen zu können beweist nicht, jede darin transportierte Erweiterung zu verstehen. Schon die gewöhnliche Hello-Option kündigt die gemeinsame Hülle an, nicht sämtliche möglichen Bedeutungen.

PLI besitzt auch diese Ankündigung nicht. RFC 9739 empfiehlt daher, Join-Nachrichten ohne Attribute zu senden, außer die Konfiguration kennt die Verarbeitungsfähigkeit der Nachbarn oder ein RFC beziehungsweise Internet-Draft erlaubt das konkrete Szenario ausdrücklich.

Für die konfigurierte Ausnahme müssen Attribut, Gegenstellen und bekannte Fähigkeit feststehen. Für die dokumentierte Ausnahme müssen Text und Bedingungen feststehen. „Unterstützt PIM-Erweiterungen“ ist kein ausreichend enges Ersatzwissen. Wirkt ein Attribut auf den Baumaufbau, muss das Verständnis den erforderlichen kooperierenden Bereich abdecken.

Beim Austausch eines Routers kann der normale Join weiterhin angenommen werden, während die Grundlage der Ausnahme nicht mehr stimmt. Kein Hello fehlt unerwartet; sein Fehlen ist hier vorgesehen. Ein automatischer Verhandlungsalarm lässt sich daraus nicht ableiten. Das ist eine Folgerung für das Änderungsmanagement, kein in den Quellen dokumentierter Zwischenfall.

Der Detektor muss eine bestimmte OIF verändern

RFC 9739 beschreibt PLI-Ausfälle, die unentdeckt bleiben können und keinen Prune in Richtung Quelle auslösen. Verkehr kann bis zum Ablauf des Ausgangsschnittstellenzustands, OIF, fortgesetzt werden. Die möglichen Gegenmaßnahmen sind implementierungsabhängig.

BFD ist ein Beispiel, keine Pflichtschutzschicht jeder PIM-Light-Implementierung. Fällt die BFD-Sitzung zur entfernten PLI aus und enthält die OIF-Liste eines (S,G) auf dem quellseitigen Router diese PLI, muss PIM sie aus der Liste entfernen. Bei einer automatisch eingerichteten BIER-Schnittstelle kann verlorene Erreichbarkeit der empfangsseitigen Grenze einen (S,G)-Prune zur Quelle ermöglichen.

Die entscheidende Verbindung führt vom beobachteten Objekt über die Benachrichtigung zur ungültigen Zustandsreferenz. Gerät, Pfad und Sitzung sind nicht zwangsläufig dasselbe Beobachtungsziel. Ein Alarm ohne wirksame Benachrichtigung an PIM beweist keine Entfernung aus der OIF-Liste.

Für eine vorgeschlagene Abnahme sind Geräteverlust, Pfadverlust und unterbrochene Benachrichtigung getrennte Fälle. Zu beobachten ist die Zustandsaktion, nicht allein eine Statusanzeige des Detektors. Die Quellen schreiben weder eine allgemeine numerische Ablaufzeit noch eine gemessene Wiederherstellung vor. Verbindliche Zeiten benötigen Belege der konkreten Implementierung und Konfiguration.

PORT benötigt eigene Vereinbarungen

RFC 6559 ist ein experimenteller Text von 2012. PORT transportiert darin Join/Prune über TCP oder SCTP zur Zielportnummer 8471. Gewöhnliches PORT kündigt Fähigkeit und Connection ID mit Hello an. Die ID ist eine IPv4- oder IPv6-Adresse für den Verbindungsaufbau, kein undurchsichtiger QUIC-artiger Bezeichner, Identitätsnachweis oder DR-Wahlverfahren.

Der übliche TCP-Aufbau vergleicht Adressen, um aktive und passive Öffnung zu bestimmen; für bedarfsgesteuerte Verbindungen gibt es Ausnahmen. SCTP kann gleichzeitige Öffnungen auflösen. Weil PLI kein Hello liefert, erlaubt RFC 9739 die Konfiguration der Connection ID. Bei TCP PORT müssen die aktive und passive Rolle ausdrücklich und korrekt an beiden Enden eingestellt sein.

Aufbau, Erhaltung und Wiederherstellung sind getrennt. RFC 6559 erläutert, dass eine unbenutzte TCP-Verbindung den Verlust des Gegenübers nicht unbedingt rasch erkennt. Keep-Alive und Ablaufmechanismen kommen hinzu, ohne einen allgemeinen Standard-Holdtime zu erzwingen. Nach Wiederverbindung ist der vollständige relevante Join/Prune-Zustand erneut zu senden. Bei Verbindungsverlust beginnt der Ablauf des zugehörigen OIF-Zustands, falls er nicht aufgefrischt wird. Die Unterbrechung erlaubt keinen automatischen Rückfall auf native Join/Prune-Datagramme.

Eine offene TCP-Verbindung belegt folglich weder die Erkennung eines stillen Ausfalls noch vollständige Neusynchronisierung oder PLI-Entfernung. Selbst korrektes PORT trifft nicht die Wahl des nächsten Datenlieferanten.

Keine Betriebsgarantie aus einem Architekturbeispiel

RFC 9739 empfiehlt eine Richtlinie für erwünschte (S,G)-Zustände und verlangt, die übrigen zu verwerfen. Das begrenzt angenommenen Zustand, authentifiziert aber keinen Sender. Für Nachrichtenschutz verweist der Text auf IPsec ESP und optional AH in RFC 5796. RFC 4607 unterscheidet ebenfalls die Auswahl einer SSM-Quelle von starker Authentifizierung.

RFC 8279 erklärt, warum BIER im Zwischenkern Zustand je Datenfluss und traditionellen Baumaufbau vermeidet. Das beseitigt nicht den PIM-Zustand an den Rändern. Die am 13. September 2026 geprüfte offizielle Seite zum BIER-PIM-Dokument zeigt Revision 13 vom 3. März 2025 als abgelaufenen Entwurf. Ihre Erwähnung in RFC 9739 ist kein Beleg für einen weiteren fertigen Standard oder eine heutige Produktionseinführung.

Eine Erhebung zur Verbreitung, gemessene Ausfälle und Kostenvorteile enthält dieses Quellenpaket nicht. Die belastbare Aussage ist enger: PIM Light lässt Zustand ohne Hello über eine Grenze gelangen. Die Architektur muss die dort fehlenden Entscheidungen weiterhin an bestimmbaren Stellen treffen.

Quellen

Das Bild ist eine KI-generierte redaktionelle Metapher, kein verifizierter Netzplan und keine Aufzeichnung eines realen Einsatzes.