Subject: [icnrg] Planning for the ICN packet format discussion on Saturday

From: David R Oran <[email-masked]>
Date: Fri, 26 Sep 2014 09:51:36 +0200

We have a 90 minute agenda item for the interim meeting tomorrow to discuss the current state of various packet format proposals that have been developed for NDN and CCN. The chairs thought that it was a propitious time to look at this issue because in the last year the various parts of the community have come a lot closer than they were a year ago. If we can converge of a minimal or subset interoperable packet format soon, that will foster broader interoperability and perhaps enable us to work bottom-up as well as top-down in evaluating some of the more far-reaching research questions in what the architectural features should be.

Here’s how I’d like to propose we structure the discussion:

I’d like to start out for about 20-30 minutes with summaries of the existing proposals, of which there are four that are reasonably well documented:

ALU (presented by Diego Perino)
CCN 1.0 (presented by Ignacio Solis or another PARC person)
Cisco (presented by Mark Stapp)
NDN (…the new one which either Mark Stapp or Dave Oran can summarize.

In the presentation phase I’d like if at all possible to avoid comparisons or targents into architectural discussions.

Then we can ave a 60 minute “panel” style discussion of the various proposals and where they might converge and where the sticking points are. In this discussion, I’d like to touch on (at least) the following design questions:

1. Do we have a fixed end-to-end header
2. Do we have a (separate) hop-by-hop header
3. Should we mandate which fields are mutable hop-by-hop and if so should they be required to be groups together in the packet.
4. Should we have typed name components and if so what are the requirements, if any, for intermediaries to understand/process them
5. If we do TLV what should the maximum “L” be - is 16 bits enough? Do we have multiple TL encodings, or just a simple fixed encoding. What are the consequences for parser/name aliasing?
6. Do we need to introduce hop-by-hop messages now or can we defer that design question for later

Feel free to suggest additions/deletions from this list.

If we have time we can also discuss how we might move forward as an RG in resolving some of the thorny architectural differences that characterize the various designs in ways that have more than trivial impact on the wire format and forwarding semantics.

Thanks, DaveO.