Minutes IETF100: lpwan
minutes-100-lpwan-02

# 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 <pthubert@cisco.com>
                       Alexander Pelov <a@ackl.io>
    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.