Posts Tagged ‘multicast vpn’
This blog post provides example M-VPN configuration using out-of-band mapping of C-multicast groups to core M-LSP tunnels signaled via M-LDP. A reader is assumed to have solid knowledge of M-VPNs and understanding of M-LDP. For people unfamiliar with M-LDP, 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-” prefix for provider specific objects (e.g. multicas routes or tunnels) and using the “C-” prefix for the customer objects (e.g. private IP addresses). Before we begin, I would like to thank our reader Hans Verkerk who pointed me the fact that Cisco IOS does support M-LDP in the latest 12.2SR images.
Interworking M-LDP with PIM: In-Band and Out-of-Band
To recap, M-LDP allows for construction of P2MP (point-to-multipoint) and MP2MP (multipoint-to-multipoint) LSPs. Every LSP is identified by a tuple
One of the most prominent applications of M-LSPs is effective multicast traffic encapsulation in MPLS networks. Since M-LSPs are signaled using M-LDP and multicast trees use PIM the problem is mapping multicast trees to M-LSPs. It is intuitively obvious that shortest path trees could be mapped to P2MP LSPs and shared trees correspond to MP2MP LSPs. There are two approaches to implement such mapping: the first uses in-band signaling, where PIM messages are directly translated into M-LDP FEC bindings, and the second approach uses out-of-band mapping, e.g. based on manual configuration.
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
Inter-AS Multicast VPN solution introduces some challenges in cases where peering systems implement BGP-free core. This post illustrates a known solution to this problem, implemented in Cisco IOS software. The solution involves the use of special MP-BGP and PIM extensions. The reader is assumed to have understanding of basic Cisco’s mVPN implementation, PIM-protocol and Multi-Protocol BGP extensions.
mVPN – Multicast VPN
MSDP – Multicast Source Discovery Protocol
PE – Provider Edge
CE – Customer Edge
RPF – Reverse Path Forwarding
MP-BGP – Multi-Protocol BGP
PIM – Protocol Independent Multicast
PIM SM – PIM Sparse Mode
PIM SSM – PIM Source Specific Multicast
LDP – Label Distribution Protocol
MDT – Multicast Distribution Tree
P-PIM – Provider Facing PIM Instance
C-PIM – Customer Facing PIM Instance
NLRI – Network Layer Rechability Information