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
