Information-Centric Networking Research Group (ICNRG) F. Lastname
Internet-Draft Affiliation
Intended status: Informational July 14, 2017
Expires: January 15, 2018

Design Choices and Differences for NDN and CCNx 1.0 Implementations of Information-Centric Networking


The purpose of this draft is to document identified commonalities and differences between the architectural design choices of NDN and CCNx 1.0, and to describe the rationales underlying the choices.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 15, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

NDN and CCNx 1.0 are two prominent realizations of the Information-Centric Networking (ICN) vision. Both realizations share the same root of Content Centric Networking (CCN) design introduced by Van Jacobson in 2006. CCNx, from versions 0.1 to 0.8 (referred to as CCNx 0.x in the rest of this draft), was the name of the software router and libraries developed and maintained by PARC. Although the protocol architecture was renamed to NDN when the effort got funded under NSF’s Future Internet Architecture (FIA) program in 2010 (with PARC being one of the ten funded institutions), the NDN project used CCNx 0.x as its implementation in its first two years of operation, and PARC provided the codebase support to meet the research needs for the rest of the project team.

In October 2012, PARC parted the way from the rest of the NDN project team in (interested readers may take a look at the related causes). In 2013 PARC introduced a significantly re-designed, non-backward-compatible protocol CCNx 1.0, which was acquired by Cisco Systems in 2017.

In parallel, the NDN project team has been continuing to refine the NDN protocol derived from the original CCNx 0.x design, guided by the NDN protocol design principles and based on experimentation results.

The objective of this document is to summarize the shared commonalities between the latest versions of NDN and CCNx 1.0 realizations, identify points of divergence, and documents reasons behind these different design choices. The identified commonalities and differences serve as a starting point to an open discussion to determine possibility to harmonize the two realizations, and if determined so, provide a general guidance on how to achieve it.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

ICN terms used in this document are interpreted as described in [I-D.wissingh-icnrg-terminology].

3. Background

3.1. CCNx 0.x: Origin and Point of Commonality

A note of notation first: the CCNx 0.x documents use the word “message" to refer to packet. CCNx 1.0 gives distinctive and different definitions to “messsage" and “packet". To avoid confusion, the following uses the word packet in CCNx 0.x description.

3.1.1. Packet Format

CCNx 0.x defines a variable-length encoding format using binary XML encoding (ccnb). This encoding defines all packet formats by XML schemas with explicitly identified field boundaries. This protocol format design permits field values of arbitrary length, nested structures, and optional fields that consume no packet space when omitted.

3.1.2. Name

CCNx 0.x defines a hierarchical naming structure, each component in a name can be an arbitrary length sequence of zero or more bytes. Encoding of the name follows the overall packet format, i.e., represented on wire as binary-encoded XML.

In addition to an explicitly defined sequence of name components, the name of each Data packet includes an additional implicitly appended name component: the implicit digest. This component contains the raw bytes of the SHA-256 digest of the entire ccnb-encoded Data.

CCNx 0.x also defines a set of naming conventions on how to encode various information as part of the name, including binary data, versions, segments, meta-data header, and commands.

3.1.3. Packet Types

CCNx 0.x defines two packet types: Interest and Data (also called Content Object).

An Interest packet is used to request data by name. The name can be either a prefix, an exact, or a full name of the desired data to be retrieved; if the name is a prefix, the Interest may carry optional "selectors" to restrict which content is preferred when multiple pieces of them all fall under the given prefix.

The name is defined as the only required element in an Interest packet; other optional elements that an Interest may carry can be sorted into the following categories:

A Data packet is named piece of content that is immutable bound together with a cryptographic signature. The specific type of the signature is defined as part of the SignedInfo field in form of OID identifier.

The structure of a Data packet is defined as Signature, Name, SignedInfo, and Content. The Signature fields carries cryptographic digest and public key signature (plus "witness" for special type of Merkle-tree group signature), computed over the rest of the ccnb-encoded part of the packet. The SignedInfo is allows inclusion of:

CCNx 0.x defines a concept of Data packet staleness. A newly received (or re-retrieved) Data packet is considered "not stale" for the duration limited by FreshnessSeconds (always not stale if Data packet does not carry the field). "Stale" content objects are still valid data, but they are not eligible to be matched with Interests, unless "answer may be stale" bit set in the Interest's AnswerOriginKind element.

3.1.4. Forwarding Behavior

A CCNx 0.8 specification defines the following forwarder behavior for processing of Interest and Data packets:

CCNx 0.8 codebase uses "two-best route then flood" strategy. Each forwarder for each name prefix in its FIB keeps an estimate of the round-trip time. If an Interest goes unsatisfied longer than this estimate, the forwarder either looks up the second best FIB entry (if exists) and forwards the Interest there (first timeout) or sends Interests to the remaining FIB entries (if any). The intention of this approach is to adaptively explore available paths and retrieve Data, taking advantage of CCNx 0.8 design to prevent Interest loops through PIT state and Nonce mechanisms. The estimate is initialized to a hard-coded value between 8 and 12 msec and uses multiplicative increase multiplicative decrease approach with constant 1/128 to adjust it after receiving Data (decrease to t = 0.992 * t) or upon timeout (increase to t = 1.125 t). This means that about every 8th Interest will trigger a timeout and sending on the second best path. This infrequent use of the second best path updates that path's RTT estimate.

The CCNx 0.x forwarder uses a set of flags on FIB entries called Child Inherit and Forward Capture [cite NFD dev guide?]. By default, the FIB matching takes a strict longest prefix matching approach. If the Child Inherit flag is set on a shorter prefix, it indicates that shorter prefixes should be considered equally feasible as the longer matching prefixes. The Forward Capture flag on a shorter prefix indicates that no longer prefix should be used (it avoids another process from "capturing" the FIB entry by making a longer entry). The use of these two flags has a strong interaction with the "two-best route then flood" forwarding strategy, as they either expand or contract the set of feasible routes used in Interest forwarding and Interest timeout retransmission.

3.2. Summary of Changes

3.2.1. Protocol Changes Made by the NDN Team

Based on a common understanding of the inefficiency from ccnb packet encoding used by CCNx 0.8, in 2013 NDN Team created, and subsequently revised, a new NDN protocol specification. The new version has kept the essential semantics and properties of the original CCNx: flexibility in packet format encoding, support of prefix match between interests and data packet to support in-network name discovery, which is required in supporting data immutability as consumers may not know the exact or full name of the desired data, which may be produced in real time or even in response to the Interest request.

The following list is a brief summary of the changes to CCNx 0.8 made by the NDN specification.




Packet Types

Interest Packet:

Data Packet:


3.2.2. CCNx 1.0 Changes

In the beginning of 2013, PARC team has undertaken a significant revision of CCNx (CCNx 1.0), refactoring the protocol behavior and packet format.

The following list is a high-level summary of the changes.




Packet Types

Interest Packet

Data Packet


4. Discussion of Individual Architecture & Design Commonalities and Differences per NDN and CCNx 1.0 Development paths

4.1. Packet Structure

In general, ICN packets require for the following three components (some optional) with semantic differences:


The NDN packet specification defines information-layer packets, including some of the elements that potentially belong to the network adaptation layer. There is an ongoing discussion to reorganizing the defined packet format to clearly separate information- and network adaptation layer elements.

A set of companion specifications (NDNLP [cite?], lora [cite?]) defined link adaptation elements, including hop-by-hop fragmentation, packet recovery, congestion information gathering, geo-tags, etc.

... some elements in NDNLP potentially belong to different layers and NDN Team is considering restructuring ...

CCNx 1.0

CCNx 1.0 specification defines a single packet structure consisting of four section, incorporating elements of ICN information, network adaption, and link adaptation layers:

4.2. Packet Encoding


NDN packet is encoded as a pure TLV encoding using a flexible 1-3-5-9-octet format for Type and Length fields.


Potential drawbacks:

CCNx 1.0

As highlighted above, different parts of the CCNx 1.0 packet use different type of encoding:


Potential drawbacks:

4.3. Naming

The naming structure of NDN and CCNx 1.0 is almost equivalent, as both define name as a set of typed name components. The only difference is interpretation of the name in relation to the data packet:

4.4. Data Retrieval


Data can be retrieved by full, exact, and prefix name. NDN includes an assumption that exact names are not intentionally reused by different data

Selector support

"FreshnessPeriod" in Data packets as a relative time to treat Data "fresh" for discovery purposes


Talk about: Name based scoping using a set of naming conventions, including "/localhost" and "/localhop"

Similar Interest Aggregation

Exponential-back off interval to allow interest retransmission

CCNx 1.0

Data can be retrieved only using full or exact name.

App-defined name discovery:

Similar Interest Aggregation

CCNx 1.0 recommends this interest aggregation algorithm:

4.5. Opportunistic In-Network Caching

Both protocols include ability to cache each forwarded data packet with forwarded-defined policies


"Fresh"/"stale" semantics for the cached data (CS can keep stale packet and satisfy Interests that do not request "fresh" data)

CCNx 1.0

alive/dead semantics: Requirement that CS cannot use "dead" data to satisfy interests (current spec only) CS alive/dead decision requires absolute time synchronization within required discovery resolution Requirement for Cache verification: if Interest specifies KeyRestriction, cache cannot satisfy the interest without verification

4.6. Forwarding Loop Management


...NDN assumes networks without guarantees for loopless routing (assumes that routing either don’t exist or have high chance to result in looping paths)...

PIT state to stop the interest from forwarding

"Nonce" to detect potentially duplicated interests with ability to prune "duplicate" paths

"HopLimit" to kill interest loops in special cases

CCNx 1.0

CCNx 1.0 uses a HopLimit field in the fixed header of Interest packets. This field restricts an Interest to at most 255 hops, so a loop will eventually terminate. An Interest loop would likely terminate faster than that because once it completes its first cycle it would either find a Pending Interest Table entry that aggregates it (suppressing forwarding it) or it finds a ContentStore entry that satisfies it. The vulnerability to longer loops occurs when PIT entries get satisfied faster than the loop period and the Content Object is either not cachable or a node has no cache or its cache entry gets evicted too fast.

CCNx 1.0 also recommends decrementing the Interest Lifetime by an appropriate amount at each hop, which also serves to limit looping.

CCNx 1.0 assumes that routing protcocols produce routes without permanent loops.

Uses of HopLimit

An option to scope interest forwarding using HopLimit field. CCNx 1.0 informally maintains the CCNx 0.x conventions of /localhost, but that convention is not in the standard.

CCNx 1.0 has not adopted a /localhop convention because it can be achieved via the HopLimit. We also believe that each link should be uniquely named to avoid confusion in the FIB and ContentStore. Clearly, /localhop prefixed names cannot use FIB forwarding and they cannot be stored in a common ContentStore.

4.7. Data-Centric Security


CCNx 1.0

There is one packet envelope with optional Validation on both Interest and Content Validation can be a MIC, MAC, or Signature. We allow formats like a CRC, an HMAC, Elliptical Curve, and RSA. We also allow unsigned packets, which are used when trust is achieved via hash chains from a previously signed packet.

Validation only covers the Message and the ValidationAlg, not the optional headers or fixed header.

CCNx 1.0 allows signing Interests. This is usually to allow a CRC on Interest to protect against in-network corruption. However, the Interest may be signed via a stronger signature within an application usage. CCNx does not recommend signing or processing signed Interest when the application protocol is not expecting such, as this is a computational denial of service vector.

The CCNx KeyExchange (CCNxKE) protocol (see is an on-line key exchange protocol similar to TLS 1.3 to negotiate encryption keys. We believe this form of session security is intrinsically useful and should be supported within an ICN, even though other forms of off-line publishing encryption may be used in other cases.

4.8. Fragmentation

Both NDN and CCNx use hop-by-hop fragmentation, though the specific details on the fragmentation protocol differ.

4.9. Indirect Data Retrieval


Forwarding Hint

CCNx 1.0

Special handling of Data packets that do not include "Name" field (=retrieved using data digest)

Data is matched against "restriction" field; name is completely ignored

5. Security Considerations


6. Acknowledgements


7. IANA Considerations

This document includes no request to IANA.

8. Normative References

[I-D.wissingh-icnrg-terminology] Wissingh, B.,, c., Zhang, L., Afanasyev, A. and D. Oran, "Information-Centric Networking: Terminology", Internet-Draft draft-wissingh-icnrg-terminology-00, July 2016.
[ndn-spec] NDN Team, "NDN Packet Format Specification 0.2-2 documentation", June 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

Firstname Lastname Affiliation Address City, ZipCode Country EMail: email URI: homepage