< draft-ietf-lpwan-overview-06.txt		draft-ietf-lpwan-overview-07.txt >
	lpwan S. Farrell, Ed.		lpwan S. Farrell, Ed.
	Internet-Draft Trinity College Dublin		Internet-Draft Trinity College Dublin
	Intended status: Informational July 21, 2017		Intended status: Informational October 3, 2017
	Expires: January 22, 2018		Expires: April 6, 2018
	LPWAN Overview		LPWAN Overview
	draft-ietf-lpwan-overview-06		draft-ietf-lpwan-overview-07
	Abstract		Abstract
	Low Power Wide Area Networks (LPWAN) are wireless technologies with		Low Power Wide Area Networks (LPWAN) are wireless technologies with
	characteristics such as large coverage areas, low bandwidth, possibly		characteristics such as large coverage areas, low bandwidth, possibly
	very small packet and application layer data sizes and long battery		very small packet and application layer data sizes and long battery
	life operation. This memo is an informational overview of the set of		life operation. This memo is an informational overview of the set of
	LPWAN technologies being considered in the IETF and of the gaps that		LPWAN technologies being considered in the IETF and of the gaps that
	exist between the needs of those technologies and the goal of running		exist between the needs of those technologies and the goal of running
	IP in LPWANs.		IP in LPWANs.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 22, 2018.		This Internet-Draft will expire on April 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	Note that some of the technology-specific drafts referenced below may		Note that some of the technology-specific drafts referenced below may
	have been updated since publication of this document.		have been updated since publication of this document.
	2.1. LoRaWAN		2.1. LoRaWAN
	Text here is largely from [I-D.farrell-lpwan-lora-overview]		Text here is largely from [I-D.farrell-lpwan-lora-overview]
	2.1.1. Provenance and Documents		2.1.1. Provenance and Documents
	LoRaWAN is a wireless technology for long-range low-power low-data-		LoRaWAN is an ISM-based wireless technology for long-range low-power
	rate applications developed by the LoRa Alliance, a membership		low-data-rate applications developed by the LoRa Alliance, a
	consortium. <https://www.lora-alliance.org/> This draft is based on		membership consortium. <https://www.lora-alliance.org/> This draft
	version 1.0.2 [LoRaSpec] of the LoRa specification. Version 1.0,		is based on version 1.0.2 [LoRaSpec] of the LoRa specification. That
	which has also seen some deployment, is available at [LoRaSpec1.0].		specification is publicly available and has already seen several
			deployments across the globe.
	2.1.2. Characteristics		2.1.2. Characteristics
			LoRaWAN aims to support end-devices operating on a single battery for
			an extended period of time (e.g., 10 years or more), extended
			coverage through 155 dB maximum coupling loss, and reliable and
			efficient file download (as needed for remote software/firmware
			upgrade).
	LoRaWAN networks are typically organized in a star-of-stars topology		LoRaWAN networks are typically organized in a star-of-stars topology
	in which gateways relay messages between end-devices and a central		in which gateways relay messages between end-devices and a central
	"network server" in the backend. Gateways are connected to the		"network server" in the backend. Gateways are connected to the
	network server via IP links while end-devices use single-hop LoRaWAN		network server via IP links while end-devices use single-hop LoRaWAN
	communication that can be received at one or more gateways.		communication that can be received at one or more gateways.
	Communication is generally bi-directional; uplink communication from		Communication is generally bi-directional; uplink communication from
	end-devices to the network server is favored in terms of overall		end-devices to the network server is favored in terms of overall
	bandwidth availability.		bandwidth availability.
	Figure 1 shows the entities involved in a LoRaWAN network.		Figure 1 shows the entities involved in a LoRaWAN network.
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 39 ¶
	have all of the above, plus channel information, somehow		have all of the above, plus channel information, somehow
	(pre-)provisioned, in which case the end-device can simply start		(pre-)provisioned, in which case the end-device can simply start
	transmitting. This is achievable in many cases via out-of-band means		transmitting. This is achievable in many cases via out-of-band means
	given the nature of LoRaWAN networks. Table 3 summarizes these		given the nature of LoRaWAN networks. Table 3 summarizes these
	values.		values.
	+---------+---------------------------------------------------------+		+---------+---------------------------------------------------------+
	| Value | Description |		| Value | Description |
	+---------+---------------------------------------------------------+		+---------+---------------------------------------------------------+
	| DevAddr | DevAddr (32-bits) = device-specific network address |		| DevAddr | DevAddr (32-bits) = device-specific network address |
	| | generated from the NwkID |		| | generated from the NetID |
	| | |		| | |
	| AppEUI | IEEE EUI64 corresponding to the join server for an |		| AppEUI | IEEE EUI64 corresponding to the join server for an |
	| | application |		| | application |
	| | |		| | |
	| NwkSKey | 128-bit network session key used with AES-CMAC |		| NwkSKey | 128-bit network session key used with AES-CMAC |
	| | |		| | |
	| AppSKey | 128-bit application session key used with AES-CTR |		| AppSKey | 128-bit application session key used with AES-CTR |
	| | |		| | |
	| AppKey | 128-bit application session key used with AES-ECB |		| AppKey | 128-bit application session key used with AES-ECB |
	+---------+---------------------------------------------------------+		+---------+---------------------------------------------------------+
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	the mobility of the UE. MME tasks include tracking and paging UEs,		the mobility of the UE. MME tasks include tracking and paging UEs,
	session management, choosing the Serving gateway for the UE during		session management, choosing the Serving gateway for the UE during
	initial attachment and authenticating the user. At MME, the Non-		initial attachment and authenticating the user. At MME, the Non-
	Access Stratum (NAS) signaling from the UE is terminated.		Access Stratum (NAS) signaling from the UE is terminated.
	Serving Gateway (S-GW) routes and forwards the user data packets		Serving Gateway (S-GW) routes and forwards the user data packets
	through the access network and acts as a mobility anchor for UEs		through the access network and acts as a mobility anchor for UEs
	during handover between base stations known as eNodeBs and also		during handover between base stations known as eNodeBs and also
	during handovers between NB-IoT and other 3GPP technologies.		during handovers between NB-IoT and other 3GPP technologies.
	Packet Data Node Gateway (P-GW) works as an interface between 3GPP		Packet Data Network Gateway (P-GW) works as an interface between 3GPP
	network and external networks.		network and external networks.
	The Home Subscriber Server (HSS) contains user-related and		The Home Subscriber Server (HSS) contains user-related and
	subscription- related information. It is a database, which performs		subscription- related information. It is a database, which performs
	mobility management, session establishment support, user		mobility management, session establishment support, user
	authentication and access authorization.		authentication and access authorization.
	E-UTRAN consists of components of a single type, eNodeB. eNodeB is a		E-UTRAN consists of components of a single type, eNodeB. eNodeB is a
	base station, which controls the UEs in one or several cells.		base station, which controls the UEs in one or several cells.
	The 3GPP radio protocol architecture is illustration in Figure 4.		The 3GPP radio protocol architecture is illustrated in Figure 4.
	+---------+ +---------+		+---------+ +---------+
	| NAS |----|-----------------------------|----| NAS |		| NAS |----|-----------------------------|----| NAS |
	+---------+ | +---------+---------+ | +---------+		+---------+ | +---------+---------+ | +---------+
	| RRC |----|----| RRC | S1-AP |----|----| S1-AP |		| RRC |----|----| RRC | S1-AP |----|----| S1-AP |
	+---------+ | +---------+---------+ | +---------+		+---------+ | +---------+---------+ | +---------+
	| PDCP |----|----| PDCP | SCTP |----|----| SCTP |		| PDCP |----|----| PDCP | SCTP |----|----| SCTP |
	+---------+ | +---------+---------+ | +---------+		+---------+ | +---------+---------+ | +---------+
	| RLC |----|----| RLC | IP |----|----| IP |		| RLC |----|----| RLC | IP |----|----| IP |
	+---------+ | +---------+---------+ | +---------+		+---------+ | +---------+---------+ | +---------+
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 4 ¶
	Figure 4: 3GPP radio protocol architecture for control plane		Figure 4: 3GPP radio protocol architecture for control plane
	Control plane protocol stack		Control plane protocol stack
	The radio protocol architecture of NB-IoT (and LTE) is separated into		The radio protocol architecture of NB-IoT (and LTE) is separated into
	control plane and user plane. The control plane consists of		control plane and user plane. The control plane consists of
	protocols which control the radio access bearers and the connection		protocols which control the radio access bearers and the connection
	between the UE and the network. The highest layer of control plane		between the UE and the network. The highest layer of control plane
	is called Non-Access Stratum (NAS), which conveys the radio signaling		is called Non-Access Stratum (NAS), which conveys the radio signaling
	between the UE and the EPC, passing transparently through the radio		between the UE and the Evolved Packet Core (EPC), passing
	network. NAS responsible for authentication, security control,		transparently through the radio network. NAS responsible for
	mobility management and bearer management.		authentication, security control, mobility management and bearer
			management.
	Access Stratum (AS) is the functional layer below NAS, and in the		Access Stratum (AS) is the functional layer below NAS, and in the
	control plane it consists of Radio Resource Control protocol (RRC)		control plane it consists of Radio Resource Control protocol (RRC)
	[TGPP36331], which handles connection establishment and release		[TGPP36331], which handles connection establishment and release
	functions, broadcast of system information, radio bearer		functions, broadcast of system information, radio bearer
	establishment, reconfiguration and release. RRC configures the user		establishment, reconfiguration and release. RRC configures the user
	and control planes according to the network status. There exists two		and control planes according to the network status. There exists two
	RRC states, RRC_Idle or RRC_Connected, and RRC entity controls the		RRC states, RRC_Idle or RRC_Connected, and RRC entity controls the
	switching between these states. In RRC_Idle, the network knows that		switching between these states. In RRC_Idle, the network knows that
	the UE is present in the network and the UE can be reached in case of		the UE is present in the network and the UE can be reached in case of
	skipping to change at page 28, line 42 ¶		skipping to change at page 28, line 42 ¶
	and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange		and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange
	may be completed in a few seconds, without incurring packet		may be completed in a few seconds, without incurring packet
	fragmentation.		fragmentation.
	In other LPWANs (with a maximum payload size of ~10 bytes, and a		In other LPWANs (with a maximum payload size of ~10 bytes, and a
	message rate of ~0.1 message/minute), the same exchange may take		message rate of ~0.1 message/minute), the same exchange may take
	hours or even days, leading to severe fragmentation and consuming a		hours or even days, leading to severe fragmentation and consuming a
	significant amount of the available network resources. 6LoWPAN		significant amount of the available network resources. 6LoWPAN
	Neighbor Discovery behavior may be tuned through the use of		Neighbor Discovery behavior may be tuned through the use of
	appropriate values for the default Router Lifetime, the Valid		appropriate values for the default Router Lifetime, the Valid
	Lifetime in the PIOs, and the Valid Lifetime in the 6CO, as well as		Lifetime in the PIOs, and the Valid Lifetime in the 6LowPan Context
	the address Registration Lifetime. However, for the latter LPWANs		Option (6CO), as well as the address Registration Lifetime. However,
	mentioned above, 6LoWPAN Neighbor Discovery is not suitable.		for the latter LPWANs mentioned above, 6LoWPAN Neighbor Discovery is
			not suitable.
	4.3. 6lo		4.3. 6lo
	The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6		The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6
	support over link layer technologies such as Bluetooth Low Energy		support over link layer technologies such as Bluetooth Low Energy
	(BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC IEEE 802.11ah. (See		(BTLE), ITU-T G.9959, DECT-ULE, MS/TP-RS485, NFC IEEE 802.11ah. (See
	<https://tools.ietf.org/wg/6lo> for details.) These technologies are		<https://tools.ietf.org/wg/6lo> for details.) These technologies are
	similar in several aspects to IEEE 802.15.4, which was the original		similar in several aspects to IEEE 802.15.4, which was the original
	6LoWPAN target technology.		6LoWPAN target technology.
	skipping to change at page 30, line 35 ¶		skipping to change at page 30, line 38 ¶
	L2 acknowledgments. On the other hand, the current work in progress		L2 acknowledgments. On the other hand, the current work in progress
	in the CoRE WG where the COMI/CoOL network management interface		in the CoRE WG where the COMI/CoOL network management interface
	which, uses Structured Identifiers (SID) to reduce payload size over		which, uses Structured Identifiers (SID) to reduce payload size over
	CoAP may prove to be a good solution for the LPWAN technologies. The		CoAP may prove to be a good solution for the LPWAN technologies. The
	overhead is reduced by adding a dictionary which matches a URI to a		overhead is reduced by adding a dictionary which matches a URI to a
	small identifier and a compact mapping of the YANG model into the		small identifier and a compact mapping of the YANG model into the
	CBOR binary representation.		CBOR binary representation.
	4.8. Mobility		4.8. Mobility
	LPWANs nodes can be mobile. However, LPWAN mobility is different		LPWAN nodes can be mobile. However, LPWAN mobility is different from
	from the one specified for Mobile IP. LPWAN implies sporadic traffic		the one specified for Mobile IP. LPWAN implies sporadic traffic and
	and will rarely be used for high-frequency, real-time communications.		will rarely be used for high-frequency, real-time communications.
	The applications do not generate a flow, they need to save energy and		The applications do not generate a flow, they need to save energy and
	most of the time the node will be down.		most of the time the node will be down.
	In addition, LPWAN mobility may mostly apply to groups of devices,		In addition, LPWAN mobility may mostly apply to groups of devices,
	that represent a network in which case mobility is more a concern for		that represent a network in which case mobility is more a concern for
	the gateway than the devices. NEMO [RFC3963] Mobility solutions may		the gateway than the devices. NEMO [RFC3963] Mobility or other
			mobile gateway solutions (such as a gateway with an LTE uplink) may
	be used in the case where some end-devices belonging to the same		be used in the case where some end-devices belonging to the same
	network gateway move from one point to another such that they are not		network gateway move from one point to another such that they are not
	aware of being mobile.		aware of being mobile.
	4.9. DNS and LPWAN		4.9. DNS and LPWAN
	The Domain Name System (DNS) DNS [RFC1035], enables applications to		The Domain Name System (DNS) DNS [RFC1035], enables applications to
	name things with a globally resolvable name. Many protocols use the		name things with a globally resolvable name. Many protocols use the
	DNS to identify hosts, for example applications using CoAP.		DNS to identify hosts, for example applications using CoAP.
	skipping to change at page 31, line 51 ¶		skipping to change at page 31, line 51 ¶
	more typical network, one would consider defining padding mechanisms		more typical network, one would consider defining padding mechanisms
	and allowing for cover traffic. In some LPWANs, those mechanisms may		and allowing for cover traffic. In some LPWANs, those mechanisms may
	not be feasible. Nonetheless, the privacy challenges do exist and		not be feasible. Nonetheless, the privacy challenges do exist and
	can be real and so some solutions will be needed. Note that many		can be real and so some solutions will be needed. Note that many
	aspects of solutions in this space may not be visible in IETF		aspects of solutions in this space may not be visible in IETF
	specifications, but can be e.g. implementation or deployment		specifications, but can be e.g. implementation or deployment
	specific.		specific.
	Another challenge for LPWANs will be how to handle key management and		Another challenge for LPWANs will be how to handle key management and
	associated protocols. In a more traditional network (e.g. the web),		associated protocols. In a more traditional network (e.g. the web),
	servers can "staple" OCSP responses in order to allow browsers to		servers can "staple" Online Certificate Status Protocol (OCSP)
	check revocation status for presented certificates. [RFC6961] While		responses in order to allow browsers to check revocation status for
	the stapling approach is likely something that would help in an		presented certificates. [RFC6961] While the stapling approach is
	LPWAN, as it avoids an RTT, certificates and OCSP responses are bulky		likely something that would help in an LPWAN, as it avoids an RTT,
	items and will prove challenging to handle in LPWANs with bounded		certificates and OCSP responses are bulky items and will prove
	bandwidth.		challenging to handle in LPWANs with bounded bandwidth.
	6. IANA Considerations		6. IANA Considerations
	There are no IANA considerations related to this memo.		There are no IANA considerations related to this memo.
	7. Contributors		7. Contributors
	As stated above this document is mainly a collection of content		As stated above this document is mainly a collection of content
	developed by the full set of contributors listed below. The main		developed by the full set of contributors listed below. The main
	input documents and their authors were:		input documents and their authors were:
	skipping to change at page 35, line 19 ¶		skipping to change at page 35, line 19 ¶
	Alexander Pelov and Pascal Thubert were the LPWAN WG chairs while		Alexander Pelov and Pascal Thubert were the LPWAN WG chairs while
	this document was developed.		this document was developed.
	Stephen Farrell's work on this memo was supported by Pervasive		Stephen Farrell's work on this memo was supported by Pervasive
	Nation, the Science Foundation Ireland's CONNECT centre national IoT		Nation, the Science Foundation Ireland's CONNECT centre national IoT
	network. <https://connectcentre.ie/pervasive-nation/>		network. <https://connectcentre.ie/pervasive-nation/>
	9. Informative References		9. Informative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc768>.		editor.org/info/rfc768>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,		[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
	Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and		Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
	D. Spence, "AAA Authorization Framework", RFC 2904,		D. Spence, "AAA Authorization Framework", RFC 2904,
	DOI 10.17487/RFC2904, August 2000,		DOI 10.17487/RFC2904, August 2000, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2904>.		editor.org/info/rfc2904>.
	[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,		[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
	Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,		Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
	K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,		K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
	Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header		Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
	Compression (ROHC): Framework and four profiles: RTP, UDP,		Compression (ROHC): Framework and four profiles: RTP, UDP,
	ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,		ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095,
	July 2001, <http://www.rfc-editor.org/info/rfc3095>.		July 2001, <https://www.rfc-editor.org/info/rfc3095>.
	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	C., and M. Carney, "Dynamic Host Configuration Protocol		C., and M. Carney, "Dynamic Host Configuration Protocol
	for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
	2003, <http://www.rfc-editor.org/info/rfc3315>.		2003, <https://www.rfc-editor.org/info/rfc3315>.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",		Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, DOI 10.17487/RFC3963, January 2005,		RFC 3963, DOI 10.17487/RFC3963, January 2005,
	<http://www.rfc-editor.org/info/rfc3963>.		<https://www.rfc-editor.org/info/rfc3963>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", STD 89,		Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,		RFC 4443, DOI 10.17487/RFC4443, March 2006,
	<http://www.rfc-editor.org/info/rfc4443>.		<https://www.rfc-editor.org/info/rfc4443>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc4861>.		editor.org/info/rfc4861>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<http://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
	[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS		[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
	Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,		Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
	March 2008, <http://www.rfc-editor.org/info/rfc5216>.		March 2008, <https://www.rfc-editor.org/info/rfc5216>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5246>.		editor.org/info/rfc5246>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	DOI 10.17487/RFC6282, September 2011,		DOI 10.17487/RFC6282, September 2011, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6282>.		editor.org/info/rfc6282>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<http://www.rfc-editor.org/info/rfc6775>.		<https://www.rfc-editor.org/info/rfc6775>.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013,		DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc6961>.		editor.org/info/rfc6961>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc7252>.		editor.org/info/rfc7252>.
	[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,		[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low		Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
	Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,		Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
	<http://www.rfc-editor.org/info/rfc7668>.		<https://www.rfc-editor.org/info/rfc7668>.
	[I-D.farrell-lpwan-lora-overview]		[I-D.farrell-lpwan-lora-overview]
	Farrell, S. and A. Yegin, "LoRaWAN Overview", draft-		Farrell, S. and A. Yegin, "LoRaWAN Overview", draft-
	farrell-lpwan-lora-overview-01 (work in progress), October		farrell-lpwan-lora-overview-01 (work in progress), October
	2016.		2016.
	[I-D.minaburo-lpwan-gap-analysis]		[I-D.minaburo-lpwan-gap-analysis]
	Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and		Minaburo, A., Gomez, C., Toutain, L., Paradells, J., and
	J. Crowcroft, "LPWAN Survey and GAP Analysis", draft-		J. Crowcroft, "LPWAN Survey and GAP Analysis", draft-
	minaburo-lpwan-gap-analysis-02 (work in progress), October		minaburo-lpwan-gap-analysis-02 (work in progress), October
End of changes. 32 change blocks.
	54 lines changed or deleted		64 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/