Internet DRAFT - draft-gomez-lpwan-ipv6-analysis
draft-gomez-lpwan-ipv6-analysis
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]
