Linux IEEE 802.15.4 and 6LoWPAN development
 help / color / mirror / Atom feed
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    [


  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