# Minutes, IETF 100 LPWAN WG Meeting # Agenda and Meeting information ============================== Meeting : IETF 100, November 11 - 17, 2017, Singapore Time : November 13, 2017, 9:30-12:00 SGT (150min) Location : Olivia, Raffles City Convention Center, Singapore 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/lpwan http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-lpwan * Administrivia (20 min, Pascal, Alexander) * LPWAN Overview (10 min, Alexander) * SCHC IPv6/UDP - compression and fragmentation (35 min, Laurent Toutain, Carles Gomez) * SCHC CoAP (5 min, Laurent Toutain) * SCHC ICMPv6 (10 min, Dominique Barthel) * SCHC over LoRaWAN (15 min, Ivaylo Petrov) * SCHC over Sigfox (15 min, Juan Carlos Zuniga) * ETSI LTN and LPWAN-CSS (30 min) * News from IEEE meeting (5 min, Bob Heile) Resources ========= * Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-lpwan/ * Links to audio streams, meetecho and jabber: https://tools.ietf.org/agenda/100/#100-mon-0930-lpwan * Presented slides: https://datatracker.ietf.org/meeting/100/session/lpwan/ Summary for INT AREA Wiki ========================= = LPWAN = The LPWAN Working Group met on Monday 13th for 2.5 hours and followed its agenda as scheduled with no particular issue. * A discussion of the LPWAN WG rechartering concluded that the group should focus on SCHC-over-FOO, and BAR-over-SCHC. FOO could include the four baseline technologies, or additional that may manifest themselves. BAR may include applications sitting on top of CoAP, such as LWM2M, CoMI or other. We consider setting up a repository for CoAP pcap traces, which will be used for profiling the applications. Additional items for the rechartering include the Data Model of the SCHC compression contexts and the minimal context provisioning protocol, as well as work on ICMPv6. * During the discussion on ICMPv6, it was observed that the work is two-fold. On the one hand, we need to describe how we treat ICMPv6 messages, such as whether we send the ECHO-request all the way to the device or proxy at the gateway, and whether we need new ICMPv6 codes in the ECHO-request to indicate the expected behavior. On the other hand, we need to specify new ICMP message codes to cover new situations that are related to the function placement in LPWAN networks, e.g. Error:Non-compressible packet. Many questions arise for ICMPv6 error messages, depending if the erroneous message is compressed or not, and which entity should receive the error message. Finally, standard traceroute uses random UDP ports for route mapping, which would result in un-compressible messages (messages that match no context or that match generic contexts). * Statuses of the drafts. * LPWAN Overview (draft-ietf-lpwan-overview) submitted for publication to IESG. Two directorates have been notified (IOTDIR and INTDIR), with reviews expected by mid-December. * SCHC IPv6/UDP (draft-ietf-lpwan-ipv6-static-context-hc) is stable, with some final polishing and corner cases to be cleared in the fragmentation operation. A 2.5h follow-up meeting was scheduled on the next day, and the identified corner cases were solved. Once retrofitted in the document, SCHC IPv6/UDP will be ready for last call. * SCHC CoAP (draft-ietf-lpwan-coap-static-context-hc) requires additional clean-up and validation using BAR-over-SCHC examples. This will be satisfied once the CoAP pcap repository is set up and the group has had some time to evaluate the provided examples with the compression. This will take at least 6 months to complete. * Non-WG documents for SCHC-over-FOO were presented for FOO in [LoRaWAN, SIGFOX]. * A presentation of the ETSI ERM TG28 was done by the Chairs on behalf of TG chairs with the intention to dig into ETSI LTN in the next meeting. * Overview of IEEE meeting in Orlando was given by Bob Heile. Of interest is a new PAR on work on new PHY for LPWAN. Also, a study group on next-generation security was formed, as well as extensions to Field Area Networks. * During the Hackathon, several of the participants have improved the open-source SCHC implementation. Action items ============ * Create repository for CoAP packet traces. * Restart bi-monthly interim calls starting from December 5th, 2017. * Prepare Hackathon for IETF 101. Volunteers ========== * Scribes * Dominique Barthel, Rahul Jadhav * Jabber scribe: * Rahul Jadhav Meeting notes ========== * [09:32] Administrivia [20min] o Note-Well, Scribes, Agenda Bashing will take some time on the rechartering. May extend past the alloted 20min. Bob Heile will report on IEEE. Juan Carlos: [Pascal] Will talk about rechartering, overall item will take about 30/35 mins .. o Status of drafts (WGLC / forthcoming WGLC) new milestone just achieved. Submitted overview doc to IESG. a few months late on the SCHC draft. Mostly because of work on fragmentation. Will hold a dedicated meeting to review the corner cases Suresh: expect IETF LC by end of year. Pascal: Samita already submitted request to IOT Directorate for review. Alex shows timeline since WG creation. interim meetings .. followed by hackathons .. open source implementation by next IETF Rechartering items: - SCHC-over-FOO documents (one doc per technology), two examples to be presented in this meeting Can have more docs based on what people want to use SCHC on.. - ICMPv6, - Data Model for SCHC contexts (YANG model improved over the Hackathon at this meeting) - minimal protocol for provisioning static context ... looking for minimal context sharing protocol. followed by extensions. Pascal: for each item, do we have critical mass? - Good number (??) of hands for participating in review of SCHC-over-Foo - ICMPv6 - [Review of ICMP6] half a dozen hands - [Data model]: Interests? half a dozen(7 hands) Juan Carlos: had offline discussions but not many people are aware of what needs to be done in this work item. Juan Carlos: not much info about work beingn asked about. So no surprise not many hands. Alex: there is already a yang model out there and people can have a look at it. Pascal: will present at the next interim meeting. Alex: Minimal protocol for context provisioning will need to be figured out .. [Juan]: are we planning on discussing arch ? [Alex]: Not detailed arch .. super minimum use-case .. between end device and gateway .. [Juan]: try to base as much as possible on overview doc .. try to map on it. help people understanding. [Pascal]: explaining background on overview doc. terminology/devs/high level arch overview. Laurent Toutain: doc on SCHC for CoAP. Could use rechartering to introduce work on CoAP for LWM2M, etc. Hannes: like looking at CoAP flows. like to see some work on coap compression. independnt of lower layers.. people are using coap without using ip layer in some cases. information document will help. [Alex]: We have wi-sun in the charter. WiSUN is IP-enabled, still interested in compressing CoAP even though doesn't need to compress IP. [Pascal]: SCHC over foo should have recommendation for app writers. Section in SCHC-over-foo for app writers would be useful. [Suresh]: I dont mind doing coap over other network/link layers... but priority should be over ip. keep benefits of tighter integration. [Juan]: worth capturing the interests [Pacal]: we welcome drafts on items of interest. Like CoAP over other link. Or Bar-over-CoAP Need to see activity to make it a charter item. * [10:00] draft-ietf-lpwan-overview [10min] o LPWAN Overview - Doc status and updates Alex preseting on behalf of Stephen. Add Charlie to the contributors. Excellent doc for people who want to understand fundamentals before going into details. Based on 6 prior individual drafts. was submitted last week to IESG for publication. Recommend that authors of future documents use terminology from this document. Alex thanks everybody who contributed. * [10:06] draft-ietf-lpwan-ipv6-static-context-hc o Update on IPv6 compression (Laurent Toutain) [10min] Main change in the context of variable lengths fields. New frag state machine More stable now. Explaining changes to variable length fields. explaining rationale for fixed length versus variable length fields. All examples in the draft have been update with this new rule format. Defined shorter names for the 3 ACK modes (per interim meeting). Reminds of 3 modes: No ACK, ACK on error (only reports on missing fragments in window), ACK always. Two special values for Fragment Compressed Numbers: All-0 (meaning all bits in FCN are 0) for last fragment in window, All-1 for last fragment of last window (ie last frag of overall msg). Goes through example. ACK contains a bitmap, one bit per fragment. Last window usually has less fragments that others. Use lowest FCNs. Optimization of ACK: one does not need to send all bits if they are all ones. Especially beneficial to avoid padding Need to send at least upto and including the last 0 bit, further (1) bits can be ignored. Sender knows the expected bitmap size so it can reconstruct the full bitmap. Extra trick: use the long representation to convey extra meaning. For example, to represent an Abort message. If it were a normal ACK, the optimisation would have sent the shorter representation. If longer representation is received, it's got to be an Abort. Abort is full (non-optimized) all-1 bitmap plus extra FF byte. Another trick: send an empty fragment with all-0 FCN to solicit ACK again. Saves sending the fragment data. Still to be done: - finish the detailed description of Abort and ACK bitmap optimisation - provide examples of this - add description of the padding Need to make text more clearer especially on padding aspects. [Juan]: State machine was moved back n forth between annexes .. do we have editorial comments anywhere? [Laurent]: The state machine now is in the document body and it will be moved to the appendix and the text description will be left in the main body of the document... [Pascal]: Once these changes are done, do you think it will be ready for last call ? [Laurent]: yes o Update on SCHC fragmentation (Carles Gomez) [10:22] [25min] Since prague two revs of the docs. Laurent provided many details for 07 ver. Explains plan of 08 ver. Side meeting tomorrow to review corner cases on fragmentation. (Butterworth, Tuesday 14th, 9:30-12) ACK always mode: draft has two parameters Implementation exp revealed that only MAX_ACK_REQUESTS was used. ACK on error: added MAX_FRAG_RETRIES. Implications in Security Considerations section. Added examples in the Appendix. Next (for -08): uncovered a problem in downlink fragmentation and ACK always mode. Deadlock on technologies where downlink transmission only immediately following an uplink, which will not happen. Idea is to add a timer. On expiration, send ACK again (uplink) to unlock downlink transmission. Other discussions on going: what if MIC check fails but FCN sequence apparently correct? This should normally not happen, but do we want to specify what to do if this situation does happen anyway? Discuss whether there is a need for final ACK ... these are the corner cases to be discussed tomm. [Juan]: is this the same sitaution as retries in the last window? [Carles]: No. Previously, problem was not clearly specified rgding retries in last window. [Juan]: So right now the spec only relies on the SCN ? [Alex]: Shows up an instance on slides and questions whether this is an transmision error ... MIC check is failed/bad. [Pascal]: The situation we are talking about is CRC false positive. [Dominique]: We should not spend so much time specifying what to do when something happens which (almost) never happens. Just make sure state machine does not hang forever. [Pascal]: It may happen .. detect and abort. [Dominique]: agree. [Laurent]: Do we specify CRC32? regarding <> on this generic doc or do we rely on SCHC-over-foo for such information? Thanks to the context it is possible to have such information in the context and so a default algorithm can be overwritten. [Carles]: [Pascal]: SCHC sdould have defaults and SCHC-over-foo should overrides the defaults if needed. [Alex]: happy with the discussion we had on the ML and at the interim. narrowing down to final corner cases, which are super-rare and specific to the link tech. cites some examples.. * [10:41] draft-ietf-lpwan-coap-static-context-hc [05min] Not much work since last meeting. Most time went on fragmentation. All the good stuff needed for CoAP has been moved to the ipv6-schc draft. Now to study CoAP traffic (COMI, LWM2M) and derive rules, improve compression [Alex]: We might need some kind of informational doc specifying what traffic traces gets compressed. [Alex]: who is itnerested in Bar-over-CoAP? a few hands (~6). [Alex]: more reviewers/ontributors from the CORE WG? [Carsten]: advertise on core ML and ask people to contribute. * [10:45] draft-barthel-icmpv6-schc [10min] [dominique] ICMPv6 is necessary for IP network (ping , traceroute, ..) Rationale for ICMPv6 in this group .. ICMP comes attached with IP. based on RFC4443 (basic ICMPv6 format), may be 4884 (extended format) 4443 defines the message format and 6 messages (4 for error and 2 for for ping6) Want feedback about scenarios, expected behaviour on IP-enabled LPWAN networks. If we decide something should not behave as usual, we should clarify the rationale, so that people do not get into same thing. Explains scenarios that were considered in the doc.. [Laurent]: Explains reason for having a new Echo Request code point which specify to propagate into the lpwan network or not. [Dominique]: WG needs to decide whether to work on this.. [Pascal]: We need it but its separate doc .. (context to laurents comment) .. We need echo, and introduce .. need to discuss this on ML .. can be used for dos attacks etc.. [Juan]: Yes this work is definitely relevant to WG. clarifies pascals questions .. [Dominique]: Seeks feedback on the scenarios from the WG. Discuss on ML (ppt continuation) .. explaining new technical issues.. [Diego]: how is the draft different from lagos-lpwan-icmpv6-SCHC [Dominique]: We have acknowleged this draft. Was mostly about ND. In this draft, not interested in ND. First goal to list the scenarios, what we expect to happen. Welcome to join the work. [Juan]: we want to limit to star topologies.. [Pascal]: good to know corner-cases where it might result in icmp errors and how can this doc help there.. Great document and really wish to reach out.. [Pascal]: make sure to align with -overview terminology. * [11:03] draft-petrov-lpwan-ipv6-schc-over-lorawan [15min] Ivaylo presenting remotely... LoRaWAN has variable payload size Draft will define timers and Max retries count, rule ID size and placement Explains draft goals and structure.. Payload size may change during fragmentation (behavior must be defined) [Ivaylo]: Is the WG interested in continuing this work? [Pascal]: SCHC-over-foo is major item for recharter ... this would be imp so please stay with us. []: You mentioned several device types ... how compressor can know the device types? ]Alex]: how anyone knows generic properties .. alex clarifies. [Ramos?]: There are some radio related parameters .. they cannot be easily mapped to outside the radio network. [Pascal]: are you telling there are some parameters that need to be handled in the radio network-side?/ [Ramos?]: atleast there are some relevant parameters. [Julien]: terminology issue: LoRa *radio gateway* does not know about the *LoRaWAN network*. [Alex]: some arch/radio specific optimizations eventually.. [Pascal]: fragmentation and compression may not necessarily be from the same box. * [11:17] draft-zuniga-lpwan-schc-over-sigfox [15min] Early draft. Mostly to signal intention to work on this. Lot of discussion on whiteboard and lot of things have not gone into draft. Will work on compression first, then fragmentation. Join the side-meeting tomorrow if interested in fragmentation * [11:23] ETSI LTN and LPWAN-CSS [30min] Pascal presenting on behalf of Benoit Ponsard. Explains different ETSI works (ERM-TG28) in the context of lpwans - LTN: 4 technologies, including Sigfox. - LPWAN-CSS: includes LoRa. - Mesh networks: looks like WiSUN. Timeslots and channel hopping. ETSI is considering pretty much every tech that we are working on .. checking how it can improve link efficiency. * [11:32] AOB [10min] [Robert] : Two ongoing projects which approved .. 1) 15.4s ease of adding mgmt tools .. Dec 5th is the review meeting date in IEEE 2) preparing 15.4 (2015) rev1 .. started input on what needs deprecating, what needs enhancements. [Alex]: How are these requests from IEEE going to come to IETF WG ? official letters? [Robert]: Yes ,, writing a letter,, will be sent on email. [Juan]: Could you [Robert] give an update on LPWAN, there is an executive meeting on friday?... [Robert] coming to that next. [Robert]: Update on security issues uncovered recently. Formed a study group "Security next gen" .. security requirements for 15.4, Another activity on FAN (Field Area Network) extensions. Study Group on 15.4 amendments on very low payload bitrate in unlicensed bands (= LPWAN). Alex: Do you think there are any items from your list we can consider as charter inputs for this WG? Robert: Possibly. explains possible timelines for doing such work.. Juan Carlos: 3 mains characteristics: star topology, frequency hopping and ... Robert: Alex: any other business? Pascal: please submit your SCHC-over-foo and bar-over-SCHC documents. Pascal: all authors of SCHC documents, extract info for work to be submitted to INT area. Alex: Carsten sent out mail about CoAP traffic that we should be considering. Alex: another hackathon on next IETF. Full SCHC package (compression/fragmentation) to be tested. Hopefully will have SCHC-over-foo documents by the time.