[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
6lpwa                                                 X. Vilajosana, Ed.
Internet-Draft                                              Worldsensing
Intended status: Standards Track                               M. Dohler
Expires: January 9, 2017                           King's College London
                                                                A. Yegin
                                                                Actility
                                                            July 8, 2016


               Transmission of IPv6 Packets over LoRaWAN
                   draft-vilajosana-lpwan-lora-hc-00

Abstract

   This document describes how IPv6 is transmitted over LoRaWAN using
   6LowPAN techniques.  LoRaWAN is a wireless communication system for
   long-range low-power low-data-rate applications.  LoRaWAN networks
   typically are laid out in a star topology in the field with gateways
   relaying messages between end-devices and a central network server in
   the backend, the complete system referred to as star of stars
   network.

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 January 9, 2017.

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
   publication of this document.  Please review these documents



Vilajosana, et al.       Expires January 9, 2017                [Page 1]


Internet-Draft                 lpwan-lora                      July 2016


   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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of LoRaWAN Technology  . . . . . . . . . . . . . . .   3
   4.  Specification of IPv6 over LoRaWAN  . . . . . . . . . . . . .   3
     4.1.  Protocol stack  . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Link Model  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Stateless Address Auto-configuration  . . . . . . . . . .   5
       4.3.1.  LoRaWAN Addressing  . . . . . . . . . . . . . . . . .   5
       4.3.2.  Address Auto-Configuration  . . . . . . . . . . . . .   6
     4.4.  Neighbour Discovery . . . . . . . . . . . . . . . . . . .   7
     4.5.  Header Compression in LoRaWAN . . . . . . . . . . . . . .   9
     4.6.  Fragmentation in LoRaWAN  . . . . . . . . . . . . . . . .   9
   5.  Internet Connectivity Scenarios . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  External Informative References . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   LoRa is a wireless technology for long-range low-power low-data-rate
   applications developed by Semtech, which is used in LoRaWAN networks.
   LoRaWAN networks typically are organized in a star-of-stars topology
   in which gateways relay messages between end-devices and a central
   network server in the backend.  Gateways are connected to the network
   server via IP links while end-devices use single-hop LoRaWAN
   communication to one or many gateways.  All communication is
   generally bi-directional, although uplink communication from end-
   devices to the network server are strongly favoured.

   Communication between end-devices and gateways is spread out among
   different frequency channels and so-called spreading factors.
   Selecting a spreading factor is a trade-off between required link
   budget and data rate.  Spreading factors create virtual and
   orthogonal non-interfering communication channels that enable
   simultaneous transmissions.  Depending on the used spreading factor,
   LoRaWAN data rates range from 0.3 kbps to 50 kbps.  To maximize both



Vilajosana, et al.       Expires January 9, 2017                [Page 2]


Internet-Draft                 lpwan-lora                      July 2016


   battery life of end-devices and overall network capacity, the LoRaWAN
   network infrastructure manages the data rate and RF output for each
   end-device individually by means of an adaptive data rate (ADR)
   scheme.  End-devices may transmit on any channel available at any
   time, using any available data rate.

   The consolidation of that technology and its important impact in the
   M2M market, is triggering the need for end to end IP connectivity
   from end devices to the backend server without the need of proxying
   roles taken at Gateways.  Due to the constrained nature of LoRaWAN
   devices, the compression techniques developed by 6LowPAN become
   mandatory.  The present document specifies how IPv6 and the 6LowPAN
   architecture run on top of the LoRaWAN MAC layer.

2.  Requirements Language

   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 RFC 2119 [RFC2119].

3.  Overview of LoRaWAN Technology

   TODO briefly describe the technology.  Phy layer and modulation.  MAC
   operation and frame formats.

   Figure 1: LoRaWAN Class A transmission and reception window.

   |----------------------------|         |--------|     |--------|
   |             Tx             |         |   Rx   |     |   Rx   |
   |----------------------------|         |--------|     |--------|
                                |---------|
                                 Rx delay 1
                                |------------------------|
                                 Rx delay 2

4.  Specification of IPv6 over LoRaWAN

   The LoRaWAN technology enables low power wide area network coverage
   at the cost of reduced data rate and to obey to strict spectrum
   occupancy regulations.  This imposes strict communication limitations
   that make applications using LoRaWAN to contain the amount of data
   that is transmitted.  6LoWPAN standards RFC4944, RFC6775, and RFC6282
   enable IP connectivity while leverage the overhead of fully IPv6
   headers.  They also provides standard Internet connectivity by
   enabling IPv6 addressing and stateless IPv6 address auto-
   configuration, Neighbour Discovery and most importantly Header
   Compression.  The main difference between IEEE 802.15.4 and LoRaWAN
   is that LoRaWAN builds stars and star of stars networks not requiring



Vilajosana, et al.       Expires January 9, 2017                [Page 3]


Internet-Draft                 lpwan-lora                      July 2016


   a routing protocol nor multi-hop operation.  At the same time LoRaWAN
   is subject to bandwidth, data rate, radio duty-cycle regulations and
   frame size constraints that impose strict limitation in the protocol
   overhead that is supported when compared to IEEE 802.15.4.

4.1.  Protocol stack

   Figure 2: Protocol Stack for IPv6 over LoRaWAN


      +----------------------------------------+ ------------------
      |                                        |     Transport and
      |         Upper Layer Protocols          |  Application Layer
      +----------------------------------------+ ------------------
      |                                        |         |
      |                 IPv6                   |         |
      |                                        |      Network
      +----------------------------------------+       Layer
      |Adaptation Layer for IPv6 over LoRaWAN  |         |
      +----------------------------------------+ ------------------
      |                                        |
      |      IPv6-LOR Addressing Binding       | LoRaWAN Link Layer
      |                                        |         |
      +----------------------------------------+ ------------------
      |                                        |         |
      |               Activities               |      LoRaWAN
      |            Digital Protocol            |   Physical Layer
      |               RF Analog                |         |
      |                                        |         |
      +----------------------------------------+ ------------------

   Adaptation layer for IPv6 over LoRaWAN SHALL support neighbour discovery,
   address auto-configuration, header compression, and fragmentation and
   reassembly.


4.2.  Link Model

   According to RFC 4861 [RFC4861] a link is "a communication facility
   or medium over which nodes can communicate at the link layer, i.e.,
   the layer immediately below IPv6."

   In LoRaWAN the IPv6 layer is designed to enable transmission of IPv6
   packets over LoRaWAN links.  The LoRaWAN protocol is in charge of
   establishing the pairwise communication between the LoRaWAN gateway
   and the LoRaWAN device.  The IPv6 adaptation layer however is in
   charge of managing header compression and packet fragmentation in




Vilajosana, et al.       Expires January 9, 2017                [Page 4]


Internet-Draft                 lpwan-lora                      July 2016


   order to deal with different spreading factors and allowed packet
   payload at the underlying MAC layer.

   Per this specification, the IPv6 header compression format specified
   in RFC 6282 MUST be used [RFC6282] but more drastic compression based
   on provisioning an extended context in the Neighbor Solicitation (NS)
   is expected in the upcoming revision.  The IPv6 payload length can be
   derived from the LoRaWAN MAC header length and the possibly elided
   IPv6 address can be reconstructed from the link-layer address, used
   at the time of LoRaWAN connection establishment.  As described in
   Section 4.5 context information or more aggressive compression
   formats such as RoHC [RFC3095] SHOULD be used at the 6LBR in order to
   compress well-known network prefixes and indicated at the specific
   field of the IPHC header.  This compression will be defined in the
   upcomming revisions.

   LoRaWAN networks form star topologies or star of stars, having a
   point-to-point nature.  Address assignment is managed by the 6LBR
   that ensures that collisions do not occur.  Broadcast features are
   used mainly by the 6LBR.  6LN to 6LN communications are always
   carried out through the 6LBR and hence it is in charge of relaying
   link local packets.

   After the LoRaWAN node and the LoRaWAN gateway have established the
   LoRaWAN connection, the link is enabled and IPv6 address
   configuration and subsequent transmission are able to start.

4.3.  Stateless Address Auto-configuration

   Nodes (both hosts and routers) in a LoRaWAN network MAY use the
   address auto-configuration process.  This process relies in the
   ability for a node to generate a link-local address for the
   communication interface.  A link-local address is formed by appending
   an identifier of the interface to the well-known link-local prefix
   [RFC4291].  Before the link-local address can be assigned to an
   interface and used, a node must attempt to verify that this
   "tentative" address is not already in use by another node on the
   link.  This section describes how LoRaWAN nodes determine the address
   to be used and how this address is bound to the 6LBR node (or
   Gateway).

4.3.1.  LoRaWAN Addressing

   The DevEUI is a global end-device ID in IEEE EUI64 address space that
   uniquely identifies the end-device.  The DevEUI is preconfigured at
   each node.





Vilajosana, et al.       Expires January 9, 2017                [Page 5]


Internet-Draft                 lpwan-lora                      July 2016


   A LoRaWAN device addressing can be conducted in two ways.  Over the
   air activation (OTAA) and Activation by personalization (ABP).  The
   former requires 2 MAC layer messages to establish the network address
   and security keys (join-request and join-response).  The latter
   assumes that device address and security keys are pre-programmed at
   the nodes and the DevEUI is not mandatory.  Lately, the LoRa Alliance
   is considering to mandate DevEUI in ABP mode.

   Figure 3: DevEUI

   +------------+----------------+
   |  Bit#      |    [63..0]     |
   +------------+----------------+
   | DevEUI     |     DevEUI     |
   +------------+----------------+

4.3.2.  Address Auto-Configuration

   A LoRaWAN end device performs stateless address auto-configuration as
   per [RFC4862].  A 64-bit Interface identifier (IID) for a LoRaWAN
   interface MAY be formed by utilizing the 64-bit LoRaWAN DevEUI.  That
   IID MAY guarantee a stable IPv6 address and MUST be used along the
   lifetime of the network.

   According to [RFC7136], interface IIDs of all unicast addresses for
   LoRaWAN-enabled devices MUST be formed on the basis of 64 bits long
   and constructed using the EUI-64 format.  LoRaWAN End Device
   Addresses MUST follow a stateless address auto-configuration with the
   64 bit DevEUI.

   [RFC4291] indicates the use of a "Universal/Local" scope bit that
   identifies the network device to be locally accessible or globally
   accessible.  The former SHOULD be followed and LoRaWAN end-devices
   SHOULD set to 0 the "Universal/Local" bit.  In the case that a
   Universally accessible IPv6 address needs to be used a Neighbor
   Discovery mechanism and a network commissioning procedure is
   required.  This procedure is described in Section 4.4.

   LoRaWAN IPv6 Network Prefix is build using the link-local prefix
   FE80::/64.  The IPv6 link-local address for a LoRaWAN-enabled device
   is formed by appending the IID, to the prefix, as depicted in
   Figure 4.

   Duplicate address detection for link-local addresses is performed by
   the 6LBR.






Vilajosana, et al.       Expires January 9, 2017                [Page 6]


Internet-Draft                 lpwan-lora                      July 2016


   Once a 6LN has established its own link-local address, it starts
   sending Router Solicitation messages as described in [RFC4861]
   Section 6.3.7.

   For non-link-local addresses a 64-bit IID MAY be formed by utilizing
   the 64-bit LoRaWAN DevEUI as described in this section.  A 6LN can
   also use a the EUI-64 generated IID from the MAC Layer.  The non-
   link-local addresses generated by the 6LN MUST be registered with the
   6LBR.

   The mechanism by which the 6LBR obtains an IPv6 prefix is out of
   scope of this document but can for example be accomplished by using
   Unique Local IPv6 Unicast Addresses (ULA) [RFC4193].  As 6LNs MUST
   always communicate to the 6LBR, the "on-link" flag (L) MUST be set to
   zero in the Prefix Information Option [RFC4861].  This will always
   happen even when the destination is another 6LN using the same
   prefix.

   Figure 4: IPv6 link-local address in LoRaWAN

     0          0                 0               0                1
     0          1                 6               9                2
     0          0                 4               6                7
     +----------+-----------------+---------------+----------------+
     |1111111010|      zeros      |             DevEUI             |
     +----------+-----------------+---------------+----------------+
     |                                                             |
     | /-------------------------- 128 bits ----------------------/|
     |                                                             |


4.4.  Neighbour Discovery

   Neighbour Discovery is addressed following the classical ND approach
   as defined by [RFC4861] , [RFC4862] and [RFC6775].  As LoRaWAN
   networks can be organized in star topologies or star of stars
   topologies the LoRaWAN manager can take two differentiated roles.
   For single star topologies the LoRaWAN manager will act as a 6LBR and
   MUST keep track of the nodes addresses within the link, otherwise it
   acts as 6LR and forwards Node Solicitation and ARO requests to the
   6LBR in the network.










Vilajosana, et al.       Expires January 9, 2017                [Page 7]


Internet-Draft                 lpwan-lora                      July 2016


   Figure 5: ND Procedure for a single star topology


    LoRaWAN node                      LoRaWAN 6LR/6LBR
         |    Router Solicitation (RS)     |
         |-------------------------------->|
         |                                 |
         |    Router Advertisement (RA)    |
         |<--------------------------------|
         |                                 |
         |    Neighbour Solicitation (NS)  |
         |-------------------------------->|
         |                                 |
         |    Neighbour Advertisement (NA) |
         |<--------------------------------|
         |                                 |


   When a LoRaWAN node joins a network, it sends an RS to the 6LR
   containing its IID as described in Section 4.3.2.  The 6LBR router
   answers with a RA containing its IIDs and prefixes.  Hosts receive
   Router Advertisement messages containing the Authoritative Border
   Router Option (ABRO), the IIDs of the 6LR or 6LBR and MAY optionally
   contain one or more 6LoWPAN Context Options (6COs).  They also
   contain the existing Prefix Information Options (PIOs) as described
   in [RFC4861].

   When a host has configured a non-link-local IPv6 address, it
   registers that address with one or more of its default routers using
   the Address Registration Option (ARO) in an NS message.  The host
   chooses a lifetime of the registration and repeats the ARO
   periodically (before the lifetime runs out) to maintain the
   registration.  The host needs to refresh its prefix and context
   information by sending a new unicast NS.  As LoRaWAN might use very
   low data rates it is recommended to use large Lifetime configurations
   assuming that LoRaWAN devices are not mobile.  According to [RFC6775]
   the maximum Router Lifetime is about 18 hours, whereas the maximum
   Registration Lifetime is about 45.5 days.

   Future versions of this document should consider the ND approach
   described in [efficient-nd]

   The ND Procedure for star of stars follows the multi-hop ND approach
   described by [RFC6775].  The multihop distribution relies on RS
   messages and RA messages sent between routers, and using the ABRO
   version number to control the propagation of the information
   (prefixes and context information) that is being sent in the RAs.




Vilajosana, et al.       Expires January 9, 2017                [Page 8]


Internet-Draft                 lpwan-lora                      July 2016


   Figure 6: ND Procedure for star of stars in LoRaWAN.


 LoRaWAN node                     LoRaWAN 6LR                      LoRaWAN 6LBR
      |    Router Solicitation (RS)    |                                  |
      |------------------------------->|                                  |
      |                                |                                  |
      |    Router Advertisement (RA)   |                                  |
      |<-------------------------------|                                  |
      |                                |                                  |
      |    Node Registration (NR)      |                                  |
      |------------------------------->|                                  |
      |                                |  Neighbour Solicitation (NS)     |
      |                                |--------------------------------->|
      |                                |                                  |
      |                                |   Neighbour Advertisement (NA)   |
      |                                |<---------------------------------|
      |    Node Confirmation (NC)      |                                  |
      |<-------------------------------|                                  |
      |                                |                                  |


4.5.  Header Compression in LoRaWAN

   TODO.

4.6.  Fragmentation in LoRaWAN

   TODO.

5.  Internet Connectivity Scenarios

   TODO.

6.  Security Considerations

   The transmission of IPv6 over LoRaWAN links has similar requirements
   and concerns for security as for IEEE 802.15.4.  LoRaWAN Link Layer
   security considerations are covered by the LoRaWAN Specification
   [LoRaSpec].

7.  IANA Considerations

   There are no IANA considerations related to this document.







Vilajosana, et al.       Expires January 9, 2017                [Page 9]


Internet-Draft                 lpwan-lora                      July 2016


8.  Acknowledgements

   The authors would like to acknowledge the guidance and input provided
   by Pascal Thubert.

9.  References

9.1.  Normative References

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <http://www.rfc-editor.org/info/rfc7136>.

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

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

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

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

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

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.





Vilajosana, et al.       Expires January 9, 2017               [Page 10]


Internet-Draft                 lpwan-lora                      July 2016


   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
              July 2001, <http://www.rfc-editor.org/info/rfc3095>.

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

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

9.2.  External Informative References

   [LoRaSpec]
              LoRa Alliance, "LoRaWAN Specification Rev.3", April 2014.

   [efficient-nd]
              Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update
              to 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-00 , May
              2016.

Authors' Addresses

   Xavier Vilajosana (editor)
   Worldsensing
   483 Arago 4th floor
   Barcelona, Catalonia  08013
   Spain

   Email: xvilajosana@worldsensing.com


   Mischa Dohler
   King's College London
   London, London
   UK

   Email: mischa.dohler@kcl.ac.uk







Vilajosana, et al.       Expires January 9, 2017               [Page 11]


Internet-Draft                 lpwan-lora                      July 2016


   Alper Yegin
   Actility
   Paris, Paris
   FR

   Email: alper.yegin@actility.com













































Vilajosana, et al.       Expires January 9, 2017               [Page 12]