* 802.15.4G support? @ 2016-02-25 18:22 Remi Philippe 2016-02-28 14:07 ` Alexander Aring 2016-03-01 9:15 ` Stefan Schmidt 0 siblings, 2 replies; 24+ messages in thread From: Remi Philippe @ 2016-02-25 18:22 UTC (permalink / raw) To: linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 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-01 9:15 ` Stefan Schmidt 1 sibling, 2 replies; 24+ messages in thread From: Alexander Aring @ 2016-02-28 14:07 UTC (permalink / raw) To: Remi Philippe; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-02-28 14:07 ` Alexander Aring @ 2016-03-01 9:17 ` Stefan Schmidt 2016-03-03 14:26 ` Michael Richardson 1 sibling, 0 replies; 24+ messages in thread From: Stefan Schmidt @ 2016-03-01 9:17 UTC (permalink / raw) To: Alexander Aring, Remi Philippe; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 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 1 sibling, 1 reply; 24+ messages in thread From: Michael Richardson @ 2016-03-03 14:26 UTC (permalink / raw) To: Alexander Aring; +Cc: Remi Philippe, linux-wpan 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 [ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-03 14:26 ` Michael Richardson @ 2016-03-04 8:35 ` Alexander Aring 2016-03-04 15:52 ` Michael Richardson 0 siblings, 1 reply; 24+ messages in thread From: Alexander Aring @ 2016-03-04 8:35 UTC (permalink / raw) To: Michael Richardson; +Cc: Remi Philippe, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-04 8:35 ` Alexander Aring @ 2016-03-04 15:52 ` Michael Richardson 2016-03-04 16:37 ` Alexander Aring 0 siblings, 1 reply; 24+ messages in thread From: Michael Richardson @ 2016-03-04 15:52 UTC (permalink / raw) To: Alexander Aring; +Cc: Remi Philippe, linux-wpan 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 [ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-04 15:52 ` Michael Richardson @ 2016-03-04 16:37 ` Alexander Aring 2016-03-04 20:16 ` Michael Richardson ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Alexander Aring @ 2016-03-04 16:37 UTC (permalink / raw) To: Michael Richardson; +Cc: Remi Philippe, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-04 16:37 ` Alexander Aring @ 2016-03-04 20:16 ` Michael Richardson 2016-03-14 15:34 ` Stefan Schmidt 2016-03-04 20:30 ` big frame support in 802.15.4G Michael Richardson [not found] ` <CAH+RWqFmxcNxtzTjkcR+Z3dmCdkB5HU-=668rmXMiVaDVZUymg@mail.gmail.com> 2 siblings, 1 reply; 24+ messages in thread From: Michael Richardson @ 2016-03-04 20:16 UTC (permalink / raw) To: Alexander Aring; +Cc: Remi Philippe, linux-wpan 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 [ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-04 20:16 ` Michael Richardson @ 2016-03-14 15:34 ` Stefan Schmidt 2016-03-14 23:11 ` Michael Richardson 0 siblings, 1 reply; 24+ messages in thread From: Stefan Schmidt @ 2016-03-14 15:34 UTC (permalink / raw) To: Michael Richardson, Alexander Aring; +Cc: Remi Philippe, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-14 15:34 ` Stefan Schmidt @ 2016-03-14 23:11 ` Michael Richardson 2016-03-15 5:19 ` Remi Philippe 0 siblings, 1 reply; 24+ messages in thread From: Michael Richardson @ 2016-03-14 23:11 UTC (permalink / raw) To: Stefan Schmidt; +Cc: Alexander Aring, Remi Philippe, linux-wpan [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-14 23:11 ` Michael Richardson @ 2016-03-15 5:19 ` Remi Philippe 2016-03-30 8:54 ` Stefan Schmidt 0 siblings, 1 reply; 24+ messages in thread From: Remi Philippe @ 2016-03-15 5:19 UTC (permalink / raw) To: Michael Richardson; +Cc: Stefan Schmidt, Alexander Aring, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-15 5:19 ` Remi Philippe @ 2016-03-30 8:54 ` Stefan Schmidt 2016-03-30 17:18 ` Remi Philippe 0 siblings, 1 reply; 24+ messages in thread From: Stefan Schmidt @ 2016-03-30 8:54 UTC (permalink / raw) To: Remi Philippe, Michael Richardson; +Cc: Alexander Aring, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-30 8:54 ` Stefan Schmidt @ 2016-03-30 17:18 ` Remi Philippe 2016-03-30 21:00 ` Stefan Schmidt 0 siblings, 1 reply; 24+ messages in thread From: Remi Philippe @ 2016-03-30 17:18 UTC (permalink / raw) To: Stefan Schmidt; +Cc: Michael Richardson, Alexander Aring, linux-wpan 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! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-03-30 17:18 ` Remi Philippe @ 2016-03-30 21:00 ` Stefan Schmidt 0 siblings, 0 replies; 24+ messages in thread From: Stefan Schmidt @ 2016-03-30 21:00 UTC (permalink / raw) To: Remi Philippe; +Cc: Michael Richardson, Alexander Aring, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* big frame support in 802.15.4G 2016-03-04 16:37 ` Alexander Aring 2016-03-04 20:16 ` Michael Richardson @ 2016-03-04 20:30 ` Michael Richardson [not found] ` <56DC2A0A.6070906@htt-consult.com> [not found] ` <CAH+RWqFmxcNxtzTjkcR+Z3dmCdkB5HU-=668rmXMiVaDVZUymg@mail.gmail.com> 2 siblings, 1 reply; 24+ messages in thread From: Michael Richardson @ 2016-03-04 20:30 UTC (permalink / raw) To: 6lo; +Cc: Alexander Aring, linux-wpan [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <56DC2A0A.6070906@htt-consult.com>]
* Re: [6lo] big frame support in 802.15.4G [not found] ` <56DC2A0A.6070906@htt-consult.com> @ 2016-03-07 16:25 ` Michael Richardson 2016-03-07 16:53 ` Don Sturek 0 siblings, 1 reply; 24+ messages in thread From: Michael Richardson @ 2016-03-07 16:25 UTC (permalink / raw) To: Robert Moskowitz; +Cc: 6lo, Alexander Aring, linux-wpan [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6lo] big frame support in 802.15.4G 2016-03-07 16:25 ` [6lo] " Michael Richardson @ 2016-03-07 16:53 ` Don Sturek 2016-03-07 21:06 ` Robert Moskowitz 0 siblings, 1 reply; 24+ messages in thread From: Don Sturek @ 2016-03-07 16:53 UTC (permalink / raw) To: Michael Richardson, Robert Moskowitz; +Cc: Alexander Aring, linux-wpan, 6lo 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6lo] big frame support in 802.15.4G 2016-03-07 16:53 ` Don Sturek @ 2016-03-07 21:06 ` Robert Moskowitz 2016-03-08 8:22 ` Alexander Aring 2016-03-08 14:09 ` Michael Richardson 0 siblings, 2 replies; 24+ messages in thread From: Robert Moskowitz @ 2016-03-07 21:06 UTC (permalink / raw) To: Don Sturek, Michael Richardson; +Cc: Alexander Aring, linux-wpan, 6lo 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 > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6lo] big frame support in 802.15.4G 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:09 ` Michael Richardson 1 sibling, 1 reply; 24+ messages in thread From: Alexander Aring @ 2016-03-08 8:22 UTC (permalink / raw) To: Robert Moskowitz; +Cc: Don Sturek, Michael Richardson, linux-wpan, 6lo 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <CADrU+dKHiNd2xW0Nd=ZWJCAZQ_PbWXwNFo_V2u4nd7A_ccfwCw@mail.gmail.com>]
* Re: [6lo] big frame support in 802.15.4G [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 1 sibling, 0 replies; 24+ messages in thread From: Michael Richardson @ 2016-03-08 14:13 UTC (permalink / raw) To: robert.cragie Cc: Alexander Aring, Robert Moskowitz, linux-wpan, Don Sturek, 6lo@ietf.org 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 [ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6lo] big frame support in 802.15.4G [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 1 sibling, 0 replies; 24+ messages in thread From: Michael Richardson @ 2016-03-08 14:17 UTC (permalink / raw) To: 6lo@ietf.org, robert.cragie Cc: Alexander Aring, Robert Moskowitz, linux-wpan, Don Sturek [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [6lo] big frame support in 802.15.4G 2016-03-07 21:06 ` Robert Moskowitz 2016-03-08 8:22 ` Alexander Aring @ 2016-03-08 14:09 ` Michael Richardson 1 sibling, 0 replies; 24+ messages in thread From: Michael Richardson @ 2016-03-08 14:09 UTC (permalink / raw) To: Robert Moskowitz, Don Sturek; +Cc: Alexander Aring, linux-wpan, 6lo [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <CAH+RWqFmxcNxtzTjkcR+Z3dmCdkB5HU-=668rmXMiVaDVZUymg@mail.gmail.com>]
* Re: 802.15.4G support? [not found] ` <CAH+RWqFmxcNxtzTjkcR+Z3dmCdkB5HU-=668rmXMiVaDVZUymg@mail.gmail.com> @ 2016-03-06 10:17 ` Alexander Aring 0 siblings, 0 replies; 24+ messages in thread From: Alexander Aring @ 2016-03-06 10:17 UTC (permalink / raw) To: Remi Philippe; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 802.15.4G support? 2016-02-25 18:22 802.15.4G support? Remi Philippe 2016-02-28 14:07 ` Alexander Aring @ 2016-03-01 9:15 ` Stefan Schmidt 1 sibling, 0 replies; 24+ messages in thread From: Stefan Schmidt @ 2016-03-01 9:15 UTC (permalink / raw) To: Remi Philippe, linux-wpan 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-03-30 21:00 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.