Minutes IETF104: lpwan
minutes-104-lpwan-00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes IETF104: lpwan
State Active
Other versions plain text
Last updated 2019-03-27

Meeting Minutes
minutes-104-lpwan

   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
                   Alexander Pelov
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: *

[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]