please help me to integrate RPL in kernel

please help me to integrate RPL in kernel

[JANARDHANACHARI KELLA]

Hi,

i am trying to integrate RPL feature in linux kernel to use on
raspberry pi2 b with at86rf233 module. can any on suggest/ provide any
information to integrate RPL feature?

is this Rpl feature supported for new kernels like(4.x)? for rpl which
kernel i have to use?




-- 
Sincerely Your's

Janardhanachari Kella
Contact:+91-9908469599
E-mail: eni.chari@gmail.com

Re: please help me to integrate RPL in kernel

[Alexander Aring]

Hi,

On 01/18/2017 08:48 AM, JANARDHANACHARI KELLA wrote:
> Hi,
> 
> i am trying to integrate RPL feature in linux kernel to use on
> raspberry pi2 b with at86rf233 module. can any on suggest/ provide any
> information to integrate RPL feature?
> 
> is this Rpl feature supported for new kernels like(4.x)? for rpl which
> kernel i have to use?
> 

look into unstrung implementation. Works well on my side.

Badly there is no other documentation you need to dig into that
yourself.

Also it depends on your use-case if you don't need to hack other things
into unstrung which you need.

- Alex

Re: please help me to integrate RPL in kernel

[João Pedro Taveira]

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

Hi JANARDHANACHARI KELLA,

Just a little of context.

For the last 2 or 3 years I've been working in projects related with smartgrids and LV powergrids. Among the huge list of requirements of the projects, let me just refer two (or three).
	• Sensors mesh networks must use wireless connectivity (not PLC, nor ethernet, or some kind of wired links)
	• Sensors were deployed on Street Lighting poles (thus, would require power provider cranes and "brave" guys to install them)
	• One of sensors features is to detect power outages, thus it would require some kind of backup power to make them work, but... usage of any kind of batteries were forbidden.
Long story short, RPL was simply part of the solution. At the time there were only one good implementation of RPL: contiki's one. For sensors it were a good approach. Anyway, in some use cases, contiki was not enough. After a search for RPL implementations for linux, I only found 2 or 3 which worked on linux userland which required huge resources, so I give it a try and started a linux RPL implementation on kernel land.

	• https://github.com/joaopedrotaveira/linux-rpl (kernel patches)
	• https://github.com/joaopedrotaveira/rpl-userspace-tools (userspace tools like iwpan, based on libnl)
To figure out the SoC power consumption of those on the market and decide which one to use, it was required to test several boards (rpi, beagleboard, beaglebones, olinuxinos, Atheros AR9330 boards, ...), check power consumptions and test RPL implementation with some contiki based sensors. It was also required to use 868band radios, which were very dificult to find. It was very hard to implement RPL in kernel and port it for every single kernel versions of each kind of ARM SoCs, which exoteric patches from this or that SoC vendor to best support for power management (namely pm3).

After Linux RPL Implementation in kernel space being tested, on several SoCs, with transceivers 802.15.4 on 2.4GHz and/or 868, I tried to get in touch with kernel wpan group, but no one seamed to be interested in my contributions. ROLL ietf group was very receptive to know that a kernel land implementation was in development, but wpan-linux had other ideas for the wpan stack, some kind of scorn about RPL, they simply ignored my issues and questions.

After this "kindly" and "warm" acceptance from wpan-group and the lack of interest in merge efforts, I was forced to give up on get RPL implementation in kernel.

RPL standards require information about transceivers link quality, stats about physical layer of 802.15.4 radios, and wpan-linux simply ignored my calls.

After months trying to get things working with dozens of different kernel-trees, from different SoCs, different kernel versions and almost no interest, I was forced to come across on unfair and insulting reviews: http://www.sixpinetrees.pl/2014/11/linux-rpl-router.html

After months trying to get fully RPL supported kernel with following goals:
	• RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy
	• RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
	• RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
	• RFC6719 The Minimum Rank with Hysteresis Objective Function
	• RFC6206 The Trickle Algorithm
	• Support for adding new Objective Functions Modules
	• Kernel Network Namespace support
	• Userland tools
... I was forced to stop working on this, and move forward on the project I was working on, when I get a nice surprise reading conclusion of the already mentioned review:
"Conclusions
RPL for Linux is usable. Joao Pedro Taveira's implementation seems to work with Linux 3.17 and 6LoWPAN (after minimal patching). This is very surprising, that implementation is no longer developed. Linux box is a superior solution for Border Router than any embedded system. Open Source's inefficiency is sometimes amazing."

Right now, I don't know the current status of wpan-linux stack. I recall that wpan-linux was merged with bluetooth-stack or something, but I assume that the required changes to netdev that allow me (or anybody else) to get RPL really working as expected in kernel, are still missing.

When there will be interest, will and gumption to resume linux-rpl project, simply let me know.

Best Regards,
João Pedro Taveira

> On 18 Jan 2017, at 07:48, JANARDHANACHARI KELLA <eni.chari@gmail.com> wrote:
> 
> Hi,
> 
> i am trying to integrate RPL feature in linux kernel to use on
> raspberry pi2 b with at86rf233 module. can any on suggest/ provide any
> information to integrate RPL feature?
> 
> is this Rpl feature supported for new kernels like(4.x)? for rpl which
> kernel i have to use?
> 
> 
> 
> 
> --
> Sincerely Your's
> 
> Janardhanachari Kella
> Contact:+91-9908469599
> E-mail: eni.chari@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

________________________________________
João Pedro Taveira Pinto Silva
e-mail: joao.p.taveira@gmail.com
github: joaopedrotaveira
linkedin: joaopedrotaveira




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: please help me to integrate RPL in kernel

[Alexander Aring]

Hi,

On 01/18/2017 10:46 AM, João Pedro Taveira wrote:
> Hi JANARDHANACHARI KELLA,
> 
> Just a little of context.
> 
> For the last 2 or 3 years I've been working in projects related with smartgrids and LV powergrids. Among the huge list of requirements of the projects, let me just refer two (or three).
> 	• Sensors mesh networks must use wireless connectivity (not PLC, nor ethernet, or some kind of wired links)
> 	• Sensors were deployed on Street Lighting poles (thus, would require power provider cranes and "brave" guys to install them)
> 	• One of sensors features is to detect power outages, thus it would require some kind of backup power to make them work, but... usage of any kind of batteries were forbidden.
> Long story short, RPL was simply part of the solution. At the time there were only one good implementation of RPL: contiki's one. For sensors it were a good approach. Anyway, in some use cases, contiki was not enough. After a search for RPL implementations for linux, I only found 2 or 3 which worked on linux userland which required huge resources, so I give it a try and started a linux RPL implementation on kernel land.
> 
> 	• https://github.com/joaopedrotaveira/linux-rpl (kernel patches)
> 	• https://github.com/joaopedrotaveira/rpl-userspace-tools (userspace tools like iwpan, based on libnl)
> To figure out the SoC power consumption of those on the market and decide which one to use, it was required to test several boards (rpi, beagleboard, beaglebones, olinuxinos, Atheros AR9330 boards, ...), check power consumptions and test RPL implementation with some contiki based sensors. It was also required to use 868band radios, which were very dificult to find. It was very hard to implement RPL in kernel and port it for every single kernel versions of each kind of ARM SoCs, which exoteric patches from this or that SoC vendor to best support for power management (namely pm3).
> 
> After Linux RPL Implementation in kernel space being tested, on several SoCs, with transceivers 802.15.4 on 2.4GHz and/or 868, I tried to get in touch with kernel wpan group, but no one seamed to be interested in my contributions. ROLL ietf group was very receptive to know that a kernel land implementation was in development, but wpan-linux had other ideas for the wpan stack, some kind of scorn about RPL, they simply ignored my issues and questions.
> 
> After this "kindly" and "warm" acceptance from wpan-group and the lack of interest in merge efforts, I was forced to give up on get RPL implementation in kernel.
> 

It's not OUR job to merge ICMPv6 protocol into kernel! I already told
you - you need to send your patches to netdev mailinglist... but I think
you need to switch some stuff there, so far I remember sysfs is used ->
switch to netlink.

We didn't ignore anything...

> RPL standards require information about transceivers link quality, stats about physical layer of 802.15.4 radios, and wpan-linux simply ignored my calls.
> 

Oh I have patches which provides some per-neighbor LQI information. :-)

If you see lack of support, just: send-patches!

> After months trying to get things working with dozens of different kernel-trees, from different SoCs, different kernel versions and almost no interest, I was forced to come across on unfair and insulting reviews: http://www.sixpinetrees.pl/2014/11/linux-rpl-router.html
> 
> After months trying to get fully RPL supported kernel with following goals:
> 	• RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy
> 	• RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
> 	• RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
> 	• RFC6719 The Minimum Rank with Hysteresis Objective Function
> 	• RFC6206 The Trickle Algorithm
> 	• Support for adding new Objective Functions Modules
> 	• Kernel Network Namespace support
> 	• Userland tools
> ... I was forced to stop working on this, and move forward on the project I was working on, when I get a nice surprise reading conclusion of the already mentioned review:
> "Conclusions
> RPL for Linux is usable. Joao Pedro Taveira's implementation seems to work with Linux 3.17 and 6LoWPAN (after minimal patching). This is very surprising, that implementation is no longer developed. Linux box is a superior solution for Border Router than any embedded system. Open Source's inefficiency is sometimes amazing."
> 
> Right now, I don't know the current status of wpan-linux stack. I recall that wpan-linux was merged with bluetooth-stack or something, but I assume that the required changes to netdev that allow me (or anybody else) to get RPL really working as expected in kernel, are still missing.
> 
> When there will be interest, will and gumption to resume linux-rpl project, simply let me know.
> 

I don't know if the ipv6 folks want's to have a RPL implementation in
kernel. For non-storing mode kernel handling is needed but currently
e.g. unstrung (which use storing mode) -> no kernel handling is requirement.

You need to ask on the netdev mailinglist how to maybe deal with that, I
am _not_ an ipv6 maintainer -> you can always send RFC patches there.

It's a big challenge to look how we can deal non-storing mode in future.

- Alex

Re: please help me to integrate RPL in kernel

[João Pedro Taveira]

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

Hi Alex,

Apologise me if I was too hard in my previous mail. It was a simply outflow about something that I kept for too long.

You’re right about the wide range of changes and/or contributions to kernel that RPL requires. I agree with you.

What really wroth me was the “no way out” situation.

My implementation of linux-rpl touch mainly in netdev (ipv6, icmpv6, NUD, extended headers, routing tables…). When I tried to contact netdev, I got no reply whatsoever. But before propose anything to netdev, I wanted to get linux-rpl to work with contiki using MRHOF and ETX. This would only work with feedback from 802.15.4.

So I tried to get some support from you. You were extremely active by then getting wpan moving forward, so I thought you could help me get metrics from wpan stack. Since you were too busy and (now I think I didn’t explained correctly what I needed) you couldn’t help me.

Now I know that you already faced and noticed the problem of MRHOF and ETX.

In a previous mail with subject “thesis - MLE” you wrote:
“Anyway for 802.15.4 I need to implement some kernel parts to calculate
ETX, which means I need some ack received/non ack received counters or
something else which can be inserted for the ETX calculation (I need to
look into that).”

From wpan, this was and still is the only problem I need to solve regarding to RPL and wpan subsystem. RPL works in a completely area of kernel.

I hope get some time to get back to this project and get some kind of stats/metrics system working with RPL Objective Function implementations.

Best Regards,

> On 18 Jan 2017, at 09:59, Alexander Aring <aar@pengutronix.de> wrote:
> 
> 
> Hi,
> 
> On 01/18/2017 10:46 AM, João Pedro Taveira wrote:
>> Hi JANARDHANACHARI KELLA,
>> 
>> Just a little of context.
>> 
>> For the last 2 or 3 years I've been working in projects related with smartgrids and LV powergrids. Among the huge list of requirements of the projects, let me just refer two (or three).
>> 	• Sensors mesh networks must use wireless connectivity (not PLC, nor ethernet, or some kind of wired links)
>> 	• Sensors were deployed on Street Lighting poles (thus, would require power provider cranes and "brave" guys to install them)
>> 	• One of sensors features is to detect power outages, thus it would require some kind of backup power to make them work, but... usage of any kind of batteries were forbidden.
>> Long story short, RPL was simply part of the solution. At the time there were only one good implementation of RPL: contiki's one. For sensors it were a good approach. Anyway, in some use cases, contiki was not enough. After a search for RPL implementations for linux, I only found 2 or 3 which worked on linux userland which required huge resources, so I give it a try and started a linux RPL implementation on kernel land.
>> 
>> 	• https://github.com/joaopedrotaveira/linux-rpl (kernel patches)
>> 	• https://github.com/joaopedrotaveira/rpl-userspace-tools (userspace tools like iwpan, based on libnl)
>> To figure out the SoC power consumption of those on the market and decide which one to use, it was required to test several boards (rpi, beagleboard, beaglebones, olinuxinos, Atheros AR9330 boards, ...), check power consumptions and test RPL implementation with some contiki based sensors. It was also required to use 868band radios, which were very dificult to find. It was very hard to implement RPL in kernel and port it for every single kernel versions of each kind of ARM SoCs, which exoteric patches from this or that SoC vendor to best support for power management (namely pm3).
>> 
>> After Linux RPL Implementation in kernel space being tested, on several SoCs, with transceivers 802.15.4 on 2.4GHz and/or 868, I tried to get in touch with kernel wpan group, but no one seamed to be interested in my contributions. ROLL ietf group was very receptive to know that a kernel land implementation was in development, but wpan-linux had other ideas for the wpan stack, some kind of scorn about RPL, they simply ignored my issues and questions.
>> 
>> After this "kindly" and "warm" acceptance from wpan-group and the lack of interest in merge efforts, I was forced to give up on get RPL implementation in kernel.
>> 
> 
> It's not OUR job to merge ICMPv6 protocol into kernel! I already told
> you - you need to send your patches to netdev mailinglist... but I think
> you need to switch some stuff there, so far I remember sysfs is used ->
> switch to netlink.
> 
> We didn't ignore anything...
> 
>> RPL standards require information about transceivers link quality, stats about physical layer of 802.15.4 radios, and wpan-linux simply ignored my calls.
>> 
> 
> Oh I have patches which provides some per-neighbor LQI information. :-)
> 
> If you see lack of support, just: send-patches!
> 
>> After months trying to get things working with dozens of different kernel-trees, from different SoCs, different kernel versions and almost no interest, I was forced to come across on unfair and insulting reviews: http://www.sixpinetrees.pl/2014/11/linux-rpl-router.html
>> 
>> After months trying to get fully RPL supported kernel with following goals:
>> 	• RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy
>> 	• RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
>> 	• RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
>> 	• RFC6719 The Minimum Rank with Hysteresis Objective Function
>> 	• RFC6206 The Trickle Algorithm
>> 	• Support for adding new Objective Functions Modules
>> 	• Kernel Network Namespace support
>> 	• Userland tools
>> ... I was forced to stop working on this, and move forward on the project I was working on, when I get a nice surprise reading conclusion of the already mentioned review:
>> "Conclusions
>> RPL for Linux is usable. Joao Pedro Taveira's implementation seems to work with Linux 3.17 and 6LoWPAN (after minimal patching). This is very surprising, that implementation is no longer developed. Linux box is a superior solution for Border Router than any embedded system. Open Source's inefficiency is sometimes amazing."
>> 
>> Right now, I don't know the current status of wpan-linux stack. I recall that wpan-linux was merged with bluetooth-stack or something, but I assume that the required changes to netdev that allow me (or anybody else) to get RPL really working as expected in kernel, are still missing.
>> 
>> When there will be interest, will and gumption to resume linux-rpl project, simply let me know.
>> 
> 
> I don't know if the ipv6 folks want's to have a RPL implementation in
> kernel. For non-storing mode kernel handling is needed but currently
> e.g. unstrung (which use storing mode) -> no kernel handling is requirement.
> 
> You need to ask on the netdev mailinglist how to maybe deal with that, I
> am _not_ an ipv6 maintainer -> you can always send RFC patches there.
> 
> It's a big challenge to look how we can deal non-storing mode in future.
> 
> - Alex

________________________________________
João Pedro Taveira Pinto Silva
e-mail: joao.p.taveira@gmail.com
github: joaopedrotaveira
linkedin: joaopedrotaveira




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: please help me to integrate RPL in kernel

[Alexander Aring]

Hi,

On 01/18/2017 11:55 AM, João Pedro Taveira wrote:
> Hi Alex,
> 
> Apologise me if I was too hard in my previous mail. It was a simply outflow about something that I kept for too long.
> 
> You’re right about the wide range of changes and/or contributions to kernel that RPL requires. I agree with you.
> 
> What really wroth me was the “no way out” situation.
> 
> My implementation of linux-rpl touch mainly in netdev (ipv6, icmpv6, NUD, extended headers, routing tables…). When I tried to contact netdev, I got no reply whatsoever. But before propose anything to netdev, I wanted to get linux-rpl to work with contiki using MRHOF and ETX. This would only work with feedback from 802.15.4.
> 

Yes, but MRHOF and ETX is a later step. Maybe bring at first your RPL
implementation mainline? You know... small steps?

btw:

I _never_ saw patches from you for a RPL implementation at netdev
mailinglist. If nobody replies send a "ping" afterwards, etc.

> So I tried to get some support from you. You were extremely active by then getting wpan moving forward, so I thought you could help me get metrics from wpan stack. Since you were too busy and (now I think I didn’t explained correctly what I needed) you couldn’t help me.
> 
> Now I know that you already faced and noticed the problem of MRHOF and ETX.
> 
> In a previous mail with subject “thesis - MLE” you wrote:
> “Anyway for 802.15.4 I need to implement some kernel parts to calculate
> ETX, which means I need some ack received/non ack received counters or
> something else which can be inserted for the ETX calculation (I need to
> look into that).”
> 
> From wpan, this was and still is the only problem I need to solve regarding to RPL and wpan subsystem. RPL works in a completely area of kernel.
> 
> I hope get some time to get back to this project and get some kind of stats/metrics system working with RPL Objective Function implementations.
> 

I changed my decision right now to ETX from L2 ack. Because it will work
on Unicast only. LQI is something which also works on multicast.

Anyway If you see such problem then "send-patches", this is how open
source works. Nobody will do anything when you talk about "I need that
and that...".

- Alex

Re: please help me to integrate RPL in kernel

[JANARDHANACHARI KELLA]

Thank You Alex and João for your advice and guidance.


Right now i am following this site:
http://www.sixpinetrees.pl/2014/11/linux-rpl-router.html

if i have any doubts i will get in touch with you.


On Wed, Jan 18, 2017 at 4:59 PM, Alexander Aring <aar@pengutronix.de> wrote:
> Hi,
>
> On 01/18/2017 11:55 AM, João Pedro Taveira wrote:
>> Hi Alex,
>>
>> Apologise me if I was too hard in my previous mail. It was a simply outflow about something that I kept for too long.
>>
>> You’re right about the wide range of changes and/or contributions to kernel that RPL requires. I agree with you.
>>
>> What really wroth me was the “no way out” situation.
>>
>> My implementation of linux-rpl touch mainly in netdev (ipv6, icmpv6, NUD, extended headers, routing tables…). When I tried to contact netdev, I got no reply whatsoever. But before propose anything to netdev, I wanted to get linux-rpl to work with contiki using MRHOF and ETX. This would only work with feedback from 802.15.4.
>>
>
> Yes, but MRHOF and ETX is a later step. Maybe bring at first your RPL
> implementation mainline? You know... small steps?
>
> btw:
>
> I _never_ saw patches from you for a RPL implementation at netdev
> mailinglist. If nobody replies send a "ping" afterwards, etc.
>
>> So I tried to get some support from you. You were extremely active by then getting wpan moving forward, so I thought you could help me get metrics from wpan stack. Since you were too busy and (now I think I didn’t explained correctly what I needed) you couldn’t help me.
>>
>> Now I know that you already faced and noticed the problem of MRHOF and ETX.
>>
>> In a previous mail with subject “thesis - MLE” you wrote:
>> “Anyway for 802.15.4 I need to implement some kernel parts to calculate
>> ETX, which means I need some ack received/non ack received counters or
>> something else which can be inserted for the ETX calculation (I need to
>> look into that).”
>>
>> From wpan, this was and still is the only problem I need to solve regarding to RPL and wpan subsystem. RPL works in a completely area of kernel.
>>
>> I hope get some time to get back to this project and get some kind of stats/metrics system working with RPL Objective Function implementations.
>>
>
> I changed my decision right now to ETX from L2 ack. Because it will work
> on Unicast only. LQI is something which also works on multicast.
>
> Anyway If you see such problem then "send-patches", this is how open
> source works. Nobody will do anything when you talk about "I need that
> and that...".
>
> - Alex



-- 
Sincerely Your's

Janardhanachari Kella
Contact:+91-9908469599
E-mail: eni.chari@gmail.com

Re: please help me to integrate RPL in kernel

[JANARDHANACHARI KELLA]

Hi,

I am working for integrating rpl with 4.9 kernel for raspberry pi. I
have ported the RPL module code from 3.17 to 4.9 kernel. and i had
installed tool from bellow site.

https://github.com/joaopedrotaveira/rpl-userspace-tools

when i was trying to enable RPL with bellow command.  kernel and
Raspberry pi  is getting hang and after few seconds all processes are
going to crash. againg to start, it is taking restart(power off/on).

# enable RPL router
$ sudo rpl-ctl enable eth0


please help me.. to activate RPL in 4.9 kernel.

On Thu, Jan 19, 2017 at 10:43 AM, JANARDHANACHARI KELLA
<eni.chari@gmail.com> wrote:
> Thank You Alex and João for your advice and guidance.
>
>
> Right now i am following this site:
> http://www.sixpinetrees.pl/2014/11/linux-rpl-router.html
>
> if i have any doubts i will get in touch with you.
>
>
> On Wed, Jan 18, 2017 at 4:59 PM, Alexander Aring <aar@pengutronix.de> wrote:
>> Hi,
>>
>> On 01/18/2017 11:55 AM, João Pedro Taveira wrote:
>>> Hi Alex,
>>>
>>> Apologise me if I was too hard in my previous mail. It was a simply outflow about something that I kept for too long.
>>>
>>> You’re right about the wide range of changes and/or contributions to kernel that RPL requires. I agree with you.
>>>
>>> What really wroth me was the “no way out” situation.
>>>
>>> My implementation of linux-rpl touch mainly in netdev (ipv6, icmpv6, NUD, extended headers, routing tables…). When I tried to contact netdev, I got no reply whatsoever. But before propose anything to netdev, I wanted to get linux-rpl to work with contiki using MRHOF and ETX. This would only work with feedback from 802.15.4.
>>>
>>
>> Yes, but MRHOF and ETX is a later step. Maybe bring at first your RPL
>> implementation mainline? You know... small steps?
>>
>> btw:
>>
>> I _never_ saw patches from you for a RPL implementation at netdev
>> mailinglist. If nobody replies send a "ping" afterwards, etc.
>>
>>> So I tried to get some support from you. You were extremely active by then getting wpan moving forward, so I thought you could help me get metrics from wpan stack. Since you were too busy and (now I think I didn’t explained correctly what I needed) you couldn’t help me.
>>>
>>> Now I know that you already faced and noticed the problem of MRHOF and ETX.
>>>
>>> In a previous mail with subject “thesis - MLE” you wrote:
>>> “Anyway for 802.15.4 I need to implement some kernel parts to calculate
>>> ETX, which means I need some ack received/non ack received counters or
>>> something else which can be inserted for the ETX calculation (I need to
>>> look into that).”
>>>
>>> From wpan, this was and still is the only problem I need to solve regarding to RPL and wpan subsystem. RPL works in a completely area of kernel.
>>>
>>> I hope get some time to get back to this project and get some kind of stats/metrics system working with RPL Objective Function implementations.
>>>
>>
>> I changed my decision right now to ETX from L2 ack. Because it will work
>> on Unicast only. LQI is something which also works on multicast.
>>
>> Anyway If you see such problem then "send-patches", this is how open
>> source works. Nobody will do anything when you talk about "I need that
>> and that...".
>>
>> - Alex
>
>
>
> --
> Sincerely Your's
>
> Janardhanachari Kella
> Contact:+91-9908469599
> E-mail: eni.chari@gmail.com



-- 
Sincerely Your's

Janardhanachari Kella
Contact:+91-9908469599
E-mail: eni.chari@gmail.com

RPL integration needs in the Linux Kernel

[Michael Richardson]

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


{please forgive how long it's taken me to respond. I've been meaning to reply
at length for some time.  And my thanks for reading to the end.
I know it's long.}

In advance of the netdev2.1 IoT panel discussion,
   http://netdevconf.org/2.1/session.html?schmidt
I thought it useful to put some thoughts on the things that userspace
routing protocols need from the kernel and 6lowPAN layer.
Some of these needs apply to BABEL and OLSR as well as RPL, btw.

Most of these things are probably in common with Joao's needs for his
in-kernel RPL implementation.  I think that other mesh protocols, perhaps
including ISA100-type mesh-under might be able to use some of these things
too, but generally, I dislike layer-2 mesh.  Enough with the layer-2 tricks,
I say.

Oh, and this is more than just 802.15.4, check out:
    https://datatracker.ietf.org/wg/6lo/documents/
to see it's also about BTLE, "lobac" aka MS/TP, DECT, NFC, G9959,
MS/TP is multi-drop 9600 baud RS422 over twisted pair, and is probably in
      every commercial building that has elevators or air-conditioning.

====

About me: I was the IETF ROLL WG co-chair from 2012 to 2016, and I edited the
      security threats analysis and then wrote a lot of the "useofrplinfo"
      document.  (I stepped down as co-chair to enable others, to return to
      being at cat, rather than a cat-herder)

      While RFC6550 tells you a lot about the RPL routing protocol
      itself, it leaves 6553 and 6554 to tell one about how to construct the
      forwarding level.  And those documents have failed to produce
      interoperable implementations.

https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ is in WG Last
Call. I'm a co-author. There are some RFC2460 rules (and 2460bis) which we
have to follow.   This clarification of the rules for when you need RFC6553
(RPI) and RFC6554 (RH3) headers (and related IPIP header) was driven by the
desire to further compress these artifacts by the 6LoWPAN Routing Header.
https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/
{we couldn't know what mattered most to compress until we sure when each
header occured and in what order}

====

Most, like Joao test against Contiki, and Contiki
      a) only implemented storing mode until very recently.
      b) did not actually support multiple instanceIDs.

If one does only storing mode with a single instanceID, and ignores all the
other stuff, then the stock Linux IPv6 kernel router processes can be made to
work.  As soon as one wants more... then we get into trouble.

Alexander Aring has done a bunch of work, or at least, planning for work on
how to implement the new compression code in the kernel.  The code patches
are still in his head at this point, I think :-)

In general many of us see Linux based devices being the RPL root nodes,
having power, lots (compared to class 2 devices) of ram, and a multitude of
interfaces.   Joao's work shows that in a number of situations the sensors
and motes could well be big enough to run Linux, and increasingly, the cost
of Linux based SoC is often lower than some ATmel based ones.  $9 CHIPs
and $10 VoCore's and PINE64s and the like.  Even RPIs and things like the
Orange PI 0... many are power-hungry, but sometimes that's okay.

802.15.4 PHYs are growing from the 128-byte packet limit, and 250kbps
peaks, to having 2K packet sizes and 2Mb/s data rates, meanwhile the
power-cost of some 802.11 chips has plumetted.

We run into problems once we start to think about being gateway routers,
running non-storing mode, or supporting multiple instanceIDs.

What we need in the kernel for the forwarding plane:
   1) processing of the RPI header in uncompressed form.
      This means to be able to increment/decrement the rank depending
      upon what direction the packet is going.  As it may well enter and
      exit upon the same (radio) interface, this directionality (up/down)
      needs to be encoded into the route and/or "Grand Unified Flow Cache".

   2) when processing the RPI header, the instanceID needs to be mapped to
      a routing table number.  We have to think about attacks involving
      this kind of header, and so we have to have some ways to either contain
      or ignore this header.  The system in question may well have a
      multitude of other functions in addition to being a RPL root.

   3) we need processing of the (source) RH3 header, which is rather simple, but a
      key point is that it asks for ignoring the routing table. Again, even
      more concerns about RH3 headers showing up in surprising places.
      The RH3 header may well evolve to become more of a Loose source route,
      and so it would be good to support some routing lookup at times.

   4) we need to be able to specify inserting of a RH3 (and IPIP) header
      within a route entry.  This is how non-storing mode works, and also
      how the P2P mode of RPL works.  Also inserting of an RPI header.

Then, we need to do all of the above for 6lowRH compressed form of headers.
Such a form is, btw, defined for 6lowpan links only, and yet RPL is layer 3,
and happily forwards over 802.11 or ethernet or PPP...

The compression is designed so that one does not need to take it all apart to
process things, but rather one manipulates the compressed form directly when
an intermediate node.  At any point, though, an error (such as
no-route-to-host), might cause the packet to be uncompressed, and then an
ICMPv6 created... and then some of that would get compressed again.

Some of the compression can be handled as if it were hardware offload or
layer-2 drivers.  For instance if one wants to perform RFC7400 (GHC)
compression on the whole packet, that can be done "below" IP.

However, in order to efficiently forward, it would be nice to if the
forwarding decompression routines could populate parts of the SKB in much the
way that the VLAN processing doesn't care if it was the NIC that did the
work, or the VLAN layer.

The number of fields and new structures required in the kernel could be many,
and stuffing them into skbuff, etc. might be unpopular.  My (recent) review
of Joao's code points to this being perhaps one reason it was perhaps not well
received. (Also not being linux-next git-pullable probably mattered).

I regard this as the challenge: not, "how to write this", but rather,
  - how can we write this in a way that is minimally disruptive to other users?

  - while we can have an option to compile things in/out, if a gateway device
    is doing both FTTH Gb/E forwarding, and also 802.15.4, can we have add
    the new things we need without killing Gb/E forwarding?

One thought that Alex and I discussed in chat over many days was how much
could we move to userspace?  802.15.4 networks are SLOW.  Aside from the
power cost of being awake longer,  the speed won't be adversely affected by a
few data copies in and out of the kernel.

One approach which has been repeated in software and hardware is not to even
try to do this in the kernel!  The Redwire gateway for instance, is a
Linux-based home router with a Redwire Econotag running Contiki attached to
it.  The radio is on the econotag, and they speak via SLIP over USB-serial.
One can repeat today with an RPI and an OpenMote with OpenWSN, and in fact
this is part of the preferered 6tisch development platform.
One version of this runs RPL and 6lowpan written in Python on the host.
The result is an academic solution: the python is too big and new to run
with uPython on platforms that would actually work.

6tisch is TIme Slot Channel Hoping, and permits devices to sleep 99% of the
time by coordinating when they actually need to be awake to Tx/Rx
packets. Getting the precise timing is actually a bit of a challenge with
Linux, and so far the solution is an OpenMote on USB, or on RPI shield.

I'm trying to switch it from a bastardized SLIP interface, to PPP, such that
we can do the 6lowpan on the Linux side, but leave the precise timing to the
OpenMote processor fow now.  PPP because I think it will be easiest to extend
to include time-slot, channel, Rx and Tx powers.

This brings up two requirements that we have in common with the mac80211
work.

a) We need to be expose Rx and Tx parameters to userspace applications.

b) We need to feed/store ETX ("link quality") values calculated by userspace
   applications back into the kernel's neighbour table.

To explain, RPL needs to know how far away each peer is so that it can best
determine what parents it should pick.  An important part of this can be
knowing how much power it took to send to that peer, and how strong the
signal was when traffic was received from that peer.

This would be best stored in the neighbour cache table in the kernel, to
expire and be recreated.  (And along with this, Alex has been working on
storing both the EUI-64 extended address and the 16-bit short address into
that table)

One can't know what the link quality is with a peer unless one actually tries
transmitting to that peer.  Zigbee defined a protocol called MLE.  It's
*still* a draft:
        https://datatracker.ietf.org/doc/draft-ietf-6lo-mesh-link-establishment/
(sigh, expired again....)

the essence is to send traffic to peers, and record how well one does.
This lives in UDP. (I claim it should have been ICMPv6).  It certainly
would be easier to do inside the kernel with better access to Tx/Rx power
information in the skbuff.  Do the mac80211 folks have a userspace API yet to
Tx/Rx info?   I know that they wanted to have one at some point.

So, if we can get/set Rx/Tx info via recvmsg(2), then a free-running daemon
can detect how strong signals are, and based upon that, we can then populate
the neighbour cache entries.  This has two purposes.  a) so that a routing
daemon (whether userspace or kernel) could see the strengths.
more importantly: b) so that the kernel will only transmit with as much power
                  is it needs to. using only as much battery as needed, and
                  also disrupting as few distant nodes as possible.

Wow, this is a lot of lines.

Let me respond to some of Joao's comments:

    > After Linux RPL Implementation in kernel space being tested, on several
    > SoCs, with transceivers 802.15.4 on 2.4GHz and/or 868, I tried to get
    > in touch with kernel wpan group, but no one seamed to be interested in
    > my contributions. ROLL ietf group was very receptive to know that a
    > kernel land implementation was in development, but wpan-linux had other
    > ideas for the wpan stack, some kind of scorn about RPL, they simply
    > ignored my issues and questions.

    > After this "kindly" and "warm" acceptance from wpan-group and the lack
    > of interest in merge efforts, I was forced to give up on get RPL
    > implementation in kernel.

I rather think you got silence because nobody knew what you were doing, nor
why.   I don't know why you think the userland code bases were so "huge":
lines of source code with debugging enabled is not the same as executable
size with things stripped out.  But in any case, you never contacted me.

    > When there will be interest, will and gumption to resume linux-rpl
    > project, simply let me know.







--
]               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: 487 bytes --]