[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                           C. Gomez
Internet-Draft                                              J. Paradells
Intended status: Informational                                 UPC/i2CAT
Expires: September 22, 2016                                 J. Crowcroft
                                                 University of Cambridge
                                                          March 21, 2016


        Analysis of IPv6 over LPWAN: design space and challenges
                   draft-gomez-lpwan-ipv6-analysis-00

Abstract

   Connecting Low Power Wide Area Networks (LPWANs) to the Internet is
   expected to provide significant benefits to these networks in terms
   of interoperability, application deployment, and management, among
   others.  However, the constraints of LPWANs, often more extreme than
   those of typical 6Lo(WPAN) technologies, constitute a challenge for
   the 6LoWPAN suite in order to enable IPv6 over LPWAN.  Considering
   the typical characteristics of LPWAN technologies, this document
   analyzes the design space and challenges related with enabling IPv6
   over LPWAN.

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 September 22, 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Gomez, et al.          Expires September 22, 2016               [Page 1]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions used in this document . . . . . . . . . . . .   3
   2.  Protocol stack  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Network topology and device roles . . . . . . . . . . . . . .   3
   4.  IPv6 subnet model . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Address autoconfiguration . . . . . . . . . . . . . . . . . .   4
   6.  Fragmentation . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Neighbor discovery  . . . . . . . . . . . . . . . . . . . . .   5
   8.  Header compression  . . . . . . . . . . . . . . . . . . . . .   6
   9.  Unicast and multicast mapping . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   12. Annex A. RFC 6775 message size analysis . . . . . . . . . . .   7
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     13.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     13.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Low Power Wide Area Network (LPWAN) technologies define long range,
   low bit rate and low power wireless interfaces that are used for
   control and monitoring applications.  Examples of LPWAN technologies
   include LoRa, SigFox, IEEE 802.15.4k LECIM, Weightless, etc.
   [I-D.minaburo-lp-wan-gap-analysis].

   Connecting LPWANs to the Internet is expected to provide significant
   benefits to these networks in terms of interoperability, application
   deployment, and management, among others.  Therefore, the support of
   IPv6 over LPWAN is a fundamental aspect to be examined for LPWAN
   Internet connectivity.

   Several technologies that exhibit significant constraints in various
   dimensions have exploited the 6LoWPAN suite of specifications
   ([RFC4944][RFC6282][RFC6775]) to support IPv6
   [I-D.hong-6lo-use-cases]. 6LoWPAN, which was originally designed for
   IEEE 802.15.4 networks, provides a frame format, address
   autoconfiguration, fragmentation, header compression, and optimized
   IPv6 neighbor discovery.



Gomez, et al.          Expires September 22, 2016               [Page 2]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   However, the constraints of LPWANs, often more extreme than those of
   typical 6Lo(WPAN) technologies, constitute a challenge for the
   6LoWPAN suite in order to enable IPv6 over LPWAN.  LPWANs are
   characterized by device constraints (in terms of processing capacity,
   memory, and energy availability), and specially, link constraints,
   such as i) very low layer two payload size (from ~10 to ~100 bytes),
   ii) very low bit rate (from ~10 bit/s to ~100 kbit/s), and iii) in
   some specific technologies, further message rate constraints (e.g.
   between ~0.1 message/minute and ~1 message/minute) due to regional
   regulations that limit the duty cycle.

   In some cases the 6LoWPAN functionality may be used to enable IPv6
   over specific LPWAN technologies (with the level of adaptation done
   in the IPv6 over foo documents produced by the IETF 6lo WG),
   maintaining good performance.  However, in the most challenged LPWAN
   technologies and/or configurations, further optimization and/or
   tuning of the 6LoWPAN functionality is required for efficient
   operation.  This document analyzes the design space and challenges of
   enabling IPv6 over LPWAN.

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]

2.  Protocol stack

   In the design of an IPv6 over foo adaptation layer, if more than one
   layer (other than the physical layer) is supported by the target
   technology, a crucial decision is which lower layer will interface
   with the adaptation layer.  The layer(s) below the adaptation layer
   must provide the functionality to enable a link, i.e. "a
   communication facility or medium over which nodes can communicate at
   the link layer, i.e., the layer immediately below IP" [RFC4861].

   In addition to the above requirement, further aspects to consider in
   the mentioned decision include lower layer support of fragmentation
   (see Section 5), overhead, and the ability of multplexing upper layer
   protocols.

3.  Network topology and device roles

   As of the writing, LPWAN technologies typically follow the star
   topology, whereby the end devices are connected through a direct link
   with a central device.  In that case, the end devices and the central
   device will act as 6LoWPAN Nodes (6LN) and 6LoWPAN Border Router




Gomez, et al.          Expires September 22, 2016               [Page 3]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   (6LBR), respectively.  The 6LBR may provide Internet connectivity
   (see Figure 1).

4.  IPv6 subnet model

   As IPv6 over LPWAN is intended for constrained nodes, and for
   Internet of Things use cases and environments, the complexity of
   implementing a separate subnet on each link and routing between the
   subnets appears to be excessive.  For LPWAN, the benefits of treating
   the collection of links of the network as a single multilink subnet
   rather than a multiplicity of separate subnets are considered to
   outweigh the multilink model's drawbacks as described in [RFC4903].



                                             /
            .---------------.               /
           /           6LN   \             /
          /               \   \           /
         |                 \   |         /
         | 6LN -----------   6LBR ----- |  Internet
         |     <--Link-->  /   |         \
          \               /   /           \
           \           6LN   /             \
            '---------------'               \
                                             \

          <------ Subnet -----><-- IPv6 connection -->
                                                                                                     to Internet

                 Figure 1: LPWAN connected to the Internet

   In the multilink subnet model, link-local multicast communications
   can happen only within a single link; thus, 6LN-to-6LN communications
   using link-local addresses are not possible. 6LNs connected to the
   same 6LBR have to communicate with each other by using the shared
   prefix used on the subnet.

5.  Address autoconfiguration

   In the ambit of 6Lo(WPAN) technologies, traditionally, Interface
   Identifiers (IIDs) have been derived from link layer identifiers
   [RFC4944] . This allows optimizations such as header compression.
   Nevertheless, due to privacy concerns, LPWAN devices should not be
   configured to embed their link layer address in the IID by default
   (see Section 3.2.2 of [RFC4903], and [I-D.ietf-6man-default-iids]).





Gomez, et al.          Expires September 22, 2016               [Page 4]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


6.  Fragmentation

   IPv6 requires an MTU of 1280 bytes [RFC2460] . Therefore, given the
   low maximum payload size of LPWAN technologies, fragmentation is
   needed.

   If a layer of an LPWAN technology supports fragmentation, proper
   analysis has to be carried out to decide whether the fragmentation
   functionality provided by the lower layer or fragmentation at the
   adaptation layer should be used.  Otherwise, fragmentation
   functionality shall be used at the adaptation layer.

   6LoWPAN defined a fragmentation mechanism and a fragmentation header
   to support the transmission of IPv6 packets over IEEE 802.15.4
   networks [RFC4944] . While the 6LoWPAN fragmentation header is
   appropriate for IEEE 802.15.4-2003 (which has a frame payload size of
   81-102 bytes), it is not suitable for several LPWAN technologies,
   many of which have a maximum payload size that is one order of
   magnitude below that of IEEE 802.15.4-2003.  The overhead of the
   6LoWPAN fragmentation header is high, considering the reduced payload
   size of LPWAN technologies and the limited energy availability of the
   devices using such technologies.  Furthermore, its datagram offset
   field is expressed in increments of eight octets.  In some LPWAN
   technologies, the 6LoWPAN fragmentation header plus eight octets from
   the original datagram exceeds the available space in the layer two
   payload.  To overcome these limitations, an optimized 6LoWPAN
   fragmentation header for LPWAN has been defined in
   [I-D.gomez-lpwan-fragmentation-header].

7.  Neighbor discovery

   6LoWPAN Neighbor Discovery [RFC6775]  defined optimizations to IPv6
   Neighbor Discovery [RFC4861] , in order to adapt functionality of the
   latter for networks of devices using IEEE 802.15.4 or similar
   technologies.  The optimizations comprise host-initiated interactions
   to allow for sleeping hosts, replacement of multicast-based address
   resolution for hosts by an address registration mechanism, multihop
   extensions for prefix distribution and duplicate address detection
   (note that these are not needed in a star topology network), and
   support for 6LoWPAN header compression.

   6LoWPAN Neighor Discovery may be used in LPWAN networks.  However,
   the relative overhead incurred will depend on the LPWAN technology
   used (and on its configuration, if appropriate).  In certain LPWAN
   setups (with a maximum payload size above ~60 bytes, and duty-cycle-
   free or equivalent operation), an RS/RA/NS/NA exchange may be
   completed in a few seconds, without incurring packet fragmentation.
   In others (with a maximum payload size of ~10 bytes, and a message



Gomez, et al.          Expires September 22, 2016               [Page 5]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   rate of ~0.1 message/minute), the same exchange may take a few hours,
   leading to severe fragmentation and consuming a significant amount of
   the available network resources.  See Annex A for an analysis of the
   6LoWPAN Neighbor Discovery message sizes.

   6LoWPAN Neighbor Discovery behavior may be tuned through the use of
   appropriate values for the default Router Lifetime, the Valid
   Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as
   the address Registration Lifetime.

   The Router Lifetime, which is present in RAs, may be as high as 18.2
   hours.  The Valid Lifetime in the PIO indicates the time of validity
   of the prefix indicated in the PIO, and it is possible to encode a
   value of infinity for this lifetime.  The Valid Lifetime in the 6CO,
   which indicates the time of validity of the related context for
   header compression, may be as high as 45 days.  A 6LN should unicast
   an RS to the router before expiration of any of these lifetimes.  On
   the other hand, the address Registration Lifetime determines the
   periodicity with which a 6LN has to perform address reregistration
   with the router, and may be as high as 45 days.

   Therefore, 6LoWPAN Neighbor Discovery supports relatively high
   periods without generating messages (the shortest being the maximum
   Router Lifetime).  However, there exists a trade-off between Neighbor
   Discovery message overhead and reactivity to network changes
   (potentially affecting network connectivity) that must be assessed.
   On the other hand, the most challenged LPWAN setups may require the
   definition of functionality beyond the limits of [RFC6775].

8.  Header compression

   [RFC6282] defines stateless and stateful header compression for
   6LoWPAN networks.  This functionality is highly required in LPWAN,
   given the extreme resource constraints of these networks.

   [RFC6282] defines a two-byte base encoding.  To enable context-based
   compression of global addresses, a further byte is needed to encode
   source and destination context.  Such compression may cover prefixes
   or complete, 128-bit IPv6 addresses.  In the most minimalistic case,
   assuming that the IPv6 header fields allow the maximum possible
   degree of compression, an IPv6 header comprising global IPv6
   addresses may be compressed to a size of 3 bytes.

   Contexts may be disseminated by using the 6CO in RA messages.  Up to
   16 contexts may be defined.  However, note that each 6CO for a full
   IPv6 address context adds 24 bytes to the RA message (Annex A), which
   incurs an amount of overhead which is not negligible for certain
   LPWAN setups.



Gomez, et al.          Expires September 22, 2016               [Page 6]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   If the network follows the star topology, optimizations for header
   compression that leverage this type of network topology may be used
   (see section 3.2.4 of [RFC7668]).

9.  Unicast and multicast mapping

   In some LPWAN technologies, layer two multicast is not supported.  In
   that case, if the network topology is a star, the solution and
   considerations of section 3.2.5 of [RFC7668] may be applied.

10.  Security Considerations

   TBD

11.  Acknowledgments

   In section 4, the authors have reused part of the content available
   in section 3.2.1 of RFC 7668, and would like to thank the authors of
   that specification.

   Carles Gomez has been funded in part by the Spanish Government
   (Ministerio de Educacion, Cultura y Deporte) through the Jose
   Castillejo grant CAS15/00336.  His contribution to this work has been
   carried out during his stay as a visiting scholar at the Computer
   Laboratory of the University of Cambridge.

12.  Annex A.  RFC 6775 message size analysis

   -- Router Solicitation (RS), without options: 8 bytes

   -- Router Advertisement (RA), without options: 16 bytes

   -- Neighbor Solicitation (NS), without options: 24 bytes

   -- Neighbor Advertisement (NA), without options: 24 bytes

   -- Source Link-Layer Address Option (SLLAO): 2 bytes + link layer
   address size (bytes)

   -- Prefix Information Option (PIO): 16 bytes + prefix size (bytes)

   -- 6LoWPAN Context Option (6CO): 8 bytes + context prefix size
   (bytes)

   -- Address Registration Option (ARO): 16 bytes

   For the following calculations, a Link Layer Address (LLA) of 4
   bytes, a prefix of 8 bytes, and a context prefix of 16 bytes (for



Gomez, et al.          Expires September 22, 2016               [Page 7]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   maximum compression) have been assumed.  A single 6CO is assumed, as
   a minimalistic use of header compression.  (Note: the Authoritative
   Border Router Option (ABRO) will not be present in networks that
   follow the star topology.)

   Message sizes:

   -- Size of RS with SLLAO = 14 bytes

   -- Size of RA with SLLAO, PIO and 6CO = 62 bytes

   -- Size of NS with ARO and SLLAO = 46 bytes

   -- Size of NA + ARO = 40 bytes

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

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

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              DOI 10.17487/RFC4903, June 2007,
              <http://www.rfc-editor.org/info/rfc4903>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <http://www.rfc-editor.org/info/rfc6282>.





Gomez, et al.          Expires September 22, 2016               [Page 8]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <http://www.rfc-editor.org/info/rfc6775>.

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
              <http://www.rfc-editor.org/info/rfc7668>.

13.2.  Informative References

   [I-D.gomez-lpwan-fragmentation-header]
              Gomez, C., Paradells, J., and J. Crowcroft, "Optimized
              6LoWPAN Fragmentation Header for LPWAN", draft-gomez-
              lpwan-fragmentation-header-01 (work in progress), March
              2016.

   [I-D.hong-6lo-use-cases]
              Hong, Y. and C. Gomez, "Use cases for IPv6 over Networks
              of Resource-constrained Nodes", draft-hong-6lo-use-
              cases-01 (work in progress), March 2016.

   [I-D.ietf-6man-default-iids]
              Gont, F., Cooper, A., Thaler, D., and S. LIU,
              "Recommendation on Stable IPv6 Interface Identifiers",
              draft-ietf-6man-default-iids-10 (work in progress),
              February 2016.

   [I-D.minaburo-lp-wan-gap-analysis]
              Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP
              Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in
              progress), February 2016.

Authors' Addresses

   Carles Gomez
   UPC/i2CAT
   C/Esteve Terradas, 7
   Castelldefels  08860
   Spain

   Email: carlesgo@entel.upc.edu







Gomez, et al.          Expires September 22, 2016               [Page 9]


Internet-Draft          IPv6 over LPWAN analysis              March 2016


   Josep Paradells
   UPC/i2CAT
   C/Jordi Girona, 1-3
   Barcelona  08034
   Spain

   Email: josep.paradells@entel.upc.edu


   Jon Crowcroft
   University of Cambridge
   JJ Thomson Avenue
   Cambridge, CB3 0FD
   United Kingdom

   Email: jon.crowcroft@cl.cam.ac.uk



































Gomez, et al.          Expires September 22, 2016              [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/