This is a continuation from Part 1.
Local vs. Remote Networks
If we look at network infrastructure, we notice that there are two major parts. One is local networks and the other is remote networks. The remote networks correspond to clouds that provide remote computing (cloud computing). Note that clouds could consist of multiple smaller clouds that are implemented with many remote networks. Once we send our loads, they are in a black box. In other words, we do not know where they are processed or if they are processed at one or multiple locations. Our loads may be sent back and forth among multiple clouds to exploit cost, minimization of delay and response time, bandwidth, and/or cost.
But at the highest level of abstraction, we can safely represent those multiple clouds as a single cloud. Networking protocols used in clouds are 3G/4G and/or TCP/IP.
Parulkar pointed out that SDN is required for a local network (sensor network) that could vary in size, ranging from small to large scale (one house or building, a campus, regional). Networking protocols used for this level are 6lowpan, ZigBee, ZWave, Bluetooth, WiFi, and WirelessHart. As far as I know, most discussions of SDN are on the networks beyond the gateway (remote side) rather than on the local networks, even though a Google search on “IoT SDN” turns up more than 900,000 results.
This is illustrated in the following diagram that I reproduced from Parulkar’s slide by focusing on that single point. When data are collected from local networks, they are aggregated via a gateway and passed on to clouds. When we talk about applying SDN, it should be considered at both the local network and the cloud level. Also, we need to apply SDN to end-to-end network traffic. From the SDN point of view, it seems like not much has been done in the overall network, consisting of both local and remote networks.
Applications of SDN to Overall Network Infrastructure
If we look at the whole infrastructure, we need to pay attention to both local and remote networks to optimize loads, delay, response time, bandwidth, and costs. If we think about this carefully, we see that it is very difficult. If our requirements are to minimize delays and response time, we would be better off letting our local network do the job rather than sending our loads to clouds. Fog computing is a new name given to computing on local networks for these requirements, as opposed to cloud computing on the remote side.
At the same conference, Fujitsu Laboratories did a demonstration named control system for large-scale sensor network. The project is still at the experimental stage, and they are working with Industrial Technology Research Institute (ITRI) in Taiwan on the experiment. I saw a brief presentation of it and talked to Koichiro Yamashita, researcher at Ubiquitous Platform Labs at the Fujitsu Laboratories LTD. Not much has been published on this technology except for some press releases.
Koichiro Yamashita (right)
The main points of my casual, short conversation with Yamashita at the demo site are these:
- A networking infrastructure consists of hardware, networking protocol layers, middleware, and applications.
- The Fujitsu technology is the middleware. The networking layers do the necessary rerouting and traffic engineering of their own. The Fujitsu technology provides rerouting and traffic engineering independent of the networking layers.
- The researcher told me that their technology is meant to make networks stay up (no disconnection) and load-balance between the local (fog) and remote networks (clouds). Real-time monitoring was not meant to be their design.
What caught my attention is the following. Because theirs does not target real-time systems, local networks do not have to handle things like automobile detection avoidance systems. Depending on loads at remote networks (clouds), it might be better to process loads there than locally. Sometimes clouds are too busy with too many loads. With their technology, traffic can be balanced between local (fog computing) and remote computing (cloud computing). I am sure there is some work reported on the load balancing between cloud and fog, but this is the first I heard about it. This may be a good use case for the Industrial Internet of Things consortium.
Specific Issues to Consider for IoT
Parulkar added that IoT has its own issues to resolve, such as security.
Since he is associated with Stanford, he is familiar with other Stanford projects. The Stanford Secure Internet of Things Project is working on the security of IoT. Actually, it addresses the following, according to their website:
- Analytics: how will we integrate these enormous streams of physical world instrumentation with all of our existing data?
- Security: how can pervasive sensing and analytics systems preserve and protect user security?
- Hardware and software systems: what hardware and software systems will make developing new intelligent and secure Internet of Things applications as easy as a modern web application?
Security is required to counter attacks on your networking infrastructure, such as:
- Viruses, worms, and Trojan horses
- Spyware and adware
- Zero-day attacks, also called zero-hour attacks
- Hacker attacks
- Denial of service attacks
- Data interception and theft
- Identity theft
Because smaller devices are limited in their ability to provide more than “sense” and “gather,” I wonder how this can be achieved without adding to the costs to the IoT infrastructure. I think smart people at Stanford are researching that.
Five Years from Now (2020)?
Three panelists gave a variety of answers to the question of what networking will be like in five years.
- Networks will be faster and smarter, allowing easy buildup and teardown with adequate security.
- From the end user view, networks will be like air. Users will use and exploit networks as if they do not exist, just as they breathe air without noticing its existence.
- From the infrastructure view, some smarts may be injected not to use energy/power excessively to fuel a huge number of connected devices and clouds.
- More white boxes will be deployed with open source networking operating systems and more new services will be provided.
- Most IoT devices within five years will be variants of smart phones, and it will take more than five years for other types of smaller devices to form IoT.