Signaling Protocols in MPLS Networks

By Walter J. Goralski, Cathy Gadecki, Michael Bushong

If you are managing a Junos based MPLS network, you need to be aware of two primary types of MPLS signaling protocols, both of which the Junos OS supports:

  • Label Distribution Protocol (LDP): LDP is a fairly simple signaling protocol that behaves much like one of the IGPs (OSPF and IS-IS). LDP runs on top of an IGP configuration, which means you have to get OSPF or IS-IS running first. Moreover, you must configure LDP on the exact set of interfaces as your IGP.

    After you configure both your IGP and LDP on an interface, LDP begins transmitting and receiving LDP messages on that interface. LDP starts off by sending LDP discovery messages to all the LDP-enabled interfaces. When an adjacent router receives the discovery message, it establishes a TCP session with the source router.

    When the LDP session is established, the routers maintain adjacencies much in the same way that OSPF routers maintain adjacencies. When the topology changes, those changes generate LDP messages that allow LDP to set up new paths.

    LDP is fantastic in that it’s so simple and just works. However, because of its simplicity, it lacks some of the more powerful traffic engineering features that RSVP boasts. For this reason, the major application for LDP-signaled LSPs is in support of Layer 3 VPNs. Suffice it to say that LDP lacks any real traffic engineering capabilities.

  • *Resource Reservation Protocol (RSVP): RSVP is a bit more complex than LDP and offers traffic engineering features that aren’t available with LDP-signaled LSPs.

    RSVP works by setting up unidirectional paths between an LSP ingress router and an egress router. In the configuration, you specify what the bandwidth requirements are for an LSP. After you configure these paths and enable RSVP, the ingress router sends a path message to the egress router. The path message contains the configured information about the resources required for the LSP to be established.

    When the egress router receives the path message, it sends a reservation message back to the ingress router in response. This reservation message is passed from router to router along the same path as the original path message (in opposite order, of course). Once the ingress router receives this reservation message, an RSVP path is established that meets the required constraints.

    All the LSRs along the path receive the same path and reservation messages, which contain the bandwidth reservation requirements. If they have the available bandwidth (that is, if no other higher-priority RSVP LSP has reserved bandwidth), they’re included in the LSP.

    If a router doesn’t have available bandwidth, it generates its own reservation message, and a new route that doesn’t include the offending router is found. If no route can be found, the LSP isn’t established.

    The established LSP stays active as long as the RSVP session stays active. RSVP maintains activity through the continued transmission and response to RSVP path and reservation messages. If the messages stop for three minutes, the RSVP session terminates, and the LSP is lost.