Hello, > Are you sure an Ethernet would support > periodic NAs about the potentially very large number of nodes in the > 6LoWPAN network?
>From RFC4861: In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address. These advertisements MUST be separated by at least RetransTimer seconds. Since they are a MAY we could just not transmit any. There probably isn't any advantage to sending them, as I doubt ERs will store a large enough table of previously received NAs, but just do a NS when they need to find something. > Ethernet uses different cables from each machine, through a hub/switch, > etc. which does scales. ND messages would be multicast anyway, so almost everyone would see them through a switch. Hence I don't see the difference between 10000 computers in a local subnet and 10000 sensor nodes in a local subnet. Assume we are at 10Mbits/second on Ethernet, through a hub so everything is broadcast. NS is 24 bytes. Let's add some options to bring it up to 40 bytes. Add IPv6 header for 80 bytes. Add Ethernet header for 96 bytes. Assume some overhead for CRC, retransmission, sync, etc etc, let's say 2x overhead so I can't be accused of underestimating: 192 bytes. 192 bytes = 1536 bits. 10E6 / 1536 = 6510 NS messages/second. Yikes! Sure it's not a good estimate, but it's so far above our requirements I don't see a need to get a better estimate. I'm assuming the proper deployment for a extended LOWPAN network is to put the entire LOWPAN behind a router. The only traffic to worry about is LOWPAN traffic, which would pale in comparison to the traffic generated by even one or two computers, with users watching YouTube and studiously downloading copyrighted material. > it's either to put a route on these towards the prefix valid on the > lowpan network, or to put a default route towards the border router (not > ER) which will subsequently ICMP Redirect to it. This works great for a single router, it's how we are doing it at Atmel. I have a DD-WRT programmed as the default route; it is then programmed with a re-direct to the ER device, works perfect! But a very good reason to do NA/NS is so that when you have two or more edge routers in the same physicalish zone you don't end up with address collisions. Take the following from http://tools.ietf.org/html/draft-ietf-6lowpan-nd-07#page-12 (in case ASCII-art is lost): Infrastructure Cloud | | +-----+ +-----+ | | Router | | Host | | | | +-----+ +-----+ | | | Backbone link | +--------------------+------------------+ | | | +-----+ +-----+ +-----+ | | Edge | | Edge | | Edge | | Router 1 | | Router 2 | | Router 3 +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o Extended LoWPAN There are three edge routers, with a bunch of nodes. Assume that IPv6 addresses of nodes are based on short addresses (aka: L2 address). When the nodes power up, each edge router must assign each one a short address. If IPv6 addresses are to remain based on L2 addresses, each short address across the entire lowpan must be different. Running proxy-ND along the backbone is primarily so that you end up with unique short addresses. Using NA/NS is a very clean way of doing this, each ER can check if the other ER's have assigned an address. The other option is to have each router on a unique subnet, so that each router knows it will not have a global address collision. However when nodes move from router 1 to router 2, they will suddenly need to change IP addresses. If people are using hardcoded IP addresses, this will break connectivity. Maintaining connectivity in the unique-subnet-per-ER case would require DNS servers on the ER, which (1) would increase complexity of ER code, and (2) bring up a whole bunch of other problems with name management. Sorry if I have misunderstood your e-mail or the point of 6lowpan-ND! This is how I see it anyway... -Colin -----Original Message----- From: Alexandru Petrescu [mailto:[email protected]] Sent: November 17, 2009 11:14 PM To: Carsten Bormann Cc: Alexandru Petrescu; Colin O'Flynn; 'Pascal Thubert (pthubert)'; 'Ralph Droms (rdroms)'; '6lowpan' Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07 Carsten Bormann a écrit : > On Nov 17, 2009, at 16:08, Alexandru Petrescu wrote: > >> Is it efficient for the Edge Router to send a myriad of Neighbor >> Advertisement messages (which are addressed to a link-layer >> multicast address, and a L3 multicast address) on the backbone? > > Well, we try to be fully 4861-compliant on the backbone. Sure, that's good. > The backbone is supposed to be an Ethernet or a similar high-capacity > link, so it should have little problem with that load. Hmm... every link has its limit. Are you sure an Ethernet would support periodic NAs about the potentially very large number of nodes in the 6LoWPAN network? Do we have numbers to compare? >> Why cluttering the backbone? > > Because that's what 4861 does to you? :-) :-) well not quite. 4861 does require all nodes physically connected to a link to do this periodic NS/NA but here you require the ER to do the periodic NS/NA on behalf of potentially very large number of nodes which are behind it. Ethernet uses different cables from each machine, through a hub/switch, etc. which does scales. But here we talk ER doing this stuff on a single cable (is it 802.1q btw? how many VLANs on it?) Are we sure it scales? > Of course, the ERs could speak a different protocol between > themselves, Well no need of new protocol, just put the appropriate routes on them. > but the idea was to enable other nodes to live on the backbone link > and communicate with the 6lowpan nodes without requiring any > 6lowpan-specific code. Those other nodes will speak 4861 only. YEs, that's good for backbone nodes to talk to 6LoWPAN nodes through ER, but there are much simpler ways of achieving that, other than proxy-ND: it's either to put a route on these towards the prefix valid on the lowpan network, or to put a default route towards the border router (not ER) which will subsequently ICMP Redirect to it. Now I know that's a long phrase, but it's simple in practice. I can picture it if you wish. Alex _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
