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

Versions: 00 01 02

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]


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