In this lesson, we introduce Protocol Independent Multicast (PIM) at a high level. Along the way, we present some of the terms and concepts that we will use extensively in the next lessons of the course.

Multicast Routing

Engineers are familiar with unicast routing and protocols such as EIGRP, OSPF, and BGP. A routing protocol's primary function is determining the most efficient IP path to a given destination across a network. However, routing protocols have many other supplementary functions, such as failure detection, loop prevention, and traffic engineering. To do that, a unicast routing protocol performs the following general functions:

• Topology Discovery:
  • It discovers and maintains knowledge of the network’s topology, including all available links and routes and their current status.
• Path Determination:
  • It calculates the best path for every destination network using various metrics such as hop count, bandwidth, delay, and cost.
• Route Maintenance:
  • It ensures that routing tables are updated to reflect network changes, such as new links, failed links, and changes in traffic patterns.

In the past, the industry thought that to deliver multicast traffic, we needed a separate full-scale multicast routing protocol that runs parallel to the unicast routing protocol. A few protocols were developed, such as MOSPF (Multicast Open Shortest Path First) and DVMRP (Distance Vector Multicast Routing Protocol). At some point, every router in a network had run two full-scale routing protocols in parallel, as shown in the diagram below. 

However, pay attention to the first couple of functions each protocol does to operate. They are the same, right?

Network researchers realized that we do not need to run two parallel protocols that do almost the same tasks with the expectation of a few specific functionalities. Since multicast sources and receivers are regular IP hosts connected to the network, the multicast routing protocol can leverage the information obtained by the unicast routing protocol and only does multicast-specific tasks, as shown in the diagram below. It does not need to compute the best path between host A and host B - this has already been done very efficiently by the unicast routing. It can take advantage of the unicast loop prevention and path selection knowledge without needing to make the same computations. This minimizes the required resources, CPU cycles, and Memory space on each router, which allows the network to scale more efficiently. Back in the days when routers had limited resources, this was a huge, huge improvement.

Protocol Independent Multicast (PIM) was introduced in the 1990s, leveraging the idea that the multicast routing protocol does not need to perform full topology computations but simply uses the information already obtained by the unicast routing. The "Protocol independent" part of the name means it does not rely on any specific unicast routing protocol. It can use the information acquired by any underlying one, such as RIP, ISIS, EIGRP, OSPF, BGP, etc. As far as the unicast topology is loop-free and operational, PIM can run on top and deliver multicast traffic from sources to receivers.

How does PIM work? (high-level)

Most of the concepts that we will see in this lesson at a high level are explained in more detail in the next lessons later on in the course.

If we must summarize how the protocol works in one sentence, it will be that Protocol Independent Multicast (PIM) operates by building and maintaining multicast distribution trees (MDT) using the information obtained by the unicast routing protocol. But what is MDT?

Multicast Distribution Tree (MDT)

In networking as a field, the term "tree" is frequently used. Multiple protocols use this concept to essentially describe a graph of the network path from a starting point to an endpoint. For example, a Spanning Tree builds a loop-free tree of a redundant Ethernet network. The tree is rooted at the Root Bridge and spans across all switches within the switching domain. In the process, the Spanning tree blocks all redundant links and leaves only one path from one switch to another. 

In general, when something is described as a "tree," it typically means it has the following four characteristics:

• It is loop-free: Trees do not have cycles or loops. They have branches and leaves, and a branch does not lead to another branch.
• It is hierarchical: Trees grow from the root through layers of branches and leaves.
• It is deterministic: There is only one shortest path from point A to point B (hence, no ECMP).
• It is directional: It extends from the root outwards.

If you think of Spanning Tree, it has all those characteristics. It is loop-free, hierarchical, and has no ECMP. There is only one path from A to B. Only if this primary path fails does the protocol calculate another path.

In the same context, the Multicast Distribution Tree (MDT) is a conceptual tree structure describing the paths multicast traffic follows from a source to a receiver. It has the four characteristics we have just seen. 

For example, let's take the network shown in the diagram below. We have a source connected to router R1 and two receivers connected to routers R6 and R8. There are multiple paths from the source to each receiver. Let's look at RCV1, for example.

Suppose we run Protocol Independant Multicast (PIM) on all links between the routers. PIM creates one deterministic path from the source to receiver RCV1. The path is loop-free, deterministic, directional, and shortest according to the unicast routing protocol. This path is typically called the Shortest Path Tree or Source Path Tree (SPT). 

Shortest Path Tree - Source Tree (SPT)

The SPT represents the shortest path (in terms of the unicast protocol's metrics, such as cost, hop count, bandwidth, delay, etc.) from a source to a receiver. The goal of PIM is to use the information obtained by the unicast routing protocol and build that shortest path tree (SPT) so that multicast from the source can be delivered optimally to the interested receivers, as shown in the diagram below.

Notice that the terms shortest-path tree and source path tree are used interchangeably as SPT in the context of PIM. Both mean the optimal, deterministic, loop-free, shortest path from the source to a given receiver. 

Also, note that each receiver has its own source path tree (SPT). For example, the diagram above shows the SPT of receiver RCV1. However, the diagram below shows the SPT of receiver RCV2. Notice that the multicast path is different because that is the shortest path from the source to RCV2 according to the unicast routing protocol.

The source path tree has one drawback. It implies that the receiver knows the source that sends traffic to the multicast group. However, in most scenarios, receivers do not know the source sending to the multicast group; they just join the multicast group without specifying a source IP address - (*, G).

Knowing the source (S, G) vs not knowing the source (*, G)

Now, it is time to reveal some fundamental aspects of IP multicast using the diagram below. 

1. Sending IP multicast is a stateless function. The source simply sends packets to a multicast group address (e.g., 239.1.1.1) without knowing or keeping track of the individual receivers. There is no state communication between the receivers and the source. The network is responsible for delivering the multicast traffic to interested receivers (if any).
2. Receiving multicast is a stateful functionality. A receiver must explicitly join the multicast group it wants to receive. In some scenarios, the receiver (or the actual application that needs the multicast) knows the specific IP address of the source of the multicast stream it wants to get. In that case, the receiver directly joins the multicast group from the specific source using the unique (Source, Group) combination. For example, RCV1 wants to get the multicast stream on 239.1.1.1 from 10.1.1.1, so it sends an IGMPv3 Membership Report for (S, G): (10.1.1.1, 239.1.1.1). From a network point of view, this scenario is easy because the unicast routing knows where the source (10.1.1.1) is connected, so it can simply build the Source-Path Tree (SPT) following the unicast routing from the receiver to the source.
3. However, in the most common scenario, the receiver (or the actual application that needs the multicast) does not know the specific IP address of any source. It only knows the multicast group it wants to receive. In that case, the receiver sends an IGMPv2 membership report with the group address only—(*, G). In this scenario, the network must keep track of whether there is an active source. From a network point of view, this scenario imposes a challenge  - the network must keep track of whether there is an active source for that multicast group and the source's IP address. When R3 receives the IGMP Membership Report for (*, 239.2.2.2), it must understand whether an active source transmits multicast to group address 239.2.2.2 and its IP address. But how does R3 do it? 

This is where the Randevouz Point (RP) comes into the picture. 

The Randevouz Point (RP)

The Randevouz Point (RP) is a router in the network that acts as a centralized point where multicast sources and receivers initially register, as shown in the diagram below.

• When a multicast source begins to send multicast traffic, it sends the traffic to the RP using a PIM Register message. Hence, the RP knows all active sources in the network.
• When a receiver wants to join a multicast group, its local gateway router sends a PIM Join message to the RP. This message basically asks the RP if there is an active source transmitting multicast to that group at the moment.

Let's look at the example shown in the diagram below. SRC2 is transmitting multicast to group 239.2.2.2. The local gateway router where the source is connected is called the First Hop Router (FHR), whereas the local gateway router where the receiver is connected is called the Last Hop Router (LHR).

• Step 1: When the FHR receives the multicast stream from the source, it registers the source with the Rendezvous Point (RP). 
• Step 2: When the local gateway router to which the receiver RCV2 is connected (the Last-hop Router, LHR) receives the multicast from the RP, it learns the source IP address (10.2.2.2). Then, the LHR initiates the shortest path tree (SPT) toward the source.
• Step 3. The FHR forwards the multicast traffic directly to the LHR, and the Rendezvous Point is no longer in the data path.

This is a high-level overview of joining a multicast stream without knowing the source IP address. We will discuss this process in greater detail later in the course. However, write down the terms that we have just introduced. They are very important and used extensively throughout the course.

MUST REMEMBER: 
The source's local gateway router is called the First Hop Router (FHR). 
The receiver's local gateway router is called the Last Hop Router (LHR).

The process of registering the source with the Rendezvous Point and sending the initial multicast via the RP involves one more Multicast Distribution Tree (MDT) that we must discuss - the Rendezvous Point Tree (RPT).

Shared tree - Rendezvous Point Tree (RPT)

The RPT is often referred to as the "shared tree."  It is rooted at a router that performs a special function in the PIM domain called the Rendezvous Point (RP). The RP manages information about the network's multicast sources by doing the following functions: 

• When a multicast source starts transmitting multicast onto the LAN, its gateway router (called the first-hop router, FHR) immediately registers the multicast source with the Rendezvous Point (RP) using a PIM Register message. Hence, the RP knows all the sources in the network.
• When a receiver joins a multicast group, its gateway router (called the last-hop router, LHR) contacts the RP to check if a source transmits on this group at the moment. If a source is active at the moment, the RP sends the multicast traffic from the source to the receiver over the RPT.

In that context, the term Rendezvous Point Tree (RPT) describes the loop-free, deterministic, directional path from the RP to the receiver, as shown in the diagram above. 

Key Takeaways

• In the past, network researchers thought we needed a separate full-scale multicast routing protocol that runs parallel to the unicast one to run IP Multicast. 
  • Protocols such as MOSPF (Multicast Open Shortest Path First) and DVMRP (Distance Vector Multicast Routing Protocol) were introduced.
  • However, people soon realized that the unicast routing protocol does all necessary computations, and they do not need a second full-scale multicast protocol to do the same computations and burn the routers' resources.
  • Protocol Independent Multicast (PIM) was introduced.
• PIM uses the information obtained by the unicast routing protocol.
  • It can work with any underlying routing protocol, such as RIP, ISIS, EIGRP, OSPF, BGP, etc.
  • PIM doesn't care which unicast routing protocol is used as long as the unicast routing table is stable and loop-free.
• The primary function of PIM is to build a Multicast Distribution Tree (MDT) that delivers multicast traffic from a source to a receiver. There are two types of MDT:
  • SPT - Source Path Tree or Shortest Path Tree. Both terms mean the same thing and are used interchangeably. SPT describes the loop-free, deterministic, shortest path between a source and a receiver.
  • RPT - Shared Tree or Rendezvous Point Tree. Both terms mean the same thing and are used interchangeably. The RPT describes the loop-free, deterministic, shortest path between the Randevouz Point (RP) and a receiver.
• Sending multicast is a stateless function. The source simply puts the multicast onto the local LAN. It does not know whether there are interested receivers.
  • The network is responsible for delivering the multicast traffic to interested receivers (if any).
• Receiving multicast is a stateful function. Receivers explicitly join and leave a multicast group they are interested in by sending IMGP Membership Reports on the local LAN.
  • Knowing the source (S, G): A receiver may know and specify the exact source sending the interested multicast traffic. In that case, the receiver's local gateway router can immediately initiate building the SPT since it knows the source's IP address (and the unicast routing protocol knows how to reach that IP).
  • Not knowing the source (*, G)—Most commonly, a receiver doesn't know the source that sends the interested multicast traffic. This imposes a challenge on the network—the network must keep track of all active sources. This is why we need the Randevouz Point (RP).
• The Randevouz Point (RP) is a router in the network that acts as a centralized point where routers register active multicast sources. The RP knows all multicast sources' IP addresses.
  • When a receiver wants to get a multicast and doesn't know the source IP address, the local gateway router asks the RP. (The RP knows all sources!)
  • If an active source exists for that group, the RP sends the multicast to the receiver's local gateway router (LHR). It understands the source IP address when it gets the multicast and can initiate an SPT directly to the source's local gateway router (FHR).
• The source's local gateway router is called the First Hop Router (FHR). 
• The receiver's local gateway router is called the Last Hop Router (LHR).