[lp-wan] Fwd: Review and proposed text for draft-minaburo-lp-wan-gap-analysis-01

[Ana Minaburo <[e-mail]>]

Thank you very much for your comments, see my answers in the text

Ana

On Tue, Mar 15, 2016 at 1:16 PM, Carles Gomez Montenegro <
[e-mail]> wrote:

> Hi everyone,
>
> Please find below a review with comments and suggested new text for
> draft-minaburo-lp-wan-gap-analysis-01.
>
> Thanks!
>
> Carles
>
>
> ---------------------------  Start  ------------------------------------
>
> Network Working Group                                        A. Minaburo
> Internet-Draft                                                  A. Pelov
> Intended status: Informational                                    Acklio
> Expires: August 27, 2016                                      L. Toutain
>                                Institut MINES TELECOM ; TELECOM Bretagne
>                                                        February 24, 2016
>
>
>                           LP-WAN GAP Analysis
>                  draft-minaburo-lp-wan-gap-analysis-01
>
> Abstract
>
>    Low Power Wide Area Networks (LP-WAN) are different technologies
>    covering different applications based on long range, low bandwidth
>    and low power operation.  The use of IETF protocols in the LP-WAN
>    technologies should contribute to the deployment of a wide number of
>    applications in an open and standard environment where actual
>    technologies will be able to communicate.  This document makes a
>    survey of the principal characteristics of these technologies and
>    covers a cross layer analysis on how to adapt and use the actual IETF
>    protocols, but also the gaps for the integration of the IETF protocol
>    stack in the LP-WAN technologies.
>
> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on August 27, 2016.
>
> Copyright Notice
>
>    Copyright (c) 2016 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>
>
>
> Minaburo, et al.         Expires August 27, 2016                [Page 1]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> 1.  Introduction
>
>    LP-WAN (Low-Power Wide Area Network) technologies are a kind of
>    constrained and challenged networks [RFC7228].  They can operate in
> >> licensed


(AM) We think it could create a confusion with the cellular networks
(3G,4G,5G technologies) that are licensed and that we do not want to be
included in the LP-WAN family.

> or
>    license-exempt bands to provide connectivity to a vast number of
>    battery-powered devices requiring limited communications.  If the
>    existing pilot deployments have shown the huge potential and the
>    industrial interest in their capabilities, the loose coupling with
>    the Internet makes the device management and network operation
>    complex.  More importantly, LP-WAN devices are, as of today, with no
>    IP capabilities.  The goal is to adapt IETF defined protocols,
>    addressing schemes and naming spaces to this constrained environment.
>
> 2.  Problem Statement
>
>    The LP-WANs are large-scale constrained networks in the sense of
>    [RFC7228] with the following characteristics:
>
>    o  very small frame payload as low as 12 bytes.  Typical traffic
>       patterns are composed of a large majority of frames with payload
>       size around 15 bytes and a small minority of up to 100 byte
>       frames.  Some nodes will exchange less than 10 frames per day.
>
>    o  very low bandwidth, most LP-WAN technologies offer a throughput
>       between 50 bit/s to 250 kbit/s, with a duty cycle of 0.1% to 10%
>       on some ISM bands.
>
>    o  high packet loss, which can be the result of bad transmission
>       conditions or collisions between nodes.
>
>    o  variable MTU for a link depending on the used L2 modulation.
>
> >> o  in many cases, lack of L2 fragmentation.
>
> (AM) Good point to be added


>    o  highly asymmetric and in some cases unidirectional links.
>
>    o  ultra dense networks with thousands to tens of thousands of nodes.
>
>    o  different modulations and radio channels.
>
>    o  sleepy nodes to preserve energy.
>
> >> o  typically, they define a star topology.
>
>
> (AM) Here also, It is true that most of the actual topologies are star,
but this will quickly put many future possibilities out of the scope. The
actual use is in an star topology but we can think about new usage with
another topology

>
>
> Minaburo, et al.         Expires August 27, 2016                [Page 2]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
>    In the terminology of [RFC7228], these characteristics put LP-WANs
>    into the "challenged network" category where the IP connectivity has
>    to be redefined or modified.
>
> -------
> Suggestion:
>
>    In the terminology of [RFC7228], these characteristics put many LP-WAN
>    technologies (and/or technology configurations) into the "challenged
>    network" category where end-to-end connectivity requires the addition of
>    new mechanisms to the existing ones.
>
> (Comment: note that in DTNs, IP connectivity is not modified per se;
> instead, additional mechanisms are added at upper layers.)
>

(AM) I think that in LP-WAN will be the same, the IP connectivity will not
be modified but we will use additional protocols or mechanisms in upper or
lower layers

>
> (Comment: some of the LP-WAN technologies, depending on how they are
> configured, e.g. the modulation used, do not actually fall in the
> challenged network category, but are probably still constrained networks.)
>
> (AM) Of course modulation is variable so we can in some cases be only
constrained but this work is already the scope of other working groups as
6lo or 6tisch and the objective is to do what is needed for challenged
network that cannot use 6lo or 6tisch technologies


> -------
>    Therefore, LP-WANs need to be
>    considered as a separate class of networks.
>
> (Comment: separate from what? Also, there are other types of challenged
> networks.)
>

(AM) Yes perhaps it is not clear. What we want to do is to assemble LP-WAN
technologies into a family or group or class of networks which has some
common characteristics and are challenged, and need some additional
mechanisms to have the IP connectivity

>
> Suggestion:
>
>    Therefore, most LP-WANs may require specific solutions extending
>    existing IETF mechanisms and/or defining new ones.
>

(AM) If we create a solution for each LP-WAN technology will not be simple,
it is better to crete a group of LP-WAN technologies that has common
characteristics and solve this problematic

> -------
>
>    The intrinsic
>    characteristics, current usages and architectures will allow the
>    group to make and justify the design choices.  Some of the desired
>    properties are:
>
>    o  keep compatibility with current Internet:
>
>       *  preserve the end-to-end communication principle.
>
>       *  maintain independence from L2 technology.
>
>       *  use or adapt protocols defined by IETF to this new environment
>          that could be less responsive.
>
>       *  use existing addressing spaces and naming schemes defined by
>          IETF.
>
>    o  ensure the correspondence with the stringent LP-WAN requirements,
>       such as:
>
>       *  limited number of messages per device.
>
>       *  small message size, with potentially no L2 fragmentation.
>
>       *  RTTs potentially orders of magnitude bigger than existing
>          constrained networks.
>
>    o  optimize the protocol stack in order to limit the number of
>       duplicated functionalities; for instance acknowledgements should
>       not be done at several layers.
>
> -------
>
> (Comment: why? Sometimes, lower layer (e.g. link layer) reliability helps
> the (acknowledged) upper layers a lot…  If both things may be of interest
> depending on the scenario/technology, it could be good to state it.)
>
> Suggestion: To minimize the number of messages to be exchanged, upper
> layer acknowledgments can be used. Nevertheless, if appropriately tuned,
> lower layer reliability may contribute to achieve a higher overall
> performance. A per-technology or per-scenario analysis is recommended.
>

(AM) Agree

> -------
>
>
> 3.  Identified gaps in current IETF groups concerning LP-WANs
>
> 3.1.  IPv6 and LP-WAN
>
>    IPv6 [RFC2460] has been designed to allocate addresses to all the
>    nodes connected to the Internet.  Nevertheless the 40 bytes of
>    overhead introduced by the protocol are incompatible with the LP-WAN
>    constraints.  If IPv6 were used, several LP-WAN frames will be needed
>    just to carry the header.
>
> -------
> OLD:
>    Another limitation comes from the MTU
>    limit, which is 1280 bytes required from the layer 2 to carry IPv6
> packet
>    [RFC1981].
>
> NEW:
>    Another limitation comes from the MTU of 1280 bytes required by IPv6
>    [RFC2460].
>

(AM) Good, thanks

> -------
>
>    Another limitation comes from the MTU
>    limit, which is 1280 bytes required from the layer 2 to carry IPv6
>    packet [RFC1981].  This is a side effect of the PMTU discovery
>    mechanism, which allows intermediary routers to send to the source an
>    ICMP message (packet too big) to reduce the size.  An attacker will
>    be able to forget this message and reduce drastically the transmission
>
> (Comment: I think a reason for the IPv6 MTU requirement was the increase
> of link layer technologies capacity by the time (compared with the state
> of art when IPv4 was designed, where an MTU of 576 bytes was defined), and
> also to allow an efficiency increase.)
>
> (AM) I can include this idea

>
> Minaburo, et al.         Expires August 27, 2016                [Page 3]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
>    performances.  This limit allows to mitigate the impact of this
>    attack.
>
>    IPv6 needs a configuration protocol (neighbor discovery protocol, NDP
>    [RFC4861]) to learn network parameters, and the node relation with
>    its neighbor.  This protocol generates a regular traffic with a large
>    message size that does not fit LP-WAN constraints.
>
> 3.2.  6LoWPAN, 6lo and LP-WAN
>
>    6LoWPAN only resolves the IPv6 constraints by drastically reducing
>    IPv6 overhead to about 4 bytes for ND traffic,
>
> (Comment: What are the 4 bytes this sentence refers to?)
> (Comment: 6LoWPAN comprises other important mechanisms, such as
> fragmentation.)
>
>    but the header
>    compression is not better for an end-to-end communications using
>    global addresses (up to 20 bytes).
>
> (Comment: but down to 3 bytes using global addresses, in the best case.)
>
>    6LoWPAN has been initially
>    designed for IEEE 802.15.4 networks with a frame size up to 127 bytes
>    and a throughput of up to 250 kb/s with no duty cycle regarding the
>    usage of the network.
>
> (Comment: 802.15.4 beacon-enabled mode is duty-cycled. Also channel
> sampling can be used, and is still duty cycled. 6LoWPAN can be used on top
> of both beacon and nonbeacon-enabled networks (RFC 4944).)
>
>    IEEE 802.15.4 is a CSMA/CA protocol which means that every unicast
>    frame is acknowledged.
>
> (Comment: No. 802.15.4 provides optional reliability. A bit in the header
> of a frame signals whether the frame requires an acknowledgment or not.)
>
>    Because IEEE 802.15.4 has its own reliability
>    mechanism by retransmission, 6LoWPAN does not have reliable delivery.
>
> (Comment: 6LoWPAN does not have reliable delivery because it just needs to
> adapt IPv6 (which does not have reliable delivery) over a link layer.
> Whatever happens below 6LoWPAN is a responsibility of the link layer,
> which may be reliable or not.)
>
>    Some LP-WAN technologies do not provide such acknowledgements at L2
>    and would require other reliability mechanisms.
>
> NEW:
> A key 6LoWPAN component is fragmentation, which allows the transmission of
> IPv6 packets greater than the available payload in IEEE 802.15.4 (of 81
> bytes in the worst case), and allows to fulfill the IPv6 MTU requirement.
> However, for example, in the LP-WAN technology called SIGFOX, which has an
> L2 MTU of 12 bytes and does not support L2 fragmentation, it is not
> possible to transmit large IPv6 packets by using RFC 4944 6LoWPAN
> fragmentation, since the 6LoWPAN fragmentation header consumes 5 bytes
> (4 bytes for the first fragment), leaving only 7 bytes of space for
> fragment data, while the offset of each fragment has to be expressed in
> increments of 8 octets.
>
> (AM) ok


> On the other hand, in L2 technologies with an L2 maximum payload size of
> 13 or more bytes, it will be possible to transmit any IPv6 packet by using
> 6LoWPAN fragmentation. However, a large overhead will be incurred, leading
> to a very high number of L2 data units per single IPv6 packet.
>
> An optimized, 3-byte 6LoWPAN fragmentation header has been defined in
> [draft-gomez-lpwan-fragmentation-header], exploiting LP-WAN
> characteristics. This fragmentation header enables the support of IPv6
> packets over L2 payload sizes of even 4 bytes in the most extreme case,
> and reduces a significant amount of both L2 and adaptation layer overhead.
>


>    6lo extends the usage of 6LoWPAN to other technologies (BLE, DECT,
>    ...), with similar characteristics to IEEE 802.15.4.  The main
>    constraint in these networks comes from the nature of the devices
>    (constrained devices), whereas in LP-WANs it is the network itself
>    that imposes the most stringent constraint.
>
> (Comment: The devices in 6lo and 6LoWPAN are constrained, but their
> networks are also constrained in terms of RFC 7228 (section 2.2). I would
> say that the difference between LP-WANs and 6LoWPAN is that many LP-WANs
> can be considered to be "challenged networks". Nevertheless, there is
> probably not a well-defined boundary between 6Lo(WPAN) and LP-WAN.)
>
>    Neighbor Discovery has to be optimized by reducing the message size,
>    the periodic exchanges and removing multicast message for point-to-
>    point exchanges with border router.
>
> (Comment: Does this refer to IPv6 ND, or to 6LoWPAN ND?
> RFC 6775 removes multicast as much as possible. On the other hand, the
> registration lifetime can be of up to 1.5 months in 6LoWPAN ND.)
>
>
> 3.3.  6tisch and LP-WAN
>
>    TODO
>
>    Describe why 6tisch is complementary to LP-WAN
>
>    A key element of 6tisch is the use of synchronization to enable
>    determinism.  An LP-WAN may or may not support synchronization like
>    the one used in 6tisch.  The 6tisch solution is dedicated to mesh
>    networks that operate using 802.15.4e with a deterministic slotted
>    channel.
>
>
>
>
>
>
> Minaburo, et al.         Expires August 27, 2016                [Page 4]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
> 3.4.  ROLL and LP-WAN
>
>    The LP-WANs considered by the WG are based on a star topology, which
>    eliminates the need for routing.  Future works may address additional
>    use-cases which may require the adaptation of existing routing
>    protocols or the definition of new ones.  For the moment, the work
>    done at the ROLL WG and other routing protocols are out of scope of
>    the LP-WAN WG.
>
> 3.5.  CORE and LP-WAN
>
>    TODO
>
>    CoRE provides a resource-oriented application intended to run on
>    constrained IP networks.  It may be necessary to adapt the protocols
>    to take into account the duty cycling and the potentially extremely
>    limited throughput.  For example, some of the timers in CoAP may need
>    to be redefined.
>
> NEW:
> For example, while the CoAP RTO timer is chosen randomly from the [2 s, 3
> s] interval by default, the transmission time of the largest L2 data unit
> size, using the most robust modulation, is 6.82 s with LoRa, 9.6 s with
> SIGFOX, and 85 s with IEEE 802.15.4k LECIM.
>
>    Taking into account CoAP acknowledgements may allow
>    the reduction of L2 acknowledgements.
>
> 3.6.  Security and LP-WAN
>
>    ToDo
>
> 3.7.  Mobility and LP-WAN
>
>    TODO
>
>    LP-WAN nodes can be mobile.  However, LP-WAN mobility is different
>    than the one studied in the context of Mobile IP.  LP-WAN implies
>    sporadic traffic and will rarely be used for high-frequency, real-
>    time communications.
>
> 4.  Annex A -- survey of LP-WAN technologies
>
>    Different technologies can be included under the LP-WAN acronym.  The
>    following list is the result of a survey among the first participant
>    to the mailing-list.  It cannot be exhaustive but is representative
>    of the current trends.
>
> Minaburo, et al.         Expires August 27, 2016                [Page 5]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
>    +-------------+---------------+--------------+--------+
>    |Technology   |range          | Throughput   |MAC MTU |
>    +-------------+---------------+--------------+--------+
>    |LoRa         |2-5 km urban   |0.3 to 50 kbps|256 B   |
>    |             |<15 km suburban|              |        |
>    +-------------+---------------+--------------+--------+
>    |SIGFOX       |10 km urban    |100 bps       |12 B    |
>    |             |50 km rural    |              |        |
>    +-------------+---------------+--------------+--------+
>
> (Comment: I have a SIGFOX flyer (date July 2012) which states a range
> between 10 bit/s and 1 kbit/s.)
>
>    |IEEE802.15.4k| < 20 km LoS   |1.5 bps to    |16/24/  |
>    |LECIM        | < 5 km NoLoS  | 128 kbps     | 32 B   |
>    +-------------+---------------+--------------+--------+
>    |IEEE802.15.4g| 2-3 km LoS    | 4.8 kbps to  |2047 B  |
>    |SUN          |               |800 kbps      |        |
>    +-------------+---------------+--------------+--------+
>    |RPMA         | 65 km LoS     |  up: 624kbps |64 B    |
>    |             | 20 km NoLoS   |down: 156kbps |        |
>    |             |               | mob: 2kbps   |        |
>    +-------------+---------------+--------------+--------+
>    |DASH-7       | 2 km          |    9 kbps    |256 B   |
>    |             |               |   55.55 kbps |        |
>    |             |               |  166.66 kbps |        |
>    +-------------+---------------+--------------+--------+
>    |Weightless-w | 5 km urban    | 1 kbps to    |min 10 B|
>    |             |               | 10 Mbps      |        |
>    +-------------+---------------+--------------+--------+
>    |Weightless-n |<5 km urban    | 30 kbps to   |max 20 B|
>    |             |<30 km suburban| 100kbps      |        |
>    +-------------+---------------+--------------+--------+
>    |Weightless-p |> 2 km urban   | up to 100kbps|        |
>    +-------------+---------------+--------------+--------+
>    |NB-LTE       |< 15 km        | < 150 kbps   | < 200 B|
>    +-------------+---------------+--------------+--------+
>
>                   Figure 1: Survey of LP-WAN technologies
>
>    The table Figure 1 gives some key performance parameters for some
>    candidate technologies.  The maximum MTU size must be taken
>    carefully, for instance in LoRa, it take up to 2 sec to send a 50
>    Byte frame using the most robust modulation.  In that case the
>    theoretical limit of 256 B will be impossible to reach.
>
>    Most of the technologies listed in the Annex A work in the ISM band
>    and may be used for private a public networks.  Weightless-W uses
>    white spaces in the TV spectrum and NB-LTE will use licensed
>    channels.  Some technologies include encryption at layer 2.
>
>
>
>
>
> Minaburo, et al.         Expires August 27, 2016                [Page 6]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
> 5.  Acknowledgements
>
>    Thanks you very much for the discussion and feedback on the LP-WAN
>    mailing list, namely, Pascal Thubert, Carles Gomez, Samita
>    Chakrabarti, Xavier Vilajosana, Misha Dohler, Florian Meier, Timothy
>    J.  Salo, Michael Richardson, Robert Cragie, Paul Duffy, Pat Kinney,
>    Joaquin Cabezas and Bill Gage.
>
> 6.  Normative References
>
>    [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
>               for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
>               1996, <http://www.rfc-editor.org/info/rfc1981>.
>
>    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>               (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
>               December 1998, <http://www.rfc-editor.org/info/rfc2460>.
>
>    [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>               "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
>               DOI 10.17487/RFC4861, September 2007,
>               <http://www.rfc-editor.org/info/rfc4861>.
>
>    [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
>               Constrained-Node Networks", RFC 7228,
>               DOI 10.17487/RFC7228, May 2014,
>               <http://www.rfc-editor.org/info/rfc7228>.
>
> Authors' Addresses
>
>    Ana Minaburo
>    Acklio
>    2bis rue de la Chataigneraie
>    35510 Cesson-Sevigne Cedex
>    France
>
>    Email: [e-mail]
>
>
>    Alexander Pelov
>    Acklio
>    2bis rue de la Chataigneraie
>    35510 Cesson-Sevigne Cedex
>    France
>
>    Email: [e-mail]
>
>
>
>
>
> Minaburo, et al.         Expires August 27, 2016                [Page 7]
>
>
> Internet-Draft             LP-WAN GAP Analysis             February 2016
>
>
>    Laurent Toutain
>    Institut MINES TELECOM ; TELECOM Bretagne
>    2 rue de la Chataigneraie
>    CS 17607
>    35576 Cesson-Sevigne Cedex
>    France
>
>    Email: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Minaburo, et al.         Expires August 27, 2016                [Page 8]
>
>
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>