the Internet is still a host centric network today. We use URLs and need DNS to resolve each URL to the IP address of the host where the desired web object is located to access the object.
It should also be possible to enter in a browser only the name of the desired object to access it. On which host the object is, we are not interested. That means, we think according to the principle "Information Centric". The first known step in the direction of "Information/Name Centric Networking" is already realized with the help of DOIs (Digital Object Identifier). To get an article, we only need its DOI. From which server (host) we finally download the article, this is meaningless for us. The DOI of the desired article must be resolved to the location of the server with this article. Of great importance here is "DOI Resolver".
How a resolver works, I would like to show an example. At the end of the 90s, when VoIP "came", a special resolver was needed to use classic telephone numbers (as addresses of telephones) on the Internet. For this
purpose, the concept ENUM (E.164 NUmber Mapping or tElephone NUmber Mapping) was introduced and already specified in 2000 in RFC 2916. With ENUM Resolvers the telephone numbers can be resolved to the location (IP addresses) of telephones. The telephone numbers can be regarded as identifiers of the telephones.
The idea of the ENUM resolver can be applied in the IoT. In the IoT, the objects (devices, sensors, ...) are assigned the unique identifiers or the user-friendly names. The names can also be structured. The identifiers / names of objects can be resolved to their location in the IoT using resolvers. The idea for these resolvers can be derived from the ENUM Reselver shown here.
A resolver is based on a virtual tree structure. The leaves of such a virtual tree in the IoT can contain:
the IPv6 addresses of objects and possibly their attributes (e.g., priority) if the objects are stationary (not mobile).
The IP addresses of special proxies with current addresses of objects when the objects are mobile.
My other two figures are just examples of how the names can be structured. The structuring of identifiers/names is very important in the IoT: for example, to design smart city citizen services.
Further help can be found in the literature that I have added. These sources only refer to the use of the ICN idea in the IoT. The entire ICN theme is very extensive and a variety of articles have already been dedicated to this topic. The ICN-related ideas are already protected in over 50 patents.
A big ICN topic in IoT is the Vehicular Named Data Networking (VNDN). On this topic VNDN you can find some articles. For the realization of the VNDN some ideas can be taken over from the LoST (Location-to-Service Translation).
Best regards
Anatol badach
Named data networking for IoT: An architectural Perspective
the Internet is still a host centric network today. We use URLs and need DNS to resolve each URL to the IP address of the host where the desired web object is located to access the object.
It should also be possible to enter in a browser only the name of the desired object to access it. On which host the object is, we are not interested. That means, we think according to the principle "Information Centric". The first known step in the direction of "Information/Name Centric Networking" is already realized with the help of DOIs (Digital Object Identifier). To get an article, we only need its DOI. From which server (host) we finally download the article, this is meaningless for us. The DOI of the desired article must be resolved to the location of the server with this article. Of great importance here is "DOI Resolver".
How a resolver works, I would like to show an example. At the end of the 90s, when VoIP "came", a special resolver was needed to use classic telephone numbers (as addresses of telephones) on the Internet. For this
purpose, the concept ENUM (E.164 NUmber Mapping or tElephone NUmber Mapping) was introduced and already specified in 2000 in RFC 2916. With ENUM Resolvers the telephone numbers can be resolved to the location (IP addresses) of telephones. The telephone numbers can be regarded as identifiers of the telephones.
The idea of the ENUM resolver can be applied in the IoT. In the IoT, the objects (devices, sensors, ...) are assigned the unique identifiers or the user-friendly names. The names can also be structured. The identifiers / names of objects can be resolved to their location in the IoT using resolvers. The idea for these resolvers can be derived from the ENUM Reselver shown here.
A resolver is based on a virtual tree structure. The leaves of such a virtual tree in the IoT can contain:
the IPv6 addresses of objects and possibly their attributes (e.g., priority) if the objects are stationary (not mobile).
The IP addresses of special proxies with current addresses of objects when the objects are mobile.
My other two figures are just examples of how the names can be structured. The structuring of identifiers/names is very important in the IoT: for example, to design smart city citizen services.
Further help can be found in the literature that I have added. These sources only refer to the use of the ICN idea in the IoT. The entire ICN theme is very extensive and a variety of articles have already been dedicated to this topic. The ICN-related ideas are already protected in over 50 patents.
A big ICN topic in IoT is the Vehicular Named Data Networking (VNDN). On this topic VNDN you can find some articles. For the realization of the VNDN some ideas can be taken over from the LoST (Location-to-Service Translation).
Best regards
Anatol badach
Named data networking for IoT: An architectural Perspective
There are several projects that are actively working on ICN topics. Several key projects in the United States (CCN/NDN , and previously DONA ) and Europe (4WARD /SAIL, PSIRP/PURSUIT, COMET], and CONNECT, which adopts the CCN model) have been working on redesigning core network primitives to enable an information-centric network architecture.
It is impotent to follow up with these running on projects to check what they have done on ICN.
I hope that this feature topic will act as a catalyst, stimulating further research and exploration of commercial applications in this exciting new area.