[Nfd-dev] What is a "region" ?

Burke, Jeff jburke at remap.UCLA.EDU
Wed Feb 24 08:16:47 PST 2016

Thanks for the explanation...!

Let me try a simple explanation:
1/ a LINK is to get an interest to the place where the name in the interest can be used directly for lookup
2/ routers do FIB lookup using LINK first (if interest carries one), until the interest reaches the place (so called "region") where its name is in the FIB, then the router will do look up using the interest name

(Just to double-check - what's the "its" here?)

3/ a router decides whether the LINK has finished its job by comparing LINK with its own name: if the LINK is either its prefix or an exact match to the name, then the LINK is no longer needed.

Not sure I follow – why should the router care whether the LINK name has anything to do with its name, shouldn't it only care if it can forward based on the Interest name or not?  (And, I guess, if it is "responsible" the LINK prefix?)

I think I understand the basic idea but am confused about the introduction of the router's administrative identity into forwarding decisions.  Isn't the point simply that the Interest reaches a router that is 1) sufficiently "responsible" for the LINK prefix that it can ignore it and 2) capable of forwarding the Interest name itself?   I guess this is the point of the regions list – to define responsibility?

(Also, if I am correct, the word 'region' seems to unnecessarily imply a perimeter / geographic boundary rather than a capability.  I wonder if it is the right term.)

To use a specific example:

When an Interest with LINK /com/microsoft/healthvault reaches a router /com/microsoft/routers/us/west/foo/47 at the edge of its AS, that router could have a region entry for "/com/microsoft/healthvault" and directly forward "/org/openmhealth" appropriately.  This doesn't meet the link prefix matching requirement but isn't unreasonable...?  Or am I missing something?

Every entity in an NDN network should know its own name (how it learns the name is design/implementation question).

Yes, but does entity name correspond directly to forwarding responsibility?  (Is this convention or requirement?)


From: Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>>
Date: Tuesday, February 23, 2016 at 3:46 PM
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] What is a "region" ?

we are in group meeting now and explained how LINK (= forwarding hint) works to Zhehao and Haitao. We also trying to figure out a solution to the function you wanted (NDNfit's original design was based on a misconception of LINK).

LINK is a forwarding hint, it just carries an interest to the place where the name in the interest can be used directly for lookup.


On Feb 23, 2016, at 1:24 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what  a "region" is, and how they should be confirmed in practice...

For example, see section 4.2 of the NFD developer's guide.
<Screenshot 2016-02-23 13.18.21.png>

1) What is a region?
2) How should they be configured at each NFD?
3) [And, who is expected to configure them, and when?]


Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160224/7ce5404f/attachment.html>

More information about the Nfd-dev mailing list