All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: Remi Philippe <remi@linqio.com>, linux-wpan@vger.kernel.org
Subject: Re: 802.15.4G support?
Date: Fri, 4 Mar 2016 09:35:33 +0100	[thread overview]
Message-ID: <20160304083528.GA1525@omega> (raw)
In-Reply-To: <28981.1457015214@obiwan.sandelman.ca>

Hi,

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.

That's for me something like a ethernet jumbo frame will talk with
another ethernet network which doesn't support jumbo frames.

(Don't know how they handle the situation then).

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.

>     > 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?

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.

First try with google I didn't find anything.

- Alex

  reply	other threads:[~2016-03-04  8:35 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 [this message]
2016-03-04 15:52       ` Michael Richardson
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=20160304083528.GA1525@omega \
    --to=alex.aring@gmail.com \
    --cc=linux-wpan@vger.kernel.org \
    --cc=mcr@sandelman.ca \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.