mirror of
https://github.com/rtbrick/bngblaster.git
synced 2024-05-06 15:54:57 +00:00
218 lines
6.8 KiB
ReStructuredText
218 lines
6.8 KiB
ReStructuredText
.. _multicast:
|
|
|
|
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.
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"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:
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"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 :ref:`BNG Blaster header <bbl_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 :ref:`command <api>`
|
|
``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``
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"status": "ok"
|
|
}
|
|
|
|
``$ sudo bngblaster-cli run.sock igmp-info session-id 1``
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"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``
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"status": "ok"
|
|
}
|
|
|
|
``$ sudo bngblaster-cli run.sock igmp-info session-id 1``
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"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.
|
|
|
|
.. code-block:: json
|
|
|
|
{
|
|
"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
|
|
}
|
|
}
|
|
|
|
.. include:: ../configuration/igmp.rst
|
|
|
|
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! |