NDN Protocol Design Principles

Comments

• [1] Universality: NDN should be a common network protocol for all applications and network environments.

  Applications and network environments that NDN should support include but not limited to:

  • today’s infrastructure-based communication (Web, Youtube, real-time conferencing, etc.)
  • ad hoc with and without infrastructure communication (IoT applications, wireless mesh networks, vehicle-to-vehicle networking, vehicle-to-vehicle-to-infrastructure, etc.)
  • DTN-style communication, communication over intermittent and disruptive links (first responder environments), application using unidirectional links (e.g., satellite)

  Therefore, NDN protocol and NDN packet format should support wide range of applications, from constrained (IoT) environments to big data science applications:

  • NDN packet format should be flexible and extensible.
  • NDN protocol and packet format should support protocol evolution without flag days: no fixed parts or fixed-length fields in the header.
  • The core network protocol operations should not depend on clock synchronization.

• [2] Data-Centricity and Data Immutability: NDN should fetch uniquely named, immutable “data packets” requested using “interest packets”.

  • NDN protocol and packet format should include only elements directly related to data, i.e., universally required, needed, and meaningful in all communication environments. Other elements needed in specific environments (e.g., in today’s infrastructure-based Internet) should go to the network adaptation layer(s).

  • Data packet immutability allows disambiguation of coordination in distributed system that may not be always connected. Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets. Related reading: “Immutability Changes Everything” by P. Helland

• [3] Securing Data Directly: Security should be the property of data packets, staying the same whether the packets are in motion or at rest.

  • Directly secured and uniquely named data removes the requirement for direct channels between communicating ends and enables asynchronous production and consumption of named and secured data, e.g., using in-network caches and managed repos.

  • Consumers should be able to validate individual data packets. Ideally, each packet should be verifiable on its own. As an engineering optimization, packets can be made verifiable in the context of others, provided that the context can be inferred from the data packet itself (its name or information in signature field).

• [4] Hierarchical Naming: Packets should carry hierarchical names to enable demultiplexing and provide structured context.

  • Name hierarchy provides context to implement and enforce various security models, i.e., give structured restrictions on which keys can sign which data.

  • Hierarchical names allow “flat” naming models, if needed/desired by applications.

• [5] In-Network Name Discovery: Interests should be able use incomplete names to retrieve data packets.

  A consumer may not know the complete network-level name for data, as some parts of the name cannot be guessed, computed, or inferred beforehand.

  Once initial data is received, naming conventions can help determine complete names of other related data

  • majority of interests will carry complete names
  • in-network name discovery expected to be used to bootstrap communication)

• [6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet.

  Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive.