6. Bereiche für zukünftige Studien

Die folgenden Themen, die in dieser Version von LDP nicht behandelt werden, sind mögliche Bereiche für zukünftige Studien:

Abschnitt 2.16 der MPLS-Architektur [RFC3031] fordert, dass die anfängliche Aushandlung des Labelverteilungsprotokolls zwischen Peer-LSRs es jedem LSR ermöglicht, festzustellen, ob sein Peer in der Lage ist, den Label-Stack zu entfernen (pop). Diese Version von LDP geht davon aus, dass LSRs das Label-Popping für alle Verbindungstypen außer ATM und Frame Relay unterstützen. Eine zukünftige Version könnte Mittel angeben, um diese Feststellung zu einem Teil der Sitzungsinitiierungsverhandlung zu machen.
Die LDP-Unterstützung für CoS (Class of Service) ist in dieser Version nicht spezifiziert. Die CoS-Unterstützung könnte in einer zukünftigen Version behandelt werden.
Die LDP-Unterstützung für Multicast ist in dieser Version nicht spezifiziert. Die Multicast-Unterstützung könnte in einer zukünftigen Version behandelt werden.
Die LDP-Unterstützung für Multipath-Label-Switching ist in dieser Version nicht spezifiziert. Die Multipath-Unterstützung könnte in einer zukünftigen Version behandelt werden.
Die LDP-Unterstützung für die Signalisierung der maximalen Übertragungseinheit (maximum transmission unit) ist in dieser Version nicht spezifiziert. Sie wird im experimentellen Dokument [LDP-MTU] erörtert.
Die aktuelle Spezifikation behandelt nicht die grundlegende Peer-Discovery auf Non-Broadcast Multi-Access-(NBMA-)Medien. Die in der aktuellen Spezifikation verfügbare Lösung besteht darin, in solchen Konfigurationen die erweiterte Peer-Discovery zu verwenden. Die Frage der Definition eines Mechanismus, der semantisch der Basic Discovery ähnelt (1-Hop-Grenze, Bindung der Hello-Adjazenz an eine Schnittstelle) und vorkonfigurierte Nachbaradressen verwendet, bleibt weiteren Studien überlassen.
Die aktuelle Spezifikation unterstützt nicht das Herunterfahren einer Adjazenz. Die Motivation dafür und die Mechanismen zu seiner Erreichung bleiben weiteren Studien überlassen.
Die aktuelle Spezifikation enthält keine Methode zur Absicherung von Hello-Nachrichten, um Spoofing von Hellos zu erkennen. Die Szenarien, in denen dies notwendig ist, sowie der Mechanismus zu seiner Erreichung bleiben zukünftigen Studien überlassen.
Die aktuelle Spezifikation ist nicht in der Lage, einen zustandslosen schnellen Neustart der Steuerungsebene (stateless fast control plane restart) zu erkennen. Die Methode zu dessen Erreichung, möglicherweise über eine im Hello mitgeführte "Inkarnations-/Instanznummer" (incarnation/instance number), bleibt zukünftigen Studien überlassen.
Die aktuelle Spezifikation unterstützt keine "End of LIB"-Nachricht, analog zur "end of RIB"-Nachricht von BGP, die ein LDP-LSR (im DU-Modus arbeitend) nach dem Sitzungsaufbau verwenden würde. Die Erörterung des Bedarfs an einem solchen Mechanismus und seiner Implementierung bleibt zukünftigen Studien überlassen.
Die aktuelle Spezifikation befasst sich nicht mit Situationen, in denen verschiedene LSRs dieselbe Adresse ankündigen. Solche Situationen treten typischerweise als Ergebnis von Konfigurationsfehlern auf, und das Ziel ist in diesem Fall, den LSRs, die dieselbe Adresse ankündigen, genügend Informationen bereitzustellen, damit Betreiber Korrekturmaßnahmen ergreifen können. Die Spezifikation dieses Mechanismus bleibt einem separaten Dokument überlassen.