leshan
leshan copied to clipboard
eclipse-leshan
🏗 Leshan 2.0 : LWM2M 1.1 🚧
Leshan v2.0.0 (master branch) is currently in development and aims to support LWM2M 1.1 (or at least some part of it).
You can have a look to currently supported or in development features or current roadmap.
If you are interested in LWM2M 1.1 support in Leshan, we strongly advice to :
- use/test this milestone release,
- report us any bug or feebacks,
- share what part of LWM2M 1.1 missing you more here :point_down: ,
- contribute code.
This is the best way to get a final 2.0.0 release which fit your needs.
(If you need stable API and are fine with LWM2M v1.0, you should use Leshan v1.x)
Hi Bernard
I would be very interested in the newly introduced Non-IP binding for NB-IOT, where we can use 3GPP SCEF to carry LwM2M traffic, though the spec is released, however a reference design regarding how to integrate with T8 interface would be a good start for us to contribute
BR/Vincent
As a part of a joint project with Ericsson about contributing OSCORE to Californium we at RISE have also been working on using OSCORE in Leshan, as OSCORE is part of LWM2M 1.1.
Currently we have code produced for enabling communication over OSCORE between the Leshan server, bootstrap server and client. In addition we have added support to bootstrap a client so it receives information to generate an OSCORE context for communication with the Leshan server. We would be interested in contributing this code to Leshan.
@wenzheng, sry for the delay response, I have no experience about NB-iot but I suppose the first step must be to have a way to make CoAP and DTLS working over NB-IOT in Java. In a californium context that means create new Connector(s) for NB-IOT.
@rikard-sics, That's a good news to know we could get a new contribution from RISE. :)
But I ask myself how we could handle this because as explained we plan to firstly release a 1.0.0 of Leshan which supports LWM2M v1.0.x. (so without 1.1 feature)
Maybe we could integrate this in another branch of Leshan which would aim to support LWM2M v1.1. I suppose the contribution is pretty big, right? Did you plan to continue to actively maintain this part of the code after your contribution?
It seems there is some interests about Observe-Composite and Cancel Observation-Composite at https://github.com/eclipse/californium/issues/881.
@rikard-sics, That's a good news to know we could get a new contribution from RISE. :)
But I ask myself how we could handle this because as explained we plan to firstly release a 1.0.0 of Leshan which supports LWM2M v1.0.x. (so without 1.1 feature)
Maybe we could integrate this in another branch of Leshan which would aim to support LWM2M v1.1.
Yes it could make sense to put it in a separate LWM2M 1.1 branch since OSCORE is not part of LWM2M 1.0.x
I suppose the contribution is pretty big, right?
Actually the contribution is not that big since we made it very targeted on providing OSCORE support. Since the actual code for OSCORE communication is in Californium, for Leshan it was more about adding code to use it.
Did you plan to continue to actively maintain this part of the code after your contribution?
This work is part of a joint project with Ericsson and for the future we have the ambition to continue to use and support this code.
We at HPE are interested in developing 1.1 features like CBOR, Composite Read,Write,Observe., Bootstrap trigger and Non-IP transport. We will start a new branch and contribute in coming days.
@yemkay : i would like to request you, please share further information once 1.1 feature available to use
@yemkay, good to know :) ! There is already some contribution about CBOR :#656 . If you are interested by this subject. (It's the very beginning of the contribution)
@rikard-sics, That's a good news to know we could get a new contribution from RISE. :)
Just to come back to this regarding OSCORE in Leshan. Would it be fine if we made a pull request with the code we currently have putting it into a separate branch of Leshan? I suppose such a branch would have to be created first?
@rikard-sics I created a 2.0.x branch and its jenkins job.
I suppose you need OSCORE feature from Californium, so the first step will be to wait for a Californium v2.0.0M14, right ? Please if you can try to make several simple, little, self-sufficient PRs. This could help review and integration. :pray:
@rikard-sics I created a 2.0.x branch and its jenkins job.
I suppose you need OSCORE feature from Californium, so the first step will be to wait for a Californium v2.0.0M14, right ? Please if you can try to make several simple, little, self-sufficient PRs. This could help review and integration.
Thanks a lot for creating the branch.
I see that Californium 2.0.0-M14 has now been released. I will proceed with making smaller pull requests with parts of our code as you requested.
@rikard-sics , just to let you know I plan to create a PR to integrate Californium 2.0.0-M14 this afternoon.
@rikard-sics oops not so ready, build failed because of new legal bundle in californium. I will try to fix it.
@rikard-sics this time it's really OK.
Thanks for setting up the branch. I will proceed with the pull requests in steps as you mentioned.
Is there any estimated time frame as to when lwm2m 1.1 is supported?
Question : what means "LWM2M 1.1 is supported" ? Do you mean full support of all defined features.. Even for 1.0 we didn't cover 100% of the specification. So you should ask yourself which part of the specification you need and share this with us. This could help to define priorities !
Anyway, I will not be able to give you any date. This is just the beginning for 1.1 implementations. Some contributors just started to work on this. Personally, I'm focus on the version 1.0.x. and maybe I will be able to start to develop some 1.1 features at the end of the year.
All the work about LWM2M 1.1 is available in branch 2.0.x.
Is OSCORE available in branch 2.0 now ? Thanks.
There is an open pull request to add support for OSCORE communication between a Leshan client and server to the 2.0.x branch here: https://github.com/eclipse/leshan/pull/718 More information can be found in that PR.
@sbernard31 , @rikard-sics , do you know the progress to implement "Send" Operation defined in LwM2M 1.1? Has it been implemented, or is someone working on it now?
Thanks. Kenny
@sbernard31, thanks for your response. In my opinion, Send operation is a very important functionality, for example: when there is a fault in a LwM2M client, it should send it out immediately in order for operators to be aware of this fault, instead of waitting for obervation from the LwM2M server. Please prioritize it if possible, thanks a lot.
B.R. Kenny
@Kenny-SZ we agree that send is really good feature because observation has too many drawback. (https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/171)
Hi @sbernard31 & All, does anyone know the progress to support LwM2M 1.1? Thanks.
Personnally, I'm still focus on the 1.0.0 release. We hope we will be able to release it soon (maybe during spring 2020) and then we would be able to start to work on LWM2M 1.1 support.
There is already some contribution from community :
- @rikard-sics is working on OSCORE support.
- @cavenaghi9 started to work on senML json & cbor content format.
Hi, just curious on how 1.1 topic is proceeding? I mean standard is already moving to 1.2, so I think some kind of 1.1 subset should be prioritized. For me the most important feature would be SEND, as that would enable use cases leveraging LwM2M for real-time control and alarms, like what is currently doable with MQTT (more or less successfully)
@henris42, I agree with you (see https://github.com/eclipse/leshan/issues/563#issuecomment-523350573)
The only missing part is time to do it :-)
@henris42, I agree with you (see #563 (comment))
The only missing part is time to do it :-)
@sbernard31: One problems is to have some kind of incentive to contribute.
Observation: most activity seem to happen in master branch.
You have also a policy not to take any non 1.0.2 changes to master.
As an example you have 2.0.x branch which is over year old and doesn't really invite contributing. There are several other work branches that has "expired" too.
Where as in my view only LWM2M 1.1 makes LWM2M actually usable for deployments as that has better EST support than 1.0.2. There are other features like send that was mentioned also in here.
Sticking to LWM2M 1.0.2 is making current Leshan releases uninteresting.
Currently there does not seem to be good path to contribute changes with target of having LWM2M 1.1 features supported in Leshan releases.
Would you be willing to start taking 1.1 (or later) changes to your master branch? If master branch would be following latest released standard then it could bring incentive for others to contribute.
Some changes also require a bit larger changes making this API protection mechanism a bit harder to tackle. Used quite a lot of time to fight that when I was testing some certificate usage improvements with Leshan code base.
most activity seem to happen in master branch You have also a policy not to take any non 1.0.2 changes to master.You have also a policy not to take any non 1.0.2 changes to master.
This is correct because main contributor was interested in a 1.x release of Leshan which supports LWM2M 1.0.x We started to develop Leshan long time ago and we didn't want to shift from LWM2M 1.0.x to LWM2M 1.1 without providing a polished release with stable API. Now Leshan 1.0.x is released and we plan a last 1.1 version for LWM2M 1.0.x, then we will mainly focus on LWM2M 1.1 (so Leshan 2.0)
As an example you have 2.0.x branch which is over year old and doesn't really invite contributing. There are several other work branches that has "expired" too.
We created this branch to help some contributor to start to work in Leshan 2.0 which will supports LWM2M 1.1 waiting we finish the work on LWM2M 1.0.x but contributors disappear without saying a word. Currently the only active one (LWM2M 1.1) works on OSCORE in its own branch and I take time to review it works. (as I tried to do for SenML before contributor vanished)
Sticking to LWM2M 1.0.2 is making current Leshan releases uninteresting.
I hope you mean "uninteresting for me" or this sounds a bit peremptory.
Currently there does not seem to be good path to contribute changes with target of having LWM2M 1.1 features supported in Leshan releases.
Because as explained, there was no more contributors who need that. But if needed I can create it again. I mean an up to date 2.0.0 branch.
Some changes also require a bit larger changes making this API protection mechanism a bit harder to tackle. Used quite a lot of time to fight that when I was testing some certificate usage improvements with Leshan code base.
We are using semantic versioning and as explained above we aim a version 2.0 of Leshan for LWM2M 1.1 so API can be break so don't worry about that.