Named data networking

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Named Data Networking (NDN) (related to Content-Centric Networking (CCN), content-based networking, data-oriented networking or information-centric networking) is a 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.[1][2] 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 belief is that this conceptually simple shift will have far-reaching implications for how people design, develop, deploy, and use networks and applications.[3]

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 (a "high 90% level of traffic") consists of data being disseminated from a source to a number of users.[4] 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.

Background

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.[5] 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.

File:NDN Architecture Stack.png
The main building blocks of the NDN architecture are named content chunks, in contrast to the IP architecture's fundamental unit of communication, which is an end-to-end channel between two end endpoints identified by IP addresses.

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 broader range of problems beyond end-to-end communications.[6] Examples of NDN applying lessons learned from 30 years of networking engineering are that self-regulation of network traffic (via flow balance between Interest 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, 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 (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.[7] 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, and growing interest from the academic and industrial research communities.[8][9] There exists a large body of research and an actively growing code base. contributed to NDN.

Key Architectural Principles

  • End-to-end principle: Enables 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.[10]
  • 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".[11] 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.

File:NDN Packets.png
Overview of the Packet Contents for NDN Packet
  • 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: (Figure 3)

  • 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 Internet, 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 Strategy module: a series of policies and rules about forwarding 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. For each Interest, the Forwarding Strategy retrieves the longest-prefix matched entry from the FIB, and decides when and where to forward the Interest.

When an Interest packet arrives, an NDN router first checks the Content Store for matching data; if it exists 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.

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 (not to be confused with symmetric routing, or with routing at all!), 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:

  • Relationship specification: allows applications to represent the context and relationships of data elements. EX: segment 3 of version 1 of a UCLA demo video might be named /ucla/videos/demo.mpg/1/3.
  • Name aggregation: /ucla could correspond to an autonomous system originating the video
  • Routing: allows the system to scale and aids in providing necessary context for the data

Specifying a Name

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:

  • an algorithm allows the producer and consumer to arrive at the same name based on information available to both
  • Interest selectors in conjunction with longest prefix matching retrieve the desired data through one or more iterations.

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.[12]

Namespaces

Data that may be retrieved globally must have globally unique names, but names used for local communications may require only local routing (or local broadcast) 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:

  • increasing the closeness of mapping between an application’s data and its use of the network
  • reducing the need for secondary notation (record-keeping to map application configuration to network configuration)
  • expanding the range of abstractions available to the developers.

Routing

Solutions to IP Issues

NDN routes and forwards packets based on names, which eliminates three problems caused by addresses in the IP architecture:

  • address space exhaustion: NDN namespace is unbounded
  • NAT traversal: NDN does away with addresses, public or private, so NAT is unnecessary
  • address management: address assignment and management is no longer required in local networks.

Protocols

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.

PIT State

The PIT state at each router supports forwarding across NDN’s data plane, recording each pending Interest and the incoming interface(s), 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:

  • control flow: since each Interest retrieves at most one Data packet, a router can directly control flow by controlling the number of pending interests it keeps.
  • multicast data delivery: the PIT recording the set of interface on which the same data has arrive, naturally supports this feature.
  • Updating paths to accommodate changes in their view of the network.[13]
  • Delivery: a router can reason about which Interests to forward to which interfaces, how many unsatisfied Interests to allow in the PIT, as well as the relative priority of different Interests.

Interest

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(s) that transmitted the Interest. Such a Negative Acknowledgment (NACK) 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, which leaves responsibility for security (or lack thereof) to the endpoints, NDN secures the data itself by requiring data producers to cryptographically sign every Data packet. The publisher’s signature ensures integrity and enables determination 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 2 different types of trust models:

  • hierarchical trust model: where a key namespace authorizes use of keys. A data packet carrying a public key is effectively a certificate, since it is signed by a third party, and this public key is used to sign specific data[14]
  • web of trust: to enable secure communication without requiring pre-agreed trust anchors.[15]

Application Security

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 (closer to root) 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 (BMS)[16] 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,[17] 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 (SDSI) [13, 3], 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 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.[18] 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.,[19] [20] 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:[21]

  • Load Balancing: the number of PIT entries is an indicator of router load; constraining its size limits the effect of a DDoS attack.
  • Interest timeout: PIT entry timeouts offer relatively cheap attack detection, and the arrival interface information in each PIT entry could support a push-back scheme in which down stream routers are informed of unserved interests, which aides in detecting attacks.

See also

Further reading

References

  1. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  2. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  3. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  4. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  5. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  6. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  7. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  8. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  9. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  10. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  11. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  12. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  13. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  14. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  15. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  16. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  17. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  18. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  19. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  20. ↑ Lua error in package.lua at line 80: module 'strict' not found.
  21. ↑ Lua error in package.lua at line 80: module 'strict' not found.
Retrieved from "https://infogalactic.com/w/index.php?title=Named_data_networking&oldid=704652399"