A PON carries multicast efficiently because the OLT runs IGMP Snooping to learn which ONUs actually joined a group, then copies each stream only to those members instead of flooding it to every user on the tree. That single mechanism is what turns "one source, many receivers" traffic from a bandwidth drain back into a bandwidth saver.
A PON is a downstream-broadcast tree, so without control a multicast stream would reach every ONU — wasting the very bandwidth multicast was meant to save.
IGMP Snooping makes the OLT "listen" to Join/Leave messages and build a membership table, so it replicates each group only to ONUs that asked for it.
Replication happens twice: the OLT copies to member ONUs, and each ONU filters again to the specific user ports that joined.
IGMP Snooping (listen) and IGMP Proxy (answer upstream) are different jobs, usually combined; a multicast VLAN plus CAC bandwidth caps keep multicast from starving unicast.
Look at the bandwidth structure first. On the downstream side, every frame the OLT sends is copied by the passive splitter to all ONUs. Take a 50 Mbps IPTV channel watched by 10 users. With unicast, the OLT would send 10 copies and burn 500 Mbps. With multicast, the OLT sends one 50 Mbps copy and the splitter replicates it to those 10 ONUs — the PON downstream only spends 50 Mbps.
The catch: the OLT has to know "who is watching." If it doesn't, it can only flood the channel to every ONU — which is just broadcast again, and all the saved bandwidth goes straight back out the window.
When a set-top box or a camera wants to join a multicast group, it sends an IGMP Join message. With IGMP Snooping enabled, the OLT stops blindly flooding multicast frames and instead "listens" to those Join/Leave messages, building a multicast membership table: which PON port, which ONU joined which group.
From then on the OLT replicates only that group's traffic to the ONUs in the table. ONUs that never joined don't receive it, and the downstream bandwidth is spent precisely per member count.
PON replication actually happens in two stages:
| Replication point | What it copies to | What problem it solves |
|---|---|---|
| OLT (PON-port level) | The multicast stream to ONUs that joined the group | Stops multicast flooding to the whole tree, saves PON downstream bandwidth |
| ONU (user-port level) | The received stream to its own user ports that joined | When one ONU serves many users, only forwards to the ports that asked |
Watching the OLT alone is not enough. If an ONU serves 8 households but only 2 are watching, the OLT delivers the stream to that ONU, and the ONU must filter a second time by port — otherwise all 8 ports receive it. Only when both stages run Snooping does "replicate on demand" hold all the way down.
IGMP Snooping: the OLT passively listens to the users' IGMP messages, builds only a local membership table, and does not answer the upstream network.
IGMP Proxy: the OLT acts as a "proxy" upstream — it aggregates the downstream users' Joins and requests the multicast from the upstream router, and answers queries on their behalf.
A common real-world combination: the OLT uses IGMP Proxy toward the upstream (requesting multicast "on behalf of" all users) and Snooping toward the downstream ONUs/users (precisely controlling replication for each subtree and each port). One manages internal replication; the other manages the external request — and they are usually deployed together.
To keep multicast and unicast from mixing on the user side, operators typically open a multicast VLAN (mVLAN): user ports join via "multicast VLAN binding," and the multicast stream travels on its own VLAN, isolated from internet unicast and easier to police and rate-limit.
Multicast also must not be allowed to fill the PON downstream. On the OLT you normally set a multicast bandwidth limit / CAC (Call Admission Control): a cap per PON port and per group, so when groups get too many new joins are rejected, protecting the bandwidth of internet and VoIP unicast services.
What bandwidth does multicast actually save in a PON? It saves the PON downstream shared bandwidth. Between the OLT and the splitter there is only one fiber; multicast sends that traffic once and the passive splitter replicates it. Switch to unicast and the OLT must send one copy per user, and that fiber fills up fast.
How do IGMP Snooping and IGMP Proxy divide the work? Snooping is "listen" — it only builds the OLT's internal membership table and controls downstream replication. Proxy is "answer" — it requests and maintains the multicast stream from the upstream router on behalf of downstream users. One governs internal copying, the other external requesting; they are often paired.
Why must the ONU also do multicast filtering — isn't the OLT enough? No. One ONU often serves several user ports; the OLT can only decide "should this ONU receive," and which of its ports get the stream is the ONU's port-level Snooping job. Both stages together give true "only the ones who asked."
Can too many multicast groups drag the OLT down? At the hardware level the OLT uses a dedicated multicast forwarding table with ample capacity; at the software level CAC and per-PON bandwidth caps are the safety net — when groups get too many, admission is denied, so multicast never crowds out unicast. Check each GPON model's multicast-entry and bandwidth specs.
Why separate the multicast into its own VLAN? A multicast VLAN keeps the multicast stream off the internet-unicast VLAN on the user side, which makes permission control and rate-limiting cleaner and stops one flooded group from disturbing ordinary browsing.
PON multicast pays off only when "one source, many receivers" traffic is sent just once on the downstream shared link. The OLT does that with IGMP Snooping — backed by Proxy — replicating precisely, the ONU adds port-level filtering, and a multicast VLAN with bandwidth caps keeps it both efficient and controlled. Plan the switch-side multicast together with the PON's own multicast capability when you need IPTV or video-surveillance one-to-many flows to run steady.
Isolate Multi-Service on a Passive Optical Network with VLAN and QoS
How an OLT Splits Upstream Bandwidth Across 100 ONUs with DBA
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
