Zusammenfassung

  • RFC 3037 empfahl die Implementierung des Basis-LDP für Geräte, die MPLS entlang normaler, zielbasierter Routen weiterleiten; sie machte LDP weder für jedes MPLS-Gerät verpflichtend noch bewies sie, dass eine Instanz konfiguriert und in Betrieb war.
  • Das Dokument trennte Hop-by-Hop-Labelverteilung von explizit geroutetem Traffic Engineering und legte mehrere unabhängige Belege frei: Erkennung, TCP-Verbindung, Parametervereinbarung, betriebsbereite Sitzung, Binding-Austausch, gespeicherter Zustand, programmierte Weiterleitung und beobachteter Verkehr.

Das in RFC 3037 am leichtesten überlesene Wort ist kein Protokollname, sondern „empfohlen“. In einem kurzen Abschnitt zur Anforderungsstufe empfahl das Dokument, LDP auf Geräten zu implementieren, die MPLS über normale, vom zielbasierten Routing gewählte Pfade weiterleiten. Das war ein eingegrenztes technisches Urteil. Es war kein allgemeines Mandat, kein Implementierungszertifikat und kein Bericht aus einem laufenden Netz.

Die im Januar 2001 als Informational RFC veröffentlichte Schrift beantwortete eine Anwendbarkeitsfrage: Wo passte das Basis-LDP unter den möglichen Verfahren zur MPLS-Labelverteilung? Ihre Antwort zog eine Grenze um den gewöhnlichen Routingpfad. Sie genau zu lesen heißt, Protokolleignung nicht mit Betriebswirklichkeit zu verwechseln.

Im Geltungsbereich lag der normal geroutete Pfad

Für MPLS mussten benachbarte Label Switching Router die Bedeutung der zwischen und durch sie verwendeten Labels teilen. LDP stellte Verfahren bereit, mit denen ein LSR ein von ihm erzeugtes Binding bekanntgab. RFC 3037 beschrieb dies als Labelverteilung entlang von Pfaden, die bereits das zielbasierte Routing gewählt hatte — MPLS-Hop-by-Hop-Weiterleitung.

Diese Rolle konnte unterschiedliche Technik verbinden. LDP, eine IP-Routingebene und Software zur Programmierung von ATM- oder Frame-Relay-Cross-Connects konnten IP ohne Overlay oder technikspezifisches Adress- und Routingsystem durch Schaltnetze tragen. Ein eigenständiges LDP verlangte auch nicht an jedem Hop dasselbe, für Erweiterungen geeignete Routingprotokoll.

Jedes „konnte“ hatte jedoch ein begrenztes Objekt. Die Architektur konnte eine Abhängigkeit beseitigen; sie bewies nicht, dass Cross-Connect-Software auf einem bestimmten Switch existierte, jeder Hop eine Sitzung bildete oder der Pfad Verkehr trug. Anwendbarkeit zeigte, wie sich ein System zusammensetzen ließ. Sie berichtete nicht, dass es zusammengesetzt worden war.

Dieselbe Grenze trennte Basis-LDP vom Traffic Engineering. Explizit geroutete LSPs müssen nicht dem normalen Routingpfad folgen. RFC 3037 nannte CR-LDP- und RSVP-TE-Erweiterungen als mögliche Verfahren und hielt fest, dass damals kein Konsens über technische Überlegenheit bestand. Betreiber sollten nach Bedarf und Lage entscheiden. Der Erweiterungsrahmen machte zusätzliche Arbeit möglich; er machte eine Erweiterung nicht schon wegen der vorhandenen Schnittstelle zum Basisprotokoll.

Die Empfehlung galt einer Funktion, nicht jeder Box

Die Anforderung war präzise: Empfohlen wurde die Implementierung für Geräte, die MPLS entlang normaler, zielbasierter Pfade weiterleiteten. Die Bedingung zählt. Ein Gerät außerhalb dieser Funktion wurde ohne Basis-LDP nicht automatisch regelwidrig; eines mit LDP-Code wurde aufgrund der Empfehlung nicht automatisch betriebsbereit.

Implementierung ist nur ein Beleg. Software kann vorhanden und die Funktion abgeschaltet sein. Ein aktivierter Prozess kann keinen Peer entdecken. Erkennung kann ohne TCP-Verbindung enden, die Verbindung ohne erfolgreiche Aushandlung. Eine betriebsbereite Sitzung kann kein nützliches Binding austauschen. Ein Binding muss nie die Weiterleitungstabelle erreichen. Ein programmiertes Label kann ohne ein einziges Paket bleiben.

Der Standard konnte die erste Fähigkeit empfehlen, ohne einen späteren Zustand zu beobachten. Das ist keine Schwäche. So kann eine Empfehlung über Produkte und Betreiber hinweg gelten, ohne deren Laufzeit vorzutäuschen.

Eine Sitzung war eine Folge, keine einzelne grüne Lampe

RFC 3037 fasste den LDP-Kontrollpfad als geordnete Schritte zusammen. Discovery fand einen möglichen Peer. Der Sitzungsaufbau stellte eine TCP-Verbindung her. Beide Seiten handelten Parameter einschließlich der Verteilungsmethode aus. Erst nach Einigung wurde die Sitzung zur Labelverteilung betriebsbereit.

TCP lieferte Sitzungsnachrichten zuverlässig, sodass verteilte Labels und zugehöriger LSP-Zustand nicht periodisch aufgefrischt werden mussten. Die Zuverlässigkeit gehörte aber zum Bytestrom. Sie bewies weder, dass der Peer die beabsichtigte Bedeutung akzeptierte, noch dass das Binding dem Routing folgte, Hardware programmiert war oder ein Paket sein Ziel erreichte.

Der Verzicht auf periodische Auffrischung veränderte zudem die Beweislast. Dauerhafter Zustand war effizient, doch bei einem späteren Fehler ließ sich aus fehlender Wiederholung keine Aktualität ableiten. Sitzungskontinuität, Routingabhängigkeit, Binding-Lebenszyklus und Datennutzung brauchten eigene Zeitstempel.

Das Modemenü enthielt ein Ressourcenargument

LDP schrieb keine universelle Kombination vor. Bei Downstream Unsolicited kündigte ein LSR ein FEC-Label-Binding an, sobald er die FEC weiterleiten konnte; bei Downstream on Demand antwortete er auf eine Anfrage. Liberal Retention bewahrte auch gerade nicht benötigte Labels, Conservative Retention gab sie frei. Independent Control erlaubte eine Ankündigung nach eigenem Zustand; Ordered Control wartete auf ein Binding des nächsten FEC-Hops oder auf die Egress-Rolle.

RFC 3037 ordnete diese Optionen nach Knappheit. Bei knappen Labelwerten wie auf ATM- und Frame-Relay-Links waren Verteilung auf Anfrage, konservative Speicherung und geordnete Kontrolle passend. Bei reichlichen Labels konnten unaufgeforderte Verteilung, liberale Speicherung und unabhängige Kontrolle einen Next-Hop-Wechsel beschleunigen, weil brauchbare Labels bereits vorlagen.

„Passend“ war bedingt, nicht absolut. Das Protokoll erlaubte andere Kombinationen und Mischformen. Labels zu sparen kostete gespeicherte Alternativen; Alternativen zu halten kostete Zustand. Frühes Ankündigen verschob den Zeitpunkt einer Upstream-Aussage, Warten die Aufbauabhängigkeit. Das Dokument lieferte einen Entscheidungsraum, keinen Sieger für jedes Netz.

Eine vorgeschriebene Fähigkeit konnte ausgeschaltet bleiben

Die Schleifenerkennung machte den Unterschied zwischen Fähigkeit und Zustand ausdrücklich. LDP definierte einen Schutz für LSPs durch MPLS-Wolken ohne TTL. Ein konformer LSR musste ihn implementieren, doch der Betreiber durfte ihn konfigurativ deaktivieren.

Ein Gerät konnte daher zugleich Konformität und eine abgeschaltete Schleifenerkennung melden. Selbst die Aktivierung auf einem Gerät bewies keinen Schutz der gesamten Domäne. Die brauchbare Beweiskette bestand aus Implementierung, lokaler Konfiguration, Peer-Parametern, übertragenen Pfadvektor- oder Hop-Angaben, Routenzustand und beobachteter Weiterleitung.

Für Erweiterungen galt dieselbe Grenze. LDP regelte neue Nachrichten und TLVs, die Erkennung unbekannter Typen und Antworten bei fehlender Unterstützung. RFC 3037 warnte, nicht jede künftige Verbesserung könne rückwärtskompatibel sein. Ein sauberes Unknown-TLV-Verfahren machte Entwicklung sicherer; gemeinsame Unterstützung einer bestimmten Erweiterung bewies es nicht.

Skalierungsaussagen benannten Kosten, nicht Kapazitäten

Das Dokument erklärte, warum inkrementelle Verteilung skalieren konnte: Bindings brauchten keine periodische Auffrischung. Es nannte auch die Gegenkosten. Knappheitsmodi begrenzten die Labelvergabe. Liberale Speicherung vermied nach Next-Hop-Wechseln Neuverteilung. Die unterstützten TCP-Verbindungen begrenzten die Peerzahl. Pfadvektor-Schleifenerkennung verbrauchte Speicher, Rechenzeit und Kontrollverkehr.

Keine Aussage lieferte eine numerische Produktkapazität. Betreiber brauchten beobachtete Peerzahlen, Labelverbrauch, Speicher, CPU, Nachrichtenraten, Rekonvergenz und Weiterleitungsergebnisse. Eine Protokolleigenschaft zeigt, welche Zähler wichtig sein können; sie ist nicht der Zählerstand.

Auch die Sicherheit war eng begrenzt. Optionales TCP MD5 konnte das Einschleusen gefälschter Segmente in einen LDP-Strom erschweren. Es authentifizierte keine FEC als legitim, autorisierte keine Route, bewies kein Binding und schützte nicht die über den LSP getragene Anwendung.

Späterer Konsens schrieb den früheren Stand nicht um

RFC 3037 hielt einen Zeitpunkt fest, an dem CR-LDP und RSVP-TE mögliche Antworten für explizite LSPs waren und kein technischer Sieger feststand. RFC 3209, RFC 3212 und RFC 3213 spezifizierten die Zweige später genauer.

Im Februar 2003 dokumentierte RFC 3468 die spätere Entscheidung von Arbeitsgruppe und IESG, neue MPLS-Signalisierungsarbeit auf RSVP-TE zu konzentrieren und keine neue CR-LDP-Arbeit der Gruppe zu beginnen. Bestehende RFC-Status blieben ausdrücklich bestehen; Einzelbeiträge wurden nicht verboten. Das belegt eine spätere Arbeitsverteilung im Standardisierungsprozess. Es belegt weder eine Migration jedes Betreibers noch das Verschwinden jeder Implementierung oder einen Irrtum der Momentaufnahme von 2001.

Die historische Lehre ist eine Disziplin der Verben. Ein Standardisierungsgremium empfiehlt. Ein Hersteller implementiert. Ein Betreiber aktiviert. Peers entdecken, verbinden sich und einigen sich. Eine Kontrollebene verteilt. Hardware installiert. Pakete durchlaufen. RFC 3037 war beim ersten Verb klar. Für alle weiteren blieben Belege nötig.

Quellen

Lu Heng war weder Autor noch Unterstützer von RFC 3037 oder den verwandten Standards. Seine Essays werden hier als offengelegte analytische Perspektiven verwendet.