HeNNA – Naming for
Heterogeneous Disruption-prone Networks
Rao Naveed Bin Rais (Planete, INRIA Sophia Antipolis, France)
Mariem
Abdelmoula (Planete, INRIA Sophia Antipolis, France)
Thierry Turletti (Planete, INRIA Sophia Antipolis, France)
Katia Obraczka (University of California, Santa Cruz, USA)
[1]. Rao
Naveed Bin Rais, “Communication
Mechanisms for Message Delivery in Heterogeneous Networks Prone to Episodic
Connectivity”, PhD Thesis Manuscript. February 2011.
[2]. Rao
Naveed Bin Rais, Mariem Abdelmoula, Thierry Turletti, Katia Obraczka, “Naming
for Heterogeneous Networks Prone to Episodic Connectivity”, in Proceedings of
IEEE WCNC, Mexico, 2011.
HeNNA (Heterogeneous Networks Naming
Architecture) decouples nodes identification from location and allows message
delivery across heterogeneous networks, including infrastructure-based and
ad-hoc networks, while coping with nodes intermittent connectivity. In this
way, the source does not have to care about the current location of the
destination that may be connected using any interface at the time of message
arrival. For this purpose, applications bind to nodes identifier instead of IP
addresses to communicate and nodes location information is maintained by their
corresponding Location and Management Server (LMS) nodes. The LMS is a node
with a globally reachable address and it maintains location information about
the registered nodes. It is also responsible for storing messages on behalf of
the nodes when they are unavailable. Details can be found in [1] and [2]. The
idea is that nodes contact the LMS of other nodes to locate them. Nodes in
ad-hoc network can also be reached via neighboring gateways that are connected
to the infrastructure; this extends message delivery beyond infrastructure-based
networks.
In HeNNA, each node owns a globally
unique identifier (GUID), and we assume that the users will learn about these
GUIDs via a variety of ways such as search engines, private communication etc.
Otherwise, a global DNS-like service can also exist with which nodes register
their GUIDs against hostnames. This service can either have the normal DNS
functionality or a Dynamic DNS service, except that nodes are registered with
their GUIDs instead of their IP address. We do not consider the hostname to
GUID resolution. On the other hand, users have the luxury of having their own
private namespace of human-readable names which map to the GUIDs of the nodes.
This way of managing namespaces allows independence from centrally maintained
nameservers.
GUIDs are persistent identifiers,
though a node may change its GUID by registering a new GUID against its
hostname in the global DNS-like service. The GUID of a node contains a
routeable address of the node's LMS along with its identifier which is unique
within the context of the LMS. GUIDs can also be used to identify objects
instead of nodes without requiring major changes in HeNNA.
We implemented the preliminary
version of HeNNA architecture with an extended version of MeDeHa in the NS-3 Simulator
(compatible with version 3.5 and 3.9). The code along with the scripts to
execute the code can be downloaded from the links given below.
NS-3 HeNNA Implementation with
Scripts: ns-3.5, ns-3.9