Protocols We Care About:
- PIM (Spare/Bidir)
- How neighbors are formed and maintained
- How the best path is calculated
- How aggregation is configured and deployed
- How external routing information is handled
- How protocols interact
The original method of switch multicast over MPLS core is called mVPN, or the Rosen draft.
The following article gives a very clear and concise description of how it works:
There are two trees in MVPN:
- Default Tree
- is used for customer Control Plane and low rate Data Plane traffic
- created by default, all PEs that run multicast VRF are part of the tree
- can use SM and SSM, SSM is preferred because without RP, it is simplier to deploy and maintain
- Data MDT
- created dynamically when there is active multicast source and listeners
- only PEs with active source or listen will join the tree
- customer traffic initially run on the default tree, when the traffic crossed over the configured threshold, a data MDT is built.
- SP core does not need any code support for mVPN, the core routers only need to support regular PIM multicast protocols
- SP core is scalable before it does not need to keep multicast states for customers. Instead, all multicast groups for each customer is configure one multicast group in the SP core. This is archive by encapsulating customers’ multicast traffic in point to multipoint GRE tunnel between PE (or Multipoint to multipoint GRE tunnels if BiDir-PIM is used in the SP network)
- customer can keep their multicast design without making any changes. They can keep their RP if running PIM-SM.
- customer can use any multicast groups as usual, because the customer multicast groups are hidden from the SP core.
- customer multicast traffic is not label switched, the multicast packets are routed using regular IP multicast tunnel in GRE.
- SP NOC need to look at Multicast RIB and FIB to troubleshoot multicast issue, and look at LFIB to troubleshoot unicast issue.
The following protocols supports IPv6 multicast:
The following protocols do not support IPv6 multicast:
Choose PIM-SSM when:
- You have few multicast sources. More sources mean more routers CPU and Memory requirement. In that case, use Any-Source Multicast
- When you want optimum routing from source to listeners
- When you want a simpler multicast network to manage, because SSM does NOT need RP, which has management overhead
- When you run IPv6 and want to have multicast between Service Providers. Because there is not way to share RP info for IPv6 between multicast domains
- When your hosts and edge routers suport MLDv2 for IPv6 and IGMPv3 for IPv4. If these protocols are not supported, static Source to Group mapping need to be defined manually on each edge router, or using DNS
- There are two models:
- Any Source Multicast (ASM)
- Source Specific Multicast (SSM)
- What is ASM?
- It requires RP
- It uses SPT between Source and RP, and ST between listeners and RP on the initial connection setup but could switch to SPT if the SPT is a more efficient path.
- The PIM model to use is PIM-SM
- What is SSM?
- It does NOT use RP
- It uses SPT (S,G) between listeners and Sources
- The PIM model is PIM-SSM
- When to use ASM?
- When you have distributed Sources, like an enterprise network with multiple DCs and multicast sources in all these DCs
- When to use SSM?
- When you have few sources, like a SP network with a centralized content streaming servers
- When you have more then one PIM domains, because there is no mechanism to exchange RP information between domains for IPv6
- When you do not want to manage RP
- MSDP is used to exchange multicast source addresses between PIM domains. It is a IPv4 only solution. IPv6 solution is being developed.
- Bootstrap router (BSR) provides dynamic distribution of RP-to-group mapping information across a PIM domain. A set of routers is configured as candidate BSRs. Each of them sends bootstrap messages (BSMs) that are flooded throughout the domain. The messages contain a Priority field. If a candidate BSR receives a BSM from another candidate with a higher priority, it stops sending BSMs for a given period of time. Through this election process, a single BSR is left flooding the domain with BSMs and thus providing the RP-to-group mapping information.