6. Domaines d'étude future

Les sujets suivants, non traités dans cette version de LDP, constituent des domaines possibles d'étude future :

La section 2.16 de l'architecture MPLS [RFC3031] exige que la négociation initiale du protocole de distribution d'étiquettes entre LSR pairs permette à chaque LSR de déterminer si son pair est capable de dépiler la pile d'étiquettes. Cette version de LDP suppose que les LSR prennent en charge le dépilage d'étiquettes pour tous les types de liaisons, à l'exception d'ATM et de Frame Relay. Une version future pourra spécifier des moyens de faire de cette détermination une partie de la négociation d'initiation de session.
La prise en charge de la CoS (Class of Service) par LDP n'est pas spécifiée dans cette version. La prise en charge de la CoS pourra être traitée dans une version future.
La prise en charge du multicast par LDP n'est pas spécifiée dans cette version. La prise en charge du multicast pourra être traitée dans une version future.
La prise en charge de la commutation d'étiquettes à chemins multiples (multipath label switching) par LDP n'est pas spécifiée dans cette version. La prise en charge des chemins multiples pourra être traitée dans une version future.
La prise en charge de la signalisation de l'unité de transmission maximale par LDP n'est pas spécifiée dans cette version. Elle est examinée dans le document expérimental [LDP-MTU].
La spécification actuelle ne traite pas de la découverte de pairs de base sur des supports non diffusés à accès multiple (Non-Broadcast Multi-Access, NBMA). La solution disponible dans la spécification actuelle consiste à utiliser la découverte étendue de pairs dans de tels agencements. La question de définir un mécanisme sémantiquement similaire à la Basic Discovery (limite de 1 saut, liaison de la hello adjacency à une interface) qui utilise des adresses de voisins préconfigurées est laissée à un examen ultérieur.
La spécification actuelle ne prend pas en charge l'arrêt d'une adjacence. La motivation pour le faire et les mécanismes permettant d'y parvenir sont laissés à un examen ultérieur.
La spécification actuelle n'inclut pas de méthode pour sécuriser les messages Hello, afin de détecter l'usurpation des Hellos. Les scénarios où cela est nécessaire, ainsi que le mécanisme permettant d'y parvenir, sont laissés à une étude future.
La spécification actuelle n'a pas la capacité de détecter un redémarrage rapide du plan de contrôle sans état. La méthode pour y parvenir, éventuellement au moyen d'un numéro "incarnation/instance" transporté dans le message Hello, est laissée à une étude future.
La spécification actuelle ne prend pas en charge un message "end of LIB", analogue au message "end of RIB" de BGP qu'un LSR LDP (fonctionnant en mode DU) utiliserait après l'établissement de la session. La discussion sur la nécessité d'un tel mécanisme et sur sa mise en œuvre est laissée à une étude future.
La spécification actuelle ne traite pas des situations où différents LSR annoncent la même adresse. De telles situations se produisent généralement à la suite d'erreurs de configuration, et l'objectif dans ce cas est de fournir aux LSR qui annoncent la même adresse suffisamment d'informations pour permettre aux opérateurs de prendre des mesures correctives. La spécification de ce mécanisme est laissée à un document séparé.