Hi Alex, Ah, the fun of Lowpan-ND discussion :)
> WEll - yes for NA, but MLD? I guess ER will _have_ to transmit at least > one MLD message for each lowpan node for which ER joins the > solicited-node IP multicast address. Yes, very true! As well since DAD is done across the backbone, I'm not trying to claim there would be no traffic from each node. Each node will generate a few NS at least... > Here you propose 10000computers proxied on a single interface of that > LAN, i.e. no switch. I am assuming each ER is somewhat dumb, and of limited range. At 2.4 GHz you are talking a few hunded metres, at 900 MHz maybe a km or so. So each ER would only have maybe a hundred nodes. Between ER we are connected by switches etc. > I don't get it: do you say that roughly an ER is ok to send proxy NAs > for 10000 lowpan nodes on a 10mbit Ethernet (just checking I understand > you). No, and that would never happen. The limit on each ER is going to be the 802.15.4 side, both number of nodes joining (see previous), and speed which nodes join. Further if proxy-ND is going on in the router, it will have timers going to keep track of each DAD process. Realistically routers are only going to run so many DAD processes concurrently. So the quick 'how many NS can we do' was just to prove that everything else limits our speed, not ethernet's speed. Also as you can guess I'm not a networking guy per-say, so if that calculation was way off-base let me know ;-) > What are you going to do when a collision is detected? Generate another > short address? Or generate another IP address? Ideally generate a new short address. So a router does the DAD to check if anyone owns the address, if so it gives it to the end node. Otherwise the ER assigns a new address. Which of course brings up an issue: if the first ER has a hundred nodes attached, it will use addresses ::1 - ::100. The second ER will then do DAD on addresses ::1 to ::100 until it find a free address! > I think it is to end up with unique IP addresses, not short addresses > (which are L2). 6lowpan-HC assumes that for best compression IP addresses are based on the L2 address you are using. So if you are using 64-bit addresses, the address is based on that. But if you are using 16-bit addresses, the IPv6 address is based on that + the PANID. For efficiency reasons you want to use 16-bit addresses, as you go from 16 total bytes to 4 total bytes (dest + src). It is up to the PAN coordinator (aka: edge router) to assign short addresses as it sees fit, they are not preset like long ones. To keep everything efficient we want (need) IPv6 addresses based on 802.15.4 short addresses. Hence the ER should assign an end node a short address with the intention that short address results in a unique IPv6 address. > But I agree yes, DNS in the system should be considered. Where is the > DNS server in 6LoWPAN? Has it come up before? Not sure myself! Regards, -Colin -----Original Message----- From: Alexandru Petrescu [mailto:[email protected]] Sent: November 18, 2009 6:58 PM To: Colin O'Flynn Cc: 'Alexandru Petrescu'; 'Carsten Bormann'; 'Pascal Thubert (pthubert)'; 'Ralph Droms (rdroms)'; '6lowpan' Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07 Colin O'Flynn a écrit : > 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. WEll - yes for NA, but MLD? I guess ER will _have_ to transmit at least one MLD message for each lowpan node for which ER joins the solicited-node IP multicast address. > 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. Well, link-layer multicast of Ethernet works good when it has good support in switches. 10000 computers on a LAN are supposedly separated by switches.(I didn't see a cable holding together 10000 computers). Here you propose 10000computers proxied on a single interface of that LAN, i.e. no switch. > 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 don't get it: do you say that roughly an ER is ok to send proxy NAs for 10000 lowpan nodes on a 10mbit Ethernet (just checking I understand you). > 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. BEfore detecting collisions one would make sure the network doesn't helpp them happen. E.g. have different subnets on different lowpan ERs and different prefixes on each lowpan. > 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). Have you thought IPv6 link-local addresses too? I mean to have a lowpan subnet attached to ER1 different than the lowpan subnet of ER2, each with its own distinct link-local scope. > 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. Could the IPv6 address be based on the long version of the L2 address? If not - then you really risk collisions, regardless of them being detected by proxying ERs or by the lowpan nodes themselves. What are you going to do when a collision is detected? Generate another short address? Or generate another IP address? (you==somebody, in general) > 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. I think it is to end up with unique IP addresses, not short addresses (which are L2). What happens when such a duplicate is found - who sees it and who takes what action? > The other option is to have each router on a unique subnet, I believe it makes sense to have each lowpan attached to eah ER constitute a distinct 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. Hmmm... connectivity. Some applications do restart after connectivity is lost and the IP address was changed. > 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. But I agree yes, DNS in the system should be considered. Where is the DNS server in 6LoWPAN? > Sorry if I have misunderstood your e-mail or the point of 6lowpan-ND! This > is how I see it anyway... Sorry, it's fine, for me it's just that I don't see the need for proxy-ND on ER. Thank you for the Atmel explanation. Alex > > -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
