# Minutes, IETF 99 LPWAN WG Meeting # Agenda and Meeting information ============================== Meeting : IETF99 Friday, July 21, 2017 (CEST) Time : 9:30-11:30 Friday Morning session (120min) Location : Karlin I/II, Hilton Chairs : Pascal Thubert Alexander Pelov Responsible AD : Suresh Krishnan URLs : http://tools.ietf.org/wg/lpwan https://datatracker.ietf.org/wg/lpwan/ https://www.ietf.org/mailman/listinfo/lp-wan http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-lpwan * Opening, agenda bashing (10 min, Alexander, Pascal) * LPWAN at the Hackathon (10 min, Dominique Barthel) * LPWAN Overview WGLC results and next steps (10 min, Stephen Farrell) * SCHC LPWAN Fragmentation Header (10 min + 5mn Q&A, Carles Gomez) * LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP (10 min + 5mn Q&A, Laurent Toutain, Ana Minaburo) * LPWAN SCHC for CoAP (10 min + 5mn Q&A, Laurent Toutain, Ana Minaburo) * SCHC for ICMP (10 mn, Diego Dujovne) * YANG for SCHC (5 min, Laurent Toutain) * Rechartering Items so far (10 min, Ana Minaburo) * Rechartering Discussion (15 min, Alexander, Pascal) * News from IEEE meeting (5 min, Bob Heile) Resources ========= * Agenda: https://datatracker.ietf.org/meeting/99/agenda/lpwan * Links to audio streams, meetecho and jabber: https://tools.ietf.org/agenda/99/#99-fri-0930-lpwan * Presented slides: https://datatracker.ietf.org/meeting/99/session/lpwan/ Summary for INT AREA Wiki ========================= = LPWAN = The LPWAN Working Group met on Friday 21st AM1 for 2 hours and followed its agenda as scheduled with no particular issue. * Work done at the Hackathon was presented. 2 SCHC implementations were present, one of them opensource ('''IMT'''). A number of lessons were learned, e.g. how to place the padding bits and the encoding of a non-present fields. Tickets will be opened on the SCHC documents which otherwise appears ready for mast call. The same sensors expressing pressure and temperature were used over a local '''LoRa''' network and a '''Sigfox''' network serving the city. * The LPWAN overview document `draft-ietf-lpwan-overview` passed last call and version 06 was published with the updates. Links to some ANSI references are missing for '''Wi-Sun''' but that can be edited on the way. The shepherd (Alex) will now kick off the shepherding process. * The IP/UDP '''SCHC''' document `draft-ietf-lpwan-ipv6-static-context-hc` is mostly ready for last call, which will start when the tickets above are addressed. Minor improvements were added to the fragmentation piece which is now stable but lacks implementation feedback, and has a few minor items still left to be resolved (e.g. the security section is probably not complete) * The '''SCHC''' CoAP document `draft-ietf-lpwan-coap-static-context-hc` needs a little more return from experience since CoAP is such a rich ecosystem. A need for collaboration to expressed time scale at which reliability operated (very slow in LPWANs) was identified. More discussion at the forthcoming CORE meeting. This item should not impact the SCHC spec, but maybe trigger new work at CORE to define a CoAP option. * A '''SCHC''' ICMP compression `draft-lagos-lpwan-icmpv6-static-context-hc` was proposed. Very early work, but inspiration for rechartering. * A rechartering discussion followed. Some concepts such as Radio Resource Management and interface between the Radio GW and the Network GW were proposed. A word of caution from chairs and AD was that items that impact the technologies should be openly discussed on the ML and the work should be supported by the technologies. Discussions are now expected. * A short "news of the world" presentation was given by Bob Heile, with a focus on 802.15.12 (which could include LPWAN SCHC in some future like it includes 6LoWPAN in its design now) and '''IG LPWAN''' (a pointer was given to the Mentor slides) -------------- Action items ============ Announce decision of SCHC IP/UDP/CoAP document structure. Follow-up on the WI-SUN contribution for the LPWAN overview document. Follow-up on the reviewers who volunteered to review the SCHC CoAP draft. Identify reviewers for the IP/UDP draft. Volunteers ========== * Scribes * Dominique Barthel, Ivaylo Petrov * Jabber scribe: * Diego Dujovne Minutes ------- 09:30> Opening, agenda bashing (10 min, Alexander, Pascal) * Notice new Note Well * SCHC currently described in two documents, we may want to discuss way to go. * For further meetings, short presentations welcome on activity in other related SDOs or alliances * milestones on time, but SCHC compression slightly delayed * Design Team creates before last IETF (98) and advanced rapidly. Thanks from the chairs to the DT and participants. * LPWAN overview document was LC'ed in June, completed on July 4th. Comments received. Editing done. Shephard write-up and shipping soon. * SCHC will go LC shortly * Side meeting. yesterday on "YANG of Things". Attended by members from YANG community and IoT community. * Suresh: send an updated charter so I can approve it. * Pascal: will do. 09:40> LPWAN at the Hackathon(10 min) Presenter: Dominique Barthel * Interop between existing implementations * Hacking new things * IMT Athlantique - JS and python implementaions * Acklio - Golang implementation * Saturday the tree implementations * Hacking: adding rules for Sigfox device and use it transparently, a legacy device (from Orange) was also used with some of the python code. * Results: - Padding matters. The decision the WG made was padding at the end. - Agreed on a temporary (JSON) common format representation of rules for the interop. - Variable-length fields of zero length are used in SCHC to represent absent fields. This allows to re-use the same rule for packets that have optional fields present or absent. However, CoAP uses zero length to represent the value 0 of a content. SCHC decompressor needs to be aware of this. - IMT Atlantique's implementation is now open source: https://github.com/ltn22/SCHC * Laurent: The issue of 0 length is only for CoAP Pascal: Then if only the CoAP draft needs to address that, this is fine. I would like to see this done in any case. * Pascal: for each issue, write a ticket to describe it and get resolved. 09:50> LPWAN Overview WGLC results and next steps (10 min) Presenter: Stephen Farrell https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ * * 10:00> SCHC LPWAN Fragmentation Header (10 min + 5mn Q&A) Presenter: Carles Gomez https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ * Presenting status of the document. Thanks to the reviewers. Version 06 is on the way and now the fragmentation is getting stable. Packet mode have been removed due to some issues. It might be added in a separate document along with solutions with those issues. Different window sizes can be used to optimize downlink messages. Window size is implied by rule number. * CFN can be less than 2^N-1 to account for technologies where bitmaps are limited in size to an "odd" value (to fit in link frame). * W bit carries the same value for all fragment from the same window. Useful if due to loses the receiver does not know to which window a fragment belongs. * DTag field can be added for packet interleaving. * added ABORT message to clear all fragmentation/reassembly on the link. * updates going on on GitHub since -05: * discussion item remaning: use MAX_FRAG_RETRIES with Ack_on_error? 3 options Pascal (no chair hat): Open a ticket. I would like the discussion on the ML and issues on github. I would like to see those discussions also in the security section. Also list this point in the security section in the draft. Chairs: Who has read the draft? about 12. Ana M: waiting for resolution of fragmentation issue just mentionned, then we are done. Alex: How many implementations (including the fragmentation) in the works? 2 10:10> LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP (10 min + 5mn Q&A) Presenter: Ana Minaburo https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ * differences since -03 (Chicago): defined a generic framework. - UDP/IPv6 application described in separate section. - match-mapping now accepts arrays - padding: discussion at hackathon resulted in decision to have padding at the end of data. * redefined some terms: Dev, NGW, App * new column in rule description: field description, position and direction * Variable length field of zero length. Special interpretation for CoAP. SHould this be here or moved to the CoAP document? Pascal: We still discover things, so if we continue to change this document, it can last forever. So I would be ok to see this in CoAP draft. Carsten Bormann: would love to have rough idea why this number encoding makes sense. If code space includes length, could use a code point to signal the absence of field, different from code to signal presence and length of zero. LT: Remark. When we put send 0 length in URI-Path, it could be useful for rule selection. When we have a rule with 4 elements for URI-Path, this way we could sent something with 3 elements if we want. Pascal: Doesn't it change the semantics LT: It's a different behaviour of the nature of the option. There is no ambiguity. Alex: You are talking about something very advanced, but we are not sure if it's going to be used. Maybe we should not the document over this. LT: I agree. We can solve it in the CoAP draft. Pascal: lets open a ticket on this and discuss on the mailing. Consider proposal by Carsten to encode absence and zero-length differently. Pascal: congrats on great work done in record time. 10:20> LPWAN SCHC for CoAP (10 min + 5mn Q&A) Presenter: Laurent Toutain https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ * tools described in "SCHC for IPv6 and UDP", specialization for CoAP. * can further compress already compact CoAP fields. * to be discuss at CoRE: some time constants assumed by CoAP, conflict with time constants of LPWAN networks: new CoAP option to set a time scaling factor? Not sent over the radio, elided by SCHC * Pascal: put examples/recommendations in Appendix. So that reader can understand claimed compression ratios, etc. LT: We already have some examples, but we can add more and study how people are going to use it and add more clarity on that poinit. Alex: It is very important to discover real use-cases and how things will behave in those cases. As the case of timeouts, such feedback would be very useful. LT: If we need to add new options to CoAP, this WG might not be the best place for this. Alex: Of course, that would be done in CoRe, but we need to identify them. Carsten: come to the CoRE meeting with some slideware. Have experience with this. Already showed up with DTLS. 10:30> draft-lagos-lpwan-icmpv6-static-context-hc-00(10 mn) Presenter: Diego Dujovne https://datatracker.ietf.org/doc/draft-lagos-lpwan-icmpv6-static-context-hc-00 * open source implementation available * SCHC compression for Echo Request/Reply, RS/RA and NS/NA. Still want to work on Redirect compression LT: As you reused the rule-id field, did you put semantic in it? Diego: Yes LT: It is very difficult to apply such kind of semantics, as the size is not defined for all technologies. It will be defined on a per-technology or deployment bases. Also if different protocols put different meaning on the rule-id, this can become a problem. LT: not recommended to apply semantic on RuleID Alex: is this statement written anywhere? LT: not sure Alex: please do, otherwise it will show up again. * used one bit of Rule ID for ICMPv6/UDP, and one for local/global address * shows comp/decomp rule for ICMP messages. Pascal: you used all bits for a few messages, so no room for future expansion. The first message I would implement would have been ICMP error reporting. Pascal: let's have a discussion on the mailing list about which ICMP messages are of interest. Alex: not on our charter today, need to consider this. Suresh: If the current items are finished, we could have a short discussion, but as there are still unfinished items, for now let's keep it to this. Ana: will later present on-going discussion on the mailing list. 10:39> YANG for SCHC Presenter: Laurent * shows content of rule and JSON representation. 2500 bytes in this example. * CoMI is CoAP based, can be compressed with SCHC for over-the-air transmission of the rules. Carsten: The JSON you showed is big and doesn't fit, so the Yang-CBOR is better, but maybe what we need here is ??. I am sure this can be made to work with YANG, but I am not sure if the needs will not be beyond what Yang-CBOR can offer. Maybe also the CBOR patch mode will be enough. CBOR and patch command LT: YANG is represention that then leads to CBOR. Carsten: If we use YANG, it will be expected that we will use Yang->CBOR. YANG is very nice and you can transport a sofa as well, but I think we need ??. Could do better than CBOR encoding of YANG. Don't start with YANG at all. Alex (chair hat off): I think YANG is a good formalism that explains the model. We have a way to map this to the very efficient CBOR encoding. Then we have the CoMI that can be used to transport this. But I don't think it will be good to invent a new mechanism for sending this. Laurent: dont create yet another prtocol. This will take one more bit to transmit. Pascal: reuse work and tools developped for YANG. Less expensive to reuse existing tools than creating new stuff. Pascal: how is the relationship with the YANG doctors? Laurent: There is a lot of work to be done for the YANG modeling, so I will have to talk with more people as this is somewhat new to me. Maybe YoT will be a good place to discuss this further. 10:49> Rechartering Items so far (10 min) Presenter: Ana Minaburo * on-going discussions on the mailing list - ICMP compression. Very active, about 10 contributors. - SCHC over specific LPWAN technologies. No input. - Security. No input either. - Rule-id management. Ranges per protocol/fragmentation or not. Alex: Does it seem reasonable to have this in SCHC over foo? Ana: Yes, this is a possibility. - YANG data modeling for SCHC Sri: radio resource management on the gateway. One work item that is very important for deployement. Also no standardised interface between GW and NS. Standardizing one interface to support many radio technogies would be immense use. Even LoRa alliance not standardizing this, opportunity for IETF to do it. Pascal: I would like to see a discussion about this on the ML, so that more people can join this discussion. Suresh: need to figure out what form this is going to take. Document stuff other people do or .. Second thing is very good relationship with other SDOs, don't want to step onto their turf. Discuss with them. No formal liaisons. Be careful about doing this. Make sure other SDO's understand we are interested in this. 3 steps to meet. << can anybody summarize what Suresh'es 3 points were ? >>> Sri: The GTP we never managed to push IPv6 as it was already deployed?, so we want to avoid this kind of problems. Pascal: need for an architecture document? Raise your hand if you think we need one? No hand. Alex: we have comp/decomp now. This lives somewhere in the middle of an environment. Maybe need to describe how all the parts are orchestrated. Also need to describe scenarii (e.g. new device coming in). Pascal: You expressed much better my ideas. Alex: describe how the whole system works. Juan Carlos Zuniga: yes, need for such description. Wasn't sure what "architecture" you were talking about. Pascal: a number of functions that we care for. A map of how they fit together. Juan Carlos: I do see value in this document. But right now we are still talking about Yang, ICMP, etc. how do you see this in time? Is this after the other things or it will evolve with them. Alex: should go together. We have SCHC and need the rest to make it live. Recommend pragmatic approach. Develop this document in parallel with technical development. JC: Do not publish this document until we finish all the work. Pascal: We did this in 6tisch and it gave us a map that was very useful. During the process we discovered how to do some of the things that we envisioned. Alex: coming back to the list shown by Ana. What items are of interest to Sigfox? JC: I see value in almost or all of them. ICMP - yes, ... rule-id - I think we can discuss where and how this is going to be handled. Alex: can we expect a SCHC over Sigfox document from you? JC: Yes. Pascal: Are there items that we didn't discuss. (no) So we will continue on the mailing list. Alex: question to AD (Suresh). We are pretty much on target. How should we move forward? Suresh: We should work on the list and have the items resolved by Singapore. Ship the SCHC by Singapore and there we will discuss more. I guess there we will hear more from some of the technologies, but I would like to have more work done before that, so that you are ready before that. Pascal, talk to the IEEE people, Alper from LoRa, etc. 3GPP are also missing, so I will try to do something on that. If we miss one, they are going to do something else. Try not to draw resources from the people writing the documents. Alex: when we ship the UDP/IPv6 document, is it enough to trigger recharter Suresh: I think you are progressing quite well. You are a little bit late, but I expected this due to the very agressive schedule. 11:05> Rechartering Discussion (15 min, Alexander, Pascal) << notes fused in previous section >> 11:12> News from IEEE meeting (5 min, Bob Heile) * 802.15 meeting last week * Pascal: LPWAN interest group * 15.12 status update. - example of 6lo - discussion on management place configuration (Comi, etc.) * interest group (similar to an IETF BOF) on LPWA. Discussed suitabilty of various ascpets, modulation, topology, . See doc 802.15-17-451, publicly available. Alex: What is the license? Can we put it on our repository or put a reference to it? Bob: Yes, the document is open to public, there is no problem with that. * 15.4-2015 just completed. New amendments. Could be useful to 6TiSCH. Just starting, send your comments/requirements in. Pascal: IEEE 802.15 considered 6LoWPAN so far. Now we have SCHC. Of interest to LPWA interest group? Bob: send presentation to Mentor showing your idea of the concept Pascal: I see the user use ... so there is a lot of power. Sometimes the devices are not that constrained in terms of ... so the application * distinction between .4 and .12. .4 is for stuff on the market, not to break compatibility. .12 introduces new stuff. Alex: Do you think you can write a draft: schc-over-802.12.. Bob: Yes, I will take that as an action. 11:22> AOB * none 11:23> Adjourn