Protocol Independent Multicast

From CT3

Jump to: navigation, search

Multicast Forwarding

In multicast forwarding, each packet in a stream is transmitted once by a source and replicated by the infrastructure to efficiently reach an arbitrary number of recipients. This introduces a number of challenges not typically of concern when dealing with strictly unicast traffic. The fundamental difference is that, while unicast routing protocols are designed to forward traffic down the optimal path or paths to a destination, a multicast routing protocol must forward traffic down all paths, often replicating packets out multiple interfaces on the same router.

Image:Unicast_vs_multicast_forwarding.png

Obviously, wherever traffic is replicated across a network containing even a single redundant path, the potential for routing loops is present. While unicast routing protocols are well-suited to detect and avoid loops when routing to a single destination, a multicast routing protocol is needed when paths have multiple end points. There are a number of multicast routing protocols, including DVMRP, MOSPF, and CBT, but this article intends to discuss Protocol Independent Multicast (PIM).

The term "protocol-independent" stems from the fact that PIM does not maintain its own topology database. Instead, it relies on the unicast forwarding table of the router to avoid loops; PIM is considered protocol-independent because it has no direct dependency on the unicast routing protocol(s) used.

Reverse Path Forwarding (RPF) checks are performed on each multicast packet received by a PIM router. RPF verifies that incoming multicast packets arrive on the interface closest to their source, by comparing the source address with the unicast routing table. If a unicast packet destined for that address would be forwarded out a different interface, the packet has reached the router via a non-optimal path, indicating the presence of a potential routing loop. In this event, the RPF check fails, and the incoming multicast packet is discarded.

In addition to monitoring the unicast routing table, PIM maintains its own multicast routing table to track incoming and outgoing interfaces for multicast traffic. Multicast routes are expressed in the format (S, G), where S is the multicast source and G is the group address. The multicast routing table is viewable on IOS with `show ip mroute`:

Router# show ip mroute 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:07:04/00:02:49, RP 2.2.2.2, flags: SJPL
  Incoming interface: FastEthernet0/0, RPF nbr 10.0.12.2
  Outgoing interface list: Null

PIM Modes

In actuality, PIM refers to a family of very similar routing protocols, but which each operate in a different mode. These are:

Personal tools

CT3

Main menu