Internet DRAFT - draft-he-core-energy-aware-pd
draft-he-core-energy-aware-pd
Network Working Group X. He
Internet-Draft YC.Ma
Intended status: Informational Hitachi (China) Research and
Expires: January 12, 2013 Development Corporation
Z.Cao
China Mobile
July 16, 2012
Energy Aware Proxy Discovery for CoAP
draft-he-core-energy-aware-pd-01.txt
Abstract
CoRE defines a mechanism for resource discovery based on Web linking
with discovery, registration,modification, and other procedures. But
energy efficiency is very important for resource constrained devices.
This specification shows an efficient method for CoAP proxy finding
the resource from end-points by reducing multicast messages.
The current version -01 of this document is just an initial draft
that is modified according to related comments.
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 12, 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
He, et al. Expires January 12, 2013 [Page 1]
Internet-Draft Proxy Discovery for CoAP Jul 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Resource discovery analysis. . . . . . . . . . . . . . . . . . 4
3. Energy aware proxy discovery . . . . . . . . . . . . . . . . . 5
3.1. Reduced Protocol Operations . . . . . . . . . . . . . . . 5
3.2. Example . . . . . . . . . . . . . . . . . . 6
4. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . .7
He, et al. Expires January 12, 2013 [Page 2]
Internet-Draft Proxy Discovery for CoAP Jul 2012
1. Introduction
The Constrained RESTful Environments (CoRE) working group aims at
realizing the REST architecture in a suitable form for the most
constrained nodes and networks. CoRE is aimed at machine-to-machine
(M2M) applications such as smart energy and building automation
[I-D.shelby-core-coap-req]. As being the main work of CORE,CoAP
defined a proxy mechanism for CoAP end-point, that proxy can be
tasked by CoAP clients to perform requests on their behalf
[I-D.ietf-core-coap].
Since in many M2M scenarios, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which hosts
descriptions of resources held on other servers, allowing lookups to
be performed for those resources[I-D.shelby-core-resource-directory].
The proxy mechanism should support this RD function in resource
constrained environments. There are several methods to discovery
proxy by a CoAP end-point, including assuming a default location
(e.g. on an Edge Router in a LoWPAN), by assigning an anycast address
to the proxy, using DHCP, or using the CoRE Link Format. While
reducing energy consumption is essential for battery operated nodes
in some devices, which is one of the most important work in M2M
communication. Node's energy usage depends on network messages it has
to receive and or respond. Thus the discovery procedure should be
optimized with energy aware consideration.
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].
He, et al. Expires January 12, 2013 [Page 3]
Internet-Draft Proxy Discovery for CoAP Jul 20121
2. Resource discovery analysis
As mentioned in other drafts, resource discovery is performed by
sending either a multicast or unicast GET request to
/.well-known/core and including a Resource Type (rt) parameter
[I-D.ietf-core-link-format] with the value "core-rd" in the query
string. Upon success, the response will contain a payload with a
link format entry for each RD discovered, with the URL indicating
the root resource of the RD.
After discovering the location of an RD, an end-point MAY register
its resources to the RD's registration interface. This interface
accepts a POST from an end-point containing the list of resources to
be added to the directory as the message payload in the CoRE Link
Format along with query string parameters indicating the name of the
end-point, an optional node identifier and the lifetime of the
registration. Upon success, the response will be 2.01 "Created"
[I-D.shelby-core-resource-directory].
That means once resource discovery needs twice communication process
between end-point and proxy. For energy saving point of view, this
procedure should be optimized. Another draft indicates more efficient
method.A CoAP server that wants to make itself discoverable sends a
POST request to the default discovery URI of any Candidate CoAP
Server Discovery Server [I-D.bormann-core-simple-server-discovery].
This draft shows more details about energy aware proxy discovery
mechanism for CoAP.
He, et al. Expires January 12, 2013 [Page 4]
Internet-Draft Proxy Discovery for CoAP Jul 2012
3. Energy aware proxy discovery
3.1. Reduced Protocol Operations
The Energy aware proxy reduces discovery and registration processes
into one.
The end-point acting as a server will use server IP address, the CoAP
default port[I-D.ietf-core-coap], and the absolute path
"/.well-known/core"[I-D.ietf-core-link-format] to build its POST
request. And this request will be send to its Neighbor by unicast
(as using 6LOWPAN or IPv6) or to a multicast address.
The POST request is a link-format message, which indicates the
service list that requesting server wants to make known to the proxy.
End-point resources in the proxy are kept active for the period
also indicated by the lifetime parameter. But unless the end-point
needs to refreshing the data with update message, the data will be
kept in this lifetime. Then the data will be delete automatically as
expired.
The discovery interface is specified as follows:
Interaction: EP -> Proxy
Path: /.well-known/core
Method: POST
Content-Type: application/link-format
Parameters:
Lifetime (lt): Lifetime of the registration in seconds. Range of
60-4294967295. If no lifetime is included, the value will be a
default lifetime, (e.g.3600seconds)
Host (h): The host identifier or name of the registering node.
The maximum length of this parameter is 63 octets. This
parameter is combined with the Instance parameter (if any) to
form the end-point name. If not included, the proxy MUST
generate a unique Host name on behalf of the node.
Instance (ins): The instance of the end-point on this host, if
there are multiple. The maximum length of this parameter is 63
octets.
Type (rt): The semantic type of end-point. The maximum length of
this parameter is 63 octets.
He, et al. Expires January 12, 2013 [Page 5]
Internet-Draft Proxy Discovery for CoAP Jul 2012
Success: 2.01 "Created". The Location header of the new resource
entry for the end-point could be e.g. in the form /{rd-base}/
{end-point name}
Failure: 4.00 "Bad Request". Malformed request.
Failure: 5.03 "Service Unavailable". Service could not perform the
operation.
3.2 Example
The following example shows an end-point with the name "node1" POST
temperature resource to a proxy using this interface.
End-point Neighbor
| (as a proxy)
| --- POST /.well-known/core?rt=core-rd-------> |
| |
| |
| <-- 2.01 Created Location: /rd/node1 --------- |
| |
Req: POST coap://[ff02::1]/.well-known/core?rt=core-rd
Payload:
</sensors/temp>;ct=41;rt="TemperatureC";if="sensor",
Res: 2.01 Created
Location: /rd/node1
The second example shows an end-point with the name "node2" POST
video resource to a proxy using this interface, but proxy cannot
support this application data.
End-point Neighbor
| (as a proxy)
| --- POST /.well-known/core?rt=core-rd-------> |
| |
| |
| <-- 4.00 Bad Request---------------- --------- |
| |
Req: POST coap://[ff02::1]/.well-known/core?rt=core-rd
Payload:
</sensors/temp>;ct=41;rt="video";if="sensor",
Res: 4.00 Bad Request
He, et al. Expires January 12, 2013 [Page 6]
Internet-Draft Proxy Discovery for CoAP Jul 2012
4. Security Considerations
TBD.
5. IANA Considerations
This document does not require any IANA actions.
6. Normative References
[I-D.shelby-core-coap-req]
Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
Kelsey, "CoAP Requirements and Features",
draft-shelby-core-coap-req-01 (work in progress),
April 2010.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-06 , May 2011.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-07,July 2011.
[I-D.bormann-core-simple-server-discovery]
Bormann, C.,"CoRE Simple Server Discovery"
draft-bormann-core-simple-server-discovery-00, June, 2011
[I-D.shelby-core-resource-directory]
Shelby, Z.,Krco, S., "CoRE Resource Directory"
draft-shelby-core-resource-directory-01, September, 2011
He, et al. Expires January 12, 2013 [Page 7]
Internet-Draft Proxy Discovery for CoAP Jul 2012
Authors' Addresses
Xuan He
Yuanchen Ma
Hitachi R&D China
301 of North Tower C, Raycom
@ Kexuyuan Nanlu, Haidian District
Beijing 100190
China
Email:
xhe@hitachi.cn
ycma@hitachi.cn
Zhen Cao
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: zehn.cao@gmail.com
He, et al. Expires January 12, 2013 [Page 8]
