Feb
08

Overview

The purpose of this blog post is to give you a brief overview of M-LSPs, the motivation behind this technology and demonstrate some practical examples. We start with Multicast VPNs and then give an overview of the M-LSP implementations based on M-LDP and RSVP-TE extensions. The practical example is based on the recently added RSVP-TE signaling for establishing P2MP LSPs. All demostrations coud be replicated using the widely available Dynamips hardware emulator. The reader is assumed to have solid understanding of MPLS technologies, including LDP, RSVP-TE, MPLS/BGP VPNs and Multicast VPNs.

Multicast Domains Model

For years, the most popular solution for transporting multicast VPN traffic was using native IP multicast in SP core coupled with dynamic multipoint IP tunneling to isolate customer traffic. Every VPN would be allocated a separate MDT (Multicast Distribution Tree) or domain mapped to a core multicast group. Regular IP multicast routing is then used for forwarding, using PIM signaling in core. Notice, that the core network has to be multicast enabled in Multicast Domains model. This model is well mature by today and allows for effective and stable deployments even in Inter-AS scenarios. However, for the long time the question with MPVNs was – could we replace IP tunneling with MPLS label encapsulation? And the main motivation for moving to MPLS label switching would be leveraging MPLS traffic-engineering and protection features.

Tag Switched Multicast


In early days of MPLS deployment (mid-late 90s) you may have seen Cisco IOS supporting tag switching for multicast traffic. Indeed, you may still find some references to these models in some older RFC drafts:

draft-rfced-info-rekhter-00.txt
draft-farinacci-multicast-tag-part-00

There were no ideas about MPLS TE and FRR back then, just some considerations to use tag encapsulation for fast-switching the multicast packets. Older IOS versions had support for multicast tag switching, which was rather quickly removed, due to compatibility issues (PIM extensions were used for label bindings) and experimental status of the project. Plus, as time passed it became obvious that a more generic concept is required as opposed to pure tag-switched multicast.

Multipoint LSP Overview

Instead of trying to create label-switched multicast, the community came with an idea of Point-to-Multipoint (P2MP) LSPs. The regular, point-to-point (P2P) LSPs are mapped to a single FEC element, which represents a single “destination” (e.g. egress route, IP prefix, Virtual Circuit). On contrary, P2MP LSP has multiple destinations, but a single root – essentially, P2MP LSP represents a tree, with a known root and some opaque “selector” value shared by all destinations. This “selector” could be a multicast group address if you map multicast groups to LSPs, but it is quite generic and is not limited to just multicast groups. P2MP LSPs could be though of as some sort of shortest-path trees built toward the root and using label switching for traffic forwarding. The use of P2MP LSPs could be much wider than simple multicast forwarding, as those two concepts are now completely decoupled. One good example of using P2MP LSPs could be VPLS deployment, where full-mesh of P2P pseudo-wires is replaced with P2MP LSPs rooted at every PE and targeted at all other PEs.

In addition to P2MP, a concept of multipoint-to-multipoint (MP2MP) LSP was introduced. MP2MP LSP has a single “shared” root just like P2MP LSP, but traffic could flow upstream to the root and downstream from the root. Every leaf node may send traffic to every other leaf mode, by using upstream LSP toward the root and downstream P2MP LSP to other leaves. This is in contrary to P2MP LSPs where only root is sending traffic downstream. The MP2MP LSPs could be though as equivalents of bi-directional trees found in PIM. Collectively, P2MP and MP2MP LSPs are named multipoint LSPs.

To complete this overview, we list several specific terms used with M-LSPs to describe the tree components:

  • Headend (root) router – the router that originates P2MP LSP
  • Tailend (leaf) router – the router that terminates the P2MP LSP
  • Midpoint router –the router that swiches P2MP LSP but does not terminate it
  • Bud router – the router that is leaf and midpoint at the same time

M-LDP Solution

Multipoint Extension to LDP defined in draft-ietf-mpls-ldp-p2mp-04 adds the notion of P2MP and MP2MP FEC elements to LDP (defined in RFC 3036) along with respective capability advertisements, label mapping and signaling procedures. The new FEC element have the notion of the LSP root, which is an IPv4 address and a special “opaque” value (the “selector, mentioned above), which groups together the leaf nodes sharing the same opaque value. The opaque value is “transparent” for the intermediate nodes, but has meaning for the root and possibly leaves. Every LDP node advertises its local incoming label binding to the upstream LDP node on the shortest path to the root IPv4 address found in FEC. The upstream node receiving the label bindings creates its own local label(s) and outgoing interfaces. This label allocation process may result in requirements for packet replication, if there are multiple outgoing branches. It is important to notice that an LDP node will merge the label binding for the same opaque value if it founds downstream nodes sharing the same upstream node. This allows for effective building of P2MP LSPs and label conservation.

p2mp-lsp-primer-mldp-signaling

Pay attention to the fact that leaf nodes must NOT allocate an implicit-null label for the P2MP FEC element, i.e. must disable PHP behavior. This is important to allow the leaf node learn the context of incoming packet and properly recognize it as coming from a P2MP LSP. The leaf node may then perform RPF check or properly select the outgoing processing for the packet based on the opaque information associated with the context. This means that the LDP implementation must support context-specific label spaces, as defined in the draft draft-ietf-mpls-upstream-label-02. The need for context-specific processing arises from the fact that M-LSP type is generic and therefore the application is not directly known from the LSP itself. Notice that RFC 3036 has previous defined two “contexts” know as label spaces – those were “interface” and “platform” label spaces.

As we mentioned, MP2MP LSPs are also defined within the scope of M-LDP draft. Signaling for MP2MP LSPs is a bit more complicated, as it involves building P2MP LSP for the shared root and upstream M2MP LSPs from every leaf mode toward the same root. You may find the detailed procedure description in the draft document mentioned above.

Just like multicast multipath procedure, M-LDP supports equal-cost load splitting, in situations where the root node is reachable via multiple upstream paths. In this case, the upstream LDP node is selected using a hash function resulting in load-splitting similar. You may want to read the following document to get a better idea of multicast multipath load splitting: Multicast Load Splitting

M-LDP Features

It is important to notice that LDP is the only protocol required to build the M-LSPs (along with respective IGP, of course). Even if you deploy multicast applications on top of M-LSPs, you don’t need to run PIM in the network core, like it you needed with original tag-switched multicast or when using Multicast Domains model. M-LDP allows for dynamic signaling of M-LSPs, irrespective of their nature. The biggest benefit is reduction of specific signaling protocols in the network core. However, the main problem is that traffic engineering is not native to M-LDP (CR-LDP is R.I.P). However, it seems that Cisco now supports MPLE TE for M-LDP signaled LSPs, at list it is apparent from the newly introduced command set. Also, IP Fast Reroute is supported for LDP singled LSPs, but this feature is not that mature and widely deployed as RSVP-TE implementations. If you are interested in IP FRR procedures, you may consult the documents found under the respective IETF working group. As for implementations, later versions os Cisco IOS XR do support IP FRR.

M-LDP Applications

First and foremost M-LDP could be used for multicast VPNs, replacing multipoint GRE encapsulation and eliminating the need for multicast routing and PIM in the SP network core. Taking the classis MDT domains model, the default MDT could be replaced with a single MP2MP LSP connecting all participating PEs and data MDTs could be mapped to P2MP LSPs signaled toward the participating PEs. The opaque value used could be the group IP address coupled with the respective RD, allowing for effective M-LSP separation in the SP core.
There is another, more direct approach to multicast VPNs with M-LDP. Instead of using the MDT trees, a customer tree could be signaled explicitly across the SP code. When a CE node sends PIM Join toward an (S,G) where S is a VPN address, the PE router will instruct M-LDP to construct the M-LSP toward the root that is the VPNv4 next-hop for the S and using the opaque value of (S,G,RD) which is passed across the core. The PE node that roots the M-LSP interprets the opaque value and geneate PIM Join toward the actual source S.

p2mp-lsp-primer-direct-mdt-model

This model is known as Direct MDT and is more straightforward than the Domains model with respect to the signaling used. However, the drawback is excessive generation of MPLS forwarding states in the network core. A solution to overcome this limitation would be to use hierarchical LSPs, which is another extension to LDP that is being developed. We may expect to see Inter-AS M-LSP extensions in near future too, modeled after the BGP MDT SAFI (e.g. Opaque information propagation) and RPF Proxy Vector features (for finding the correct next hop toward an M-LSP root in another AS). If you want to find out more about those technologies, you may read the following document: Inter-AS mVPNs: MDT SAFI, BGP Connectorand RPF Proxy Vector.

As mentioned above, multicasting is not the only application that could benefit from M-LSPs. Any application that requires traffic flooding or multipoint connection is a good candidate for using M-LSPs. Like we mentioned above, VPLS is the next obvious candidate for using M-LSPs, which may result in optimal broadcast and multicast forwarding in VPLS deployments. You may see the VPLS multicast draft for more details: draft-ietf-l2vpn-vpls-mcast-05

Summary

M-LDP is not yet completely standardized, even though the work has been in progress for many years. Experimental Cisco IOS trains support this feature, but those are not yet available to general public. The main feature of M-LDP signaled M-LSPs is that they don’t require any other protocol aside from LDP, are dynamically initiated by leaf nodes and very generic in respect to the applications that could use them.

RSVP-TE Point-to-Multipoint LSPs

Along with “yet-work-in-progress” M-LDP draft, there is another standard technique for signaling P2MP LSPs using RSVP protocol. This technique has been long time employed in Juniper SP multicast solution and thus is quite mature, compared to M-LDP. Recently, RSVP-signaled P2MP LSPs have been officially added in many Cisco IOS trains, including IOS version for 7200 platform. The RSVP extensions are officially standardized in RFC 4875, which could be found at RFC 4875.

Signaling Procedures

This standard employs the concept of P2MP LSPs statically signaled at head-end router using a fixed list of destinations (leaves). Every destination defines so-called “sub-LSP” construct of the P2MP LSP. The Sub-LSP an LSP originating at the root and terminating at the particular leaf. RSVP signaling for P2MP Sub-LSPs bases on sending RSVP PATH messages to all destinations (sub-LSPs) independently, though multiple sub-LSP descriptions could be carried in a single PATH message. Every leaf node then sends RSVP RESV messages back to the root node of the P2MP LSP, just like in regular RSVP TE. However, the nodes where multiple RSVP RESV messages “merge” should allocate only a single label for those “merging” sub-LSPs and advertise it to the upstream node using either multiple or single RESV messages. Effectively, this “branches” the sub-LSPs out of the “trunk”, even though signaling for both sub-LSPs is performed separately. The whole procedure is somewhat similar to the situation where source uses RSVP for bandwidth reservation for a multicast traffic flow, with flow state merging at the branching point. This is no surprise as the P2MP LSP idea was modeled after multicast distribution shortest-path trees.

p2mp-lsp-primer-rsvp-te-signaling

The only “edge” (that is PE-CE) multicast tree construction protocol supported with RSVP-TE M-LSPs is PIM SSM, as static M-LSPs do not support dynamic source discovery by means of RP. Plus, as we mentioned above, every leaf-node allocated a non-null label for incoming Sub-LSP tunnel. This allows the leaf router to associate the incoming packets with a particular M-LSP and properly perform RPF check using the tunnel source address. Cisco IOS creates a special virtual interface know as LSPVIF and associate the multicast RPF route toward M-LSP tunnel source with this interface. Every new M-LSP will create another LSPVIF interface and another static mroute. In addition to this, you need to manually set static multicast routes for the multicast sources that would be using this tunnel and associate them with the tunnel’s source address. An example will be shown later.

Notice that RSVP-signaled M-LSPs are currently supported only within a single IGP area and there is no support for Inter-AS M-LSPs. However, we may expect those extensions in the future, as they exist for P2P LSPs.

Benefits, Limitations and Applications

The huge benefit of RSVP-signaled P2MP LSPs is that every sub-LSP could be constructed using cSPF, honoring bandwidth, affinity and other constraints. You may also manually specify explicit paths in situations where you use offline traffic-engineering strategy. The actual merging of the sub-LSPs allows for accurate bandwidth usage and avoiding duplicate reservations for the same flow. The second biggest benefit is that since every Sub-LSP is signaled explicitly via RSVP, the whole P2MP LSP construct could be natively protected using RSVP FRR mechanics per RFC 4060. Finally, just like M-LDP, RSVP-signaled M-LSPs do not require running any other signaling protocol such as PIM in the SP network core.

In general, RSVP signaled P2MP LSPs are an excellent solution for multicast IP-TV deployments, as they allow for accurate bandwidth reservation and admission control along with FRR protection. Plus, this solution has been around for quite a while, meaning it has some maturity, as compared to the developing M-LDP. However, the main drawback of RSVP-based solution is the static nature of RSVP-TE signaled P2MP LSPs, which limits their use for Multicast VPN deployments. You may combine P2MP LSPs with Domain-based Multicast VPN solution, but this limits your M-VPNs to a single Default MDT tunneled inside the P2MP LSP.

In addition to IP-TV application, RSVP-TE M-LSPs form a solution to improve multicast handling in VPLS. Effectively, since VPLS by its nature does not involve dynamic setup of pseudowires, the static M-LSP tunnels could be used to optimal traffic forwarding across the SP core. There is an IETF draft outlining this solution: draft-raggarwa-l2vpn-vpls-mcast-01.

M-LSP RSVP-TE Lab Scenario

For a long time, Cisco hold on with releasing the support of RSVP-TE signaled M-LSPs to the wide auditory, probably because the main competitor (Juniper) actively supported and developed this solution. However, there was an implementation used for limited deployments and recently made public with the IOS version of 12.2(33)SRE. The support now includes even the low-end platforms such as 7200VXR, which allows using Dynamips for lab experiments. We will now review a practical example of P2MP LSP setup using the following topology:

p2mp-lsp-primer-lab-scenario

Where R1 sets up an M-LSP to R2, R3 and R4 and configures the tunnel to send multicast traffic down to the nodes. Notice a few details about this scenario. Every node is configured to enable automatic primary one-hop tunnels and NHOP backup tunnels. This is a common way of protecting links in the SP core, which allows for automatic unicast traffic protection. If you are not familiar with this feature, you may read the following document: MPLS TE Auto-Tunnels.

The diagram above displays some of the detour LSPs that are automatically created for protection of “peripheral” links. In the topology outlined every node will originate three primary tunnels and three backup NHOP tunnels. First, look at the template configuration shared by all routes:

Shared Template

!
! Set up auto-tunnels on all routers
!
mpls traffic-eng tunnels
mpls traffic-eng auto-tunnel backup nhop-only
mpls traffic-eng auto-tunnel primary onehop
!
! Enable multicast traffic routing over MPLS TE tunnels
!
ip multicast mpls traffic-eng
!
! Enable fast route withdrawn when an interface goes down
!
ip routing protocol purge interface
!
router ospf 1
 network 0.0.0.0 0.0.0.0 area 0
 mpls traffic-eng area 0
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng multicast-intact
!
! The below commands are only needed on leaf/root nodes: R1-R4
!
ip multicast-routing
ip pim ssm default

Notice a few interesting commands in this configuration:

  • The command ip multicast mpls traffic-eng enables multicast traffic to be routed over M-LSP tunnels. This still requires configuring a static IGMP join on the M-LSP tunnel interface as the tunnel is unidirectional.
  • The command ip routing protocol purge interface
    is needed on leaf nodes that perform RPF check. When a connected interface goes down, IOS code normally runs special walker process that goes through the RIB and deletes the affected routes. This may take considerable time and affect RPF checks if the Sub-LSP was rerouted over a different incoming interface. The demonstrated command allows for fast purging of RIB by notifying the affected IGPs and allowing the protocol process to quickly clear the associated routes.
  • The command mpls traffic-eng multicast-intact is very important in our context as we activate MPLS TE tunnels and enabled auto-route announces. By default, this may affect RPF check information for the M-LSP tunnel source and force the leaf nodes to drop the tunneled multicast packets. This command should be configured along with the static multicast routes as shown below.

Head-End configuration

R1:
hostname R1
!
interface Loopback 0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial 2/0
 no shutdown
 encapsulation frame-relay
 no frame-relay inverse
!
interface Serial 2/0.12 point
 frame-relay interface-dlci 102
 ip address 10.1.12.1 255.255.255.0
 bandwidth 10000
 mpls traffic-eng tunnels
 ip rsvp bandwidth 10000
!
interface Serial 2/0.15 point
 frame-relay interface-dlci 105
 ip address 10.1.15.1 255.255.255.0
 bandwidth 10000
 mpls traffic-eng tunnels
 ip rsvp bandwidth 10000
!
interface Serial 2/0.14 point
 frame-relay interface-dlci 104
 ip address 10.1.14.1 255.255.255.0
 bandwidth 10000
 mpls traffic-eng tunnels
 ip rsvp bandwidth 10000
!
interface FastEthernet 0/0
 ip address 172.16.1.1 255.255.255.0
 ip pim passive
 no shutdown
!
mpls traffic-eng destination list name P2MP_TO_R2_R3_R4_DYN
 ip 10.1.2.2 path-option 10 dynamic
 ip 10.1.3.3 path-option 10 dynamic
 ip 10.1.4.4 path-option 10 dynamic
!
interface Tunnel 0
 description R1 TO R2, R3, R4
 ip unnumbered Loopback0
 ip pim passive
 ip igmp static-group 232.1.1.1 source 172.16.1.1
 tunnel mode mpls traffic-eng point-to-multipoint
 tunnel destination list mpls traffic-eng name P2MP_TO_R2_R3_R4_DYN
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth 5000
 tunnel mpls traffic-eng fast-reroute
  • First notice that PIM is not enabled on any of the core-facing interfaces. This is due to the fact that M-LSP signaling does not require any core multicast set up. Secondly, notice the use of command ip pim passive. This is a long awaited command that enables multicast forwarding out of the interfaces but does not allow to establish any PIM adjacencies.
  • The command mpls traffic-eng destination list defines multiple destinations to be used for the M-LSP. Every destination could have one or more path options. Every path option could be either dynamic or explicit, and we use only dynamic path options for every destination.
  • Notice the M-LSP tunnel configuration. The tunnel mode is set to multipoint and the destination is set to the list created above. Pay attention that PIM passive mode is enabled on the tunnel interface along with a static IGMPv3 join. This allows for the specific multicast flow to be routed down the M-LSP.
  • Lastly, pay attention to the fact that the tunnel is configured with TE attributes, such as bandwidth and enabled for FRR protection. The syntax used is the same as with the P2P LSPs

Midpoint and Tail-End Configuration

R2:
hostname R2
!
interface Loopback 0
 ip address 10.1.2.2 255.255.255.255
!
interface Serial 2/0
 no shutdown
 encapsulation frame-relay
 no frame-relay inverse
!
interface Serial 2/0.12 point
 frame-relay interface-dlci 201
 ip address 10.1.12.2 255.255.255.0
 bandwidth 10000
 mpls traffic-eng tunnels
 ip rsvp bandwidth 10000
!
interface Serial 2/0.26 point
 frame-relay interface-dlci 206
 ip address 10.1.26.2 255.255.255.0
 bandwidth 10000
 mpls traffic-eng tunnels
 ip rsvp bandwidth 10000
!
interface Serial 2/0.23 point
 frame-relay interface-dlci 203
 ip address 10.1.23.2 255.255.255.0
 bandwidth 10000
 mpls traffic-eng tunnels
 ip rsvp bandwidth 10000
!
interface FastEthernet 0/0
 ip address 172.16.2.1 255.255.255.0
 ip pim passive
 ip igmp version 3
 ip igmp join-group 232.1.1.1 172.16.1.1
 no shutdown
!
ip mroute 172.16.1.0 mask 255.255.255.0 10.1.1.1

The only special command added here is the static multicast route. It provides RPF information for the multicast sources that will be sending traffic across the M-LSP. Notice that the mroute points toward the respective tunnel source, which is mapped to the automatically created LSPVIF interface.

M-LSP RSVP-TE Scenario Verifications

The following is a list of the steps you may apply to verify the scenario configuration.

Step 1

Verify M-LSP setup and labeling

R1#show mpls traffic-eng tunnels dest-mode p2mp brief 
Signalling Summary:
    LSP Tunnels Process:            running
    Passive LSP Listener:           running
    RSVP Process:                   running
    Forwarding:                     enabled
    auto-tunnel:
	backup Enabled  (3 ), id-range:65436-65535
	onehop Enabled  (3 ), id-range:65336-65435
	mesh   Disabled (0 ), id-range:64336-65335

    Periodic reoptimization:        every 3600 seconds, next in 515 seconds
    Periodic FRR Promotion:         Not Running
    Periodic auto-tunnel:
        primary establish scan:     every 10 seconds, next in 3 seconds
        primary rm active scan:     disabled
        backup notinuse scan:       every 3600 seconds, next in 640 seconds
    Periodic auto-bw collection:    every 300 seconds, next in 215 seconds

P2MP TUNNELS:
                         DEST        CURRENT
INTERFACE   STATE/PROT  UP/CFG     TUNID  LSPID
Tunnel0     up/up       3/3        0      28
Displayed 1 (of 1) P2MP heads

P2MP SUB-LSPS:
SOURCE        TUNID  LSPID  DESTINATION   SUBID  STATE UP IF      DOWN IF
10.1.1.1      0      28     10.1.2.2      1      Up    head       Se2/0.12
10.1.1.1      0      28     10.1.3.3      2      Up    head       Se2/0.12
10.1.1.1      0      28     10.1.4.4      3      Up    head       Se2/0.14
Displayed 3 P2MP sub-LSPs:
          3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails

There are three Sub-LSPs going out of the headed node, toward R2, R3 and R4. You may now check the detailed information including outgoing labels assigned to every Sub-LSP:

R1#show mpls traffic-eng tunnels dest-mode p2mp

P2MP TUNNELS:

Tunnel0     (p2mp),  Admin: up, Oper: up
  Name: R1 TO R2, R3, R4    

  Tunnel0 Destinations Information:

    Destination     State SLSP UpTime
    10.1.2.2        Up    00:51:08
    10.1.3.3        Up    00:51:08
    10.1.4.4        Up    00:51:08   

    Summary: Destinations: 3 [Up: 3, Proceeding: 0, Down: 0 ]
      [destination list name: P2MP_TO_R2_R3_R4_DYN]

  History:
    Tunnel:
      Time since created: 53 minutes, 16 seconds
      Time since path change: 51 minutes, 5 seconds
      Number of LSP IDs (Tun_Instances) used: 28
    Current LSP: [ID: 28]
      Uptime: 51 minutes, 8 seconds
      Selection: reoptimization
    Prior LSP: [ID: 20]
      Removal Trigger: re-route path verification failed

  Tunnel0 LSP Information:
    Configured LSP Parameters:
      Bandwidth: 5000     kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
      Metric Type: TE (default)

  Session Information
    Source: 10.1.1.1, TunID: 0

    LSPs
      ID: 28 (Current), Path-Set ID: 0x90000003
        Sub-LSPs: 3, Up: 3, Proceeding: 0, Down: 0

      Total LSPs: 1

P2MP SUB-LSPS:

 LSP: Source: 10.1.1.1, TunID: 0, LSPID: 28
     P2MP ID: 0, Subgroup Originator: 10.1.1.1
     Name: R1 TO R2, R3, R4
     Bandwidth: 5000, Global Pool

  Sub-LSP to 10.1.2.2, P2MP Subgroup ID: 1, Role: head
    Path-Set ID: 0x90000003
    OutLabel : Serial2/0.12, 19
    Next Hop : 10.1.12.2
    FRR OutLabel : Tunnel65436, 19 
    Explicit Route: 10.1.12.2 10.1.2.2
    Record   Route (Path):  NONE
    Record   Route (Resv): 10.1.2.2(19)

  Sub-LSP to 10.1.3.3, P2MP Subgroup ID: 2, Role: head
    Path-Set ID: 0x90000003
    OutLabel : Serial2/0.12, 19
    Next Hop : 10.1.12.2
    FRR OutLabel : Tunnel65436, 19
    Explicit Route: 10.1.12.2 10.1.23.3 10.1.3.3 
    Record   Route (Path):  NONE
    Record   Route (Resv): 10.1.2.2(19) 10.1.3.3(20)

  Sub-LSP to 10.1.4.4, P2MP Subgroup ID: 3, Role: head
    Path-Set ID: 0x90000003
    OutLabel : Serial2/0.14, 19
    Next Hop : 10.1.14.4
    FRR OutLabel : Tunnel65437, 19
    Explicit Route: 10.1.14.4 10.1.4.4 
    Record   Route (Path):  NONE
    Record   Route (Resv): 10.1.4.4(19)

In the output above notice that that Sub-LSPs to R2 and R3 share the same label and outgoing interface, meaning that R1 has merged the two Sub-LSPs. The output also shows that every Sub-LSP is protected by means of FRR NHOP tunnel. You may notice explicit paths for every Sub-LSP that have been calculated at the headed based on the area topology and constrains. Next, check the multicast routing table at R1 to make sure the M-LSP is used as an outgoing interface for multicast traffic.

R1#show ip mroute 232.1.1.1 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

 (172.16.1.1, 232.1.1.1), 00:59:57/stopped, flags: sTI
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 00:58:17/00:01:42

R1#show ip mfib 232.1.1.1
Entry Flags:    C - Directly Connected, S - Signal, IA - Inherit A flag,
                ET - Data Rate Exceeds Threshold, K - Keepalive
                DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
                NS - Negate Signalling, SP - Signal Present,
                A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts:      Total/RPF failed/Other drops
I/O Item Counts:   FS Pkt Count/PS Pkt Count
Default
  (172.16.1.1,232.1.1.1) Flags:
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   FastEthernet0/0 Flags: A
   Tunnel0 Flags: F NS
     Pkts: 0/0

Step 2

Look at R2, which is a bud router in this scenario. It acts an a middle-point for the Sub-LSP from R1 to R2 and tail-end for the Sub-LSP to R2. The output below demonstrates this behavior:

R2#show mpls traffic-eng tunnels dest-mode p2mp 

P2MP TUNNELS:

P2MP SUB-LSPS:

 LSP: Source: 10.1.1.1, TunID: 0, LSPID: 28
     P2MP ID: 0, Subgroup Originator: 10.1.1.1
     Name: R1 TO R2, R3, R4
     Bandwidth: 5000, Global Pool

  Sub-LSP to 10.1.2.2, P2MP Subgroup ID: 1, Role: tail
    Path-Set ID: 0x8000003
    InLabel  : Serial2/0.12, 19
    Prev Hop : 10.1.12.1
    OutLabel :  -
    Explicit Route:  NONE
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 10.1.3.3, P2MP Subgroup ID: 2, Role: midpoint
    Path-Set ID: 0x8000003
    InLabel  : Serial2/0.12, 19
    Prev Hop : 10.1.12.1
    OutLabel : Serial2/0.23, 20
    Next Hop : 10.1.23.3
    FRR OutLabel : Tunnel65437, 20
    Explicit Route: 10.1.23.3 10.1.3.3
    Record   Route (Path):  NONE
    Record   Route (Resv): 10.1.3.3(20)

The output shows that Sub-LSP to R2 terminates locally and the Sub-LSP to R3 is label switched using the incoming label 19 and outgoing label 20. This ensures that incoming packets are decapsulated locally and label-switched in parallel. The output below demonstrates that the source 172.16.1.1 is seen on R2 as being connected to LSPVIF0 by the virtue of static multicast route configured. The received packets are replicated out of the connected FastEthernet interface.

R2#show ip mroute 232.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

 (172.16.1.1, 232.1.1.1), 01:08:31/00:02:37, flags: sLTI
  Incoming interface: Lspvif0, RPF nbr 10.1.1.1, Mroute
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 01:08:29/00:02:37

R2#show ip mfib 232.1.1.1
Entry Flags:    C - Directly Connected, S - Signal, IA - Inherit A flag,
                ET - Data Rate Exceeds Threshold, K - Keepalive
                DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
                NS - Negate Signalling, SP - Signal Present,
                A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts:      Total/RPF failed/Other drops
I/O Item Counts:   FS Pkt Count/PS Pkt Count
Default
 (172.16.1.1,232.1.1.1) Flags:
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   Lspvif0, LSM/0 Flags: A
   FastEthernet0/0 Flags: F IC NS
     Pkts: 0/0

Step 3

Now it’s time to run a real test. We need a source connected to R1, as if we source process-switched ICMP packets off R1 they will not be MPLS encapsulated. This seems to be a behavior of the newly implemented MFIB-based multicast switching. Notice that the source uses the IP address of 172.16.1.1 for proper SSM multicast flooding:

R7#ping 232.1.1.1 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:

Reply to request 0 from 172.16.4.1, 80 ms
Reply to request 0 from 172.16.3.1, 108 ms
Reply to request 1 from 172.16.4.1, 32 ms
Reply to request 1 from 172.16.3.1, 44 ms
Reply to request 1 from 172.16.2.1, 40 ms

If you enable the following debugging on R2 prior to running the pings, you will see the output similar to the one below:

R2#debug ip mfib ps
MFIB IPv4 ps debugging enabled for default IPv4 table

R2#debug mpls packet 
Packet debugging is on

MPLS turbo: Se2/0.12: rx: Len 108 Stack {19 0 254} - ipv4 data
MPLS les: Se2/0.12: rx: Len 108 Stack {19 0 254} - ipv4 data
MPLS les: Se2/0.23: tx: Len 108 Stack {20 0 253} - ipv4 data
MFIBv4(0x0): Receive (172.16.1.1,232.1.1.1) from Lspvif0 (FS): hlen 5 prot 1 len 100 ttl 253 frag 0x0 
FIBfwd-proc: Default:224.0.0.0/4 multicast entry
FIBipv4-packet-proc: packet routing failed

Per the output above, the packet labeled with label 19 is received and switched out with the label 20, which is in accordance with the output we saw when checking the M-LSP tunnel. Also, you can see MFIB output demonstrating that a multicast packet was received out of LSPVIF interface. The forwarding fails as there are no outgoing encapsulation entries, but the router itself responds to the ICMP echo packet.

Summary

We reviewed the concept of M-LSP – how it evolved from the tag-switched multicast to a generic technology suitable to transport of multipoint traffic flows, not limited to multicast only. We briefly outlined the two main signaling methods for establishing M-LSPs – the multipoint LDP and the RSVP-TE extensions for P2MP LSPs. Both approaches have their benefits and drawbacks, but only the RSVP-TE method has been widely deployed so far and recently offered to public by Cisco. Both methods are still evolving toward the support of broader application sets, such as multicast VPNs and VPLS.

Further Reading

A lot of documents have been mentioned in the document itself. They are now summarized below along with some additional reading.

Tag Switching Architecture Overview (Historical)
Partitioning Tag Space among Multicast Routers on a Common Subnet (Historical)
Multipoint Signaling Extensions to LDP
MPLS Upstream Label Assignment and Context Specific Label Space
Multicast Multipath
Multicasting in VPLS
RFC4875 RSVP-TE Extensions for P2MP LSPS
MPLS TE Auto-Tunnels
MPLS Point-to-Multipoint Traffic Engineering
Using Multipoint LSPs for IP-TV Deployments
Inter-AS mVPNs: MDT SAFI, BGP Connector & RPF Proxy Vector

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

19 Responses to “The Long Road to M-LSPs”

 
  1. Hassan B. says:

    Perfect as usual Petr , Thanks

  2. Maher, CCIE #21032 says:

    Really WOW!

  3. anonymous says:

    I couldn’t understand anything, but it looks awesome :D

  4. kim says:

    It looks complex and need some time to digest. thanks.

  5. Rodrigo says:

    Very clarifying article about M-LSP.
    Thanks!

  6. Hans says:

    There is more fun to explore with 12.2SRE. I just managed to setup a network (dynamips) with two PE routers running mVPN over MPLS (m(?)p-to-mp using mLDP), so without using PIM routing in the core.

    When I was short testing your setup I noticed mLDP commands were available (mpls mldp …) so I decided to try setup a simple network using two PE’s and two CE’s. It took me hour or so, because I could not find any config guide on CCO.

    CE1 — PE1 — PE2 — CE2

    It seems that there is no BGP signalling available in combination with SSM, compared to draft Rosen.

    Here is config from one PE. Config from other is simular. I’ll spend more time next week to discover (reverse engineer) the understanding of the mLDP solution.

    Best regards,
    Hans

    !
    hostname PE1
    !
    interface Loopback0
    ip address 1.1.1.1 255.255.255.255
    !
    ip vrf test
    rd 1:1
    vpn id 111:1111
    route-target export 1:1
    route-target import 1:1
    mdt default mpls mldp 1.1.1.1
    mdt default mpls mldp 2.2.2.2
    !

    ip multicast-routing vrf test
    !!! beware no global mcast routing!
    !

    interface FastEthernet0/0
    description *** to CE1 ***
    ip vrf forwarding test
    ip address 10.10.10.2 255.255.255.0
    ip pim sparse-mode
    duplex half
    !
    interface FastEthernet1/0
    description *** to PE2 ***
    ip address 12.12.12.1 255.255.255.0
    ip ospf network point-to-point
    duplex full
    !
    !
    router ospf 1
    log-adjacency-changes
    network 0.0.0.0 255.255.255.255 area 0
    mpls ldp autoconfig area 0
    !
    router bgp 1
    no bgp default ipv4-unicast
    bgp log-neighbor-changes
    neighbor 2.2.2.2 remote-as 1
    neighbor 2.2.2.2 update-source Loopback0
    !
    address-family ipv4
    no synchronization
    no auto-summary
    exit-address-family
    !
    address-family vpnv4
    neighbor 2.2.2.2 activate
    neighbor 2.2.2.2 send-community extended
    exit-address-family
    !
    address-family ipv4 vrf test
    no synchronization
    redistribute connected
    exit-address-family
    !
    ##########
    On CE1 (connected to PE1) I configured static IGMP join to 239.2.2.2 and RP/BSR router, so on CE2 (connected to PE2) I should be able to ping this group add.

    ###

    PE1#sh ip mroute
    IP Multicast Forwarding is not enabled.
    IP Multicast Routing Table

    PE1#sh ip pim vrf test neighbor
    PIM Neighbor Table
    Mode: B – Bidir Capable, DR – Designated Router, N – Default DR Priority,
    P – Proxy Capable, S – State Refresh Capable, G – GenID Capable
    Neighbor Interface Uptime/Expires Ver DR
    Address Prio/Mode
    2.2.2.2 Lspvif0 00:17:29/00:01:30 v2 1 / DR S P G
    10.10.10.1 FastEthernet0/0 01:11:14/00:01:18 v2 1 / S P G
    !
    !
    PE1#sh ip mroute vrf test
    IP Multicast Routing Table
    Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
    L – Local, P – Pruned, R – RP-bit set, F – Register flag,
    T – SPT-bit set, J – Join SPT, M – MSDP created entry, E – Extranet,
    X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
    U – URD, I – Received Source Specific Host Report,
    Z – Multicast Tunnel, z – MDT-data group sender,
    Y – Joined MDT-data group, y – Sending to MDT-data group,
    V – RD & Vector, v – Vector
    Outgoing interface flags: H – Hardware switched, A – Assert winner
    Timers: Uptime/Expires
    Interface state: Interface, Next-Hop or VCD, State/Mode

    (*, 239.2.2.2), 01:04:56/stopped, RP 10.10.10.1, flags: SJPC
    Incoming interface: FastEthernet0/0, RPF nbr 10.10.10.1
    Outgoing interface list: Null

    (10.10.20.2, 239.2.2.2), 00:00:51/00:02:38, flags: T
    Incoming interface: Lspvif0, RPF nbr 2.2.2.2
    Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:00:51/00:02:38, A

    (*, 224.0.1.40), 02:17:23/00:02:01, RP 0.0.0.0, flags: DCL
    Incoming interface: Null, RPF nbr 0.0.0.0
    Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 01:14:26/00:02:01

    ####

    CE2#sh ip pim rp mapping
    PIM Group-to-RP Mappings

    Group(s) 224.0.0.0/4
    RP 10.10.10.1 (?), v2
    Info source: 10.10.10.1 (?), via bootstrap, priority 0, holdtime 150
    Uptime: 01:07:03, expires: 00:02:16

    CE2#ping 239.2.2.2

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:

    Reply to request 0 from 10.10.10.1, 28 ms

    • @Hans,

      this is absolutely cool, I’ll come up with a detailed blog post on M-LDP signaled mVPN and definitely citing you as my point of inspiration! :) I’m really pleased to see that they now have the option to route M-LSPs over MPLS-TE, thus enabling a bunch of powerful features! I guess this is enabled as a result of ordered label allocation for M-LSPs.

  7. [...] OTV Patent Paper RBridges Draft Document SEATTLE Technology VPLS using LDP Signaling VPLS using BGP Signaling Multicasting in VPLS Multicast VPNs using Draft Rosen Introduction to M-LSPs and Practical Examples [...]

  8. Zeus says:

    Petr,

    When you are posting M-LDP signaled mVPN blog? I am anxiously waiting for it.

    thanks dude…you are awesome…

  9. [...] of M-LDP. For introduction to M-LSPs, the following blog post provides some introductory reading: The long road to M-LSPs. The terminology used in this article follows the common convention of using the “P-” [...]

  10. Peter Koltl, CCIE #10192 says:

    This feature is available in 12.2(33)SRE.

  11. [...] The Long Road to M-LSPs [...]

  12. Hudson says:

    I just found this posting but in order to know what is being said, I had to study the RFC…nonetheless, I will try it out live shortly. I also noticed it is in the new SP lab…including Multicast Only FRR.

  13. Del says:

    Petr, you are a machine.

  14. Amit says:

    Hi Petr,
    On which interfaces are you configuring the join-group command on the receivers (R4, R2, R3) for P2MP TE setup?

    I tried labbing up your P2MP TE setup, and everything got working, except I am not able to get the ping working. Even though, I see the traffic reaching the Receivers (R4, R2, R3 verified using debug mpls packet), the ping doesn’t seem to work.

    I am using 15.1 code.

    I realized few things too:
    ip multicast mpls traffic-eng, mpls traffic-eng multicast-intact only needs to be configured on the receivers (and not the midpoint/source)

  15. John CG says:

    Love this post because you said “Virtual Circuit” to signify the unicast MPLS’s purpose and limitation in the “Multipoint LSP Overview” section.

    Many people can’t correctly distinguish the word tunnel from virtual circuit after studying too much into it. Tunnel is dug under a pile of dirt and it works in an isolated way. Circuit is maintained and controlled every step of the way.

  16. John CG says:

    Hi Petr,
    Can you provide an architectural view to compare running PIM in the service provider core versus pure switching M-LSP?
    When I look at cisco’s strategy of small support for purely switched M-LSP, namely omitted inter-AS support, I can see that PIM in the service provider enforces the routing functionality for tighter address space control; pure switching loosens the control and theoretically scales up.
    How large the scalability is the best? Networking is the art of dividing and combining information. If MPLS-VPN was scaled as the public Internet, and the Internet were to become a huge switch to make VPNs and not route any traffic, the public does not benefit from the all-things-private internet. That Internet would have become the dial up telephone network.
    The problem is how to fragment/compartment information for our advantage. Combine many things to make the Internet benefit many people, us included. Combining too many things may be detrimental for networkers, and that will, in turn, cost the greater cause.

    John

  17. John CG says:

    I understand that RP sparse mode with MSDP is the largest scalability, even though it is not the most public Internet. There is a difference between largest scale and the public Internet. SSM is not for the largest scale. But I don’t know if the pure-switching M-LSP is aimed at the largest scalability or the public Internet. If it can’t reach its target, whether scale or public , I can’t figure out what is missing. You may say that adding RPs into the core solves the dilemma, but as soon as you add RPs into the core, it is not pure-switching any more.

 

Leave a Reply

Categories

CCIE Bloggers