29 November 2010

PIM and IGMP

Multicast data, say for audio or video streams, has unicast source IP's and destination IP's in the range 224.0.0.0/4. The data payload is currently always UDP. Local multicast routing decisions are based on IGMP (protocol 2) and PIM (protocol 103).

Clients send IGMP join messages to an upstream device with TTL 1, which processes them, adds the multicast destination IP to its list of subscribed groups, and emits in turn a new IGMP message toward it's own upstream device. On a LAN, ethernet packets will use special multicast destination addresses which repeat a chunk of the multicast group IP.

Within an autonomous system, PIM (protocol independent routing, sparse mode) has a centralized RP (rendezvous point) which keeps track of where multicast senders are for joined group clients. Between autonomous systems, multicast routes are advertised using some other protocol, typically extensions to BGP. Eventually the chain of join messages reaches the multicast source, which starts sending traffic back down the chain toward the client.

IGMP messages stop as soon as you run into a PIM enabled router. From there the PIM router sends join messages towards the RP or source and a distribution tree gets built. IGMP only goes beyond one hop when IGMP forwarding/proxying is enabled (which is described later). Some consumer level Linksys routers also employ an IGMP proxy to allow multicast traffic to penetrate within a local NAT, when configured to do so.

Each intermediate router, firewall, or other device has to keep track of which interfaces have multicast clients on them and send subscribed group traffic to only those interfaces. When a client is done, it sends an IGMP leave message upstream, and the traffic stops. If a client simply vanishes, the upstream device is periodically doing IGMP queries to see what groups are active on a particular interface/LAN. Each active client has to respond with an IGMP group membership report packet. Any groups which don't get responses get pruned by the querying device, and the traffic eventually stops.

The RFC's for multicast and the group assignments by IANA are a bit of a mess; they have mutated a lot over the years, and continue to do so. For example, so far IGMP version 3 exists only in draft form; it hasn't been converted to standards track yet, much less ratified by the IETF. Multicast address assignments are also a bit of a mess. Some particularly important group ranges are:


  • 224.0.0.0/8 is globally routable and directly assigned by IANA. 
  • 224.0.0.0/24 is reserved for local LAN stuff. 
  • 233.0.0.0/8 is the "GLOP" range, where autonomous systems with 16- bit AS's can emit 233.X.Y.0/24 and be globally accessible (clients send joins toward the AS, inside the AS the actual sources register with their PIM RP). Most remote sources you run across will be in this range, because all other globally routable multicast groups have to go to the formality of a specific assignment by IANA. Each 16-bit AS gets its own /24.
  • 239.0.0.0/24 is for administratively scoped multicast within an autonomous system (routing domain). Most local sources you run across will be in this range, e.g. our DATN channels.

No comments:

Post a Comment