Sebastian Sattler
Senior Systems Engineer
Blog

New TSN Standards Like IEEE 802.1CB Highlight Importance of Having the Right Test Solution in Place

July 16, 2020 by Sebastian Sattler

While working with a customer who was using low-end, low-budget traffic generators, it turned out that just sending packets was not enough to fully analyze a time-sensitive networking (TSN) protocol implementation. Full device verification requires packet timing and implementation of protocol functions, including negative testing capabilities.       

The development and testing of devices supporting the different TSN standards are moving forward. With a focus on automotive Ethernet, industrial automation (IIot, Industry 4.0), or 5G fronthaul, different parts of TSN are used for different applications. Now, as functions like clock synchronization, filtering, policing, prioritization, queuing, and configuration management become more mature, the focus moves to the next level of reliability. Automotive and industry automation developers are starting to implement and test IEEE 802.1CB, a standard defining methods for redundant packet transport. It defines how packets are duplicated on the first switch in the redundant path (1) to be sent on different routes and how the elimination of the duplicated packets is handled on the switch of the receiving side (2). 

1

Packets are duplicated at (1) and dropped at (2)

For testing all aspects of the redundancy concept and implementation, three main scenarios are given.

  1. Testing the full scenario from end to end. This means the test system is sending packets and comparing them with the received packets on the receiver ports. In this scenario, Replication and Elimination is handled by the SUT (System under Test) and the test solution is just verifying the functionality as a black box test.2
  2. Testing the correct duplication of the packets in the switch (1). Here the test system needs to be aware of the concept of labeling duplicated packets using the R-tag in the 802.1 CB header
  3. Testing the correct De-duplication or Elimination of the packets in the last switch of the redundancy line. Here, the test system needs to generate packets on two ports that look like duplicated packets as described in the standard. R-Tag and Sequence Number need to be added correctly to the packets to verify several aspects of the Elimination functionality implemented on the switch. 

For all three scenarios, adding wrong parameters or sending packets out of standard in a controlled way is important to verify the stability and reliability of the functions. 

But just sending packets is not enough, timing is the key.

In the implementation of the switch vendor mentioned above, the device uses a time window in which the switch recognizes packets as duplicates by analyzing the R-Tag and sequence number. Packets that are delivered out of the window will not be recognized as duplicates. Similar mechanisms are implemented in most switches supporting 802.1CB.

In the switch vendor case, they had no chance to verify the correct implementation and setting for this window as the traffic generator was not able to send out packets in a dedicated time or delay the packets of the redundant stream over the main packets stream. From interoperability testing, they also observed some issues when delayed packets have CRC (cyclic redundancy check) errors. There is no chance to validate if the implemented fixes are solving the issue. Running this test and verifying the correct functioning of the DUT took just a few minutes with a system offering the right capabilities. Solving these kinds of issues once the code is implemented in the final chip and already integrated into customer solutions is highly time-consuming, and unbelievably expensive or just impossible to fix.

It’s just a few steps to configure advanced IEEE 802.1CB test cases

For testing the correct implementation of the elimination, correct length of the time slot, and reset of the window—it is required to delay one of the redundant streams in a controlled and repeatable way. As timing is critical, the delay needs to be set exactly on a nanosecond base. 

3

With Keysight’s IxNetwork application + Novus load module combination, it’s quite simple to configure a start delay for each configured stream. This feature, that is also required for testing time-aware shapers and scheduled traffic, can be found in IxNetwork’s “Traffic Wizard” in the “Rate Setup” section in “Flow Group transmission Mode”. 

4

Also, direct configuration in the Flow group overview, that shows all configured flows, is given. At this screen, it’s also possible to modify the packet headers, in this case VLANs and R-Tags might be helpful, or set frame size and packet rate.

5

Using these tools makes it easy to verify all aspects of “Frame Replication and Elimination for Reliability”—especially for handling negative scenarios to ensure a stable and reliable functionality of the 802.1CB redundancy mechanisms and implementation.

To achieve a more complete coverage of use cases and scenarios to develop a stable and bug-free device, Keysight offers several tools to help test engineers execute their test work in a fast, structured, and reliable way. For more advanced and complete test plans, we recommend you leverage Keysight’s experience and involvement in many plugfests and early adopter discussions by using the ready-to-run test plans covering tests standardized by AVNU or Autosar, as well as the many additional test cases maintained and collected by Keysight. Switching from the automated test cases to a manual test is always possible—use the test cases for deeper troubleshooting based on the exact test procedure from the conformance test.