Project

General

Profile

Feature #4650

Accept and store PrefixAnnouncement in rib/register command

Added by Junxiao Shi over 1 year ago. Updated 10 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
RIB
Target version:
Start date:
Due date:
% Done:

40%

Estimated time:
6.00 h

Description

Including PrefixAnnouncement in RibMgmt rib/register command enables prefix propagation without NFD having to access the prefix owner's signing key.
This issue changes RibManager to accept the alternate command format, and also stores the PrefixAnnouncement element in the RIB entry so that readvertise component can retrieve it.


Related issues

Blocked by NFD - Feature #4649: Include PrefixAnnouncement in prefix registration commandsIn Progress

Actions
Blocks NFD - Feature #4651: Prefix propagation: use stored PrefixAnnouncementNew

Actions
Blocks jndn - Feature #4652: Include PrefixAnnouncement in prefix registration commandsNew

Actions
Blocked by ndn-cxx - Feature #4804: Signed Interest v0.3In Progress

Actions

History

#1

Updated by Junxiao Shi over 1 year ago

  • Blocked by Feature #4649: Include PrefixAnnouncement in prefix registration commands added
#2

Updated by Junxiao Shi over 1 year ago

  • Blocks Feature #4651: Prefix propagation: use stored PrefixAnnouncement added
#3

Updated by Junxiao Shi over 1 year ago

  • Blocks Feature #4470: Extend RIB for prefix announcement in self-learning added
#4

Updated by Junxiao Shi over 1 year ago

  • Blocks Feature #4652: Include PrefixAnnouncement in prefix registration commands added
#5

Updated by Junxiao Shi over 1 year ago

  • Blocks Feature #4683: add RIB entry update with prefix announcement in self-learning added
#6

Updated by Junxiao Shi over 1 year ago

  • Assignee set to Junxiao Shi
  • Target version set to v0.7

As I promised on 20180815 NFD call, I will provide code for Rib changes within 7 days after #4649 design is approved.

#7

Updated by Junxiao Shi over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20
  • Estimated time changed from 3.00 h to 6.00 h

https://gerrit.named-data.net/#/c/NFD/+/4918 changes object ownership between rib::Service and RibManager. It fulfills most of #3818-23 design. This is a necessary preparation before PrefixAnnouncement changes.

#8

Updated by Junxiao Shi over 1 year ago

  • % Done changed from 20 to 30

https://gerrit.named-data.net/#/c/ndn-cxx/+/4921 encode and decode prefix announcement object. Please review API before I proceed further.

#9

Updated by Junxiao Shi over 1 year ago

  • % Done changed from 30 to 40

Change 4921 patchset 2 has PrefixAnnouncement decoding implementation. Encoding implementation comes next.

#10

Updated by Junxiao Shi over 1 year ago

Change 4921 patchset 4 has PrefixAnnouncement encoding implementation.

#11

Updated by Junxiao Shi over 1 year ago

https://gerrit.named-data.net/#/c/NFD/+/4931 puts incoming prefix announcements in Route, and provides outgoing prefix announcements from RibEntry. In case a RibEntry does not contain a Route with a PA, one will be made up for use in readvertisement (including self-learning's producer node).

#12

Updated by Teng Liang over 1 year ago

Junxiao Shi wrote:

https://gerrit.named-data.net/#/c/NFD/+/4931 puts incoming prefix announcements in Route, and provides outgoing prefix announcements from RibEntry. In case a RibEntry does not contain a Route with a PA, one will be made up for use in readvertisement (including self-learning's producer node).

If NFD can make up a PA, there is no need for end hosts to register a route using PA. I was thinking to add another registerPrefix API in ndn-cxx, for producers control the creation of PA. Just want to point out that there is no requirement from end points to use this feature.

#13

Updated by Junxiao Shi over 1 year ago

shouldn't the origin be prefix announcement?

Teng, can you help with this? It needs protocol update and declarations in ndn-cxx.

If NFD can make up a PA, there is no need for end hosts to register a route using PA.

NFD may not have a suitable key to sign the PA, see #4648.

I was thinking to add another registerPrefix API in ndn-cxx, for producers control the creation of PA.

This part is blocked by #4649 command format definition, which in turn is blocked by #4599. Self-learning does not depend on this (if you relax the trust schema or install the keys to NFD keychain), but Android depends on this (see #4648).

#14

Updated by Teng Liang over 1 year ago

Junxiao Shi wrote:

shouldn't the origin be prefix announcement?

Teng, can you help with this? It needs protocol update and declarations in ndn-cxx.

To make it clear, we are keeping one format of PA, which can used in both the rib/register command and NDNLP header, right?

What is exactly needed for protocol update (specific tasks)?

If NFD can make up a PA, there is no need for end hosts to register a route using PA.

NFD may not have a suitable key to sign the PA, see #4648.

What's the potential trust models?

I prefer the NFD to generate PA on behalf of the registered producers, using NFD's own keys:

  1. it does not require changes to end apps
  2. the trust model would be simpler?

I was thinking to add another registerPrefix API in ndn-cxx, for producers control the creation of PA.

This part is blocked by #4649 command format definition, which in turn is blocked by #4599. Self-learning does not depend on this (if you relax the trust schema or install the keys to NFD keychain), but Android depends on this (see #4648).

If NFD makes up PA, there is not need to change registerPrefix API in ndn-cxx.

#15

Updated by Junxiao Shi over 1 year ago

What is exactly needed for protocol update (specific tasks)?

See #4280-83.

What's the potential trust models?

Testbed routers enforce hierarchical trust model, so NFD-Android has to let application create the PA, see #4648.

Self-learning is more flexible because it does not involve testbed routers. We can start with:

  1. From enterprise CA (a CA trusted by every node in the local area network), issue an announcement signing certificate to each node.
  2. In the trust schema, set trust anchor to enterprise CA (or its issuer), and set rules so that any announcement signing certificate can sign any PA.

The better solution is in self-learning dissertation.
Since this question is out of scope of #4650, I will not post further answers here. If you want more discussion, please email nfd-dev mailing list.

#16

Updated by Teng Liang over 1 year ago

Junxiao Shi wrote:

Self-learning is more flexible because it does not involve testbed routers.

I agree with this. So in self-learning, the producers can be unaware of PA, and the NFD they connect to will help them to create PA.

#17

Updated by Teng Liang over 1 year ago

[Bug] The data returned by PrefixAnnouncement::toData does not have the tlv::ContentType_PrefixAnn content type.

#18

Updated by Junxiao Shi over 1 year ago

[Bug] The data returned by PrefixAnnouncement::toData does not have the tlv::ContentType_PrefixAnn content type.

Fixed in https://gerrit.named-data.net/#/c/ndn-cxx/+/4943

#19

Updated by Teng Liang over 1 year ago

self-learning is still waiting for this to finish.

#20

Updated by Junxiao Shi over 1 year ago

  • Blocks deleted (Feature #4470: Extend RIB for prefix announcement in self-learning)
#21

Updated by Junxiao Shi over 1 year ago

  • Blocks deleted (Feature #4683: add RIB entry update with prefix announcement in self-learning)
#22

Updated by Davide Pesavento 6 months ago

  • Target version changed from v0.7 to v0.8
#23

Updated by Junxiao Shi 10 days ago

#24

Updated by Junxiao Shi 10 days ago

PrefixAnnouncement rev8 defines the rib/announce command (variant of rib/register that accepts PrefixAnnouncement) to use signed Interest. Therefore, this issue is blocked by #4804 signed Interest implementation.

Also available in: Atom PDF