Label Distribution Protocol

Standardized in RFC 3036, "LDP Specification," LDP exchanges labels for IGP and static routes. As mentioned earlier, Cisco's implementation of MPLS traffic engineering is not based on CR-LDP, which is an extension of LDP protocol for constrained based routing. However, understanding LDP is useful even in an MPLS TE network; often, MPLS-enabled networks run a mix of LDP and RSVP in different places.

Because this book is not really about LDP, and because RFC 3036 is more than 130 pages long, an exhaustive discussion of LDP is out of the scope of this chapter (and book). However, the following sections present enough details for you to understand the basics of LDP, as well as some of the packet format details. When you finish reading this section, you will know how to configure LDP, what it's used for, and some of how the protocol works.

LDP PDU Header

Before diving into the four major LDP functions, it is useful to understand the basic packet format behind LDP. LDP is carried in either UDP or TCP. Either way, an LDP packet always starts with a Protocol Data Unit (PDU) header, as illustrated in Figure 2-13.

The LDP PDU header is comprised of the following fields:

• Version— Currently, the only version of LDP defined is 1.

• PDU Length— The length of the PDU, including any data carried in the packet after the PDU header.

• LDP Identifier— An LDP identifier is a six-octet string used to identify a particular label space. The first four octets of this LDP identifier are the LSR-ID. The value of the next two octets depends on the label space. If this LDP PDU pertains to global label space, these two octets are both 0. If this LDP PDU is per-interface label space, these two octets are a unique number assigned by the originator of the LDP PDU. By convention, this LDP identifier is written as RouterID:space identifier. So, global label space advertisements from a router with an LSR-ID of 1.2.3.4 are written as 1.2.3.4:0; per-interface label space is written as 1.2.3.4:1 or some other nonzero number.

LDP Message Format

The LDP PDU header is followed by one or more LDP messages, the general format of which is shown in Figure 2-14.

The Unknown (U) bit is set to 1 if the message type is Unknown. No messages defined in the LDP specification have a type of Unknown, so this bit is always 0.

Table 2-5 shows the possible values for the Message Type field.

Table 2-5. Message Types

Message Name	Message Number
Notification	0x0001
Hello	0x0100
Initialization	0x0200
Keepalive	0x0201
Address	0x0300
Address Withdraw	0x0301
Label Mapping	0x0400
Label Request	0x0401
Label Release	0x0403
Label Withdraw	0x0402
Label Abort Request	0x0404

The Message Length is the length of a set of fields after the message length (Message ID + Mandatory Parameters + Optional Parameters), in bytes.

The Message ID is sometimes used to associate some messages with others. For example, a message sent in response to another message uses the Message ID of the message to which it's responding.

The Mandatory Parameters and Optional Parameters depend on the types of message sent. They are covered in the upcoming sections about different LDP functions. The Mandatory and Optional Parameters are often TLV (Type/Length/Value) triplets, a common way of encoding arbitrary amounts of data in a packet.

When a TLV is used inside an LDP message, the generic format looks like Figure 2-15.

The U bit, if set to 1, means the receiving router should ignore it if it understands this message.

The Forward (F) bit is relevant only if the U bit is set to 1. Because these bits are always 0 in the messages defined in RFC 3036, we will not go into any more detail on them.

The Type field indicates the type of data carried in the Value portion of the TLV.

The Length field indicates the length of the data carried in the Value portion of the TLV. The actual values in the Type, Length, and Value fields depends on the Message Type and what exactly LDP is trying to accomplish with a particular message.

LDP's Major Functions

LDP has four major functions:

• Neighbor discovery

• Session establishment and maintenance

• Label advertisement

• Notification

Neighbor Discovery

Like most other network protocols, LDP has the concept of neighbors. LDP uses UDP/TCP ports 646 for discovery. LDP has two different types of neighbors:

• Directly connected neighbors— These neighbors have a Layer 2 connection between them. So, routers that are connected by any Layer 2 link—whether a POS link, an ATM PVC, an Ethernet connection, or a DS-3 interface—are considered directly connected for LDP. Neighbors connected by a logical connection such as GRE tunnel are also considered directly connected. The basic commonality over such connections is the fact that a neighbor is one IP hop away.

• Non-directly connected neighbors— These neighbors do not have a Layer 2 connection between them. More importantly, these neighbors are several IP hops away. Routers that are connected to each other by MPLS traffic engineering tunnels and that have LDP enabled on them are considered non-directly connected. Such an LDP session is called a targeted or directed LDP session.

The only difference between directly and non-directly connected neighbors is in how they discover each other. LSRs discover directly connected neighbors by sending LDP hello messages encapsulated in UDP to the 224.0.0.2 multicast address (all routers on a subnet). These packets are known as hello messages.

Non-directly connected neighbors can't be reached through a multicast UDP packet. So, the same hello messages are sent as unicasts (also to UDP port 646). This requires that an LSR know ahead of time who it wants to have as a non-directly connected neighbor. This can be achieved through configuration.

Configuring directly connected neighbors is easy. All you need to do is enable tag-switching ip or mpls ip at the interface level. mpls label protocol ldp can be configured either on an interface, as demonstrated in Example 2-11, or at the global level, as shown in Example 2-12.

Example 2-11 Configuring Directly Connected Neighbors for LDP

interface POS3/0

 ip address 192.168.17.15 255.255.255.0

 mpls label protocol ldp

 tag-switching ip

end

tag-switching Versus mpls in the CLI As mentioned earlier, Cisco's TDP is the predecessor to LDP. Migrating the TDP CLI commands to support LDP while still maintaining backward compatibility is a nontrivial problem. You often see some commands that say tag-switching and others that say mpls. These commands are often functionally identical; tag-switching ip and mpls ip, for example, do the same thing. Which protocol you use is controlled by the command mpls label protocol {ldp | tdp}. The command-line interface (CLI) might well have changed between the time this book was written and now. For the most up-to-date details, check the LDP documentation. Some online links are provided in Appendix B.

The command mpls label protocol ldp is necessary because the label protocol on an interface defaults to TDP. However, the CLI was designed to be flexible. Instead of overriding the default of TDP on every interface, you can instead configure mpls label protocol ldp at a global level, and then the interface default becomes LDP. Example 2-12 shows mpls label protocol specified only at the global level, which results in all the interfaces using LDP instead of TDP.

Example 2-12 Configuring LDP for All Interfaces on the LSR

!

mpls label protocol ldp

...

!

interface POS3/0

 ip address 192.168.17.15 255.255.255.0

 mpls ip

end

You can use the command mpls label protocol tdp on a per-interface basis to configure TDP if you need those interfaces to be TDP instead of LDP.

Use show mpls interfaces to verify that you have the proper interface configuration, as demonstrated in Example 2-13.

Example 2-13 Verifying TDP/LDP Configuration on an Interface

vxr15#show mpls interfaces

Interface              IP            Tunnel   Operational

FastEthernet0/0        Yes (tdp)     No       Yes

POS3/0                 Yes (ldp)     Yes      Yes

You might notice that the IP column shows a Fast Ethernet interface that is configured to run TDP, whereas the POS interface is configured to run LDP. The Operational column should say Yes if the interface is up/up.

So, what do LDP hello packets look like?

After the PDU header, an LDP hello message is used. Its format is shown in Figure 2-16.

As Figure 2-16 shows, the hello message contains a Common Hello Parameters TLV. This TLV contains information about the type of LDP session that the LSR wants to establish. Figure 2-17 shows the Common Hello Parameters TLV format.

Hold Time is the hello holdtime in seconds. The default holdtime for directly connected sessions is 5 seconds. Hellos for directly connected sessions are sent every 5 seconds, whereas for targeted LDP neighbors, the holdtime is 180 seconds (hellos are still sent every 5 seconds). Hello messages are constantly being exchanged between a pair of LDP neighbors acting as link keepalives between the LDP neighbors.

The Targeted Hello (T) and Request Targeted Hello (R) bits are set to 1 when LSRs are forming non-directly connected LDP neighbors and are 0 otherwise.

The IPv4 Transport Address TLV is optional, but it is implemented in Cisco's implementa-tion of LDP. It is the IP address of the LSR initiating the LDP session over TCP. Generally, the transport address is the LSR ID of the transmitting router and it is most likely Loopback0.

All these packet formats might be confusing. Figure 2-18 shows you what an entire LDP packet looks like.

The LDP PDU Header is the Version, PDU Length, and LDP Identifier. The hello message starts immediately after the LDP Identifier. It consists of the Hello Type, Message Length, and Message ID. After the Message ID is the Common Hello Parameters TLV header, the Length of the Common Hello Parameters TLV, and other pieces of the Common Hello Parameters TLV.

Session Establishment and Maintenance

After discovering potential LDP neighbors, LDP session establishment can begin. LDP session establishment is a two-step procedure:

Active or passive roles are determined by comparing the transport address (almost always the LSR-ID of the transmitter, which is Loopback0) in the hello packet. If the receiver determines that he is the one who should be active, he initiates a TCP session. If not, he waits for the sender to initiate it.

As shown in Figure 2-19, R1 receives hello R2:0 on link L1. R1 compares its transport address, 1.1.1.1, to that of R2, 2.2.2.2. Because R2's transport address is greater numerically, R1 plays the passive role and waits for R2 to establish the TCP connection. The TCP connection is initiated to well-known TCP port 646.

After the TCP session is established, the LSRs negotiate the session parameters through LDP initialization messages. These include version, label distribution method (unsolicited downstream or DoD), timer values (the hold-down time for the TCP connection), VPI/VCI ranges for label-controlled ATM, and so on.

After it is established, the session is maintained by sending periodic UDP discovery hellos and keepalive messages within the TCP session.

Various LDP timers can be checked with the show mpls ldp parameters command, as demonstrated in Example 2-14.

Example 2-14 Checking LDP Timers

gsr1#show mpls ldp parameters

Protocol version: 1

Downstream label pool: min label: 16; max label: 100000

Session hold time: 180 sec; keep alive interval: 60 sec

Discovery hello: holdtime: 15 sec; interval: 5 sec

Discovery targeted hello: holdtime: 180 sec; interval: 5 sec

Downstream on Demand max hop count: 255

TDP for targeted sessions

LDP initial/maximum backoff: 15/120 sec

LDP loop detection: off

The holdtime and hello interval can be changed with the following global configuration knob:

mpls ldp discovery {hello | targeted-hello} {holdtime | interval} 1-2147483 seconds

Holding up an LDP session is dependent on receiving LDP keepalives on a regular basis. Changing the discovery holdtime changes the amount of time that can pass without a keepalive's being received from a neighbor. In other words, if the holdtime is increased, an LSR waits a little longer before declaring a neighbor down if it has not received keepalives from that neighbor.

The discovery interval is how often hellos are sent from a particular router. This value is not advertised in any LDP message; it is local to the receiver of the hellos.

As with so many other timers, don't change these unless you're sure you have a good reason to change them. However, there might be times when you know you have a congested link, and you want LDP to be more patient in receiving keepalives before declaring a neighbor down. Similarly, you might want LDP to detect neighbor failure faster, so you might want to turn the timers down, making them more sensitive to lost hellos. However, detecting failures is best left to the IGP or to link-specific alarm mechanisms.

As soon as an LDP neighbor comes up, you can view the neighbor relationship using the show mpls ldp neighbor command, as demonstrated in Example 2-15.

Example 2-15 Viewing LDP Neighbor Relationships

vxr15#show mpls ldp neighbor

    Peer LDP Ident: 192.168.1.8:0; Local LDP Ident 192.168.1.15:0

        TCP connection: 192.168.1.8.646 - 192.168.1.15.11056

        State: Oper; Msgs sent/rcvd: 41/39; Downstream

        Up time: 00:00:03

        Addresses bound to peer LDP Ident:

          192.168.1.8     192.168.13.8    192.168.3.8     192.168.17.8

          192.168.8.8

Example 2-15 shows an LDP neighbor relationship (because it says Peer LDP Ident) with neighbor 192.168.1.8. Output from show tag-switching tdp neighbor looks much the same, except it says Peer TDP Ident instead if the label protocol is TDP.

Figure 2-20 summarizes LDP session establishment. The number of sessions needed between LSRs depends on the label space. For frame-mode interfaces, even though there are multiple links between two LSRs, only one LDP session is established, because for frame-mode operation, a per-platform label space is used. When ATM interfaces are used, the LSR has to maintain a per-interface label space for each of them. RFC 3036 requires the use of one neighbor relationship per interface when using per-interface label space.

Case A in Figure 2-20 shows that four routers—R1, R2, R3, and R4—are connected by links L1 through L4. For each of the links, only one session needs to be established—assuming that these are frame-mode interfaces.

Case B shows multiple links between two routers, R1 and R2. Again, assuming frame-mode interfaces, only one LDP session is required.

Case C shows one ATM link between the two LSRs R1 and R2 doing cell mode. This calls for an additional session to be established.

What happens at the packet level? After deciding which LSR plays the active role in neighbor establishment, the active LSR sends an initialization message. Its format is illustrated in Figure 2-21.

The initialization message contains a Common Session Parameters TLV. Its format is shown in Figure 2-22.

The initialization message might also contain optional parameters. These are not covered in this book; see RFC 3036, Sections 3.5.3, for more details.

The fields in the Common Session Parameters TLV are as follows:

• Protocol Version— Version 1.

• Keepalive Time— The proposed time in seconds after which the LDP neighbor relationship is torn down.

• A— Set to 0 for Downstream Unsolicited mode and 1 for DoD.

• D— Set to 0 if loop detection is disabled and 1 if loop detection is enabled. Loop detection is used with LC-ATM LDP relationships.

• Reserved— Not used.

• PVLim— Path vector limit. Also used with LC-ATM.

• Max PDU Length— The largest allowable LDP PDU between two neighbors. The default is 4096.

• Receiver LDP Identifier— The LDP Identifier, advertised back to the receiver.

Initialization messages are exchanged between two neighbors to determine parameters to be used for a session.

After neighbors are established, keepalive messages are sent between neighbors. Figure 2-23 shows the format for LDP keepalive messages.

Keepalive messages are pretty straightforward. Optional parameters aren't covered here, and we've already defined the rest of the fields in the packet.

Keepalives are sent every 60 seconds by default; if a keepalive is not seen in 180 seconds, the LDP neighbor is torn down.

Hellos and Keepalives? You might have noticed that LDP has both hello messages and keepalive messages. Both are necessary. As mentioned earlier in this chapter, LDP forms only one neighbor relationship if there are multiple frame-mode links between two LSRs. Hello messages are sent on each link via UDP multicast and are used to ensure that an LSR knows which interfaces a neighbor is over. Keepalives are sent between established neighbors on a TCP connection, and which interface the keepalives come in on isn't tracked. Hello messages are per-link keepalives, whereas keepalive messages are per-neighbor keepalives. Although perhaps a bit confusing, the separation of per-link and per-neighbor maintenance messages helps LDP scale more effectively.

Label Advertisement

As soon as LSRs have established an LDP neighbor relationship, they begin to advertise labels to each other. Seven different LDP message types are involved in label advertisement:

• Address

• Address Withdraw

• Label Request

• Label Mapping

• Label Withdraw

• Label Release

• Label Abort Request

Address Message

An LSR sends Address messages to advertise the interface addresses to which it is bound. Address messages are not LDP label advertisement messages. Address messages are also a form of advertisement and hence included here. Figure 2-24 shows the Address message format.

The Address message is the glue that creates an association between a label space and a next-hop. Without it, the LSR doesn't know which LDP ID to listen to if it wants to send a packet to particular next-hop. Refer to Figure 2-7, in which LSRs 12008a and 12008b have two links between them. If the ATM 3/0 link goes down, the route to 12.12.12.12 on 12008a is over the POS 1/0 link, and the next hop is the address of the POS 1/1 interface of 12008b. Now, because of receiving the Address message, 12008a can associate the binding it has from 12008b to this new next hop.

The command show mpls ldp neighbor shows the address bindings received from the neighbor, as demonstrated in Example 2-16.

Example 2-16 Viewing Address Bindings Received from LDP Neighbors

12008a#show mpls ldp neighbors

Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 5.5.5.5:0

        TCP connection: 3.3.3.3.646 - 5.5.5.5.11004

        State: Oper; Msgs sent/rcvd: 28881/28887; Downstream

        Up time: 2w3d

        LDP discovery sources:

          POS2/0

        Addresses bound to peer LDP Ident:

          7.1.5.113       10.0.1.3        3.3.3.3         10.0.2.3

Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 5.5.5.5:0

        TCP connection: 4.4.4.4.646 - 5.5.5.5.11005

        State: Oper; Msgs sent/rcvd: 28894/28931; Downstream

        Up time: 2w3d

        LDP discovery sources:

          POS2/1

        Addresses bound to peer LDP Ident:

          7.1.5.110       10.0.1.4        4.4.4.4         10.0.3.4

Peer LDP Ident: 11.11.11.11:0; Local LDP Ident 5.5.5.5:0

        TCP connection: 11.11.11.11.11008 - 5.5.5.5.646

        State: Oper; Msgs sent/rcvd: 28904/28875; Downstream

        Up time: 2w3d

        LDP discovery sources:

          POS1/0

        Addresses bound to peer LDP Ident:

          10.0.19.11      10.0.17.11      10.0.4.11       7.1.5.100

          11.11.11.11     10.0.5.11

Peer LDP Ident: 11.11.11.11:1; Local LDP Ident 5.5.5.5:1

        TCP connection: 10.0.4.11.11009 - 10.0.4.5.646

        State: Oper; Msgs sent/rcvd: 5821/5821; Downstream on demand

        Up time: 3d12h

        LDP discovery sources:

          ATM3/0.1

The highlighted text in Example 2-16 shows the address bindings that 12008a received from its neighbor, whose LDP identifier is 11.11.11.11:0. The addresses listed under Addresses bound are those received by 12008a from the LSR 11.11.11.11:0 in the address-binding message. When it's time to install a label entry in the FIB/LFIB, 12008a consults the routing table. Only if a route's next-hop address is listed in the address bindings sent by a next-hop router does 12008a consider using the label bindings sent by that router. In Example 2-16, for 12008a to use label bindings from 11.11.11.11 for a prefix, the IGP next hop for that prefix must be one of the following addresses:

10.0.9.11

10.0.17.11

10.0.4.11

7.1.5.100

11.11.11.11

10.0.5.11

In liberal retention mode, if a route's next hop changes, as long as the next hop is one of the IP addresses listed under the Address bound portion for that neighbor, the LSR continues to use the previously received bindings it still holds.

Address Withdraw Message

The Address message and the Address Withdraw message share a similar format, as shown in Figure 2-25.

It contains a list of addresses that are being withdrawn in the Address List TLV.

Label Request Message

When LSRs are acting in DoD/conservative retention mode, the upstream LSR requests a label from the downstream LSR. This request is sent as a Label Request message. It has the format shown in Figure 2-26.

The FEC TLV contains the prefix for which the label binding is being requested.

Label Mapping Message

Label bindings are sent using the Label Mapping message. This is used for both DoD and Downstream Unsolicited distribution modes.

Figure 2-27 shows the format of the Label Mapping message.

The Optional Parameters can be one of the following:

• Label Request Message ID TLV— Usually set to the message ID that was set in the request message.

• Hop Count TLV— Specifies the total number of hops along the LSP that would be set up by the label message.

• Path Vector TLV— Contains the list of LSRs of the LSP being set up.

Hop Count and Path Vector TLVs are both used for loop avoidance, almost always in LC-ATM networks.

Label Withdraw Message

An LSR sends the Label Withdraw message when it wants to withdraw the previous bindings it sent. Upon receipt of the Label Withdraw message, an LSR should stop using the label binding and should respond with a Label Release message to the sender of the Label Withdraw message.

Figure 2-28 shows the format of the Label Withdraw message.

The Label TLV field is optional because, if it is present, only the labels that are listed in the Label TLV are withdrawn. If it isn't, all labels corresponding to that FEC should be removed.

Label Release Message

This is identical to the Label Withdraw message in format, except for the Label Release (0x0403) field. A Label Release message confirms the release of the label bindings that was indicated in the Label Withdraw message. It is also used in conservative retention mode, to signal that the upstream LSR will no longer use this label—perhaps because it's next-hop has changed. If the Label TLV is present and contains labels, the message confirms withdrawal of only those label bindings. If the Label TLV is empty, all label bindings corresponding to the FEC are confirmed as withdrawn.

Label Abort Request Message

Label Abort Request, as the name suggests, aborts any outstanding requests made earlier. This could happen under a few circumstances:

• If the route for the prefix has changed since the LSR made a request.

• This LSR has received an abort from an upstream LSR that prompted the request in the first place.

The LSR that receives the Abort Request can respond in the following ways:

• If it has not already replied to the request with a Label Mapping message or an error notification, it needs to reply with a Label Request Aborted Notification message.

• If the LSR has already replied, just ignore the notification.

Notification

When an LSR needs to inform its peers of a problem, it uses a Notification message. Notifications can be

• Error notifications

• Advisory notifications

Error notifications are used when the LSR has encountered a fatal error and cannot recover from it. This results in tearing down the LDP session. By the same token, LSRs that receive the notification discard all the bindings associated with this session.

Advisory notifications are used like a warning. The LSR can recover from such problems. Notifications are carried in Status messages, the format of which is illustrated in Figure 2-29.

The Status Code field has the format shown in Figure 2-30.

If the E bit is set to 1, a fatal error has occurred. If it is set to 0, it should be treated as a warning. The Status Data carries the Status Code of what actually went wrong.

Loop Detection

Loop detection is used only in DoD distribution mode, and therefore only in cell-mode ATM environments. This is because loop detection by nature requires ordered control mode. In ordered control mode, label requests are sent from upstream to downstream, and label bindings are sent in the opposite direction. This makes it natural for the LSRs along the path to add themselves to the path vector. If independent distribution mode is used, LSRs don't wait to receive label bindings from downstream neighbors before distributing labels to upstream neighbors. In DoD distribution, if an LSR receives a label mapping from its downstream neighbor in response to its own label request and the Label Mapping message contains a hop count TLV, the LSR simply updates the count. In Downstream Unsolicited (DU) distribution mode, no such communication occurs between neighbors. In a way, DoD can be considered stateful and DU stateless. Besides, in DU distribution, because the LSRs are routers and not ATM LSRs, the TTL field in the MPLS header is used to avoid infinite looping of packets.

If an LSR receives a Label Mapping message and the hop count TLV is out of range (more than the maximum), or if the path-vector TLV contains its own LSR ID, the LSR concludes that a loop is present within the LSP.

When an LSR detects a loop, it drops the label mapping and does not respond to the upstream neighbor's request. It also sends a notification message indicating a loop to the LSR that sent the Label Mapping message.