Quick Notes: Label Distribution Protocol (LDP)

• All LSRs must run a label distribution protocol and exchange label bindings.
• All directly connecdted LSRs must establish an LDP peer relationship (LDP session) between them.
• The label bindings received from neighbor routers, locally assigned, or statically configured label bindings are stored in label information base (LIB). 
• The label forwarding information base (LFIB), which is the table that forwards labeled packets, is fed by the LIB.
• LDP has four major functions:
• the discovery of LSRs that are running LDP
• session establishment and maintenance
• advertising of label mappings
• housekeeping by means of notification
• Two LSRs discover each other by means of Hello messages and then establish a session across a TCP connection.
• LSRs send LDP Hello messages on all links that are LDP enabled. 
• LDP is automatically enabled with the mpls ip command.
• LDP Hello messages are UDP messages that are sent to the "all routers" multicast IP address 224.0.0.2. The UDP port for LDP is 646.
• The LDP Hello message contains a Hold time, and if no Hello message is received within that time, the LDP neighbor is removed.
• By default, the Hello interval is 5 seconds and the Hold time is 15 seconds.
• If the two LDP peers have different LDP Hold times configured, the smaller of the two values is used as the Hold time.
• Cisco IOS might overwrite the configured LDP Hello interval. It will choose a smaller LDP Hello interval than configured so that it can send at least three LDP Hellos before the Hold time expires. (At least nine Hellos are sent in the case of a targeted LDP session.)
• LSRs have an LDP Identifier, or LDP ID. This LDP ID is a 6-byte field that consists of 4 bytes identifying the LSR uniquely and 2 bytes identifying the label space that the LSR is using (per-platform or per-interface).
• The first 4 bytes of the LDP ID are an IP address taken from an operational interface on the router. If Loopback interfaces exist, the highest IP address of the Loopback interfaces is taken for the LDP ID or LDP router ID. If no Loopback interfaces exist, the highest IP address of an interface is taken. The LDP router ID can also be configured manually (mpls ldp router-id interface [force]).
• In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed.
• When two LSRs have discovered each other by means of the LDP Hellos, they attempt to establish an LDP session between them. 
• One LSR tries to open a TCP (646) connection to the other LSR.
• Once the TCP connection is set up, both LSRs negotiate LDP session parameters, which include:
• timer values
• label distribution method
• VPI/VCI ranges for LC-ATM
• DLCI ranges for LC-Frame Relay
• If the peers don't agree on the parameters, they retry to create the LDP session between them, but at a throttled rate.
• After the LDP session has been set up, it is maintained by either the receipt of LDP packets or a periodic keepalive message.
• Usually the IP addresses used to create the LDP session are the LDP router Identifiers on each router. However, if you do not want to use this IP address to create the LDP session, you can change it (mpls ldp discovery transport-address {interface | ip address}).
• When a router has multiple links toward another LDP router, the same transport address must be advertised on all the parallel links that use the same label space.
• Normally one LDP session between a pair of LSRs is enough but with per-interface label space one LDP session must exist per interface.
• The advantage of show mpls ip binding vs. show mpls ldp bindings is that it also shows which label from all possible remote bindings is used to forward traffic by indicating in use. In use indicates the outgoing label in the LFIB for that prefix.
• Note that LDP assigns local labels to all IGP prefixes and advertises the bindings to all LDP peers.
• The concept of split horizon does not exist; an LDP peer assigns its own local label to a prefix and advertises that back to the other LDP peer.

Targeted LDP Session

• This is an LDP session between LSRs that are not directly connected.
• For example, AToM networks and TE tunnels in an MPLS VPN need targeted LDP sessions.
• For directly connected neighbors, you only need to enable mpls ip on the interface; the LDP peers discover each other and create the LDP TCP session between them.
• For LDP neighbors that are not directly connected, the LDP neighborship needs to be configured manually on both the routers with the mpls ldp neighbor targeted command.

LDP Authentication

• LDP can use Message Digest 5 (MD5) authentication.
• MD5 adds a signature—called the MD5 digest—to the TCP segments. The MD5 digest is calculated for the particular TCP segment using the configured password on both ends of the connection and the MD5 digest is checked for every segment received from the TCP connection.
• The configured MD5 password is never transmitted.
• To enable authentication, issue the mpls ldp neighbor command with the password keyword.

LDP Autoconfiguration

• The MPLS LDP Autoconfiguration feature enables you to globally enable LDP on every interface associated with an IGP instance. 
• This feature is supported on OSPF and IS-IS IGPs. 
• The goal of the MPLS LDP Autoconfiguration feature is to make configuration easier, faster, and error free.
• You issue the mpls ldp autoconfig command to enable LDP on each interface that is running an OSPF or IS-IS process. 
• If you do not want some of the interfaces to have LDP enabled, you can issue the no mpls ldp igp autoconfig command on those interfaces.

MPLS LDP-IGP Synchronization

• Packet loss due to LDP and IGP not being synchronized can occur in the following situations:
• When an IGP adjaceny is established, the router begins forwarding packets before the LDP label exchange completes.
• If the LDP session closes, the router continues to forward traffic using that link.
• At the point where LDP is broken, the packets become unlabeled. The packets are forwarded as IPv4 packets until they become labeled again on the next LSR.
• With MPLS VPN, AToM, Virtual Private LAN Switching (VPLS), or IPv6 over MPLS, the packets must not become unlabeled in the MPLS network. If they do become unlabeled, the LSR does not know how to forward the packets anymore and drop them.
• In the case of MPLS VPN, the packets are IPv4 packets, but they should be forwarded according to a VRF routing table. This table is private for one customer and is present only on the edge LSRs or PE routers. Therefore, when the MPLS VPN packets become unlabeled on the core LSRs—the P routers—they are dropped.
• The same problem can occur when LSRs restart. The IGP can be quicker in establishing the adjacencies than LDP can establish its sessions. This means that the IGP forwarding is already happening before the LFIB has the necessary information to start the correct label forwarding. The packets are incorrectly forwarded (unlabeled) or dropped until the LDP session is established.
• The solution is MPLS LDP-IGP Synchronization. This  feature ensures that LDP is fully established before the IGP path is used for switching.
• This feature is only supported on interfaces running OSPF or IS-IS.
• This feature works when LDP is enabled on interfaces with either mpls ip or mpls ldp autoconfig command. 
• MPLS LDP-IGP Synchronization is enabled for the IGP process. This means that it is configured for an IGP, and it applies to all the interfaces on which the IGP is running. The command to enable it for the IGP is mpls ldp sync, configured under the router process. 
• When the MPLS LDP-IGP synchronization is active for an interface, the IGP announces that link with maximum metric until the synchronization is achieved, or until the LDP session is running across that interface.
• After the LDP session is established and label bindings have been exchanged, the IGP advertises the link with its normal IGP metric.
• Basically, OSPF does not form an adjacency across a link if the LDP session is not established first across that link. (OSPF does not send out Hellos on the link.)
• Until the LDP session is established or until the synchronization Holddown timer has expired, the OSPF adjacency is not established. Synchronized here means that the local label bindings have been sent over the LDP session to the LDP peer.

MPLS LDP Session Protection

• A common problem in networks is flapping links.
• Because the IGP adjacency and the LDP session are running across the link, they go down when the link goes down.
• The impact is pretty severe though, because the routing protocol and LDP can take time to rebuild the neighborship. LDP has to rebuild the LDP session and must exchange the label bindings again.
• When the LDP session between two directly connected LSRs is protected, a targeted LDP session is built between the two LSRs.
• When the directly connected link does go down between the two LSRs, the targeted LDP session is kept up as long as an alternative path exists between the two LSRs.
• The global command to enable LDP Session Protection is this: mpls ldp session protection [vrf vpn-name] [for acl] [duration seconds]
• The access list (acl) you can configure lets you specify the LDP peers that should be protected. It should hold the LDP Router Identifier of the LDP neighbors that need protection. 
• The duration is the time that the protection (the targeted LDP session) should remain in place after the LDP link adjacency has gone down. The default value is infinite.
• For the protection to work, you need to enable it on both the LSRs. If this is not possible, you can enable it on one LSR, and the other LSR can accept the targeted LDP Hellos by configuring the command mpls ldp discovery targeted-hello accept.

References

MPLS Fundamentals