8 min read
This guide describes the IP multicast testing features in CDRouter and the role of IGMP (Internet Group Management Protocol) in CPE networks. CDRouter supports multicast testing using IGMP version 3. Although many CPE devices have support for IP multicast and IGMP, new functional requirements for set-top boxes and other IPTV multicast applications are pushing the adoption of IGMPv3 into the CPE networking space.
Several different industry technology bodies including the Broadband Forum and CableLabs (DOCSIS) have defined the use of IGMPv3 for CPE devices. IGMPv3 has many improvements over earlier versions of IGMP that make it more attractive for set-top box applications. In order to work well with newer set-top box devices, CPE devices are adopting IGMPv3.
IGMP is used by end hosts to join and leave IP multicast streams. The protocol defines a “host” mode and a “router” mode. The “host” mode is run on an endpoint that wishes to receive multicast traffic. The “router” mode is run by a routing device that may forward multicast traffic to hosts. In a typical CPE device, the CPE runs “router” mode on the LAN side of the device and “host” mode on the WAN side of the device. This is known as an IGMP proxy.
The first version of IGMP contained a simple technique for hosts to join a multicast group by sending an IGMP membership report. The host maintains its membership in the group by responding to IGMP queries from the router. When the host wishes to leave the group, it stops responding to IGMP queries and the group membership eventually times out.
IGMPv2 improved the leave latency by adding an IGMP leave message to allow the host to explicitly leave a multicast group. IGMPv1 is rarely encountered today and most protocol stacks support at least IGMPv2.
GMPv3 improves on IGMPv2 by adding source filtering and the possibility of multiple membership reports in a single protocol packet. One weakness of IGMPv2 is the host’s inability to specify which source is allowed to send the multicast traffic. If an IGMPv2 host joins a multicast group, any source in the multicast network may send to that group. Security and filtering must be handled by some other means. This has a huge implication when it comes to deploying multicast across a public or operator network. IGMPv3 solves this problem by allowing the multicast receiver to specify specific sources when joining a group. This source information can be reported to the multicast routers to set up the correct filtering.
IGMPv3 also reduces the number of IGMP protocol packets needed by allowing multiple membership reports in a single packet. This has a big impact on channel change latency which is an import metric of IPTV networks. With IGMPv2, a multicast receiver must send an IGMP leave followed by a new IGMP membership to change from one multicast channel to the next. IGMPv3 improves this situation by allowing the IGMP leave and new membership to be carried in the same packet. This reduces the amount of IGMP traffic required on larger multicast networks.
CDRouter supports IGMPv3 and includes several test cases to test both IGMPv2 and IGMPv3 specific functionality. The IGMPv3 specific test cases cover source specific multicast, multiple record reports, and IGMPv3 group scaling. Along with IGMPv3 test functionality, CDRouter’s multicast test module includes IPTV channel change test scenarios that simulate channel changing behavior.
Before getting started with multicast testing, CDRouter should be configured to match the IGMP configuration of the CPE device. CDRouter supports both IGMP proxy testing and simple pass through implementations. Pass through implementations simply apply NAT to outgoing IGMP packets and do not actually act as either an IGMP host or router.
To enable multicast and IGMP proxy support:
testvar supportsMulticast yes testvar multicastType proxy
CDRouter can run with either IGMP version 2 or version 3. The IGMP version is configured with the igmpVersion testvar. If not specified, CDRouter uses IGMP version 2.
testvar igmpVersion 3
CDRouter can test support for multiple IGMP groups. The Broadband Forum’s TR-124 recommends that a device support at least 32 multiple groups and recommends 64 groups. The igmpMaxGroups testvar can be used to verify this requirement.
testvar igmpMaxGroups 64
To work with both IGMP proxy and pass through implementations, CDRouter defines a multicastCacheTimeout testvar to specify the amount of time between a host leaving a multicast group and stopping the forwarding of this multicast traffic. For IGMP proxy implementations, this amount of time is usually based on the IGMP last member query interval and the IGMP last member query count. These two values are used to define the “leave latency” for the multicast router. Generally, the default leave latency is a few seconds so CDRouter’s default value for the testvar multicastCacheTimeout is usually sufficient. If the CPE device is using a higher leave latency, the multicastCacheTimeout can be increased to accommodate the device.
testvar multicastCacheTimeout 10
CDRouter also allows you to configure the IGMP query interval, robustness variable, and query response interval. These parameters defined by both RFC 2236 and RFC 3376 and are used to determine when a multicast group should be aged out.
testvar igmpQueryInterval 125
testvar igmpRobustnessVariable 2
testvar igmpQueryResponseInterval 10
CDRouter’s new IPTV channel change tests allow you to configure the number of channels that should be attempted, the millisecond delay between changing channels, and a failure count to stop the test.
testvar iptvChannelRange 200
testvar iptvChannelChangeDelay 200
testvar iptvMaxFailures 10
Several of CDRouter’s multicast tests allocate unused multicast addresses to use for multicast groups. CDRouter uses the multicast pool defined in your configuration file. The multicastPoolStart and multicastPoolStop testvars can be modified to change this allocation range.
testvar multicastPoolStart 188.8.131.52
testvar multicastPoolStop 184.108.40.206
CDRouter contains a few other multicast related configuration options that can be modified.
Some IGMP devices support IGMP Fast leave which allows the IGMP router to immediately remove an interface from a multicast group after receiving an IGMP Leave for the group. Unlike normal IGMP behavior, the IGMP router does not send an IGMP group specific query after receiving the IGMP Leave. IGMP Fast Leave only works when the router knows there is only a single IGMP host on a port. IGMP Fast Leave is usually enabled when the device is also using IGMP Snooping to detect the number of IGMP devices on a port. CDRouter’s multicast tests will work with or without IGMP snooping.
CDRouter supports IGMP Fast Leave behavior by setting the testvar igmpFastLeave to yes.
testvar igmpFastLeave yes
The IPv4 Router Alert Option can be turned off using the testvar igmpRouterOption. Both IGMPv2 and IGMPv3 define the use of the IPv4 Router Alert Option in all IGMP packets.
testvar igmpRouterOption no
If a device does not support outbound multicast traffic through NAT, the testvar supportsMulticastOut can be set to no to automatically skip outbound multicast testing.
testvar supportsMulticastOut no
IGMP is a layer 3 protocol, but the addition of IGMP snooping on layer 2 devices allows them to perform the same multicast functions enabled by IGMP by monitoring IGMP traffic and determining which links need which multicast streams. IGMP snooping support in CDRouter allows you to perform IGMP test cases on a device that is a bridge or configured for bridge mode broadband access. To enable this, CDRouter is set up to expect the DUT to be in bridge forwarding mode and be acting as a multicast proxy.
testvar forwardingMode bridge
testvar multicastType proxy
Beyond running all the multicast test cases in the mcast.tcl module, there are few other testing ideas that can help with your multicast testing
IGMPv3 is defined to be backwards compatible with IGMPv2 and IGMPv1. A device running IGMPv3 router mode should drop back into IGMPv2 on a per group basis when it detects an IGMPv2 device. If the device you are testing supports IGMPv3, it is import to run CDRouter using both IGMPv3 and IGMPv2. When CDRouter is running with IGMPv2, but the device is configured for IGMPv3, the device should drop into IGMPv2 compatibility mode and all IGMPv2 test cases should still pass.
The new IPTV channel change test scenarios can be used to simulate set-top box channel changing based on multicast. The testvar iptvChannelChangeDelay can be adjusted to simulate rapid or slow channel changes. It is also possible to set a delay of 0 and quickly cycle through the channels. If the device only supports a limited number of multicast groups, the total number of groups may be exceeded before the device can cycle through all channel changes.
CDRouter contains useful options for repeating test cases and shuffling the test case order. Both of these options are helpful for improving the robustness of your multicast implementation.
CDRouter allows you to combine multicast testing with other application testing. This can be done by building a test package including multicast and other test modules. Use the “shuffle” option to mix up the order of test cases so that multicast testing will be mixed in with other application testing.
The adoption of set-top boxes with IP multicast functionality is driving the implementation of IGMPv3 in CPE devices. Along with testing all CPE functionality, CDRouter plays an import role in qualifing CPE devices with IGMPv3 support.