Minutes IETF99: lpwan
minutes-99-lpwan-02

# 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 <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/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