Named data networking


Named data networking , content-based networking, data-oriented networking or information-centric networking ) is a proposed Future Internet architecture inspired by years of empirical research into network usage and a growing awareness of unsolved problems in contemporary internet architectures like IP. NDN has its roots in an earlier project, Content-Centric Networking, 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. The belief is that this conceptually simple shift will have far-reaching implications for how people design, develop, deploy, and use networks and applications.
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 request desired data by its name, so communications in NDN are consumer-driven. Second, NDN communications are secured in a data-centric manner, that is, each piece of data 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 and erase the state when a corresponding Data packet comes back; NDN's stateful forwarding allows intelligent forwarding strategies and eliminates loop.
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 he or she needs, 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 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, 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 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 and security primitives 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 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 project at UC Berkeley and ICSI proposed a content-centric network architecture, which improved TRIAD by incorporating security and persistence as first-class primitives in the architecture. Van Jacobson gave a Google Talk, , 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, at the time a research fellow at PARC. On September 21, 2009, PARC published the specifications for interoperability and released an initial open source implementation of the Content-Centric Networking research project on the . NDN is one instance of a more general network research direction called information-centric networking, under which different architecture designs have emerged. The Internet Research Task Force established an ICN research working group in 2012.

Current state

NDN includes sixteen NSF-funded principal investigators at twelve campuses, and growing interest from the academic and industrial research communities. More than 30 institutions form a global . There exists a large body of and an actively growing contributed to NDN.
The is currently supported on Ubuntu 16.04 and 18.04, Fedora 20+, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+, and several other platforms. are actively supported for C++, Java, Javascript, Python,.NET Framework, and Squirrel programming languages. The 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 and 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

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
For the complete specification see .

Router architecture

To carry out the Interest and Data packet forwarding functions, each NDN router maintains three data structures, and a forwarding policy:
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 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.
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.
Neither Interest nor Data packets carry any host or interface addresses; routers forward Interest packets toward data producers based on the names carried in the packets, and forward Data packets to consumers based on the PIT state information set up by the Interests at each hop. This Interest/Data packet exchange symmetry induces a hop-by-hop control loop, and eliminates the need for any notion of source or destination nodes in data delivery, unlike in IP's end-to-end packet delivery model.

Names

Design

NDN names are opaque to the network. This allows each application to choose the naming scheme that fits its needs, and naming can thus evolve independently from the network.

Structure

The NDN design assumes hierarchically structured names, e.g., a video produced by UCLA may have the name /ucla/videos/demo.mpg, where ‘/’ delineates name components in text representations, similar to URLs. This hierarchical structure has many potential benefits:
To retrieve dynamically generated data, consumers must be able to deterministically construct the name for a desired piece of data without having previously seen the name or the data through either:
Current research is exploring how applications should choose names that can facilitate both application development and network delivery. The aim of this work is to develop and refine existing principles and guidelines for naming, converting these rules into naming conventions implemented in system libraries to simplify future application development.

Namespaces

Data that may be retrieved globally must have globally unique names, but names used for local communications may require only local routing to find matching data. Individual data names can be meaningful in various scopes and contexts, ranging from “the light switch in this room” to “all country names in the world”.
Namespace management is not part of the NDN architecture, just as address space management is not part of the IP architecture. However naming is the most important part of NDN application designs.
Enabling application developers, and sometimes users, to design their own namespaces for data exchange has several benefits:

Solutions to IP issues

NDN routes and forwards packets based on names, which eliminates three problems caused by addresses in the IP architecture:
NDN can use conventional routing algorithms such as link state and distance vector. Instead of announcing IP prefixes, an NDN router announces name prefixes that cover the data the router is willing to serve. Conventional routing protocols, such as OSPF and BGP, can be adapted to route on name prefixes by treating names as a sequence of opaque components and doing component-wise longest prefix match of a name in an Interest packet against the FIB table. This enables a wide array of inputs to be aggregated in real time and distributed across multiple interface environments simultaneously without compromising content encryption. Key interface analytics are likewise spared by the process. Application transfer and data sharing within the environment are defined by a multimodal distribution framework, such that the affected cloud relay protocols are unique to the individual runtime identifier.

PIT state

The PIT state at each router supports forwarding across NDN's data plane, recording each pending Interest and the incoming interface, and removing the Interest after the matching Data is received or a timeout occurs. This per hop, per packet state differs from IP's stateless data plane. Based on information in the FIB and performance measurements, an adaptive forwarding strategy module in each router makes informed decisions about:
If a router decides that the Interest cannot be satisfied, e.g., the upstream link is down, there is no forwarding entry in the FIB, or extreme congestion occurs, the router can send a NACK to its downstream neighbor that transmitted the Interest. Such a Negative Acknowledgment may trigger the receiving router to forward the Interest to other interfaces to explore alternate paths. The PIT state enables routers to identify and discard looping packets, allowing them to freely use multiple paths toward the same data producer. Packets cannot loop in NDN, which means there is no need for time-to-live and other measures implemented in IP and related protocols to address these issues.

Security

Overview

In contrast to TCP/IP security which secures communication by securing IP-to-IP channels, NDN secures the data itself by requiring data producers to cryptographically sign every Data packet. The publisher's signature ensures the integrity and enables authentication of data provenance, allowing a consumer's trust in data to be decoupled from how or where it is obtained. NDN also supports fine-grained trust, allowing consumers to reason about whether a public key owner is an acceptable publisher for a specific piece of data in a specific context. The second primary research thrust is designing and developing usable mechanisms to manage user trust. There has been research into 3 different types of trust models:
NDN's data-centric security has natural applications to content access control and infrastructure security. Applications can encrypt data and distribute keys as named packets using the same named infrastructure to distribute keys, effectively limiting the data security perimeter to the context of a single application.
To verify a data packet's signature, an application can fetch the appropriate key, identified in the packet's key locator field, just like any other content. But trust management, i.e., how to determine the authenticity of a given key for a particular packet in a given application, is a primary research challenge. Consistent with an experimental approach, NDN trust management research is driven by application development and use: solving specific problems first and then identifying common patterns.
For example, the security needs of NLSR required development of a simple hierarchical trust model, with keys at lower levels, being used to sign keys in higher levels in which keys are published with names that reflect their trust relationship. In this trust model, the namespace matches the hierarchy of trust delegation, i.e., /root/site/operator/ router/process. Publishing keys with a particular name in the hierarchy authorizes them to sign specific data packets and limits their scope. This paradigm can be easily extended to Other applications where real world trust tends to follow a hierarchical pattern, such as in our building management systems
Since NDN leaves the trust model under the control of each application, more flexible and expressive trust relations, may also be expressed. One such example is ChronoChat, which motivated experimentation with a web-of-trust model. The security model is that a current chatroom participant can introduce a newcomer to others by signing the newcomer's key. Future applications will implement a cross-certifying model , which provides more redundancy of verification, allowing data and key names to be independent, which more easily accommodates a variety of real-world trust relationships.

Routing efficiency and security

Furthermore, NDN treats network routing and control messages like all NDN data, requiring signatures. This provides a solid foundation for securing routing protocols against attack, e.g., spoofing and tampering. NDN's use of multipath forwarding, together with the adaptive forwarding strategy module, mitigates prefix hijacking because routers can detect anomalies caused by hijacks and retrieve data through alternate paths. Owing to multi-source, multicast content-delivery nature of Named Data Networking, the random linear coding can improve over all network efficiency. Since NDN packets reference content rather than devices, it is trickier to maliciously target a particular device, although mitigation mechanisms will be needed against other NDN-specific attacks, e.g., Interest flooding DoS.,
Furthermore, having a Pending Interest Table, which keeps state regarding past requests, which can make informed forward decisions about how to handle interest has numerous security advantages: