Protocol Independent Multicast (PIM)
PIM leverages the unicast routing protocols such as OSPF, IS-IS, BGP, and static routes to create the unicast routing table. Since PIM relies on unicast routing information to carry out the multicast forwarding function, it is effectively IP protocol independent. Unlike DVMRP, PIM does not send multicast routing table updates to its neighbors.
- PIM-SM (ASM model) on default and non-default network instances for both IPv4 and IPv6
- PIM-SM (SSM model) on default and non-default network instances for both IPv4 and IPv6
- PIM policy - IPv4 and IPv6
The logical path taken through the network from the source to multiple receivers is called the multicast distribution tree (MDT).
PIM has two modes of operation - Dense and Sparse mode
In PIM dense mode, the type of MDT used is called the source tree. The root of the tree is the source device, and data flows from the root (source) to the leaves through branches. This tree is also known as the shortest-path tree (SPT).
PIM sparse mode (PIM-SM) uses two types of multicast trees: the shared tree and the source tree.
The ASM mode of operation relies on the concept of a rendezvous point (RP), which is the
point in the network where the source and receivers meet to establish the multicast
flow. The shared tree is a tree rooted at the RP. Multicast transmission starts with the
source sending packets to the RP and from there on, the shared tree to the receivers.
ASM is represented by (*,G) notation. The * (wildcard)
indicates that the multicast group can receive traffic from any source, and
G represents the multicast group address.
In the
SSM
mode of operation, the RP is omitted, and the source tree is established directly. SSM
is represented by (S,G) notation. The S indicates that
the multicast group receives traffic from a specific source, and G
represents the multicast group address.
PIM Sparse mode (PIM-SM)
PIM-SM only forwards data to network segments with active receivers that have explicitly requested the multicast group. PIM-SM uses the unicast routing table to perform the Reverse Path Forwarding (RPF) check function instead of building up a completely independent multicast routing table.
Depending on the configuration options, the traffic can remain on the shared tree or switch over to an optimized source distribution tree. As multicast traffic starts to flow down the shared tree, routers along the path determine if there is a better path to the source. If a more direct path exists, then the router closest to the receiver sends a join message toward the source and then reroutes the traffic along this path.
As stated above, PIM-SM relies on an underlying topology-gathering protocol to populate a routing table with routes. This routing table is called the Multicast Routing Information Base (MRIB). The routes in this table can be taken directly from the unicast routing table, or they can be different and provided by a separate routing protocol such as Multiprotocol BGP (MBGP) which is used for Next Generation Multicast VPN (NG-MVPN). Regardless of how it is created, the primary role of the MRIB in the PIM-SM protocol is to provide the next hop router along a multicast-capable path to each destination subnet. The MRIB is used to determine the next hop neighbor to whom any PIM join/prune message is sent. Data flows along the reverse path of the join messages. Thus, in contrast to the unicast RIB that specifies the next hop that a data packet would take to get to some subnet, the MRIB gives reverse-path information and indicates the path that a multicast data packet would take from its origin subnet to the router that has the MRIB.
For the PIM protocol to function correctly, multicast signaling (PIM ) packets need to be received by the CPM CPU. Therefore, CPM filters and management access filters must be configured to allow forwarding of PIM packets. PIM signaling needs to signal the specific <S, G> from the host to RP or the source of the tree. Using policies, specific <S, G>s can be disallowed to join the tree. If a <S, G> is disallowed to join the tree, any multicast stream from that <S, G> is dropped on the datapath.
PIM-SM functions
PIM-SM functions have three phases.
Phase one
In this phase, a multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically, it does this using IGMP, but other mechanisms may also serve this purpose. One of the local routers of the receiver is elected as the Designated Router (DR) for that subnet. When the expression of interest is received, the DR sends a PIM join message toward the Rendezvous Point (RP) for that multicast group. This join message is known as a (*, G) join because it joins group G for all sources to that group. The (*, G) join travels hop-by-hop toward the RP for the group, and in each router it passes through, the multicast tree state for group G is instantiated.
Eventually, the (*, G) join either reaches the RP or reaches a router that already has the (*, G) join state for that group. When many receivers join the group, their join messages converge on the RP and form a distribution tree for group G that is rooted at the RP. The distribution tree is called the RP tree or the shared tree because it is shared by all sources transmitting to the same multicast group. Join messages are re-sent periodically as long as the receiver remains in the group. When all receivers on a leaf network leave the group, the DR sends a PIM (*, G) prune message toward the RP for that multicast group. However, if the prune message is not sent for any reason, the state eventually times out.
A multicast data sender starts sending data destined for a multicast group. The local router of the sender (the DR) takes these data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, removes the encapsulation, and forwards them to the shared tree. The packets then follow the (*, G) multicast tree state in the routers on the RP tree, and are replicated wherever the RP tree branches, and eventually reach all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM register packets.
At the end of phase one, multicast traffic flows encapsulated to the RP and then natively over the RP tree to the multicast receivers.
Phase two
In this phase, register-encapsulation of data packets is performed. However, register-encapsulation of data packets is inefficient for the following reasons:
-
Encapsulation and de-encapsulation can be resource-intensive operations for a router to perform, depending on whether the router has appropriate hardware for the tasks.
-
Traveling to the RP and then back down the shared tree can cause the packets to travel a relatively long distance to reach receivers that are close to the sender. For some applications, increased latency is unwanted.
Although register-encapsulation can continue indefinitely, for the previous reasons, the RP normally switches to native forwarding. To do this, when the RP receives a register-encapsulated data packet from source S on group G, it normally initiates an (S, G) source-specific join toward S. This join message travels hop-by-hop toward S, instantiating an (S, G) multicast tree state in the routers along the path.
The (S, G) multicast tree state is used only to forward packets for group G if those packets come from source S. Eventually, the join message reaches the S subnet or a router that already has the (S, G) multicast tree state, and packets from S start to flow following the (S, G) tree state toward the RP. These data packets can also reach routers with a (*, G) state along the path toward the RP, and if this occurs, they take a shortcut to the RP tree at this point.
While the RP is in the process of joining the source-specific tree for S, the data packets continue being encapsulated and sent to the RP. When packets from S also start to arrive natively at the RP, the RP receives two copies of each of these packets. At this point, the RP starts to discard the encapsulated copy of these packets and sends a register-stop message back to the DR of S to prevent the DR from unnecessarily encapsulating the packets. At the end of phase two, traffic is flowing natively from S along a source-specific tree to the RP and from there along the shared tree to the receivers. Where the two trees intersect, traffic can transfer from the shared RP tree to the shorter source tree.
A sender can start sending before or after a receiver joins the group; therefore, phase two may occur before the shared tree to the receiver is built.
Phase 3
In this phase, the RP joins back toward the source using the shortest path tree (SPT). Although having the RP join back toward the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. For many receivers, the route via the RP can involve a significant detour when compared with the shortest path from the source to the receiver.
To obtain lower latencies, a router on the LAN of the receiver, typically the DR, may optionally initiate a transfer from the shared tree to a source-specific SPT. To do this, it issues an (S, G) join toward S. This instantiates the (S, G) state in the routers along the path to S. Eventually, this join either reaches the S subnet or reaches a router that already has the (S, G) state. When this happens, data packets from S flow following the (S, G) state until they reach the receiver.
At this point, the receiver (or a router upstream of the receiver) receives two copies of the data—one from the SPT and one from the RP tree. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree. In addition, it sends an (S, G) prune message toward the RP. The prune message travels hop-by-hop, instantiating an (S, G) state along the path toward the RP, indicating that traffic from S for G should not be forwarded in this direction. The prune message is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers.
By now, the receiver is receiving traffic from S along the SPT between the receiver and S. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree. As far as the receiver is concerned, this is the final distribution tree.
Differences between PIM-SM in ASM and SSM models
| Features | PIM-SM in ASM model | PIM-SM in SSM model |
|---|---|---|
| Source discovery | Uses RP for source discovery | Does not require source discovery and only supports a single source for a specific multicast stream |
| Rendezvous Point (RP) | Requires an RP for initial traffic distribution and source discovery | Does not require RP. The traffic is source-specific |
| Join process | Receivers join a multicast group and expect traffic from any source | Receivers join a multicast group and specify the source they want to receive traffic from |
| Traffic distribution | Initially uses the RP to forward traffic, then switches to the SPT | Directly uses the SPT from the start without using an RP |
Encapsulating data packets in the register tunnel
Conceptually, the register tunnel is an interface with a smaller Maximum Transmission Unit (MTU) than the underlying IP interface toward the RP. IP fragmentation on packets forwarded on the register tunnel is performed based on this smaller MTU. The encapsulating DR can perform path-MTU discovery to the RP to determine the effective MTU of the tunnel. This smaller MTU considers both the outer IP header and the PIM register header overhead.
PIM-SM routing policies
Multicast traffic can be restricted from specific source addresses by creating routing policies.
-
multicast group address embedded in the join and prune message
-
multicast source address embedded in the join and prune message
- multicast group address embedded in the register message
- multicast source address embedded in the register message
When a multicast policy is applied to IGMP, MLD, or PIM using the command
routing-policy+ policy* [name] statement** [name] match multicast
<group-address,source-address>, the multicast parameters in the policy
statement are compared to the source and group (S, G) or (*, G) in the incoming join or
prune messages for the protocol. If a match is found, the join or prune message is
accepted or denied based on the policy action. The same policy can be applied to
multiple protocols.
RPF checks
Multicast implements a Reverse Path Forwarding (RPF) check. RPF checks the path that multicast packets take between their sources and the destinations to prevent loops. Multicast requires that an incoming interface be the outgoing interface used by unicast routing to reach the source of the multicast packet. RPF forwards a multicast packet only if it is received on an interface that is used by the router to route to the source.
If the forwarding paths are modified because of routing topology changes, any dynamic filters that may have been applied must be re-evaluated. If filters are removed, the associated alarms are also cleared.
Distributing PIM joins over multiple ECMP paths
The per bandwidth or round-robin method is commonly used for multicast load-balancing. However, the interface in an ECMP set can also be used for a specific channel to be predictable without knowledge of other channels that use the ECMP set.
When a link in the ECMP set is removed, multicast streams that use this link are
redistributed over the remaining ECMP links using the same hash algorithm. When a link
is added to the ECMP set, new joins may be allocated to the new link based on the hash
algorithm. Existing multicast streams using the other ECMP links stay on those links
until they are pruned, unless the rebalance parameter under
network-instance* [name] protocols pim!+ ecmp-hashing! context is
enabled.
The default is not enabled, which means that the use of multiple ECMP paths is controlled
through the existing implementation and the enabling of ecmp-balance
option under network-instance* [name] protocols pim!+ context.
You cannot enable the ecmp-balance option when the MC ECMP hashing
option ecmp-hashing is configured in the same context.
To achieve distribution of streams across the ECMP links, the hashing steps are as follows:
-
For a specific (S,G) get all possible next hops.
-
Sort these next hops based on next hop address.
-
XOR S and G addresses.
-
Hash the XORed address over the number of PIM next hops.
-
Use the hash value obtained in step 4, and set that element in the sorted list that was obtained in step 2 as the preferred next hop
-
If this element is not available or is not a PIM next hop (PIM neighbor), choose the next available next hop.
IPv6 PIM models
IPv6 multicast enables multicast applications over native IPv6 networks.
- Any Source Multicast (ASM)
- Source Specific Multicast (ASM)
These models work in conjunction with PIM-SM and MLD to delivery multicast in IPv6 network.SSM does not require source discovery and only supports single source for a specific multicast stream. As a result, SSM is easier to operate in a large scale deployment that uses the one-to-many service model.
PIM SSM
The SSM model supports the IPv6 address family and allows for selecting the Routing Table Manager (RTM), whether unicast RTM, multicast RTM, or both. OSPFv3, IS-IS, and static routes have extensions that enable route submissions to the IPv6 multicast RTM.
PIM ASM
The ASM model supports the IPv6 address family. All PIM ASM-related functions, such as RP and SPT, support IPv4 and IPv6 address-families.
Basic PIM configuration
The PIM protocol is operational after at least one interface is assigned. After an interface is enabled for PIM, it is known as a PIM interface. When created, the PIM interface can be configured with PIM parameters in addition to the standard parameters for the interface. When PIM is operational, data is forwarded to network segments with active host receivers that have explicitly requested the multicast group.
-
Enable PIM (required)
-
Add interfaces so the protocol establishes adjacencies with the neighboring routers (required)
-
Configure a way to calculate group-to-RP mapping (required) by static group-to-RP mapping
-
Enable unicast routing protocols to learn routes toward the RP/source for reverse path forwarding (required)
-
Add SSM ranges (optional)
-
Change hello interval (optional)
-
Configure route policies
Configuring IPv4 PIM-SM in the ASM model
In PIM-ASM, routers forward multicast traffic only to the receivers that explicitly request it via an RP. Receivers use IGMPv1 or IGMPv2 to join a multicast group without specifying the source. The RP initially forwards the multicast traffic from any source to the receivers through a Shared Tree (RPT). Later, the network may switch to a Source-Specific Tree (SPT).
Configuring PIM-SM with static RP using the ASM model
The following configuration enables PIM on interface ethernet-1/1.1 and defines a static RP with the IP address 10.10.10.1. The RP manages the multicast traffic for the groups with the prefixes 239.24.24.24/32 and 239.24.28.24/32.
--{ + candidate shared default }--[ ]--
# info network-instance srl_test_instance protocols pim
network-instance srl_test_instance {
protocols {
pim {
interface ethernet-1/1.1 {
admin-state enable
}
rendezvous-points {
static {
rendezvous-point 10.10.10.1 {
group 239.24.24.24/32 {
}
group 239.24.28.24/32 {
}
}
}
}
}
}
}Configuring IPv4 PIM-SM in the SSM model
In PIM-SM, routers forward multicast traffic only to the receivers that explicitly request it through SSM group membership using IGMPv3. In this model, the receivers specify both the multicast group and the source they want to receive traffic from; therefore, no RP is needed. The source address is included in the IGMP report messages that are passed to PIM routers as PIM join messages. The multicast traffic is directly delivered from the specified source to the receivers using a source-specific tree (SPT).
Configuring PIM-SM using the SSM model
The following configuration enables PIM on interface ethernet-1/1.1 and uses IGMPv3 to manage multicast group memberships. The SSM group address range is, by default, 232.0.0.0/8.
--{ + candidate shared default }--[ ]--
#info network-instance srl_test_instance protocols pim ssm
network-instance srl_test_instance {
protocols {
pim {
ssm {
ssm-ranges {
group-range 233.0.0.0/8 {
}
}
}
}
}Configuring IPv6 PIM-SM in the ASM model
The following configuration enables PIM on interface ethernet-1/1.1 and defines a static RP with the IP address 2001:db8:1:1::1. The RP manages the multicast traffic for the group with the prefix ff05::/16.
--{ + candidate shared default }--[ ]--
# info network-instance srl_ipv6_test_instance protocols pim
network-instance srl_ipv6_test_instance {
protocols {
pim {
interface ethernet-1/1.1 {
admin-state enable
}
rendezvous-points {
static {
rendezvous-point 2001:db8:1:1::1 {
group ff05::/16 {
}
}
}
}
}
}
}Configuring IPv6 PIM-SM in the SSM model
The following configuration enables PIM on interface ethernet-1/1.1 and uses IGMPv3 to manage multicast group memberships. By default, the SSM group address range is FF3E::/32.
--{ + candidate shared default }--[ ]--
#info network-instance srl_test_instance protocols pim ssm
network-instance srl_test_instance {
protocols {
pim {
ssm {
ssm-ranges {
group-range ff3e:1:0:0::/64 {
}
}
}
}
}Configuring PIM hello messages
hello-interval) to adjust the frequency of the
hello message. The hold-time specifies how long the router should
maintain information about a neighbor after receiving its PIM hello messageWhen a router receives a PIM hello message, it stores the neighbor's IP address and DR priority. A designated router (DR) election is performed on all multi-access networks. The DR is the device with the highest configured DR priority on the broadcast domain. If priorities are equal, the DR is the device with the highest IP address on the broadcast domain.
In the following configuration example, the PIM hello-interval and
hello-multiplier are set to 65, defining how often hello
messages are sent and their expiration time.
--{ + candidate shared default }--[ ]--
#info network-instance default_nw_instance protocols pim
network-instance default_nw_instance {
protocols {
pim {
admin-state enable
interface ethernet-1/1.1 {
hello-interval 65
hello-multiplier 65
}
rendezvous-points {
static {
rendezvous-point 10.10.10.1 {
group 239.24.24.24/32 {
}
}
}
}
}
}
}Configuring PIM join policies
Configuring PIM join policies establishes a routing policy that enables the router to manage multicast traffic effectively by allowing only specific combinations of source and group addresses. Before configuring a multicast routing policy, you must configure prefix sets for the group and source addresses.
Configuring prefix set for group address
The following configuration example defines a group prefix
(srl_group_prefix-set) that can be used as a matched
against group-address configured in the policy statement
(allow-group).
--{ * candidate shared default }--[ ]--
#info routing-policy prefix-set srl_group_prefix-set
routing-policy {
prefix-set srl_group_prefix-set {
prefix 226.0.2.0/24 mask-length-range 21..24 {
}
}
}Configuring prefix set for source address
The following configuration example defines a group prefix
(srl_source_prefix-set) that can be used as a matched
against source-address configured in the policy statement
(allow-source).
--{ * candidate shared default }--[ ]--
#info routing-policy prefix-set srl_source_prefix-set
routing-policy {
prefix-set srl_source_prefix-set {
prefix 192.0.2.0/25 mask-length-range 21..25 {
}
}
}Configuring multicast routing policy
In the following configuration example, the policy (multicast_new_policy) allows traffic that matches the specified group and source prefixes.
--{ * candidate shared default }--[ ]--
info routing-policy policy multicast_new_policy
routing-policy {
policy multicast_routing_policy {
default-action {
policy-result reject
}
statement allow-group {
match {
multicast {
group-address {
prefix-set srl_group_prefix-set
}
}
}
}
statement allow-source {
match {
multicast {
source-address {
prefix-set srl_source_prefix-set
}
}
}
}
}
}Configuring the switchover to SPT
By default, the last hop router or the receiver DR initiates an SPT switchover toward the source after receiving the first copy of multicast data packets.
Use the spt-switchover
parameter in the network-instance* [name] protocols pim!+ context,
to define the threshold for switching from a shared tree (RP) to a shortest path
tree (SPT). Configure the spt-switchover parameter with a specific
group prefix to define the switchover threshold on a per-group basis.
To prevent the DR from triggering an SPT switchover,
set the spt-switchover parameter to
infinity.
--{ + candidate shared default }--[ ]--
#info network-instance srl_test_intance protocols pim
network-instance srl_test_intance {
protocols {
pim {
admin-state enable
interface ethernet-1/1.1 {
}
spt-switchover {
group 239.255.0.0/16 {
threshold 100000
}
}
}
}
}