Problem
What if you have a data source (live video/audio stream, stock ticker...) that has to reach multiple listeners?
Solution
One way to achieve this is for the source to send multiple independent streams to each listener. This is highly inefficient and not scalable; if there were a thousand interested listeners, the source will have to send out a thousand identical copies to each listener.
Enter multicast. Multicasting allows a source to send traffic to a specific "group address" (class D 224.0.0.0/4) and have the routers automatically forward copies out ports that have interested listeners on them.
Ok, that's great, but that introduces another problem. Unless the routers know where these listeners are, they'll have to just forward the traffic everywhere to make sure that the data gets to all the listeners. We now have only one stream, but its still being flooded to all routers. What we need is a protocol for the listeners to signal the routers that they are interested in a multicast group; a group is just a multicast address. We also need a protocol for the routers to communicate among themselves to determine where the sources are and where the listeners are.
That's where IGMP and PIM come in. IGMP is the protocol that listeners use to signal routers that it is interested in a specific multicast group, and in the case of IGMPv3, that it is interested in a particular source. PIM is the multicast routing protocol that routers use to exchange information to build their multicast routing trees.
PIM
We'll need to focus on PIM for a moment because it runs in different modes - dense mode, sparse mode, sparse-dense mode, bidirectional PIM, source specific PIM - and each of these run in fundamentally different ways.
PIM Dense Mode
The core problem to solve in multicast is "how do we get the traffic to everyone that wants the traffic and only the ones that want the traffic?" In PIM dense mode, multicast traffic is initially forwarded everywhere. Routers then send prune messages via PIM to upstream routers to signal that it does not want to receive traffic for that multicast group. Some other messages that PIM dense mode uses are "graft", "assert", and "refresh".
Due to PIM dense mode's flood and prune behavior, multicast initially still goes to places where there are no interested listeners; it is not very efficient or scalable unless we have a dense population of listeners.
PIM Sparse Mode
The core problem to solve in multicast is "how do we get the traffic to everyone that wants the traffic and ONLY the ones that want the traffic?" In PIM sparse mode, we add the concept of a Rendezvous Point. The routers begin in a state where they all know of the RP. The RP is a router that knows of all sources.
You can imagine the operation of the RP divided into two "legs". The first leg is from the RP to the multicast source. The second leg is from the RP to the multicast listeners.
Before we begin with the description of how this all works, we must define what the Designated Router (DR) is. The DR is a router on a multi-access segment chosen to be the one that will be designated to send multicast traffic and communicate with the RP on behalf of that segment.
A source will begin sending multicast traffic to a group. The DR will send a 'register' message with the multicast traffic encapsulated in unicast to the RP. The RP will then send (S,G) joins towards the source, carving a path for the multicast traffic. When the (S,G) joins get to the DR with the source, the multicast traffic will flow through the (S,G) routes. The RP will then send a (*,G) stop message to the DR to stop the encapsulated stream.
A listener will notify its DR with an IGMP join 'report'. The DR will send a (*,G) join message towards the RP, carving a path for the multicast traffic to reach the listener. When the (*,G) request gets all the way to the RP, the RP will forward traffic for the group towards the listeners. After this, the destination router with the listeners will know the source's IP address. They can then send (S,G) joins towards the source, carving a more direct route to the source. When the listener router starts receiving traffic on the (S,G) route, it will send a prune message towards the RP to stop the flow from the RP.
For more information, read the RFC: http://www.ietf.org/rfc/rfc4601.txt
