Configuring and Securing Time-Sensitive Networks
When Ethernet was first developed, it was under a plug-and-play model where all devices that needed to be on the local area network (LAN) had to be connected to a central router using Ethernet cable. As technology advanced and Time-Sensitive Networking (TSN) Ethernet was developed, plug-and-play was no longer needed. TSN switches and end devices must be enabled and configured to closely synchronize communications between devices, especially for mission-critical data exchanges. Configuration includes enabling TSN mechanisms, such as time synchronization and the Time-Aware Scheduler and then adjusting cycle times, time slots, frame priorities and other parameters according to the application’s requirements.
When dealing with nearly any large enterprise Ethernet network these days, the difference between plug-and-play Ethernet and non-plug-and-play TSN is barely an issue. Most of today’s enterprise and automation networks require engineering and configuration. TSN increases the amount of configuration that’s necessary to get a network running, but also brings lots of benefits to the table in return.
Choosing a Configuration Approach: Auto or Manual
Although manual setup and configuration of a small time-sensitive network is possible, configuration typically is mostly automated. The end devices announce their requirements and all TSN switches and devices between those end devices are configured automatically through the following three-step process:
- All TSN supported mechanisms in the network that the application requires are identified and enabled
- The sending device (talker) announces requirements about the data it’s ready to send, such as required bandwidth and acceptable latency
- The receiving device (listener) calls for and receives the data in accordance with the talkers requirements
It is important to note that manual configuration is also an option. Just as human operators have always done with engineered networks, they can configure a small TSN. Manual configuration may be practical for networks that are mostly static (those that can be engineered and configured once and will never change in their operational lifespan), such as critical functions in the design of an in-vehicle car network.
However, TSN was designed to cover much larger and more dynamic networks as well, such as IIoT networks. In networks such as these, TSN must account for movement of network participants, such as autonomous guided vehicles, workers and robots. For these more complex applications, having a person handle the configuration may not be practical, in which case a mechanism must be in place to automate the configuration process.
Choosing a TSN Configuration Model
The configuration mechanism may provide central control, allow for decentralized control or take the middle ground with a hybrid approach depending on the TSN configuration model.
In the centralized TSN model, the end devices announce their requirements to a central user configuration (CUC) instance, which can be done through an automation protocol.
The CUC aggregates all information regarding the end devices and their communication requirements. A CUC can be envisioned, such as an automation support application that is running on a tablet, PC or terminal. A second entity, called the centralized network configuration (CNC), assembles all information from the network infrastructure, such as the number of switches present, the physical and logical topology, the TSN mechanisms and the available bandwidth. The CNC can be envisioned as a network support server or program.
Using the details collected about the communication requirements and the available network resources, the CUC computes a network configuration that accommodates all end devices. Assuming the CUC computes a feasible configuration, the CUC pushes the configuration to the network infrastructure through the CNC. If the CUC can’t compute a network configuration that meets all of the application’s TSN requirements, it announces the failure to the user who can then take corrective action.
The advantage of centralized TSN is that it supports large network infrastructures with dynamic device movement. Through the CUC and the visibility of all devices and all communication requirements, a user or device can tell immediately whether a network configuration is feasible or not.
The disadvantage of the centralized model is that it requires dedicated infrastructure that houses the CNC and CUC. However network management systems, such as Hirschmann Industrial HiVision, are commonplace in large industrial network infra-structure installations, so this disadvantage rarely restricts the use of centralized TSN in industrial automation applications.
In the decentralized TSN model, the end devices transmit their requirements for sending and receiving TSN communication streams to the first TSN switch each is connected to. This switch receives the information, evaluates it and distributes it across the network through any other switches. Ultimately, all end devices are informed about the data streams offered in the network and the requests to receive certain streams.
When an offer and a request in the network match, the end devices and switches automatically establish the connection and process frames according to the parameters agreed upon by the two end devices.
This decentralized approach has the distinct advantage that the TSN switches require very little manual configuration. The mechanisms for registration and deregistration are well proven, because they’re based on the AVB Stream Registration Protocol. This protocol enables dynamic changes in the network, such as adding, removing and moving devices automatically, while the network is operational.
The drawback to decentralized TSN is that on larger networks, conflicts between the requirements of different devices and streams become more and more difficult to resolve. A decentralized network has no CUC or CNC to coordinate activities among the network devices.
One model does not have to be the exclusion of another. There is an opportunity to combine the centralized and decentralized TSN models. For example, it may be true that centralized TSN is best for one part of the network, while decentralized TSN works better for other parts of the network.
The advantage of the hybrid model is that the end devices need to support only one configuration protocol (this is the same in the decentralized and hybrid models), although the user has the benefit of a CNC, just as with the centralized model.
Addressing Security Issues
TSN doesn’t specifically include cybersecurity mechanisms because security is outside the scope of basic Ethernet. Unfortunately, TSN presents new attack surfaces that were not present with Ethernet before. The largest attack surface is time synchronization, a successful attack on this mechanism would be a very effective denial of service (DoS) because TSN can’t operate without synchronized clocks on all devices.
Another aspect that makes cybersecurity slightly more complex in TSN networks is that many security mechanisms introduce additional latency and jitter into the network. Latency and jitter can be unacceptable for TSN, especially with cycle times in the low millisecond range or even lower.
Fortunately, methods are available to secure time-sensitive networks without compromising deterministic data transmission. Below are two methods to provide necessary protection:
- Segmenting traffic with zones and conduits – IEC 62243
- Filtering and policing traffic by stream – IEEE 802.1Qci-2017