| 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
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.
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 (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 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.
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.
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.
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]
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.
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 (6LBR), respectively. The 6LBR may provide Internet connectivity (see Figure 1).
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.
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]).
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].
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 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].
[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.
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]).
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.
TBD
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.
-- 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 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
| [I-D.gomez-lpwan-fragmentation-header] | Gomez, C., Paradells, J. and J. Crowcroft, "Optimized 6LoWPAN Fragmentation Header for LPWAN", Internet-Draft draft-gomez-lpwan-fragmentation-header-01, March 2016. |
| [I-D.hong-6lo-use-cases] | Hong, Y. and C. Gomez, "Use cases for IPv6 over Networks of Resource-constrained Nodes", Internet-Draft draft-hong-6lo-use-cases-01, March 2016. |
| [I-D.ietf-6man-default-iids] | Gont, F., Cooper, A., Thaler, D. and S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", Internet-Draft draft-ietf-6man-default-iids-10, February 2016. |
| [I-D.minaburo-lp-wan-gap-analysis] | Minaburo, A., Pelov, A. and L. Toutain, "LP-WAN GAP Analysis", Internet-Draft draft-minaburo-lp-wan-gap-analysis-01, February 2016. |