Named Data Networking is a network protocol proposal for the replacement of TCP/IP.

First described in an IEEE paper in 1974, TCP/IP has grown to become the default network protocol for most networks and indeed the Internet.

Although work by the US National Science Foundation first started back in 2010, it was only in September 2014 that industry players like Cisco, Juniper, Intel, etc, sat down and formed a consortium to look to the future of the Internet as we know it.

Other links

http://named-data.net/

http://www.theregister.co.uk/2014/09/05/named_data_networking_consortium_launches_to_replace_tcp_ip/

================================================================

http://named-data.net/project/execsummary/

Named Data Networking: Executive Summary

The Internet’s hourglass architecture made its design elegant and powerful. The heart of this architecture is a simple, universal network layer (IP) which implemented all the functionality necessary for global interconnectivity. This “thin waist” was the key enabler of the Internet’s explosive growth but one of its design choices is the root cause of today’s Internet problems. The Internet was designed as a communication network so the only entities that could be named in its packets were communication endpoints [1]. Recent growth in e-commerce, digital media, social networking, and smartphone applications has resulted in the Internet primarily being used as a distribution network. Distribution networks are fundamentally more general than communication networks and solving distribution problems with a communications network is complex and error prone.

Internet and NDN Hourglass Architectures

NDN retains the Internet’s hourglass architecture but evolves the thin waist to allow the creation of completely general distribution networks. The core element of this evolution is removing the restriction that packets can only name communication endpoints. As far as the network is concerned, the name in an NDN packet can be anything — an endpoint, a chunk of movie or book, a command to turn on some lights, etc. This conceptually simple change allows NDN networks to use almost all of the Internet’s well understood and well tested engineering properties to efficiently solve not only communication problems but also digital distribution and control problems.

PARC’s CCN project demonstrated this architectural evolution was feasible. Using CCN as a starting point, the NDN project’s fundamental research challenge is to evolve it into architectural framework capable of solving real problems, particularly in application areas poorly served by today’s Internet. Solving real problems forces architectural details to be filled in and, most importantly, verifies and shapes the architectural direction. We believe that an architectural research effort should be fundamentally experimental in nature. Design specifics cannot be derived from an intellectual exercise nor can validation be done through greenhouse testbed demonstrations. The Internet design was matured via actual usage through early deployment and our research plan follows the Internet’s successful footsteps.

Intended Outcome

The NDN architecture design draws heavily on what we learned from the successes of today’s Internet. Similarly, our execution plan for realizing the new design closely follows the footsteps of the Internet’s successes.

As shown in the figure, the NDN architecture retains the same hourglass shape as the IP architecture, and the narrow waist is the centerpiece in this architecture. However the minimal functionality of NDN’s narrow waist, as we described in the architecture overview, is fundamentally different from IP’s. NDN’s minimal functionality includes support for consumer-driven data delivery, built-in data security, and use of in-network memory. The consumer-driven data delivery is realized through setting up packet forwarding state. Together with in-network memory, this forwarding state provides support for scaling data dissemination (multicast delivery and content distribution), balancing data flows for congestion control, retrieving data via multiple paths, and facilitating mobile and delay-tolerant communications.

We expect the following major deliverables by the end of this project. 

• A specification of the standard formats for the two packet types, Interest and Data, in NDN data delivery. We expect this specification to play a role equivalent to that of RFC791 (Internet Protocol Specification) for NDN networks.
  The challenge in nailing down this specification is not the format, but the verification and validation of the exact functions that must be supported by the narrow waist.
• A functional version of each of the necessary supporting modules in an operational NDN network [2]. The currently identified modules include libraries for naming conventions that reside above the NDN layer, routing protocols and forwarding strategy module that reside at the narrow waist NDN layer, trust management, and usable, efficient cryptography for data security.
  We see an analogy between the above list and IP with its supporting components. Although the IP address allocation system, routing protocols, and DNS are not part of the IP narrow waist, they are nonetheless necessary supporting components to make an operational IP network. The fact that DNS was added after the initial IP deployment further underscores the importance of identifying missing components from real deployment.
• A set of applications, including but not limited to the ones we have identified, that operate over an NDN network. These applications will include both new ones that are specifically designed to run on top of NDN, as well as legacy ones that have been deployed in today’s Internet.
• An online documentary for the NDN project process, and a technical report series to capture our thinking along the path of architectural development.

[1] RFC791 explicitly requires that an IP address be bound to an “interface” — i.e., that it has the same semantics as a telephone number.

[2] By “functional version” we mean that these modules are likely to continue to evolve in an operational, interoperable NDN network.