PIM Sparse mode

PIM Sparse mode

Ask and ye shall receive

• It addresses many of the scaling issues of PIM Dense Mode
• The major difference is in the idea of "Implicit Join" now discarded.
• A receiver must explicitly choose to join a multicast stream
• If PIM-DM was "Push" model, PIM-DM is referred as "pull" model
• Although they share names, PIM-DM and PIM-SM should be treated as very different protocols
• Different Priorities
• Different mechanisms
• They do share some packet formats

Initial Signaling

• Just like anu multicast routing protocol, the end goal for PIM-SM is to bring the source's traffic to interested receivers
• To enable this to occur, the first step is to locate the sources and receivers
• Sources
• Signal to the FHRs about their existence
• Occurs completely in data plane
• Receivers
• Signal to the LHRs about their existence
• Either dynamically via IGMP or statically via interface configuration.

After initial Signaling

• PIM-SM's Challenge: 
• Connect the FHRs to the LHRs

Rendezvous Point

• The FHRs know about the source, LHRs know about the receivers
• One way would be for them to sent it to each other directly
• Scaling nightmare on many different levels
• Simpler solution - "Central registry" or Redezvous Point (RP)
• Idea is very simple - pick one multicast enabled router in the network and assign it special duties
• It should receive MC state information from both FHRs and LHRs
• It should compare this information and work to connect them if needed be
• FHRs; LHRs and the RP should all agree on who is the RP
• Almost any MC enabled router can be selected to perform RP duties
• Only stipulation is that all MC routers must be informed about it.

LHR with interested Receivers (Join/prune message to the RP)

Once an LHR creates a (*,G) state, it can start the PIM signaling process\

• PIM trees are built from the leaves towards the root
• RP is considered to be the root for the (*,G) tree (or RP tree or Shared tree)
• LHR sends a join/Prune message (Join version)
• Sent  upstream on the RPF interface for the RP IP
• Processed hop-by-hop, directed towards the RP by each router between the LHR and RP
• Each router also creates a (*,G) state (if one did not exist previously)
• Tree is being built in reverse, from the leaves, to the root
• Interface receiving the join is included in the OIL
• RFP interface to the RP becomes the IIF

FHR Joining/Pruning

• LHR method to join a PIM tree is the join/prune messages
• This is not good solution for disseminating information about sources
• Join/prune messages were designed to build the tree from leaves towards the root - i.e message is sent upstream repeatedly
• Since the source is already the root, it is already at the top of the stream
• Nowhere further up to send the message.

FHR to RP Communication

• FHR simply inform the RP about the stream - i.e about the source and the MC group, (SG)
• Then the RP has the ability to use the Join/Prune mechanism to build a tree from itself to the source
• Furthermore, the RP would build this tree only if it was required 
• In other words, the RP would not have to build trees to source of group no receivers ere interested in.
• This is exactly the purpose of the PIM register message
• One of the few unicast message in PIM
• Source IP - FHR's IP
• Destination IP - RP's IP
• Content - Information about the (S,G) (Plus some a few things)
• Each MHR simply routes/forwards the packet as it would any unicast packet
• The message is not processed by the MHRs

RP's on-demand Join

• Once the RP has the (S,G) from the FHR it joins the (S,G) to first receive the multicast packets
• It can use the join/prune mechanism as it is a leaf for the SPT
• PIM trees are built from the leaves towards the root
• FHR is considered to be the root for an (S,G) tree (Source Tree or Shortest Path Tree)
• RP sends a join/prune message (join version)
• Sent upstream on the IIF (RPF interface for the source's IP)
• Processed hop-by-hop, directed towards the FHR by each router between the RP and FHR
• Each middle hop router (MHR) creates an (S,G) state (if one did not exist previously)
• Tree is being built in reverse, from the leaf to the root
• Interface receiving the join is included in the OIL
• RPF interface to the FHR (or source) becomes the IIF

Multicast traffic flow

• As the (S,G) join is received by the FHR, it adds the incoming interface to the OIL of the (S,G) state.
• It now starts replicating (S,G) packets on the interface
• MHRs will receive these packets on the IIF
• Put through the RPF check (which they should pass)
• Replicate them on the OIL
• The packets will eventually reach the RP
• RP will replicate them on the (*,G) tree(s)
• Same process as above repeats on the MHRs between RP and LHR
• LHR receives the packets and delivers them to the receivers

======================Advanced PIM Sparse Mode======================

Hello Message

• Both PIM modes require the establishment of the neighbor adjacencies through the network.
• Leads the creation of the base multicast tree
• Topology of links where multicast traffic can flow
• Routed multicast traffic will only flow between two directly connected PIM nodes
• Note: Can be radically different from the UC routing topology
• PIM uses Hello messages to discover directly connected neighbors
• Source IP - That of the directly connected interface
• Destination IP - 244.0.0.13 (All-PIM-Routers)
• IP protocol - 103
• TTL - 1
• Option carried as TLVs
• Note: PIM SM routers can become adjacent with PIM DM routers 

PIM DR

• PIM elects a DR for every multi-access segment
• DR election is a requirement of the PIM-SM protocol
• A DR serves two functions depending on its placement
• Segments with MC senders (FHR Segment)
• DR is responsible for sending the PIM register message to the RP
• Segments with MC receivers (LHR segment)
• DR is responsible for sending the PIM join message towards the RP
• PIM-SM uses the DR priority option in the hello message
• Highest priority preferred
• Highest IP used for tie-breakers
  
  
• PIM Join/Prune Message
• The most important PIM Message
• No separated Prune Message
• Used in both PIM DM and SM
• Capable of signaling both Joins and Prunes.
• Message only used for pruning in PIM DM
• Joins in PIM DM are implicit
• Join messages are processed hop-by-hop in the PIM topology
• Destination IP - 224.0.0.13 
• IP protocol - 103
• TTL - 1
• (S,G) Join
• The simpler of the two Join messages
• Pre-requisite - The source must be known
• The RP has that information after the source registration
• The RP can use this message to build an SPT to the FHR
• Upstream neighbor - RPF neighbor towards the source
• MC Group - The desired group's IP
• Joined M Source - The discovered source's IP
• Each MHR performs an RPF check, processes the packet and then passes on to the RPF interface for the FHR
• Each MHR also creates the (S;G) state
• IIF and the OIL added or updated 
• Finally the LHR adds the OIL to its (S,G) state
•