Multicast and IPTV
The BNG Blaster provides advanced functionalities for testing multicast over PPPoE sessions with a focus on IPTV. Therefore IGMP versions 1, 2 and 3 are implemented with support for up to 12 group records per session and 3 sources per group.
Multicast testing is supported using external multicast traffic like real world IPTV traffic or by generating multicast traffic on one of the network interface functions.
Generate Multicast Traffic
The BNG Blaster supports different ways to generate multicast traffic using autogenerated traffic enabled in the igmp configuration section or by manually defined RAW traffic streams.
The following example shows how to generate traffic for 100 multicast groups with one packet per millisecond (1000 PPS) for every group.
{
"interfaces": {
"network": {
"interface": "eth2",
"address": "100.0.0.10",
"gateway": "100.0.0.2"
}
},
"igmp": {
"group": "239.0.0.1",
"group-iter": "0.0.0.1",
"group-count": 100,
"source": "100.0.0.10",
"send-multicast-traffic": true
}
}
It is recommended to send multicast traffic with 1000 PPS (default) per group to measure the join and leave delay in milliseconds.
It is also possible to generate multicast traffic using RAW streams as shown in the example below:
{
"streams": [
{
"name": "MC1",
"type": "ipv4",
"direction": "downstream",
"priority": 128,
"network-ipv4-address": "1.1.1.1",
"destination-ipv4-address": "239.0.0.1",
"length": 256,
"pps": 1000,
"network-interface": "eth1"
},
{
"name": "MC2",
"type": "ipv4",
"direction": "downstream",
"priority": 128,
"network-ipv4-address": "2.2.2.2",
"destination-ipv4-address": "239.0.0.2",
"length": 256,
"pps": 1000,
"network-interface": "eth2"
}
]
}
Using RAW streams allows generating streams distributed over multiple network interfaces with more options to modify the traffic.
Setting the destination-ipv4-address
of a stream to a multicast IPv4 address is enough
to generate proper multicast streams. All headers including the BNG Blaster header will be
automatically set for multicast. Therefore such streams can be also used to measure the IGMP
join and leave delay.
The BNG Blaster is recognizing loss using the BNG Blaster header
sequence numbers. After the first multicast traffic is received for a particular group,
for every further packet it checks if there is a gap between the last and new sequence number
which would be reported as a loss. The argument option -l loss
enables loss logging which
helps to search for the missing packets in the corresponding capture files.
Tip
It is also possible to start a dedicated BNG Blaster instance to generate multicast traffic only. This traffic can be consumed by multiple different BNG Blaster instances. The BNG Blaster header allows doing the same measurements on traffic generated from the same or different BNG Blaster instances.
Manual Join/Leave Testing
It is possible to join and leave multicast groups manually using the command
igmp-join
.
$ sudo bngblaster-cli run.sock igmp-join session-id 1 group 232.1.1.1 source1 202.11.23.101 source2 202.11.23.102 source3 202.11.23.103
{
"status": "ok"
}
$ sudo bngblaster-cli run.sock igmp-info session-id 1
{
"status": "ok",
"igmp-groups": [
{
"group": "232.1.1.1",
"igmp-sources": [
"202.11.23.101",
"202.11.23.102",
"202.11.23.103"
],
"packets": 1291,
"loss": 0,
"state": "active",
"join-delay-ms": 139
}
]
}
$ sudo bngblaster-cli run.sock igmp-leave session-id 1 group 232.1.1.1
{
"status": "ok"
}
$ sudo bngblaster-cli run.sock igmp-info session-id 1
{
"status": "ok",
"igmp-groups": [
{
"group": "232.1.1.1",
"igmp-sources": [
"202.11.23.101",
"202.11.23.102",
"202.11.23.103"
],
"packets": 7456,
"loss": 0,
"state": "idle",
"leave-delay-ms": 114
}
]
}
IPTV Zapping Test
A key element of IPTV services is the delay in changing channels. How long does it take to change from one channel to another, is the right channel received and the old channel stopped without overlap between the old and new channel? Overlapping channels may lead to traffic congestion if both channels are sent at the same time.
Verify that fast channel changes (zapping) work reliably as well.
The BNG Blaster can emulate different client zapping behaviors and measure the resulting join/leave delays and possible multicast traffic loss.
The join delay is the time in milliseconds between sending join and receiving the first multicast packet of the requested group. The leave delay is the time between sending leave and the last multicast packet received for this group. Multicast packets received for the leaved group after the first packet of the joined group is received are counted as overlap.
The following configuration shows an example of the igmp
section
for a typical zapping test.
{
"igmp": {
"version": 3,
"start-delay": 10,
"group": "239.0.0.1",
"group-iter": "0.0.0.1",
"group-count": 20,
"source": "100.0.0.10",
"zapping-interval": 5,
"zapping-count": 5,
"zapping-view-duration": 30,
"zapping-wait": false,
"combined-leave-join": true,
"send-multicast-traffic": true
}
}
{ "igmp": {} }
Attribute |
Description |
---|---|
autostart |
Automatically join after the session is established.
Default: true
|
start-delay |
Delay between session established and initial IGMP join in seconds.
Default: 1
|
version |
IGMP protocol version (1, 2, or 3).
Default: 3
|
combined-leave-join |
Per default, join and leave requests are sent using dedicated
reports. This option allows the combination of leave and join
records within a single IGMPv3 report using multiple group records.
This option applies to the IGMP version 3 only!
Default: true
|
group |
Multicast group base address (e.g. 239.0.0.1).
If group is set to 293.0.0.1 with group-iter of 0.0.0.2,
source 1.1.1.1 and group-count 3, the result are the following
three groups (S.G):
1.1.1.1,239.0.0.1, 1.1.1.1,239.0.0.3, 1.1.1.1,239.0.0.5
Default: 0.0.0.0 (disabled)
|
group-iter |
Multicast group iterator.
Default: 0.0.0.1
|
group-count |
Multicast group count.
Default: 1
|
source |
Multicast source address (e.g. 1.1.1.1).
Default: 0.0.0.0 (ASM)
|
zapping-interval |
IGMP channel zapping interval in seconds.
Default: 0 (disabled)
|
zapping-count |
Define the number of channel changes before starting
the view duration.
Default: 0 (disabled)
|
zapping-wait |
Wait for multicast traffic before zapping to the next channel.
Default: false
|
view-duration |
Define the view duration in seconds.
Default: 0 (disabled)
|
max-join-delay |
Maximum join delay in milliseconds.
If configured, the final report includes how often
the measured join delay is above this threshold.
Default: 0 (disabled)
|
send-multicast-traffic |
If enabled, the BNG Blaster generates multicast traffic on the
network interface based on the specified group and source
attributes mentioned before. This traffic includes some special
signatures for faster processing and more detailed analysis.
Default: false
|
multicast-traffic-length |
Multicast traffic IP length.
Only applicable with send-multicast-traffic enabled!
Default: 76
|
multicast-traffic-tos |
Multicast traffic TOS priority.
Only applicable with send-multicast-traffic enabled!
Default: 0
|
multicast-traffic-pps |
Multicast traffic PPS (packets-per-second) per group.
Only applicable with send-multicast-traffic enabled!
Default: 1000
|
network-interface |
Multicast traffic source interface.
Only applicable with send-multicast-traffic enabled!
Default: first network interface from configuration
|
Multicast Limitations
The BNG Blaster IGMP implementation supports up to 3 sources per group record and 12 group records per session.
The check for overlapping multicast traffic is supported for zapping tests only.
Multicast tests should be done without RX threads enabled for correct measurements!