One document matched: draft-castellani-core-http-coap-mapping-00.txt
CORE Working Group A. Castellani
Internet-Draft University of Padova
Intended status: Informational S. Loreto
Expires: July 29, 2011 Ericsson
January 25, 2011
Best Practice to map HTTP to COAP and viceversa
draft-castellani-core-http-coap-mapping-00.txt
Abstract
This draft aims at being a simple guide to the use of CoAP REST
interface, to show how it can be mapped to and from HTTP, and at
being a base reference documentation for CoAP/HTTP proxy
implementors.
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 July 29, 2011.
Copyright Notice
Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Castellani & Loreto Expires July 29, 2011 [Page 1]
Internet-Draft Map HTTP to COAP January 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CoAP/HTTP best practice . . . . . . . . . . . . . . . . . . . 4
2.1. Methods and Status . . . . . . . . . . . . . . . . . . . . 4
2.2. Headers and Content . . . . . . . . . . . . . . . . . . . 5
3. CoAP observe to HTTP options . . . . . . . . . . . . . . . . . 5
3.1. HTTP subscription to a CoAP resource . . . . . . . . . . . 6
3.1.1. Subscription parameters mapping . . . . . . . . . . . 6
3.1.2. Soft state requirements . . . . . . . . . . . . . . . 8
3.1.3. HTTP long-polling to CoAP observe . . . . . . . . . . 8
3.1.4. HTTP streaming to CoAP observe . . . . . . . . . . . . 10
3.2. CoAP observing an HTTP resource . . . . . . . . . . . . . 11
3.3. Open questions . . . . . . . . . . . . . . . . . . . . . . 13
4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Resource Discovery . . . . . . . . . . . . . . . . . . . . . . 14
5.1. CoRE resource discovery by an HTTP Client . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Alternatives for CoAP subscription/notification(s) . 17
A.1. Server-to-server notifications . . . . . . . . . . . . . . 17
A.2. Observe using native Transfer-Encoding chunked . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Castellani & Loreto Expires July 29, 2011 [Page 2]
Internet-Draft Map HTTP to COAP January 2011
1. Introduction
Since implementing on constrained devices the full HyperText Transfer
Protocol (HTTP) [RFC2616] is believed to be operationally and
computationally too complex, especially in an M2M communication
environment, resources available on constrained nodes are expected to
be served using CoAP [I-D.ietf-core-coap].
These days on the web, we observe that information is increasingly
converging to HTTP, thus a paramount feature of CoAP will be HTTP
interoperability.
A convenient choice to operate this mapping is by simply using an
HTTP/CoAP proxy. The HTTP clients can transparently get access to
this network through the proxy.
The proxy itself does not require any particular knowledge about the
constrained network topology, devices contained, nor about the
content of data exchanged.
The mapping operated by the proxy spans across several protocol
layers:
o HTTP is mapped to CoAP
o TCP is used on the HTTP side, while CoAP uses UDP transport
o IPv4/IPv6 are converted to 6LoWPAN
in this document we will focus on the HTTP to CoAP mapping, assuming
the aforementioned lower layer protocol conversions.
The HTTP/CoAP proxy is expected to be deployed at the edge of the
constrained network. The arguments supporting this assumption are
the following:
o Translation between HTTP and CoAP requires also a TCP to UDP
mapping; UDP performance over the Internet may not be adequate,
UDP should be dropped as soon as possible to minimize the number
of required retransmissions and overall reliability.
o Efficient caching requires that all the CoAP traffic is
intercepted by the same proxy, network edge is a strategical
placement for this need.
o To enable access to local-multicast in the constrained network,
the HTTP/CoAP proxy may require a network interface directly
attached to the constrained network.
The following sections outline the possible issues of the HTTP/CoAP
mapping in many typical use cases:
o Section 2 focuses on providing insight on the practice to map CoAP
to HTTP;
Castellani & Loreto Expires July 29, 2011 [Page 3]
Internet-Draft Map HTTP to COAP January 2011
o Section 3 outlines the options available to map CoAP observe to
the well-known HTTP bidirectional methods;
o Section 4 describes how to map a CoAP multicast reques;
o Section 5 outlines the mapping of CoAP link format;
o Appendix A proposes two alternative mappings for observe, that
however require modifications to the current observe
functionality.
2. CoAP/HTTP best practice
Mapping of CoAP to HTTP as described in Section 7 of
[I-D.ietf-core-coap], is a straightforward conversion of features
present in both protocols.
Transaction layer messages without application layer content are
transparent to HTTP, thus the proxy MUST not map them to HTTP.
Every request served by the proxy, from HTTP to CoAP and viceversa,
requires the proxy to keep a state, in order to map the TCP
connection on the HTTP side to the Transaction ID on the CoAP side.
The proxy COULD support HTTP clients using persistent TCP
connections, always updating the TID of every new CoAP transaction in
the state related to the HTTP connection.
2.1. Methods and Status
HTTP methods supported by CoAP (Table 1 in [I-D.ietf-core-coap]) are
mapped directly. Every other HTTP method (e.g. HEAD etc.) not
supported, will cause the proxy to drop the request and generate a
response with status "405 Method Not Allowed" to the HTTP client.
Because CoAP supports a subset of HTTP methods, mapping from CoAP to
HTTP is direct.
Even if OPTIONS method is not defined in CoAP [I-D.ietf-core-coap],
an HTTP OPTIONS request MAY be translated as a CoAP GET to the
"/.well-known/core" URI.
Status codes supported by CoAP are listed in Table 3 of
[I-D.ietf-core-coap]. If an HTTP response carries a status not
supported by CoAP, the proxy should map the response using CoAP "502
Bad Gateway". Viceversa if the response issued by a CoAP server
contains a status code not supported by HTTP, the proxy should issue
an HTTP response with status "502 Bad Gateway".
Castellani & Loreto Expires July 29, 2011 [Page 4]
Internet-Draft Map HTTP to COAP January 2011
2.2. Headers and Content
HTTP traffic, as can be seen circulating in the traditional Internet,
SHOULD not enter the constrained network if it is not light enough to
fit this particular environment.
Given the constrained nature of the environment, the content size of
the exchange is expected to be low; higher attention should be paid
to the well-known detail richness of the HTTP headers.
Even if the high level of detail carried by HTTP headers is an
advantage to better describe the REQ/RES exchange, in our special
environment this is not feasible and should be avoided.
CoAP Headers are a minimal subset of HTTP Headers (see Section 3.2 in
[I-D.ietf-core-coap]), HTTP messages MUST be mapped dropping all
headers not supported by CoAP (e.g. User-Agent, Accept, Cookie,
etc).
When a request to be properly served requires a feature not offered
by CoAP, that request can be dropped by the proxy sending a "505 HTTP
Version Not Supported" error message to the HTTP client.
In contrast to this, when a message is to be mapped from CoAP to
HTTP, the proxy should describe the HTTP message with the highest
possible richness of details present in the CoAP message.
The mapping of URI requires special processing to split URI-Path part
from the URI-Query part.
CoAP URI-Authority header MUST be mapped to Host HTTP header. When a
CoAP message is lacking the URI-Authority Header, it MUST be
translated to HTTP/1.0 [RFC1945] because it is lacking the
information to complete the required Host HTTP Header; alternatively
can be evaluated the use of a reverse DNS lookup at the proxy to
complete the Host header.
3. CoAP observe to HTTP options
HyperText Transfer Protocol [RFC2616] is a request/response protocol,
where every request MUST be initiated by a client and can generate
only a single response. HTTP does not natively support any mechanism
for sending push notifications of changes on a specific resource on a
client.
However, in the real world, various mechanisms have been used
successfully for years in advanced web services. These mechanisms
Castellani & Loreto Expires July 29, 2011 [Page 5]
Internet-Draft Map HTTP to COAP January 2011
enable a web server to send updates to clients without waiting for a
poll request from the client.
Such mechanisms can deliver updates to clients in a more timely
manner while avoiding the latency experienced by client applications
due to the frequent opening and closing of connections required to
periodically poll for data.
The two most common server push mechanisms are "HTTP long polling"
and "HTTP streaming" [I-D.loreto-http-bidirectional].
These mechanisms can be used to observe the status of a resource
changing over time. The subscription to a resource (the information
kept by the server about an observation request to be continuously
notified of changes in the state of the resource) is mimicked by the
presence on the server of a hanging get (in the case of HTTP long
polling) or by the fact that the client stays connected (in the case
of HTTP streaming).
An observable resource can be an "event source" that emits
notifications corresponding to each change in its representation.
Events occur regardless of whether or not they are observed. The
CoAP server can mimic event sources on non event-enabled resources,
by locally polling the resource and transmitting a notification when
the content changes. Each observable resource can be identified
using the "obs" link extension.
3.1. HTTP subscription to a CoAP resource
In this section the mapping of CoAP observe to an HTTP client wishing
to subscribe to a CoAP resource is discussed;
[I-D.loreto-http-bidirectional] is a base reference of the most
widely used HTTP bidirectional methods.
The following sections are organized as follows:
o Section 3.1.1 discusses possible mappings available for
subscription parameters;
o Section 3.1.2 points out the state required from an HTTP/CoAP
proxy for handling CoAP observe sessions;
o Section 3.1.3 proposes a possible mapping of CoAP observe to HTTP
long-polling;
o Section 3.1.4 describes a second mapping to HTTP streaming.
3.1.1. Subscription parameters mapping
An HTTP client wishing to subscribe to a CoAP resource MUST insert in
the first request the lifetime of the subscription, in order to
enable the observe mechanism in the CoAP server.
Castellani & Loreto Expires July 29, 2011 [Page 6]
Internet-Draft Map HTTP to COAP January 2011
To insert in the request the needed options, there exist at least
three options:
o HTTP Request content: An XML document can be defined to hold the
lifetime parameter.
o HTTP URI Query parameter: The lifetime option can be inserted in
the query parameters of the HTTP URI requested. A major issue in
this method is the requirement for the HTTP/CoAP proxy to look
through all the query parameters present in every served request,
searching for the "lifetime" option. Moreover if found, the proxy
needs to read it, insert a "Subscription-lifetime" CoAP option
header and hopefully remove that query parameter from the request,
before inserting the URI Option header in the CoAP packet. If the
CoAP resource needs a "lifetime" parameter for its needs, in this
way this parameter will not be accessible by the HTTP clients.
o HTTP Header Option: a Subscription-Lifetime option header can be
inserted in the HTTP request itself. The proxy can directly map
that option to CoAP, operating only on the headers of the request
without modifying the URI or the content of the message. HTTP
standardization of a new header is required (IANA action?).
The lifetime option SHOULD be inserted only to notify the CoAP server
that the lifetime associated with that particular subscription has
changed. The proxy MUST relay the information to the CoAP server, if
the HTTP client has passed this option.
The observe functionality is designed to be used for observing
changes on resources, however if the resource value changes
frequently, sending every new value is not viable; with the current
observe design the traffic can be limited by the server. In some
specific circumstances this cannot satisfy particular application
requirements.
Example: the resource "energy" is attached to a sensor measuring the
energy detected in a channel in the previous K seconds, if energy is
higher than X the application ALARM wants to be notified immediately;
however ALARM cannot notify its threshold X to the server. This can
lead to a notification delay or to missing the notification of the
value of interest.
As the example suggests, to better define the notification
conditions, vendors may desire to use an extended set of parameters.
For this reason observe parameters SHOULD be easily mappable to HTTP,
and SHOULD support a possible growth of these parameters in number
and type.
The aforementioned reasons lead to prefer the "HTTP Request Content"
method, and also to encourage a specific effort to define this
Castellani & Loreto Expires July 29, 2011 [Page 7]
Internet-Draft Map HTTP to COAP January 2011
format, to obtain the best interoperability and efficiency in it.
Even if the unique parameter of the subscription will be the
lifetime, probably the simplest technique seems to be using the HTTP
request content.
3.1.2. Soft state requirements
Current [I-D.ietf-core-observe] design requires the HTTP/CoAP proxy
to maintain a state for each subscription, throughout the whole life
of the observe session.
As observe sessions are expected to be very long, this requirement
has a strong impact on the proxy efficiency, in terms of maximum
number of manageable subscriptions.
In particular for every concurrent subscription, the proxy is
required to maintain the data related to every active protocol:
1. CoAP endpoint IP/port, TID and headers as Token;
2. HTTP session data and in particular the TCP connection.
This state may lead to various issues when the number of
subscriptions grows, in particular the number of concurrently active
TCP connections per proxy should be limited.
As an added complexity, requiring the proxy to actively operate in
the subscription process leads to an added point-of-failure of the
subscription (e.g.: proxy restart leads to a subscription drop) and
could add complexity to deploy load-balancing proxies for crowded
WPANs.
The state requested by CoAP observe is higher than the minimum
possible, and different options for observe exist (as briefly
described in Appendix A) that remove the need for subscription-long
TCP connections.
Further evaluation of the observe method in terms of state
requirements is encouraged, especially towards solutions that do not
require the presence of application-level data in the state (e.g.
Token).
3.1.3. HTTP long-polling to CoAP observe
HTTP long-polling is a well-known method to obtain notifications over
HTTP. An extensive description of this technique can be found in
Section 2 of [I-D.loreto-http-bidirectional].
Figure 1 shows an HTTP client requesting to start the observation of
a CoAP resource for a period of time with duration "lifetime".
Castellani & Loreto Expires July 29, 2011 [Page 8]
Internet-Draft Map HTTP to COAP January 2011
A GET requesting a subscription can be distinguished by the presence
of the "lifetime" parameter; the parameter is shown in the chart, but
the actual method of transmitting that parameter is still an open
issue as discussed in Section 3.1.1.
The following charts also pin-point a list of open questions. To the
best of our knowledge the questions have not yet been discussed in
the WG, and for convenience have been gathered in Section 3.3.
HTTP HTTP-CoAP CoAP
client proxy server
| | |
| GET /foo | |
| lifetime=60s | |
|----------------------->| |
| (hanging GET) | CON tid=47 |
| | GET /foo |
| | lifetime=60s |
| |----------------------->|
| | ACK tid=47 |
| | 200 /foo |
| 200 OK | "<temp... |
| "<temp... |<-----------------------|
|<-----------------------| |
| GET /foo?lifetime=60s | |
|----------------------->| |
| (hanging GET) | Open question #1, #2 |
| | |
| | ..Time Passes.. |
| | |
| | CON tid=703 |
| | 200 /foo |
| | "<temp... |
| |<-----------------------|
| | |
| | Open question #3 |
| | |
| | ACK tid=703 |
|200 OK |----------------------->|
|"<temp.. | |
|<-----------------------| |
Figure 1: HTTP long polling to CoAP observe
Castellani & Loreto Expires July 29, 2011 [Page 9]
Internet-Draft Map HTTP to COAP January 2011
3.1.4. HTTP streaming to CoAP observe
HTTP streaming is another well-known method to get instant
notifications and multiple responses using a single HTTP request. An
extensive description can be found in Section 3 of
[I-D.loreto-http-bidirectional].
In Figure 2 an HTTP client starts with the same request described in
Section 3.1.3; the proxy decides to map this request using a chunked
transfer-encoding format.
How can the HTTP client suggest to the proxy the preference for
chunked encoding?
HTTP HTTP-CoAP CoAP
client proxy server
| | |
| GET /foo | |
| lifetime=60s | CON tid=47 |
|----------------------->| GET foo |
| | lifetime=60s |
| |----------------------->|
| | ACK tid=47 |
| | 200 foo |
| | "<temp... |
| 200 OK |<-----------------------|
| Transfer-Encoding: chunked |
| | |
| 8 | |
| "<temp... | |
|<-----------------------| |
| | ..Time Passes.. |
| | |
| | CON tid=703 |
| | 200 foo"<temp... |
| |<-----------------------|
| | |
| | Open question #3,#4 |
| | |
| 8 | ACK tid=703 |
| "<temp... |----------------------->|
|<-----------------------| |
| | |
| Open question #5 | |
Castellani & Loreto Expires July 29, 2011 [Page 10]
Internet-Draft Map HTTP to COAP January 2011
Figure 2: HTTP streaming to CoAP observe
3.2. CoAP observing an HTTP resource
In Figure 3 a CoAP client wishes to observe an HTTP resource; the
proxy to serve this request uses an HTTP long-polling.
This is not possible without an assumption on the HTTP resource
"/foo": the client should know in advance that "/foo" is a long-
polling resource and it shares this knowledge with the proxy by
inserting the "lifetime" option in the first message.
The proxy receiving a GET with the "lifetime" option SHOULD handle
that request differently, by requesting again the "/foo" resource
every time a response is received and the lifetime is not expired.
Castellani & Loreto Expires July 29, 2011 [Page 11]
Internet-Draft Map HTTP to COAP January 2011
CoAP CoAP-HTTP HTTP
client proxy server
| | |
| CON tid=47 | |
| GET foo | |
| lifetime=60s | |
|----------------------->|GET /foo |
| |----------------------->|
| Open question #6 |hanging GET |
| | |
| Empty ACK? | |
| ACK tid=47 | |
|<-----------------------| |
| | ..Time Passes.. |
| | |
| |<-----------------------|
| | 200 OK |
| CON tid=703 |"<temp.. |
| 200 foo"<temp | |
|<-----------------------| |
| | |
| ACK tid=703 | |
|----------------------->|GET /foo |
| |----------------------->|
| |hanging GET |
| | |
| | ..Time Passes.. |
| | |
| | Open question #7 |
| | |
| |<-----------------------|
| CON tid=755 | 200 OK |
| 200 foo"<temp | "<temp.. |
|<-----------------------| |
| RST tid=703 | |
|----------------------->| |
Figure 3: CoAP observe to HTTP long polling
To the best of our knowledge a possible mapping for an HTTP streaming
resource is not possible using the currently proposed protocol.
Appendix A.2 briefly describes a possible solution to this, by
proposing to add native support for chunked transfer encoding in
CoAP.
Castellani & Loreto Expires July 29, 2011 [Page 12]
Internet-Draft Map HTTP to COAP January 2011
3.3. Open questions
Open question #1 The second GET is identical to the first one. How
should the proxy understand that this is not a new client
requesting a subscription? Related question: How to match the
received GETs to the right CoAP observe session (e.g.: token)?
Open question #2 Should we need to consider the time-out issues
present in bidirectional HTTP as described in
[I-D.loreto-http-timeout]?
Open question #3 Should the proxy send an ACK message immediately
after receiving the response (+1) or after the HTTP client has
received it?
Open question #4 A response code different from the first one will
be dropped. Does the subscription remain valid or should be
dropped? (e.g.: Should a 500 error on the second notification be
ignored or should the proxy drop the HTTP session?)
Open question #5 Should the CoAP subscription be closed immediately
(+1) or should send a RST when receives another notification?
Open question #6: If lifetime expires while the HTTP GET is still
waiting for a response, should the proxy should drop the TCP
connection or .. what ?
Open question #7: Should the proxy send always/all the notifications
in a Confirmable way?.
4. Multicast
CoAP supports multicast communication by using the UDP transport,
while HTTP using TCP cannot talk to multiple hosts with a single
request.
The CoAP/HTTP proxy is in charge of the UDP to TCP mapping and will
be also the most convenient place to merge multiple UDP responses to
a single TCP stream.
Notifications and multicast responses share a similarity between
them, both are multiple responses to a single request; for this
reason, a straightforward mapping for a request to a multicast CoAP
resource is using the HTTP bidirectional methods.
In contrast to this, the actual source of the response is lost using
a direct mapping. This problem can be handled using two different
Castellani & Loreto Expires July 29, 2011 [Page 13]
Internet-Draft Map HTTP to COAP January 2011
approaches:
o Proxy adds it: the proxy has the information available and can add
it in the stream, using a predefined data format (efficient but
requires a standardization effort/+1).
o Not needed/Application adds it: the source information itself is
not believed valuable by default, applications that require it
should add the information in their content (no standardization,
not efficient).
Mappings proposed for the CoAP observe can also be suitable to solve
this problem too:
o HTTP streaming can be the preferred solution, because the client
does not require a new connection for every value
o the technique described in Appendix A.1 is also valid for
receiving responses to multicast requests.
o HTTP long polling can be also used, in the case the proxy is able
to encapsulate more answers within a single message-body (e.g.
Content-type: multipart/*).
5. Resource Discovery
[I-D.ietf-core-link-format] specifies a link format useful for CoRE
Resource Discovery; link format is realized extending the HTTP Link
Header Format defined in [RFC5988].
This link format is offered as content of resources and transmitted
using a new Internet media type (application/link-format), the
typical resource holding this content is the "/.well-known/core": it
contains a list of links useful for resource discovery.
As defined in [RFC5988], in HTTP the links are delivered as HTTP
headers within a specific resource; this architectural difference
leads to a harder mapping of CoRE resource discovery in HTTP.
5.1. CoRE resource discovery by an HTTP Client
If [I-D.ietf-core-link-format] is supported and the HTTP client
handles the "application/link-format" media type, the well-known URI
"/.well-known/core" can be accessed directly by the client and the
resource discovery can be performed as discussed in
[I-D.ietf-core-link-format].
Castellani & Loreto Expires July 29, 2011 [Page 14]
Internet-Draft Map HTTP to COAP January 2011
HTTP HTTP-CoAP CoAP
client proxy server
| | |
| GET /.well-known/core | |
| Host: xxx.xxx | |
| Accept: application/link-format |
|----------------------->| |
| | CON tid=47 |
| | GET /.well-known/core |
| | Accept: application/link-format
| |----------------------->|
| | CON tid=47 |
| | 200 OK |
| | Content-Type: application/link-format
| | </sensors>;rel="index";n="Sensor Index"
| 200 OK |<-----------------------|
| Content-Type: application/link-format |
| </sensors>;rel="index";n="Sensor Index" |
|<-----------------------| |
Figure 4: HTTP-Core Discovery
If the HTTP client does not support the link format specification,
some alternative mapping may be investigated:
o HTTP OPTIONS method could be mapped to a "GET /.well-known/core";
o CoRE resource discovery can be implemented inside the proxy; the
proxy can operate the resource discovery as a separate task, and
can keep a cached version of the well-known URI(s). Using this
knowledge Link headers can be inserted in the HTTP responses, even
if that information is not present in the CoAP response.
6. Security Considerations
TBD
7. IANA Considerations
This document does not require any actions by the IANA.
8. Acknowledgements
Special thanks to Nicola Bui and Michele Zorzi for their support and
for the various contributions to this document.
Castellani & Loreto Expires July 29, 2011 [Page 15]
Internet-Draft Map HTTP to COAP January 2011
Thanks to Brian Frank for its support and its feedback about the
content.
9. References
9.1. Normative References
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.ietf-core-coap]
Shelby, Z., Frank, B., and D. Sturek, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-03
(work in progress), October 2010.
[I-D.ietf-core-observe]
Hartke, K. and Z. Shelby, "Observing Resources in CoAP",
draft-ietf-core-observe-00 (work in progress),
October 2010.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-02 (work in progress),
December 2010.
9.2. Informative References
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[I-D.loreto-http-bidirectional]
Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known issues and best practices for the Use of Long
Polling and Streaming in Bidirectional HTTP",
draft-loreto-http-bidirectional-05 (work in progress),
October 2010.
[I-D.loreto-http-timeout]
Loreto, S., Thomson, M., and G. Wilkins, "Hypertext
Transfer Protocol (HTTP) Timeouts",
draft-loreto-http-timeout-00 (work in progress),
June 2010.
Castellani & Loreto Expires July 29, 2011 [Page 16]
Internet-Draft Map HTTP to COAP January 2011
Appendix A. Alternatives for CoAP subscription/notification(s)
A.1. Server-to-server notifications
In an M2M network environment, communication between entities is
envisioned to happen using a peer-to-peer host model. Such
consideration could motivate a subscription architecture working in
server-to-server fashion.
HTTP HTTP-CoAP CoAP
client proxy server
| | |
| GET /foo | |
| Link: </bar>; rel=via | |
| | |
| "<Subscription> | |
| <lifetime value="60s"/> |
| <threshold value=">10"/> |
| </Subscription>" | |
|----------------------->| |
| | |
| | CON tid=47 |
| | GET foo |
| | source-URI=bar |
| | lifetime=60s |
| |----------------------->|
| | |
| | ACK tid=47 |
| | 200 |
| | "<temp... |
| |<-----------------------|
| | |
| 200 OK | |
| "<temp... | |
|<-----------------------| |
| | |
HTTP HTTP-CoAP CoAP
server proxy client
| | ..Time Passes.. |
| | |
| | NON tid=223 |
| | 200 bar |
| | source-URI=foo |
| | "<temp... |
| |<-----------------------|
| | |
| POST /bar | |
Castellani & Loreto Expires July 29, 2011 [Page 17]
Internet-Draft Map HTTP to COAP January 2011
| Link: </foo>; rel=via | |
| Content-Type: message/http |
| | |
| 200 OK | |
| "<temp... | |
|<-----------------------| |
| | |
| 200 OK | |
|----------------------->| |
| | |
| | ..Time Passes.. |
| | |
| | CON tid=703 |
| | 200 bar |
| | source-URI=foo |
| | "<temp... |
| |<-----------------------|
| | |
| POST /bar | |
| Link: </foo>; rel=via | |
| Content-Type: message/http |
| | |
| 200 OK | |
| "<temp... | |
|<-----------------------| |
| | |
| 200 OK | |
|----------------------->| |
| | |
| | ACK tid=703 |
| |----------------------->|
| | |
| | |
Figure 5: Server-to-Server HTTP Mapping
The diagram depicted in Figure 5 introduces a new CoAP Option header,
source-URI representing the resource that is the source of the
request.
When this option is present in a request, the client is willing to
start a subscription session to the resource.
This option can remove the need for the Subscription-lifetime header;
the lifetime parameter, together with the other subscription
parameters, can be carried as part of the content of the initial
subscription request, as described in Section 3.1.1.
Castellani & Loreto Expires July 29, 2011 [Page 18]
Internet-Draft Map HTTP to COAP January 2011
The interaction is performed between two entities both assuming the
server role. This characteristic can cause at least two issues that
need to be properly evaluated:
o Only hosts supporting inbound connectivity on a TCP port can
access this subscription functionality. In an IPv6/M2M network
environment this problem can be more easily addressed.
o Accepting inbound connections can lead to new security threats,
this requires deeper investigation
Nevertheless server-to-server has significant advantages in terms of
scalability and reliability; it does not require the HTTP/CoAP proxy
to hold any state about the subscription. For this reason even if
the proxy is load-balanced or rebooted the subscription will remain
in place. Moreover the need for maintaining permanent TCP
connections for every observe session is fully removed.
A.2. Observe using native Transfer-Encoding chunked
Transfer-Encoding chunked is a data transfer mechanism present in
HTTP [RFC2616]; this technique is used in HTTP to obtain a
bidirectional channel as described in
[I-D.loreto-http-bidirectional].
If the observe mechanism is built upon a Native chunked Transfer-
Encoding in CoAP, it could be mapped straightforwardly to HTTP
streaming by an HTTP/CoAP proxy, without any soft-state in the CoAP
part of the proxy (on the HTTP side, the TCP connection must be kept
open).
Porting chunked Transfer-Encoding to an UDP based protocol can be
realized with a new CoAP Option header (New-Opt). If the New-Opt
option is present with value 1, the exchange is not ending with a
single response but only when a response is received with a 0-valued
New-Opt option.
If the source emits only one message without acknowledgment the
transaction number can be preserved, in this scenario the source can
emit new chunks only if the previous one has been acknowledged.
The Token header can be used if more than one unacknowledged message
has to be transmitted simultaneously.
Realizing the HTTP streaming mapping in CoAP with this option present
is straightforward, however on the HTTP side of the proxy a TCP
connection is open for every active subscription.
If this functionality is properly investigated, it may offer a
solution also to the transfer of resources having a large
Castellani & Loreto Expires July 29, 2011 [Page 19]
Internet-Draft Map HTTP to COAP January 2011
representation. Example: the chunks may belong to a single large
representation (case A) or to multiple smaller representations (case
B). The client can distinguish between case A and B, if the server
tells the client in the first message using a flag in New-Opt.
Authors' Addresses
Angelo P. Castellani
University of Padova
Via Gradenigo 6/B
Padova 35131
Italy
Email: angelo@castellani.net
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Castellani & Loreto Expires July 29, 2011 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 15:15:00 |