* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lpwan Status Pages

IPv6 over Low Power Wide-Area Networks (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2016-Oct-14 —  
Chairs
 
 


IETF-100 lpwan minutes

Session 2017-11-13 0930-1200: Olivia - Audio stream - lpwan chatroom

Minutes

minutes-100-lpwan-02 minute



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



Generated from PyHt script /wg/lpwan/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -