HI Carles, Below, you indicate you might have some updates for Montreal.
Would you like some time during the meeting to discuss any progress you may have had on the implementation and validation of the spec? Not ready yet? Thanks, Gabriel From: 6lo <[email protected]> On Behalf Of Samita Chakrabarti Sent: 16 March, 2018 05:16 To: Carles Gomez Montenegro <[email protected]> Cc: [email protected]; lo <[email protected]> Subject: Re: [6lo] Status of draft-ietf-6lo-blemesh-02 Thank you Carles for the implementation update of BLEmesh.. Great work in finding out and sharing the ble existing base implementations pros and cons. That is helpful for 6lo wg and it is good to know that Contiki now supports RFC 7668. -Samita On Mar 16, 2018 4:38 AM, "Carles Gomez Montenegro" <[email protected]<mailto:[email protected]>> wrote: Dear WG, We would like to provide a short report on the status and our activities related with draft-ietf-6lo-blemesh-02. As you may recall, while we believe the document to be ready, we wanted to implement it before proceeding further. We had planned to implement the draft based on Raspberry Pi devices and BlueZ. We actually enabled an RFC 7668 scenario with one device as a master (or a 6LBR), another one as a slave (or a 6LN), and even IPv6-based communication between the 6LN and a non-BLE interface of the 6LBR was working well. However, when we tried to increase the number of 6LNs per 6LBR, we encountered the issue that communication between the 6LBR and the already existing 6LN stopped working. It appears that several concurrent BLE connections are not handled correctly with BlueZ. This is a problem other people have found, and as per the BlueZ mailing list, there is not a currently known solution. Fortunately, we have found another basis for our implementation. Recently, the BLEach open implementation of RFC 7668 (based on Contiki and CC2650 devices) was released (http://spoerk.github.io/contiki<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fspoerk.github.io%2Fcontiki&data=04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d2296594d8b0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=gg8G01srzJ3e6X1IbLwUQ2mFcqhPq9Wm9FUTBry8XFw%3D&reserved=0>). It is promising, as in fact results are shown by BLEeach authors on a scenario with one 6LBR and several 6LNs. We are currently in the process of enabling the RFC 7668 scenario based on this platform, and then we plan to modify/extend the code in order to implement our draft. Our plan is to have a first prototype implementation by IETF 102 (Montreal), and request to give a report in the 6Lo session of that meeting. Meanwhile, please let us know whether you have any comments on the draft. And, of course, any feedback from implementation experience will be very much appreciated! (Note: when the I-D submission tool reopens, we will upload a new version of the draft as "a refresher".) Thanks! Carles, Mahdi, Teemu _______________________________________________ 6lo mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6lo<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d2296594d8b0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=fVu7RwdS7gDMMvY5N0iLrwe201uqttE58Gw3eHrKqhE%3D&reserved=0>
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
