label mappings are of little practical value. So, you are left with a requirement for a label distribution protocol.

7.3 TAG DISTRIBUTION PROTOCOL (TDP)

One of the original, proprietary pre-MPLS protocols was developed by Cisco and was called tag switching. TDP is Cisco’s protocol for the distribution of ‘tags’ used in its tag switching system. It works on a hop-by-hop basis. The tag switched paths produced by TDP follow the shortest path as selected by the IGP. Tag switching is supported on Cisco’s routers in frame and cell mode and on Cisco’s ATM switches in cell mode only.

Unless you have only Cisco LSRs, then TDP is not a practical solution. Even if you do have only Cisco LSRs today, it is not really wise to use TDP because it constrains you if you subsequently wish to use another vendor’s hardware. Cisco routers can run TDP on one interface of a router and LDP (see below) on another, providing a conversion interface between the two protocols.

7.4 LABEL DISTRIBUTION PROTOCOL (LDP)

LDP is a protocol similar to, but incompatible with, TDP. It also works on a hop-by-hop basis producing LSPs, which follow the shortest path from ingress to egress as selected by the IGP. It was designed by the MPLS working group of the IETF. LDP is widely supported by router vendors. It is also supported on ATM LSRs providing the means for integrating signalling of LSPs from end to end across both frame and cell-based networks.

If you have no traffic engineering requirements, it is generally simpler to implement LDP than RSVP-TE (see below). An LSR running LDP discovers its neighbours and automatically distributes a label for each address for which it has received a label. Cisco routers by default also create a label for every attached interface. Juniper routers only produce a label for the loopback interfaces. Since labels are not created for the links to your eBGP neighbours, you must set next-hop-self on iBGP sessions or the next hop will not be accessible. If you have a combination of Cisco and Juniper routers as PE, then it is advisable to decide which model you will use and ensure that you use it consistently. Under these circumstances, my advice would be to limit the Cisco PE to advertising only the loopback address (see Table 7.1).

Table 7.1 IOS configuration to constrain LDP advertisements to loopback0 only

mpls ip

mpls ldp advertise-labels for 1

!

interface loopback0

ip address 192.168.255.1 255.255.255.255 mpls ip

!

access-list 1 permit 192.168.255.1 0.0.0.0 access-list 1 deny any

7.4.1LDP GRACEFUL RESTART

As with several of the routing protocols described in Chapter 5, it is desirable to be able to support graceful restart for LDP sessions. Graceful Restart for LDP is described in RFC 3478.

If the LDP control plane in an LSR restarts, it is preferable not to have to tear down all the LSPs traversing that LSR, recalculate a shortest path and resignal the new LSPs avoiding the restarting LSR then, upon recovery of the LSR, be left with non-optimal LSPs until an optimization of the LSPs is carried out. Instead, in cases where the forwarding plane can be maintained across the temporary failure of the control plane, it is better simply to continue forwarding traffic using exactly the same mappings of incoming label, incoming interface, outgoing label, outgoing interface/next-hop.

Adjacent LSRs signal their ability to maintain their MPLS forwarding state derived from LDP by setting the fault tolerant (FT) TLV during the initial exchanges of the LDP protocol. This FT TLV contains two items, a Reconnect Timeout and a Recovery Time.

The Reconnect Timeout is the time in milliseconds within which the restarting router can restart its control plane and establish an LDP session to the receiving router such that LDP information can be exchanged. The receiving router should maintain the MPLS forwarding state for the period specified in the Reconnect Timeout. If the Reconnect Timeout specified by the restarting router is zero, it indicates that the restarting router cannot maintain its MPLS forwarding state across the control plane restart. This sounds rather strange, but it indicates that this router is capable of responding correctly if a neighbour can maintain its forwarding state across the restart.

If the restarting router can maintain its forwarding state, it sets a configurable timer and marks all its forwarding entries as stale. As it receives updates following the restart, the restarting router replaces stale entries with updated entries. When this timer expires, any remaining stale entries are purged.

Similarly, when the receiving router notices that the LDP session with its neighbour has been lost, it checks whether that neighbour is capable of maintaining its state across the restart. If so, the receiving router would mark the state learned from the restarting router as stale and start a timer, the value of which is the lower of the Reconnect Timeout from the FT TLV exchanged at the time of initialization and a configurable local timer called the Neighbour Liveness Timer. When the timer expires, any remaining stale state is purged.

7.5RSVP WITH TRAFFIC ENGINEERING EXTENSIONS (RSVP-TE)

RSVP is a protocol that was designed for an entirely different purpose—the reservation of resources across a network for a single flow between a source host and destination host. It was chosen as a candidate for a label distribution protocol because it has the ability to define specific paths across the network and associate resources with those paths. This was particularly attractive as it provides a mechanism for traffic engineering of labelled