NDN-CCL

For starters, I'd suggest supporting a "set" for local control headers in the outgoing interest and a "get" for the incoming data packet. Would that work?

Sounds good to me; that's all I need right now to do what I need to do.

Andrew, I'm a little bit confused how the need of creating routes depends on LocalControlHeader. This header is designed to pass some information between app and local forwarder (and back), such as IncomingFaceId (for things from the forwarder) and NextHopId (in interests towards the forwarder).

Are you thinking about adding some other fields?

Alex, I am no expert on the LocalControlHeader feature but from what Junxiao explained to me at the retreat I think I can use IncomingFaceId to register routes back to other nodes from within my application. My application, on node A, will wait for an incoming command interest from node B; when it receives it and validates it, it can use the IncomingFaceId to instruct its local NFD to register a static route back to node B. (In this case, both nodes would have local NFDs, but once we add setInterestFilter() I can do the same with non-NFD nodes). I am vaguely aware of several tools that may do similar things to this (ndns?) but not programmatically. Thoughts?

To clarify, without IncomingFaceId I would have to pull the face list from the NFD and then parse/guess/something to figure out what face to make the static route on.

Got it. It was just a little unclear what you meant by registering prefixes. Now I understand that you want to register prefixes towards faces from which interest was received, so yes, you need LocalControlHeader feature.

How it is implemented can be different from cxx (as I don't really like it and planning to rework at some point). Interest/Data packet can allow "annotation" to be attached to them, that is added when LocalControlHeader is present. When putting Interest/Data on the wire, the annotation can be added in front of the packet.

Sounds good. Since this is a low-use feature, there won't be a problem to change to a new approach at some point when ndn-cxx fleshes it out. For now, we'll add a LocalControlHeader field and mark it as an experimental API as we have in other places.

Hi Andrew. Please check out the branch issue/2531-LocalControlHeader: https://github.com/named-data/jndn/commits/issue/2531-LocalControlHeader .

At the moment, it will unwrap an incoming LocalControlHeader and set the fields in the Data packet. You can call Data.getIncomingFaceId(). Two questions:

1. For your purposes at the moment, do you need to be able to set the outgoing Interest setNextHopFaceId?

2. Do you already have code to send the command interest to enable the local control feature in NFD, or do you need a library utility method to do that? (I'd like to avoid if possible since the pieces are already in the library to make an interest with a ControlParameters and to sign it.)

Looks good to me. (One minor question re: Data/Interest API: why don't we just expose one getter/setter, e.g. getLocalControlHeader(), and that way Data and Interest won't have to change as much if the NFD team adds more properties? I am not too concerned either way, just a thought; it would be consistent with how getMetaInfo() works too).

1. No
2. No, I don't, but I will add that as a helper method in the jndn-management library (https://github.com/01org/jndn-management).

Thanks, I'm excited to start using this next week. By the way, once all these changes are in, have you thought about deploying/releasing to Maven Central as 0.3.1?

why don't we just expose one getter/setter, e.g. getLocalControlHeader() ... it would be consistent with how getMetaInfo() works too.

It is a little different than getMetaInfo() since meta info is really part of the Data packet. The local control header stuff is auxiliary and for now we aren't supporting setting local control header fields for an outgoing data packet. (And even if we did it doesn't make sense to set the outgoing data packet's next hop face ID.) Only having Data.getIncomingFaceId() expresses what we intend to support. (I even tried to avoid Data.setLocalControlHeader().)

Makes sense. When are you thinking of merging and releasing?

I want to write an integration test and merge tomorrow.

Since you said you don't need to set the outgoing Interest setNextHopFaceId, I'll remove this method from Interest since there is no code at the moment to wrap an outgoing interest in a LocalControlHeader.

The integration test would have to modify NFD to send LocalControlHeader packets. So I'm going to delay writing the integration test until the other libraries can parse an incoming LocalControlHeader since it could mess up the other tests.

I take that back. The documentation says that the enable local control header command only affects the face which received the command, so it should be OK to make an integration test.

Since NFD will soon change to use the NDNLPv2 header instead of the current LocalControlHeader, so wait to implement that.

NDNLPv2 equivalent of LocalControlHeader is defined in #2763, so it's unnecessary to block this on #2520 which would take longer time.