From: Michael Richardson <mcr@sandelman.ca>
To: Alexander Aring <alex.aring@gmail.com>
Cc: Remi Philippe <remi@linqio.com>, linux-wpan@vger.kernel.org
Subject: Re: 802.15.4G support?
Date: Fri, 04 Mar 2016 10:52:56 -0500 [thread overview]
Message-ID: <24416.1457106776@obiwan.sandelman.ca> (raw)
In-Reply-To: <20160304083528.GA1525@omega>
Alexander Aring <alex.aring@gmail.com> wrote:
> On Thu, Mar 03, 2016 at 09:26:54AM -0500, Michael Richardson wrote:
>> Alexander Aring <alex.aring@gmail.com> wrote: > You want to run
>> 6LoWPAN on it, current the 802.15.4 calculates a lot of > stuff with
>> the IEEE802154_MTU define, in most cases when using > fragmentation.
>>
>> > It seems you don't need fragmentation in your case, because you
>> reach > the 1280 minimum MTU for IPv6. The condition at [4] should be
>> always > true then.
>>
>> I believe that they do, as 15.4g PHYs can communicate with 15.4 PHYs,
>> and so the fragment on/off/MTU decision will need to be added to the
>> neighbour cache.
> Okay, this really scares me now. You say that the these "SUN PHY's" use
> the same modulation/band/preamble and can probaly talk with all other
> PHY's.
Yes, that's my belief.
Maybe they don't use the same modulation when they send bigger frames, but
they can speak to 15.4-noletter,/15.4e.
(Note: 802.15.4-2015 includes all of e, and I think, all of the g work too,
making it harder to know which is which when speaking)
> That's for me something like a ethernet jumbo frame will talk with
> another ethernet network which doesn't support jumbo frames.
No, that's not the case.
Both Ethernet and 802.15.4 can not send "jumbo" frames to non-jumbo nodes, it
just won't work. They have to send smaller frames.
The ARP and ND process has a way to say what the MTU is.
But, in the 802.15.4 case, the affect is not on the L3 MTU, but the L2 MTU.
> It scares me, because we have still the situation that we can't tell
> much the L2-layer for special things from the neighbor cache. E.g. the
> still important functionality to support short address handling. I
> currently try to solve this and will try to take care for such possible
> future handling.
Yes -- exactly, this is more L2 info needed in the neighbour cache.
>> > Another question would be: You can run 6LoWPAN on it, but nobody >
>> specifies to run 6LoWPAN on such "SUN PHY's". I actually don't see >
>> that. Everything is specified with 127 MTU.
>>
>> > I don't want to tell you cannot run 6LoWPAN on it, but does somebody
>> > need to specify 6LoWPAN for 802.15.4g at first?
>>
>> WiSun alliance did that, I think.
>>
> ok. Then the above situation about handling with "SUN PHYs" and all
> other PHYs need to be specified there, or?
> And another question is: Is that an open standard?
https://www.wi-sun.org/ seems relatively open, it's just 802.15.4g, I think.
And https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/
is mostly about 4g.
> Can it be that there exits a closed 6lowpan standard somehow for a
> specific link-layer? Okay, they probaly use IPHC and fragmentation
> handling of 6LoWPAN but all other parts can be closed then.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
next prev parent reply other threads:[~2016-03-04 15:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 18:22 802.15.4G support? Remi Philippe
2016-02-28 14:07 ` Alexander Aring
2016-03-01 9:17 ` Stefan Schmidt
2016-03-03 14:26 ` Michael Richardson
2016-03-04 8:35 ` Alexander Aring
2016-03-04 15:52 ` Michael Richardson [this message]
2016-03-04 16:37 ` Alexander Aring
2016-03-04 20:16 ` Michael Richardson
2016-03-14 15:34 ` Stefan Schmidt
2016-03-14 23:11 ` Michael Richardson
2016-03-15 5:19 ` Remi Philippe
2016-03-30 8:54 ` Stefan Schmidt
2016-03-30 17:18 ` Remi Philippe
2016-03-30 21:00 ` Stefan Schmidt
2016-03-04 20:30 ` big frame support in 802.15.4G Michael Richardson
[not found] ` <56DC2A0A.6070906@htt-consult.com>
2016-03-07 16:25 ` [6lo] " Michael Richardson
2016-03-07 16:53 ` Don Sturek
2016-03-07 21:06 ` Robert Moskowitz
2016-03-08 8:22 ` Alexander Aring
[not found] ` <CADrU+dKHiNd2xW0Nd=ZWJCAZQ_PbWXwNFo_V2u4nd7A_ccfwCw@mail.gmail.com>
2016-03-08 14:13 ` Michael Richardson
2016-03-08 14:17 ` Michael Richardson
2016-03-08 14:09 ` Michael Richardson
[not found] ` <CAH+RWqFmxcNxtzTjkcR+Z3dmCdkB5HU-=668rmXMiVaDVZUymg@mail.gmail.com>
2016-03-06 10:17 ` 802.15.4G support? Alexander Aring
2016-03-01 9:15 ` Stefan Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24416.1457106776@obiwan.sandelman.ca \
--to=mcr@sandelman.ca \
--cc=alex.aring@gmail.com \
--cc=linux-wpan@vger.kernel.org \
--cc=remi@linqio.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox