LDP, defined in RFC 3035, contains a set of procedures and messages by which LSRs establish LSPs through a network by mapping Layer 3 routing information directly to Layer 2 1/2 switched paths. LDP associates a Forwarding Equivalence Class (FEC) with each LSP it creates. The FEC associated with an LSP specifies which packets are mapped to that LSP. In essence, LDP is used to distribute <label, prefix> bindings. It runs in parallel with routing protocols. Other label-distribution mechanisms, such as TDP, Resource Reservation Protocol (RSVP), Protocol-Independent Multicast version 2 (PIMv2), and Border Gateway Protocol (BGPsee RFC 3107), can run in parallel with LDP. LDP descends from Cisco-proprietary TDP in such a way that LDP is a superset of TDP, using the same methods to achieve the same functions. The four categories of LDP messages are as follows:
LDP Message OverviewLDP runs over TCP port 646 to provide reliable delivery of messages. The only exception is the discovery message, which uses UDP port 646. LDP Message StructureAll LDP messages have a common structure that uses a type-length-value (TLV) encoding scheme to provide expandability. The value part of a TLV-encoded object (or TLV for short) can itself contain one or more TLVs. TLV encoding is very easy to deal with when it comes to adding a new capability because a new type is defined. As described in RFC 3036, the LDP specification, all LDP messages have an LDP header followed by one or more TLVs. The LDP header format is shown in Figure 4-7. Figure 4-7. LDP Message EncodingLDP HeaderThe fields in the LDP header are as follows:
Figure 4-8 shows the LDP TLV format. Figure 4-8. LDP Message EncodingTLV FormatFigure 4-8 contains the following fields:
LDP IdentifierThe LDP ID is a 32-bit magnitude that uniquely identifies the label space network-wide. Figure 4-9 shows the format of the LDP ID. Figure 4-9. LDP IdentifierFigure 4-9 has two fields:
The combination of these two fields forms an LDP identifier that uniquely identifies the label space network-wide. Each LDP identifier has it own LDP session, and each LDP session uses a separate TCP connection, as discussed in the upcoming section "Establishing LDP Sessions." Label SpacesFrame-based MPLS interfaces use a per-platform label space. In other words, labels are assigned from a unique pool of labels in the LSR. However, given the nature of labels on LC-ATM interfaces, per-platform label space cannot be used for ATM interfaces. Two LC-ATM interfaces can use the same VPI/VCI pair as a label. Therefore, LC-ATM interfaces use per-interface label spaces and a non-null label space ID. In summary, we have the following:
From another angle, one label space is used per LDP session. When two LSRs are connected through three frame-based interfaces, as shown in Figure 4-10, you have only one LDP session and one label space. Figure 4-10. Link Topology and LDP Sessions, Part IHowever, as shown in Figure 4-11, each LC-ATM interface has its own LDP session and label space. Figure 4-11. Link Topology and LDP Sessions, Part IISo an LSR has essentially two scenarios in which it needs to announce multiple label spaces to a peer and therefore use different LDP identifiers. One is when the LSR has two LC-ATM links to the peer, and the other is when the LSR has one LC-ATM link to the peer and one or more Ethernet links to the peer using per-platform label spaces. In summary, the number of LDP sessions is determined by the number of different label spaces. LDP DiscoveryLSRs learn of LSR neighbors using LDP discovery and LDP link hellos. Figure 4-12 shows an example of LDP hello messages. Figure 4-12. LDP Discovery Using HellosLDP discovery simplifies operational aspects of explicitly configuring peer LSRs. LDP link hellos are sent out of MPLS-enabled interfaces as UDP packets to the well-known UDP port 646 for LDP discovery and for an "all routers on this subnet" group multicast address (they are sent to 224.0.0.2:646 UDP). The willingness to label-switch on a specific link is signaled by the LDP link hello messages. Figure 4-13 shows a complete example of LDP discovery. Figure 4-13. LDP Discovery ExampleLDP sessions for nondirectly connected LSRs use an extended discovery process and require explicit configuration and the use of targeted hellos. There are two main differences between targeted hellos (or directed hellos) and normal hellos:
Establishing LDP SessionsLDP discovery triggers LDP session establishment. Session establishment is a two-step process:
An example of LDP session establishment is shown in Figure 4-14. Figure 4-14. LDP Session EstablishmentIf multiple links connect two LSRs and use the same label space and LDP ID, there will be multiple link or hello adjacencies but only one transport adjacency. Maintaining LDP SessionsTwo methods are used to maintain LDP sessions:
Label Distribution MethodsTo help you understand the label distribution methods, I will first define the terms downstream and upstream, which are relative to an IP destination or FEC in general. Figure 4-15 shows upstream and downstream routers. Figure 4-15. Upstream and Downstream RoutersIn Figure 4-15, Router C is the downstream neighbor of Router B for destination 10.1.2/24, and Router B is the downstream neighbor of Router A for destination 10.1.2/24. Likewise, Router A is the upstream neighbor of Router B for destination 10.1.2/24. Every interface on an LSR uses one of two methods for label distribution:
The advertisement mode is exchanged between peer LSRs during the initialization phase. Neighbor LSRs must agree on the distribution method used. The label-mapping LDP message uses two TLVs to perform the mappingthe FEC TLV and the Label TLV. Different types of labels use different Label TLVs. In particular, you can have a Generic Label TLV (type 0x0200), an ATM Label TLV (type 0x0201), and a Frame Relay Label TLV (type 0x0202). Two methods of label distribution control can be used:
One last concept has to do with whether an LSR maintains or requests a label binding from or to a neighbor that is not the next hop according to the routing table. This is called label retention mode, and it has two alternatives:
As a summary, Table 4-1 lists the different recommendations for label distribution modes.
Loop DetectionLDP implements three mechanisms to prevent looping LSPs beyond the loop detection mechanisms built into the IGP:
Figure 4-16 shows an example of the usage of the path vector TLV. Figure 4-16. Loop Prevention with the Path Vector TLVIf loop detection is desired in an MPLS domain, it should be turned on in all LSRs and eLSRs. Security ConsiderationsLDP runs on top of TCP, and it provides a TCP MD5 configurable signature option based on the one specified in RFC 2385 and used by BGP. The MD5 hash function is specified in RFC 1321. A shared secret is configured on the LDP peers, and the MD5 digest is computed from the shared password and the TCP segment. ATM MPLS provides extra security capabilities. With per-interface label space, an LSR using Downstream on Demand label allocation mode discards labeled packets from upstream neighbors if the label was not previously advertised to that neighbor. This inherent capability prevents label spoofing. |