[Nfd-dev] What link object to use on testbed?

[Haitao Zhang]

On Fri, Aug 18, 2017 at 6:10 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Haitao
>
> Link object in Interest has been replaced by forwarding hint. However,
> your question still applies when forwarding hint is used.
>
>
>> I tried to send an Interest with link object to the testbed, but the
>> producer didn't receive the interest. Could you help to see what is wrong
>> with my link object?
>>
>
>> Here is what I did:
>> (1) The producer registers prefix /org/openmhealth/<user-id> on ucla
>> router (spurs.cs.ucla.edu)
>> (2) A consumer connecting to remap router (128.97.98.7) sends an interest
>> with prefix /org/openmhealth/<user-id>, and with link object. The link
>> object has name  /org/openmhealth/<user-id>, and a delegation /ndn/edu/ucla(it
>> is ucla router's routable prefix), and it is signed by a cert
>> /org/openmhealth/KEY/<user-id>/...., which is signed by ndnfit trust
>> anchor, a second trust anchor on the testbed.
>>
>>
> REMAP router is configured <https://github.com/WU-ARL/NDN_Ansible/blob/
> 138020756db384222e62802baeaca0b6a090c6d7/host_vars/REMAP> to have network
> region name /ndn/edu/ucla/remap. Since the delegation name /ndn/edu/ucla
> carried in the forwarding hint is a prefix of this network region name,
> forwarding hint (or Link object) is removed when it arrives at REMAP, and
> forwarding follows the FIB entry for /org/openmhealth/<user-id>.
>
> REMAP has a static route for /org/openmhealth toward udp4://
> 128.97.98.8:6363 at cost 0 with child inherit enabled (as observed on the
> node right now, but no evidence in Ansible).
>

I asked John to configure this. We need /org/openmhealth to be routed to
128.97.98.8 by default, as ndnfit users produce data and "upload" their
data to DSU residing on 128.97.98.8, when users are offline, consumers
could still fetch those data from DSU.


> If I can assume you are working on the same app as
> http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2017-August/002601.html ,
> your prefix registration on UCLA sets route origin to "app", which does not
> trigger readvertising to global routing system. Therefore, NFD at REMAP
> forwards the Interest to udp4://128.97.98.8:6363 and it does reach your
> end host.
>

I intentionally didn't set route origin to "client", as
(1) I want to show broadcasting prefixes is not necessarily needed for apps
to work on testbed
(2) If I understand correctly, setting route origin to "client" will
disable the route I asked John to add (i.e., route all /org/openmhealth
traffic to 128.97.o98.8) partially:  /org/openmhealth/<user-id> will be all
routed to my app
(3) The app may connect any router, but not only ucla cs router. I don't
think it's a good practice to broadcast /org/openmhealth/<user-id> on the
entire testbed every time the app connects a different router and every
time the app uses a different user-id.


>
> Should you set route origin to "client" when you register
> /org/openmhealth/<user-id> on UCLA, the route would be readvertised into
> the global routing system, and show up at REMAP (and every other router) as
> a route with capture flag so that a FIB lookup would not match the udp4://
> 128.97.98.8:6363 route, and therefore the Interest would go to your end
> host. In this case, it would be unnecessary to place a forwarding hint on
> the Interest given the route for /org/openmhealth/<user-id> is already
> announced globally.
>

Please correct me if I am wrong. Thanks!

Best,
Haitao


> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170818/86250aec/attachment.html>