Alexandru Petrescu wrote:
Zach Shelby a écrit :
Alexandru Petrescu wrote:
Zach Shelby a écrit : [...]
I hear you saying the link-local scope may not cover the entire
link, only the part of it which is fully transitive and reflexive.
It leads me more and more to think a non-transitive
link is actually two links. Each link with its own link-local
scope, each fully transitive and symmetric. (If so, the problem
left is to fit a router with a single interface connecting to two
links simultaneously (the parts of a non-transitive link).)
You can't split this non-transitive link into a clean set of
transitive ones just like that. It doesn't work, especially from the
single-interface router point of view.
A - B - C
A can reach B, B can reach C, but A can't reach C.
B is a LoWPAN Router. From its perspective, its link-local scope
includes both A and C. It does not have two links by any means. It
is forwarding between two nodes on the same link (and in the same
link-local scope) who don't have transitivity between each other (A
and C).
B in LL scopes of both A and C, B has a single interface... could it
be that B forwards a packet from A to C without A hearing it too?
A's link-layer can hear when B forwards the packet (unless it went to
sleep immediately)..
Ok.
Node A receiving its own packet could be easily qualified as noise.
However, as the IP destination is the unicast address of C, the
link-layer destination is the MAC address of C. Thus A's link-layer
will discard it.
Ok when the IP and MAC addresses are not multicast.
When they are, like when A sends an RS to "all-nodes" IP address
(converted into "all-nodes" MAC address) B repeats back this packet to A
(because in the same link-local scope as A), in addition to forwarding
it to C. This could lead to more noise, maybe even an RA generated by A.
Multicast with link-local scope, is simply a link-layer broadcast and is
not retransmitted. So the above does not occur. Thus this kind of
multicast used by RAs and NSs is not a big problem. We should still keep
the frequency of these down.
If you try to do a multicast with scope > 2, then you have a flooding
problem unless multicast is implemented in some other way. This is why
we use the Whiteboard approach in 6lowpan-nd, to avoid the need to flood
the LoWPAN.
Medium access control schemes of wireless link-layers are able to deal
with extra transmissions from multihop forwarding.
I agree MAC schemes could alleviate the B transmits back to A problems.
And these schemes are part (supposedly?) of the Mesh-Under concept.
Which makes think that Route-Over wouldn't work without Mesh-Under at
the same time.
This has nothing to do with mesh-under. Every wireless link-layer
implements medium access control, for example CSMA in the case of IEEE
802.15.4.
Of course because you are forwarding with a single interface, your
channel capacity decreases with more hops (this is the multihop
penalty of all such schemes, including Mesh Under).
Ok.
Otherwise nodes should have a means to know on _which_ link-local
scopes are they, and send data on only one scope. But I think
there's only one link-local address per interface, and only a
scope_id field in the respective C struct.
Not needed, the link-layer deals with this using MAC addressing and
the MAC algorithm. A node just tracks who are its neighbors.
Ok. Some questions rest about how does the link layer deal with
link-layer multicast addresses, when they are used by RS and NS, such
that to avoid noise amplification on non-transitive links.
You use link-local scope and it is not a problem (RS and NS are
link-local messages). You of course want to keep the amount of ND
signaling on a whole as low as possible - which is a goal of 6lowpan-nd.
Alex
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
