The Abstracted Network
for Enterprises and the Internet of Things.
(reprinted from DZone Article:
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
(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
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
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
. 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).
|FIG 1: Traditionally separate networks for human-oriented and machine-to-machine
||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.
|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
|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.
Abstracted Network Concept (Slides)