Project

General

Profile

Feature #4786

KITE implementation

Added by Zhongda Xia 4 months ago. Updated 15 days ago.

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

0%

Estimated time:

Description

KITE is a producer mobility support solution for NDN. The goal of this issue is to implement network-layer support for KITE in NFD. For the design details, the paper and slides for ACM ICN 18' are attached.

icn18-final23.pdf (1.74 MB) icn18-final23.pdf Zhongda Xia, 12/10/2018 02:31 PM
slides-papers-13.pdf (1.46 MB) slides-papers-13.pdf Zhongda Xia, 12/10/2018 02:31 PM

History

#1 Updated by Davide Pesavento 3 months ago

  • Tracker changed from Task to Feature
  • Start date deleted (12/10/2018)

#2 Updated by Zhongda Xia 3 months ago

I have revised the implementation plan according to the last discussion. Link to Google doc: https://docs.google.com/document/d/1p0TCVdWuNIAPFmhy50-CnOpfsxax5F7JbyUP53fLDJE/edit?usp=sharing

A few key points:
* the "trace" tag name component should be "keyword" type
* trace Data should be set to a designated ContentType
* trace Data carries a PrefixAnnouncment object
* the trust schema for trace Data verification should be provided (manually at this stage)

Apart from implementing the network layer support, another required change is using NFD readvertise module for trace update (sending trace Interest upon relocation). I am currently checking the readvertise code to figure out the missing parts, any help or suggestion is welcome!

#3 Updated by Junxiao Shi 3 months ago

The ContentType should be reserved on ContentType registry.
This in turn requires a specification of the exact encoding of the trace data.

#4 Updated by Zhongda Xia 3 months ago

Junxiao Shi wrote:

The ContentType should be reserved on ContentType registry.
This in turn requires a specification of the exact encoding of the trace data.

Hi Junxiao, I haven't figured out how to edit the Wiki page, maybe I don't have the permissions?

#5 Updated by Teng Liang 2 months ago

Hi Junxiao, I haven't figured out how to edit the Wiki page, maybe I don't have the permissions?

Can you see an icon with the name New wiki page on this page https://redmine.named-data.net/projects/nfd/wiki?

#6 Updated by Zhongda Xia 2 months ago

Teng Liang wrote:

Hi Junxiao, I haven't figured out how to edit the Wiki page, maybe I don't have the permissions?

Can you see an icon with the name New wiki page on this page https://redmine.named-data.net/projects/nfd/wiki?

Hi Teng, no I don't see the icon.

#7 Updated by Davide Pesavento 2 months ago

I've added you to the NFD project as developer. Try again.

#8 Updated by Zhongda Xia 2 months ago

Davide Pesavento wrote:

I've added you to the NFD project as developer. Try again.

Works now, thanks.

#9 Updated by Zhongda Xia about 1 month ago

As last discussed in an NFD call, a KiteAck (trace Data in KITE) should carry a prefix announcement object (PA) to reuse the existing code for verification. The RV will create a PA for each legitimate trace Interest (signed Interest sent by a mobile producer), encapsulate the PA in a Data packet (KiteAck), and forwarders check the PA carried in KiteAck to decide whether to update RIB.

But for KITE, an extra step is needed, that is, to check whether the prefix specified by the PA is the same as the prefix specified by the Interest/Data name. For example, a KiteAck named "/Alice/trace/photos" can only carry a PA named "/Alice/photos". In KITE's design, the prefix is determined by the name of trace Interest/Data (signed Interest from mobile producer and KiteAck), so the PA's name must represent the same prefix.

If the above makes sense, then one option is as follows:

  • Provide a new API for KiteAck verification (nfd::rib::RibManager::kiteAnnounce): kiteAnnounce is invoked for Data with KiteAck ContentType. The API first checks the name format (since so far only the ContentType is checked), then checks whether the PA specifies the right prefix, and finally invokes the nfd::rib::RibManager::slAnnounce API to check the PA and update RIB.

#10 Updated by Teng Liang about 1 month ago

Since I didn't join the call, some description is not very clear to me. Here are my questions and comments:
1. Regarding KiteAck (just a Data packet), is PA appended to it as an NDNLPv2 field or is PA encapsulated as the content of KiteAck?
2. nfd::rib::RibManager::slAnnounce uses the localhop validator, which probably does not use the same validation policy as Kite, therefore you may need a different validator and have your own implementation in nfd::rib::RibManager::kiteAnnounce.
3. Where is this procedure executed, in a forwarding strategy or among forwarding pipelines?

#11 Updated by Junxiao Shi about 1 month ago

There’s no need for a separate nfd::rib::RibManager::kiteAnnounce function. Just check the Data name - PA name relation before invoking nfd::rib::RibManager::slAnnounce.
There will be more validators, because NFD-Android cannot use localhop_security. Refer to 20190213 call for details.

#12 Updated by Zhongda Xia about 1 month ago

Teng Liang wrote:

Since I didn't join the call, some description is not very clear to me. Here are my questions and comments:
1. Regarding KiteAck (just a Data packet), is PA appended to it as an NDNLPv2 field or is PA encapsulated as the content of KiteAck?
2. nfd::rib::RibManager::slAnnounce uses the localhop validator, which probably does not use the same validation policy as Kite, therefore you may need a different validator and have your own implementation in nfd::rib::RibManager::kiteAnnounce.
3. Where is this procedure executed, in a forwarding strategy or among forwarding pipelines?

Thanks for the comments! Responses below.

  1. Appended as NDNLPv2 field, like self-learning.
  2. Agree, KITE needs its own validator, cannot directly invoke slAnnounce for validating PA.
  3. The consensus was to integrate into forwarding pipelines. After receiving Data, and finding a match in PIT, enter KiteAck processing (parallel to normal processing like Data forwarding) if ContentType==KiteAck.

After some more thought, how about KiteAck not carrying PA? Arguments below.

  • A KiteAck that is signed by the RV is enough for verification purpose, and only the name and the signature is important. The name of the KiteAck determines the prefix, and hence how to verify the signature (which RV is in charge of this prefix). The content of KiteAck is not important.
  • In self-learning, PA can be saved and later attached to Data by forwarders, KITE requires no such operations (a forwarder does not propagate the route, KITE only updates the forwarders on the path between the MP and the RV), any piece of information carried in KiteAck does not need to be remembered or reused. In fact, since the MP sends a new trace Interest for each path update (the name will be different after signing), and considering that a KiteAck is essentially an acknowledgment from the RV for a specific trace Interest, an old KiteAck is irrelevant.

Without carrying PA, the KiteAck processing logic looks like this:

  1. check name format
  2. determine prefix
  3. validate KiteAck's signature (using the trust model for the prefix)
  4. update RIB

#13 Updated by Zhongda Xia about 1 month ago

Junxiao Shi wrote:

There’s no need for a separate nfd::rib::RibManager::kiteAnnounce function. Just check the Data name - PA name relation before invoking nfd::rib::RibManager::slAnnounce.
There will be more validators, because NFD-Android cannot use localhop_security. Refer to 20190213 call for details.

This should work if KITE can have its own validator, and nfd::rib::RibManager::slAnnounce knows which validator to use for PA from KiteAck.

Also, what do you think of KiteAck not carrying PA, please refer to my response to Teng (#12). Thanks!

#14 Updated by Junxiao Shi about 1 month ago

This should work if KITE can have its own validator

No, KITE does not need its own Validator. Within a single ValidatorConfig, one can construct filters to match only certain kinds of packets. If necessary, ValidatorConfig can be extended to have more filters.

how about KiteAck not carrying PA?

No. Every prefix registration needs to have a PA eventually, including those created by /localhost/nfd/rib/register command today. This PA would support readvertising into a different context.

Consider this topology:

R---S---E
    |   |
    P   C

R is KITE rendezvous server. P is the mobile producer. P uses KITE to establish a route for /P prefix from R to S to P.

Now C wants to use self-learning to find /P. When its discovery Interest reaches S, S should have a PA to attach to the response, and the PA should come from the KiteAck packet, not made up by S.

#15 Updated by Zhongda Xia 18 days ago

Junxiao Shi wrote:

The ContentType should be reserved on ContentType registry.
This in turn requires a specification of the exact encoding of the trace data.

Wiki pages updated, please check.

#16 Updated by Junxiao Shi 18 days ago

KiteAck rev6 says:

Carry a prefix announcement object in NDNLPv2 header, and the "announced prefix" indicated by the PA object must be the same as the name of the KiteAck minus the "32=KITE" component (excluding Interest signature related components).

This design is wrong. The prefix announcement object should be placed in the Data payload instead.

#17 Updated by Zhongda Xia 15 days ago

  • Status changed from New to In Progress

#18 Updated by Zhongda Xia 15 days ago

Junxiao Shi wrote:

KiteAck rev6 says:

Carry a prefix announcement object in NDNLPv2 header, and the "announced prefix" indicated by the PA object must be the same as the name of the KiteAck minus the "32=KITE" component (excluding Interest signature related components).

This design is wrong. The prefix announcement object should be placed in the Data payload instead.

I agree.

And just to make sure we are on the same page, I guess your point is that KiteAck is itself an independent piece of data generated upon request, and the PA object is an inherent part, thus should be put in the payload. Unlike the self-learning case, where the PA object is an extra piece of information piggybacked on the returned data object, thus has to be attached at link layer.

Also available in: Atom PDF