[Nfd-dev] [Ndn-interest] NDN link protocol

Dave Oran (oran) oran at cisco.com
Fri Oct 10 08:42:48 PDT 2014


On Oct 10, 2014, at 11:19 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Hi Dave
> 
> The scenario is: switches understand Names, NICs understand Names.
> 
I understand the scenario. I’m pointing out first that it’s highly unrealistic, and second that when you have a big flat L2 waking up all the nodes with multicasts is a very bad idea.

I still argue that we need L3<->L2 binding machinery either built into NDN or in some kind of convergence layer, and that either multicasting everything or re-inventing ARP are poor choices.

For example, I’d think about at least the following:
- use different multicast addresses for Interests and Data
- perhaps partition the multicast space using prefix hashes (analogous to what is done when mapping IP multicast to L2 multicast)
- Record in the PIT the source MAC address of the interest as well as the incoming face. This allows you to make an intelligent decision as to whether to multicast or unicast the data packet based on how many consumers have asked for a given data packet.
- use routing to suppress redundant forwarding of interests received by multiple forwarders on the same LAN. This can be done using designated router techniques as in OSPF/ISIS for IP, or perhaps we can do something cleverer.

And there’s probably a whole lot more, including how to do liveness assessment without relying on Hellos - perhaps we just run BFD.


> When an Interest / Data arrives at a NIC but the host is not listening to this Name prefix, the NIC should drop or NACK the packet, without waking up rest of the PC.
> 
This seems quite unrealistic for a NIC to do.

> We have high-end home routers running NFD. They have enough memory to keep a PIT.
No doubt. 
I’ll grant the home router case. It’s the easy one. Bandwidth is low, node count is low.

> 
> 
> Wireless is a scenario I haven't studied much about. I'll be sure to look up the terms you mentioned.
> 
> Yours, Junxiao
> 
> On Thu, Oct 9, 2014 at 12:38 PM, Dave Oran (oran) <oran at cisco.com> wrote:
> 
> On Oct 8, 2014, at 9:28 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> > Dear folks
> >
> > If a local area network is using regular Ethernet (learn paths from source MAC address) today, self-learning can work on it.
> > Self-learning idea also has been tested on a 16-server fat tree topology.
> >
> > It's not crazy to multicast every packet.
> I beg to differ. Waking up 10,000 hosts on an extended LAN with a data packet when only one of them sent an interest, is, I’m afraid, actually crazy.
> 
> > Switches are expected to understand NDN Names and act as NDN forwarders;
> good luck with that. No switches I’ve met in the last 10 years have enough memory to keep a PIT.
> 
> > at physical layer there's no difference between multicast and unicast.
> >
> Also not true for pt-multipoint radios with hidden terminals.
> Not to mention the rate minimization pathologies of wireless LANs like 802.11.
> 





More information about the Nfd-dev mailing list