An IPTV channel needs one stream from the source and one delivered copy for each viewing household. Where the network makes those copies determines backhaul bandwidth, membership state and the scope of a forwarding mistake. Choosing a replication point is therefore a service architecture decision, not just a multicast checkbox on a BNG.
This article analyses the general design choices. Netavo does not itself perform IGMP membership tracking or multicast replication. Multicast is punted/policed in its pipeline. In a Netavo deployment, IPTV membership and replication belong in a suitable access or aggregation layer, with a delivery path designed around that boundary.
Follow one channel from source to screen
Imagine a channel source sending an 8 Mbit/s stream. A multicast routing domain carries it towards access regions with interested receivers. At each branch, a multicast-capable forwarding device sends copies only onto the required downstream interfaces.
Near the subscriber, the network must know which household wants that channel. The receiving device expresses interest through membership signalling. A router or proxy maintains the relevant listener state, while a multicast-capable access switch can constrain delivery to interested ports.
The last step is subscriber delivery. On a shared Ethernet service, the access switch may replicate the stream towards several subscriber ports. On a PPP service, delivery requires equipment that understands the subscriber sessions or a separate IPTV service path. A generic switch does not turn a multicast packet into correctly encapsulated copies for arbitrary PPPoE sessions.
Routing, membership and snooping do different jobs
Multicast routing chooses distribution paths
Routing determines how traffic from a source reaches downstream networks that need it. It owns the distribution tree between routed interfaces. Unicast reachability to the source and the multicast design must agree sufficiently for the chosen routing scheme to work.
For operations, the useful questions are concrete: where is the source accepted, which upstream interface is expected, and which downstream interfaces should receive the channel? A correct subscriber membership table cannot repair a missing distribution path in the core.
IGMP describes receiver interest
IGMP handles IPv4 group membership between hosts and their adjacent multicast router. IGMPv3 supports source filtering, allowing receivers to express interest in traffic from particular sources as well as groups. The protocol and membership state machinery are specified in RFC 3376.
An IGMP proxy maintains downstream listener information and presents appropriate membership upstream. It can consolidate requests from many subscribers, but it must retain enough downstream state to avoid withdrawing a channel while someone still watches it. It is an active participant in membership, with an explicit upstream/downstream relationship.
Snooping constrains Layer 2 forwarding
IGMP snooping observes membership exchanges and uses them to limit multicast forwarding on switch ports. It is distinct from routing and from an IGMP proxy. A snooping deployment also needs a functioning querier arrangement so membership remains current.
Check the switch's handling of source filters, router ports and unknown multicast. A design that looks correct during the first join can flood after state expires, or stop forwarding when a querier disappears. Packet delivery and membership refresh need separate verification.
Compare the replication locations
| Replication location | Bandwidth consequence | Channel-change considerations | Failure scope |
|---|---|---|---|
| Central core or service edge | Per-subscriber copies can consume downstream backhaul | Central membership processing and signalling path | A shared state error can affect many access regions |
| Multicast-capable BNG | Copies sent into individual subscriber sessions | Session-aware admission and membership processing | Incorrect subscriber or group state affects its service population |
| Access or aggregation | Shared streams travel further before copying | Local handling can reduce signalling distance | Port and branch state can contain errors locally |
These are architectural tendencies, not latency guarantees. Hardware queues, membership timers, upstream availability and the video encoder's keyframe interval all influence how quickly a viewer sees a picture.
For the illustrative 8 Mbit/s channel, 100 separate downstream copies consume about 800 Mbit/s before encapsulation overhead. If those viewers sit behind one aggregation branch, carrying one shared copy to that branch uses about 8 Mbit/s on its uplink. Replication still consumes capacity on the final subscriber-facing links.
Repeat the calculation with the number of distinct channels watched per branch. One popular channel gives a very different aggregation benefit from 100 households watching 100 different channels. Include encapsulation and operational headroom when turning the model into a link budget.
The bad-leave problem defines your state boundary
When one receiver stops watching, the network must remove only the delivery that is no longer needed. If several receivers share a downstream interface, a leave from one cannot safely imply that every receiver has left.
Fast-leave behaviour can be useful on a port known to have one receiver. Apply it carelessly behind a household switch or another aggregation device and one viewer can interrupt another. The decision depends on what the port represents, not just on a desirable channel-change time.
At a proxy, the same principle applies upstream. The proxy should stop requesting a channel only when no relevant downstream membership remains. A fault that collapses several subscriber states into one can widen a local leave into an outage for an entire branch.
Fast leave is safe only when the device's receiver model matches the actual topology; a port can represent more than one listener.
Test simultaneous viewers, overlapping joins and leaves, membership expiry and device restart. Count who loses video during each event. That observable blast radius is more useful than a feature label.
IPTV over PPPoE needs an explicit service path
PPPoE gives each subscriber a point-to-point session. A shared multicast Ethernet frame does not automatically become traffic delivered inside those sessions. Session replication requires a capable termination device and an agreed model for membership, encapsulation and policy.
An alternative is a separate multicast IPTV VLAN or equivalent access service alongside the subscriber's Internet session. In that design, the access or aggregation platform owns multicast delivery, while the BNG handles the Internet service. The CPE must map the IPTV service to the intended receiver and preserve the required isolation.
For Netavo, design that access/aggregation IPTV path explicitly. Punt/police handling is not a multicast distribution service and should not be treated as one. Verify that the intended video traffic reaches receivers through the multicast-capable equipment without depending on Netavo to replicate or track IGMP listeners.
Validate the service rather than the feature list
Start with one channel, one receiver and a capture at each boundary. Then add a second receiver on the same branch and another on a different branch. Confirm where stream counts increase and where they remain shared.
Measure join-to-first-packet separately from join-to-picture. Exercise a leave while another viewer remains, remove the querier, interrupt the upstream feed and restart the replication device. Include service admission, channel entitlement and per-subscriber isolation in the wider design; snooping alone does not provide those policies.
Use the results to place replication where bandwidth savings, manageable state and failure containment meet your service requirements. Netavo's role remains the subscriber Internet BNG alongside the multicast-capable access or aggregation system.
Plan the Internet service with a Netavo evaluation, and use the documentation to define the BNG boundary in your IPTV architecture.