33 Mesh Networks and IPv6 over Mesh

Prof. Bhushan Trivedi

Introduction

We have looked at what are IoT devices, what are their characteristic, some important applications of IoT devices in the previous module. We have also seen that communicating and collaborating between IoT devices makes the IoT-based solutions special. We have seen that IoT communication does not augur well with existing networking infrastructure and needs a special treatment. Most IoT devices prefer wireless connections to the world and there are constraints like power and storage which does not allow the state of the art solutions like Wi-Fi and Wi-Max to work effectively with IoT devices. We have also seen that we need to have low bandwidth, low power wireless solutions for IoT networks. We are going to discuss some popular solutions in the current module as well as the next module.

Routing and forwarding in Mesh

The mesh network is built using peer to peer links, basically forming an ad hoc network. There is no specific routing protocol specified for this case. However, some constraints are imposed. For example, Each RFDs should be able to communicate with only one FFDs. If there are multiple paths, they should select one based on selection criteria we discussed earlier. That makes it structured like a tree where the leaves are RFDs and most of the other nodes are FFDs. That means, one actually does not require any routing process as there are no multiple paths to choose from. Once this structure is ready, forwarding is done in a very straight forward manner as there is only one alternative and the packet is to be forwarded along that path only. The steps needed to execute the normal routing process and forwarding process in conventional networks are not really needed here1.

In the example of home network with IoT devices the central router (the FFD or the coordinator) helps them to connect to the Internet and especially the cloud for accessing typical set of services. In some cases, like factory network with IoT devices embedded in machines, the central FFD may run servers and apply logic to inputs from machines, learn about patterns of working and decide which machine needs which type of repair. Thus it is quite possible for the central coordinator FFD to run servers and provide typical services to all its mesh members.

The technology that we are discussing does not provide a guarantee of direct connections between every device. Unlike ISP’s network where each node has a connection to other

1  An interesting parallel can be drawn with LS algorithm. The spanning tree generated for deciding the next hop router is similar to what is constructed here. However, the broadcasting which LS uses is not advised here. The output, however, is similar spanning tree for only one destination, the central router.

node using point to point links, the mesh network needs to communicate with others via other intermediary nodes. Thus the mesh network is one which is a collection of multiple individual links.

There are two ways the routing can be done in such mesh networks, mesh-under, and route-over. Let us see how do they do their job.

The issue being addressed is to send IP packets over low powered links of the mesh network, i.e. using 802.15.4 frames. Whenever IP protocol is chosen for the mesh network, the dilemma is whether to consider it a single broadcast domain or not. Let us try to understand both solutions in the context of that broadcast domain.

First solution is to consider the entire network as a single subnet or broadcast domain. That means, the sender sends anything to this network and it should reach to all nodes. A single broadcast domain has all communication being transitive. That means, if A can send to B and B can send to C, then A can also send to C. Once this condition is satisfied, a single packet delivered to this domain can reach all nodes connected to it by a single broadcast. Remember that each node is not directly accessible form the entry point router, and this broadcast process must be deployed in a way that not directly accessible device gets the message by routing through other devices along the path. To emulate single broadcast, the mesh network requires a link level routing (layer-2) and forwarding. For an outsider, the network is like any other network and the mesh processing (which routes and forwards packets) is hidden within that mesh network. That is why it is called mesh-under.

IETF has not specified any protocol for this mesh-under version but chosen the other, route-over approach which is implemented by another protocol called RPL which we study in the next module. The mesh under approach was assuming an IP link is connected to all network nodes which are directly addressable or not, the route over approach assumes only those nodes which are directly connected to the given node. That means, the network is collection of multiple segments, each segment contains a member node and all neighbors directly connected to it. The route over approach considers each node to be a network itself and thus every link connects networks consisting of one node each. The link, thus, works like normal IP operation between routers connecting networks. Here each link is connected to the network layer, that means, each endpoint of a link belongs to different networks and traversing on link means moving from one network to another. Unlike that, the mesh under case, a layer-2 (bridge-like) process is carried out. Here the link belongs to the very network and both endpoints only indicate different nodes of the same network.

A mesh-under approach uses layer-2 routing process to emulate a broadcast while a route over approach uses a layer-3 routing process, much like a normal network.

Both route-over and mesh under are possible in 802.15.4. The administrators decide that based on their own convenience. However, the ZigBee consortium recommends the route-over approach.

In the route-over approach on the Internet, the routers run conventional protocols based on DV or LS algorithms and construct forwarding tables based on the process and exchange of packets between routers. The forwarding process is handled by IP. It picks up the incoming packet, look at the destination address, search that address in the forwarding table and forward the packet based on that.

In the mesh-under approach, the nodes can discover neighbors, do not use IP to forward packets, an additional Intranet Sublayer is introduced in the data link layer (quite similar to the MAC layer for MANets). The Job of Intranet Sublayer is to decide the link to forward the packet. The other layers act the same. One of the bottlenecks of this approach is that it is independent of IP routing. That means ISL do not coordinate with IP based routing that is happening outside this mesh. If there is some problem in this routing process, it is not seen by the IP layer and the problem reporting mechanism based on IP, (ICMP) does not work well in this situation. ICMP may only report the sender, for example, that the central router of the house has dropped the packet for some reason, which, in the true sense, might be dropped by one of the devices along the path from that router to the actual destination. When a node in a mesh is not reachable, a node outside the mesh will never learn about it.

For routing, the 802.15.4’s first job is to determine a tree from the mesh network. If it is using a mesh-under approach, it uses a layer-2 forwarding method. The tree is formed by choosing one link between any RFD to FFD. Once that is done, the central router will have a single path to all nodes and thus forming a spanning tree.

The process works using an approach similar to MANet. The central router broadcasts its signal and all devices in the range responds back. Every neighbor also broadcasts. Each neighbor looks at the signal quality of others and decides the best connection.

Eventually, every node in the network will have information about all other nodes and how to reach them2. They also will learn about forwarding the broadcast; if coming from shortest route, on all other paths, otherwise do not broadcast. Thus when the MAC address of the central router is provided, each node knows exactly which node to forward the packet to send it to the central router.

When ZigBee uses a route-over approach, it recommends using another protocol and not IP. The IP protocol demands different IP prefixes for different networks. As each individual link

2  The case is different when the node does not have enough memory to contain this routing information. We will study how RPL solves this problem while using a route-over approach, in next module.

represents connection between different networks, each node belongs to as many IP networks as number of links it is connected to3. This demands huge number of network prefixes, which isn’t usually available to the administrators. ZigBee consortium, therefore, provide options of modifying IP behavior while using the route-over approach.

In this case, the layer-3 protocol uses a forwarding table based on layer-3 protocol (that means based on IP addresses) unlike the mesh under case where the tables are based on MAC addresses. IP, as we know, cannot forward on its own, it has to construct a frame to do so. Constructing a frame needs converting an IP address into respective MAC address, which demands broadcasting and cashing those addresses additionally. Considering comparatively static the structure of these nodes (as compared to MANets) and smaller size of the networks, it is not a big overhead though4.

The mesh-under approach considers entire mesh as one network. If the packet is received by the central router, the IP passes this packet to MAC layer and MAC layer forwards the packet to the destination. Unlike that, in route-over approach, IP routes over the nodes till the final node. Here, the problem arises if the node is not directly reachable.

Using IPv6

Interestingly, the IoT devices, from the word go, chose IPv6. The reason is simple, the big footprint of IPv6 allows many more devices than IPv4 could have provided. The idea is to use IPv6 as long as possible and provide modifications as need be. There are some other, important reasons to use IP instead of proposing some other protocol. Here is a list of some most common reasons.

1. IP network is pervasive and thus once IPv6 is used by this mesh network, it can communicate with any other network of the world seamlessly.

2. IP-based solutions and technologies are already available and getting matured, for example, an IPv6 node can choose its own address (by a process known as auto-configuration) when there is no server to do so. Using IPv6, each node can use auto configuration to avail its own address.

3.  IP is open and freely available technology. This is not a technical but critical reason for its adoption and spread. Adopting an open and freely available technology improves the changes of the spread of applications of IoT devices.

4. There are tools which can help detect problems (i.e. ICMP or Internet Control Message Protocol), manage nodes (using SNMP or Simple Network Management Protocol), and deploying IP networks. Same tools can be used here.

3   Why? If a node is part of 5 networks, he will have five different addresses as each network has a different network prefix, an essential part of an IP address. When an IoT node is connected to other nodes using different links, it represents different networks and thus must have that many network addresses.

4  There are protocols which can even reduce this broadcasting. We will discuss them in next modul

5. Any other IP-based devices and networks can be seamlessly connected to IoT device networks. A standalone IoT device can be easily integrated into a conventional network if some conditions are satisfied.

IETF is working on three different areas where ZigBee can be used for IoT devices. It has formed 3 different working groups. The first group called 6LoWPAN works on a mechanism which allows compression of IPv6 packet and sending it over to 802.15.4 wireless link. Second group known as ROLL (Routing over Low power and Lossy networks) is working on the protocol for routing the packets in an 802.15.4 network called RPL and third, the CoAP (Constrained Application Protocol) is the application protocol for constrained (one which low memory and low processing power) devices. It is a specialized web transfer protocol with constrained nodes and constrained links.

IPv6 over low power wireless PAN (6LoWPAN)

The 6LoWPAN is designed to send the IPv6 packet over the 802.15.4 radio link. It is the IETF initiative for making sure the IP could and should be applied even to small IoT devices. This is targeting devices which has limited processing capabilities and less memory. The IP networks (the conventional wired and wireless networks which use IP for transmission) are different than low power mesh networks like 802.15.4 in more than one way but most critical difference is about the packet size. When an IPv6 packet is moved over a 6LowPAN network, it has to manage these differences. Let us try to understand.

As IPv6 packet has a limit of 1280 bytes minimum, thus it cannot have a packet smaller than that size. This limit creates a problem for 802.15.4 radio link as the maximum packet size of it is limited to 127-bytes only. Out of these 127 bytes, 25 bytes are maximum possible overhead. That makes it 102 bytes available for data. Additionally, the content is encrypted and also authenticated and thus actual size of data that can be sent over the link is reduced to just 81 bytes5 as the authentication tag size is 21 bytes.

Another issue is the address size. An IPv6 protocol uses an address size of 128 bits. One typical method is to use IEEE 64 bit extended address for each device6. Interestingly, a shortened address of 16 bytes can also be used. This, however demands address resolution process. For example, a query is like: whose IP address is ABC2347D0x (a 128-bit address)? This query is responded back by: Mine, I am 100…11 (a 16 bit or 64-bit address), by the node whose address is so. Conventional networks can sustain such broadcasts but these networks cannot. We will soon see what they do to eliminate such broadcasts.

5 The Encryption is done with AES (Advanced Encryption Standard), where each 128-bit block of data is encrypted at a stretch, provides authentication using a method known as CCM (Counter Cipher Block Chaining Mode).

6  Reference 2 has an entire chapter of IPv6 where this part is explained in more detail.

The parameters to be optimized are different for IP networks and 6LoWPAN networks. For example, IPv6 nodes stress a lot on optimizing the speed and getting larger bandwidth, often at the cost of more power consumption. On the contrary, power saving is the prime issue, low bandwidth is not a problem in most cases.

The 6LoWPAN works like this. At the sender, the IPv6 header is compressed first. Once that is done, the IPv6 payload is fragmented into small segments which can fit into 802.15.4 payload. These small segments are known as fraglets. These fraglets are forwarded by 802.15.4 nodes till it reaches the destination. Once the destination is reached, the receiver collects these fraglets, decompresses the header and generates the original IPv6 packet from it.

To do this complete job of converting an IPv6 packet into fraglets and back, an additional layer is provided, called a shim layer. This layer converts packets into fraglets in the sender and vice versa at the receiver. This shim layer is also called the adaptation layer because it helps converge from one type of traffic into another (i.e. IPv6 traffic into mesh traffic). That layer is also responsible for address management.

The routing process involves two different cases, one, between the devices of the mesh, and between an IPv6 domain and the mesh. To address this problem, ITU is working on LOADng7 protocol which is a variant of AODV and IETF is working on RPL protocol8. We will look at RPL in next module but won’t be describing LOAD now onwards as it is quite similar to AODV.

The IPv6 has a network discovery (ND) protocol. The IPv6 network node can send ND request (called Neighbor solicitation message) to the neighbor to check if the neighbor is reachable. It is also used to learn the MAC address of the neighbor. This neighbor discovery process is improved to work with 802.15.4. This method also demands to broadcast the query to all neighbors. How such queries are eliminated in 6LowPAN is also discussed next.

Neighbor discovery extension for 6LoWPAN

The IPv6 protocol uses ND for reachability assessment (finding out if a neighbor is alive) and learning MAC address (what is the MAC address of the neighbor). Apart from that, it is also used for checking if a self-assigned (or auto-configured) address is duplicate. An IPv6 node can assume a 64-bit random value as its own address9. Based on the laws of probability,

7 This is acronym of 6LoWPAN Ad hoc On-Demand Ad Hoc Distance Vector, next generation, a simplified version of the AODV protocol we looked at earlier.

8 Interestingly, this is the place where there are three different standardization bodies working on. IEEE is working on 802.15.4 as it is data link layer and part of the card, IETF as it involves internet and IP, ITU because it involves the telecom.

9  This process is known as auto-configuration given a usually small number of nodes in a network, it is highly unlikely that two different nodes, choosing address randomly, decide the same random value as their address. However, it is critical for each node, after choosing the address, and before start using it, to check if it is indeed unique. The ND protocol is also used to check if so.

The problem is, when we want to use the same protocol here, we will not be able to reach all nodes directly. When we use network discovery to reach all nodes in a conventional network, a simple broadcast reaches all nodes of the network and the sender gets clear idea if the 64-bit random value it chose is really unique or not. Unlike that, in mesh networks, the broadcast might not reach to some (in most cases, many) nodes and thus cannot guarantee to reach each node. Another important issue is, we would like to have a solution where such broadcasting is either eliminated or minimized to save energy.

Two more interesting jobs of the IPv6 protocol are called Router Solicitation and Router Discovery. Router Solicitation is a message coming from router for all devices recently joined the network. It says something like this “Hi, I am router X, for any communication needs, kindly send me your packets”. On the contrary, router discovery is a message from a new comer (or from a node just started working). It looks like “Hi, I just joined this network, any routers here? Please respond.”. Both these messages are critical for adapting to changes in the network like a new router joining, a router coming up after being down, or a node coming up after being down or joining afresh. This solution demands broadcasting which we would like to avoid.

Moreover, the mesh network based on 802.15.4 only has an option of broadcasting and no multicasting. It is not possible for a node belongs to 802.15.4 to multicast a message to select neighbors. That means, it is not possible to restrict the message forwarding to a small number of nodes using 802.15.4. The designers need to find a solution where they do not need to use broadcasting.

The special ND protocol designed to work with 6LoWPAN is known as 6LoWPAN-ND and is a little different way neighbors are being discovered. It is a modified version of IPv6 ND protocol10.

Here are some goals of this modified protocol.

1. Minimize the number of multicast messages, for cases like

a. No multicast for duplicate address detection

b. Limit multicast for router solicitation and router discovery

c.  Avoid or reduce neighbor solicitation messages

10 The RFC calls this protocol LowPAN

2.  Minimize unreachability messages for neighbors.

To achieve these goals, mapping of IPv6 packet to a 6LoWPAN network acts differently. For example, it assumes the topology and addresses mapping work in the manner where we have already learned. Some of the assumptions are as follows.

1. Each mesh network will have a PAN ID and it acts like one IPv6 subnet (a small portion of network with a unique prefix)

2. Each PAN has at least one coordinator (which is an FFD), which is also an IPv6 router

3. Each node of this PAN is auto-configured (chooses its own address of 64 bit using a random number generation method)11

4. Every node knows how to forward a packet

To reduce multicast, Router Advertisement and Solicitation are not broadcasted. The FFD which is the PAN Coordinator is the only router assumed and no other FFD can act as a router, there is no need for both of these messages.

To reduce ND messages, the nodes have their MAC addresses known to their parents12, either by some MAC layer protocol or administrators configure them.

Minimizing unreachability is also managed by making sure the PAN coordinator (Central Router) learning about all nodes and keeps on updating itself and periodically let other nodes learn about that rather than nodes doing this themselves by broadcasting.

To handle assessment of duplicate addresses, the 6LoWPAN uses a simpler registration approach. Every node must register their address with the coordinator and thus avoid broadcasting. If ever a duplicate address is found, the coordinator will inform the node and process further13.

In a way, all mechanisms that demand broadcasting is either avoided or changed.

Mesh Link Establishment

Interestingly, IPv6 expects links being established and tested before the communication commences over a link. The mesh links, being wireless, are lossy as well as unreliable. The

11 one may ask, the IPv6 address are of 128 bit, here we are discussing generation of 64-bit the value as an address, what about rest 64 bits? That is called network prefix. The network prefix for an IPv6 network is decided using other methods. Adding a prefix to this 64-bit value makes it complete 128-bit address.

12 Considering the tree where the coordinator is the root

13 as per the IPv6 specification, when auto-configuration process fails, there have to be some other means of getting the new address, the node cannot work further on its own unless administrator assigns it a new address by some other method. There is no process of choosing another random value in the auto-configuration process.

IPv6 implements IPsec by default and thus encryption and authentication are needed from the word go. That means, we need to have an additional protocol for establishing, testing a secure all links in a mesh network.

IETF has provided one such protocol known as MLE or Mesh Link Establishment protocol.

The MLE adds three capabilities to the wireless link.

1. Dynamically configure and secure radio links by encrypting the content and providing authentication.

2. Enable network wide change of radio parameters like long (64 bit) or short (16 bit) addresses, initialization of the security related information etc.

3. Detecting neighboring devices, by sending a request about the quality of the link to their neighbors. Neighbors will have their own estimate about the same link from their side. This, seemingly strange requirement, is due to the fact that the links in the 6LoWPAN are asymmetric. For example, when an FFD is connected to RFD, one side of the link is powerful (from FFD) while the other may not be that powerful (From RFD).

MLE operates below IP layer. That means IPv6 gets the service of secured, working links. Maintaining each wireless link is done by MLE and thus it is transparent to IPv6. One more important job of MLE is to find out the best link to the coordinator if there are multiple links available.

The routing and forwarding for 6LoWPAN networks

The 6LoWPAN network nodes need to forward incoming packets like normal network nodes do. However, it is not as straight forward as in the case of normal network nodes. A node in this mesh network may have very less memory and processing power that it cannot even store forwarding table in the memory. These networks are much smaller in size, containing 10 to 20 nodes on an average, and thus the tables do not contain many entries. So Some of the nodes may be able to store information about other nodes. The nodes which can store forwarding tables are known as storing nodes while others who cannot, are known as non-storing nodes. The routing process must be able to handle both types of nodes.

Another issue is about the visibility of some nodes to the coordinator, some of them are directly connected while some nodes are not. Visible nodes are known as on-link nodes while not directly accessible nodes are known as off-link nodes. The solution deployed by IPv6 is called source routing, which describes a complete path to reach to that directly unreachable node. The conventional ‘network prefix’ approach cannot work as not all prefixes are possible to be connected directly.

The non-storing nodes only contain two types of information. First, list of all directly reachable nodes from it, and second, one node which is connected with the coordinator. When such non-storing nodes are part of the network, they send their information to the only option that they have, to the coordinator via the node they know connected to it. When the coordinator learns about every other node, it can generate a spanning tree for reaching all nodes, we call it forwarding tree. Once this forwarding tree is available, the routing process is carried out in a fashion similar to 802.11 PCF mode. Every sender sends its packet to the coordinator and coordinator sends it to the receiver. Thus every communication is a two-step process. This seems to be waste of time but eventually, it helps the devices to be freed from storing any information that drains its battery or consume important memory otherwise useful for its own processing. However small number of nodes exists in a typical mesh network, total number of combinations for each case may be overwhelming for a tiny device like a temperature sensor or habitat monitoring node. So, they prefer to remain as non-storing node.

On the other hand, the storing nodes need to keep information about the complete topology of the network. This will enable them to send the packet to the best possible route. As the topology is semi-permanent as some nodes may change their position over a period of time, they also need to update their knowledge about topology over a period of time. When IP needs to send a packet across, it uses this information to send it. You can see that conventional routing protocols are not preferred here as they demand periodic broadcasting either to the neighbors (DV) or every other node of the network (LS), both of which are highly inappropriate.

The routing process, actually need to handle a case where both of these types of nodes are part of the network. That means, when the routing takes place, some nodes only know whom they are directly connected to and one neighbor who connects to the coordinator while some other nodes have their own forwarding table. Obviously one needs an additional routing protocol to implement this type of processing. That protocol is proposed from IETF, known as RPL which we stress in the next module.

Summary

We have looked at low power low bandwidth 6LoWPAN network characteristics in this module. We looked at the problems that are faced by such networks when processing using IPv6 packets. We have looked at route-over and mesh-under approaches and learned that route over is recommended for this network. We have seen some innovative ideas are used to make sure the broadcasting is minimized in these types of networks. We have also seen that a routing process demands to manage, storing and non-storing, both types of nodes.

References

1. Computer Networks by Bhushan Trivedi, Oxford University Press

2. Data Communication and Networking, Bhushan Trivedi, Oxford University Press

3.Internetworking with TCP/IP, Douglas Comer, Pearson