Named Data Networking : A realization of information centric networking - ECE-180D-WS-2023/Knowledge-Base-Wiki GitHub Wiki

The Internet is no doubt one of the greatest technological inventions by mankind. At the heart of its hourglass shaped architecture is a simple, versatile, and elegant network layer implementation, the Internet Protocol, more famously known as IP. Since the Internet’s invention more than 50 years ago, much innovation has been made on the transport and application layer, while IP has stayed the same. It is the key of the Internet’s success, but it is also the root cause of many problems.

From Naming Entities To Naming Packets

IP’s most important design concept is Packet Switching: as long as the two end entities in the network have been identified, data sent by either party can be encapsulated into packets that route to the other. Under such a design, the “client-server” model is naturally developed: a central content distributor handles requests from multiple clients. However, with the development of decentralized technologies such as the blockchain, and with the growing demand in distributed applications such as social-networking, a centralized “client-server” model is becoming less desirable. Information Centric Networking (ICN) is thus proposed. Instead of identifying the end entities, ICN suggests identifying each data packet, while entities simply ask for that specific named data.

Named Data Networking

Named Data Networking is an implementation of ICN. On the high level, when an entity needs a specific chunk of data from the network, it broadcasts its need in a interest packet. Whichever entity in the network that is able to satisfy the need will send the data back. This seemingly straightforward workflow actually has many details that need to explained.

First, there are two main types of packets, an interest packet and a data packet. Whenever an entity requests some data, it broadcasts an interest packet to the network. Receivers of the interest packet then generate data packets that contain requested content if they can satisfy the request. An interest packet has four fields: 1. Its name, which not only identifies the packet itself, but also contains information about the requester and the requested data; 2. A selector, which enables the requester to filter out unwanted or malicious data; 3. A Nonce, a randomly generated byte string that is used to identify packets; 4. Guiders, which contains information such as the interest’s lifetime. A data packet has four fields as well: 1. Its name, which has similar functions as an interest packet’s; 2. Meta info; 3. Signed info, which encrypts the data and contains important information for the packet receiver to verify the security related facts of the data; 4. The data itself. (NDN, 2021)

The name of either packet is no doubt the most essential part of it, and the process of creating such a name by an entity is called Naming. Naming are performed by applications, and the final name is transparent to the network layer. Names can vary a lot depending on the usage of the packet, for instance, the names below specifies a video segment and a certification revocation record respectively (Tianyuan, 2022).

Now the data packets are well defined, how to route them in the network so that entities can “communicate” is the next question. A straightforward algorithm determines the behavior of a common entity. First, if an entity receives an interest packet, meaning that another entity in the network is looking for a specific data packet, it has to ask itself two questions and act accordingly. 1. Do “I” have the data requested in the local Content Store. If yes, then the entity generates a data packet, sends it back to the requester, and no further action is needed, otherwise it adds the interest to a Pending Interest Table (PIT) to keep record of this unsatisfied interest. 2. If “I” cannot satisfy the request, can I forward the interest packet. The entity checks its Forwarding Information Base (FIB) table. If there there is a match, it forwards the interest table to the next entity as listed in FIB, otherwise it drops the interest packet. On the other hand, if an entity receives a data packet, it first checks its PIT to determine whether this data packet satisfies one of the previously recorded interests. If the packet does, then the entity forwards the packet back to the requester and adds the data to its local Content Storage to cache it. However, if there is no matching interest in the PIT, the entity simply drops the data packet. (NDN, 2021)

Try to imagine tens or even thousands of such entities inter-connected in a network, where each of them act accordingly to the above algorithm. Interest packets are be distributed to the data provider, and data packets back-trace the incoming path and be routed back to the requester. This design is not possible in the early days when the Internet was just invented due to a lack of clients and computation power. However, nowadays, with the exponentially growing number of connected nodes and the skyrocketed computation power of each node, NDN is making ICN more feasible than ever before.

Limitations Of NDN

Theoretically, NDN is more efficient than IP due to its decentralized nature. However, no publications has provided any quantitative analysis showing that NDN has either a lower latency or a higher throughput. The reason is that NDN is at a rudimentary stage. Basic security features such as distributing and revoking certifications were first introduced to NDN just months ago. Performance optimization always comes after feature completion, and the current status of NDN is still far from the latter.

How Can We Use NDN?

Although NDN is still rudimentary, nothing stops us from taking a glance at this next-generation network. NDN has its own GitHub repo, which contains all the components needed to build a local small NDN network, and it can be accessed from: https://github.com/named-data/ndn-cxx. This is a complete C++ implementation, while there is also a python NDN client implementation: https://github.com/named-data/python-ndn. Since building the application layer from scratch may not be desirable for most users, there are also many pre-constructed frameworks that can be easily integrated into the applications. For instance, NDNoT is an IoT framework that “aims to create an open environment where IoT applications and different services can easily cooperate and work together” (Zhiyi, 2021). (https://github.com/named-data-iot) It can run on the RIOT operating system and on Arduino compatible hardware, and it has been tested on Expressif ESP32 boards.

In Conclusion

It has been nearly 10 years since Named Data Networking was first proposed in 2014 as an implementation of Information Centric Networking to replace Internet Protocol. Throughout the years, major design choices were made and countless features were added. We can see that the community of NDN is growing, and more and more brilliant ideas are implemented with NDN. Although it is impossible to predict whether NDN will actually replace IP in the future, NDN has already shown us a brand new possibility of networking.

References

  1. Tianyuan Yu, Hongcheng Xie, Siqi Liu, Xinyu Ma, Xiaohua Jia, and Lixia Zhang. 2022. CertRevoke: a certificate revocation framework for named data networking. In Proceedings of the 9th ACM Conference on Information-Centric Networking (ICN '22). Association for Computing Machinery, New York, NY, USA, 80–90. https://doi.org/10.1145/3517212.3558079
  2. Zhiyi Zhang, Edward Lu, Yanbiao Li, Lixia Zhang, Tianyuan Yu, Davide Pesavento, Junxiao Shi, and Lotfi Benmohamed. 2018. NDNoT: a framework for named data network of things. In Proceedings of the 5th ACM Conference on Information-Centric Networking (ICN '18). Association for Computing Machinery, New York, NY, USA, 200–201. https://doi.org/10.1145/3267955.3269019
  3. Named data networking: Motivation & details. Named Data Networking (NDN). (2021, July 22). Retrieved February 2, 2023, from https://named-data.net/project/archoverview/