Internet DRAFT - draft-heile-lpwan-wisun-overview
draft-heile-lpwan-wisun-overview
lpwan B. Heile
Internet-Draft Wi-SUN Alliance
Intended status: Informational B. Liu
Expires: January 4, 2018 M. Zhang
Huawei Technologies
C. Perkins
Futurewei
July 3, 2017
Wi-SUN FAN Overview
draft-heile-lpwan-wisun-overview-00
Abstract
This draft presents an informational overview of the Wi-SUN
technology, which gives the principal characteristics of the
protocols that have been adopted. The objective is to provide
overview information for the IETF LPWAN working group. We also
identify relevant characteristics of Wi-SUN that make it suitable for
deployment in LPWWANs.
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 4, 2018.
Copyright Notice
Copyright (c) 2017 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
Heile, et al. Expires January 4, 2018 [Page 1]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 4
5. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Cluster Tree . . . . . . . . . . . . . . . . . . . . . . 6
6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Unicast Addressing . . . . . . . . . . . . . . . . . . . 9
7.2. Multicast Addressing . . . . . . . . . . . . . . . . . . 9
8. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Layer-3 routing: Route-Over . . . . . . . . . . . . . . . 10
8.2. L2 routing: Mesh-Under . . . . . . . . . . . . . . . . . 11
9. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Frame Formats . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Information Elements . . . . . . . . . . . . . . . . . . 11
10. Wi-SUN Alliance . . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Wi-SUN is a wireless communication technology designed for Utilities,
Smart Cities and IoT. Wi-SUN is based on various IEEE, IETF, and
ANSI/TIA standards supporting low power and lossy networks. Use
cases for Wi-SUN that are relevant for LPWAN may be found in a
companion document [draft-wisun-use-cases].
This document provides an overview of the Wi-SUN FAN technology,
based on the FAN Technical Profile Specification [FANTPS]. The FAN
technical profile is a product of the Wi-SUN Alliance (see
Section 10).
The remainder of this document describes the Wi-SUN FAN profile in
more detail to support the inclusion of Wi-SUN as a technology choice
Heile, et al. Expires January 4, 2018 [Page 2]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
that can beneficially be used in the deployment of low-power, wide-
area networks (LPWANs).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Additionally, this document uses the following terms:
Border Router: a node that provides WAN connectivity to the FAN,
maintains source routing tables, provides node authentication and key
management services, and disseminates PAN wide information.
DAO: DODAG Destination Advertisement Object [RFC6550]
DIO: DODAG Information Object
DIS: DODAG Information Solicitation
DODAG: Destination oriented Directed Acyclic Graph
IE: Information Element
FAN: Field Area Network, containing one or more PANs
FFD: A Full-Function Device, which can act as a Border Router, a
Router Node, or a Leaf Node.
Leaf Node: a node that offers minimum capabilities such as
discovering and joining a PAN, sending/receiving IPv6 packets, etc.
PAN: Personal Area Network
RFD: A Reduced-Function Device. A RFD does not allow other devices
to associate, and can only act as Leaf Node.
Router Node: a node that provides upward and downward packet
forwarding, as well as security and address management protocols
relaying.
Wi-SUN: Wireless Smart Ubiquitous Network
Heile, et al. Expires January 4, 2018 [Page 3]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
3. Characteristics
WiSUN [FANTPS] is an established suite of IoT technologies that is
based on IEEE 802.15.4, TCP/IP, and related standard protocols as
detailed in the following sections. Important characteristics of
WiSUN include the following:
Coverage
Range measured in kilometers
Development Ecosystem
WiSUN Alliance with task groups for targeted use cases and assured
interoperability (see Section 10)
High Bandwidth
Up to 300 kbps
Low Latency
0.02 seconds
Mesh Routing
Resilient and scalable
Power Efficiency
less than 2 uA when resting; 8 mA when listening
Scalability
Networks to 5,000 devices; 10 million endpoints worldwide
Security
Public key certificates, AES, HMAC, dynamic key refresh, hardened
crypto
Taken as a whole, these characteristics support consideration of
WiSUN protocol solution as an implementation choice for LPWAN.
4. Protocol Stack
The stack overview of Wi-SUN FAN is illustrated in Figure 1. The PHY
layer is based on IEEE 802.15.4g, which provides bi-directional
communication with high data rate (up to 300kbps) and low latency.
The low power consumption permits a battery-powered FAN device to
listen frequently while maintaining a lifetime measured in years.
The MAC sub-layer is based on IEEE 802.15.4e along with Wi-SUN
defined Information Extensions (IEs). The network layer is IPv6 with
6LoWPAN [RFC6282] adaptation. The Wi-SUN FAN supports star and mesh
topologies, as well as hybrid star/mesh deployments. Two methods are
available for packet routing: RPL [RFC6550] non-storing mode is
Heile, et al. Expires January 4, 2018 [Page 4]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
mandatory at the network layer, and MHDS [ANSITIA-4957.200] is
optional at the Logical Link Control (LLC) sub-layer. The transport
layer provides both UDP and TCP services.
+--------------------------------------+
| Application |
+------------+-------------------------+ +---------+
| Transport | UDP/TCP | |Security |
+------------+-------------------------+ +---------+
| Network | IPv6/ICMPv6/RPL/6LoWPAN | | 802.1X |
+------------+-------------------------+ | EAP-TLS |
| | LLC Sub-Layer | | 802.1fi |
| | +-------+ | | |
| | |L2 MESH| | |+-------+|
| Data Link +--------+-------+--------+ || ETSI- ||
| | MAC Sub-Layer | ||TS-102-||
| | IEEE 802.15.4e | || 887-2 ||
| | IE extensions | |+-------+|
+------------+-------------------------+ +---------+
| PHY | IEEE 802.15.4g |
+------------+-------------------------+
Figure 1: Stack Overview
A Wi-SUN FAN node can operate in any of the regional frequency bands
defined in [PHYSPEC], i.e. 470-510MHz, 779-787MHz and 920.5-924.5MHz
in China, 863-870MHz and 870-876MHz in Europe, or 920-928MHz in USA,
Canada and Japan. The radio interface is also compliant with local
regulations of India, Mexico, Brazil, Australia, New Zealand, Korea,
Philippines, Malaysia, Hong Kong, Singapore, Thailand, and Vietnam.
The MAC layer supports channel hopping for both unicast and broadcast
frame transmission. The total number of channels available is
determined by the regional band and the channel spacing. A node can
also choose to exclude a set of channels from its hopping sequence.
A channel function defines a method used to determine, from the list
of available PHY channels, the specific channel upon which a node is
operating at a given time [FANTPS]. The resulting hopping schedule
is advertised to the neighbors. A variety of channel functions can
be implemented, including TR51 [ANSITIA-4957.200], direct hash
[FANTPS], fixed channel and vendor defined channel functions.
Related information is encapsulated in the unicast/broadcast schedule
IE.
Wi-SUN FAN's PHY layer supports data rates ranging from 50-300kbps.
Wi-SUN devices support low latency (0.02s) and frequent (as often as
every 10 seconds) communications.
Heile, et al. Expires January 4, 2018 [Page 5]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
5. Topologies
The Wi-SUN FAN can operate in a star topology or a peer-to-peer mesh
topology. Either way, the FAN should include at least one FFD which
acts as the PAN coordinator. The coordinator is the primary
controller of the PAN and is often mains powered. In a star
topology, communication is established between the devices and the
PAN coordinator. In a peer-to-peer topology, any two devices can
communicate with another if they are in the range of other mesh
nodes, and multi-hop forwarding is enabled.
5.1. Star Topology
+-+
|R| C: PAN Coordinator
+-+ +-+ +-+ F: FFD
|R|**** * ****|F| R: RFD
+-+ * * * +-+
* * *
+-+
|C|
+-+
* * *
+-+ * * * +-+
|F|**** * ****|F|
+-+ +-+ +-+
|R|
+-+
Figure 2: Star topology
The topology of a star network is illustrated in Figure 2. When the
first FFD is activated, it chooses a PAN identifier that is not used
by any other PAN in its range. Then it becomes the coordinator and
allows both FFD and RFD to join the star PAN.
5.2. Cluster Tree
An example peer-to-peer topology is the cluster tree, which can be
regarded as a tree of PANs (clusters) as illustrated in Figure 3. In
a cluster tree, several of the nodes are FFDs, and one of them
operates as the overall coordinator. This coordinator forms the
first cluster by choosing an unused PAN identifier and broadcasting
beacon frames to discover its neighbors. A candidate device
receiving a beacon frame can request to join the network at the PAN
coordinator. If the PAN coordinator agrees on this requirement, it
adds this new devices as a child in its neighbor list. Once the
requirements are met, the first coordinator can appoint FFDs to be
Heile, et al. Expires January 4, 2018 [Page 6]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
coordinators of new clusters which are adjacent to the first cluster.
These appointed coordinators may continue to appoint coordinators of
their adjacent clusters, until all devices have joined in the cluster
tree.
+----+
+------------+ ****|PAN4| C: PAN Coordinator
|PAN1 |* +----+ F: FFD
| +-+* R: RFD
| ***|F||
| * +-+*
| * |* +----+
| +-+ +-+| ****|PAN3|
| |C|*****|R|| +----+
| +-+ +-+| +-----------------+
| * | | +-+ |
| * +-+| | |R| |
| ***|F|| | *+-+ |
| +-+* | * |
+------------+* |+-+* |
****||F| |
|+-+* +-+| +----+
| * ****|F|*****|PAN5|
| *+-+* +-+| +----+
| |F| |
| +-+* +-+|
| ****|F||
|PAN2 +-+|
+-----------------+
Figure 3: Cluster Tree
6. Discovery
In this section we describe the method by which new Wi-SUN devices
may securely discover and join an existing Wi-SUN network. For this
purpose Wi-SUN relies on EAP and 802.1x security standards. Trickle
timers are used to reduce interference and battery consumption while
still maintaining responsive connectivity.
A node is at Join State 1 with no information of the PAN when it
first is powered up. It MUST transmit PAN Advertisement Solicit
(PAS) Frames as triggered by the Advertisement Solicit trickle timer.
A received PAN Advertisement (PA) frame is accepted if information
carried in the frame matches the factory preset information (e.g. the
Network Name and Routing Method). Both PAS and PA are transmitted as
cleartext. During the Advertisement Solicit trickle interval, a node
may receive several PA frames, and it MUST select the node which
Heile, et al. Expires January 4, 2018 [Page 7]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
advertises the lowest PAN Cost [FANTPS] as its EAPOL (Extensible
Authentication Protocol over LAN) target node.
After selecting an EAPOL target node, the node is in Join State 2.
It MUST perform the 802.1x/802.11i security flow via the selected
EAPOL target node, to authenticate itself to the network and obtain
its GTKs (group transient keys) from the PAN Border Router. If the
authentication succeeds, the node MUST set its PAN ID to be that of
the EAPOL target node, and then proceeds to Join State 3. Otherwise
the node returns to Join State 1.
At Join State 3, a node transmits PAN Configuration Solicit (PCS)
frames as triggered by the Configuration Solicit trickle timer. When
a PAN configuration (PC) frame is received and decrypted
successfully, the node MUST select the source of the PC frame as its
initial source of broadcast transmissions. Then the node enters to
Join State 4. Otherwise, if a node fails to receive and decrypt a PC
frame after several retries, it returns to Join State 1.
In Join State 4, the node has been configured with its channel-
hopping schedule and active group keys. The node is then a secured
member of the PAN.
Heile, et al. Expires January 4, 2018 [Page 8]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
_____________________________________________
| |
| |
v EAPOL Target |
+--------------+ Selected +--------------+ |
| Join State 1 |------------------>| Join State 2 | |
| | | | |
| No PAN |<------------------| Acquire Keys | |
+--------------+ EAPOL Fails +--------------+ |
| |
| |
GTKs Acquired |
| |
| |
v |
+--------------+ +--------------+ |
| Join State 4 | | Join State 3 | |
| |<------------------| | |
| Secured | RX and Decrypt | PAN Selected | |
+--------------+ PAN +--------------+ |
Configuration | |
|___________|
Unsuccessful
PAN Configuration
Figure 4: FAN Join States
7. Addressing
The short addressing of 16 bit is not used in Wi-SUN, which means
that all the related addressing and header compression mechanisms
defined in IEEE 802.15.4 and the 6LoWPAN are not applied.
7.1. Unicast Addressing
The link local IPv6 address of a FAN node is auto configured
according to [RFC4291]. The address combines the well-known link
local prefix FE80::0 and the modified EUI-64 Interface Identifier.
The node's Global and Unique Local Addresses (GUA and ULA) are
managed via DHCPv6 [RFC3315].
7.2. Multicast Addressing
For both L2 and L3 routing networks, a FAN node MUST join the all-
nodes group (ff02::1) and all-routers group (ff02::2) in link scope
[RFC4291]. The realm for IEEE 802.15.4 is defined as all the
interfaces which share a common PAN ID [RFC7346]. In realm scope, a
FAN node MUST join the all-nodes group (ff03::1) and all-routers
Heile, et al. Expires January 4, 2018 [Page 9]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
group (ff03::2). A FAN node SHOULD subscribe to the unicast-prefix-
based IPv6 multicast group [RFC3306] to support MPL [RFC7731].
For L3 routing networks, a FAN node MUST also join the all-nodes
group (ff02::1a)[RFC6550] in link scope and the all-mpl-forwarders
group (ff03::fc) in realm scope.
8. Routing
8.1. Layer-3 routing: Route-Over
For Layer-3 routing, Wi-SUN FAN adopts the non-storing mode of RPL
[RFC6550]. RPL requires the construction and maintenance of DODAGs.
A DODAG rooted at the Border Router is called a "grounded DODAG".
After a link failure, some nodes may lose connection to the Border
Router; then they can form a "floating DODAG". A node's rank is
defined by its relative position to the root; the rank strictly
increases after every link from the root to the leaves.
To build a DODAG, the Border Router multicasts a DIO message to its
immediate neighbors. Each neighbor decides whether or not to join
the DODAG or not cccording to the objective function and other
criteria. If so, the Border Router is noted as their parent. Each
node in the DODAG sets trickle timers [RFC6206] for DIO message
transmission. Upon receiving a DIO, if the node is the Border Router
or the source node has a higher rank, the message is ignored; if not,
in case that the node decides to join in this DODAG, the source of
the DIO can be included in the node's DODAG parent set; the node that
has the best objective function value is marked as the most preferred
parent, which provides the default upward route from the child node.
Thus the upward packets can be routed hop-by-hop to the root. A
neighbor can send a DIS message to solicit the transmission of a DIO
message.
According to the non-storing mode of RPL, downward packets are routed
using source routing from the root. Each node, except the Border
Router, sends DAO messages to the Border Router indicating its route
to its DODAG parents. When the Border Router receives DAO messages
from all node, it scan construct source routes to any node in the
DODAG.
For communication between two peers, in the non-storing mode, the
packet goes up to the Border Router at first then sent to the
destination node via source routing [RFC6997].
When a link failure happens (e.g. by temporary obstruction), if a
node has no alternative parent it becomes the root of a floating
DODAG and sends DIO to its neighbors to advertise this change. Each
Heile, et al. Expires January 4, 2018 [Page 10]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
child node switches to an alternative parents if possible, but
otherwise stays in the floating DODAG. When receiving the DIO
messages from the nodes in the grounded DODAG, a node in the floating
DODAG tries to find a new preferred DODAG parent. Once the
connection is recovered at this node, the other nodes in the floating
DODAG can join the grounded DODAG through this new link. The
topology of the floating DODAG might be changed during this local
redirection process.
8.2. L2 routing: Mesh-Under
Mesh-under L2 routing is based on MHDS, as defined in
[ANSITIA-4957.210].
9. Encapsulation
The Wi-SUN MAC MTU is 2047 bytes as defined in IEEE802.15.4g,
satisfying the IPv6 packet length requirement. The header
compression and fragmentation in 6LoWPAN [RFC6282] can be applied.
Besides 6LoWPAN fragmentation, Wi-SUN FAN supports an optional L2
fragmentation.
9.1. Frame Formats
Wi-SUN FAN defines 7 frame formats, including PAN Advertisement
frame, PAN Advertisement Solicit frame, PAN Configuration frame, PAN
Configuration Solicit frame, Upper Layer Application Data frame,
Acknowledgment frame and EAPOL frame. Detailed information can be
found in [FANTPS].
9.2. Information Elements
Wi-SUN FAN defines its own Information Elements (IEs) to support
certain operations. Depending on where the MAC management
information is encapsulated, IEs defined in Wi-SUN can be divided
into two categories: Wi-SUN header IEs, and Wi-SUN payload IEs. A
payload IE can be longer than a header IE, and can be encrypted as a
part of the payload. Wi-SUN FAN also adopts the MP-IE defined in
IEEE802.15.9 to carry the MAC payload.
Detailed definitions and the inclusion relation of the IEs for Wi-SUN
frame types can be found in [FANTPS].
10. Wi-SUN Alliance
The Wi-SUN Alliance consists of more than 130 member companies
including product vendors, silicon vendors, software companies,
utilities, government institutions and universities. Each member
Heile, et al. Expires January 4, 2018 [Page 11]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
company contributes to the Wi-SUN ecosystem as the Wi-SUN Alliance
has defined testing and certification programs for multi-vendor
interoperability. Wi-SUN networks have been deployed for more than
10 years in mixed-vendor environments, demonstrating ongoing
commitments from a wide variety of organizations.
The mission of the Wi-SUN Alliance is to advance seamless
connectivity by promoting IEEE 802.15.4g standard-based
interoperability for regional markets worldwide. Key activities of
the Wi-SUN Alliance include the following:
Promotion of wireless Smart Ubiquitous Networks and related
applications as defined by international and regional standards
development organizations.
Advancement of wireless Smart Ubiquitous Networks worldwide
Interoperability and compliance certification programs.
User education
Industry outreach and other support programs
Lobbying regional regulatory bodies for spectrum allocation to be
used in the support of smart grid services
Provide a forum for global collaboration to achieve Smart City and
Smart Ubiquitous Communications Network Interoperability
In January 2015, the Wi-SUN Alliance released its "Technical Profile
Specification for IEEE 802.15.4g Standard-Based Field Area Networks"
(FANs) [FANTPS]. That specification integrates:
A 802.15.4g physical layer compatible with the existing Wi-SUN
Alliance PHY Certification Program
Frequency hopping, network discovery/join and protocol dispatch
The IPv6 protocol suite, including 6LoWPAN, address management,
routing using RPL, unicast and multicast forwarding
A standards-based multi-layer security specification encompassing
authentication, authorization, encryption.
Heile, et al. Expires January 4, 2018 [Page 12]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
11. Security Considerations
FAN access control is based on IEEE802.1x and EAP-TLS [RFC5216]. If
the supplicant is not able to reach the Authenticator directly, the
EAPOL Datagram can be forwarded by multiple routing nodes. FAN nodes
also support Node Pairwise (N2NP) Authentication [ETSI-TS-102-887-2]
between one-hop neighbors in the mesh.
FAN nodes MUST implement Frame Security policy based on AES-CCM* as
defined in IEEE802.15.4. The derivation of the Group AES Key and
Pairwise AES Key is described in [FANTPS]. A node MUST maintain a
frame counter for each GTK. The frame counter is set to 0 initially,
and increases with each transmission using this GTK. It is
recommended to replace a GTK which has been used for 30 days.
12. IANA Considerations
IANA need not assign anything for this document. RFC editor: please
remove this section before publication.
13. References
13.1. Normative References
[ANSITIA-4957.210]
ANSI, "Multi-Hop Delivery Specification of a Data Link
Sub-Layer", February 2013.
[draft-wisun-use-cases]
Liu, B., Zhang, M., and C. Perkins, "WiSUN use cases",
July 2017.
[FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field
Area Network", May 2016.
[PHYSPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
2016.
[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>.
[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>.
Heile, et al. Expires January 4, 2018 [Page 13]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
13.2. Informative References
[ANSITIA-4957.200]
ANSI, "Layer 2 Standard Specification for the Smart
Utility Network", January 2013.
[ETSI-TS-102-887-2]
ETSI, "Smart Metering Wireless Access Protocol; Part 2:
Data Link Layer (MAC Sub-layer)", September 2013.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
August 2002, <http://www.rfc-editor.org/info/rfc3306>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[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>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
DOI 10.17487/RFC7346, August 2014,
<http://www.rfc-editor.org/info/rfc7346>.
Heile, et al. Expires January 4, 2018 [Page 14]
Internet-Draft draft-liu-lpwan-wisun-overview July 2017
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.
Authors' Addresses
Bob Heile
Wi-SUN Alliance
11 Robert Toner Blvd, Suite 5-301
North Attleboro MA 02763
USA
Email: bheile@ieee.org
Bing Liu (Remy)
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: remy.liubing@huawei.com
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: zhangmingui@huawei.com
Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara 95050
United States
Email: charliep@computer.org
Heile, et al. Expires January 4, 2018 [Page 15]
