Internet DRAFT - draft-cao-core-pd
draft-cao-core-pd
Internet Engineering Task Force Z. Cao
Internet-Draft China Mobile
Intended status: Informational Y. Ma
Expires: January 17, 2013 Hitachi R&D China
H. Deng
China Mobile
R. Zhang
China Telecom
July 16, 2012
HTTP-COAP Proxy Discovery using Link-format
draft-cao-core-pd-02
Abstract
This document discusses the problem of HTTP-COAP proxy discovery and
proposes a method of using Link-format to do the job.
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 17, 2013.
Copyright Notice
Copyright (c) 2012 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
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
Cao, et al. Expires January 17, 2013 [Page 1]
Internet-Draft CoAP Proxy Discovery July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Formation . . . . . . . . . . . . . . . . . . . . . . . 3
4. Link-format Proxy Discovery . . . . . . . . . . . . . . . . . . 4
5. Design Consideration . . . . . . . . . . . . . . . . . . . . . 5
6. Existing Discovery Mechanisms . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Cao, et al. Expires January 17, 2013 [Page 2]
Internet-Draft CoAP Proxy Discovery July 2012
1. Introduction
CoAP [I-D.ietf-core-coap] is a RESTful protocol designed for
constrained devices. The ultimate goal of CoAP is to enable the "Web
of Things" concept, which connects the smart sensor network with the
global internet. Although CoAP has been implemented on various
platforms, the rest of web is still dominated by HTTP. As a result,
it is desirable to interconnect the HTTP and CoAP via some
intermediary proxy. For example, the CoAP sensor client in the
constrained network can access and update resources on the HTTP
server, and also the HTTP client on the web can access and/or update
resources on the CoAP server.
There are already some works discussing how to map HTTP to CoAP and
vice versa. The basic mapping between HTTP and CoAP is described in
Section 8 of [I-D.ietf-core-coap] . Further details of implementing
the proxy, internal procedures and design choices are described
in[I-D.castellani-core-http-mapping] .
Static configuration of HTTP-CoAP proxies is a straightforward way
for the client to access the server. However, in many situations,
static configuration is not enough to meet the requirements. For
example, if the HTTP client would like to access a certain type of
resource (temperature or humidity in a certain location, etc.), it is
required that the client would find an appropriate proxy to serve the
content.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Scenario
One example scenario of proxy discovery comes from the requirements
that integrates the smart network with the mobile network. The
sensors want to find a mobile proxy that can proxy the information to
the web. The sensors are static, running CoAP as a client, and wants
to report information to the SNS website. The "mobile M2M devices"
are nomadic and can serve as the CoAP-HTTP proxy. The sensor wants
to discover who is nearby and can shepherd message to the Web.
3. Problem Formation
We divide the problem into two separated parts. The first is how a
Cao, et al. Expires January 17, 2013 [Page 3]
Internet-Draft CoAP Proxy Discovery July 2012
CoAP client discovers a proxy to access the HTTP server. For
example, the CoAP sensors want to report or get some information to a
Web server. In this case, the CoAP sensor only acts as a client. In
static configuration, the CoAP client is configured via DHCP or RSRA.
But in dynamic environment, a mechanism for dynamic configuration is
desired. This document mainly discusses this aspect.
The other case is how a HTTP client discovers a proxy to access the
CoAP server. For example, the HTTP client wants to access a certain
type of information in the constrained network, and would discover
the proxy to the exact constrained sensor. In this case, the HTTP
Client only accesss the sensor indirectly. In this case, the HTTP
Client only needs to know the address or the domain name of the proxy
node, and the proxy forwards the requests to the sensor node
according to the sub-domain information or the path included in the
URI within the request. But in this case, we believe that the DNS-SD
infrastures are sufficient to handle this problem. For example,
[I-D.vanderstok-core-bc] has described detailed considerations of a
DNS-SD based proxy discovery method for Building Control use cases.
So, in this document we will not talk about this direction.
4. Link-format Proxy Discovery
Before the CoAP sensor makes use of the CoAP-HTTP proxy, it must know
the location of the proxy. There can be multiple ways to discover
the proxy'ss location, including both static and dynamic methods.
DHCP is one way to do that, and documented in another document. This
document describes one way to discover the proxy by the CoRE link
format [I-D.ietf-core-link-format].
Note: Think of the way the user is configured with the http proxy in
the enterprise network.
Discovery is performed by sending a multicast GET request to /.well-
known/core and including a Resource Type (rt) parameter
[I-D.ietf-core-link-format] with the value "core-pd" in the query
string. Upon success, the response will contain a payload with a
link format entry for each proxy discovered. The multicast IP
address used will depend on the scope required and the multicast
capabilities of the network. (If determined, IANA actions are
required to assign a multicast address for this purpose)
The following example shows an end-point discover a locally available
CoAP-HTTP proxy. The CoAP end-point sends a multicast GET request to
the multicast address in the domain carrying a resource type
"core-pd" indicating its discovery of a local proxy. Then the
serving proxy responds the request with the rt="core-pd" and the
Cao, et al. Expires January 17, 2013 [Page 4]
Internet-Draft CoAP Proxy Discovery July 2012
address of the proxy is carried within the Content payload.
Afterwards, the CoAP sensor initiates the data-plane communication
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
| | |
| -- GET /.well-known/core?rt=core-pd -->| |
| | |
| | |
|<----------- 2.05 Content ; rt="core-pd" ----------------- |
| |
|---------------------- GET /temp/ --------------------->|
Req: GET coap://[ff02::1]/.well-known/core?rt=core-pd
Res: 2.05 Content
fe80::ff; rt="core-pd";
5. Design Consideration
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 energy consumption would be high and unneccessary. To avoid 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
multicast addresses, there would be IANA actions on it. Second, the
resource type (rt) definition of the proxy discovery should be
defined by IANA.
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]
Cao, et al. Expires January 17, 2013 [Page 5]
Internet-Draft CoAP Proxy Discovery July 2012
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
Zach Shelby on the problem. And authors also thank comments from
Jari Arkko and Ralph Droms on IETF 82th meeting.
8. IANA Considerations
If the ideas in this document is determined by the working group,
IANA actions are required to assign a multicast address for the
purpose of HTTP-CoAP proxy discovery, as well as the link format for
the proxy discovery.
9. Security Considerations
None.
10. References
10.1. Normative References
[I-D.castellani-core-http-mapping]
Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Best Practices for HTTP-CoAP Mapping
Implementation", draft-castellani-core-http-mapping-05
(work in progress), July 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-10 (work in progress), June 2012.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-14 (work in progress),
June 2012.
[I-D.vanderstok-core-bc]
Cao, et al. Expires January 17, 2013 [Page 6]
Internet-Draft CoAP Proxy Discovery July 2012
Stok, P. and K. Lynn, "CoAP Utilization for Building
Control", draft-vanderstok-core-bc-05 (work in progress),
October 2011.
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
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
Zhen Cao
China Mobile
Xuanwumenxi Ave. No.32
China, 100053
China
Phone:
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Cao, et al. Expires January 17, 2013 [Page 7]
Internet-Draft CoAP Proxy Discovery July 2012
Yuanchen Ma
Hitachi R&D China
Phone:
Fax:
Email: ycma@hitachi.cn
URI:
Hui Deng
China Mobile
Phone:
Fax:
Email: denghui@chinamobile.com
URI:
Rong Zhang
China Telecom
No.109 Zhongshandadao avenue
Guangzhou, Tianhe 510630
China
Phone:
Fax:
Email: zhangr@gsta.com
URI:
Cao, et al. Expires January 17, 2013 [Page 8]
