Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Multipoint LDP In-Band Signaling for Point-to-Multipoint LSPs

Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs

The Multipoint Label Distribution Protocol (M-LDP) for point-to-multipoint label-switched paths (LSPs) with in-band signaling is useful in a deployment with an existing IP/MPLS backbone, in which you need to carry multicast traffic, for IPTV for example.

For years, the most widely used solution for transporting multicast traffic has been to use native IP multicast in the service provider core with multipoint IP tunneling to isolate customer traffic. A multicast routing protocol, usually Protocol Independent Multicast (PIM), is deployed to set up the forwarding paths. IP multicast routing is used for forwarding, using PIM signaling in the core. For this model to work, the core network has to be multicast enabled. This allows for effective and stable deployments even in inter-autonomous system (AS) scenarios.

However, in an existing IP/MPLS network, deploying PIM might not be the first choice. Some service providers are interested in replacing IP tunneling with MPLS label encapsulation. The motivations for moving to MPLS label switching is to leverage MPLS traffic engineering and protection features and to reduce the amount of control traffic overhead in the provider core.

To do this, service providers are interested in leveraging the extension of the existing deployments to allow multicast traffic to pass through. The existing multicast extensions for IP/MPLS are point-to-multipoint extensions for RSVP-TE and point-to-multipoint and multipoint-to-multipoint extensions for LDP. These deployment scenarios are discussed in RFC 6826, Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. This feature overview is limited to point-to-multipoint extensions for LDP.

How M-LDP Works

Label Bindings in M-LDP Signaling

The multipoint extension to LDP uses point-to-multipoint and multipoint-to-multipoint forwarding equivalence class (FEC) elements (defined in RFC 5036, LDP Specification) along with capability advertisements, label mapping, and signaling procedures. The FEC elements include the idea of the LSP root, which is an IP address, and an “opaque” value, which is a selector that groups together the leaf nodes sharing the same opaque value. The opaque value is transparent to the intermediate nodes, but has meaning for the LSP root. Every LDP node advertises its local incoming label binding to the upstream LDP node on the shortest path to the root IP address found in the FEC. The upstream node receiving the label bindings creates its own local label and outgoing interfaces. This label allocation process might result in packet replication, if there are multiple outgoing branches. As shown in Figure 1, an LDP node merges the label bindings for the same opaque value if it finds downstream nodes sharing the same upstream node. This allows for effective building of point-to-multipoint LSPs and label conservation.

Figure 1: Label Bindings in M-LDP Signaling Network diagram showing MPLS label flow: PE routers PE1, PE2, PE3 connect to MPLS backbone. P routers swap labels to route traffic. Red arrows indicate label mapping.

M-LDP in PIM-Free MPLS Core

Figure 2 shows a scaled-down deployment scenario. Two separate PIM domains are interconnected by a PIM-free core site. The border routers in this core site support PIM on the border interfaces. Further, these border routers collect and distribute the routing information from the adjacent sites to the core network. The edge routers in Site C run BGP for root-node discovery. Interior gateway protocol (IGP) routes cannot be used for ingress discovery because in most cases the forwarding next hop provided by the IGP would not provide information about the ingress device toward the source. M-LDP inband signaling has a one-to-one mapping between the point-to-multipoint LSP and the (S,G) flow. With in-band signaling, PIM messages are directly translated into M-LDP FEC bindings. In contrast, out-of-band signaling is based on manual configuration. One application for M-LDP inband signaling is to carry IPTV multicast traffic in an MPLS backbone.

Figure 2: Sample M-LDP Topology in PIM-Free MPLS Core Network diagram of a PIM-Free MPLS Domain with Sites A B and C. Dashed lines for IP multicast links and solid lines for MPLS multicast links. Core Site C is PIM-free.
Configuration

The configuration statement mldp-inband-signalling on the label-edge router (LER) enables PIM to use M-LDP in-band signaling for the upstream neighbors when the LER does not detect a PIM upstream neighbor. Static configuration of the MPLS LSP root is included in the PIM configuration, using policy. This is needed when IBGP is not available in the core site or to override IBGP-based LSP root detection.

For example:

M-LDP in PIM-Enabled MPLS Core

Starting in Junos OS Release 14.1, in order to migrate existing IPTV services from native IP multicast to MPLS multicast, you need to smoothly transition from PIM to M-LDP point-to-multipoint LSPs with minimal outage. Figure 3 shows a similar M-LDP topology as Figure 2, but with a different scenario. The core is enabled with PIM, with one source streaming all the IPTV channels. The TV channels are sent as ASM streams with each channel identified by its group address. Previously, these channels were streamed on the core as IP streams and signaled using PIM.

Figure 3: Sample M-LDP Topology in PIM-Enabled MPLS Core Network diagram showing multicast setup across three sites: Site A with router A1, Site C with routers C1-C4 as PIM MPLS domain, and Site B with routers B2-B3. Site A and B connect to Site C via IP multicast links. Multicast sources and receivers: Sa, 1 and Ra, 1 at Site A; Sb, 1 and Rb, 2 at Site B. Uses mLDP and PIM for multicast routing, ISIS/OSPF for protocols, and IBGP for MPLS domain routing.

By configuring the mldp-inband-signaling in this scenario, M-LDP signaling is initiated only when there is no PIM neighbor towards the source. However, because there is always a PIM neighbor towards the source unless PIM is deactivated on the upstream interfaces of the egress PE, PIM takes precedence over M-LDP and M-LDP does not take effect.

Configuration

To progressively migrate channel by channel to M-LDP MPLS core with few streams using M-LDP upstream and other streams using existing PIM upstream, include the selected-mldp-egress configuration statement along with group based filters in the policy filter for M-LDP inband signaling.

Note:

The M-LDP inband signaling policy filter can include either the source-address-filter statement or the route-filter statement, or a combination of both.

For example:

Note:

Some of the limitations of the above configuration are as follows:

  • The selected-mldp-egress statement should be configured only on the LER. Configuring the selected-mldp-egress statement on non-egress PIM routers can cause path setup failures.

  • When policy changes are made to switch traffic from PIM upstream to M-LDP upstream and vice-versa, packet loss can be expected as break-and-make mechanism is performed at the control plane.

Terminology

The following terms are important for an understanding of M-LDP in-band signaling for multicast traffic.

Point-to-point LSP

An LSP that has one ingress label-switched router (LSR) and one egress LSR.

Multipoint LSP

Either a point-to-multipoint or a multipoint-to-multipoint LSP.

Point-to-multipoint LSP

An LSP that has one ingress LSR and one or more egress LSRs.

Multipoint-to-point LSP

An LSP that has one or more ingress LSRs and one unique egress LSR.

Multipoint-to-multipoint LSP

An LSP that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others.

Ingress LSR

An ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. Multipoint-to-multipoint LSPs can have multiple ingress LSRs. Point-to-multipoint LSPs have only one, and that node is often referred to as the root node.

Egress LSR

An egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for further processing. Point-to-point and multipoint-to-point LSPs have only a single egress node. Point-to-multipoint and multipoint-to-multipoint LSPs can have multiple egress nodes.

Transit LSR

An LSR that has reachability to the root of the multipoint LSP through a directly connected upstream LSR and one or more directly connected downstream LSRs.

Bud LSR

An LSR that is an egress but also has one or more directly connected downstream LSRs.

Leaf node

Either an egress or bud LSR in the context of a point-to-multipoint LSP. In the context of a multipoint-to-multipoint LSP, an LSR is both ingress and egress for the same multipoint-to-multipoint LSP and can also be a bud LSR.

Ingress Join Translation and Pseudo Interface Handling

At the ingress LER, LDP notifies PIM about the (S,G) messages that are received over the in-band signaling. PIM associates each (S,G) messagewith a pseudo interface. Subsequently, a shortest-path-tree (SPT) join message is initiated toward the source. PIM treats this as a new type of local receiver. When the LSP is torn down, PIM removes this local receiver based on notification from LDP.

Ingress Splicing

LDP provides PIM with a next hop to be associated with each (S,G) entry. PIM installs a PIM (S,G) multicast route with the LDP next hop and other PIM receivers. The next hop is a composite next hop of local receivers + the list of PIM downstream neighbors + a sub-level next hopfor the LDP tunnel.

Reverse Path Forwarding

PIM's reverse-path-forwarding (RPF) calculation is performed at the egress node.

PIM performs M-LDP in-band signaling when all of the following conditions are true:

  • There are no PIM neighbors toward the source.

  • The M-LDP in-band signaling statement is configured.

  • The next hop is learned through BGP, or is present in the static mapping (specified in an M-LDP in-band signaling policy).

Otherwise, if LSP root detection fails, PIM retains the (S,G) entry with an RPF state of unresolved.

PIM RPF registers this source address each time unicast routing information changes. Therefore, if the route toward the source changes, the RPF recalculation recurs. BGP protocol next hops toward the source too are monitored for changes in the LSP root. Such changes might cause traffic disruption for short durations.

LSP Root Detection

If the RPF operation detects the need for M-LDP in-band signaling upstream, the LSP root (ingress) is detected. This root is a parameter for LDP LSP signaling.

The root node is detected as follows:

  1. If the existing static configuration specifies the source address, the root is taken as given in configuration.

  2. A lookup is performed in the unicast routing table. If the source address is found, the protocol next hop toward the source is used as the LSP root.

    Prior to Junos OS Release 16.1, M-LDP point-to-multipoint LSP is signaled from an egress to ingress using the root address of the ingress LSR. This root address is reachable through IGP only, thereby confining the M-LDP point-to-multipoint LSP to a single autonomous system. If the root address is not reachable through an IGP, but reachable through BGP, and if that BGP route is recursively resolved over an MPLS LSP, then the point-to-multipoint LSP is not signaled further from that point towards the ingress LSR root address.

    There is a need for these non-segmented point-to-multipoint LSPs to be signaled across multiple autonomous systems, which can be used for the following applications:

    • Inter-AS MVPN with non-segmented point-to-multipoint LSPs.

    • Inter-AS M-LDP inband signaling between client networks connected by an MPLS core network.

    • Inter-area MVPN or M-LDP inband signaling with non-segmented point-to-multipoint LSPs (seamless MPLS multicast).

    Starting from Junos OS Release 16.1, M-LDP can signal point-to-multipoint LSPs at ASBR or transit or egress when root address is a BGP route which is further recursively resolved over an MPLS LSP.

Egress Join Translation and Pseudo Interface Handling

At the egress LER, PIM notifies LDP of the (S,G) message to be signaled along with the LSP root. PIM creates a pseudo interface as the upstream interface for this (S,G) message. When an (S,G) prune message is received, this association is removed.

Egress Splicing

At the egress node of the core network, where the (S,G) join message from the downstream site is received, this join message is translated to M-LDP in-band signaling parameters and LDP is notified. Further, LSP teardown occurs when the (S,G) entry is lost, when the LSP root changes, or when the (S,G) entry is reachable over a PIM neighbor.

Supported Functionality

For M-LDP in-band signaling, Junos OS supports the following functionality:

  • Egress splicing of the PIM next hop with the LDP route

  • Ingress splicing of the PIM route with the LDP next hop

  • Translation of PIM join messages to LDP point-to-multipoint LSP setup parameters

  • Translation of M-LDP in-band LSP parameters to set up PIM join messages

  • Statically configured and BGP protocol next hop-based LSP root detection

  • PIM (S,G) states in the PIM source-specific multicast (SSM) and anysource multicsast (ASM) ranges

  • Configuration statements on ingress and egress LERs to enable them to act as edge routers

  • IGMP join messages on LERs

  • Carrying IPv6 source and group address as opaque information toward an IPv4 root node

  • Static configuration to map an IPv6 (S,G) to an IPv4 root address

Unsupported Functionality

For M-LDP in-band signaling, Junos OS does not support the following functionality:

  • Full support for PIM ASM

  • The mpls lsp point-to-multipoint ping command with an (S,G) option

  • Nonstop active routing (NSR)

  • Make-before-break (MBB) for PIM

  • IPv6 LSP root addresses (LDP does not support IPv6 LSPs.)

  • Neighbor relationship between PIM speakers that are not directly connected

  • Graceful restart

  • PIM dense mode

  • PIM bidirectional mode

LDP Functionality

The PIM (S,G) information is carried as M-LDP opaque type-length-value (TLV) encodings. The point-to-multipoint FEC element consists of the root-node address. In the case of next-generation multicast VPNs (NGEN MVPNs), the point-to-multipoint LSP is identified by the root node address and the LSP ID.

Egress LER Functionality

On the egress LER, PIM triggers LDP with the following information to create a point-to-multipoint LSP:

  • Root node

  • (S,G)

  • Next hop

PIM finds the root node based on the source of the multicast tree. If the root address is configured for this (S,G) entry, the configured address is used as the point-to-multipoint LSP root. Otherwise, the routing table is used to look up the route to the source. If the route to the source of the multicast tree is a BGP-learned route, PIM retrieves the BGP next hop address and uses it as the root node for the point-to-multipoint LSP.

LDP finds the upstream node based on the root node, allocates a label, and sends the label mapping to the upstream node. LDP does not use penultimate hop popping (PHP) for in-band M-LDP signaling.

If the root addresses for the source of the multicast tree changes, PIM deletes the point-to-multipoint LSP and triggers LDP to create a new point-to-multipoint LSP. When this happens, the outgoing interface list becomes NULL, PIM triggers LDP to delete the point-to-multipoint LSP, and LDP sends a label withdraw message to the upstream node.

Transit LSR Functionality

The transit LSR advertises a label to the upstream LSR toward the source of the point-to-multipoint FEC and installs the necessary forwarding state to forward the packets. The transit LSR can be any M-LDP capable router.

Ingress LER Functionality

On the ingress LER, LDP provides the following information to PIM upon receiving the label mapping:

  • (S,G)

  • Flood next hop

Then PIM installs the forwarding state. If the new branches are added or deleted, the flood next hop is updated accordingly. If all branches are deleted due to a label being withdrawn, LDP sends updated information to PIM. If there are multiple links between the upstream and downstream neighbors, the point-to-multipoint LSP is not load balanced.

Example: Configuring Multipoint LDP In-Band Signaling for Point-to-Multipoint LSPs

This example shows how to configure multipoint LDP (M-LDP) in-band signaling for multicast traffic, as an extension to the Protocol Independent Multicast (PIM) protocol or as a substitute for PIM.

Requirements

This example can be configured using the following hardware and software components:

  • Junos OS Release 13.2 or later

  • MX Series 5G Universal Routing Platforms or M Series Multiservice Edge Routers for the Provider Edge (PE) Routers

  • PTX Series Packet Transport Routers acting as transit label-switched routers

  • T Series Core Routers for the Core Routers

Note:

The PE routers could also be T Series Core Routers but that is not typical. Depending on your scaling requirements, the core routers could also be MX Series 5G Universal Routing Platforms or M Series Multiservice Edge Routers. The Customer Edge (CE) devices could be other routers or switches from Juniper Networks or another vendor.

No special configuration beyond device initialization is required before configuring this example.

Overview

CLI Quick Configuration shows the configuration for all of the devices in Figure 4. The section #d484e113__d484e932 describes the steps on Device EgressPE.

Figure 4: M-LDP In-Band Signaling for Point-to-Multipoint LSPs Example Topology Multicast network diagram with nodes: src1 10.1.1.7/32 to IngressPE 10.1.1.2/32, Transit p6 10.1.1.6/32, EgressPE 10.1.1.1/32 to Receiver 192.168.215.11/28 via interfaces. Nodes pr3, pr4, pr5 and cloud networks shown.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device src1

Device IngressPE

Device EgressPE

Device p6

Device pr3

Device pr4

Device pr5

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device EgressPE:

  1. Configure the interfaces.

    Enable MPLS on the core-facing interfaces. On the egress next hops, you do not need to enable MPLS.

  2. Configure IGMP on the egress interfaces.

    For testing purposes, this example includes static group and source addresses.

  3. Configure MPLS on the core-facing interfaces.

  4. Configure BGP.

    BGP is a policy-driven protocol, so also configure and apply any needed routing policies.

    For example, you might want to export static routes into BGP.

  5. (Optional) Configure an MSDP peer connection with Device pr5 in order to interconnect the disparate PIM domains, thus enabling redundant RPs.

  6. Configure OSPF.

  7. Configure LDP on the core-facing interfaces and on the loopback interface.

  8. Enable point-to-multipoint MPLS LSPs.

  9. Configure PIM on the downstream interfaces.

  10. Configure the RP settings because this device serves as the PIM rendezvous point (RP).

  11. Enable M-LDP in-band signaling and set the associated policy.

  12. Configure the routing policy that specifies the root address for the point-to-multipoint LSP and the associated source addresses.

  13. Configure the autonomous system (AS) ID.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device EgressPE

Similarly, configure the other egress devices.

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the PIM Join States

Purpose

Display information about PIM join states to verify the M-LDP in-band upstream and downstream details. On the ingress device, the show pim join extensive command displays Pseudo-MLDP for the downstream interface. On the egress, the show pim join extensive command displays Pseudo-MLDP for the upstream interface.

Action

From operational mode, enter the show pim join extensive command.

Checking the PIM Sources

Purpose

Verify that the PIM sources have the expected M-LDP in-band upstream and downstream details.

Action

From operational mode, enter the show pim source command.

Checking the LDP Database

Purpose

Make sure that the show ldp database command displays the expected root-to-(S,G) bindings.

Action

Looking Up the Route Information for the MPLS Label

Purpose

Display the point-to-multipoint FEC information.

Action

Checking the LDP Traffic Statistics

Purpose

Monitor the data traffic statistics for the point-to-multipoint LSP.

Action

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
16.1
Starting from Junos OS Release 16.1, M-LDP can signal point-to-multipoint LSPs at ASBR or transit or egress when root address is a BGP route which is further recursively resolved over an MPLS LSP.
14.1
Starting in Junos OS Release 14.1, in order to migrate existing IPTV services from native IP multicast to MPLS multicast, you need to smoothly transition from PIM to M-LDP point-to-multipoint LSPs with minimal outage.