Hilton Buenos Aires, Buenos Aires, Argentina Monday, April 4, 2016. 17:40–19:40 Room Buen Ayre C Chair: Donald Eastlake Sponsoring AD: Brian Haberman IAB Shepherd: Erik Nordmark Minute takers: Thomas Watteyne, Dominique Barthel, Pascal Thubert, Ana Minaburo Minutes reviewed by Donald Eastlake. Minutes: ===> Administrativia (scribes), Agenda Bashing, Chair ===> Opening Remarks, AD [15.43] meeting starts ~60-80 people in room (please check blue sheets) ~25 people on chat [15.43] intro BoF chaired by Don Eastlake Don point out Note Well Don introduces agenda Don calls for agenda bashing - no issues raised [Brian Haberman, AD] states what he is looking for: How much of a problem is there that Babel addresses? Is the IETF a good forum for address the problem? How much interest is there in working on this? ===> Why LPWAN, Alexander Pelov [17.47] Why LPWAN [Alex Pelov] presentation about the business side low-cost: 5M USD for HW to cover France 1 Billion devices by 2020 589 Billion USD LPWAN market for 2020 different competing technologies, goal: help ecosystem thrive [?? Cisco] Supports this work, but doesn't trust market predictions ===> LP-WAN GAP Analysis, Ana Minaburo [17.54] gap analysis [Ana Minaburo] LPWAN technologies See http://goo.gl/S3uSPU goal, get general characteristics. Ana presents characteristics for LPWAN technologies, including: limit of 10 packets per day no fragmentation at L2? what the IETF can bring IP communication for E2E communication, L2 independence security scalability reliability interop header compression network and devices management Gaps in today's IETF protocols compact IPv6 fragmentation Neighbor discovery 6lo constraint nature is different than LPWAN 6tisch: lp-wan is star, no mesh, some technologies are not slotted channel routing: star in LPWAN, perhaps in a future core: CoAP is good solution for lpwan, but need to adapt for limited duty cycle of lpwan mobility: mobile-ip not adapted [Juan Carlos] Questions regarding addressing, will you talk about them later? [Emmanuel] Interesting, we need to address this in the IETF. One point: scalability is not a concern at the IETF, not sure about this, because adding on bit over the air will have a huge hit, it is a concern [Erik Nordmark] wide range of characteristics, will we go after the whole range? Example: 10 packets/day is not a lot. different approach a bit higher packet rate, do you think there is a single solution for all of that? [Ana] we need to choose 2 or 3 technologies to focus on, open to discussions [Subir] Is running IP a problem? [Don] we have a presentation on that [Sri Gundavell] LoRa and SigFox doesn't adopt IPv6, do we konw why? [Ana] [Samita] If you're asking about optimized ND, 6LoWPAN/6lo designed one [Sri Gundavell] Did we concern existing protocols? [Alex] is the reason why, everyone things we have a solution, many announcements, but know there are problems, and IP might solve that [Ana] More presentations about solutions [Dan York] In the gap analysis, we need to understand what they are using if they are not using IP. What is the networking technology they are using now? [Alex] Comes later, application data directly over MAC, proprietary [Dan] Do they have enough capacity for an IP stack? [Alex] it's the network which is constrained, the devices have calculation resources [Diego as Jabber Scribe] [Basavaraj Patil] how would LoRa and Sigfox benefit from what you want t work on? [Pascal] they have a solution for one problem/scale. LoRA WAN is looking at join process, so not all is solved. suggest we go through the slides layer by layer, and we ask questions layer by layer [Diego] Can we not run LoRa with slots? [Ana] in the general case, we cannot assume all is slotted [Don] closes the mic line ===> IP Challenges and non-IP Wireless I/O Models, Pascal Thubert [18.18] IP challenges [Pascal thubert] Goal of next presentation: go layer by layer Not only do we have momentum in market, but IEEE and IETF should help to get some homogeneity in the solutions Pascal will talk about IP, Alex will talk about sec and app Question about the sixe of the stack and packets. The crucial part is the communication All these technologies are about the energy/range tradeoff 6LoWPAN could optimally compress down to 4 bytes. ROHC can do 1 byte, but needs to learn from the flow. In the case of LP-WAN, we don't have flows. [Hannes Tschoefenig] What are the security requirements? If you leave security out, it's lightweight but less secure. Lots of expertise at IETF Do these networks want IP at all? the last hop is non-IP, no layer 3 or 4. But the so-called gateway can introduce these layers 3 and 4 to join the network. WirelessHART now does that. If we provide IP to these LP-WANs, the benefits could be: device management, security, etc… CoAP will provide a way to authenticate the device, application-level multiplexing. Will help get through the next 10-20 years. Compression is key: neither 6LoWPAN nor ROHC fit the bill. We want best of both worlds, absolute compression without on-line learning. Use a data model, so that state known a priori can be put into the equipment. [Christian Huitema] Microsoft : reason for IP is end-to-end model. Non-IP solutions rely on intelligence in the gateway. You're looking for a solution to be able to change the end-point without changing the gateway. [Pascal] We find that the device usually always talks to the same other device at network layer, but IP alleviates the need to collocate. [Christian] You definitely want to have IP. Not sure about CoAP [Hannes] Remote IO was interesting analogy. Like cable replacement. How to identify end point and relay message without too much overhead. Also how to identify application server. Companies would expect the operator to provide this service. [Pascal] Some of these protocols are already there, and are here to stay. Now want to add IP... [Hannes] We can provide functionalities such as device management (OMA, CoMI, ...) CBOR encoding, ... We'll have to focus on a few technologies. Let's dicuss this on the mailing list. We had excellent collaboration with IEEE 802 on 15.4, let's do the same with e.g. LoRa and a few other technologies. [Juan Carlos] Excellent work. What exactly are the needs on the different layers? e.g. do we need E2E communication? work in 802c for local MAC address, from OUI to EUI to CUI. IEEE802 is looking at addressing, good timing to consider these use cases. Let's avoid having to fix things later on. [Pascal] What we see here at IETF, IEEE is addressing it as well. ===> APP-level protocols/AAA/Management/Security, Alexander Pelov [18.40] application, AAA, management, sec [Alex Pelov] We have soluions here at IETF AAA: network access control is a problem in general, PSK (Pre-Shared Key) used specific LPWAN requirements: huge number of devices what can IETF offer: AAA framework and protocols guidance for AAA key managements can we live with PSK when we have devices there for 20 years and easy to grab? scalability? flexibility? They are trying to redefine things that have already been done at IETF device management: currently through MAC commands. Not flexible. e.g. in LoRa Spreading factor, coding rate and ?? but only 15 combinations allowed ??? application management: can't change parameters in current devices. CoOL, CoAP could help application developers configure their devices. scaling to high number of devices requires flexibility. we propose to add this layer onto the MAC management of these devices Security: there are many things, including asymmetric links some of these technologies are very asymmetric: SigFox max 4 downlink messages a day. One-time passwords ore not usable. Applications limited number of flows (typically 2). Compression feasible. end-device time scale vs application time-scale. Desire that there is no need to update the G/W for every change in the device Example: how to manage timers, how to manage devices, what about fragmentation, what about sleepy nodes? all left to application developers. => there is an application protocol, but it's implicit. Nobody is sure what is there [Sri Gundavell] How many thing that you list are application issues vs network issues [Alex Pelov] Some timers are hardcoded and the application depends on it. [Sri] Need an "AP" so the application does not have to care about networking stuff [Alex Pelov] How does the application know how long it should wait for an answer. That's app stuff. [Alex Petrescu] Apps are specific and design for purpose. All is done at the application and the way it is deployed; this is why IP is needed, to make app more independent. what does IETF bring? remove interlayer dependence profiling applications to manage acks, if you go for satellite backhaul with LoRa, all your timers timeout, the whole stack breaks. ===> Optimized 6LoWPAN Fragmentation Header for LPWAN, Carles Gomez [19.01] optimized 6LoWPAN fragmentation for LP-WAN presentation [Carles Gomez] motivation: * some LP-WANs have payloads much smaller that 15.4. 6LoWPAN has 4-5 bytes fragmentation headers. * RFC4944 frag offset in expressed in 8-byte increments. Not usable with smaller frame LP-WANs. proposed format: 3-byte fragmentation headers. datagram size included in the frist fragment only, since no re-ordering expected in star-topology LP-WANs. datagram_tag on 1 byte only, no ambiguity because low datarate. offset in 1-byte increments. shows table with overhead in various common cases. compares overheads of RFC4944 and 6LoFHL, IANA and security considerations IANA has to allocate 16 dispatch values from the 6LoWPAN space [Don] Move to next presentation, questions at end ===> Constrained Signaling Over LP-WAN including AAA, Alexander Pelov [19.11] CoSOL Constrained Signaling over LPWAN [Alex Pelov] use CoAP as signaling protocol for LPWANs to manage behavior of end devices. you must be able to use CoAP before having an IP address Alex gives E2E example with LPWAN LoRa technology Note: The Lora Gateway is called a Node-R in CoSol, and CoSol's gateway is upper layer gateway diagram shows node-F exchanging messages with node-G. Node-R is not shown because it only is a transceiver. explains the states the device goes through when booted: disconnected -> discovery -> associated -> authenticated -> semi-associated reactive and proactive approach makes use of EAP over CoAP (see draft-marin-ace-wg-coap-eap-02) authentication with certificates over LoRA is possible, although takes time for network management, CoOL, done at the CoRE WG Alex shows example with CoOL semi-associated state is used for SigFox. Using COSE-based object security using IEEE802.15.4 frame format over LoRA YANG model for LoRA device (draft-pelov-yang-lora-01), 19 bytes to update the full config of the device CoSOL can run over 15.4, LoRa, SigFox [Stewart Bryant, proxied by Diego] If it takes a day to authenticate, how does a service engineer install or replace and verify that it works [Alex] we are giving the possibility to do certificates, up to them to check it makes sense [Juan Carlos] 19 bytes to reconfig, but SIGFOX has MTU of 12 bytes. fragmentation required? [Alex] you can use fragmentation at different layers. Important part is that we don't optimize specifically for one technology ===> Discussion [19.25] discussion [Don] We have 15min left for discussion [Brian Haberman] Ask whether we see a problem, and where IETF can help with it. [Sri] like this area, cannot identify specific problems. We need to understand what the cost aspect is. If not a problem, we should address it, I support this work but should define precisely what problems are we trying to solve. [Alex Petrescu] 3 problems 1. IPv6 over foo, different LPWAN have different capabilities. Is this not an IPv6-over-foo discussion? 2. Remote software update 3. Security, how gets authenticated [Pascal] Don't see LPWAN as IP-over-foo. We will be looking at a global problem, architecture rather than building blocks. [Juan Carlos] See that there is work needed, no solution can fit all, need to look at it. worth giving it a thought. like presented layer-by-layer. otherwise we will have to fix problems in the future. [Samita] Thank team for great work. there are issues to solve, already deployment of IP on constrained devices. Challenges, you cannot just take an RFC and use on LPWAN. Interesting IETF work, e.g. on fragmentation. We can discuss later about management, CoAP, etc. I see more work to be done. We don't want to have a GW device [Pascal] Do you think we should have this at IETF [Samita] Yes [Subir]c thanks for presentation. A lot of use cases, since involved in other SDOs, statements that LoRA says don't need help, that's scary. Who would be using this work? Would be good to hear from those SDOs hat need helps from IETF. We don't want nobody to use it. Little bit premature. [Pascal] All of this work depends on forming a relationship with other SDOs. By Berlin, we need to prove that we have established this relationship. [Alex] Discusses with a lot of companies, are interested in getting IP over these technologies. Interest is there IMO. [Stewart Bryant, on Jabber] The paradigm is very different from what we're used to. Agree that there are issues, but needs to be looked at. [Erik] If we are going for these technologies, there is some work at the IETF to do this. Key thing is ... [Suresh] expresses concern on boiling the ocean / keeping active forever if addressing too many of the possible cases [Gabriel] ... - end -