802.15.4G support?

802.15.4G support?

[Remi Philippe]

Hello,

We’re currently developing a driver for RF215 (dual radio) using
6lowpan and are nearly done with it. We’ve figured out the current MAC
and PHY are built for 15.4 and not 15.4g which is a blocking point the
sub-ghz module.


It doesn’t look like there is a need for a huge amount of work to get
a basic version of it working (key ones we’ve seen are different MTU
and also some changes in the header like PHR).


Before jumping in coding, is anyone on the list already working on
this? Or has any starting points.


Thanks,

--
Rémi

Re: 802.15.4G support?

[Alexander Aring]

Hi,

On Thu, Feb 25, 2016 at 10:22:45PM +0400, Remi Philippe wrote:
> Hello,
> 
> We’re currently developing a driver for RF215 (dual radio) using
> 6lowpan and are nearly done with it. We’ve figured out the current MAC
> and PHY are built for 15.4 and not 15.4g which is a blocking point the
> sub-ghz module.
> 

ok.

> 
> It doesn’t look like there is a need for a huge amount of work to get
> a basic version of it working (key ones we’ve seen are different MTU
> and also some changes in the header like PHR).
> 

I took a look into 802.15.4g and you probaly mean with different MTU:

aMaxPHYPacketSize:

	2047 for SUN PHYs
	127 for all other PHYs

So we working currently with "127" for aMaxPHYPacketSize. In your case you
will have "2047".


Current issue is:

We don't handle this parameter as a variable, it's a define see [0]. :-)
I am fine to change it as variable declaration into PIB [1], then add a
new PHY FLAG [2] for such "SUN PHY's", while registering [3] the phy, it will
update specific constants for such phy's e.g. aMaxPHYPacketSize.


6LoWPAN:

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.

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?

> 
> Before jumping in coding, is anyone on the list already working on
> this? Or has any starting points.
> 
> 

I describe one point above for handling different MTU size. I don't know
if somebody already working on 802.15.4g support.

- Alex

[0] http://lxr.free-electrons.com/source/include/linux/ieee802154.h#L29
[1] http://lxr.free-electrons.com/source/include/net/cfg802154.h#L184
[2] http://lxr.free-electrons.com/source/include/net/mac802154.h#L127
[3] http://lxr.free-electrons.com/source/net/mac802154/main.c#L150
[4] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/tx.c#L285

Re: 802.15.4G support?

[Stefan Schmidt]

Hello.

On 25/02/16 19:22, Remi Philippe wrote:
> Hello,
>
> We’re currently developing a driver for RF215 (dual radio) using

You mean the at86rf215 here, right?
http://www.atmel.com/images/atmel-42415-wireless-at86rf215_datasheet.pdf

> 6lowpan and are nearly done with it.

Great. I hope you plan to send it for mainline inclusion. Is is a 
complete new driver or did you work on extending the at86rf2xx driver to 
support this chip?

> We’ve figured out the current MAC
> and PHY are built for 15.4 and not 15.4g which is a blocking point the
> sub-ghz module.

That is correct. So far nobody did any work on supporting 15.4g  and to 
answer the question from below I also do not know anyone actually 
working on it. So you could jump to the coding. :)
>
>
> It doesn’t look like there is a need for a huge amount of work to get
> a basic version of it working (key ones we’ve seen are different MTU
> and also some changes in the header like PHR).

Alex already gave you some hints about handling the different MTU size 
for SUN phys. The sub GHz frequency bands and channel setting should 
already be covered in the kernel and wpan-tools. We might miss some 
corner cases as Alex and myself do not have sub GHz hardware but they 
should not be that hard to handle.

Can you elaborate on the problem with the PHR header?

For the chip with two phy I expect you will just expose two different 
phy's and we need no special handling for it. Are there any limitation 
on the chip side like a shared frame buffer or regs which might extra 
logic in the core?

Are there any other MAC related changes in 15.4g? I briefly looked at it 
but the abstract of changes has been very vague ("In addition to the
new PHYs, the amendment also defines those MAC modifications needed to 
support their implementation.") and reading the whole 252 pages was to 
much for this morning. :)

>
> Before jumping in coding, is anyone on the list already working on
> this? Or has any starting points.

Its an area nobody is working on as far as we now. Be our guest here. We 
are happy to review patches for it.
Btw, do you happen to know if 15.4g was merged into 2015 edition of the 
main 15.4 spec or is it still a separate spec?

regards
Stefan Schmidt

Re: 802.15.4G support?

[Stefan Schmidt]

Hello.

On 28/02/16 15:07, Alexander Aring wrote:
> 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?
>

I would expect that for SUN phy's they would just ignore the 
fragmentation part of the spec and use all the rest of it. Still making 
use of the header compressions, subtyping, etc. Remi, please correct me 
if I'm wrong here.

regards
Stefan Schmidt

Re: 802.15.4G support?

[Michael Richardson]

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.

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

--
]               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    [

Re: 802.15.4G support?

[Alexander Aring]

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

Re: 802.15.4G support?

[Michael Richardson]

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    [

Re: 802.15.4G support?

[Alexander Aring]

On Fri, Mar 04, 2016 at 10:52:56AM -0500, Michael Richardson wrote:
> 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)
> 

ok.

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

ok.

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

Yes, sir. :-)

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

Okay. I think at first normal 127-bytes frames need to be send. After if
you are sure that your "neighbor" uses a "SUN Phy" then you need to
change the MTU (during runtime) for this special neighbor so a different
handling can be done.

Depends if you really want such handling as default behaviour.

Something like that, but I am not sure how it really would working and
don't know how the "indentification it's a SUN Phy or not will work",
the MAC frame format has some extensions with "capabilities" maybe
somehow while parsing mac frame in L2 which indicates the transmitted
node as a "SUN Phy".

Maybe there exists also a L3 mechanism to indicate a "SUN Phy", e.g.
an Option-Field. (I would more like such handling than that the L2 header
indicates it somehow). I suppose the right website to lookup such thing
is [0], but didn't find anything related to that.

(about fragmentation handling for 4g):
The [1] say something about that fragmentation/reassembly is not
necessary when using 2048 frames. :-)

- Alex

[0] https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml#icmpv6-parameters-5
[1] https://tools.ietf.org/html/draft-ietf-roll-applicability-ami-11#section-7.2.2

Re: 802.15.4G support?

[Michael Richardson]

Alexander Aring <alex.aring@gmail.com> wrote:
    > Okay. I think at first normal 127-bytes frames need to be send. After
    > if you are sure that your "neighbor" uses a "SUN Phy" then you need to
    > change the MTU (during runtime) for this special neighbor so a
    > different handling can be done.

Exactly... ND messages fit nicely in 127 bytes, and so the reply could
say something.

--
]               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    [

big frame support in 802.15.4G

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]


Can 802.15.4g with 2048 byte frames exist in an LLN along with nodes using
802.15.4-2012 classic 127 byte frames?

There are three questions embedded here:
1) are there radios issues that would prevent this from ever being an issue?

2) assuming that 15.4g radios can communicate with 15.4 radios, is there
   something that would permit one 15.4g radio to realize it was talking
   to another 15.4g radio at the L2 (frame) level?

3) if the answer to #2 is no, then is this akin to ethernet with jumbo
   frames, where the MTU (and fraglettation method) to each destination needs
   to go into the neighbour cache?

RFC4681 section 4.6.4 specifies an MTU value for the network as a whole
        in the RA.  https://tools.ietf.org/html/rfc4861#section-4.6.4

I thought that I'd see an option to put the MTU into the NA as well, but
I don't see that specified, so how can jumbo ethernet work today?
(maybe that's why it isn't on by default more often...)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]

Re: 802.15.4G support?

[Alexander Aring]

Hi,

please cc linux-wpan mailinglist.

On Sun, Mar 06, 2016 at 09:32:50AM +0400, Remi Philippe wrote:
> On Fri, Mar 4, 2016 at 8:37 PM, Alexander Aring <alex.aring@gmail.com> wrote:
> > On Fri, Mar 04, 2016 at 10:52:56AM -0500, Michael Richardson wrote:
> >> 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)
> >>
> >
> > ok.
> 
> 
> I believe modulation is always different, from the 802.15.4-2011 spec
> the supported modulations are : O-QPSK, BPSK, ASK, CSS, UWB, MPSK and
> GFSK while for 802.15.4g-2012 they are: MR-FSK, MR-OFDM and MR-O-QPSK.
> From the chips datasheet, they only support a subset for 15.4 / 15.4g,
> for example AT86RF215 only supports MR-FSK, MR-O-QPSK and O-QPSK.
> 
> Maybe I'm missing something but I wouldn't expect to chip to process
> frames for a modulation it's not configured on.
> 

Looking again into 802.15.4g-2012 there stands on page (not pdf page)
95:

"For the 780 MHz, 915 MHz, and 2450 MHz frequency bands, the MR-O-QPSK
 PHY supports communication with legacy devices according to the
 specifications in Clause 10, as described in 18.3.3."

so somewhat with "Clause 10" and at 18.3.3 the standard says:

"18.3.3 Support of legacy devices of the 780 MHz, 915 MHz, and 2450 MHz
 O-QPSK PHYs" ... the lot of copy&pasting witht the same sentences but
 different frequencies. :-)

Then looking into 802.15.4-2011 for Clause 10, the standard says:

"10. O-QPSK PHY"

so Clause 10, they mean all other PHYs. For me it looks like it is
possible to communicate with "legacy device according to the
specifications in Clause 10".

MR-O-QPSK is compatible with O-QPSK.

So the question is also when using the other modulations. At first for
supporting also the "legacy device" it should be O-QPSK. But then there
is some mechanism and the neighbor need to know "it supports these
modulations and this MTU".

> >
> >>     >> > 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.
> >>
> >
> > Okay. I think at first normal 127-bytes frames need to be send. After if
> > you are sure that your "neighbor" uses a "SUN Phy" then you need to
> > change the MTU (during runtime) for this special neighbor so a different
> > handling can be done.
> >
> > Depends if you really want such handling as default behaviour.
> >
> > Something like that, but I am not sure how it really would working and
> > don't know how the "indentification it's a SUN Phy or not will work",
> > the MAC frame format has some extensions with "capabilities" maybe
> > somehow while parsing mac frame in L2 which indicates the transmitted
> > node as a "SUN Phy".
> >
> > Maybe there exists also a L3 mechanism to indicate a "SUN Phy", e.g.
> > an Option-Field. (I would more like such handling than that the L2 header
> > indicates it somehow). I suppose the right website to lookup such thing
> > is [0], but didn't find anything related to that.
> >
> > (about fragmentation handling for 4g):
> > The [1] say something about that fragmentation/reassembly is not
> > necessary when using 2048 frames. :-)
> >
> 
> Nivis (http://www.nivis.com/) is using 6loWPAN on 802.15.4g for
> example (apparently on a Linux 3.2 kernel if I believe the specs)
> 

Okay, maybe they don't use the 6LoWPAN/802.15.4 Implementation of the
Linux-Kernel.

Maybe they do the SLIP way and the external device with firmware do the
6LoWPAN adapation. Look at my slides [0] to understand the difference.
Slides 11-12.

I can't see it at layer-graphic [1] and board graphic [2].

They write that they using linux, maybe ask for the kernel sources?

- Alex

[0] http://www.netdevconf.org/1.1/proceedings/slides/aring-generic-6lowpan-branch.pdf
[1] http://www.nivis.com/resources/Smart%20Object%20Solution%20Brief.pdf
[2] http://www.nivis.com/products/images/products/VR1100/IMG_4450.jpg

Re: [6lo] big frame support in 802.15.4G

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]


Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
    > The difference is in the header bits. A 802.15.4-2011 device would see
    > the bits set in the header that 4g uses and drop the packet
    > immediately. Pat would have to pipe in here, and there may be some
    > issues around super frames and intergap timings that result in
    > interesting behaviour, better to be avoided.

Right, but the question is:

1) is it physically possible for a 15.4g device to send both 15.4g
   frames and 15.4-2011 frames?
   Another email suggests that this can never happen because frequencies
   are never the same.  If so, end of problem.

2) if the answer to question 1 is yes, then 15.4g devices need to know
   if they are speaking to 15.4-2011 devices, and
      a) adjust their frame header bits appropriately.
      b) to 6lowpan fraglettation.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]

Re: [6lo] big frame support in 802.15.4G

[Don Sturek]

Hi Michael,

I was not clear on what you were asking.  Here are a couple of points:
1)  IEEE 802.15.4g was an amendment to IEEE 802.15.4-2011 where the main
contributions were to the PHY (not so much the MAC).   There is nothing in
4g that would make it incompatible with IEEE 802.15.4-2011
2)  IEEE 802.15.4-2011 has a field called "frame version" that denotes
special processing for the 2003, 2006 and 2011 versions of the
specification.  That is one place where a packet may be dropped but that
would not apply to MAC versions that are based on 2011 alone
3)  If you were asking whether a 4g MAC/PHY implementation could send
payloads of varying sizes then I think the answer is "yes" with the
following caveats:
      I.     Since IEEE 802.15.4 never had a propoer protocol dispatch
until IEEE 802.15.9 came along, there would have to be some special vendor
extensions to denote where a full IPv6 frame was present or when a 6LoWPAN
fragment was present.  It is possible with the Multiplex ID/EtherType in
IEEE 802.15.9 to make that distinction.

I think in some implementations you would see a varying payload size.  For
example, when transferring packets over a good radio link, the payload
size might be set to 1280 bytes or better and a full IPv6 frame would be
present.  In cases where the link is poor, the two communicating devices
may choose to use shorter packets and 6LoWPAN to fragment/reassemble,
however, keep in mind there are only MAC retries to ensure delivery.

Don




On 3/7/16 8:25 AM, "6lo on behalf of Michael Richardson"
<6lo-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:

>
>Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
>    > The difference is in the header bits. A 802.15.4-2011 device would
>see
>    > the bits set in the header that 4g uses and drop the packet
>    > immediately. Pat would have to pipe in here, and there may be some
>    > issues around super frames and intergap timings that result in
>    > interesting behaviour, better to be avoided.
>
>Right, but the question is:
>
>1) is it physically possible for a 15.4g device to send both 15.4g
>   frames and 15.4-2011 frames?
>   Another email suggests that this can never happen because frequencies
>   are never the same.  If so, end of problem.
>
>2) if the answer to question 1 is yes, then 15.4g devices need to know
>   if they are speaking to 15.4-2011 devices, and
>      a) adjust their frame header bits appropriately.
>      b) to 6lowpan fraglettation.
>
>
>--
>Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
>_______________________________________________
>6lo mailing list
>6lo@ietf.org
>https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] big frame support in 802.15.4G

[Robert Moskowitz]

I was thinking that there is also some difference in the physical header 
to support the larger PPU?

On 03/07/2016 11:53 AM, Don Sturek wrote:
> Hi Michael,
>
> I was not clear on what you were asking.  Here are a couple of points:
> 1)  IEEE 802.15.4g was an amendment to IEEE 802.15.4-2011 where the main
> contributions were to the PHY (not so much the MAC).   There is nothing in
> 4g that would make it incompatible with IEEE 802.15.4-2011
> 2)  IEEE 802.15.4-2011 has a field called "frame version" that denotes
> special processing for the 2003, 2006 and 2011 versions of the
> specification.  That is one place where a packet may be dropped but that
> would not apply to MAC versions that are based on 2011 alone
> 3)  If you were asking whether a 4g MAC/PHY implementation could send
> payloads of varying sizes then I think the answer is "yes" with the
> following caveats:
>        I.     Since IEEE 802.15.4 never had a propoer protocol dispatch
> until IEEE 802.15.9 came along, there would have to be some special vendor
> extensions to denote where a full IPv6 frame was present or when a 6LoWPAN
> fragment was present.  It is possible with the Multiplex ID/EtherType in
> IEEE 802.15.9 to make that distinction.
>
> I think in some implementations you would see a varying payload size.  For
> example, when transferring packets over a good radio link, the payload
> size might be set to 1280 bytes or better and a full IPv6 frame would be
> present.  In cases where the link is poor, the two communicating devices
> may choose to use shorter packets and 6LoWPAN to fragment/reassemble,
> however, keep in mind there are only MAC retries to ensure delivery.
>
> Don
>
>
>
>
> On 3/7/16 8:25 AM, "6lo on behalf of Michael Richardson"
> <6lo-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
>
>> Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
>>     > The difference is in the header bits. A 802.15.4-2011 device would
>> see
>>     > the bits set in the header that 4g uses and drop the packet
>>     > immediately. Pat would have to pipe in here, and there may be some
>>     > issues around super frames and intergap timings that result in
>>     > interesting behaviour, better to be avoided.
>>
>> Right, but the question is:
>>
>> 1) is it physically possible for a 15.4g device to send both 15.4g
>>    frames and 15.4-2011 frames?
>>    Another email suggests that this can never happen because frequencies
>>    are never the same.  If so, end of problem.
>>
>> 2) if the answer to question 1 is yes, then 15.4g devices need to know
>>    if they are speaking to 15.4-2011 devices, and
>>       a) adjust their frame header bits appropriately.
>>       b) to 6lowpan fraglettation.
>>
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>

Re: [6lo] big frame support in 802.15.4G

[Alexander Aring]

Hi,

On Mon, Mar 07, 2016 at 04:06:32PM -0500, Robert Moskowitz wrote:
> I was thinking that there is also some difference in the physical header to
> support the larger PPU?
> 

I copy&paste here some parts which I already wrote in another mailing
thread:

---
Looking again into 802.15.4g-2012 there stands on page (not pdf page)
95:

"For the 780 MHz, 915 MHz, and 2450 MHz frequency bands, the MR-O-QPSK
 PHY supports communication with legacy devices according to the
 specifications in Clause 10, as described in 18.3.3."

so somewhat with "Clause 10" and at 18.3.3 the standard says:

"18.3.3 Support of legacy devices of the 780 MHz, 915 MHz, and 2450 MHz
 O-QPSK PHYs" ... the lot of copy&pasting witht the same sentences but
 different frequencies. :-)

Then looking into 802.15.4-2011 for Clause 10, the standard says:

"10. O-QPSK PHY"

so Clause 10, they mean all other PHYs. For me it looks like it is
possible to communicate with "legacy device according to the
specifications in Clause 10".
---

That means for me:

MR-O-QPSK is compatible with O-QPSK.

The question which follows is:
How 6LoWPAN for 802.15.4g devices deals with 802.15.4g and 802.15.4-2011
(legacy devices) in one 6LoWPAN network, if this handling is supported
somehow?

Is there some mechanism on for getting the capabilities "MTU" and
Modulation for each neighbor?

Then you could start always with a O-QPSK modulation and 127 bytes MTU,
if you know your 6LoWPAN network is a complete 802.15.4g only network,
then simple use 802.15.4g features.

If not: exist there some mechanism (Option-Field in NA) to see, this
neighbor is a SUN Phy and I could change the MTU/modulation for this
neighbor.

btw: for broadcast frames you should need then 127 bytes and O-QPSK
only.

- Alex

Re: [6lo] big frame support in 802.15.4G

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]


Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
    > I was thinking that there is also some difference in the physical
    > header to support the larger PPU?

Yeah, but you guys seem to be stuck thinking about whether 802.15.4-2011
PHYs/MACs would be able to receive 15.4g packets.

That's not the question.

The question is again:

    > 1) is it physically possible for a 15.4g device to send both 15.4g
    > frames and 15.4-2011 frames?  Another email suggests that this can
    > never happen because frequencies are never the same.  If so, end of
    > problem.

    > 2) if the answer to question 1 is yes, then 15.4g devices need to
    > know if they are speaking to 15.4-2011 devices, and a) adjust their
    > frame header bits appropriately.  b) to 6lowpan fraglettation.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]

Re: [6lo] big frame support in 802.15.4G

[Michael Richardson]

Robert Cragie <robert.cragie@gridmerge.com> wrote:
    > I don't know the word "fraglettation"; I assume this is the same as
    > "fragmentation"? The device would need to invoke 6LoWPAN fragmentation
    > if the target device is a legacy device and the IPv6 frame is too large
    > to fit into the MSDU.

I thought that 6lowpan adopted the term "fraglet" to mean fragmentation below
IPv6, such that the term "fragment" could continue to refer to what happens
above IPv6 using the Fragmentation Header.

I see that I've mis-reremembered, and the term became "link fragment".

--
]               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    [

Re: [6lo] big frame support in 802.15.4G

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]


Robert Cragie <robert.cragie@gridmerge.com> wrote:
    > 1) is it physically possible for a 15.4g device to send both 15.4g
    > frames and 15.4-2011 frames?

    > Yes, in theory. The PHY would have to support both the SUN-O-QPSK and
    > the O-QPSK PHYs, the intersecting frequencies, rates and spreading mode
    > and somehow be selectable on Tx and discriminate on Rx (accept both
    > PPDU formats)

Thank you for this answer.

Alex is trying to make the lowpan code for the Linux kernel more flexible,
and the question of whether we need to include a way to use different MTUs on
a per-destination basis has come up, and we had no clear answer.

We now know that this is physically possible; we don't know if chipsets will
implement this, or whether it SHOULD be possible.

This is now a technical policy question for 6lo, in my opinion.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]

Re: 802.15.4G support?

[Stefan Schmidt]

Hello.

Having read through the mail threads on linux-wpan and ietf 6lo now.

On 04/03/16 21:16, Michael Richardson wrote:
> Alexander Aring <alex.aring@gmail.com> wrote:
>      > Okay. I think at first normal 127-bytes frames need to be send. After
>      > if you are sure that your "neighbor" uses a "SUN Phy" then you need to
>      > change the MTU (during runtime) for this special neighbor so a
>      > different handling can be done.
>
> Exactly... ND messages fit nicely in 127 bytes, and so the reply could
> say something.
>

That would be a way to tackle this mid term, agreed.

 From my sidem and with my linux hat on, this loks like the following.

1) 802.15.4 nodes can talk to 802.15.4g nodes on a physical level (it 
needs selection of the right modulation, frequency range, overlapping 
channels, etc) but it can happen and thus we need to be prepared for it.

2) If the 802.15.4g node uses a SUN PHY with a 2047 byte MTU we can run 
into trouble with normal nodes only able to handle 127. So far there is 
nothing specified to handle this case. Michael is proposing to use 6lo 
ND for this and record the MTU value for this neighbour in the l2 nd 
cache. Something that would certainly work but would need specing and 
implementing. I see this as a mid term goal we want to have. Anyone 
going to work on this?

3) Until 2) is done I would suggest we add a config option "802.15.4g 
with SUN PHY" which will change the hardcoded MTU from 127 to 2047 and 
will thus only work for a 15.g with SUN PHY only network. No interop as 
we have no way of knowing. The option would be disabled by default and 
the help text needs to mention the drawbacks. Once we have 2) in place 
we can remove this.

Remis, Alex, Michael how does this sound. It would allow Remi to go 
ahead and do the work needed to get his driver and things for 15.4g 
mainline while the interop problem can get further discussed, speced and 
implemented. Whats your folks opinion on this?

regards
Stefan Schmidt

Re: 802.15.4G support?

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]


Stefan Schmidt <stefan@osg.samsung.com> wrote:
    > 2) If the 802.15.4g node uses a SUN PHY with a 2047 byte MTU we can run into
    > trouble with normal nodes only able to handle 127. So far there is nothing
    > specified to handle this case. Michael is proposing to use 6lo ND for this
    > and record the MTU value for this neighbour in the l2 nd cache. Something
    > that would certainly work but would need specing and implementing. I see this
    > as a mid term goal we want to have. Anyone going to work on this?

It's not even clear to me that ND can do this.
I still propose that we want to have a space in the l2 or l3 ND cache for
this info.  It could well go in the L3 cache because it is really a statement
about how the 6lowpan layer should fragment.

    > 3) Until 2) is done I would suggest we add a config option "802.15.4g with
    > SUN PHY" which will change the hardcoded MTU from 127 to 2047 and will thus
    > only work for a 15.g with SUN PHY only network. No interop as we have no way
    > of knowing. The option would be disabled by default and the help text needs
    > to mention the drawbacks. Once we have 2) in place we can remove this.

Couldn't we use "ifconfig blah0 mtu 2047"?

    > Remis, Alex, Michael how does this sound. It would allow Remi to go ahead and
    > do the work needed to get his driver and things for 15.4g mainline while the
    > interop problem can get further discussed, speced and implemented. Whats your
    > folks opinion on this?



--
]               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    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]

Re: 802.15.4G support?

[Remi Philippe]

On Tue, Mar 15, 2016 at 3:11 AM, Michael Richardson <mcr@sandelman.ca> wrote:
>
> Stefan Schmidt <stefan@osg.samsung.com> wrote:
>     > 2) If the 802.15.4g node uses a SUN PHY with a 2047 byte MTU we can run into
>     > trouble with normal nodes only able to handle 127. So far there is nothing
>     > specified to handle this case. Michael is proposing to use 6lo ND for this
>     > and record the MTU value for this neighbour in the l2 nd cache. Something
>     > that would certainly work but would need specing and implementing. I see this
>     > as a mid term goal we want to have. Anyone going to work on this?
>
> It's not even clear to me that ND can do this.
> I still propose that we want to have a space in the l2 or l3 ND cache for
> this info.  It could well go in the L3 cache because it is really a statement
> about how the 6lowpan layer should fragment.
>
>     > 3) Until 2) is done I would suggest we add a config option "802.15.4g with
>     > SUN PHY" which will change the hardcoded MTU from 127 to 2047 and will thus
>     > only work for a 15.g with SUN PHY only network. No interop as we have no way
>     > of knowing. The option would be disabled by default and the help text needs
>     > to mention the drawbacks. Once we have 2) in place we can remove this.
>
> Couldn't we use "ifconfig blah0 mtu 2047"?

Maybe we should do both, have a flag to specify the PHY type as the
PHY header is slightly different in15.4g MR-FSK to support for mode
switch, data whitening... it needs to support 2 octets header (page 52
of the 802.15.4g-2012 spec) it can also lock the max MTU supported for
the media. And allow to change the MTU from command line.

>
>     > Remis, Alex, Michael how does this sound. It would allow Remi to go ahead and
>     > do the work needed to get his driver and things for 15.4g mainline while the
>     > interop problem can get further discussed, speced and implemented. Whats your
>     > folks opinion on this?
>
>
>
> --
> ]               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    [
>



-- 
Rémi Philippe - CTO
Linqio

Re: 802.15.4G support?

[Stefan Schmidt]

Hello.

On 15/03/16 06:19, Remi Philippe wrote:
> On Tue, Mar 15, 2016 at 3:11 AM, Michael Richardson <mcr@sandelman.ca> wrote:
>> Stefan Schmidt <stefan@osg.samsung.com> wrote:
>>      > 2) If the 802.15.4g node uses a SUN PHY with a 2047 byte MTU we can run into
>>      > trouble with normal nodes only able to handle 127. So far there is nothing
>>      > specified to handle this case. Michael is proposing to use 6lo ND for this
>>      > and record the MTU value for this neighbour in the l2 nd cache. Something
>>      > that would certainly work but would need specing and implementing. I see this
>>      > as a mid term goal we want to have. Anyone going to work on this?
>>
>> It's not even clear to me that ND can do this.
>> I still propose that we want to have a space in the l2 or l3 ND cache for
>> this info.  It could well go in the L3 cache because it is really a statement
>> about how the 6lowpan layer should fragment.
>>
>>      > 3) Until 2) is done I would suggest we add a config option "802.15.4g with
>>      > SUN PHY" which will change the hardcoded MTU from 127 to 2047 and will thus
>>      > only work for a 15.g with SUN PHY only network. No interop as we have no way
>>      > of knowing. The option would be disabled by default and the help text needs
>>      > to mention the drawbacks. Once we have 2) in place we can remove this.
>>
>> Couldn't we use "ifconfig blah0 mtu 2047"?
> Maybe we should do both, have a flag to specify the PHY type as the
> PHY header is slightly different in15.4g MR-FSK to support for mode
> switch, data whitening... it needs to support 2 octets header (page 52
> of the 802.15.4g-2012 spec) it can also lock the max MTU supported for
> the media. And allow to change the MTU from command line.
>

Did you move on with this? If you ahve any patches let us know. We are 
happily going to review them.

regards
Stefan Schmidt

Re: 802.15.4G support?

[Remi Philippe]

On Wed, Mar 30, 2016 at 12:54 PM, Stefan Schmidt <stefan@osg.samsung.com> wrote:
> Hello.
>
> On 15/03/16 06:19, Remi Philippe wrote:
>>
>> On Tue, Mar 15, 2016 at 3:11 AM, Michael Richardson <mcr@sandelman.ca>
>> wrote:
>>>
>>> Stefan Schmidt <stefan@osg.samsung.com> wrote:
>>>      > 2) If the 802.15.4g node uses a SUN PHY with a 2047 byte MTU we
>>> can run into
>>>      > trouble with normal nodes only able to handle 127. So far there is
>>> nothing
>>>      > specified to handle this case. Michael is proposing to use 6lo ND
>>> for this
>>>      > and record the MTU value for this neighbour in the l2 nd cache.
>>> Something
>>>      > that would certainly work but would need specing and implementing.
>>> I see this
>>>      > as a mid term goal we want to have. Anyone going to work on this?
>>>
>>> It's not even clear to me that ND can do this.
>>> I still propose that we want to have a space in the l2 or l3 ND cache for
>>> this info.  It could well go in the L3 cache because it is really a
>>> statement
>>> about how the 6lowpan layer should fragment.
>>>
>>>      > 3) Until 2) is done I would suggest we add a config option
>>> "802.15.4g with
>>>      > SUN PHY" which will change the hardcoded MTU from 127 to 2047 and
>>> will thus
>>>      > only work for a 15.g with SUN PHY only network. No interop as we
>>> have no way
>>>      > of knowing. The option would be disabled by default and the help
>>> text needs
>>>      > to mention the drawbacks. Once we have 2) in place we can remove
>>> this.
>>>
>>> Couldn't we use "ifconfig blah0 mtu 2047"?
>>
>> Maybe we should do both, have a flag to specify the PHY type as the
>> PHY header is slightly different in15.4g MR-FSK to support for mode
>> switch, data whitening... it needs to support 2 octets header (page 52
>> of the 802.15.4g-2012 spec) it can also lock the max MTU supported for
>> the media. And allow to change the MTU from command line.
>>
>
> Did you move on with this? If you ahve any patches let us know. We are
> happily going to review them.
>
> regards
> Stefan Schmidt

We're still fixing some issues on the AT86RF215 (some timing issues
and bit swapping), then we'll go for the configurable MTU and then
look into the 15.4G. So work in progress, we'll send the patches once
we have something stable!

Re: 802.15.4G support?

[Stefan Schmidt]

Hello.

On 30/03/16 19:18, Remi Philippe wrote:
> On Wed, Mar 30, 2016 at 12:54 PM, Stefan Schmidt <stefan@osg.samsung.com> wrote:
>> Hello.
>>
>> On 15/03/16 06:19, Remi Philippe wrote:
>>> On Tue, Mar 15, 2016 at 3:11 AM, Michael Richardson <mcr@sandelman.ca>
>>> wrote:
>>>> Stefan Schmidt <stefan@osg.samsung.com> wrote:
>>>>       > 2) If the 802.15.4g node uses a SUN PHY with a 2047 byte MTU we
>>>> can run into
>>>>       > trouble with normal nodes only able to handle 127. So far there is
>>>> nothing
>>>>       > specified to handle this case. Michael is proposing to use 6lo ND
>>>> for this
>>>>       > and record the MTU value for this neighbour in the l2 nd cache.
>>>> Something
>>>>       > that would certainly work but would need specing and implementing.
>>>> I see this
>>>>       > as a mid term goal we want to have. Anyone going to work on this?
>>>>
>>>> It's not even clear to me that ND can do this.
>>>> I still propose that we want to have a space in the l2 or l3 ND cache for
>>>> this info.  It could well go in the L3 cache because it is really a
>>>> statement
>>>> about how the 6lowpan layer should fragment.
>>>>
>>>>       > 3) Until 2) is done I would suggest we add a config option
>>>> "802.15.4g with
>>>>       > SUN PHY" which will change the hardcoded MTU from 127 to 2047 and
>>>> will thus
>>>>       > only work for a 15.g with SUN PHY only network. No interop as we
>>>> have no way
>>>>       > of knowing. The option would be disabled by default and the help
>>>> text needs
>>>>       > to mention the drawbacks. Once we have 2) in place we can remove
>>>> this.
>>>>
>>>> Couldn't we use "ifconfig blah0 mtu 2047"?
>>> Maybe we should do both, have a flag to specify the PHY type as the
>>> PHY header is slightly different in15.4g MR-FSK to support for mode
>>> switch, data whitening... it needs to support 2 octets header (page 52
>>> of the 802.15.4g-2012 spec) it can also lock the max MTU supported for
>>> the media. And allow to change the MTU from command line.
>>>
>> Did you move on with this? If you ahve any patches let us know. We are
>> happily going to review them.
>>
>> regards
>> Stefan Schmidt
> We're still fixing some issues on the AT86RF215 (some timing issues
> and bit swapping), then we'll go for the configurable MTU and then
> look into the 15.4G. So work in progress, we'll send the patches once
> we have something stable!

OK, cool, so its being worked on. Was just going through my pending 
mails and wanted to see if there was anything blocking you from our side. :)

regards
Stefan Schmidt