[Ndn-interest] Faces and adjacency
Ignacio.Solis at parc.com
Ignacio.Solis at parc.com
Mon Jun 8 12:23:21 PDT 2015
CCNx (1.0) is designed for adjacency.
In old CCN (0.x) (and maybe NDN too if based on the old CCN model), faces
were used for PITs and FIBs. Faces could behave like L2 in many
circumstances, so these were real problems. For example, what is
currently done for multicast faces?
On 6/8/15, 11:53 AM, "Dave Oran (oran)" <oran at cisco.com> wrote:
>Are faces like L2 interfaces, or like routing adjacencies?
>If the former, all the kinds of weirdnesses regarding unsolicited data
>and non-transitivity show up.
>If the latter, you need an adjacency initialization and maintenance
>protocol (which all routing protocols running on multi-access links
>have), but you avoid all the messiness pointed out in this thread.
>My recommendation is that faces behave as adjacencies, not interfaces and
>that we adopt or design a good adjacency management protocol ASAP.
>> On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote:
>> On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet"
>><M.AbdollahiSabet at mail.sbu.ac.ir> wrote:
>>> Actually I'm looking for a chances to have self-learning path feature,
>>>which implies - I guess - receiving data packets on faces which are not
>>>the same faces the interest has been forwarded to, or in better words
>>>the faces which is not in the corresponding FIB entry.
>> Can you describe what you have in mind? I¹m unclear what you mean by
>>self-learning path features with respect to the data objects. I can
>>come up with protocols in my mind but they change the behavior of
>>> I'm not quite aware of those security risks you are talking about, and
>>>I will be grateful If you could enlighten me a bit.
>>> The only point that is in my mind right now is that accepting such
>>>data packets will break fully symmetric subscriber-publisher approach.
>> Well, in a regular Interest->Data exchange allowing "off-path²
>>responses basically means you can have nodes that shouldn¹t have
>>authority in responding to traffic being able to generate responses.
>>This is a waste of resources and a potential denial of service between
>>otherwise cooperating nodes. A node off path can insert data in
>>response to interests that will cause nodes to perform extra work
>>(verifying hashes or signatures, triggering retransmissions, adding
>>exclude filters, etc).
>> You can imagine this gets trickier on multi-access networks.
>>> -----Original Message-----
>>> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com]
>>> Sent: Mon 6/8/2015 10:21 PM
>>> To: shijunxiao at email.arizona.edu
>>> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu
>>> Subject: Re: [Ndn-interest] Data comes from another face?
>>> On 6/8/15, 10:15 AM, "Junxiao Shi"
>>><shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
>>> Sabet's original question is asking whether a Data packet could be
>>>received on a face where an Interest has not been forwarded to, under
>>>normal situations. The question is not about whether such Data packet
>>>should be accepted.
>>> Currently NFD forwarding would accept a Data packet as long as there
>>>is a PIT entry, without considering whether an Interest has been
>>>forwarded to the incoming face.
>>> This behavior is inherited from ccnd 0.7.2, and I know there's a
>>> Good thing we deprecated the old ccnd :-).
>>> I also suspect there would forwarding problems where transmissions on
>>>a multi-access link cannot reach every node.
>>> But I'm unfamiliar with those links, so I can't say exactly what
>>>problem could occur.
>>> Assume a network of: A--B--C--D where nodes can only hear
>>>neighbors. So: A can hear B but not C. B can hear both A+C. C can
>>>hear B+D, D can only hear C. A is a requester, D is a producer. A
>>>wants to get data located at D.
>>> Case 1 - Nodes don't forward interests over the interface they
>>>received them from.
>>> A sends and interest and B gets it. B needs to forward the interest,
>>>but won't do so over the same interface it arrived on. Protocol fails.
>>> Case 2 - Nodes forward interest over interface they received it on +
>>>nodes don't forward objects over same interface
>>> A sends an interest and B gets it. It forwards the interest. Any
>>>node that receives the interest will forward it, flooding the network.
>>>C gets the interest, D gets the interest. D responds. C gets the
>>>reply satisfying the PIT from the interface that requested it. It
>>>assumes somebody else answered. - Protocol fails.
>>> Case 2b - Nodes that receive duplicate interests (same nonce), send
>>>control message to prune
>>> Chaos ensues as networks larger than 3 start pruning each other. A
>>>sends to B. B sends to A+C. C sends to B+D.
>>> B sees same interest from C, sends a prune message to C. C removes pit
>>> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry
>>>again. Protocol fails.
>>> Case 2b.2 - If there is no hold time on the PIT entry, it may get
>>>created again as the interest is still being flooded. Network will
>>>continuously prune and flood, collapsing. - Network fails.
>>> Case 3 - Nodes forward interest over interface they received it on +
>>>nodes forward objects over same interface
>>> Same as Case 2, interest is flooded on the network. and then the data
>>>is flooded on the network.
>>> I'm sure other cases exist.
>>> These errors don't occur if the link/interface/face has other
>>>properties. Like they can all hear each other (though there may are
>>>other issues in this scenario alone), there is an underlying protocol
>>>(like MAC level unicast), next-hops are used instead of
>>> Again, maybe there are NDN features I'm not aware of or forgot. But
>>>either way, it's a good discussion to have. And maybe you can clarify
>>>how NDN handles these cases.
>>> On Mon, Jun 8, 2015 at 9:55 AM,
>>><Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>> wrote:
>>> Hi folks.
>>> I wanted to bring up a couple of important points to this discussion
>>>that have not been mentioned. Maybe people have already assimilated
>>>them so they think they're obvious, but just in case:
>>> 1- A node should not accept data packets over links/interfaces/faces
>>>over which it did not forward an interest. This is a security risk.
>>> 2- NDN may have issues over multiple access links/interfaces/faces
>>>where not all nodes can hear each other (non-infrastructure WiFi).
>>> Both of these are true in the basic case. It's possible that with
>>>extra design, protocols or developments that I'm unaware of these can
>>> Nacho (Ignacio) Solis
>>> Protocol Architect
>>> Principal Scientist
>>> Palo Alto Research Center (PARC)
>>> Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
More information about the Ndn-interest