Over the past decade, we’ve come to think of personal computers, laptops, and mobile phones not just as computing devices but as communications systems as well. The next frontier in the evolution of the Internet will be the ability to connect more than just computers and communications devices; that next step will involve connecting smart objects.
Imagine the energy savings that could be realized by connecting energy-consuming objects such as dishwashers and washing machines to an energy-producing smart grid. Imagine further the energy-consumption savings and the cost benefits if HVAC (heating, ventilating, and air-conditioning) systems, lights, windows and window shades and blinds, doors, and locks could talk both to each other and to controller systems as a matter of routine.
What is the Internet of Things? While much has been written that describes IP (Internet Protocol) smart-object networks in great detail,1,2 simply put, the Internet of Things refers to the interconnection of IP smart objects, such as sensors and actuators. Such devices have been used in the industry for decades, usually in the form of non-IP/proprietary protocols that are connected to IP networks by way of protocol translation gateways. With the emergence of a myriad of applications, such as Smart Grid, Smart Cities, building and industrial automation, as the smart grid, smart cities, and building and industrial automation, and cars that can interconnect millions of objects for sensing things like power quality, tire pressure, and temperature and that can actuate engines and lights, it quickly became of the utmost importance to extend the IP protocol suite for these networks.
To that end, the IETF has formed (as of this writing) three working groups (WGs) that define an adaptation layer (6LoWPAN), routing (ROLL), and a resource-oriented application protocol (CoRE). The activities of these WGs are described briefly in this article.
IP Smart-Object Networks (the Internet of Things) and the IETF
The 6LoWPAN Working Group
One particular IP smart-object network has been standardized as IEEE 802.15.4. It was initially popularized by the Zigbee family of vertical specifications. This low-power radio is designed to deliver 20 to 256 kilobits per second (less on 900 megahertz [MHz], more on 2.4 gigahertz) with about a milliwatt of transmission power.
The MAC (medium access control) layer provides only a small packet size of 127 bytes, which requires an adaptation layer with fragmentation and reassembly to enable Internet-style maximum transmission units. As a result, the so-called IP over foo specification (RFC 4944) is more complicated than, for example, that for Ethernet. The 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks [WPANs]) WG, initially chartered to create that specification, went on to provide two critical performance improvements: 6LoWPAN-HC and 6LoWPAN-ND.
Due to the number of nodes that will be on constrained node/networks, only IPv6 provides enough addresses, but IPv6’s large headers would fill almost half of a MAC layer packet and therefore require good header compression (HC). RFC 4944 provides a simple, stateless form of header compression, but it does not compress globally prefixed addresses well. Unfortunately, the existing HC family of specifications created in the Robust Header Compression (ROHC) working group is too expensive for 6LoWPAN, as it is based on per-flow state, which would be prohibitive for a constrained node.
The solution in 6LoWPAN-HC [draft-ietf-6lowpan-hc] is simple (mostly static) networkwide state in the form of /context/, which can be distributed, for example, via IPv6’s neighbour discovery (ND) protocol.
6LoWPAN-HC recently completed WG Last Call and is moving on to the Internet Engineering Steering Group (IESG).
The other set of performance improvements addresses the ND protocol.
ND, as it stands now, works well on Ethernet or point-to-point links, but it requires subnetwide multicast for many of its operations. In a constrained wireless network, this requires some form of flooding or other routing protocol support and thus can be prohibitive.
6LoWPAN-ND [draft-ietf-6lowpan-nd] uses the RFC 5889 IP addressing model with off-link hosts, thereby limiting the need for multicast to inexpensive radio-range transmissions. Hosts can /register/ to their routers, allowing these to redistribute host addresses in the routing protocol. 6LoWPAN-ND also contains support for distributing 6LoWPAN-HC’s context. As of this writing, 6LoWPAN-ND is in WG last-call.
The Routing Over Low power and Lossy networks (ROLL) Working Group
The IETF has considerable experience in routing in IP networks and it has specified a number of routing protocols over the past two decades (such as RIP, OSPF, BGP, and IP for IS-IS), but routing in networks made of IP smart objects has unique characteristics. Indeed, not only are the devices constrained in terms of resources (such as process power, memory, and, potentially, energy); they also are usually interconnected by low-speed lossy links where the packet drop ratio may be quite high. Furthermore, some of those networks may be made of hundreds of thousands of nodes. This unique set of characteristics led to the formation in 2008 of a new working group called ROSS, whose objective is to specify an IPv6 routing solution for such IP smart-object networks.
After one year of detailed requirements analysis and a survey of the existing IP routing protocols specified at IETF 78, the WG concluded that none of the existing protocols would meet the set of requirements. Thus, the ROLL WG was rechartered to specify a new routing protocol, called RPL (Routing Protocol for LLNs). RPL is a distance-vector routing protocol that supports the formation of directed acyclic graphs (DAGs) according to a user-defined objective function using a set of link/node routing metrics/constraints. RPL supports the notion of multitopology routing (where the DAG is specified in a newly defined IPv6 hop-by-hop header) and has been designed to make efficient use of limited resources in the network (such as using Trickle timer and supporting local repair complemented with global repairs).
RPL supports two modes of operation known as storing and nonstoring. In storing mode, each node in the network stores a routing table. Traffic between two nodes travels along the DAG in an upward direction to a common ancestor, at which point packets are redirected to their destination. In the nonstoring mode, no routing tables are stored; packets always travel up to the DAG root, where routes are stored and the root redirects the traffic to its destination by using source routing.
RPL has currently passed WG and IETF Last Call and is under IESG review. More than a dozen implementations exist as of this writing, and two interoperability tests have been performed by the IPSO (www.ipso-alliance.org) and Zigbee-IP alliances.
Constrained RESTful Environments
In spring 2010, the IETF started a new working group called Constrained RESTful Environments (CoRE). The aim of this WG is to extend the Web architecture to even the most constrained networks and embedded devices. Machine-to-machine applications—such as smart energy, building automation, and asset management—will benefit tremendously from the use of Internet technology and from integration with the Internet of Things. In particular, the Web architecture will be important in scaling large-scale, machine-to-machine applications. Today’s Web protocols work well between Web servers and Web clients running on PCs and handheld computing devices. However, constrained Low-power and Lossy networks often mean high packet loss (5 to 10 percent is common), frequent topology changes, low throughput (10–20 kilobits per second is common), and useful payload sizes that are often less than 100 bytes. Embedded devices typically depend on cheap embedded microcontrollers with processors running at several MHz and limited RAM and ROM. In addition, the interaction patterns in machine-to-machine applications are different, often requiring multicast support, asynchronous transactions, and push rather than pull. The CoRE WG has been chartered to develop a new Web transfer protocol and appropriate security setups for these machine-to-machine applications over constrained networks and nodes.
The WG is now completing work on the Constrained Application Protocol (CoAP) [draft-ietf-core-coap-02], which is on schedule for completion at the end of 2010. At IETF 78, a successful PlugFest of CoAP was held with more than 10 implementations of the protocol. Security is another important subject for CoRE, which is also working on security bootstrapping techniques for these environments.
Perspectives
Enormous progress has been made at the IETF over the past few years in specifying new IPv6 protocols that connect IP smart objects to private IP networks or the public Internet, thus facilitating a myriad of new applications. Still, there’s no doubt that new work will further enrich the IPv6 protocol suites for these devices—and transport, security, and management for this new wave of the Internet: the Internet of Things.
References
1. J. P. Vasseur, A. Dunkels. Interconnecting Smart Objects with IP: The Next Internet. Burlington, Mass.: Morgan Kaufmann, 2010.
2. Z. Shelby, C. Bormann. 6LoWPAN: The Wireless Embedded Internet. Chichester, England: John Wiley & Sons, 2009.
[SIDEBAR]
Constrained Nodes and the Internet of Things
Constrained nodes have limited CPU power and memory. In some ways, they are a throwback to the environments on which the Internet was prototyped in the 1970s and 1980s. Today, the cost of electrical energy is an important consideration: many constrained nodes are powered from primary batteries (such as AA cells), which may have to last multiple years. This means that a node may only consume average power in the range of microwatts, which is only possible if it spends most of its time sleeping (and thus off the Net). Moore’s law has a different effect on this space: while its improvements do reach the constrained nodes, they are mostly invested in making nodes cheaper and longer lasting, not making them more powerful, such as what we are used to from our personal computers and mobile phones.
This article was posted on 31 January 2011