< draft-cao-core-pd-01.txt		draft-cao-core-pd-02.txt >
	Internet Engineering Task Force Z. Cao, Ed.		Internet Engineering Task Force Z. Cao
	Internet-Draft China Mobile		Internet-Draft China Mobile
	Intended status: Informational Y. Ma		Intended status: Informational Y. Ma
	Expires: September 13, 2012 Hitachi R&D China		Expires: January 17, 2013 Hitachi R&D China
	H. Deng		H. Deng
	China Mobile		China Mobile
	March 12, 2012		R. Zhang
			China Telecom
			July 16, 2012
	HTTP-COAP Proxy Discovery using Link-format		HTTP-COAP Proxy Discovery using Link-format
	draft-cao-core-pd-01		draft-cao-core-pd-02
	Abstract		Abstract
	This document discusses the problem of HTTP-COAP proxy discovery and		This document discusses the problem of HTTP-COAP proxy discovery and
	proposes a method of using Link-format to do the job.		proposes a method of using Link-format to do the job.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 34 ¶		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 September 13, 2012.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 2, line 13 ¶		skipping to change at page 2, line 15 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
	2. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Problem Formation . . . . . . . . . . . . . . . . . . . . . . . 3		3. Problem Formation . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Link-format Proxy Discovery . . . . . . . . . . . . . . . . . . 4		4. Link-format Proxy Discovery . . . . . . . . . . . . . . . . . . 4
	5. Design Consideration . . . . . . . . . . . . . . . . . . . . . 5		5. Design Consideration . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		6. Existing Discovery Mechanisms . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 6		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9.2. Informative References . . . . . . . . . . . . . . . . . . 6		10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		10.2. Informative References . . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	CoAP [I-D.ietf-core-coap] is a RESTful protocol designed for		CoAP [I-D.ietf-core-coap] is a RESTful protocol designed for
	constrained devices. The ultimate goal of CoAP is to enable the "Web		constrained devices. The ultimate goal of CoAP is to enable the "Web
	of Things" concept, which connects the smart sensor network with the		of Things" concept, which connects the smart sensor network with the
	global internet. Although CoAP has been implemented on various		global internet. Although CoAP has been implemented on various
	platforms, the rest of web is still dominated by HTTP. As a result,		platforms, the rest of web is still dominated by HTTP. As a result,
	it is desirable to interconnect the HTTP and CoAP via some		it is desirable to interconnect the HTTP and CoAP via some
	intermediary proxy. For example, the CoAP sensor client in the		intermediary proxy. For example, the CoAP sensor client in the
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	The following example shows an end-point discover a locally available		The following example shows an end-point discover a locally available
	CoAP-HTTP proxy. The CoAP end-point sends a multicast GET request to		CoAP-HTTP proxy. The CoAP end-point sends a multicast GET request to
	the multicast address in the domain carrying a resource type		the multicast address in the domain carrying a resource type
	"core-pd" indicating its discovery of a local proxy. Then the		"core-pd" indicating its discovery of a local proxy. Then the
	serving proxy responds the request with the rt="core-pd" and the		serving proxy responds the request with the rt="core-pd" and the
	address of the proxy is carried within the Content payload.		address of the proxy is carried within the Content payload.
	Afterwards, the CoAP sensor initiates the data-plane communication		Afterwards, the CoAP sensor initiates the data-plane communication
	with the proxy directly.		with the proxy directly.
			To avoid the heavy load of multicast traffic on the link, there may
			be need of designate a ALL-COAP-MULTICAST address for proxy
			discovery.
	End-point Multicast address Proxy		End-point Multicast address Proxy
	| | |		| | |
	| -- GET /.well-known/core?rt=core-pd -->| |		| -- GET /.well-known/core?rt=core-pd -->| |
	| | |		| | |
	| | |		| | |
	|<----------- 2.05 Content ; rt="core-pd" ----------------- |		|<----------- 2.05 Content ; rt="core-pd" ----------------- |
	| |		| |
	|---------------------- GET /temp/ --------------------->|		|---------------------- GET /temp/ --------------------->|
	Req: GET coap://[ff02::1]/.well-known/core?rt=core-pd		Req: GET coap://[ff02::1]/.well-known/core?rt=core-pd
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 37 ¶
	There are some considerations with the above scheme. First, if all		There are some considerations with the above scheme. First, if all
	the nodes on the link is obliged to listen to the multicast message,		the nodes on the link is obliged to listen to the multicast message,
	the energy consumption would be high and unneccessary. To avoid all		the energy consumption would be high and unneccessary. To avoid all
	the nodes on the link receiving the GET message, we can use a "ALL-		the nodes on the link receiving the GET message, we can use a "ALL-
	COAP" multicast address for such kind of request. Regarding the		COAP" multicast address for such kind of request. Regarding the
	multicast addresses, there would be IANA actions on it. Second, the		multicast addresses, there would be IANA actions on it. Second, the
	resource type (rt) definition of the proxy discovery should be		resource type (rt) definition of the proxy discovery should be
	defined by IANA.		defined by IANA.
	6. Acknowledgements		6. Existing Discovery Mechanisms
			There are many service discovery protocols, including:
			1. DNS Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd], part
			of Apple's Bonjour technology.
			2. Service Location Protocol (SLP) [RFC2608]
			3. Simple Service Discovery Protocol (SSDP) as used in Universal
			Plug and Play (UPnP)[upnp]
			4. multicast DHCP (MDHCP) [mDHCP]
			5. Web Proxy Autodiscovery Protocol (WPAD)[wpad]
			6. Dynamic Host Configuration Protocol (DHCP) [RFC2131]
			7. Acknowledgements
	Some ideas in this document are according to the discussion between		Some ideas in this document are according to the discussion between
	Zach Shelby on the problem. And authors also thank comments from		Zach Shelby on the problem. And authors also thank comments from
	Jari Arkko and Ralph Droms on IETF 82th meeting.		Jari Arkko and Ralph Droms on IETF 82th meeting.
	7. IANA Considerations		8. IANA Considerations
	If the ideas in this document is determined by the working group,		If the ideas in this document is determined by the working group,
	IANA actions are required to assign a multicast address for the		IANA actions are required to assign a multicast address for the
	purpose of HTTP-CoAP proxy discovery, as well as the link format for		purpose of HTTP-CoAP proxy discovery, as well as the link format for
	the proxy discovery.		the proxy discovery.
	8. Security Considerations		9. Security Considerations
	None.		None.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[I-D.castellani-core-http-mapping]		[I-D.castellani-core-http-mapping]
	Castellani, A., Loreto, S., Rahman, A., Fossati, T., and		Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
	E. Dijk, "Best practices for HTTP-CoAP mapping		E. Dijk, "Best Practices for HTTP-CoAP Mapping
	implementation", draft-castellani-core-http-mapping-02		Implementation", draft-castellani-core-http-mapping-05
	(work in progress), October 2011.		(work in progress), July 2012.
	[I-D.ietf-core-coap]		[I-D.ietf-core-coap]
	Frank, B., Bormann, C., Hartke, K., and Z. Shelby,		Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
	"Constrained Application Protocol (CoAP)",		"Constrained Application Protocol (CoAP)",
	draft-ietf-core-coap-08 (work in progress), October 2011.		draft-ietf-core-coap-10 (work in progress), June 2012.
	[I-D.ietf-core-link-format]		[I-D.ietf-core-link-format]
	Shelby, Z., "CoRE Link Format",		Shelby, Z., "CoRE Link Format",
	draft-ietf-core-link-format-11 (work in progress),		draft-ietf-core-link-format-14 (work in progress),
	January 2012.		June 2012.
	[I-D.vanderstok-core-bc]		[I-D.vanderstok-core-bc]
	Stok, P. and K. Lynn, "CoAP Utilization for Building		Stok, P. and K. Lynn, "CoAP Utilization for Building
	Control", draft-vanderstok-core-bc-05 (work in progress),		Control", draft-vanderstok-core-bc-05 (work in progress),
	October 2011.		October 2011.
	9.2. Informative References		10.2. Informative References
			[I-D.cheshire-dnsext-dns-sd]
			Cheshire, S. and M. Krochmal, "DNS-Based Service
			Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
			progress), December 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
			RFC 2131, March 1997.
			[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
			"Service Location Protocol, Version 2", RFC 2608,
			June 1999.
			[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
			Protocol (XMPP): Core", RFC 3920, October 2004.
			[mDHCP] "Multicast DHCP",
			<http://technet.microsoft.com/en-us/library/
			cc958927.aspx>.
			[upnp] "Universal Plug and Play", <http://www.upnp.org/>.
			[wpad] "Web Proxy Autodiscovery Protocol (WPAD)",
			<http://tools.ietf.org/html/draft-ietf-wrec-wpad>.
	Authors' Addresses		Authors' Addresses
	Zhen Cao (editor)		Zhen Cao
	China Mobile		China Mobile
	Xuanwumenxi Ave. No.32		Xuanwumenxi Ave. No.32
	China, 100053		China, 100053
	China		China
	Phone:		Phone:
	Email: zehn.cao@gmail.com, caozhen@chinamobile.com		Email: zehn.cao@gmail.com, caozhen@chinamobile.com
	Yuanchen Ma		Yuanchen Ma
	Hitachi R&D China		Hitachi R&D China
	skipping to change at line 260 ¶		skipping to change at page 8, line 19 ¶
	Email: ycma@hitachi.cn		Email: ycma@hitachi.cn
	URI:		URI:
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	Phone:		Phone:
	Fax:		Fax:
	Email: denghui@chinamobile.com		Email: denghui@chinamobile.com
	URI:		URI:
			Rong Zhang
			China Telecom
			No.109 Zhongshandadao avenue
			Guangzhou, Tianhe 510630
			China
			Phone:
			Fax:
			Email: zhangr@gsta.com
			URI:
End of changes. 20 change blocks.
	26 lines changed or deleted		75 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/