It's a mouthful but it needn't be stressful: How to juggle software-defined networks and industrial IoT needs

Sponsored Software-defined networking (SDN) has shaken up networks, making infrastructure easier to configure and manage. But as the network’s composition changes, so you must change your network management practices – you can’t simply port over existing tools and techniques.

Add to the network an Industrial Internet of Things (IIoT) deployment, and you’ve got an even bigger challenge to meet: management of a new generation of devices.

But these aren’t devices in the traditional sense. These gadgets have fluctuating bandwidth demands, employ different protocols, and come with a lifecycle that’s yours to manage. Fortunately, to an extent, there’s SDN.

SDN is becoming a growing part of the IT sector, expected to grow in value from $4.4bn in 2017 to a market worth $15.8bn by 2022, according to research firm IHS Markit.

SDN is based on virtualising the way the network operates and making it programmable. It’s a shift away from the use of dedicated hardware with proprietary software to an environment where network connections, bandwidth, and new features can be added via the software.

That’s important when it comes to IIoT because you’re probably going to add a large number of extra devices to your network, making management and control a much more complex task than before. Adopting an SDN should offer the kind of flexibility and programmability that means your network can adapt to these new requirements relatively easily and without disruption.

Just don’t expect you can manage this IIoT using the same tools and practices of the pre-SDN world.

Meet the new management

The basic concept behind SDN is to decouple the control plane from the data plane of the network, where the data plane is responsible for routing traffic around the network while the control plane manages the data plane and the rules it applies for routing that traffic.

This architecture led to the development of protocols such as OpenFlow that specify a standard for how the control plane communicates with the data plane.

In practice, this may be implemented in the data centre with hardware switches operating as the data plane. It features a centralised SDN controller remotely managing each switch's packet forwarding tables and forwarding rules, communicated to them using a protocol like OpenFlow, an open standard developed by the Open Networking Foundation.

The advantage of this approach is that it provides for control using a set of policies, with administrators creating the rules to govern their network’s behaviour. These are enacted by the SDN controller, which uses them to respond to changing conditions or requirements from the application layer in order to provision new resources or reconfigure the data plane, for example. In other words, automation is a key part of how SDN operates.

This contrasts with a traditional network setup where each switch is effectively its own control plane and – largely – has to be manually programmed or configured using a remote console or some proprietary software provided by the switch manufacturer.

But this is just one deployment model for SDN. Another is that of the overlay network, where virtual network tunnels are created that are overlaid onto an existing physical network. This model is most often associated with platforms that operate virtual machines, which for the most part communicate with other virtual machines serving as part of the same application stack. It therefore makes sense for them to use a virtual network to isolate their traffic from everything else.

The advantage of this approach is that when change is required it does not call for large-scale upgrades to most of the network equipment. That’s because the physical network – or underlay – essentially serves as a high-bandwidth pipe to carry traffic between virtual tunnel end points, which are typically servers running virtual switch software.

The downside comes in the shape of added complexity, with potentially thousands or even millions of virtual networks operating across the physical network. This is why automated management based on policies, once again, becomes key rather than relying on manual configuration.

Further, it means network managers must begin to get to grips with virtualisation tools and technologies, and may need to take over responsibility for management of the virtual switches rather than the hypervisor administrators.

SDN meets IIoT

How does all this apply to IIoT, with its use of sensors and the application of modern IT to enhance manufacturing and industrial processes?

IIoT, or the industrial internet, is about broadly connecting hardware that may have once stood alone or that ran in groups on very closed networks, enabling devices to be remotely monitored and updated and letting you gather telemetry data on their operation that can then be analysed.

SDN comes into the picture because virtualising network functions and making them programmable means they can be reconfigured to deliver bandwidth as required – when new devices are added to the network, for example – and apply the necessary authentication and access rules.

So far, so simple, though let’s take data capture for advanced analytics. This requires sensor data streams to be routed to the appropriate storage or data analytics systems and that calls for rules to govern the flow of packets as outlined earlier. Yet IIoT poses a challenge when it comes to planning network capacity and bandwidth. Many IIoT devices may only send data in a burst at intervals. Automated SDN policies can allow for bandwidth to be allocated to such devices only as required, ensuring the best use of limited resources.

Another concern is security, with vulnerability of systems a big roadblock to rollout. A survey by consultants Bain & Company found that enterprise customers are limiting their investment in IoT because of potential security risks, with 60 per cent of respondents saying they were concerned about the dangers such devices pose to their companies.

Although not the answer to security, SDN can help in ways that would not be possible using legacy network technology and conventional network management tools and practices. For example, standards such as OpenFlow can ease security policy distribution among IoT devices, while the centralised controller can provide insight into where attacks happen, and use the reconfigurable nature of the data plane to segregate or block network paths where an attack is detected.

Rise of automation

One major area of difference between the tools of the pre-SDN world and now that we’ve touched on is automation. This is a major step forward but takes a change of tools and practices.

SDN has coincided with the rise of DevOps, which emphasises closer collaboration between those building the kinds of virtualised software running on SDNs and those running and managing it. Continuous lifecycle is a key part of DevOps, where software is built and maintained in such a way that resources, updates and changes are delivered automatically without need to request a change or submit a support ticket and wait for the IT team to act.

Automation is only going to become bigger. It provides a much-needed tool for admins to tackle the growing complexity of corporate networks as they gain more devices, carry more traffic and are segmented up more and more so that it becomes difficult for network operators to understand and manage the entire infrastructure.

Network managers should explore and familiarise themselves with the automated configuration management tools popular on the developer side of the DevOps fence. That is tools like Puppet or Chef that avoid the need to manually type commands at a console and either update network devices individually or see you plan rolling upgrades.

Organisations may find their IT staff somewhat ambivalent about automation. This is understandable given that they prefer to evaluate changes before rolling them out across the entire infrastructure to make sure they will not break anything or cause unexpected behaviour. It is possible that two different policy rules may conflict if care is not taken, for example, although there are tools that should be able to flag up such errors.

Not so middle management

Something that goes hand-in-hand with automation is monitoring. Yes, we had monitoring in the pre-SDN world but the challenge now is how to monitor network and application performance when the network topology can change several times a day. Adding further complexity is the need to monitor physical and virtual network environments.

With IIoT in the mix, monitoring tools take on greater importance than before not least because of the larger number of devices on the network. Then there is the issue of security – again. Monitoring of IIoT devices may give an early indication that a device has been compromised if it starts to deviate from its normal traffic profile, sending out more data than usual or sending packets to devices on the network that it does not usually communicate with.

The control plane may be able to compensate for some failures, such as that of an individual network device, overall network performance will still be affected by these failures. This means that full monitoring of the network’s data plane is still necessary in the SDN world, in order that remedial action can be taken in the event of any problems.

Traditional monitoring tools have kept an eye on individual devices, network packets, bandwidth and ports, as well as the performance level of applications. But where SDN is concerned, other aspects of the infrastructure can prove to be at least as important.

For example, the communication pathways and APIs that SDN applications use to interact with the control plane to make adjustments to the network must be operating and available at all times and should be covered by network monitoring.

This means a comprehensive monitoring capable of overseeing virtual environments and workloads is important to SDN – something like Paessler PRTG Network Monitor.

What all means that if or when you take the SDN route for IIoT, you must rethink your network management to cope with what becomes a more dynamic and complex network.

Ultimately that means adapting to work in a more automated style, so that network configuration changes are automated and driven by sets of rules and any decision to act is based on close monitoring of the infrastructure – rather than waiting for problems to arise.

Sponsored by Paessler.