Internet DRAFT - draft-qin-lpwan-dau
draft-qin-lpwan-dau
LPWAN X. Qin
Internet-Draft N. Kong
Intended status: Experimental CNNIC
Expires: November 10, 2016 May 9, 2016
Data Aggregation Unit for LP-WAN
draft-qin-lpwan-dau-00
Abstract
Connecting LP-WANs(Low-Power Wide Area Networks) to the Internet is
expected to provide significant benefits to these networks in terms
of interoperability, application deployment, and management,among
others. However, the specific characteristics of LP-WANs, such as
very limited data unit size, and large-scale data sets make the
network operation more complex: using one IP packet to send one LP-
WAN data unit is a waste of bandwidth(because the packet header is
much bigger than payload), and the large-scale LP-WAN data sets can
also increase the Internet burden. This specification defines a Data
Aggregation Unit(DAU) for LP-WANs to aggregate small-size date units
into bigger data chains so they can be sent through the Internet more
efficiently.
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 November 10, 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
Qin & Kong Expires November 10, 2016 [Page 1]
Internet-Draft Data Aggregation Unit for LP-WAN May 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statemate . . . . . . . . . . . . . . . . . . . . . . 4
3. L-DAU Scheme . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. L-DAU Format . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The existing pilot deployments of LP-WANs have shown the huge
potential and the industrial interest in their capabilities, such as
in control and monitoring applications. Examples of LPWAN
technologies include LoRa, SigFox, IEEE 802.15.4k LECIM, DASH-7,
Weightless, etc. [I-D.minaburo-lp-wan-gap-analysis]. Connecting
these LP-WANs to the Internet is expected to provide significant
benefits to these networks in terms of interoperability, application
deployment, and management, among others. For these reasons, more
and more LP-WAN owners are connecting their own LP-WANs to the
Internet.
Qin & Kong Expires November 10, 2016 [Page 2]
Internet-Draft Data Aggregation Unit for LP-WAN May 2016
It is generally desirable that a given Data Unit(DU) generated by any
LP-WANs can be sent through the Internet efficiently and quickly.
However, the intrinsic characteristics of LP-WANs, very limited DU
size and large-scale DU sets make the data transmission through
Internet more complex. In a nutshell, that may be a terrible waste
of bandwidth if use one IP packet to send one LP-WAN Data Unit(LDU),
because the packet header is much bigger than payload.And what's
more, the LP-WAN usually consists of many nodes, so the large-scale
data may increase the Internet burden. This is the motivation for
aggregating these small-size LDUs into a bigger data chain to improve
the percentage of the payload in IP packet to make the information
retrieval and dissemination more efficient. For example,a ZigBee
Cluster can aggregate several LDUs into a LDU chain and send them
together as an atomic payload of the IP packet. By doing this, the
ZigBee Cluster doesn't need to initiate the transmission for every
LDU as well as improve the proportion of the payload in the IP packet
to increase the transmission efficiency.
During transmission, the aggregator cannot do any processing on the
LDUs and just encapsulates them into an aggregation chain. During
reception, the de-aggregator just opens the data chain and separately
forwards them to the applications.
This arrangement provides numerous benefits for LP-WAN
applications(both transmitter and receiver): increased delivery
efficiency, reduced transmission/receiving times, and improved
quality of experience for LP-WAN Users. Considering that a vast
number of LP-WAN devices are,as of today,battery-powered,the DAU is
also helpful for saving battery consumption.
1.1. Terminology
This document uses the following terms:
Aggregator: Software entity which resides either in the system kernel
or hardware aggregating one or more LDUs into an aggregation chain,
the payload of the IP packet that is sent through the internet. The
aggregator is usually placed into transmitter device with cache
capacity.
De-aggregator: Software entity which resides either in the system
kernel or hardware de-aggregating the LDU chain into seperate LDU,
which comes from aggregator. De-aggregator is usually placed into
receiving device with cache capacity.
Data Unit: Refers to data packets generated by LP-WANs in general,
for example generated by LoRa, SigFox, IEEE 802.15.4k LECIM, etc.
Qin & Kong Expires November 10, 2016 [Page 3]
Internet-Draft Data Aggregation Unit for LP-WAN May 2016
1.2. Abbreviations
o DU:Data Unit
o LDU: LP-WAN Data Unit
o L-DAU: LP-WAN Data Aggregation Unit
2. Problem Statemate
LP-WAN technologies are a kind of constrained and challenged networks
[RFC7228].
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.
o ultra dense networks with thousands to tens of thousands of nodes.
On the other side, the existing Internet technologies have their
specific characteristics:
o IP header is usually more than 20 bytes[RFC6864],[RFC6973], and
the Ethernet header is at least 14 bytes[RFC7796].
o TCP is a reliable and connection oriented transport
mechanism[RFC7661].
Therefore, it is obviously unwise to just encapsulate one LDU into
the IP packet. That's a waste of bandwidth and also increases
Internet burdens. However, no standards or open specifications
currently exist to solve above problems.
In the terminology of [RFC7228], these characteristics put LP-WANs
into the "challenged network" category, and the intrinsic
characteristics, current usages and architectures will allow the
group to make and justify the design choices. However, there also
some desired properties:
o preserve the end-to-end communication principle.
o maintain independence from L2 technology.
o use or adapt protocols defined by IETF to this new environment
that could be less responsive.
o use existing addressing spaces and naming schemes defined by IETF.
Qin & Kong Expires November 10, 2016 [Page 4]
Internet-Draft Data Aggregation Unit for LP-WAN May 2016
o small message size, with potentially no L2 fragmentation.
o optimize the protocol stack in order to limit the number of
duplicated functionalities; for instance acknowledgements should
not be done at several layers.
So,the L-DAU is proposed in this document to make the information
retrieval and dissemination of LP-WANs more efficient as well as
fully conforms to the principles proposed in [RFC7228].
3. L-DAU Scheme
The L-DAU service architecture is shown in Figure 1. During
transmission, a LDU is passed down from LPWAN application, and stored
temporarily by the aggregator, then aggregated into a L-DUA. During
reception, a received L-DAU is de-aggregated into seperate LDUs and
forwarded to the LP-WAN application.
+--------------------+ +--------------------+ ^
| | LPWAN | Frame Flow | LPWAN | |
S| | Application Lawer |<----------->| application | |
e| +--------------------+ +--------------------+ |g
n| | L-DAU | | L-DAU | |
d| | Aggregation | | Aggregation | |i
i| +--------------------+ +--------------------+ |v
n| | Network | | Network | |i
g| | Layer | | Layer | |e
| +--------------------+ +--------------------+ |c
| | PHY | | PHY | |e
| | Layer | | Layer | |R
V +--------------------+ +--------------------+
Figure 1 L-DAU service architecture
3.1. L-DAU Format
A L-DAU consists of a sequence of one or more L-DAU subframes as
shown in Figure 2.
Qin & Kong Expires November 10, 2016 [Page 5]
Internet-Draft Data Aggregation Unit for LP-WAN May 2016
+------------------+-----------------+------+------------------+
| L-DAU subframe 1 | L-DAU subframe 2| ... | L-DAU subframe n |
+------------------+-----------------+------+------------------+
Octets: variable variable variable
Figure 2 L-DAU format
Each L-DAU subframe consists of a LDU delimiter followed by a LDU.
Except when a L-DAU subframe is the last one in a L-DAU. The L-DAU
length should be less than 65535 octets. The LDU delimiter is 2
octets in length and the structure of the LDU delimiter is defined in
Figure 3.
Bits: B0 B1 B2 B7 B8 B15
+-----------+-----------+---------------------+---------------+
| Reserved | LDU length| Delimiter Signature | LDU |
+-----------+-----------+---------------------+---------------+
L-DAU Delimiter
Octets: <---------------------------------------------> variable
2
Figure 3 L-DAU subframe format
The fields of the L-DAU delimiter are defined in Table 1.
Qin & Kong Expires November 10, 2016 [Page 6]
Internet-Draft Data Aggregation Unit for LP-WAN May 2016
Table 1: L-DAU delimiter fields
+-----------+--------+---------------------------------------------+
| Field | Size | Description |
| | (Bits) | |
+-----------+--------+---------------------------------------------+
| Reserved | 2 | |
+-----------+--------+---------------------------------------------+
| LDU Length| 6 | Length of the LDU in octets |
+-----------+--------+---------------------------------------------+
| | 8 | Pattern that may be used to detect an L-DAU|
| Delimiter | | delimiter when scanning for a delimiter. |
| Signature | | The unique pattern is set to the value |
| | | 0x7E. |
| | | |
+-----------+--------+---------------------------------------------+
The purpose of the L-DAU delimiter is to locate the LDUs within the
L-DAU.
4. Security Considerations
This document focuses on approach and the motivational for L-DUA, and
does not analyze the associated threats. Those threats will be
discussed in future.
5. Acknowledgments
The authors wish to thank Linlin Zhou for her invaluable comments.
6. References
6.1. Normative References
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<http://www.rfc-editor.org/info/rfc6864>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[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>.
Qin & Kong Expires November 10, 2016 [Page 7]
Internet-Draft Data Aggregation Unit for LP-WAN May 2016
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015,
<http://www.rfc-editor.org/info/rfc7661>.
[RFC7796] Jiang, Y., Ed., Yong, L., and M. Paul, "Ethernet-Tree
(E-Tree) Support in Virtual Private LAN Service (VPLS)",
RFC 7796, DOI 10.17487/RFC7796, March 2016,
<http://www.rfc-editor.org/info/rfc7796>.
6.2. Informative References
[PPSP-Charter]
Y, Yan., "simulated-annealing algorithm", December 2009,
<http://datatracker.ietf.org/wg/ppsp/charter/>.
Authors' Addresses
Xiaowei Qin
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3689
Email: qinxiaowei@cnnic.cn
Ning Kong
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3147
Email: kongning@cnnic.cn
Qin & Kong Expires November 10, 2016 [Page 8]
