< draft-zuniga-lpwan-schc-over-sigfox-05.txt		draft-zuniga-lpwan-schc-over-sigfox-06.txt >
	lpwan Working Group JC. Zuniga		lpwan Working Group JC. Zuniga
	Internet-Draft SIGFOX		Internet-Draft SIGFOX
	Intended status: Informational C. Gomez		Intended status: Informational C. Gomez
	Expires: May 9, 2019 Universitat Politecnica de Catalunya		Expires: September 12, 2019 Universitat Politecnica de Catalunya
	L. Toutain		L. Toutain
	IMT-Atlantique		IMT-Atlantique
	November 05, 2018		March 11, 2019
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-zuniga-lpwan-schc-over-sigfox-05		draft-zuniga-lpwan-schc-over-sigfox-06
	Abstract		Abstract
	The Static Context Header Compression (SCHC) specification describes		The Static Context Header Compression (SCHC) specification describes
	a header compression scheme and a fragmentation functionality for Low		a header compression scheme and a fragmentation functionality for Low
	Power Wide Area Network (LPWAN) technologies. SCHC offers a great		Power Wide Area Network (LPWAN) technologies. SCHC offers a great
	level of flexibility that can be tailored for different LPWAN		level of flexibility that can be tailored for different LPWAN
	technologies.		technologies.
	The present document provides the optimal parameters and modes of		The present document provides the optimal parameters and modes of
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 May 9, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	5.1. Fragmentation headers . . . . . . . . . . . . . . . . . . 5		5.1. Fragmentation headers . . . . . . . . . . . . . . . . . . 5
	5.2. Uplink fragment transmissions . . . . . . . . . . . . . . 5		5.2. Uplink fragment transmissions . . . . . . . . . . . . . . 5
	5.2.1. Uplink No-ACK mode . . . . . . . . . . . . . . . . . 5		5.2.1. Uplink No-ACK mode . . . . . . . . . . . . . . . . . 5
	5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . . 6		5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . . 6
	5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6		5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6
	5.3. Downlink fragment transmissions . . . . . . . . . . . . . 6		5.3. Downlink fragment transmissions . . . . . . . . . . . . . 6
	6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security considerations . . . . . . . . . . . . . . . . . . . 8		7. Security considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. Informative References . . . . . . . . . . . . . . . . . . . 8		9. Informative References . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) specification		The Static Context Header Compression (SCHC) specification
	[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression		[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression
	scheme and a fragmentation functionality. Both can be used on top of		scheme and a fragmentation functionality. Both can be used on top of
	all the LWPAN systems defined in [RFC8376] . These LPWAN systems have		all the LWPAN systems defined in [RFC8376] . These LPWAN systems have
	similar characteristics such as star-oriented topologies, network		similar characteristics such as star-oriented topologies, network
	architecture, connected devices with built-in applications, etc.		architecture, connected devices with built-in applications, etc.
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	+--------+-------+ +-------+------+		+--------+-------+ +-------+------+
	$ +--+ +----+ +-----------+ .		$ +--+ +----+ +-----------+ .
	+~~ |RG| === |NGW | === | SCHC |... Internet ..		+~~ |RG| === |NGW | === | SCHC |... Internet ..
	+--+ +----+ |F/R and C/D|		+--+ +----+ |F/R and C/D|
	+-----------+		+-----------+
	Figure 1: Architecture		Figure 1: Architecture
	Figure 1 represents the architecture for compression/decompression		Figure 1 represents the architecture for compression/decompression
	and fragmentation/reassembly, which is based on [RFC8376]		and fragmentation/reassembly, which is based on [RFC8376]
	terminology.		terminology, where the Radio Gateway is a Sigfox Base Station and the
			Network Gateway is the Sigfox Cloud.
	The Device is sending applications flows that are compressed and/or		The Device is sending applications flows that are compressed and/or
	fragmented by a Static Context Header Compression Compressor/		fragmented by a Static Context Header Compression Compressor/
	Decompressor (SCHC C/D) to reduce headers size and/or fragment the		Decompressor (SCHC C/D) to reduce headers size and/or fragment the
	packet. The resulting information is sent over a layer two (L2)		packet. The resulting information is sent over a layer two (L2)
	frame to a LPWAN Radio Gateway (RG) which forwards the frame to a		frame to a LPWAN Radio Gateway (RG) which forwards the frame to a
	Network Gateway (NGW).		Network Gateway (NGW).
	4. SCHC over Sigfox		4. SCHC over Sigfox
	In the case of the global Sigfox network, RGs (or base stations) are		In the case of the global Sigfox network, RGs (or base stations) are
	distributed over the multiple countries where the Sigfox LPWAN		distributed over the multiple countries where the Sigfox LPWAN
	service is provided. On the other hand, the NGW (or Cloud-based Core		service is provided. On the other hand, the NGW (or Cloud-based Core
	network) is a single entity that connects to all Sigfox base stations		network) is a single entity that connects to all Sigfox base stations
	in the world.		in the world.
	Uplink transmissions occur in repetitions over different times and		Uplink Sigfox transmissions occur in repetitions over different times
	frequencies. Besides these time and frequency diversities, the		and frequencies. Besides these time and frequency diversities, the
	Sigfox network also provides space diversity, as potentially an		Sigfox network also provides space diversity, as potentially an
	uplink message will be received by several base stations. Since all		uplink message will be received by several base stations. Since all
	messages are self-contained and base stations forward them all back		messages are self-contained and base stations forward them all back
	to the same Core network (NGW), multiple input copies can be combined		to the same Core network (NGW), multiple input copies can be combined
	at the NGW and hence provide for extra reliability based on the		at the NGW and hence provide for extra reliability based on the
	triple diversity (i.e. time, space and frequency).		triple diversity (i.e. time, space and frequency). A detailed
			description of the Sigfox Radio Protocol can be found in
			[sigfox-spec].
	The NGW communicates with the Network SCHC C/D for compression/		The NGW communicates with the Network SCHC C/D for compression/
	decompression and/or for fragmentation/reassembly. The Network SCHC		decompression and/or for fragmentation/reassembly. The Network SCHC
	C/D shares the same set of rules as the Dev SCHC C/D. The Network		C/D shares the same set of rules as the Dev SCHC C/D. The Network
	SCHC C/D can be collocated with the NGW or it could be in another		SCHC C/D can be collocated with the NGW or it could be in another
	place, as long as a tunnel is established between the NGW and the		place, as long as a tunnel is established between the NGW and the
	SCHC C/D. After decompression and/or reassembly, the packet can be		SCHC C/D. After decompression and/or reassembly, the packet can be
	forwarded over the Internet to one (or several) LPWAN Application		forwarded over the Internet to one (or several) LPWAN Application
	Server(s) (App).		Server(s) (App).
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 11 ¶
	from the network. This is the case for Sigfox-enabled devices, which		from the network. This is the case for Sigfox-enabled devices, which
	can only listen to downlink communications after performing an uplink		can only listen to downlink communications after performing an uplink
	transmission and requesting a downlink.		transmission and requesting a downlink.
	When there are fragments to be transmitted in the downlink, an uplink		When there are fragments to be transmitted in the downlink, an uplink
	message is required to trigger the downlink communication. In order		message is required to trigger the downlink communication. In order
	to avoid potentially high delay for fragmented datagram transmission		to avoid potentially high delay for fragmented datagram transmission
	in the downlink, the fragment receiver MAY perform an uplink		in the downlink, the fragment receiver MAY perform an uplink
	transmission as soon as possible after reception of a downlink		transmission as soon as possible after reception of a downlink
	fragment that is not the last one. Such uplink transmission MAY be		fragment that is not the last one. Such uplink transmission MAY be
	triggered by sending a SCHC message, such as a SCHC ACK.		triggered by sending a SCHC message, such as a SCHC ACK. However,
			other data messages can equally be used to trigger DL communications.
	For reliable downlink fragment transmission, the ACK-Always mode is		For reliable downlink fragment transmission, the ACK-Always mode is
	RECOMMENDED.		RECOMMENDED.
	The recommended Fragmentation Header size is: 8 bits		The recommended Fragmentation Header size is: 8 bits
	The recommended Rule ID size is: 2 bits.		The recommended Rule ID size is: 2 bits.
	The recommended DTag size (T) is: 2 bits.		The recommended DTag size (T) is: 2 bits.
	skipping to change at page 7, line 45 ¶		skipping to change at page 8, line 5 ¶
	the 3 last bits of the fragmentation header are used to indicate in		the 3 last bits of the fragmentation header are used to indicate in
	bytes the size of the padding. A size of 000 means that the full		bytes the size of the padding. A size of 000 means that the full
	ramaining frame is used to carry payload, a value of 001 indicates		ramaining frame is used to carry payload, a value of 001 indicates
	that the last byte contains padding, and so on.		that the last byte contains padding, and so on.
	6. Padding		6. Padding
	The Sigfox payload fields have different characteristics in uplink		The Sigfox payload fields have different characteristics in uplink
	and downlink.		and downlink.
	Uplink frames can contain a payload from 0 to 96 bits (i.e. 12		Uplink frames can contain a payload size from 0 to 96 bits, that is 0
	bytes). The radio protocol allows sending zero bits or one single		to 12 bytes. The radio protocol allows sending zero bits or one
	bit of information for binary applications (e.g. status). However,		single bit of information for binary applications (e.g. status), or
	for 2 or more bits of payload it is required to add padding to the		an integer number of bytes. Therefore, for 2 or more bits of payload
	next integer number of bytes. The reason for this flexibility is to		it is required to add padding to the next integer number of bytes.
	optimize transmission time and hence save battery consumption at the		The reason for this flexibility is to optimize transmission time and
	device.		hence save battery consumption at the device.
	Downlink frames on the other hand have a fixed length. The payload		Downlink frames on the other hand have a fixed length. The payload
	length must be 64 bits (i.e. 8 bytes). Hence, if less information		length must be 64 bits (i.e. 8 bytes). Hence, if less information
	bits are to be transmitted padding would be necessary and it should		bits are to be transmitted, padding would be necessary and it should
	be performed as described in the previous section.		be performed as described in the previous section.
	7. Security considerations		7. Security considerations
	The radio protocol authenticates and ensures the integrity of each		The radio protocol authenticates and ensures the integrity of each
	message. This is achieved by using a unique device ID and an AES-128		message. This is achieved by using a unique device ID and an AES-128
	based message authentication code, ensuring that the message has been		based message authentication code, ensuring that the message has been
	generated and sent by the device with the ID claimed in the message.		generated and sent by the device with the ID claimed in the message.
	Application data can be encrypted at the application level or not,		Application data can be encrypted at the application level or not,
	depending on the criticality of the use case, to provide a balance		depending on the criticality of the use case. This flexibility
	between cost and effort vs. risk. AES-128 in counter mode is used		allows providing a balance between cost and effort vs. risk. AES-128
	for encryption. Cryptographic keys are independent for each device.		in counter mode is used for encryption. Cryptographic keys are
	These keys are associated with the device ID and separate integrity		independent for each device. These keys are associated with the
	and confidentiality keys are pre-provisioned. A confidentiality key		device ID and separate integrity and confidentiality keys are pre-
	is only provisioned if confidentiality is to be used.		provisioned. A confidentiality key is only provisioned if
			confidentiality is to be used.
	The radio protocol has protections against reply attacks, and the		The radio protocol has protections against reply attacks, and the
	cloud-based core network provides firewalling protection against		cloud-based core network provides firewalling protection against
	undesired incoming communications.		undesired incoming communications.
	8. Acknowledgements		8. Acknowledgements
	Carles Gomez has been funded in part by the ERDF and the Spanish		Carles Gomez has been funded in part by the ERDF and the Spanish
	Government through project TEC2016-79988-P.		Government through project TEC2016-79988-P.
	skipping to change at page 8, line 47 ¶		skipping to change at page 9, line 9 ¶
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "LPWAN Static Context Header Compression (SCHC)		Zuniga, "LPWAN Static Context Header Compression (SCHC)
	and fragmentation for IPv6 and UDP", draft-ietf-lpwan-		and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
	ipv6-static-context-hc-17 (work in progress), October		ipv6-static-context-hc-17 (work in progress), October
	2018.		2018.
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
			[sigfox-spec]
			Sigfox, "Sigfox Radio Specifications",
			<https://build.sigfox.com/
			sigfox-device-radio-specifications>.
	Authors' Addresses		Authors' Addresses
	Juan Carlos Zuniga		Juan Carlos Zuniga
	SIGFOX		SIGFOX
	425 rue Jean Rostand		425 rue Jean Rostand
	Labege 31670		Labege 31670
	France		France
	Email: JuanCarlos.Zuniga@sigfox.com		Email: JuanCarlos.Zuniga@sigfox.com
	URI: http://www.sigfox.com/		URI: http://www.sigfox.com/
	Carles Gomez		Carles Gomez
End of changes. 15 change blocks.
	25 lines changed or deleted		36 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/