IP To The End Node Challenges

With the advent of IPv6 we have been promised the native Internet technologies reaching each grain of sand. Which is a great vision. Unfortunately, as in real life, there are significant engineering challenges that prevent that vision from becoming a reality. I should even say that this is not an engineering problem. It all can be done. It just costs too much.

Like carrying shipping containers on board of cargo planes.

IP-based protocols are by nature heavy. Or should I say - heavier. Heavier to operate and heavier to manage. Simply speaking a "grain of sand" end node may not have enough resources to fully participate in an IP-Based network.

One example of such a resource is a real time clock (RTC). It is necessary to provide proper IP security, as certificates, that are the foundation of IP-based security, require the nodes to have a notion of time. An RTC is not a problem for a laptop, or even for a smartphone, but it is a significant added cost compared to a sub-dollar "grain of sand" silicon. Also initializing the time is easy on devices that have UI capabilities, but a device that does not have its time initialized cannot even properly authenticate a network time server that would offer it the time. Protocols such as BRSKI attempt to solve this Catch-22 situation, but still - they are complex and require significant resources on an end node.

Speaking of time, there are much more practical considerations. Say we have a bunch of sensors and we want to have reports of the accumulated values they measure over regular intervals (e.g., hourly dissipated heat energy). A classic approach would be a circular buffer to hold a histogram of the energy values for the last 10 hours. But to do that, the heat dissipation sensor would have to know the time to manage the hourly buckets. An alternative approach is to let the sensors just accumulate the dissipated energy and report this single value: total accumulated energy [now]. Time - stamping and bucketing would be offloaded to an intermediate node (a gateway) that collects the accumulated energy from the sensors at regular time intervals, time-stamps and buckets them and stores the series of several historical values.

Note that in this example, while everything could be implemented using IP-based technologies, we are losing the IP advantages: the gateway cannot be generic. It needs to be specific, it needs to understand the application and in fact becomes an essential part of the application. But it is hard to argue that such aggregating gateway helps driving the cost of the system down. The requirements on the end nodes are simplified a lot. The difference may be very significant. Sensors reporting a single accumulated value of dissipated energy could very likely be powered by the energy that they measure. Sensors with on board real time clocks would probably require their own power source (to keep the time when there is no external energy flowing through them).

One can argue the Moore's law and the overall progress will at some point drive electronics to the point when each grain of sand will have its own real time clock. Or other necessary resources. While this may be true, reducing the resource requirements will always lead to significant cost savings: a small amount for each grain of sand, but multiplied by the number of the grains...