At the recent Internet Engineering Task Force (IETF) meeting in Buenos Aires, I had an interesting conversation with Jari Arkko, the IETF chair. We talked about an Internet of Things (IoT) workshop the Internet Architecture Board (IAB) held recently exploring the upper layer abstractions that make it possible for devices to come together into a network and understand what each of them might be capable of sharing.
A sense I had from reading the mailing lists after this workshop was that the action right now in the field of IoT isn’t down at the network layer. Instead, people in IoT are focused on application-level standards, exploring how IoT devices can exploit secure reliable byte streams, such as Datagram Transport Layer Security (DTLS), to communicate their capabilities and command/control logic.
In this world view, the network is an assumption. It aims for efficiency over small areas, with low-power budgets, even low data rate networks. It targets things like IPv6 over Low power Wireless Personal Area Networks (6LoWPAN), IPv6 header compression models, and DTLS.
DTLS provides secure, private end-to-end encrypted transport that is less costly than TCP in protocol terms. It still has cryptography costs, of course, and can function more like UDP when needed, but with some sense of ordered packet delivery.
There are other objectives driving this direction to an IPv6 network view. But the real decisions are now being made higher up the stack, around how devices might declare what functions they implement and what assumptions they bring to the table about their role in the network.
This is a modern day version of the library introspection (a way of finding out what an object is and what it contains), which came with shared libraries where you needed to know not only which function calls were available, but which version(s) of the applications binary interface they supported.
Microsoft is an expert in this field having written surprisingly large amounts of code into library modules which document what they do, as well as doing it. Or, you might be familiar with Python’s coding standards, which do much the same thing for the interpreted language – you can find out what you can do if a library is written to tell you.
IAB’s IoT workshop explored some scary but interesting concepts, which I recommend you take a look at for yourself. Let us know what you think.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Useful write-up. Thanks.
There ought to be more emphasis on the network layer(s) in IoT. Many of the protocols that have emerged so far are both too broad and too narrow in scope. For example, Zigbee includes an application model of a billing engine, while not having enough emphasis on spotting, reporting and diagnosing network layer failures in the mesh. The ‘too narrow’ makes it a challenge to assure any system level service quality. The “too broad” makes it interoperability hard.