Minutes for LPWAN at IETF-95
minutes-95-lpwan-1

Hilton Buenos Aires, Buenos Aires, Argentina
	Monday, April 4, 2016. 
	17:40–19:40 Room Buen Ayre C
Chair: Donald Eastlake
Sponsoring AD: Brian Haberman
IAB Shepherd: Erik Nordmark

Minute takers: Thomas Watteyne, Dominique Barthel, Pascal Thubert,
               Ana Minaburo
Minutes reviewed by Donald Eastlake.

Minutes:

===> Administrativia (scribes), Agenda Bashing, Chair
===> Opening Remarks, AD

[15.43] meeting starts
  ~60-80 people in room (please check blue sheets)
  ~25 people on chat
[15.43] intro
  BoF chaired by Don Eastlake
  Don point out Note Well
  Don introduces agenda
  Don calls for agenda bashing - no issues raised
[Brian Haberman, AD] states what he is looking for:
  How much of a problem is there that Babel addresses?
  Is the IETF a good forum for address the problem?
  How much interest is there in working on this?

===> Why LPWAN, Alexander Pelov

[17.47] Why LPWAN [Alex Pelov]
   presentation about the business side
     low-cost: 5M USD for HW to cover France
     1 Billion devices by 2020
     589 Billion USD LPWAN market for 2020
   different competing technologies,
   goal: help ecosystem thrive
   [?? Cisco] Supports this work, but doesn't trust market predictions

===> LP-WAN GAP Analysis, Ana Minaburo

[17.54] gap analysis [Ana Minaburo]
  LPWAN technologies
    See http://goo.gl/S3uSPU
    goal, get general characteristics.
    Ana presents characteristics for LPWAN technologies, including:
      limit of 10 packets per day
      no fragmentation at L2?
  what the IETF can bring
    IP communication for E2E communication, L2 independence
    security
    scalability
    reliability
    interop
    header compression
    network and devices management
  Gaps in today's IETF protocols
    compact IPv6
    fragmentation
    Neighbor discovery
    6lo constraint nature is different than LPWAN
    6tisch: lp-wan is star, no mesh,
      some technologies are not slotted channel
    routing: star in LPWAN, perhaps in a future
    core: CoAP is good solution for lpwan,
      but need to adapt for limited duty cycle of lpwan
    mobility: mobile-ip not adapted
    [Juan Carlos] Questions regarding addressing,
      will you talk about them later?
    [Emmanuel] Interesting, we need to address this in the IETF.
      One point: scalability is not a concern at the IETF, not sure
      about this, because adding on bit over the air will have a huge
      hit, it is a concern
    [Erik Nordmark] wide range of characteristics, will we go after
      the whole range? Example: 10 packets/day is not a lot. different
      approach a bit higher packet rate, do you think there is a
      single solution for all of that?
      [Ana] we need to choose 2 or 3 technologies to focus on,
        open to discussions
    [Subir] Is running IP a problem?
      [Don] we have a presentation on that
    [Sri Gundavell] LoRa and SigFox doesn't adopt IPv6, do we konw why?
      [Ana]
    [Samita] If you're asking about optimized ND, 6LoWPAN/6lo designed one
    [Sri Gundavell] Did we concern existing protocols?
      [Alex] is the reason why, everyone things we have a solution,
        many announcements, but know there are problems,
	and IP might solve that
      [Ana] More presentations about solutions
    [Dan York] In the gap analysis, we need to understand what they
       are using if they are not using IP.
       What is the networking technology they are using now?
      [Alex] Comes later, application data directly over MAC, proprietary
    [Dan] Do they have enough capacity for an IP stack?
      [Alex] it's the network which is constrained,
        the devices have calculation resources
    [Diego as Jabber Scribe] [Basavaraj Patil] how would LoRa and
      Sigfox benefit from what you want t work on?
      [Pascal] they have a solution for one problem/scale.  LoRA WAN
        is looking at join process, so not all is solved. suggest we
        go through the slides layer by layer, and we ask questions
        layer by layer
    [Diego] Can we not run LoRa with slots?
      [Ana] in the general case, we cannot assume all is slotted
    [Don] closes the mic line

===> IP Challenges and non-IP Wireless I/O Models, Pascal Thubert

[18.18] IP challenges [Pascal thubert]
  Goal of next presentation: go layer by layer
  Not only do we have momentum in market, but IEEE and IETF should
    help to get some homogeneity in the solutions
  Pascal will talk about IP, Alex will talk about sec and app
  Question about the sixe of the stack and packets.
    The crucial part is the communication
  All these technologies are about the energy/range tradeoff
  6LoWPAN could optimally compress down to 4 bytes.
    ROHC can do 1 byte, but needs to learn from the flow.
    In the case of LP-WAN, we don't have flows.
  [Hannes Tschoefenig] What are the security requirements?
    If you leave security out, it's lightweight but less secure.
  Lots of expertise at IETF
  Do these networks want IP at all? the last hop is non-IP,
    no layer 3 or 4. But the so-called gateway can introduce these
    layers 3 and 4 to join the network. WirelessHART now does that.
  If we provide IP to these LP-WANs, the benefits could be:
    device management, security, etc…
  CoAP will provide a way to authenticate the device,
    application-level multiplexing.
    Will help get through the next 10-20 years.
  Compression is key: neither 6LoWPAN nor ROHC fit the bill.
    We want best of both worlds, absolute compression without
    on-line learning. Use a data model, so that state known
    a priori can be put into the equipment.
  [Christian Huitema] Microsoft : reason for IP is end-to-end model.
    Non-IP solutions rely on intelligence in the gateway.
    You're looking for a solution to be able to change the end-point
    without changing the gateway.
    [Pascal] We find that the device usually always talks to the
      same other device at network layer,
      but IP alleviates the need to collocate.
    [Christian] You definitely want to have IP. Not sure about CoAP
  [Hannes] Remote IO was interesting analogy. Like cable replacement.
    How to identify end point and relay message without too much
    overhead. Also how to identify application server.
    Companies would expect the operator to provide this service.
  [Pascal] Some of these protocols are already there,
    and are here to stay. Now want to add IP...
  [Hannes] We can provide functionalities such as device management
    (OMA, CoMI, ...) CBOR encoding, ...
  We'll have to focus on a few technologies. Let's dicuss this on
    the mailing list. We had excellent collaboration with IEEE 802
    on 15.4, let's do the same with e.g. LoRa and a few other
    technologies.
  [Juan Carlos] Excellent work. What exactly are the needs on the
    different layers? e.g. do we need E2E communication? work in 802c
    for local MAC address, from OUI to EUI to CUI. IEEE802 is looking
    at addressing, good timing to consider these use cases. Let's
    avoid having to fix things later on.
[Pascal] What we see here at IETF, IEEE is addressing it as well.

===> APP-level protocols/AAA/Management/Security, Alexander Pelov

[18.40] application, AAA, management, sec [Alex Pelov]
  We have soluions here at IETF
  AAA:
    network access control is a problem
    in general, PSK (Pre-Shared Key) used
    specific LPWAN requirements:
      huge number of devices
    what can IETF offer:
      AAA framework and protocols
      guidance for AAA key managements
    can we live with PSK when we have devices there for 20 years and
      easy to grab? scalability? flexibility?
      They are trying to redefine things that have already been done
        at IETF	
    device management: currently through MAC commands. Not
      flexible. e.g. in LoRa Spreading factor, coding rate and ?? but
      only 15 combinations allowed ???
    application management: can't change parameters in current
      devices. CoOL, CoAP could help application developers configure
      their devices.
        scaling to high number of devices requires flexibility.
    we propose to add this layer onto the MAC management of these devices
    Security: there are many things, including asymmetric links
      some of these technologies are very asymmetric: SigFox max 4 downlink
      messages a day. One-time passwords ore not usable.
    Applications
    limited number of flows (typically 2). Compression feasible.
    end-device time scale vs application time-scale. Desire that there
      is no need to update the G/W for every change in the device
    Example:
      how to manage timers, how to manage devices, what about
      fragmentation, what about sleepy nodes? all left to application
      developers. => there is an application protocol, but it's implicit.
      Nobody is sure what is there
    [Sri Gundavell] How many thing that you list are application
      issues vs network issues
    [Alex Pelov] Some timers are hardcoded and the application depends on it.
    [Sri] Need an "AP" so the application does not have to care about
      networking stuff
    [Alex Pelov] How does the application know how long it should wait
      for an answer. That's app stuff.
    [Alex Petrescu] Apps are specific and design for purpose. All is
      done at the application and the way it is deployed; this is why IP
      is needed, to make app more independent.
    what does IETF bring?
      remove interlayer dependence
      profiling applications to manage acks,
      if you go for satellite backhaul with LoRa, all your timers timeout,
        the whole stack breaks.

===> Optimized 6LoWPAN Fragmentation Header for LPWAN, Carles Gomez

[19.01] optimized 6LoWPAN fragmentation for LP-WAN presentation
[Carles Gomez]
  motivation: * some LP-WANs have payloads much smaller that
    15.4. 6LoWPAN has 4-5 bytes fragmentation headers. * RFC4944 frag
    offset in expressed in 8-byte increments. Not usable with smaller
    frame LP-WANs.
  proposed format: 3-byte fragmentation headers.
  datagram size included in the frist fragment only,
    since no re-ordering expected in star-topology LP-WANs.
  datagram_tag on 1 byte only, no ambiguity because low datarate.
  offset in 1-byte increments.
  shows table with overhead in various common cases.
  compares overheads of RFC4944 and 6LoFHL, IANA and security considerations
  IANA has to allocate 16 dispatch values from the 6LoWPAN space
  [Don] Move to next presentation, questions at end

===> Constrained Signaling Over LP-WAN including AAA, Alexander Pelov

[19.11] CoSOL Constrained Signaling over LPWAN [Alex Pelov]
  use CoAP as signaling protocol for LPWANs to manage behavior of end devices.
  you must be able to use CoAP before having an IP address
  Alex gives E2E example with LPWAN LoRa technology
  Note: The Lora Gateway is called a Node-R in CoSol, and CoSol's
    gateway is upper layer gateway
  diagram shows node-F exchanging messages with node-G. Node-R is not
    shown because it only is a transceiver.
  explains the states the device goes through when booted:
    disconnected -> discovery -> associated -> authenticated ->
    semi-associated
  reactive and proactive approach
  makes use of EAP over CoAP (see draft-marin-ace-wg-coap-eap-02)
  authentication with certificates over LoRA is possible, although takes time
  for network management, CoOL, done at the CoRE WG
    Alex shows example with CoOL
  semi-associated state is used for SigFox. Using COSE-based object security
  using IEEE802.15.4 frame format over LoRA
  YANG model for LoRA device (draft-pelov-yang-lora-01), 19 bytes to
    update the full config of the device
  CoSOL can run over 15.4, LoRa, SigFox
  [Stewart Bryant, proxied by Diego] If it takes a day to
    authenticate, how does a service engineer install or replace and
    verify that it works
    [Alex] we are giving the possibility to do certificates,
      up to them to check it makes sense
  [Juan Carlos] 19 bytes to reconfig, but SIGFOX has MTU of 12
    bytes. fragmentation required?
    [Alex] you can use fragmentation at different layers. Important
      part is that we don't optimize specifically for one technology
  
===> Discussion

[19.25] discussion
  [Don] We have 15min left for discussion
  [Brian Haberman] Ask whether we see a problem, and where IETF can
    help with it.
  [Sri] like this area, cannot identify specific problems. We need to
    understand what the cost aspect is. If not a problem, we should
    address it, I support this work but should define precisely what
    problems are we trying to solve.
  [Alex Petrescu] 3 problems
    1. IPv6 over foo, different LPWAN have different capabilities. Is
       this not an IPv6-over-foo discussion?
    2. Remote software update
    3. Security, how gets authenticated
  [Pascal] Don't see LPWAN as IP-over-foo. We will be looking at a
    global problem, architecture rather than building blocks.
  [Juan Carlos] See that there is work needed, no solution can fit
    all, need to look at it. worth giving it a thought. like presented
    layer-by-layer. otherwise we will have to fix problems in the
    future.
  [Samita] Thank team for great work. there are issues to solve,
    already deployment of IP on constrained devices. Challenges, you
    cannot just take an RFC and use on LPWAN. Interesting IETF work,
    e.g. on fragmentation. We can discuss later about management,
    CoAP, etc. I see more work to be done. We don't want to have a GW
    device
  [Pascal] Do you think we should have this at IETF
  [Samita] Yes
  [Subir]c thanks for presentation. A lot of use cases, since involved
    in other SDOs, statements that LoRA says don't need help, that's
    scary. Who would be using this work? Would be good to hear from
    those SDOs hat need helps from IETF. We don't want nobody to use
    it. Little bit premature. 
  [Pascal] All of this work depends on forming a relationship with
    other SDOs. By Berlin, we need to prove that we have established
    this relationship.
  [Alex] Discusses with a lot of companies, are interested in getting
    IP over these technologies. Interest is there IMO.
  [Stewart Bryant, on Jabber] The paradigm is very different from what
    we're used to. Agree that there are issues, but needs to be looked
    at.
  [Erik] If we are going for these technologies, there is some work at
    the IETF to do this. Key thing is ...
  [Suresh] expresses concern on boiling the ocean / keeping active
    forever if addressing too many of the possible cases
  [Gabriel] ...

- end -