Zusammenfassung

  • RFC 3353 zeigte den Startzirkel eines verkehrsgetriebenen Multicast-LSP: Der neue Zweig wartete auf ein Paket, das ohne diesen Zweig auf Layer 2 nicht ankommen konnte.
  • Gemischte L2/L3-Weiterleitung oder ein vom Upstream-LSR angestoßener Labelaustausch überbrückten die Lücke; Paketbeobachtung, Routingzustand, Signalisierung, Replikation und Empfang blieben dennoch getrennte Belege.

Ein Multicast-Strom erreicht bereits einen Empfänger. Hinter einem zweiten Downstream-LSR tritt ein weiterer Empfänger bei. Um Labels nicht für stumme Gruppen zu binden, soll der zweite Zweig erst nach Ankunft echter Daten entstehen. Der nachgelagerte Router soll das erste Paket sehen und daraufhin die Bindung auslösen.

Auf Layer 2 kann er dieses Paket aber nur über einen vorhandenen LSP sehen. Der LSP wartet auf den Trigger, der Trigger auf den LSP. RFC 3353 nannte das ein Henne-Ei-Problem. Es ging nicht um Wortklauberei, sondern um die Frage, auf welcher Seite der fehlenden Verbindung Beobachtung und Handlungsbefugnis liegen.

Das Dokument erschien im August 2002 als Informational RFC. Es standardisierte kein einzelnes Multicast-MPLS-Protokoll und berichtete keine flächendeckende Einführung. Es ordnete die Probleme, die entstehen, wenn veränderliche IP-Multicast-Bäume auf Label-Switched Paths abgebildet werden. Ein Baum besitzt Verzweigungen, mehrere Ausgänge und Mitgliedschaftsdynamik; er ist nicht nur eine längere Unicast-Route.

Die Zustandsform bestimmte den Preis. Ein gemeinsamer Baum wurde als (*,G) geführt, ein quellenspezifischer als (S,G). Der gemeinsame Baum sparte Labels, verlangte aber Multipoint-to-Multipoint-Verhalten und Zusammenführung. Quellbäume reduzierten manche Merge-Probleme, vervielfachten jedoch den Zustand. Begrenzter Labelraum, fehlende Merge-Fähigkeit und TTL-Eigenschaften der darunterliegenden Technik veränderten die Rechnung zusätzlich.

Flood-and-Prune-Protokolle machten die Bäume volatil. Daten erzeugten Zustand, unerwünschte Zweige wurden abgeschnitten, Inaktivität ließ Einträge verschwinden. Eine L2-Abbildung jeder Änderung verursachte Signalisierungs- und Labelaufwand. Vorab eingerichtete LSPs belegten Ressourcen ohne Verkehr. Verkehrsgetriebene Einrichtung sparte im Leerlauf und bezahlte beim ersten Paket.

RFC 3353 unterschied drei Auslöser. Request-driven nutzte Join-, Prune- oder Reservierungsnachrichten. Topology-driven übernahm den Multicast-Baum aus der Routingtabelle, auch ohne Daten. Traffic-driven wartete auf tatsächliche Pakete. Jede Wahl verlagerte die Kosten: Protokollkopplung, ungenutzten Zustand oder Startlatenz und Beobachtungsbedarf.

Eine Lösung war Initiative von oben. Der Upstream-LSR, der den Strom bereits sah, konnte beim Downstream ein Label anfordern oder selbst ein upstream-assigned Label bekanntgeben. Beobachtung und Auslösung lagen damit vor der Lücke. Deshalb verknüpfte die Kombinationstabelle des RFC Triggerart und Verteilungsrichtung; sie waren keine unabhängigen Schalter.

Die zweite Lösung hieß mixed L2/L3 forwarding. Ein Knoten konnte bestehende Zweige auf Layer 2 schalten und den neuen Zweig vorübergehend auf Layer 3 routen. Das erste Paket erreichte sein Ziel über IP, lieferte den fehlenden Nachweis und ermöglichte anschließend Labelaustausch und Programmierung. Erst nach Prüfung wechselte der Zweig zu MPLS. Das Mischmodell war eine reversible Übergangsfläche.

Dabei musste Layer 3 die bereits von Layer 2 bedienten Ausgänge auslassen, sonst entstanden Duplikate. Ohne Mischweiterleitung konnte ein Downstream nicht durch Verkehr auslösen; der Upstream musste die Labelvergabe beginnen. Ein Konfigurationssystem, das diese Abhängigkeit nicht abbildet, kann einen zulässigen Einzelwertsatz zeigen, dessen Kombination nie startet.

Auch die Beweiskraft blieb gestuft. Ein gesehenes Paket belegt eine Ankunft an einem Messpunkt. Ein Cache Miss belegt einen fehlenden lokalen Eintrag. Eine MRT-Zeile belegt lokalen Kontrollzustand. Eine Labelnachricht belegt einen Signalisierungsschritt. Ein ASIC-Eintrag belegt lokale Programmierung. Kein einzelner Beleg beweist die Zustellung an alle Blätter.

Das Unix-Beispiel des Multicast Forwarding Cache zeigte eine weitere Grenze. Das erste Paket löste einen Cache Miss aus; der Multicast-Daemon lieferte die Route. Sobald Layer 2 den Strom übernahm, sah Layer 3 keine Pakete mehr. Ein nur auf L3-Zählern beruhender Inaktivitätstimer konnte aktiven Zustand löschen.

Der RFC schlug vor, die L3-Zähler aus L2-Messungen zu aktualisieren. Das war zweckmäßig, machte den Zähler aber zu einer Projektion. Er bedeutete nicht mehr ausschließlich „von dieser IP-Stufe weitergeleitet“, sondern enthielt Aktivität einer anderen Schicht. Herkunft, Messfenster, Reset-Epoche und Zuordnung zum Zweig wurden Teil des Belegs.

Bei PIM-SM konnten gemeinsamer und quellenspezifischer Zustand gleichzeitig bestehen. Während des Wechsels vom RP-Baum zum Quellbaum konnte derselbe Strom kurz über zwei Eingänge eintreffen. Layer 3 konnte anhand des (S,G)-Zustands die falsche Kopie verwerfen. Reines L2 musste Duplikate hinnehmen, zusätzliche Labels verwenden oder die Entscheidung wieder an L3 geben. Das Label ersetzte die Multicast-Semantik nicht.

Kapselung bildete eine noch härtere Grenze. Sender eines gemeinsamen Baums konnten Daten zum Wurzelknoten tunneln, der sie entkapselte. Beide Vorgänge waren L3-Verarbeitung. Ein ununterbrochener End-to-End-L2-LSP konnte diesen Interpretationspunkt nicht einfach überspringen. MPLS konnte den Tunnel oder andere Zweige tragen, aber die Schichtgrenze blieb real.

Piggy-backing von Labelbindungen auf Multicast-Nachrichten synchronisierte Route und Label und sparte gesonderte Nachrichten. Dafür musste jedes Multicast-Protokoll erweitert werden; manche Triggerkombinationen entfielen, und zuverlässiges LDP über TCP konnte durch periodischen Soft State ersetzt werden. Synchronität der Nachricht war noch keine Replikationsquittung.

Auf Multiaccess-Netzen brauchten mehrere Downstream-LSRs dasselbe Label. Sie konnten sämtliche Vergaben merken, Bereiche aufteilen oder einen Zuteiler wählen. Upstream-Vergabe nutzte den einzigen oberen Baumknoten, wurde aber durch Topologieänderungen berührt. Downstream-Vergabe bewahrte Labels eher über einen Upstream-Wechsel, musste jedoch mehrere Vorschläge auflösen. RFC 3353 ließ die Entscheidung bewusst offen.

Spätere Standards beschrieben den Baum genauer. RFC 4461 formulierte Anforderungen an Aufbau, Blattänderungen, Fehlermeldung und Skalierung von P2MP-TE-LSPs. RFC 4875 setzte sie mit RSVP-TE um: mehrere Source-to-Leaf-Sub-LSPs wurden an Branch-LSRs kombiniert. Entscheidend war die Trennung zwischen verzweigtem Signalisierungszustand und tatsächlicher Datenreplikation. Der Kontrollbaum blieb eine andere Realität als der Paketstrom.

RFC 5332 korrigierte zudem eine Erwartung aus der frühen Phase. Die in RFC 3032 vorgesehene getrennte Nutzung von Unicast- und Multicast-Codepoints war nie eingeführt worden; der zweite Codepoint erhielt eine neue Bedeutung für upstream-assigned Labels auf Multiaccess-Medien. RFC 6513 zeigte später für Multicast-VPNs weiterhin den Tausch zwischen Verteilungsbäumen und Ingress-Replikation über Unicast-Tunnel. Replikation ließ sich verlagern, nicht abschaffen.

Die bleibende Leistung von RFC 3353 liegt in der sichtbaren Reihenfolge. Vor dem markierten Zweig standen ein erstes Paket, ein vorläufiger L3-Weg oder eine Upstream-Entscheidung. Nach der Signalisierung folgten Programmierung, Replikation und Empfangskontrolle. Nur diese Kette erklärt, was das Netz wirklich getan hat.

Quellen