Discussion of Individual Architecture & Design Commonalities and Differences per NDN and CCNx 1.0 Development paths
... below we take in succession individual topics that capture the points where the differences between the NDN and CCNx 1.0 approaches are relevant and important to discuss. The topics listed below are taken from our prior discussions and are included for completeness only. We can reorganize, add or delete items as we see fit. The structure of each section will be the same as suggested in 4.1...
Use of TLV encodings
.. Details and motivation...
... Details and motivation ...
... Details and motivation ...
... Details and motivation ...
NDN and CCNx 1.0 has the same definitions of naming and extended it
- Explicitly typed components
// definition of Data digest
In CCNx 1.0, full name combines of "Name" and "digest" but is not logically tied together
Data can be retrieved by full, exact, and prefix name. NDN includes an assumption that exact names are not intentionally reused by different data
Data can be retrieved only using full or exact name.
Name based scoping using a set of naming conventions, including "/localhost" and "/localhop"
An option to scope interest forwarding using HopLimit field
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)
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
Selector support
- As a temporary mechanism to implement in-network name discovery
- Open research for the adequate replacement
"FreshnessPeriod" in Data packets as a relative time to treat Data "fresh" for discovery purposes
App-defined name discovery:
- Manifests for static data
- Encoding Selectors as part of the Interest name
...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 assumes (but no requirements) that routing system will provide mostly loopless forwarding paths
PIT state to stop interests from forwarding further
"HopLimit" to kill loops
Exponential-back off interval to allow interest retransmission
... Re-expressed interest detection ...
- Exploring signature formats: RSA, ECDSA, HMAC
- Command (Signed) Interests
- Trust schema
- Name based access control
...
Hop by hop fragmentation when necessary
LINK object
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
ChronoSync, RepoSync, ChronoSync 2.0, PartialSync "refs"
Manifest-based synchronization "refs"