Skip to main content

6. Areas for Future Study

The following topics not addressed in this version of LDP are possible areas for future study:

  • Section 2.16 of the MPLS architecture [RFC3031] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation.

  • LDP support for CoS (Class of Service) is not specified in this version. CoS support may be addressed in a future version.

  • LDP support for multicast is not specified in this version. Multicast support may be addressed in a future version.

  • LDP support for multipath label switching is not specified in this version. Multipath support may be addressed in a future version.

  • LDP support for signaling the maximum transmission unit is not specified in this version. It is discussed in the experimental document [LDP-MTU].

  • The current specification does not address basic peer discovery on Non-Broadcast Multi-Access (NBMA) media. The solution available in the current specification is to use extended peer

    discovery in such setups. The issue of defining a mechanism semantically similar to Basic Discovery (1 hop limit, bind the hello adjacency to an interface) that uses preconfigured neighbor addresses is left for further study.

  • The current specification does not support shutting down an adjacency. The motivation for doing it and the mechanisms for achieving it are left for further study.

  • The current specification does not include a method for securing Hello messages, to detect spoofing of Hellos. The scenarios where this is necessary, as well as the mechanism for achieving it are left for future study.

  • The current specification does not have the ability to detect a stateless fast control plane restart. The method for achieving this, possibly through an "incarnation/instance" number carried in the Hello message, is left for future study.

  • The current specification does not support an "end of LIB" message, analogous to BGP's "end of RIB" message that an LDP LSR (operating in DU mode) would use following session establishment. The discussion on the need for such a mechanism and its implementation is left for future study.

  • The current specification does not deal with situations where different LSRs advertise the same address. Such situations typically occur as the result of configuration errors, and the goal in this case is to provide the LSRs advertising the same address with enough information to enable operators to take corrective action. The specification of this mechanism is left for a separate document.