In this section, we summarize the results and observations collected during the interoperability test. In general, functionality test goals in the multi-vendor TVoDSL environment were reached. Some interoperability issues and future test areas were identified.
Results of Service Tests
The end-to-end quality of service (QoS) test verified if video quality (multicast traffic stream) was maintained with high priority even when the link between DSLAM and DSL modem was saturated and further oversubscribed with emulated unicast Internet traffic.
All devices involved in the test ultimately passed it, but surprisingly we faced initial configuration issues in all cases. In one case, there was additional configuration necessary to tag multicast IP packets in order to prioritize them; in another case, the ATM traffic management configuration of the systems under test was incorrect. Clearly, the technology is available but from our point of view it is important to verify correct QoS configuration in triple play networks today.
During the interoperability test, all configuration was done manually and via CLIs / GUIs. The issues emphasize that it is important to use an efficient management system for triple play service provisioning.
When these issues had been sorted out, the devices showed correct oversubscription behavior. To evaluate if prioritization works as expected, we generated a prioritized multicast stream of 1518 Byte packets with the load generator. The test showed the expected results: only unicast frames were dropped in the overload situation while multicast TV packets were prioritized.
The results of link oversubscription tests with two parallel multicast streams were as expected, no stream was prioritized over the other and so packets from both streams were discarded.
Results of Transport Tests
In this section, the vendors verified the functionality, interoperability and scalability of their Ethernet/IP multicast implementations. At first, basic IP multicast stream transport from the DSLAM to the modem was evaluated, including the test of IGMPv2 for a channel switchover at the DSLAM.
This basic test worked well in some combinations, but uncovered an IGMP interoperability issue with one of the Annex B modems. The modem vendor accepted the issue and planned to solve it in the next software release. It appears that multicast transmission was not an initial design goal for all modem vendors.
We were unable to run the next test case dealing with multicast transmission over an ATM backbone, scalability for multiple IP multicast streams in parallel, and the ability for DSM-CC to IGMP conversion: The participating DSLAM vendors provided only Ethernet uplinks for the test. For this reason, the generic test setup for all following tests used Ethernet links only, as shown in the diagram on the right.
The DSLAMs showed outstanding scalability and robustness in the next test, verifying the maximum simultaneously active number of IP multicast streams (video channels). All DSLAMs under test scaled to their documented design goals without any issues, supporting a maximum of between 255 and 1024 multicast streams. Given the limited number of DSL modems available, the test ran all streams in parallel over a few modems only, each using a very low rate - making this test an IGMP signalling and multicast cache size test, not a data plane performance test for the DSLAMs.
For the same reason - number of available modems - the maximum number of simultaneous IP multicast subscribers for one stream could not be tested in practice. A very large number of modems would have been required to verify that the DSLAM can replicate a multicast stream to all ports simultaneously. To our knowledge, there is unfortunately no IP load generator in the industry attaching directly to the ADSL/ADSL+ lines of the DSLAMs. All DSLAM multicast scalability tests are still expensive to carry out and difficult to manage.
The next test we executed, showing the zapping time under load, will certainly remain one of the most critical DSLAM and DSL modem multicast performance tests in the foreseeable future. The time it takes a CPE device to join/leave multicast streams while the DSLAM is fully populated with incoming streams and subscribers, and running a large number of active IGMP instances, is an extremely important parameter for customer satisfaction. During our test, we were able to measure join latencies only with a single active modem and one multicast stream. The join latencies were very promising, between 13 ms and 230 ms. However it is difficult to predict behavior at full load based on these figures.
Finally, we verified the Quality of Service on the xDSL link using either a single virtual channel (VC) for all applications or multiple VCs for different applications. One participating vendor ran the prioritization on the DSLAM uplink module based on IP TOS bits. On the ADSL link, the stream used only one ATM PVC. To realize QoS the packet need to be queued according to their traffic profile before being transmitted over the PVC. Another participating vendor classified the traffic based on VLAN or IP TOS information and mapped the traffic to different ATM PVCs with different service classes like UBR or VBR-rt for transport over the ADSL link. With both solutions we successfully verified that a prioritization of a multicast stream over a data stream was possible.
