Named Data Networking (NDN) (related to content-centric networking (CCN), content-based networking, data-oriented networking or information-centric networking (ICN)) is a proposed Future Internet architecture that seeks to address problems in contemporary internet architectures like IP. NDN has its roots in an earlier project, Content-Centric Networking (CCN), which Van Jacobson first publicly presented in 2006. The NDN project is investigating Jacobson's proposed evolution from today's host-centric network architecture IP to a data-centric network architecture (NDN). The stated goal of this project is that with a conceptually simple shift, far-reaching implications for how people design, develop, deploy, and use networks and applications could be realized.
NDN has three core concepts that distinguish NDN from other network architectures. First, applications name data and data names will directly be used in network packet forwarding; consumer applications would request desired data by its name, so communications in NDN are consumer-driven. Second, NDN communications are secured in a data-centric manner wherein each piece of data (called a Data packet) will be cryptographically signed by its producer and sensitive payload or name components can also be encrypted for the purpose of privacy. In this way, consumers can verify the packet regardless of how the packet is fetched. Third, NDN adopts a stateful forwarding plane where forwarders will keep a state for each data request (called an Interest packet), and erase the state when a corresponding data packet comes back. NDN's stateful forwarding allows intelligent forwarding strategies, and eliminates loops.
Its premise is that the Internet is primarily used as an information distribution network, which is not a good match for IP, and that the future Internet's "thin waist" should be based on named data rather than numerically addressed hosts. The underlying principle is that a communication network should allow a user to focus on the data they need, named content, rather than having to reference a specific, physical location where that data is to be retrieved from, named hosts. The motivation for this is derived from the fact that the vast majority of current Internet usage (a "high 90% level of traffic") consists of data being disseminated from a source to a number of users. Named-data networking comes with potential for a wide range of benefits such as content caching to reduce congestion and improve delivery speed, simpler configuration of network devices, and building security into the network at the data level.
Overview Today's Internet's hourglass architecture centers on a universal network layer, IP, which implements the minimal functionality necessary for global inter-connectivity. The contemporary Internet architecture revolves around a host-based conversation model, which was created in the 1970s to allow geographically distributed users to use a few big, immobile computers. This thin waist enabled the Internet's explosive growth by allowing both lower and upper layer technologies to innovate independently. However, IP was designed to create a communication network, where packets named only communication endpoints.
Sustained growth in e-commerce, digital media, social networking, and smartphone applications has led to dominant use of the Internet as a distribution network. Distribution networks are more general than communication networks, and solving distribution problems via a point-to-point communication protocol is complex and error-prone.
The Named Data Networking (NDN) project proposed an evolution of the IP architecture that generalizes the role of this thin waist, such that packets can name objects other than communication endpoints. More specifically, NDN changes the semantics of network service from delivering the packet to a given destination address to fetching data identified by a given name. The name in an NDN packet can name anything – an endpoint, a data chunk in a movie or a book, a command to turn on some lights, etc. The hope is that this conceptually simple change allows NDN networks to apply almost all of the Internet's well-tested engineering properties to a broader range of problems beyond end-to-end communications. Examples of NDN applying lessons learned from 30 years of networking engineering are that self-regulation of network traffic (via flow balance between Interest (data request) and data packets), and security primitives (via signatures on all named data) are integrated into the protocol from the start.
History
Early research The philosophy behind NDN was pioneered by Ted Nelson in 1979, and later by Brent Baccala in 2002. In 1999, the TRIAD project at Stanford proposed avoiding DNS lookups by using the name of an object to route towards a close replica of it. In 2006, the Data-Oriented Network Architecture (DONA) project at UC Berkeley and ICSI proposed a content-centric network architecture, which improved TRIAD by incorporating security (authenticity) and persistence as first-class primitives in the architecture. Van Jacobson gave a Google Talk, A New Way to Look at Networking, in 2006 on the evolution of the network, and argued that NDN was the next step. In 2009, PARC announced their content-centric architecture within the CCNx project, which was led by Jacobson who was a research fellow at PARC at the time. On 21 September 2009, PARC published the specifications for interoperability and released an initial open source implementation (under GPL) of the Content-Centric Networking research project on the Project CCNx site. NDN is one instance of a more general network research direction called information-centric networking (ICN), under which different architecture designs have emerged. The Internet Research Task Force (IRTF) established an ICN research working group in 2012.
Current state NDN includes sixteen NSF-funded principal investigators at twelve campuses, with participation from the academic and industrial research communities. More than 30 institutions form a global testbed. There is a body of research and a code base. contributed to NDN.
The NDN forwarder is currently supported on Ubuntu 18.04 and 20.04, Fedora 20+, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+, and several other platforms. Common client libraries are actively supported for C++, Java, JavaScript, Python, .NET Framework (C#), and Squirrel programming languages. The NDN-LITE is a lightweight NDN library designed for IoT networks and constrained devices. NDN-LITE is being actively developed and so far, NDN-LITE has been adapted to POSIX, RIOT OS, NRF boards. An NDN simulator and emulator are also available and actively developed. Several client applications are being developed in the areas of real-time conferencing, NDN friendly file systems, chat, file sharing, and IoT.
Key architectural principles End-to-end principle: Enables the development of robust applications in the face of network failures. NDN retains and expands this design principle. Routing and forwarding plane separation: This has proven necessary for Internet development. It allows the forwarding plane to function while the routing system continues to evolve over time. NDN uses the same principle to allow the deployment of NDN with the best available forwarding technology while new routing system research is ongoing. Stateful forwarding: NDN routers keep the state of recently forwarded packets, which allows smart forwarding, loop detection, flow balance, ubiquitous caching, etc. Built-in security: In NDN, data transfer is secured at the network layer by signing and verification of any named data. Enable user choice and competition: The architecture should facilitate user choice and competition where possible. Although not a relevant factor in the original Internet design, global deployment has demonstrated that "architecture is not neutral". NDN makes a conscious effort to empower end users and enable competition.
Architecture overview
Types of packets Communication in NDN is driven by receivers i.e., data consumers, through the exchange of two types of packets: Interest and Data. Both types of packets carry a name that identifies a piece of data that can be transmitted in one Data packet. Packet types
Interest: A consumer puts the name of a desired piece of data into an Interest packet and sends it to the network. Routers use this name to forward the Interest toward the data producer(s). Data: Once the Interest reaches a node that has the requested data, the node will return a Data packet that contains both the name and the content, together with a signature by the producer's key which binds the two. This Data packet follows in reverse the path taken by the Interest to get back to the requesting consumer.
For the complete specification see NDN Packet Format Specification.
Router architecture To carry out the Interest and Data packet forwarding functions, each NDN router maintains three data structures, and a forwarding policy: Pending Interest Table (PIT): stores all the Interests that a router has forwarded but not satisfied yet. Each PIT entry records the data name carried in the Interest, together with its incoming and outgoing interface(s). Forwarding Information Base (FIB): a routing table which maps name components to interfaces. The FIB itself is populated by a name-prefix based routing protocol, and can have multiple output interfaces for each prefix. Content Store (CS): a temporary cache of Data packets the router has received. Because an NDN Data packet is meaningful independent of where it comes from or where it is forwarded, it can be cached to satisfy future Interests. Replacement strategy is traditionally least recently used, but the replacement strategy is determined by the router and may differ. Forwarding Strategies: a series of policies and rules about forwarding interest and data packets. Note that the Forwarding Strategy may decide to drop an Interest in certain situations, e.g., if all upstream links are congested or the Interest is suspected to be part of a DoS attack. These strategies use a series of triggers in the forwarding pipeline and are assigned to name prefixes. For instance, by default /localhost uses the Multicast forwarding strategy to forward interests and data to any local application running on a client NFD. The default forwarding strategy (i.e. "/") is the Best Route forwarding strategy.
When an Interest packet arrives, an NDN router first checks the Content Store for matching data; if it exists in the router returns the Data packet on the interface from which the Interest came. Otherwise the router looks up the name in its PIT, and if a matching entry exists, it simply records the incoming interface of this Interest in the PIT entry. In the absence of a matching PIT entry, the router will forward the Interest toward the data producer(s) based on information in the FIB as well as the router's adaptive Forwarding Strategy. When a router receives Interests for the same name from multiple downstream nodes, it forwards only the first one upstream toward the data producer(s).
When a Data packet arrives, an NDN router finds the matching PIT entry and forwards the data to all down-stream interfaces listed in that PIT entry. It then removes that PIT entry, and caches the Data in the Content Store. Data packets always take the reverse path of Interests, and, in the absence of packet losses, one Interest packet results in one Data packet on each link, providing flow balance. To fetch large content objects that comprise multiple packets, Interests provide a similar role in controlling traffic flow as TCP ACKs in today's Internet: a fine-grained feedback loop controlled by the consumer of the data.