Table of contents

Introduction ....................................................................................................................................................... 3
IPv6 .................................................................................................................................................................... 3
Address space ................................................................................................................................................ 3
Header ........................................................................................................................................................... 4
Neighbour Discovery (ND) ............................................................................................................................. 5
IPCMPv6......................................................................................................................................................... 5
6LowPAN ........................................................................................................................................................... 6
Architecture ................................................................................................................................................... 6
IP Header Compression (IPHC) ...................................................................................................................... 7
6LowPAN Addressing..................................................................................................................................... 8
Fragmentation ............................................................................................................................................... 9
Setup & Operation......................................................................................................................................... 9
Mobile IP.......................................................................................................................................................... 11
Terminology ................................................................................................................................................. 12
Basic operation ............................................................................................................................................ 12
Mobile Routing ................................................................................................................................................ 14
Reactive Protocols ....................................................................................................................................... 14
DSDV: Destination-Sequenced Distance Vector .......................................................................................... 15
DSR: Dynamic Source Routing ..................................................................................................................... 15
AODV: Ad Hoc On-Demand Distance Vector ............................................................................................... 16

1
2
Introduction
Most of the communications based on the IP protocol follow the IPv4 version. Ipv4 is quite heavy
for embedded systems, that have some constraints in energy consumption and don’t need high
bitrate.
In the IoT there is a huge number of devices, but Ipv4 is only able to address some billions of
different devices (high, but not so high).
IPv6 and 6LowPAN are the main proposal for the IoT. Let’s have a look at them.
We will then see the solution to the routing for mobile nodes with Mobile IP.
Finally, we will deal with Wireless Routing.

IPv6
IPv6 is defined in the RFC 2460, and it is designed to be the next generation of IP. It has a totally
new design for addressing: it is able to address 2^128 devices in a “hierarchical” way. The
addresses can be autoconfigured in a stateless way. The routing mechanism is simple.
A lot of devices are IPv6 ready, but the transition is still taking place, in fact different governments
are requiring IPv6.
An IPv6 address is usually represented in hexadecimal (because its length), with two dots as
separator of groups of 2 bytes (4 hex digits, with a total of 8 group). The zeroes can be omitted in
order to shorten it, but the two - two dots must be put to highlight the omission.
Ipv6 was designed to send a lot of data. So sometimes is not suggested in contexts where few data
are needed to be send. 6LowPan, as we will see, is better in those contexts.
IPv6 removes some IPv4 features considered useless today. It has also a better QoS.

Address space
The IPv6 address space is divided in two part:
1. 64 bit (4 groups) for the prefix, that identifies the network uniquely, in the global level and
in a hierarchical way;
2. 64 bit (4 groups) for the Interface ID (IID), that identifies the single network interface
(remember: some devices has more that one network interface) within a network. This is
tipically (but not always) autogenerated from the MAC address of the network interface
with the so called Stateless Address Autoconfiguration (defined in RFC 2462).
There are some special IPv6 classes:

• Loopback address: 0::1 (0 in the prefix and 1 in the IID)

• Unspecified address: 0::0 (all 0s), used from a node that asks for an Ipv6 address from a
DHCP server when the autoconfig. Is not used.
• Unicast with global: 2001::, that acts as a global network
• Link-local: FE80::, that must be used for autoconfigurated addresses within a local network.
So the router will not forward a packet with this address to other routers.

3
 • Site-local: FEC0::, that acts as an equivalent of the IPv4 private address space. So a router
will not forward a packet with an address like this to the outside.
• Multicast addresses: FF00::, used for multicasting;
• Anycast addresses: Un indirizzo anycast serve per inviare un pacchetto a un gruppo di host
ma ne basta uno che lo riceve. Non hanno un particolare schema, va deciso ad hoc quale
indirizzo assegnare a quale gruppo di host.
Subnetting is possible in the usual way, however only the / notation is possible, with a decimal
number to represent the size of the netmask.
How does the autoconfig works? Look at this example
1. Take the MAC address, for example 52:74:f2:b1:a8:7f
2. Put the value ff:fe in the middle: 52:74:f2:ff:fe:b1:a8:7f
3. Reformat to IPv6 notation (groups of 4 hex digits): 5274:f2ff:feb1:a87f
4. Convert the first byte from hex to binary: 52 -> 01010010
5. Invert the bit at index 6 (counting from 0): 01010010 -> 01010000
6. Convert Byte back to hexadecimal: 01010000 -> 50
7. Replace the first byte with newly calculated one: 5074:f2ff:feb1:a87f
8. Prepend the link-local prefix: fe80::5074:f2ff:feb1:a87f
9. Here you are!
This setup is automatic in the IPv6 network interfaces.

Header
Comparing the Ipv4 and IPv6 headers we can see some import differences:

• No more Header Length because the size of the header is fixed at 40 bytes and no more
variable as in IPv4 (because of the variable options);
• No more native Identification nor fragmentation. These can be achieved through a
particular Extension Header (see below);
• No more checksum, because nowadays network level routes are quite reliable. The
integrity is demanded to higher levels.
The structure of the header is:

• Version (4 bit): fixed at the value of 6 (decimal)

• Traffic Class (8 bit): that classifies the kind of packets in order to have a certain priority by
routers (QoS) + congestion control traffic.
• Flow label (20 bit): used for tagging packets with same behavior. Same behavior means
packets that are part of a same TPC communication. It is used to have a higher QoS (better
performances, routers provided special treatments)

4
 • Payload length (16 bit): # of bytes of the payload. At least 1280 byte and up to 64KB.
Determined by the MTU (Maximum Transmission Unit).
• Next header (8 bit): used as a pointer to an Extension Header, that is an extra header that
carries extra info for a packet. An Extension Header has a variable length but it is not
mandatory. Extension Headers have a this pointer too, so the pattern will be a linked list.
The last node of this list is the payload itself! Tipically a TPC/UDC message.
• Hop limit (8 bit): same as TTL in IPv4
• Source Address (128 bit)
• Destination Address (128 bit)

Neighbour Discovery (ND)

The autoconfiguration is done through the Neighbour Discovery. In this phase the host look for
other neighbours and routers, in order to construct an appropriate address. ND is also used to
have a first sight on the network, so to recover the addresses of other nodes and routers. Besides,
ND is able to look for an operating DNS server.
The discovery is started through an Router Solicitation (RS), multicast to the routers in the
network. Routers respond with a Router Advertisement (RA). This RA can optionally be
broadcasted periodically, instead as a unicast response, a beacon-like way.
The discovery the continues with Neighbor Solicitation (NS), sent in multicast in order to get the
MAC address of other hosts (it is enough to build its IPv6 address). The MAC address is put in the
Neighbor Advertisement (NA). This is the infamous Address Resolution Protocol (ARP).
This NS/NA schema can be used again to verify the reachability of a specific node (Neightbor
Unreachability Detection) and to resolve duplicate addresses (Duplicate Addresses Detection).
It is not prohibited the usage of DHCPv6 in conjunction with this ND.
These RS, RA, NS and NA are particular packets defined in ICMPv6.

IPCMPv6
Just like IPv4, we have ICMPv6 that is used for messages of control and notification, outside
normal data transfer, defined in RFC 2463. These can be Error messages or Information messages.
These packets are short and are used for:

• Error of unreachable destination

• Error of packet too big
• Error of exceeding of hop limit
• Request of echo (testing time)
• Reply of echo
• ND messages

5
6LowPAN
IPv6 requires to carry a payload of up to 64KB, and the minimum is 1280 byte… but the IEEE
802.15.4 frame is only able to support up to 127 bytes of payload (remember that the payload of
the frame IS the whole IPv6 packet).
IPv6 as it is in IoT contexts in not suitable… we need a variant: 6LowPAN
6LowPAN is IPv6 version designed for Wireless PAN. It reduces the size of the payload up to 127
bytes and removes some useless data. It is defined in the RFC 4919 and 4944.
It can work well with IEEE 802.15.4 (typical choice) but also with Sigfox (and other Narrowband
ISM technologies) and Power-line connections.
It has a low bandwidth, with a datarate of 250/40/20kbps depending on the reference radio range
of frequencies, respectively 2.4GHz, 915 MHz and 868 MHz.
It supports different kind of MAC addresses: other than usual 48 bit MAC (EUI-48, typical in non
IoT), it supports short MAC addresses of 16 bit and extended MAC addresses of 64 bit (EUI-64).
This changes the way it autogenerates its IPv6 address. The autoconfig. process uses the ND seen
before.
Multicast is mapped to broadcast.
There is a mechanism of Header Compression, as we will see later.
There is a mechanism to support fragmentation in instances where the packet to sent is too big,
as we will see later.
It supports IP Routing and Link-Layer Mesh.

Architecture
A LowPAN is a stub network, that is a network with a single exit point to the global Internet. The
exit point is called Edge Router. A stub network will not be passed for hopping external packets, so
its traffic is for outgoing and incoming data.
The Edge router act as a gateway from 6LowPAN environment to the IPv6 environment, so it
converts a device “local” 6LowPAN addresses to its global IPv6 addresses.
A Simple LowPAN has only a single Edge Router, but an Extended LowPAN is a sort of intersection
of two or more Simple LowPAN. An Extended LowPAN, clearly, has more than one Edge Router
and they talk to each other over a dedicated backbone link (they do the synchronization of some
shared data).
An Ad-hoc LowPAN does not need to be visible in the Internet, so it has no Edge Router.
Interfacing with the global Internet is not easy, because we have to deal with different problem:

• Some nodes still send IPv4 packets;

• Firewalls
• NAT
6
 • MTU of external packets greater than 6LowPan limit

IP Header Compression (IPHC)

6LowPAN does not use the canonical IPv6 header but applies a compression to it and a
compression to the UDP header too, of course only in the case the used transport protocol is UDP.
This format was initially defined in RFC 4944, and it is updating in the draft-ietf-6lowpan-hc.
Without applying a compression, the whole 6LowPAN must be up to 53 bytes, in fact in the IEEE
802.15.4 the payload field in the frame must be 53 bytes at most. Through this compression we
can reach a payload up to 108 bytes (we will manage the payload after this section).
This is done through the removal of useless information. This compression is stateless: the
compression is applied to every packet independently and without the sender/receiver keep info
from the compression.
The IPv6 header is compressed in this way:

• Version field is assumed to be always 6;

• Traffic class and Flow label are assumed to be always 0;
• No Payload length: it is demanded to the link layer protocol its calculation;
• The source and destination address can be compressed in 4 ways:
o If both are link local addresses (FE80::)
▪ They can be totally elided.
o If source is link local and destination is multicast (FF00::)
▪ Only the least significant byte of the Multicast prefix is identifies the
particular multicast group;
o If both are global and source IID can be derived by MAC
▪ An extra byte: CIE (see below) + the destination IID only is stored (2 bytes).
o If both are global but source IID cannot be derived by MAC
▪ An extra byte: CIE (see below) + destination and source IID are store (4
bytes).
• Next Header and Hop Limit are compressed in the “dispatch” byte.
The IPv6 header is replaced by 2 bytes of IPHC, describing the used compression schema:

• A Dispatch byte used to identify the type of header:

o First 3 bits, fixed at 011;
o 2 bits of Traffic Control: fixed at 00 right now:
▪ 00 Not a LowPAN packet
▪ 01 Normal dispatch
▪ 10 Mesh header
▪ 11 Fragment header (see below how I works)
o 1 bit of Next Header, it is 1 iff there is a UDB header following
o 2 bits of Hop Limit, so from 0 to 3 (limitation in the extended LowPAN).
• A byte named LOWPAN_IHC that states the kind of compression applied (there is more
than one kind):
7
 o 1 bit of CIE Context Identifies Extension, it is 1 iff the CIE byte must be inserted. The
CIE is used to compress global addresses.
o 1 bit of SAC Source Address Compression, it is 1 iff the source address is
compressed
o 2 bit of SAM Source Address Mode, says which kind of compression of the source
address is used
o 1 bit of MC Multicast Compression, it is 1 iff the multicast address (FF::) is
compressed
o 1 bit of DAC Destination Address Compression, it is 1 iff the destination address is
compressed
o 2 bit of DAM Destination Address Mode, says which kind of compression of the
destination address is used
After this IPHC we have 0/1/4/6 bytes of compressed addresses, explained before.
The UDP header (treated as the last next header in IPv6), from 8 bytes it becomes 4 bytes in this
way:

• A byte named LOWPAN_NHC that states the kind of compression applied (there is more
than one kind);
• The compressed source port;
• The compressed destination port;
• The usual UDP checksum.
So, the total size can be 6/7/10/12 bytes, obtained by: IPHC + Compressed Addresses +
Compressed UDP header. This entire structure is stored directly inside the IEEE 802.15.4 frame
before the IPv6 payload.

6LowPAN Addressing
In a LowPAN a node can be a relay node, that has two or more connection with other nodes or
with the Edge Router; a leaf node is only connected to a relay node. Relay nodes act as a sort of
intermediate routers, so decrementing the hop limit. This is more common in ah-hoc scenario. In
other scenarios we have all the leaf directly connected to the router or connected each other with
link layer connections, so treating with frames only.
Usually a LowPAN cannot be divided in other subnets: just one per LowPAN. So, we will have a
prefix number for each LowPAN. Having a single subnet and having a single Edge Router, there is
no need to put the prefix explicitly in the packets: the Edge Router stores the prefix for all the
devices in the LowPAN! Besides, no secondary addresses are allowed. We say that we have a Flat
Address Space.
Mac addresses potrebbero essere assegnati lo stesso devices che è in due network differenti
(extended lowpan) da due nodi coordinatori. Questo potrebbe portare a problemi di
comunicazione nella rete (questo è dovuto alla ridotta dimensione del frame). Si può risolvere
assegnando indirizzi ip a mano stando attenti a non avere collisioni. (?)

8
Fragmentation
We already resolved the problem of the large IPv6 header, but we still have the problem of the
minimum IPv6 payload size: minimum MTU of IPv6 is 1280 bytes!! In out IEEE 802.15.4 frame we
have up to 108 available bytes. We must find a way to “reduce” this 1280 into 108… we need the
IPv6 Fragmentation, defined in RFC 4944.
Fragmentation is not suggested in IPv6, because it creates an overhead in the network. But we
need it here: we must split the IPv6 packets in fragment that can be inserted in a single IEEE
802.15.4 frame. The fragmentation should be avoided in LowPAN contexts for various reasons:

• If a fragment is lost, then the entire array of fragments must be retransmitted;

• Fragments creates high traffic in low-bandwidth networks like LowPANs;
Fragmentation is typically used when there is need to send a lot of data to the global Internet.
In order to have a fragmentation we need some extra data before the IPHC. We will have two kind
of fragments:

• The first fragment that will be put in a frame, must have an extra header of 4 byte, called
FRAG1, then we have the usual triple: IPHC + Compressed Address + UDP compressed
header.
FRAG1 contains:
o 5 bits fixed at 11000, stating that this is a FRAG1;
o 11 bits Datagram Size for the number of bytes of the ENTIRE IPv6 packet that is
fragmented, according to the IPv6 MTU;
o 16 bits of Datagram Tag for the unique identification of a parent packet, needed for
reconstruction
• Subsequent fragments that will be put in a frame, must have an extra header of 5 byte,
called FRAGN, then we have the nth fragment payload.
FRAGN contains:
o 5 bits fixed at 11100, stating that this is a FRAGN;
o 11 bits Datagram Size for the number of bytes of the ENTIRE IPv6 packet that is
fragmented, according to the IPv6 MTU. This field in FRAGN header can be
optionally elided;
o 16 bits of Datagram Tag for the unique identification of a parent packet, needed for
reconstruction;
o 8 bits of Datagram Offset for the unique identification of the fragment of the same
parent packet, needed for reconstruction.

Setup & Operation

6LowPAN requires some variations to the autoconfigurations and ND. 3 phases for 6LowPAN
setup:
1. Commisioning, that establish the link layer connectivity of the nodes;
2. Bootstrapping, that does the IPv6 autoconfiguration and ND (slightly different from
canonical IPv6);
9
 3. Route initialization, that enables the IP routing algorithms seen in Computer Networks.
These 3 phases must be repeated continuously, because nodes can be added and removed
continuously in a LowPAN. A plug-and-play schema.
In the Commissioning phase these is assurance check whether all the nodes support the same PHY
and link layers, or at least compatible. In the instance of IEEE 802.15.4, it is checked whether:

• Channels (11-26 at 2.4GHz)

• Modulation
• Datarate
• Addressing mode (EUI-64 or EUI-16)
• MAC mode (beaconless or super-frame)
• Security (if encryption is used)
In the bootstrapping phase a different ND is used. Canonical ND is not suitable for LowPANs for
various reasons:

• It assumes that all nodes in the same subnet are on the same link layer segment;
• It assumes that all network interfaces are active;
• It sends a lot of packets: high traffic
ND for 6LowPAN is under construction in the draft-ietf-6lowpan-nd.
Periodically the Edge Router send the Router Adventirsement (RA) to nodes, in order to notify
them the prefix on the network to joining devices. After this, the joining nodes send a Node
Registration (NR) message to the Edge Router and it confirms it by sending a Node Confirmation
message (NC) and adding it to its table.
This NR/NC schema replace the NS/NA schema used in canonical ND, and it is able to implement
the Address Resolution, the Neightbor Unreachability Detection and the Duplicate Addresses
Detection.
Registration expires after a period (soft binding) and must be refreshed with a new NR/NC cycle.
If there are relay nodes, they act as edge routers for leaf nodes point of view. However, relay
nodes must notify the Edge Router of the presence of leaf nodes using the NR/NC schema: the
Edge Router must have the vision of all the nodes in the LowPAN! Relay nodes just helps it for the
multi-hopping.
The Edge Router keeps ALL these information in a Whiteboard, useful when it comes with:

• Duplicate Address Detection (it has trace of all the nodes addresses);
• Manages Extended LowPAN contexts. The different Edge Routers talk to each other in
order to sync the shared nodes: only of the whiteboard can keep it;
• It is used to generate short addresses.

10
Mobile IP
IoT devices may move within a great area called Region. There are different problematics at
different level:

• Phy and MAC level: Interferences, so transmission error. They can be solved with the
wireless mechanism seen before, like RTS/CTS.
• Network level: Addressing and routing are affected by continuing joining and leaving of
nodes. Which address is assigned? How to forward packets to them? Mechanism of device
location and hand-over (region switch) are adopted here.
• Transport level: the QoS is affected because congestion and flow are not easily controlled.
• Application level: problem in localization and adaptions.
The user focuses on the applications, so he wants to use the device without worrying about
mobility and he wants to join and leave a network at will and in an implicit way: hand-over.
Of course, all of these things must assure: security, management, fault-tolerance, accounting, best
use of resources...
Traditional routing sets up a static routing table stores in routers, tipically built with Link-State or
Distance-Vector algorithms. They are updated not so often, but here we have to deal with
mobility, so:

• Frequent route changes

• Reduced data transfer
Our goals are:

• Reduce the routing overhead (overhead data that is sent over the network by routing
algorithm during they build phase), so we want a lightweight routing algorithm;
• Find “short” routes, because we don’t want to saturate the network;
• Find “stable” routes, because we want to keep a route as long as possible. Clearly, a
network like this will always have moving objects.
Mobile IP (RFC 3344) is then proposed, extension of IP routing.
In traditional IP network prefixes determines the belonging subnet, so when a node leave and join
another subnet we had two alternatives:
1. The node will receive a new IP, conform to the new subnet;
2. The IP is preserved but the routing table must be updated according new path.
But the problems with these solutions are:
1. DNS (if used) takes too long to reflect the updates; TPC connections must be reconstructed
again; we have problems regarding security.
2. Does not scale well with the number of nodes and with the high rate of location change;
security problems again.
Another problem of joining another network is that the other network might use a different link
layer protocol that the node does not support.
11
Mobile IP proses to keep the same IP address and using the same link layer protocol using a
tunneling mechanism. In this way we do not need to update DNS, maintain the same TCP
connections and the routing becomes easier.
In short: a node belongs to a home network, and it has a certain IP address. When it moves to
another network, its home router acknowledge this and create a tunnel with the new network.
Every packet forwarded to this node will arrive at home router, but then it forward again to the
new router.
The home network is like our home, and new network is like a hotel, a temporary local where we
live, but not everyone knows that we are not at home, so they keep send packets to our home,
and someone forwards them to the hotel, in our room.

Terminology
We first need some terminology:

• Mobile Node (MN), the node/device that moves across networks and maintain the same IP
address; its original network is called Home Network;
• Home Agent (HA), router of the Home Network of a Mobile Node. It keeps track of the
actual network (Foreign Network) of the Mobile Node and realizes the IP tunneling;
• Foreign Agent (FA), router of the Foreign Network of a Mobile Node. It forwards the
tunneled packets received from the Home Agent to the Mobile Node;
• Care-of Address (COA), address of the Mobile Node in the current Foreign Network;
• Correspondent Node (CN), a host that is TCP connected with the Mobile Node. He wants to
maintain the connection without knowing its movements, without knowing that it the
Home Agent is redirecting the traffic to the current location.
Typically, the Correspondent Node sends packets to the original IP address he knows of the Mobile
Node. The Home Agent, clearly, intercepts the packets via proxy ARP. The Home Agent realizes
the tunneling by encapsulating the packet in a tunnel packet and sending to the Mobile Node at
its new address: the COA. The tunneled packet arrives at Foreign Agent, and it forwards to the
Mobile Node.
The Mobile Node respond to the Correspondent Node in the classical schema, because its Foreign
Agent act as a classical router and the IP address of the Correspondent Node is known.

Basic operation
These are the main operations:

• Agent Advertisement, Home and Foreign Agents periodically send advertisement

messages to all nodes in their subnets. If the Mobile Node is in the home network: nothing
is done; if the Mobile Node is in the foreign network: in this advertisement message there
is the COA for the Mobile Node.
• Mobile Node Registration, as soon as the Mobile Node receive a COA, it informs its Home
Agent through the Foreign Agent. And acknowledgement is sent back to the Mobile Node,
12
 through the Foreign Agent. Now the Home Agent would like to maintain the knowledge
that its node is away.
• Home Agent Proxy, the Home Agent maintains the original IP address of the Mobile Node,
and all the traffic for the Mobile Node is sent to Home Agent as usual. However, from this
moment the Home Agent will redirect the traffic to the Foreign Agent, but how?
• Packet Tunneling, the Home Agent prepare the packet for the Foreign Agent, so it will be
able to forward the content to the Mobile Node.
Note: The Agent is typically a router, but can also be another kind of node, the important is that it
acts as a mediator among many devices. This agent is also able to filter data, realizing some fog
computation. Fog is not edge computation. Edge is just gathering data, but fog is able to manage
them. It is typically done on servers.
We need a mechanism for discovery for the COA. This mechanism is built on Router
Advertisement (RFC 1256). The Router Advertisements are extended to carry a list of available
COA… just that, so we have our Agent Advertisement implemented. All agents send this
periodically, but a Mobile Node can raise a Solicitation Message in order not to wait for the next
Advertisement, in this case the Agent send back a message the available COAs.
We need a mechanism for registration between Foreign Agent and Home Agent. The Mobile Node
sends a Registration Request to the Home Agent passing through the Foreign Agent. The Home
Agent approves the request and send a Registration Response back to the Mobile Node. The
request may also be rejected, for example when a country has some strict rules. When accepted,
the Home Agent keeps track of the mapping Home Address – COA in a Binding Table.
We need a mechanism for tunneling. Two ways:
• IP-in-IP, the packets from the Correspondent Node that arrives to the Home Agent is
encapsulated in a new packet that has the sources address the Home Agent exposed
address and the destination address the COA of the Mobile Node. The encapsulation
contains the protocol value: 55 or 4, whether minimal or not encapsulation is used.
This hops to the Foreign Agent, that decapsulate the packet and forwards it to the right
Mobile Node. It’s a redirection!
• GRE
We also must manage how the tunneling is in reverse:
• Triangle Routing, packets from Mobile Node to Correspondent Node follow a different
path, so without needing the tunneling. Easy but this can cause problems with some
firewalls because they can have the rule to block the IP that were never seen before.
• Reverse Tunneling, packets from Mobile Node to Correspondent Node uses the tunneling,
in the same way seen before. This resolves the problems with firewalls said before.
Mobile IP has some issue:

• Routing Inefficiencies, caused when Triangle Routing is used. Besides, route optimization
cannot be done so often because of the continuing changes on the nodes.
• Security issues, like for firewalls said before in Triangle Routing, but not only…
13
Mobile Routing
With devices of IoT, and in general with ad-hoc connection known as MANET: Mobile Ad-Hoc
Network, we have infrastructureless schema for the topography of the network because we have
devices always in movement and not always visible to every node, so we have a multi hop relay
situation with constant route changes.
Typically, in a normal network we use routing protocol belonging link state or distance vector
family, that assumes that the routers know the addresses of each other’s, know the links between
them and their cost. They both allow a router to determine a global routing information by only
consulting its neighbor routers. In link state routers know the entire network topology and
computes the shortest path, distance vector instead knows all cost between routers and computes
the most convenient routes.
In a MANET the topology is deducted from information that neighbors send to each other. We
have three kinds of protocols:
• Proactive, traditional shortest paths protocol, routing tables are maintained all the time
and periodically updated. This creates high routing overhead! In some instances we can
trigger the update on status change of a device, reducing the load. An example is DSVD:
Destination Sequenced Distance Vector, as we will see.
• Reactive (or on-demand), the route is determined only when needed, so only when a
packet must reach a certain destination. When a source (of course a router or anyone with
the knowledge of the network via routing table) wants to reach a certain destination and
the route is not known, the discovery phase starts. They usually have better performances
than proactives. Some examples are DSR: Dynamic Source Routing and AODV: Ad Hoc On-
demand Distance Vector, as we will see.
• Hybrid, where the proactive is normally used with reactive behavior if needed. Not very
used. An example is ZRP: Zone Routing Protocol, but we will not see this.

Reactive Protocols
Our goal is the reduction of the routing overhead, in fact in MANETs the number of traffic sessions
is much lower than the number of nodes. So we don’t have a routing structure since the start but
it is created as soon as a packets are send to unknown routes. Of course, all the discovery phase is
overhead, but it is “distributed” in the time. However, this overhead means a direct delay for the
packet that wants to go on an unknown path.
Two methods for route discovery:

• Source Initiated, we will see;

• Backward Learning, similar to intra-AS routing;
Pros: we eliminate the periodic updates and the network adaption is dynamic. Cons: the discovery
itself implies quite high flooding and latency.
In the source initiated, the source (router) that wants to send a packet on an unknown path, start
to send a Route Request (RREQ) packet, sent in pure flooding to the whole network, so that this
request is retransmitted by the nodes only once, without useless replicas (if a node already
14
retransmitted the very same request, it will not do it again). The request contains an IP address of
the destination, and when it is received, it replies with a Route Reply (RREP), using the same path
that the request did but in reverse, in fact the request keeps track of the hops it did to reach the
destination (explained better below).
Differently from reactive ones, proactive protocols:

• Always maintain routes, that must be maintained updated, so we have periodic peak of
high traffic due to flooding;
• Some paths may be unavailable, but they are still kept in the tables, until the next update
(bad);
• No overhead during the period of non-updates (good);
Reactive ones are the most used the IOT context right now, because, like MANETs, we have
frequent topology updates. However, flooding is very problematic in IoT! But for now, we use
these solutions.

DSDV: Destination-Sequenced Distance Vector

One of the most important proactive protocol. Like every routing protocol, every router needs to
maintain a routing table which store entries with: the destination IP address, next hop IP address,
a cost value (typically hop count) and a destination sequence number (DSN), first established by
the destination node itself in the moment it joins the network (in fact this protocol is proactive).
The table is then forwarded to the neighbors periodically, but before sending it, the sender
increments its sequence number and appends it in each entries of the table, so the whole DSN will
grow. Typically, the sequence number is increased evenly.
In this way, every entry in a table will be tagged by a certain DSN, and when an update with a
greater sequence number comes it is considered more reliable than this one and substituted.
If a node decides that a route is broken then it increments the number of the route to infinite,
stating that the route is unavailable, similar to the “route poisoning”.
When two DSN are equals then the cost value is used to decide.
The greater the sequence number the longer the life of that node on the network (node age),
that’s why it is considered more reliable.
When a route must change, the whole process is repeated and due to the previous increases of
the sequence number the new path will be bigger that the old one, so more reliable.
Not very used and not suitable for high mobility networks.

DSR: Dynamic Source Routing

Very used in IoT and it was the first reactive protocol. It has different phases:
• Route Discovery phase, where the source node S wants to send a packet to a destination
node D. The RREQ is sent in (pure) flooding across the network and every node that
forwards the RREQ push its own identifier in it.
15
 The longer the path, the longer the RREQ, of course.
When RREQ arrives in D, it stops the forwarding, of course.
• Route Reply phase, when D receives the first RREQ from S it sends a RREP back to the same
path, in fact the RREP will have the stack of identifiers and will pop out the identifier of the
next node that will receive the RREP… this until the RREP arrives in S.
• Data Forwarding phase, where now S can send data to D because the S’s routing tables will
store the entire list of identifiers to reach D. In fact, in every data packet that S sends to D
it must put the list of identifiers inside it.
The longer the path, the longer the data packet header, of course. However, this is good because
there is no need to store all the path on different routing tables but only on a single entry in the
source node table. So, the deletion of a route is easy and fast.
What if a route is not valid anymore? How does S acknowledge this? An ACK schema can be
implemented or a timer can be used to determine whether the route is valid or not. Typically, an
ICMP message can be used to check if a path is reachable before starting so send data at all.

AODV: Ad Hoc On-Demand Distance Vector

Like DSR, pure flooding is used to spread the RREQ, but with a slightly different discovery phase.
Whenever a node N receives the RREQ from S, it may forward it just like DSR or it can build the
RREP by itself without needing to forward the RREQ anymore only if N already knows a path to
reach D.
So, when S has to send a data packet to D, it forwards it to N with the same mechanism used in
DSR. In this case, there is no need to maintain the whole list of identifiers in each data packets
from source to destination, because a semi hop-by-hop schema is possible.
In AODV each path has a limited duration (aging), so they will expire if not used for a certain time.
The fact that some routes expire is good because we will have fewer useless connections and so
less flooding.
This optimization is good, but, differently from DSR, we can have routing loops if a link fails!

Assume that link C-D fails and only C know about this fact.
C wants to know a different route to reach D, so it sends a RRQE in flooding.
At a certain point A receives the RREQ from C passing through E.
A consults its routing table and see that D can be reached by hopping to B, so it sends a RREP C
telling it to hop to it when it want to reach D.
C updates its routing table and store the list of identifier to reach A in cases it wants to send a data
packet to D.
16
But A didn’t know about the C-D link failure, so it forwards to B packets with D as destination.
B sends them to C, and C to A through E… loop!

This problem can be solver using the DSDV method: sequence number.
Each node X maintains a sequence number, just like DSDV. It acts as a time stamp and
incremented every time that X sends any packet.
For each node Y, in each route to X there will be the last X’s sequence number that Y knew when it
built the path to X. A higher sequence number means a fresher and more reliable route.
In an RREQ for destination D there will be the its sequence number inside (DSN), starting from 0 if
it is the first discovery of D.
For example, when a node S wants to reach D and S already had the path to D with a sequence
number of 10, it send the RREQ with the destination sequence number (10).
When it reaches Y that has a route to D but with a value of 7, Y decides not to reply because its
path is less reliable than the one already owned by S, so it keeps forwarding the RREQ…
This mechanism is called Loop freedom, in fact it guarantees loop avoidance and can be verified in
the previous example if C has a DSN of D at 10 and A at 7.

17