draft-ietf-lwig-cellular-04.txt		draft-ietf-lwig-cellular-05.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft A. Eriksson		Internet-Draft A. Eriksson
	Intended status: Informational A. Keranen		Intended status: Informational A. Keranen
	Expires: November 1, 2015 Ericsson		Expires: February 28, 2016 Ericsson
	April 30, 2015		August 27, 2015
	Building Power-Efficient CoAP Devices for Cellular Networks		Building Power-Efficient CoAP Devices for Cellular Networks
	draft-ietf-lwig-cellular-04		draft-ietf-lwig-cellular-05
	Abstract		Abstract
	This memo discusses the use of the Constrained Application Protocol		This memo discusses the use of the Constrained Application Protocol
	(CoAP) protocol in building sensors and other devices that employ		(CoAP) protocol in building sensors and other devices that employ
	cellular networks as a communications medium. Building communicating		cellular networks as a communications medium. Building communicating
	devices that employ these networks is obviously well known, but this		devices that employ these networks is obviously well known, but this
	memo focuses specifically on techniques necessary to minimize power		memo focuses specifically on techniques necessary to minimize power
	consumption.		consumption.
	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 November 1, 2015.		This Internet-Draft will expire on February 28, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 6, line 4		skipping to change at page 6, line 4
	In the following we look at some of these characteristics and their		In the following we look at some of these characteristics and their
	implications. Note that in most cases these characteristics are not		implications. Note that in most cases these characteristics are not
	properties of the specific networks but rather inherent in the		properties of the specific networks but rather inherent in the
	concept of public networks.		concept of public networks.
	Public networks		Public networks
	Using a public network service implies that applications can be		Using a public network service implies that applications can be
	deployed without having to build a network to go with them. For		deployed without having to build a network to go with them. For
	economical reasons, only the largest users (such as utility		economic reasons, only the largest users (such as utility
	companies) could afford to build their own network, and even they		companies) could afford to build their own network, and even they
	would not be able to provide a world-wide coverage. This means		would not be able to provide a world-wide coverage. This means
	that applications where coverage is important can be built. For		that applications where coverage is important can be built. For
	instance, most transport sector applications require national or		instance, most transport sector applications require national or
	even world-wide coverage to work.		even world-wide coverage to work.
	But there are other implications, as well. By definition, the		But there are other implications, as well. By definition, the
	network is not tailored for this application and with some		network is not tailored for this application and with some
	exceptions, the traffic passes through the Internet. One		exceptions, the traffic passes through the Internet. One
	implication of this is that there are generally no application-		implication of this is that there are generally no application-
	skipping to change at page 9, line 16		skipping to change at page 9, line 16
	device should perform the necessary registration with these devices,		device should perform the necessary registration with these devices,
	for instance, as specified in [I-D.ietf-core-resource-directory]. In		for instance, as specified in [I-D.ietf-core-resource-directory]. In
	order to do this registration, the device needs to know its CoRE Link		order to do this registration, the device needs to know its CoRE Link
	Format description, as specified in [RFC6690]. In essence, the		Format description, as specified in [RFC6690]. In essence, the
	registration process involves performing a GET on .well-known/		registration process involves performing a GET on .well-known/
	core/?rt=core-rd at the address of the resource directory, and then		core/?rt=core-rd at the address of the resource directory, and then
	doing a POST on the path of the discovered resource.		doing a POST on the path of the discovered resource.
	Other mechanisms enabling device discovery and delegation of		Other mechanisms enabling device discovery and delegation of
	functionality to a non-sleepy node include		functionality to a non-sleepy node include
	[I-D.vial-core-mirror-proxy] and [I-D.koster-core-coapmq].		[I-D.vial-core-mirror-proxy] and [I-D.koster-core-coap-pubsub].
	However, current CoAP specifications provide only limited support for		However, current CoAP specifications provide only limited support for
	discovering the resource directory or other registration services.		discovering the resource directory or other registration services.
	Local multicast discovery only works in LAN-type networks, but not in		Local multicast discovery only works in LAN-type networks, but not in
	these public cellular networks. Our recommended alternate methods		these public cellular networks. Our recommended alternate methods
	for discovery are the following:		for discovery are the following:
	Manual Configuration		Manual Configuration
	The DNS name of the resource directory is manually configured.		The DNS name of the resource directory is manually configured.
	skipping to change at page 10, line 20		skipping to change at page 10, line 20
	The delegating manufacturer server model could be generalized into		The delegating manufacturer server model could be generalized into
	a reverse-DNS -like discovery infrastructure that could answer the		a reverse-DNS -like discovery infrastructure that could answer the
	question "this is device with identity ID, where is my home		question "this is device with identity ID, where is my home
	registration server?". However, at present no such resolution		registration server?". However, at present no such resolution
	system exists. (Note: The EPCGlobal system for RFID resolution is		system exists. (Note: The EPCGlobal system for RFID resolution is
	reminiscent of this approach.)		reminiscent of this approach.)
	6. Data Formats		6. Data Formats
	A variety of data formats exist for passing around data. These data		A variety of data formats exist for passing around data. These data
	formats include XML, JavaScript Object Notation (JSON) [RFC4627],		formats include XML, JavaScript Object Notation (JSON) [RFC7159],
	Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text		Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text
	formats. Message lengths can have a significant effect on the amount		formats. Message lengths can have a significant effect on the amount
	of energy required for the communications, and such it is highly		of energy required for the communications, and such it is highly
	desirable to keep message lengths minimal. At the same time, extreme		desirable to keep message lengths minimal. At the same time, extreme
	optimization can affect flexibility and ease of programming. The		optimization can affect flexibility and ease of programming. The
	authors recommend [I-D.jennings-senml] as a compact, yet easily		authors recommend [I-D.jennings-senml] as a compact, yet easily
	processed and extendable textual format.		processed and extendable textual format.
	7. Real-Time Reachable Devices		7. Real-Time Reachable Devices
	skipping to change at page 11, line 39		skipping to change at page 11, line 39
	Note that the the VPN approach can not prevent unwanted traffic		Note that the the VPN approach can not prevent unwanted traffic
	received at the tunnel endpoint address, and may require keep-alive		received at the tunnel endpoint address, and may require keep-alive
	traffic. Special APNs can solve this issue, but require explicit		traffic. Special APNs can solve this issue, but require explicit
	arrangement with the service provider.		arrangement with the service provider.
	8. Sleepy Devices		8. Sleepy Devices
	These devices are best modeled as devices that can delegate queries		These devices are best modeled as devices that can delegate queries
	to some other node. For instance, as mirror proxy		to some other node. For instance, as mirror proxy
	[I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe		[I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe
	[I-D.koster-core-coapmq] clients. When the device initializes		[I-D.koster-core-coap-pubsub] clients. When the device initializes
	itself, it makes a registration of itself in a proxy as described		itself, it makes a registration of itself in a proxy as described
	above in Section 5 and then continues to send periodic updates of		above in Section 5 and then continues to send periodic updates of
	sensor values.		sensor values.
	As a result, the device acts only as a client, not a server, and can		As a result, the device acts only as a client, not a server, and can
	shut down all communication channels while it is during its sleeping		shut down all communication channels while it is during its sleeping
	period. The length of the sleeping period depends on power and		period. The length of the sleeping period depends on power and
	application requirements. Some environmental sensors might use a day		application requirements. Some environmental sensors might use a day
	or a week as the period, while other devices may use a smaller values		or a week as the period, while other devices may use a smaller values
	ranging from minutes to hours.		ranging from minutes to hours.
	skipping to change at page 13, line 48		skipping to change at page 13, line 48
	mechanisms described in [RFC7252] or data objects.		mechanisms described in [RFC7252] or data objects.
	10. IANA Considerations		10. IANA Considerations
	There are no IANA impacts in this memo.		There are no IANA impacts in this memo.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC4627] Crockford, D., "The application/json Media Type for		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	JavaScript Object Notation (JSON)", RFC 4627, July 2006.		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
			2014, <http://www.rfc-editor.org/info/rfc7159>.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	Format", RFC 6690, August 2012.		Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
			<http://www.rfc-editor.org/info/rfc6690>.
	[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, June 2014.		Application Protocol (CoAP)", RFC 7252,
			DOI 10.17487/RFC7252, June 2014,
			<http://www.rfc-editor.org/info/rfc7252>.
	[I-D.ietf-core-observe]		[I-D.ietf-core-observe]
	Hartke, K., "Observing Resources in CoAP", draft-ietf-		Hartke, K., "Observing Resources in CoAP", draft-ietf-
	core-observe-16 (work in progress), December 2014.		core-observe-16 (work in progress), December 2014.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Shelby, Z. and C. Bormann, "CoRE Resource Directory",		Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
	draft-ietf-core-resource-directory-02 (work in progress),		Resource Directory", draft-ietf-core-resource-directory-04
	November 2014.		(work in progress), July 2015.
	[W3C.REC-exi-20110310]		[W3C.REC-exi-20110310]
	Kamiya, T. and J. Schneider, "Efficient XML Interchange		Kamiya, T. and J. Schneider, "Efficient XML Interchange
	(EXI) Format 1.0", World Wide Web Consortium		(EXI) Format 1.0", World Wide Web Consortium
	Recommendation REC-exi-20110310		Recommendation REC-
	http://www.w3.org/TR/2011/REC-exi-20110310, March 2011.		exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310,
			March 2011.
	[I-D.jennings-senml]		[I-D.jennings-senml]
	Jennings, C., Shelby, Z., and J. Arkko, "Media Types for		Jennings, C., Shelby, Z., and J. Arkko, "Media Types for
	Sensor Markup Language (SENML)", draft-jennings-senml-10		Sensor Markup Language (SENML)", draft-jennings-senml-10
	(work in progress), October 2012.		(work in progress), October 2012.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228, May 2014.		Constrained-Node Networks", RFC 7228,
			DOI 10.17487/RFC7228, May 2014,
			<http://www.rfc-editor.org/info/rfc7228>.
	11.2. Informative References		11.2. Informative References
	[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in		[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
	Customer Premises Equipment (CPE) for Providing		Capabilities in Customer Premises Equipment (CPE) for
	Residential IPv6 Internet Service", RFC 6092, January		Providing Residential IPv6 Internet Service", RFC 6092,
	2011.		DOI 10.17487/RFC6092, January 2011,
			<http://www.rfc-editor.org/info/rfc6092>.
	[I-D.arkko-core-sleepy-sensors]		[I-D.arkko-core-sleepy-sensors]
	Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.		Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
	Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-		Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-
	sleepy-sensors-01 (work in progress), July 2011.		sleepy-sensors-01 (work in progress), July 2011.
	[I-D.aks-crypto-sensors]		[I-D.aks-crypto-sensors]
	Sethi, M., Arkko, J., Keranen, A., and H. Rissanen,		Sethi, M., Arkko, J., Keranen, A., and H. Rissanen,
	"Practical Considerations and Implementation Experiences		"Practical Considerations and Implementation Experiences
	in Securing Smart Object Networks", draft-aks-crypto-		in Securing Smart Object Networks", draft-aks-crypto-
	skipping to change at page 15, line 14		skipping to change at page 15, line 24
	[I-D.fossati-core-publish-monitor-options]		[I-D.fossati-core-publish-monitor-options]
	Fossati, T., Giacomin, P., and S. Loreto, "Publish and		Fossati, T., Giacomin, P., and S. Loreto, "Publish and
	Monitor Options for CoAP", draft-fossati-core-publish-		Monitor Options for CoAP", draft-fossati-core-publish-
	monitor-options-01 (work in progress), March 2012.		monitor-options-01 (work in progress), March 2012.
	[I-D.vial-core-mirror-proxy]		[I-D.vial-core-mirror-proxy]
	Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-		Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
	proxy-01 (work in progress), July 2012.		proxy-01 (work in progress), July 2012.
	[I-D.koster-core-coapmq]		[I-D.koster-core-coap-pubsub]
	Koster, M., Keranen, A., and J. Jimenez, "Message Queueing		Koster, M., Keranen, A., and J. Jimenez, "Publish-
	in the Constrained Application Protocol (CoAP)", draft-		Subscribe Broker for the Constrained Application Protocol
	koster-core-coapmq-00 (work in progress), July 2014.		(CoAP)", draft-koster-core-coap-pubsub-02 (work in
			progress), July 2015.
	[Android-Bundle]		[Android-Bundle]
	"Optimizing Downloads for Efficient Network Access",		"Optimizing Downloads for Efficient Network Access",
	Android developer note		Android developer note
	http://developer.android.com/training/efficient-downloads/		http://developer.android.com/training/efficient-downloads/
	efficient-network-access.html, February 2013.		efficient-network-access.html, February 2013.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The authors would like to thank Zach Shelby, Jan Holler, Salvatore		The authors would like to thank Zach Shelby, Jan Holler, Salvatore
End of changes. 15 change blocks.
	26 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/