Meshdynamics
The Abstracted Network for Emerging Industrial Internet of Things (IIOT) t

 The Abstracted Network for Enterprises and the Internet of Things.

(reprinted from DZone Article: https://dzone.com/articles/the-abstracted-network-for-enterprises-and-the-int)

The Challenges

As Enterprises begin the serious work of moving beyond trial phases to truly integrate Internet of Things traffic, three key factors are coming to the fore. As I described in DZONE’s Guide to The Internet of Things Volume III, the first is that the future will bring a huge increase in the number of sensors, actuators, and devices broadly categorized as the Internet of Things (IoT). The amount of data generated by these new end points is staggering. But more importantly, a very large percentage of these devices will be too small, too cheap, too dumb, and too copious to run the hegemonic IPv6 protocol. But somehow this traffic must still be incorporated into Enterprises’ networks.

Simultaneously, these same Enterprises are increasingly moving their main networking and computing tasks to cloud network architectures. In order to maintain or increase control of these resources, many Enterprises are rolling out variations of Software Defined Networking (SDN) technologies and protocols. Although standards and techniques vary with different SDN approaches, a common requirement is for computing power at the edges of the network to manage the interactions. A conflict is immediately obvious given these first two realities: a proliferation of simple devices with little to no computing power and memory – and Enterprise networking schemes that demand both!

The third factor is somewhat hidden from view, but will become more important as Enterprises seek to truly incorporate all the data from every kind of “thing.” There are millions of legacy machine-to-machine (M2M) networks operating everything from robotic assembly lines to process control facilities. These run on idiosyncratic older protocols that are often implemented on purpose-built Programmable Logic Controllers (PLC). Although these M2M networks have long existed as independent islands, increasingly Enterprises wish to pull these into a broader IoT strategy. But these legacy networks were often designed with no thought to wider communication and management and demand local control and response.

Concomitantly, any solution addressing these three factors must also be exceptionally tolerant of disruption, mobility and change. Enterprises placing “more eggs in one basket” will require that all data operation continue despite perturbations.

Abstracting diverse networks to unify them

The solution to these seemingly contradictory requirements is not to change the devices, as some have suggested. Many IoT devices can’t be burdened with IPv6and its accompanying costs of processing, memory, and power. Many legacy M2M networks likewise are based on simple devices and would require many person-years of software to fully participate in an IPv6 network, let alone SDN.

Instead, the answer is simple in concept, but demanding in implementation: The Abstracted Network. The Abstracted Network replaces the topologically separate networks – existing legacy M2M and Enterprise networks, along with the emerging IoT – with a single network that creates the appearance of separation but with the benefits of integration.

Traditional networks are still often separate today based on whether they are handling human-oriented traffic (smart phones, tablets, computers, etc.) or M2M traffic (sensors, actuators, robots, etc.). As noted above, many M2M devices operate as “islands” or “silos” disconnected from the rest of the Enterprise. These isolated networks have remained despite the rise of IP because of simplicity of the end devices or their peculiar communications and control requirements (See Figure 1 below).
 
Click to Enlarge Click to Enlarge
FIG 1: Traditionally separate networks for human-oriented and machine-to-machine data FIG  2: The Abstracted Network based on propagator nodes emulates separate networks. Allows Enterprise control, publish/discover/subscribe

Click Images to Enlarge.

It’s perhaps immediately obvious that there are networking inefficiencies in these separated networks, but more critically for Enterprises, the legacy and IoT networks are not easily controlled and tuned by SDN software. Another hidden issue may be even more important in the long run: events and trends generated within the legacy and IoT networks are invisible to the primary Big Data servers handling the rest of the Enterprise’s activities. The power of the publish/discover/subscribe model I described in DZONE’s Guide to The Internet of Things Volume III, depends on incorporation of the broadest range of data sources and devices and uses a device called a propagator node to create the virtual network topology (Figure 2 above).

Propagator nodes are similar to traditional networking devices such as routers and switches, but also incorporate support for legacy and emerging IoT protocols as well as standards-based Ipv6. Propagator nodes emulate the formerly separate networks’ protocols, timing, and control interactions. This means that legacy and IOT devices that cannot incorporate higher-level protocols themselves may still function as part of the overall Enterprise operational structure.

The networks are in the database

A sophisticated distributed database is hosted in applications agents found in each propagator node. Built partially on discovery and tuned by the Enterprise’s needs, the database forms a model of the logical interconnections and networking needs of each type of attached device (Figure 3 below). Network traffic flows and interactions are tracked to constantly update the abstracted model, creating an efficient virtual network architecture no matter the physical topology. This includes such details as latency, protocol translation, multicast pruning and forwarding, and even control loop management.
 
Click to Enlarge Click to Enlarge
FIG 3: The Abstracted Network is created as a database within propagator nodes, virtualizing legacy and standards-based connections FIG 4: The Abstracted Network database may be monitored and modified by Enterprise SDN tools, extending even to legacy and IoT M2m devices
 

Click Images to Enlarge.

The Abstracted Network is initially built autonomously, but is constantly refined, restructured, monitored, and tuned. Some of the modification happens based on process internal to the propagator node network, in particular the use of scheduling and modeling algorithms to maintain deterministic performance for all of the virtualized networks. In addition, the applications agents within each propagator node are active in SDN monitoring and tuning by participating in messaging based on rules and other parameters (Figure 4 above). In this way, even legacy M2M and IoT networks of simple devices may be managed by SDN techniques and tools.

Managing change and disruption

An important additional benefit to the distributed Abstracted Network database is that is maintained for the attached devices and the propagator nodes themselves, monitoring link status, adjacencies, and other networking parameters. Since the virtual topology is independent of the physical topology, network operation may be maintained despite failures and changes.

Link fault tolerance is the first level of fault tolerance. Propagator nodes build a logical tree of links from the virtual mesh of possible routes, but maintain awareness of alternate paths. This allows a nearly instantaneous re-routing around failures (Figure 5 below). A valuable by-product of this capability is the capacity for propagator nodes to be in motion relative to one another, to end devices, and to other network elements. Propagator nodes smoothly shift to other connections as old ones fade, maintaining network function.
 
Click to Enlarge Click to Enlarge
FIG 5: Disruption tolerance between propagator nodes is provided autonomously through an adjacency database and routing table exchanges FIG 6: Applications agents in propagator nodes maintain local operation for connected devices despite upstream communications failures
 

Click Images to Enlarge.

Maintaining M2M operation

Disruption tolerance is also critical at the application level, especially for IoT and legacy M2m devices. As noted above, many (if not most) of these devices lack sophisticated networking protocols, so they have no functions to deal with network failures. But the applications agents in each propagator node may be provisioned with software that performs many of the functions necessary for end device operation. These could include data collection and interim storage, alarms and status, control loop management, even spoofing of network acknowledgement and requests.

Because these applications reside in each propagator node, attached devices may continue operating more-or-less normally no matter the status of the physical topology, even through a complete failure of round-trip communications. The Abstracted Network keeps local operation intact until the physical network connection can be re-established (Figure 6 above).

The Abstracted Network Concept and the capabilities of propagator nodes provide solutions for the Enterprise’s competing needs to incorporate the burgeoning IoT world and legacy devices into new cloud-based and Software Defined networking architectures. This delivers networking efficiencies and improves the ability to manage and survive disruption and change.

Related Links

The Abstracted Network Concept (Slides)
The Abstracted Network Concept (Paper and Slides)