[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                              X. He
Internet-Draft                                                     YC.Ma
Intended status: Informational              Hitachi (China) Research and
Expires: January 12, 2013                        Development Corporation
                                                            China Mobile
                                                           July 16, 2012

                    Energy Aware Proxy Discovery for CoAP


   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

   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",
   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"

   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

   The discovery interface is specified as follows:

   Interaction:  EP -> Proxy

   Path:  /.well-known/core

   Method:  POST

   Content-Type:  application/link-format


      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

      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

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

   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

   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


5.  IANA Considerations

   This document does not require any IANA actions.

6.  Normative References

              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.

              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-06 , May 2011.

              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-07,July 2011.

              Bormann, C.,"CoRE Simple Server Discovery"
              draft-bormann-core-simple-server-discovery-00, June, 2011

              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


   Zhen Cao
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053

   Email: zehn.cao@gmail.com

He, et al.                Expires January 12, 2013              [Page 8]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/