| Yijian Li, liyjian at wustl.edu (A paper written under the guidance of Prof. Raj Jain) |
Download |
Keywords: naming, naming scheme, IoT, IPv6, 6LoWPAN, IPv6 over Low power Wireless Personal Area Networks, URI, uniform resource identifier, AAID, Access Address/Identifier, GS1 identification key, sensor UID, IoT@Work, CCN, Content-Centric Network, NDN, Named Data Networking, MobilityFirst, GUID, Global unique identifier.
The naming scheme is an important component of any kind of Internet architecture. With the arriving of Internet of Things (IoT), naming schemes became parts of the solutions to the new challenges that lie ahead. Some are based on IP structure which is the cornerstone of today’s Internet. Some are brand new schemes part of future Internet architectures aiming to solve the tricky problems such as mobility and security for good. In this paper, we will discuss some representative naming schemes including those based on traditional architecture (sections 2 and 3) and the new ones (sections 5 and 6). Between them, section 4 will focus on the way naming schemes can be constructed and the motivation for new naming schemes in the context of IoT.
IP is the fundamental structure of today’s Internet and IPv6 is expected to be the base of IoT in the future. But the traditional system, which typically lacks mobility and security inherently, is way behind the growing needs. The extensions of IPv6 and alternative solutions built on IPv6 have been proposed as the effort to let IP move into the future Internet.
The most common naming scheme in the current Internet is with no doubt uniform resource identifier which is used to identify a name of a web resource. The IP structure and related technologies provide reliable connection after the resources are located. IP address itself is also an identifier as it reveals the location and identity of a host or network interface. The Domain Name System (DNS) enables people to use URI, which is more friendly compared to IP address, to connect to certain web resource without knowing the IP address of it.
The Internet is now connecting millions of web resources together via the three systems, i.e. IP, URI and DNS, mentioned above. As the information technology evolves at an astonishing rate, however, traditional structures have begun to struggle to keep up with the change. IoT which is the future of the Internet presents the trickiest challenges. With all the infrastructure and standards built on these systems, it will be unwise to totally discard them. A lot of efforts has been done to adjust and extend these systems, mainly IP, to keep them usable in the future Internet.
IPv6 is the final solution for the originally very limited IP address space. By providing 10^38 possible addresses [Atzori10], IPv6 will meet the needs of not only the constant growing Internet nowadays, but also IoT which will contain 50 to 100 billion connected things by 2020 [Jara12]. Despite having had a slow start, IPv6 is still being assumed to be the natural selection for future Internet. Small and low power sensors and devices which are not designed to implement IP in the first place will also be an important part of IoT. This requires IPv6 to be extended to cope with these kind of devices.
IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) is a solution provided by the Internet Engineering Task Force (IETF). So far most of the personal area network of these low power devices and sensors with limited processing capabilities are using specifications like ZigBee and WirelessHART which are based on the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard. The way 6LoWPAN extends IPv6 to these devices is to allow IP packets to be transmitted over IEEE 802.15.4 based networks through encapsulation and header compression mechanisms [Wiki2]. With IPv6, these previously separated nodes could be integrated into bigger IP network and ultimately the whole IoT. We can use URI and/or IP address to locate and connect to these small devices around us.
If IPv6 can be extended to small objects connected via wireless network, then there comes another issue that how to put radio-frequency identification (RFID) tag which has been standardized by EPCglobal into the IPv6 framework. As one of the most widely used naming schemes, RFID tag uses 64-96 bits identifier and is the ID of millions of small objects. By now two major approaches [Atzori10] has been discussed. The first one is to use an agent to map the RFID identifier to a 64 bits field and then apply it as the interface ID of the IPv6 address. Another one is the RFID information is carried as the payload of the IPv6 packet.
One of 6LoWPAN’s inherent disadvantages is that it has a relatively long overhead which highly limits the size of payload with in a IEEE 802.15.4 frame. 6LoWPAN requires a 26-41 bytes overhead. Taking the 25 bytes with the extended MAC address into account, overhead will occupy up to 52% of the 127 byte-long Maximum Transfer Unit (MTU) provided by IEEE 802.15.4 standard. This will cause the system to be severely inefficient. In [Jara12], authors proposed a solution to this problem in which a new naming scheme, Access Address/Identifier (AAID), is included.
Glowbal IP protocol, an alternative to 6LoWPAN, enables IPv6 to connect to a IEEE 802.15.4 based network. AAID is a key part of this protocol because it can significantly shorten the length of overhead, which is a big trouble in 6LoWPAN framework. When a connection between a client and a node is set up, a 32 bits AAID is generated by hashing source IP, destination IP and destination port of each node. The typical overhead of IPv6 will be replaced by a much shorter AAID when the initialization process is done. The reduced 22-35 bytes overhead means there will be 40% to 60% more space in the payload. A gateway or a border router does the translation job, as showed in Figure 1 below, between the AAID within a IEEE 802.15.4 based network and the global IPv6 network while it negotiate with the node to generate the AAID.
On the other hand, the mobility and muti-homing issue which comes along almost every IP based solution is still a big challenge for Glowbal IP protocol and AAID. It will be much more complicated to generate and manage AAIDs when things are moving.
Besides IP related solutions, some other naming schemes have been developed to deal with IoT needs in certain areas such as manufacture industry, logistics and sensor network. Although they may not have the potential to be the cornerstone of future IoT, they will have a place in the future due to their great performance in specific tasks.
GS1 is an international non-for-profit organization dedicated to the design and implementation of global standards and solutions to improve the efficiency and visibility of supply and demand chains globally and across sectors [GS1]. Standardizing the method of naming millions of small objects is an essential part of their work. They introduced the GS1 Identification Keys as the naming scheme in the standard. The key steps of assigning a GS1 Identification Key include getting a company prefix, assigning numbers and selecting bar code and its related parameters. The keys can be used to keep track of the status and location of the objects globally.
The Object Name Service (ONS), developed also by GS1, enables the objects using GS1 Identification Keys to be located via Internet. The DNS is leveraged here to locate the specific item in the way that ONS transforms the GS1 Identification Keys into a format that DNS could understand [EPC13]. As DNS is available all over the Internet and it requires no modification to DNS servers, this naming scheme can be integrated into the traditional structure with limited extra cost.
Several IoT projects, such as SmartAgriFood and CEN TC225 [Bauer13], have taken this as their primary naming schemes. Although some disadvantages discovered in practice will limit its function in future IoT, it still has its value as an efficient system cover millions of small objects.
Sensors are applied in many places in everyday life, from traffic monitors to satellite imaging devices. They are indispensable in future IoT because they are the main sources for real time data. Sensor Web Enablement (SWE) standards, developed by Open Geospatial Consortium (OGC), enable developers to make all types of sensors, transducers and sensor data repositories discoverable, accessible and usable via the Web [SWE].
Among all the major SWE standards, Sensor Model Language (SensorML) is the one directly related to the naming scheme for sensors. It provides the standardized model and Extensible Markup Language (XML)-encoding which is used to describe different kinds of sensor related processes. One of the description collected is the metadata of sensors or sensor system. The metadata can be mined and used to retrieve the important parameters one of which is the identifier, i.e the name of the sensor. In [Hu11], the authors created a SensorML-based template and adopted the Sensor UID and Platform UID defined by International Standard Organization (ISO) 19130 as the identifiers in the metadata. In this way, the sensors, especially remote sensors, have the ability to let others discover them within a standard framework [Wiki1].
SensorML is an early work for descriptions of IoT related data and the usage of XML caused severe limitations on semantic interoperability which is a big issue because the connection and communication between devices in different scenarios will be everywhere.
The Semantic Web is a proper solution for the interoperability issue. In fact the URI mentioned in section 2 is an example of semantic ontology. It is a base standard for the Resource Description Framework (RDF) which is a family of World Wide Web Consortium (W3C) specifications. Apart from URI, other semantic ontologies support different kinds of naming schemes. In this section we’ll talk about one case of them.
IoT@Work is a European Research Cluster on the Internet of Things (IERC) project mainly focused on factory automation systems auto-configuration and improved security [Bauer13]. In the project, to address the events happening in a factory production context, they devised a mechanism called Event Notification Service (ENS) which adopts a publish/subscribe model instead of the request/response one in traditional system. Also Namespace, a hierarchy structure dedicated to solve the naming issues, is built in order to let ENS function properly.
In a Namespace, a set of published events related to a certain need or service are organized together in the form of a tree which is shown in figure 2 below. The leaf nodes in it are normally refer to a physical entity like a certain robot of a production line while the intermediate nodes are virtual entity implemented to simplify the way subscribers get the information they want. Each node has four major attributes which are Name, Description, EntityURI and a URI. Among the four, Name is the identifier of the node and the other three is used to accelerate and improve the handling of the event. Because the nodes of different Namespaces are typically uncorrelated, under totally different hierarchy there could exist leaf nodes named in the same way.
The hierarchy naming structure is particular good for communication between client and object. However, to the Machine to Machine (M2M) communication mode which will be critical in the future IoT, this way is inefficient. Mobility will be a big trouble for this scheme, too.
The new requirements proposed by IoT are affecting the naming scheme which is a part of the basic structure. A rapid change of the naming scheme is happening. New schemes are being developed via several major methods and will play a key role in future Internet architecture.
IoT is a complicated vision of the future Internet. It is hard to summarize the trend it will bring, for there are too many areas need to be taken into to account. Nonetheless several major issues are universally considered important. They are connectivity, scalability, mobility, management and security. Additionally the mammoth number of objects involved in IoT makes the challenges much more difficult. Even with the progress achieved in cloud computing, big data and many other frontiers, the traditional Internet structure still requires major modification or ,to the authors of [1Li12], a clean-slate redesign of the current infrastructure.
Naming issue naturally is an essential part of the structure and the daily operation of the Internet. Currently IP and URI are doing the excellent job in naming and locating the resources available online. Some other schemes like those mentioned in section 3 are designed for specific tasks which is beyond the reach of IP and URI. But what the IoT really needs is one naming scheme that can be the base of the whole IoT and can integrate all kinds of sub naming schemes into one framework. IPv6 with appropriate extensions is a promising candidate as long as it can fix some inherent problems like mobility and security in IoT services.
In the vision, IoT will provide various services to accommodate service need on different level such as personal, enterprise or scientific research. In [Gigli11], IoT services are categorized into four types: identity related services, information aggregation services, collaborative aware services and ubiquitous services. Each service has its own demand when it comes to naming issues. For instance, information aggregation services may not require that each object has a unique name which is mandatory in identity related services. This means that the chosen naming scheme of the future IoT should be flexible enough to provide any certain kind of service.
Identification is one of several functions performed by a name. In IoT this function is the most important one because finding one object is pretty hard when there are billions of things available. In our daily life, license plate and social security number is examples of identifiers. Identifier can be globally unique, like fingerprint, or unique only within a certain scope, like zip code.
Identifiers are usually the target of naming schemes related to IoT. In [Bauer13], authors listed four primary methods used to construct an identifier. They are random data, hierarchy identifier, encoding additional information (e.g. manufacturer, locator), by cryptographic operations (e.g. hash of public key). One scheme can apply several methods in the same time. In table 1, the methods used by each scheme mentioned in this paper including the two new schemes will be discussed later are listed. As a matter of fact, these methods are sufficient for constructing any new naming schemes.
When devising a new name scheme, generally there are two approaches, reusing a scheme already there or define a new one. The latter approach requires a mapping mechanism to integrate itself into an existing scheme in order to provide service in a much broader scope. That’s exactly what AAID has done and RFID based schemes such as GS1 identification keys haven’t done.
| Project or Architecture | Naming Scheme | Method applied |
|---|---|---|
| IPv6 | URI | hierarchy identifier encoding additional information |
| IPv6 | IPv6 | hierarchy identifier |
| Glowbal IP Protocol | AAID | encoding additional information |
| GS1 | GS1 identification keys | random data encoding additional information |
| SWE | Sensor UID | encoding additional information |
| IoT@Work | Name of a node within a namespace |
hierarchy identifier encoding additional information |
| NDN | Name of the data | hierarchy identifier encoding additional information cryptographic operations |
| MobilityFirst | GUID | encoding additional information cryptographic operations |
Future Internet Architecture (FIA) is a project funded by National Science Foundation (NSF) aiming to build up a secure and highly dependable information technology infrastructure for the future Internet. Among the five projects in FIA, Named Data Networking (NDN) and MobilityFirst are the two trying to construct a new naming scheme which can be applied to IoT. Compared to the extensions and solutions based on traditional structure, NDN and MobilityFirst are taking a much more radical way as they are redesigning the fundamental structure of the Internet. Hopefully these changes will solve the major problems, mainly about mobility and security, in today’s Internet services for good. The details of these changes will be discussed in the following two sections.
The naming schemes are at the center of these changes for naming issue is closely related to how we view the object or the data in IoT. This is exactly what the changes are about. Traditional structure like TCP/IP’s host-centric and point to point communication model [Zhu13] is a big obstacle to completely solving the mobility issue. The construction of the new naming schemes doesn’t jump out of the box as Table 1 shows while the new naming schemes are paying more and more attention to security issues by involving cryptographic operations in the early stage of naming.
Being a future Internet architecture project, NDN aims to topple the TCP/IP communication paradigm and replace it with a content/data-centric network structure. A new naming scheme which are similar to URI is at the center of this trial. The name of the data will perform several key functions such as routing, securing and content delivery. High expectation is paralleled by big challenges.
Named Data Networking (NDN) follows the idea of Content-Centric Network first proposed by Van Jacobson [Baid12]. Content distribution which is a significant function of today’s Internet is performed inefficient in the TCP/IP host-centric, point to point paradigm. During the process of getting a content of interest over the Internet, we need to know the location, i.e. IP address, before we can set up the connection. This leads to the translation service provided by DNS. To the users who are interested only in the content, these steps seems irrelevant.
In a content-centric network architecture as CCN and NDN are developing, in order to retrieve the content they want, all they need to do is to send interest with name. The web server listening to an incoming interest with certain name prefix will create and send back the data packet directly based on the name of the content [Burke12]. In other words, the name of the content or the data will replace IP in the future Internet and act as the universal component in Internet protocol stack [Zhang11]. The Hourglass architecture which is the principle of the design is showed in figure 3.
The form of the name is similar to URI. [Jacobson13] illustrated an example:
/UCLA/video/demo.mpg/1/3
This name could represent segment 3 of version 1 of the video demo.mpg which is stored in the server at UCLA.
It is a hierarchically structured name as the architecture has designed. Flat names are also allowed in the NDN when the data is local. But the routing function of name of the date and the scale of the future NDN routing system make flat name useless in most cases. The routing system knows the boundary in a name, i.e. “/”, while it doesn’t interpret meaning of the name. Consequently choice of the name is up to the corresponding application. One scenario will be considered very normal in IoT. That is data is generated in real time and the client doesn’t have the specific knowledge of how the data is named. Right now these kind of knowledge are manually propagated via major websites, social network or email. In NDN, this needs to be done in an automated way. There are two way to achieve goal: designing an deterministic algorithm that enables both sides have the same result or letting the client put more parameters of the data which are called interest selectors in NDN in the interest sent to the server. The first way will be an important component of the naming scheme because the algorithm will decide how the name is constructed.
The world-wide service provided by NDN demands that the name should be unique globally while uniqueness eliminates certain names that can be very useful within a specific scope. A new name space management strategy is wanted.
What IP is doing in today’s Internet is what name is expected to do in NDN architecture. The fact locating and routing depends on the naming of the data means the choice of the name would affect many aspects of the operation of the Internet. Scalable routing, network delivery and application development will be improved if a proper naming mechanism is introduced. Especially the scalable routing issue will be a big challenge for NDN in future IoT. Since NDN directly routes data packets on the name and IoT will have billions of objects needs to be named, the routing table will grow to a size no commercial router can support if the naming scheme fails to constrain the complexity of the name structure.
Security, another top issue, is associated with the naming scheme. On a data-centric network, the best way to secure the content is to tie a key to the name of the data and the key is signed into the data when the data is going to be transmitted [Zhang11]. Compared to securing the communication channel in the TCP/IP paradigm, the new way directly encrypts the data. This will significantly improve the quality of service in the whole network because the less components are involved, the less chance integrity of the data is compromised.
NDN has been proved to be much more efficient in content distribution [Yuan13] and be feasible in the context of IoT [Burke12]. Nonetheless, if NDN wants to be the basic architecture of the future Internet, more solutions including a comprehensive naming scheme are needed.
Another strong candidate of future Internet architecture is MobilityFirst. The key idea of it is separating the name from network address to achieve much greater mobility performance. Global unique identification (GUID) and other related mechanisms are introduced to provide basic MobilityFirst services. The comparison between NDN and MobilityFirst offers an interesting perspective.
MobilityFirst is another future Internet architecture project funded by NSF. From its name we literally know that it is mainly focused on mobility issue. Mobility has always been referred to the biggest problem of IP structure even before the idea of IoT. Any other IP based solution can not totally get rid of it. The most prominent innovation in MobilityFirst is the separation of naming and addressing [2Li12]. The naming scheme adopted is a global unique identification (GUID). What makes it different from URI is that it is detached with its location, i.e. IP address for URI.
This idea is not new. Locator/Identifier Separation Protocol (LISP) developed by Internet Engineering Task Force (IETF) applied this paradigm to deal with the mobility issue in the existing IP network. But what MobilityFirst proposed is supporting it at network layer which demands a complete redesign of the network architecture.
In the architecture of MobilityFirst, despite the GUID and network address is separated from each other, the network still maintains the mapping between the two. MobilityFirst implements two routing scheme, GUID and network address based, in the same time which make the network much more flexible. Consequently four basic network services should be available in MobilityFirst: 1.Global Name Resolution Service, 2.Hybrid GUID/network address routing, 3.Delay-tolerant network (DTN) transport and 4.Name Assignment Service (NAS) [1Li12]. Among them, the last service are directly linked to the generation and management of GUID. The details of GUID and NAS will be discussed in the next subsection.
The owner’s public key and a sequence number coming from the hashing of certain attribute, such as MAC address or URI of the content is the two parts of a GUID. The structure is showed in figure 4 below. The fact that the structure is simple while inherent secure is highly desirable in IoT context.
The uniqueness of GUID is achieved by the unique public key assigned by the NAS which will map the a description of the content, typically in the form of a string, to a unique GUID. By choosing a NAS for his/her network object, the owner can publish new resources on the Internet. People who want to retrieve this object will only have to simply look up the corresponding GUID in NAS and then the object is accessible. Since the public key and hashing of the private information is combined together when the GUID is created, the security is done by the naming scheme just like NDN.
Muti-homing is another feature of GUID in MobilityFirst because the same content could be in several different places on the Internet simultaneously. For example, an electronic book could be available in multiple libraries. In this scenario, a GUID will be tied to all the network addresses it is in. The point to multipoint mapping is done by Global Name Resolution Service which is also a basic service provided by MobilityFirst.
Instead of implementing routing mechanism only depends on name which is the case in NDN, MobilityFirst retains the network address routing along with the GUID based routing. Indeed this will increase the complexity of the routing mechanism. But the usage of traditional routing technique will bring advantages which will neutralize or even exceed the negative effects since IP routing has been proved pretty effective.
The hybrid routing method will not degrade the role of GUID in the whole picture. The safeguard built in the GUID is one of the most crucial improvement of MobilityFirst. And more importantly, supporting mobility is the key concept of the entire structure. The separation and the mapping between GUID and its one or multiple network addresses give the named object an outstanding mobility with limited overhead. When the object moves to a new location, all it needs to do is to update its GUID to network address mapping in Global Name Resolution Service and then the traffic will seamlessly goes to the new location. This results in a much more better performance in mobility context [Baid12]. MobilityFirst looks promising in future IoT as mobility will be critical to almost every IoT services. But same as NDN, MobilityFirst needs more comprehensive solutions to cope with all kinds of challenges proposed by IoT.
Being the counterparts in the future Internet architecture project, NDN and MobilityFirst have some features in common while having more fundamental differences. The naming schemes are both key component in each architecture. The comparison between the two will give us a clear big picture of development of the naming scheme in the future Internet architecture. Table 2 lists the common points, advantages and disadvantages of the two naming schemes. All the content in the table has been discussed in previous sections.
| Name of the data/NDN | GUID/MobilityFirst | |
|---|---|---|
| common points | 1.Built in security mechanism 2.Detached from network address 3.Automated content distribution 4. Need a total redesign of Internet infrastructure |
|
| advantages | 1.Simpler routing mechanism only depends on name 2. Much more Efficient content distribution |
1.Exploiting the effective traditional network address routing technique 2. Much less mobility overhead |
| disadvantages | Scalability of the routing table | More complex routing rules |
In this paper, we discussed the solutions based on the existing architecture. But those solutions, like 6LoWPAN and AAID, still face some inherent issues. More extensions and modifications are needed to bring some fundamental changes to the IP architecture. Some other solutions such as GS1 identification key perform very well in certain areas and can be very efficient doing specific tasks. They may not be able to be implemented in the scope of the entire Internet, but they should be considered to be integrated into future IoT basic structure.
Since some challenges brought by IoT are very hard to deal with within tradition paradigm, new naming schemes along with future Internet architecture is proposed. The methods used to construct them is already there. By introducing some radical idea, projects like NDN and MobilityFirst are able to offer some innovative solutions which will topple the existing Internet structure while get rid of some IoT issues for good. However these solutions still have a long way to go. They need much more comprehensive mechanism and techniques in order to compete with IP architecture in future IoT. In one word, the door is open and everyone has a chance.
*The references are listed by the importance.
| Acronym | Definition |
|---|---|
| 6LoWPAN | IPv6 over Low power Wireless Personal Area Networks |
| AAID | Access Address/Identifier |
| CCN | Content-Centric Network |
| DNS | Domain Name System |
| ENS | Event Notification Service |
| FIA | Future Internet Architecture |
| GUID | Global unique identification |
| IEEE | Institute of Electrical and Electronics Engineers |
| IoT | Internet of Things |
| NAS | Name Assignment Service |
| NDN | Named Data Networking |
| NSF | National Science Foundation |
| ONS | Object Name Service |
| RFID | radio-frequency identification |
| SensorML | Sensor Model Language |
| SWE | Sensor Web Enablement |
| XML | Extensible Markup Language |