Minutes IETF104: lpwan
minutes-104-lpwan-00
| Meeting Minutes | IPv6 over Low Power Wide-Area Networks (lpwan) WG | |
|---|---|---|
| Date and time | 2019-03-26 15:10 | |
| Title | Minutes IETF104: lpwan | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-03-27 |
minutes-104-lpwan-00
Meeting : IETF 104 Tuesday, March 26, 2019 Time : 16:10-18:10 Prague (CET) time Tuesday Afternoon session II (2H00min) Location : Room Grand Ballroom, Prague Hilton Hotel Agenda : https://datatracker.ietf.org/meeting/104/materials/agenda-104-lpwan Meeting Slides : https://datatracker.ietf.org/meeting/104/materials.html Etherpad : https://etherpad.ietf.org/p/notes-ietf-104-lpwan?useMonospaceFont=true Meetecho : http://www.meetecho.com/ietf104/lpwan/ Audio stream : http://ietf104streaming.dnsalias.net/ietf/ietf1041.m3u Chairs : Pascal Thubert <pthubert@cisco.com> Alexander Pelov <a@ackl.io> Responsible AD : Suresh Krishnan WG URLs : http://tools.ietf.org/wg/lpwan/ https://datatracker.ietf.org/wg/lpwan/ https://www.ietf.org/mailman/listinfo/lpwan Note takers ------ Dominique Barthel (part time) Fabrice Theoleyre Ivaylo Petrov Agenda ------ (This part is for the agenda. The Minutes section is below) * [16:10] Administrivia (chairs) [10min] o Note-Well, Scribes, Agenda Bashing o Status of drafts o Rechartering status (with Suresh) * [16:20] draft-ietf-lpwan-ipv6-static-context-hc (Dominique) [15min] * [16:35] draft-zuniga-lpwan-schc-over-sigfox (Juan-Carlos) [ 5min] * [16:40] draft-petrov-lpwan-ipv6-schc-over-lorawan (Ivaylo) [ 5min] * [16:45] draft-minaburo-lpwan-nbiot-hc (Ana) [10min] * [16:55] draft-toutain-lpwan-schc-yang-data-model (Laurent) [30min] * [17:25] draft-gomez-rto-considerations-lpwan (Carles) [10min] * [17:35] draft-ietf-lpwan-coap-static-context-hc (Laurent) [10min] * [17:45] draft-barthel-lpwan-oam-schc (Dominique) [10min] * [17:55] Status on IEEE 802.15 and 802.15.4w (Charlie) [10min] * [18:05] ESP HC [ 5min] * [18:10] Rechartering status (Chairs) [ 5min] * [18:15] AOB, Adjourn [QS] Minutes ------ [16:10] Administrivia (chairs) [10min] * Note-Well, Scribes, Agenda Bashing * Status of drafts * Rechartering status (with Suresh) * Alex presents an historical view of the achievements of the WG. lpwan keeps on organizing 5 or 6 interim meeting between each IETF. Please join us. * Congratulations for the document of SCHC * [16:20] draft-ietf-lpwan-ipv6-static-context-hc (Dominique) [15min] * draft on the SCHC * What this draft is: Header Compression generic engine, a fragmentation protocol and the application of the compression to the UDP/IP headers * Since Bangkok: presentation of the fragmentation to LoRa alliance (Nov 20) * Fragmentation MIC optional again (while integrity checking is mandatory, MIC is one way of doing intergrity checking) * Reworked the text with Charlie Perkins inputs. * Partial review received from Carsten (on behalf of IoT-Directorate) -> ongoing work. * 9 attendees for Hackaton@ietf104: * work done: made the code easier to use (documentation, tests, etc.); added additionnal functionalities * some parts are not well interpreted: we inserted examples in the appendix * source of information for the data model * Charlie: * Dominique: we did, it was included as an attachment. * Carles: email not cc'ed to the ML * * [16:27] draft-zuniga-lpwan-schc-over-sigfox (Juan-Carlos) [ 5min] * Update of the latest version of the draft * Public specifications on Sigfox architecture (long discussion but now they are) * Patrick Wetterwald: what is the meaning of 'public'. The text is available but IPR is stil specified as SigFox. * Juan Carlos Zuniga:it's public since anbybody can download and read it. It is also mentioned that the IP is royalty-free, although this is probably not the forum to have this discussion. * Pascal: adoption for all three technology-specific SCHC documents will be done with the recharter of the WG. We will see at the end of the meeting and the data model. * -> call for adoption * Suresh on jabber: agree that this is not the forum. On the call for adoption, go for it. * * * [16:34] draft-petrov-lpwan-ipv6-schc-over-lorawan (Ivaylo) [ 5min] * What has changed since ietf103: * more contributions from LoRaWAN alliance members (O. Gimenez and M. Le Gourrierec) * comments of Shoichi have been addressed: terminology, security * parsing of the current improvements * Improve termnology and security considerations * Next version will have: Ack-on-error fragmentation * How to transfer part of the header to the fport * How to support the DLMS as well as CoAP * Addressing the multi-fragment windows for classes B and C devices (downlink) * Did someone experience SCHC for LoRaWAN? We are not sure to cover all the use cases, and we would appreciate a feedback. Please solicit us. * Inputs about Rule IDs * Pascal: fports -> some people from LoRa Alliance may help [16:42] draft-minaburo-lpwan-nbiot-hc (Ana) [10min] * describes use cases: in IP mode, non IP mode. We inserted use cases for SCHC in the draft * we started to define each fragmentation mode for each use case Use Case IP packets over USer Plan * define where SCHC can be placed in the 3GPP Architecture (as for RoHC)in the PDCP layer * layer RLC gives segmentation except for transparent mode * In a transparent mode for SCHC in the user mode SCHC may be used but it must be investigated * Rule ID size is not a problem, PDU's over 1300 bytes Use Case IP / Non IP packets over Control Plane * In the control plance, it is like sending a SMS, 11 to 25 bytes, fragmentation is needed * CoAP (wihtout IP) can be used for management, SCHC can be used here * Rule ID may be of 2 bits only Use Case IP / Non IP packets on the non IP based * on the NON IP based SCEF can tunnel to SCHC * Rule ID size does not have a problem * Fragmentation need to be study [16:46] draft-toutain-lpwan-schc-yang-data-model (Laurent) [30min] * on-going work since the beginning of the WG * in the SCHC draft, Rules are described in an abstract way, not formaly specified * Now is the time to define them accurately, as well as their representation. * Will use YANG and CoreCONF, with CBOR representation to have a compact representation * goes through content of a Rule. * the Field ID has to be unique among all fields of all protocols that are to be compressed * Target Value can be a number, a string or even an array (typically used for the match-mapping operator) * CDAs currently don't have arguments, but they could in the future. * Rule ID can be represented with a variable unber of bits (entropic coding) * example with the YANG model * representation of the entry values: could use new identities (SID). But SIDs can be large (e.g. 4 bytes) * one possibility is to have a short representation by an enumaration. Using samll negative and small positive values will provide a short CBOR representation * things may change because still work being done on CoreCONF * Alex (chair hat off): no SID will be added to this representation, don't worry * Pascal: is enum value the shortcut? * Laurent: indeed. * learning YANG on this use case. [17:01] draft-gomez-rto-considerations-lpwan (Carles) [10min] * typical lpwan technologies provide a very large RTT (seconds to hours). Default timeout values for TCP and CoAP: a few seconds * shows results of theoretical studies, on LoRaWAN and Sigfox. * for LoRaWAN different receive windows are also considered. * the CoAP timeout may be below some RTT in LoRa (even in an ideal case) * Laurent: the messages shown are empty, this is a best case. * Carles: we assume a minimal payload of 4 bytes is used. * Laurent: In SF12 it might take ~2s to send 50 bytes of data. * For Class A devices, downlink response may stay for a long time in a buffer at the gateway (if the gateway misses some transmission opportunities). * Next opportunity may have to wait for the next uplink, which may only happen hours later depending on the application. * This draft proposes a dual RTO algorithm. Transition between the two RTO values. * * Juan Carlos Zuniga: are you planning to expand the scope to other technologies, such as multihop IEEE 802.15.4, which is considering using SCHC in the future? Or do you want to limit it to lpwan? * Carles: Focus of the doc would be LPWAN. Some doubts as to whether LPWAN is the good home for this doc. Purpose of this presentation is to find out. * Pascal: related to the work done here, but certainly more a Transport issue. * Pascal: still very important data for the schc-over-foo docs to provide expected * Mina Rady: RTO values to be included in the protocol or configurable from the application layer. * Carles: probably different setting for each technology. * Alex: your figures show that CoAP timers timeout routinely with the LPWAN technologies. * Suresh: this draft is outside of what was discussed in the recharter. * Alex: definitely. Of interest to the group but not in the charter. [17:20] draft-ietf-lpwan-coap-static-context-hc (Laurent) [10min] * document unchanged since the last meeting. Waiting for reviews. * Feedback of the Hackaton and the reviews: the variable length fields compression is not correctly understood * Indeed, UDP and IPv6 don't have variable length fields! * Suggestion to move a CoAP example into an Appendix of the SCHC draft. * Dominique Barthel: the other draft has a generic description of the compression technique that includes variable length fields. But we don't have an example for that, and how the variable length fields are processed. The SCHC draft has actually three parts, generic compression engine, fragmentation protocol, and application of generic compression to UDP/IPv6. Could have an example of variable length fields in an Appendix, and this example could be a CoAP example. * Pascal: but the draft has UDP/IPv6 in its title. Readers don't expect to see CoAP stuff. * Dominique: readers can also read this doc to understand the generic engine, and they are missing an example of variable length field compression. * Pascal: don't delay SCHC draft with changes. * Dominique: this is just an example in an Appendix. We're going to respin the document anyway following the IESG reviews. It's currently in "Revised I-D needed" status anyway. * Pascal Thubert: we need early reviews from experts in CoAP. * Alex: is the document ready and good enough or do we need a feedback from actual deployments? In the second case, it would need more time. * Alex: who has read a version of this daft? 10 people have read one version of the draft * Alex: who votes for shipping this draft, and potentially respinning it later? about 10 people (same ones). * Alex: who thinks we should rather wait? nobody * Suresh (AD hat off): please ship it. [17:29] draft-barthel-lpwan-oam-schc (Dominique) [10min] * historically: two separate drafts (@ietf100 and 101) which have been merged * Do simple basic stuff ICMPv6, ping, traceroute, open to other use cases * what has to be forwarded through the lpwan, what needs to be proxied * We expect some discussions on the ML * We want to implement that with openSCHC * Charlie: has it to cross the Internet? * Dominique: the response might be the next time the device wakes up. We might want to just know that the device is seen as expected. We may use codes to adapt the behavior. * Laurent: If we create a new code, there might be a problem with devices that currently don't know it. * Charlie: this is not something we expect to do (?) * Dominique: This is the discussion that we want to have. [17:37] Call for adoption * schc-over-sigfox (?) * in favor: about 10 * opposed: none * LoRaWAN * in favor: about 10 * opposed: none * NBiot * in favor: about 10 * opposed: none * YANG data model doc? * in favor: about 10 * opposed: none * will be pushed to the ML * Suresh: I haven't seen any work on this. Who has the request? * Ana: * Edgar: NB-IoT networks are IPv4 only. Many external networks are also IPv4 only even if the operator networks are IPv6. I don't find it very difficult to use SCHC to compress IPv4. ... I don't know what we are targeting. If we are interested in legacy, we should handle IPv4 as well. Or maybe we can do that later. ... Half of the networks are IPv4. * Pascal: ?? * Edgar: I don't have a recommendation. I think it is a good thing to do, but I don't know if it is the right thing to do. As a personal opinion, I think we should address legacy. * Suresh: will be happy to share result of survey. Not sure how .. will scale .. number of IPv4 <????> * JCZ: SCHC NAT? * Suresh: not at all. I don't see how v4 can scale the way we want. Idont see v4 cutting it. * Pascal: Why don't we start the work and if we see that it's good, we can recharter a second time, right? * Suresh: usually need a draft, such as problem statement, to recharter. Could add a milestone in the charter so that don't have to recharter later. * Pascal: what's the feedback on our next proposed charter? * Suresh: we have to go through the process. Personally I am good, but we need to go through with the process. * Sothy: get input from 3GPP regarding v4. * Suresh: if you want, I can send liaison statement to 3GPP to get an answer on IPv4. * Alex: <summing up the discussion> * [17:53] Status on IEEE 802.15 and 802.15.4w (Charlie) [10min] * 15.4w is LPWA. Their doc is currently in Letter Ballot, which is similar to WGLC at IETF. * 15.4 is Field Area Network extension. More praamters in a table for QPSK, etc. * 15.10a amendment to routing document, coudl e of interest ot this gruop but is Layer 2 routing, up to tns of thousans of devices. * Coex between 11ah and 15.4g, precipated by 15.4z (believed to be UWB). * 15.12 is to make 15 as nicely programmable as 11. APi to layer 3, very popoluar in 11. Philosophy in 15 is to make device simple and push everything to higher layers. Now want to make 15 much more like 11. * 15.4y more security mesaures to 15.4. Ask Tero Kevinen, he is an author * Tero: 256 bit AES. Getting ready for the future. * Charlie made a SCHC presentation to 15.4. Show the slides here. Question about which fragmentation to use (15.4 has its won). * Charlie figured minimal fragm configuration with SCHC. * 15.4 has integrity checking (FCS field), so Charlie expects to have MIC=0. The two mechanisms are redundant * Dominique: Each fragment is encapsulated in a frame. So, it depends on what you designate by 'frame'. SCHC does integrity protection of the full Message. * Dominique: we call Frame what is below SCHC, that why we don't want to call our MIC a Frame Check. * Pascal: we can dicusss about that on the ML * 15.4 MIC is cryptographically secure. Typically done on-chip. * SCHC "MIC" is a checksum, should be called FCS. * * * [18:06] ESP HC Tobias Guggemos [ 5min] * this is about IPsec. * ESP header compression (security since ESP encrypts the payload) * some variables are already in the Security Association (already a separate channel) * other variables are to be calculated * Finally, we reuse the same principles, and we compress 44 headers with 9 context values. * Alex: did you find the description of SCHC featured enough for what you want to do, without adding too much? * Tobias: yes, it was easy to apply to our security scenario [17:40] Rechartering status (Chairs) [ 5min] * The OAM for ping in green in the slide, document to be included in the charter * Goran: The SCHC header compression of CoAP has a very good part for OSCORE. There is a very compact protocol for key exchange (EDHOC) that might be of interest. * * * * * [18:12] AOB, Adjourn [-5min]