Problems befalling IoT Networks due to TCP/IP Architecture
Arslan Syed, Najam-ul-Hassan, Farhan Jamil, M. Taha Bhatti
Introduction
“Internet of Things” (IoT), networking (potentially) a large number of resource-constrained
devices, is gaining popularity in recent years. Today’s IoT systems are largely based on the use of
the TCP/IP protocols (IPv6 in particular). However, the observations so far suggest that the TCP/IP
protocol stack, as originally designed, is not a good fit to the IoT environment. Over the last several
years the IETF (Internet Engineering Task Force) has spent significant amount of effort in
modifying the protocol stack to fit IoT deployment scenarios. These efforts have resulted in
extensions to existing protocols in the TCP/IP protocol suite as well as development of multiple
new protocols. Yet new problems continuously occur. In this paper we analyze the technical
challenges in applying TCP/IP to the IoT environment and review various solutions proposed by
the IETF. We argue that existing IP-based solutions are either inefficient or insufficient in
supporting IoT applications, and that a more effective solution would embrace the Information
Centric Network architecture.
1 Literature Review
“Internet of Things” (IoT) generally refers to the interconnection of different types of computing
devices to support various kinds of monitoring and control applications. To accommodate the
heterogeneity of devices and applications from different venders, modern IoT systems have
adopted the open standards of TCP/IP protocol suite, which was developed for the wired global
Internet several decades ago, as the networking solution. However, IoT networks differ from
traditional wired computer networks in fundamental ways as we elaborate below. Those
differences pose significant challenges in applying TCP/IP technologies to the IoT environment,
and addressing these challenges will make afar reaching impact on the network architecture. This
paper aims to systematically identify the challenges posed by the IoT environment, and to
articulate the future direction to tackle the challenges. IoT networks often contain a large number
of low-end, resource-constrained devices. The design of those devices are mostly driven by low
manufacturing and operational cost. As a result, the IoT devices are typically equipped with limited
computing power and required to operate over longtime periods (e.g., a year) on battery. Due to
the power constraints, the IoT networks often employ low-energy Layer-2technologies, such as
IEEE 802.15.4, Bluetooth LE and low-power Wi-Fi, which usually operate with much smaller
MTU and lower transmission rate compared to traditional Ether-net links. Therefore an immediate
challenge for the IoT network protocol design is to adapt the packet size to the constrained links
(discussed in Section 2.3). To save energy, IoT nodes may not be always on as in wired networks.
More-over, an IoT system may be deployed in environments with-out wired network infrastructure
(e.g., forests, underwater, battle fields) and consequently has to rely on wireless mesh technologies
to communicate. This brings more challenges to the TCP/IP protocol architecture: first, mesh
networks typically adopt the multi-link subnet model which is not sup-ported by the original IP
addressing architecture (discussed in Section 2.2); second, broadcast and multicast are expensive
on a battery powered network as a single multicast will involve a series of multi-hop forwarding
and potentially wakeup many sleeping nodes (discussed in Section 2.1); third, a scalable routing
mechanism is now necessary for IP communications to happen over the mesh networks and lastly,
the TCP-style reliable and in-order byte stream delivery is often ill-suited for applications that
require customized control and prioritization of their data. Most IoT applications interact with lots
of sensors and actuators to perform various monitoring and control tasks on the ambient
environment. Their design patterns intrinsically require efficient and scalable support for naming
configuration and discovery, security protection on the data acquisition and actuation operations,
and a resource-oriented communication interface such as Representational State Transfer (REST).
Unfortunately, existing solutions to those problems, many of which are widely used by today’s
Web technologies, do not satisfy the constraints of the IoT environments. For example, the
traditional DNS-based naming services are unsuitable in many IoT deployment scenarios that lack
infrastructural support for dedicated servers. The application-layer content caches and proxies are
often inefficient in dynamic network environments with intermittent connectivity. In addition, the
channel-based security protocols such as TLS and DTLS, which are used to secure the REST
communications, impose high overhead on the IoT devices in terms of protocol operations and
resource consumption. (Discussed in Section 4)
The rest of this paper discusses each of the aforementioned issues in detail. We seek to identify
the architectural reason that causes the difficulties when applying TCP/IP to the IoT world. We
also survey the current solutions to those issues that have been standardized or under active
development at the IETF, and analyze why they are often insufficient to solve the targeted
problems. The goal of this paper is to offer insights and point out directions for the design of future
IoT network architectures.
2 Problems at Network Layer
IP, especially IPv6, is engineered for today’s Internet environment with desktops and laptops as
end devices communicating with wire-connected servers. In this section we discuss which
properties of the hosts and the networks currently assumed by IP no longer exist in the IoT world,
and what have been done to tailor IP and its companion protocols to fit them into the IoT
environment.
2.1 Multicast efficiency
A lot of IP-based protocols make heavy use of IP multicast to achieve one of the two
functionalities: notifying all the members in a group and making a query without knowing exactly
whom to ask. However, supporting multicast packet delivery is a big challenge for constrained IoT
mesh networks. First, most wireless MAC protocols disable link layer ACK for multicast;
consequently lost packets are not recovered at link-layer. Second, multicast recipients may
experience different data transmission rate due to the coexistence of multiple MAC protocols (e.g.,
different versions of Wi-Fi) and/or the link-layer rate adaptation; therefore the sender has to
transmit at the lowest common link speed among all receivers. Third, IoT nodes may switch to
sleeping mode from time to time to conserve energy, thus may miss some multicast packets. Lastly,
when nodes are connected through a mesh network, a multicast packet needs to be forwarded over
multiple hops along many paths, potentially waking up many sleeping nodes and overloading the
already-scarce network resource. To get around the difficulties in multicast support, the legacy
protocols have to be redesigned to minimize the use of IP multicast before they can be applied to
constrained IoT environments. When IoT nodes need to send out notifications to multiple
recipients, instead of multicasting the packets, they can buffer those packets temporarily at some
well-known location and wait for the recipients to pull the packets over unicast on-demand (based
on their sleeping schedule).
When they want to make queries to a group, instead of flooding the network with multicast, they
can send the queries to some designated nodes which are preconfigured to answer queries by
collecting the information on a priority. These new approaches replace multicast with on-demand
unicast pulling, to get around the difficulties in supporting multicast and also to accommodate
sleeping nodes. One example of such protocol adaptation is the IPv6 Neighbor Discovery (ND)
optimization for 6LoWPAN [24]. The original IPv6 ND [21] relies on multicast to learn default
gateway routers, resolve neighbor’s IPs to MAC addresses, and perform duplicate address
detection. When adapting ND functionalities to 6LoWPAN, instead of having the routers multicast
Router Advertisements periodically (which will either wake up the sleeping nodes or be missed by
those nodes), the optimized protocol allows the constrained nodes to refresh Router Advertisement
information on demand with Router Solicitation messages.1 Another extension is to maintain a
registry of host addresses on the routers, making the routers capable of answering address
resolution and duplicate address detection requests on behalf of the end hosts, so that the querying
nodes simply send their queries to the default routers via unicast messages.
An alternative solution called MPL, proposed by the IETF roll WG, fundamentally changes the
forwarding semantics of multicast over constrained networks [12]. MPL disseminates multicast
packets across the entire multicast domain through synchronization among MPL forwarders (i.e.,
nodes that participate in MPL) using controlled flooding, without requiring any multicast routing
protocol to maintain the topology information. Every multicast packet is identified by the packet
generator id and a sequence number in order to allow duplication detection. Also, recent packets
are buffered by the MPL forwarders in a sliding-window fashion (i.e., FIFO buffer), which can be
used for retransmission in the future. This new multicast forwarding protocol has been adopted by
the current ZigBee IP specification [2].
2.2 Multi-link subnet
The current subnet model of IPv4 and IPv6 considers two types of Layer-2 networks: multi-access
link, where multiple nodes share the same access medium, and point-to-point link, where there are
exactly two nodes on the same link. Both of them assume that the nodes in the same subnet can
reach each other within one hop. An IoT mesh network, on the other hand, contains a collection
of Layer-2 links joined together without any Layer-3 device (i.e., IP routers) in between. This
essentially creates a multi-link subnet model that is not anticipated by the original IP addressing
architecture [11]. RFC 4903, “Multi–Link Subnet Issues” [29], documents the reasons why the
IETF community decided to abandon the multi-link subnet model in favor of 1:1 mapping between
Layer-2 links and IP subnets. The main concerns are around the “one–hop” reachability model that
many existing protocols already depend on. First, forwarding across multiple links within the
subnet creates trouble with TTL/Hop Limit handling. In IP networks it is common practice to limit
the scope of communication to a single subnet by setting the TTL/Hop-Limit to 1 or 255 and verify
that the value stays the same upon receipt. The multi-link subnet model will break any protocol
that follows such practice because the nodes who perform IP forwarding across multiple links will
necessarily decrement the TTL/Hop-Limit value.
The second issue is that link-scoped multicast does not work on multi-link subnets without proper
support for multicast routing (which is often disabled even in today’s Internet).
Consequently, legacy protocols that depend on link-scoped multicast (e.g., ARP, DHCP, Neighbor
Discovery, and many routing protocols) will also be broken on multi-link subnets.
Fundamentally, the issues above are caused by the mismatch between the old IP subnet model and
the new IoT mesh networks. To avoid those technical issues, one has to either rely on Layer-2
mechanisms to glue multiple links into a single network transparently (similar to bridging of
multiple Ethernet segments), or partition the mesh network into multiple subnets with different
prefixes. The first approach requires some form of intra-subnet routing capability, which will be
