LDP Extensions

Background

On a large-scale network, multiple IGP areas are often configured for flexible network deployment and fast route convergence. To reduce the number of routes and conserve resources, area border routers (ABRs) summarize the routes in their areas and advertise the summarized routes to neighboring IGP areas. However, LDP follows the exact match principle when establishing LSPs. LDP searches for the route exactly matching a forwarding equivalence class (FEC) in the received Label Mapping message. If only summarized routes are available, LDP supports only liberal LSPs and cannot set up inter-area LSPs. LDP extensions are available to help set up inter-area LDP LSPs.

A liberal LSP is an LSP that has been assigned labels but fails to be established.

Implementation

The network shown in Figure 3-5 have two IGP areas, Area 10 and Area 20. LSR_2 at the border of Area 10 has two host routes to LSR_3 and LSR_4. To reduce the resources consumed by routes, LSR_2 can run IS-IS to summarize the two routes to one route 1.3.0.0/24 and advertise this route to Area 20.

Figure 3-5  Networking topology for LDP extensions for inter-area LSPs

When establishing an LSP, LDP searches the routing table for the route that exactly matches the FEC in the received Label Mapping message. In Figure 3-5, LSR_1 has only a summarized route (1.3.0.0/24) but not 32-bit host routes in its routing table. Table 3-4 lists the route of LSR_1 and routes carried in the FEC.

If only summarized routes are available, LDP supports only liberal LSPs and cannot set up inter-area LDP LSPs. In this situation, tunnels cannot be set up on the backbone network.

To set up an LSP, LSR_1 must follow the longest match principle to find the route. There is a summarized route 1.3.0.0/24 in the routing table of LSR_1. When LSR_1 receives a Label Mapping message (for example, a message carrying FEC 1.3.0.1/32) from Area 10, LSR_1 finds the summarized route 1.3.0.0/24 according to the longest match principle. Then LSR_1 applies the outbound interface and next hop of the summarized route to the route 1.3.0.1/32. An inter-area LDP LSP is established.

Background

On a large-scale network with inter-AS L3VPN Option C deployment, PEs and ASBRs establish fully meshed IBGP peer relationships. This deployment increases loads PEs and ASBRs, requires complex configuration, and makes network expansion difficulty. LDP can allocate labels to BGP routes to solve this problem.

Implementation

In Figure 3-6, IBGP peer relationships do not need to be established between PE_1 and ASBR_1 or between PE_2 and ASBR_2. The two ASBRs run LDP to distribute labels to BGP routes and import BGP routes to an IGP. Then a local PE can set up an LDP ingress LSP destined for the peer PE as the public network tunnel for L3VPN services. LDP LSPs and BGP LSPs transmit private network traffic over the public network.

Figure 3-6  L3VPN inter-AS Option C

LDP works with GBP routes as follows:

• Route advertisement

  The loopback address of PE_2 in Figure 3-6 is used as an example to describe the route advertisement process. PE_2 advertises 5.5.5.9/32 to ASBR_2 through an IGP. After learning the route 5.5.5.9/32, ASBR_2 distributes a label to the route and then advertises 5.5.5.9/32 to EBGP neighbor ASBR_1 through BGP. After ASBR_1 learns the labeled public network BGP route 5.5.5.9/32, ASBR_1 advertises the route (already imported to an IGP) to PE_1 through an IGP. Then PE_1 learns the IGP route 5.5.5.9/32.

• Label distribution

  Figure 3-7 shows tunnel label distribution on the public network. Lm is distributed by MP-BGP. Lx, Ln, and L3 are distributed to IGP routes by LDP. Ly is distributed to a BGP route by LDP.

  Figure 3-7  Label distribution
  
  

• Packet forwarding

  After labels are distributed, an LSP is set up. Figure 3-8 shows the packet forwarding process. L3 is a private network label.

  Figure 3-8  Packet forwarding process
  
  

  PE_1 pushes a BGP private label and then an LDP label to the packet. P_1 swaps the LDP label in the packet. ASBR_1 pops outs the LDP label, directs the packet to the LDP LSP, and then pushes a BGP public label to the packet. ASBR_2 pops outs the BGP public label, directs the packet to the LDP LSP, and then pushes an LDP label to the packet. P_2 swaps the LDP label in the packet and pops out L3. PE_2 pops out the inner BGP private label and forwards the packet to 20.0.0.1/8 through IP routing.

GRE provides a mechanism to encapsulate packets of a protocol into packets of another protocol. This allows packets to be transmitted over heterogeneous networks. A channel for transmitting heterogeneous packets is called a tunnel.

If backbone network devices are not enabled with MPLS or do not support MPLS, LDP LSPs cannot be established. As a result, L2VPN or L3VPN services cannot be deployed. LDP over GRE/mGRE addresses the preceding problem.

LDP over GRE

LDP over GRE technology establishes an LDP LSP on a GRE tunnel interface configured with MPLS LDP to transmit MPLS LDP packets.

As shown in Figure 3-9, L2VPN or L3VPN services are deployed between PE_1 and PE_2 of an enterprise. Because backbone network devices may be not enabled with MPLS or do not support MPLS, an LDP LSP across a GRE tunnel needs to be set up between PE_1 and PE_2.

Figure 3-9  Deploying LDP over GRE on L2VPN/L3VPN networking (all P devices do not support MPLS)

As shown in Figure 3-10, backbone network device P_2 supports MPLS, whereas P_1 does not support MPLS. A GRE tunnel can be established between PE_1 and P_2 so that an LDP LSP is set up across the GRE tunnel.

Figure 3-10  Deploying LDP over GRE on L2VPN/L3VPN networking (some P devices do not support MPLS)

LDP over mGRE

Dynamic Smart Virtual Private Network (DSVPN) technology solves the preceding problem. NHRP solves problems caused by non-fixed public addresses of branch devices and dynamically establishes a tunnel between the headquarters and a branch. mGRE allows multiple GRE tunnels to be set up on a tunnel interface, simplifying the Hub configuration. Similar to LDP over GRE, LDP over mGRE technology establishes an LDP LSP on an mGRE tunnel interface configured with MPLS LDP to transmit MPLS LDP packets.

As shown in Figure 3-11, the enterprise establishes a backbone network. The headquarters Hub-P_1 uses a static address to connect to the public network and branch Spoke-PE uses dynamic addresses to connect to the public network. The enterprise requires that L3VPN services be deployed between all PEs. Because branch devices connect to the enterprise IP/MPLS backbone network through the public network and Spoke-PEs' public addresses are not fixed, LDP over mGRE is used to establish LDP LSPs between PEs across GRE tunnels.

Figure 3-11  Deploying LDP over mGRE in Hub-Spoke networking

When LDP over mGRE is used to construct an L3VPN network, traffic between branches is forwarded through Hubs.

In addition, MPLS requires that labels in MPLS packets be swapped on LSPs between ingress and egress nodes. After LDP over mGRE is used, all Spokes are equivalent to PEs on an MPLS network. If Spokes directly communicate with each other (this scenario is not used), each two Spokes need to establish an LDP and distribute labels. Consequently, label resources of Spokes are insufficient. You can use the Hub to forward traffic between branches (the Hub, similar to the P on an MPLS network, maintains the LDP neighbor relationship and swaps packet labels). A Spoke only needs to establish one LSP with the Hub so that the Spoke can communicate with other Spokes. Because MPLS label swapping is used, only traffic on the Hub is increased. Hub performance is less affected.

Although LDP over mGRE does not use DSVPN to establish tunnels between Spokes, it provides the Spoke-Hub-Spoke path to better transmit traffic between Spokes. LDP over mGRE is often used when the MPLS network needs to be extended.