* 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-99 lpwan minutes

Session 2017-07-21 0930-1130: Karlin I/II - Audio stream - lpwan chatroom

Minutes

minutes-99-lpwan-02 minute



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



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