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)..
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. Medium access control schemes of wireless link-layers are
able to deal with extra transmissions from multihop forwarding. 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).
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.
Sorry for insisting on this, it is IMHO. I will agree with the WG further.
No problem, as a WG we needed to re-assure we agree on the terminology.
In fact I think you helped make a big improvement with the link and
LoWPAN IP routing definitions.
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
