Alex,
On Nov 12, 2009, at 17:50 , Alexandru Petrescu wrote:
Especially here, where 802.15.4 is cited upfront.
The 6lowpan-nd draft specifically says the link could be 802.15.4 or
any other suitable link.
Well - you're questioning here prior agreements. We did seem to be
in agreement when defining links in 6lowpan, as of April 2009, see
attached email.
We do appreciate all the help you gave to polish our model in April,
thanks for that!
Now you do not like that anymore.
Why?
We have feedback from 6man and the ADs to look at using a similar
model as in autoconf, as the multi-hop subnet model we currently have
is still pretty controversial (although not-quite-as-bad as a multi-
link subnet...). Therefore we are looking at that. Let's see what we
can do with -08. Thanks for your feedback, let's return to that again
after the next revision.
Zach
From: Zach Shelby <[email protected]>
Date: April 25, 2009 16:00:55 GMT+03:00
To: Alexandru Petrescu <[email protected]>
Cc: 6lowpan <[email protected]>
Subject: Re: [6lowpan] link definition of rfc4861 to cover wireless
non-transitive links as well
Hi,
I like this, taking the RFC4861 definition and just adding the
wireless considerations. We should also mention as part of the
wireless links part the following:
- Wireless links considered by 6LoWPAN may not support native
multicast.
- Wireless links are not static, frequent changes are to be expected
because of radio channel fading or node mobility.
This link definition originates from the ND draft, and was just
copied into the other drafts for consistency. I will make a ticket
to update the link definition in nd-03. This was a good solution,
thanks.
- Zach
Alexandru Petrescu wrote:
Previous discussion indicated that link definition of RFC 4861
"Neighbor
Discovery for IPv6" is pertinent to 6LoWPAN. I agree with it and
suggest the following 6LoWPAN definition:
link - a communication facility or medium over which
nodes can communicate at the link layer, i.e.,
the layer immediately below IP (each node can
communicate to each other in this medium).
Examples are Ethernets (simple or bridged), PPP
links, X.25, Frame Relay, wireless links or ATM
networks as well as Internet-layer (or
higher-layer) "tunnels", such as tunnels over
IPv4 or IPv6 itself.
This is a slightly modified definition of the link
defined in RFC4861, in order to cover also the
wireless
links. Wireless links may be non-transitive (node A
communicates at link layer to both B and C yet B
and C
are not on the same link). Hidden terminal problem
in
wireless communications is described in [reference to
individual draft in AUTOCONF]
draft-baccelli-multi-hop-wireless-communication-02
What do people think about using this link definition in 6LoWPAN?
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
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.
--
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
