1. LDP-Überblick

Die MPLS-Architektur [RFC3031] definiert ein Labelverteilungsprotokoll als eine Reihe von Verfahren, durch die ein Label-Switching-Router (LSR) einen anderen über die Bedeutung der Labels informiert, die zur Weiterleitung des Verkehrs zwischen ihnen und durch sie hindurch verwendet werden.

Die MPLS-Architektur geht nicht von einem einzigen Labelverteilungsprotokoll aus. Tatsächlich werden mehrere verschiedene Labelverteilungsprotokolle standardisiert. Bestehende Protokolle wurden erweitert, so dass die Labelverteilung auf ihnen mitgeführt werden kann. Es wurden auch neue Protokolle speziell zu dem ausdrücklichen Zweck definiert, Labels zu verteilen. Die MPLS-Architektur erörtert einige der Überlegungen bei der Wahl eines Labelverteilungsprotokolls für die Verwendung in bestimmten MPLS-Anwendungen wie Traffic Engineering [RFC2702].

Das Label-Verteilungsprotokoll (Label Distribution Protocol, LDP) ist ein Protokoll, das zum Verteilen von Labels definiert wurde. Es wurde ursprünglich im Januar 2001 als RFC 3036 veröffentlicht. Es wurde von der MPLS-Arbeitsgruppe der IETF erarbeitet und gemeinsam von Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette und Bob Thomas verfasst.

LDP ist ein Protokoll, das zum Verteilen von Labels definiert wurde. Es ist die Menge von Verfahren und Nachrichten, mit denen Label-Switching-Router (LSRs) Label-Switched-Paths (LSPs) durch ein Netz aufbauen, indem sie Routing-Informationen der Netzwerkschicht direkt auf vermittelte Pfade der Datenschicht abbilden. Diese LSPs können einen Endpunkt an einem direkt angeschlossenen Nachbarn haben (vergleichbar mit der IP-Hop-by-Hop-Weiterleitung) oder einen Endpunkt an einem Netzausgangsknoten haben, was die Vermittlung über alle Zwischenknoten hinweg ermöglicht.

LDP ordnet jeder von ihm erstellten LSP eine Forwarding-Equivalence-Class (FEC) [RFC3031] zu. Die einer LSP zugeordnete FEC legt fest, welche Pakete auf diese LSP "abgebildet" werden. LSPs werden durch ein Netz erweitert, indem jeder LSR eingehende Labels für eine FEC mit dem ausgehenden Label "verschweißt" (splices), das dem nächsten Hop für die gegebene FEC zugewiesen ist.

Weitere Informationen zur Anwendbarkeit von LDP finden sich in [RFC3037].

Dieses Dokument setzt Vertrautheit mit der MPLS-Architektur [RFC3031] voraus (erfordert sie aber nicht). Beachten Sie, dass [RFC3031] ein Glossar der MPLS-Terminologie enthält, wie etwa Ingress, Label-Switched-Path usw.

1.1. LDP-Peers

Zwei LSRs, die LDP verwenden, um Label/FEC-Abbildungsinformationen auszutauschen, werden in Bezug auf diese Informationen als "LDP-Peers" (LDP Peers) bezeichnet, und man spricht von einer zwischen ihnen bestehenden "LDP-Sitzung" (LDP Session). Eine einzelne LDP-Sitzung ermöglicht es jedem Peer, die Label-Abbildungen des anderen zu erlernen; d. h. das Protokoll ist bidirektional.

1.2. LDP-Nachrichtenaustausch

Es gibt vier Kategorien von LDP-Nachrichten:

1. Discovery-Nachrichten (Discovery messages), mit denen das Vorhandensein eines LSR in einem Netz angekündigt und aufrechterhalten wird.

2. Sitzungsnachrichten (Session messages), mit denen Sitzungen zwischen LDP-Peers aufgebaut, aufrechterhalten und beendet werden.

3. Advertisement-Nachrichten (Advertisement messages), mit denen Label-Abbildungen für FECs erstellt, geändert und gelöscht werden.

4. Notification-Nachrichten (Notification messages), mit denen Hinweisinformationen bereitgestellt und Fehlerinformationen signalisiert werden.

Discovery-Nachrichten bieten einen Mechanismus, durch den LSRs ihr Vorhandensein in einem Netz anzeigen, indem sie periodisch eine Hello-Nachricht senden. Diese wird als UDP-Paket an den LDP-Port an der Gruppen-Multicast-Adresse 'all routers on this subnet' gesendet. Wenn ein LSR beschließt, eine Sitzung mit einem anderen, über die Hello-Nachricht erfahrenen LSR aufzubauen, verwendet es das LDP-Initialisierungsverfahren über TCP-Transport. Nach erfolgreichem Abschluss des Initialisierungsverfahrens sind die beiden LSRs LDP-Peers und können Advertisement-Nachrichten austauschen.

Wann ein Label angefordert oder einem Peer eine Label-Abbildung angekündigt wird, ist weitgehend eine lokale Entscheidung, die von einem LSR getroffen wird. Im Allgemeinen fordert der LSR eine Label-Abbildung von einem benachbarten LSR an, wenn er eine benötigt, und kündigt einem benachbarten LSR eine Label-Abbildung an, wenn er möchte, dass der Nachbar ein Label verwendet.

Der korrekte Betrieb von LDP erfordert eine zuverlässige und reihenfolgetreue Zustellung von Nachrichten. Um diese Anforderungen zu erfüllen, verwendet LDP den TCP-Transport für Session-, Advertisement- und Notification-Nachrichten, d. h. für alles außer dem UDP-basierten Discovery-Mechanismus.

1.3. LDP-Nachrichtenstruktur

Alle LDP-Nachrichten haben eine gemeinsame Struktur, die ein Type-Length-Value-(TLV-)Kodierungsschema verwendet; siehe den Abschnitt "Type-Length-Value Encoding". Der Value-Teil eines TLV-kodierten Objekts, kurz TLV, kann selbst ein oder mehrere TLVs enthalten.

1.4. LDP-Fehlerbehandlung

LDP-Fehler und andere interessante Ereignisse werden einem LDP-Peer durch Notification-Nachrichten signalisiert.

Es gibt zwei Arten von LDP-Notification-Nachrichten:

1. Error Notifications, die zum Signalisieren schwerwiegender Fehler verwendet werden. Wenn ein LSR von einem Peer eine Error Notification für eine LDP-Sitzung empfängt, beendet es die LDP-Sitzung, indem es die TCP-Transportverbindung für die Sitzung schließt und alle über die Sitzung erlernten Label-Abbildungen verwirft.

2. Advisory Notifications, die verwendet werden, um einem LSR Informationen über die LDP-Sitzung oder den Status einer zuvor vom Peer empfangenen Nachricht weiterzugeben.

1.5. LDP-Erweiterbarkeit und zukünftige Kompatibilität

Die Funktionalität von LDP kann künftig erweitert werden. Es ist wahrscheinlich, dass zukünftige Funktionalität neue Nachrichten und Objekttypen (TLVs) nutzen wird. Es kann wünschenswert sein, solche neuen Nachrichten und TLVs in einem Netz zusammen mit älteren Implementierungen einzusetzen, die sie nicht erkennen. Obwohl es nicht möglich ist, jede zukünftige Erweiterung abwärtskompatibel zu machen, kann eine gewisse Vorausplanung die Einführung neuer Fähigkeiten erleichtern. Diese Spezifikation definiert zu diesem Zweck Regeln für die Behandlung unbekannter Nachrichtentypen und unbekannter TLVs.

1.6. Spezifikationssprache

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in [RFC2119] beschrieben.