EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

PIM Sparse Mode Introduction

PIM Sparse Mode Introduction

Posted on Jan 24, 2020 (0)

PIM Sparse Mode Introduction

PIM-SM is just like PIM-DM mode which uses unicast routing to perform RPF to forward the multicast traffic.

PIM-SM Explicit Join model:

This model ensure that multicast traffic can only be sent to those location of that network that specifically request for it and this can be easily done by PIM-SM joins which are sent hop by hop towards root node of the tree which is RP and as join are sent hop by hop the tree is created and by help of this tree multicast traffic can be forwarded down to host.

When any multicast traffic is not needed, PIM-SM will send the prune message up the tree towards root node to prune off all unnecessary traffic and likewise the interface will be removed from OIL list.

There are two type of tree PIM-SM follows:

  • PIM-SM Shared Tree
  • PIM-SM shortest path tree

We will discuss each of the scenario when these trees are used under which circumstances. 

PIM-SM Shared Trees

PIM-SM mode works on unidirectional tree model where multicast traffic flows from Source to RP and from RP it is sent down to shared tree members, that is why this type of tree is also called as RPT (RP trees). To make this happen the Source must get registered to RP and all members of the Tree who wants the multicast traffic must sent join to RP to form shared tree and after this from source multicast traffic can flow to destination.

PIM-SM Shared Tree Joins

We can understand this by following example, that in below figure H1 has just joined the multicast group G via IGMP membership report.

As soon as R5 received the IGMP report, it will create (*, G) entry and in outgoing list it will enter fa0/0 marked RED and will send the (*, G) join to RP to join the shared tree.

R3 being the RP does not have (*, G) entry, so it will create the (*, G) entry and update its OIL with fa0/1 of R3 towards R5 marked RED.

Now from RP the shared tree has been formed and if RP receives the Multicast traffic for group G, the host H1 will receive it. Now let’s suppose another receiver H2 join at R6 and send the IGMP membership report to join group G.

Now if R6 does not have (*, G) entry R6 will create it and update its OIL with fa0/0 of R6 marked RED and will send the (*, G) join to R3.

Now when R5 receives the (*, G) I will find that it already has (*, G) entry for Group G so it will simply add its fa0/0 interface in OIL list marked RED.

The above figure will be the final shared tree which will be created and tree branches are red marked Lines includes R3 and R5 and R6.

 PIM-SM Shared Pruned Tree:

Let’s assume that H2 does not want to receive any multicast traffic for Group G, it will send the IGMP leave message to R6.

H2 is the only member of group G on R6 fa0/0 interface , this interface will be removed from OIL list of (*,G) entry and when this entry  removed the OIL list will be empty as this was the only interface and R6 no longer requires the group G traffic , and R6 will sent (*,G) prune message towards R5.

Once it is done R5 will remove the interface connecting to R6 from OIL list of R5 (*, G) entry.

PIM-SM Shortest Path Tree:

PIM-SM mode also provide the facility to switchover from shared tree to SPT if there is a source available which is in shortest path from destination instead of RP.

By joining SPT. Multicast traffic can be routed directly to receivers without going to RP thus reducing network latency etc. Here in SPT, STP join and SPT leave message are used to create the SPT.

SPT Joins:

H2 has joined the group G its send the IGMP join (Sr, G) marked as Red. Now let’s assume that R6 know that source Sr is active source for Group G.

Now R6 will verify the RPF interface and will send the (Sr, G) join towards S1 by the correct interface.

Now when R5 receives the (Sr, G) joins, it creates the (Sr, G) entry in its multicast forwarding table and add the fa0/0 in its OIL list marked RED in figure. Now R5 will send the (Sr, G) joins towards source.

Finally RouterR1 will receive the (Sr, G) join and it will add its fa0/1 interface in OIL list of existing (S1, G) entry as (S1, G) entry must have been already created as soon as it receives the first packet from source.

Below is the final SPT for group G which is marked RED.

SPT Prunes:

Let’s suppose that R6 has no interested host for Group G, so R6 will send (Sr, G) prune towards Sr.

When Router R5 receives the (Sr, G) prune, it will removes its interface towards R6 which is fa0/0 from its OIL list. Now R5 will send the (Sr, G) prune message towards Source Sr. 

When Router R1 receives the prune message it will remove the fa0/1 interface from its OIL list even if R1 will receives multicast traffic from Sr, it will simply drops the packet.

PIM Source Registration:

PIM-SM uses a unidirectional shared tree, multicast traffic can only flow down this tree. Therefore, multicast sources must somehow get their traffic to the RP so that the traffic can flow down the shared tree. PIM-SM accomplishes this by having the RP join the SPT back to the source so it can receive the source's traffic. First, however, the RP must somehow be notified that the source exists. PIM-SM makes use of PIM Register and Register-Stop messages to implement a source registration process to accomplish this task.

For this PIM Register and PIM Register-Stop message is used.

PIM Register Message: PIM register message are sent by first-hop DRs (that is, a DR that is directly connected to a multicast source) to the RP. The purpose of the PIM Register message are:

  • Notify the RP that Source S1 is actively sending to Group G.
  • Deliver the initial multicast packet(s) sent by Source S1 (each encapsulated inside of a single PIM Register message) to the RP for delivery down the shared tree.

When Multicast source begin to transmit , the DR which receives the multicast packets sent by the source and creates an (S, G) state entry in its multicast routing table  and  the DR encapsulates each multicast packet in a separate PIM Register message and unicasts it to the RP. When an RP receives a PIM Register message, it first de-encapsulates the message and find that the packet inside is multicast.

If the packet is for an active multicast group the RP forwards the packet down the shared tree. The RP then joins the SPT for Source Sr so that it can receive (Sr, G) traffic natively instead of it being sent encapsulated inside of PIM Register messages. If, on the other hand, there is no active shared tree for the group, the RP simply discards the multicast packets and does not send a Join toward the source.

PIM Register-Stop Message:

 The RP unicasts PIM Register-Stop messages to the first-hop DR, instructing it to stop sending (Sr, G)

Register messages under any of the following conditions:

  • When the RP begins receiving multicast traffic from Source Sr via the (Sr, G) SPT between the source and the RP.
  • If the RP has no need for the traffic because there is no active shared tree for the group.

When a first-hop DR receives a Register-Stop message, the router knows that the RP has received the Register message and one of the two conditions above has been met. In either case, the first-hop DR terminates the Register process and stops encapsulating (Sr, G) packets in PIM Register messages.

Source Registration Example:

 In first step Source S1 starts sending Multicast traffic for Group G.

When first hop router R1 receives the multicast packet, it will encapsulate this multicast packet in PIM register message and unicast to RP.

When RP receives this packet and decapsulate it , it find that it is multicast packet and also see that if there is active host for this group and shared tree has been created , RP will forwards this packet to its member OIL for Group G. ad sends the (Sr,G) join back to source.

When (Sr, G) join reaches to R1 an (Sr, G) SPT will be built from R1 to RP.

Now the (Sr, G) traffic begins to flow to the RP via this newly created (Sr, G) SPT. At this point, the RP no longer needs to continue to receive the (Sr, G) traffic encapsulated in Register messages, so the RP unicasts a Register-Stop message back to the first-hop DR (R1)


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.