[Ndn-interest] Mobility support on technical report + Signature infrastructure NDN

[Muhammad Hosain Abdollahi Sabet]

Hi Matteo,

Delegation names are names/prefixes which the carrying interest will be
forwarded
​towards them at first
.
​ When the interest reaches a delegation name, from there it will be
forwarded by it's name, not the Link anymore.

As an example take an application responsible for me(/sabet) which is
mobile and at the moment is located, or some how can be reached in /eurecom
network.​ For Interersts looking for a data under /sabet prefix (e.g
/sabet/calander/sep23), they should carry a Link object which has /eurecom
as a delegation name. So we will an interest packet(or a set of interests)
which has /sabet/calander/sep23 for its name, and a Link object which has
/eurecom as a delegation is attached
to it(the interest). Routers outside /eurecom network when receive that
interest, will forward it towards /eurecom. When the interest reaches a
router in /eurecom network, then it will be forwarded towards /sabet which
existence of the Link object indicates that /sabet exist in FIB table of
​routers in /eurecom. If application responsible for /sabet moves into
another network (e.g. /ucla) and cannot be accessed in /eurecom, then
Interest should have updated version of Link, which has /ucla as delegation
name, in order to reach /sabet.
Sorry. It seems my example got a bit complicated.
I suggest you to take a look at
http://named-data.net/publications/snamp-ndn-scalability/ for understanding
how Link object is supposed to work and what is its impact on forwarding
process.

Bests,
Sabet

On Sep 23, 2016 4:40 PM, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
wrote:

> Good morning, I would like to ask you a thing about mobility support and
> one about the signature mechanism.
>
> 1) I am reading the paragraph about the mobility support during the
> forwarding of an interest in the NFD Developer guide:
> https://named-data.net/wp-content/uploads/2016/03/ndn-0021-6
> -nfd-developer-guide.pdf
> Paragraph 4.2.3. I need to clarify some aspects because I do not
> understand well the process described in this paragraph:
>
> "If the Interest carries a Link object, it is processed for mobility
> support.
> First, the pipeline determines whether the Interest has reached the
> producer region, by checking if any delegation name
> in the Link object is a prefix of any region name from the network region
> table (Section 3.2). If so, FIB lookup is
> performed using Interest Name, as if the Link object does not exist.
> Second, the pipeline inspects whether the Interest contains the
> SelectedDelegation field, which indicates that a down-
> stream forwarder has chosen which delegation to use. If so, it implies
> that the Interest is already in default-free zone,
> FIB lookup is performed using the selected delegation name.
> Third, the pipeline determines whether the Interest is in the consumer
> region or has reached the default-free zone, by
> looking up the first delegation Name in FIB. If this lookup turns out the
> default route (i.e., the root FIB entry ndn:/
> with a non-empty nexthop list), it means the Interest is still in consumer
> region, and this lookup result is passed down
> to next step. Otherwise, the Interest has reached the default-free zone.
> Last, the pipeline selects a delegation for an Interest that has reached
> the default free zone, by looking up every
> delegation name in the FIB, and choose the lowest-cost delegation that
> matches a non-empty FIB entry. The chosen
> delegation is written into the SelectedDelegation field in the Interest
> packet, so that upstream forwarders can follow
> this selection without doing multiple FIB lookups."
>
> In particular, the purposes of mobility support, what are the delegations,
> what their utility and so on.
>
>
> 2) Meanwhile, I would like to use this mail in order to ask another thing
> about the Signature infrastructure using the ndn-cxx. I would like to test
> the mechanism, but I need some advices. For example, does it exists already
> something that can help me? Or should I create a node "Certificate
> authority" that answer to the request in the recursive verification
> process, should I generate and store the certificate myself, should I
> implement all "by hand" ?
>
> Have a nice weekend. Thanks a lot,
> Matteo
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160923/90add58f/attachment.html>