In the comments of my last post on X, a fellow reader suggested that it would be helpful to go over some of the concepts surrounding IPTV to provide a bit better context around the previously diagnosed problems and discovery that accompanied my previous troubleshooting post.
I have had the good fortune to work with IPTV in a multicast environment in both service provider and enterprise environments. Both are heavily reliant upon IP Multicast for live content distribution. This shouldn’t be confused with virtually every other streaming service out there (e.g. Amazon Prime, Apple TV+, Max, etc.) which still relies on per-user stream delivery.
I expect most of this will be old hat for my peers in the NetEng community, but I’ll go over a couple things here.
Unicast vs. Multicast vs. Broadcast
In the IPv4 world, there are three types of frames used when placing information on an Ethernet network. This is a quick review:
Unicast
A unicast packet represents a one-to-one flow of traffic between a sender and a receiver. In an IPTV sense, this is the kind of traffic that is most people will commonly use. Netflix, YouTube, Twitch, and nearly all others stream individual programs to each concurrent viewer. Optimizing bandwidth for hundreds of thousands of concurrent viewers has led to incredibly efficient, albeit highly compressed, codecs.
Multicast
A multicast packet represents a one-to-many flow of traffic between a sender and a receiver. In a multicast network, the sender only sends a given program once. The network replicates the multicast packets ensuring all requesting receivers can receive the full program. Multicast networks only send the data to hosts that request a given program. Since only one copy of a program needs to be sent, a codec can be selected that provides more favorable latency and higher visual quality.
Multicast can also operate in a many-to-many manner where hosts are not just members of a multicast group, but also participants in sending data to the group. True many-to-many mulitcast networks and applications are very rare.
Broadcast
A broadcast packet represents a one-to-all flow of traffic between a receiver and every host on a given subnet or broadcast domain. A major downside of broadcast traffic is that it must be processed by every host which can be massively inefficient.
I added broadcast for completeness. It’s worth mentioning that in IPv6 the notion of broadcast traffic is eliminated. Any IP functions that are in broadcast in IPv4 are now multicast in IPv6.
Multicast Groups and Addressing
Multicast uses the concept of groups. A group represents a flow of packets that are meaningful to a group of recipients. Since this blog is focused on IPTV, we’ll consider each group to be a given program that a set of viewers want to watch.
In order to use these groups for an indeterminate number of receivers, each group is represented with its own multicast address. Depending on the IP protocol version, the following address ranges cover what is a multicast area:
- IPv4: 224.0.0.0/4
- IPv6: FF00::/8
These are the aggregate areas for multicast space, and there are many reserved addresses and spaces for multiple functions. For instance, multicast traffic is heavily used for network routing (e.g. OSPF) and a number of other control protocols (e.g. Bonjour, mDNS).
Within IPv4 space, the first address block I’ll focus on is the Source-Specific Multicast range at 232.0.0.0/8. This is for multicast groups where the address of a transmitter to that group is known to the receivers, which is nearly always the case in IPTV environments.
The second space is the administratively scoped address range of 239.0.0.0/8. While using this space does have some guidelines for its use (RFC 2365, section 6), it is often handled however a given organization desires to use the space. In my cable days, each of the network regional areas was assigned a /16 from the admin-scoped range to use for its programs.
Further Reading:
- RFC 2365 – Administratively Scoped IP Multicast (ietf.org)
- RFC 4607 – Source-Specific Multicast for IP (ietf.org)
- RFC 5771 – IANA Guidelines for IPv4 Multicast Address Assignments (ietf.org)
Multicast Control Plane
Joining A Group
The first step to receiving a multicast program is becoming a member of a group. This is quite an old concept which was first brought to light way back with RFC 988 in July of 1986. Even with the revisions and refinements to IGMP since that time, the concept remains the same. A host which wants to receive a program sends a request to join a group, which the network facilitates.
A deeper discussion can be hand on exactly how the network achieves this end. Through a combination of IGMP snooping on the switch layer, and through rendezvous points on the network layer, a given program can be located and replicated to its intended recipients.
IGMPv3 and Source-Specific Multicast
IGMPv3 extended the capability of IGMP in a very important way where IPTV is concerned: It allowed a host to specify a known source address for a given multicast group. This presented a couple of distinct benefits for any routed network.
A multicast network based entirely on SSM stream delivery does not need any sort of rendezvous point, RP discovery, or PIM Bootstrap router discovery enabled. This reduces complexity in the control plane easing supportability. With the source address known, multicast routers build the multicast path back to the source of a program via the protocols that make up their routing tables.
Another benefit to using IGMP and SSM is that a given group can be reused. While my memory is a little fuzzy, this was something I used primarily for redundant bulk encryptors on the cable network. The only configuration difference between the programs was the source IP used. By only changing the source IP, the reduction of typos was rather substantial.
Notes on Assignment
One idea worth mentioning when assigning multicast groups is to do so with one group per program. While this may seem obvious, I have witnessed at least one vendor load up a ton of programs onto a single multicast group where each channel was its own UDP port.
The resulting traffic absolutely obliterated the GQAM transmitter that was supposed to be used. What should have been a steady stream of around 150mbps of IPTV traffic was upwards of 700mb of requested traffic.
Further Reading:
- Multicast routing – Wikipedia
- RFC 988 – Host extensions for IP multicasting (ietf.org)
- RFC 3376 – Internet Group Management Protocol, Version 3 (ietf.org)
ASM Control Streams
The enterprise environment I am currently in first used multicast IPTV to deliver video programming to patient rooms using specifically provisioned systems provided by one of our vendors. This initially used SSM and the multicast content was delivered over a dedicated MPLS tenant with mLDP and other cool features.
However, all good things tend to extend beyond their original scope. When the demand for IPTV went beyond patient rooms, we moved the program sources to be carried on the global routing table.
Once we started to add in commercial televisions by LG and connected other standalone HDMI televisions and monitors with small set-top box (STBs) from ZeeVee, we now needed to support any-source multicast. This is due in part to the STB capability to grab information for the program guide, as well as any provisioning information that eliminates the need to individually configure and manage every last device.
Recently, we added the transmission of our channel lineup via SAP beacons, which are readily tuned in VLC.
Headend Equipment
The kind of equipment in a given headend is likely to vary depending on the environment.
In a previous life mine in Cable (2007-2012), many programs were received by satellite and sent out via DVB-ASI connections. PEG (public, educational, government) access channels and analog terrestrial broadcasts were often encoded at the headend as they were right from NTSC. New HDTV transmissions were taken from ASI and ATSC. Equipment from BigBand Networks, EGT, RGB Networks, Scientific Atlanta, and others was used to handle all the ingestion from analog and MPEG-2 sources.
At this point in time, nearly all of what I used and configured back then is ancient history and obsolete equipment.
In the much smaller enterprise environment that I currently work on, we have a collection of DirecTV receivers which output 720p HDMI which is then encoded into individual MPEG-4 streams. Equipment from ZeeVee and Castus provide the lion’s share of the video content to the network. A Raspberry Pi is used to advertise non-ZeeVee sources to the ZeeVee STBs as well as generate SAP beacons for VLC receivers. Finally, an LG ProCentric server is used to populate the information for all lobby and common area televisions.
I imagine in a not-so-distant future, we will receive all our television programming over IP. However, we expect that we are at least a year or two away from decommissioning the coaxial plant.
Further reading:
Acknowledgements
- Steve Drzaszcz (X: @stevedrz) for the topic suggestion.
- Daniel Dib (X: @danieldibswe) for technical feedback.
This post originally appeared on Underwood HQ.