CoRE Mirror Proxy
draft-vial-core-mirror-proxy-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Matthieu Vial | ||
| Last updated | 2012-03-02 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vial-core-mirror-proxy-00
CoRE M. Vial
Internet-Draft Schneider-Electric
Intended status: Standards Track March 2, 2012
Expires: September 3, 2012
CoRE Mirror Proxy
draft-vial-core-mirror-proxy-00
Abstract
This document introduces the concept of Mirror Proxy that enables
sleeping devices to participate in a REST architecture despite the
fact that they are not web servers. Most constrained devices may
sleep during long periods preventing them from acting as traditional
web servers. However as client-only endpoints they can rely on a
Mirror Proxy to cache and serve the content they provide.
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 September 3, 2012.
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
the Trust Legal Provisions and are provided without warranty as
Vial Expires September 3, 2012 [Page 1]
Internet-Draft CoRE Mirror Proxy March 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Resource mapping in a Mirror Proxy . . . . . . . . . . . . 4
3.2. Cache refresh strategies . . . . . . . . . . . . . . . . . 5
3.3. Placing a Mirror Proxy . . . . . . . . . . . . . . . . . . 7
4. Mirror Proxy interfaces . . . . . . . . . . . . . . . . . . . 7
4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Validation . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Content refresh . . . . . . . . . . . . . . . . . . . . . 10
5.4. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Vial Expires September 3, 2012 [Page 2]
Internet-Draft CoRE Mirror Proxy March 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 (e.g. 8-bit microcontrollers with limited RAM and
ROM) and networks (e.g. 6LoWPAN). As pointed out by
[I-D.arkko-core-sleepy-sensors], the server model is far from being
optimum for devices with high energy constraints. Since the client
model seems to be the most efficient energy mode for sleeping device,
this document proposes to define a new intermediary called Mirror
Proxy whose role is to make a sleeping device appears like any other
web server in the network. On that point, a Mirror Proxy is similar
to a caching reverse proxy except that there is no origin server but
rather an "origin" client. So the Mirror Proxy serves content and
also advertises resources on behalf of its registered endpoints.
This document defines the REST interface required to support the
Mirror Proxy function on a constrained web server.
2. 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].
This specification requires readers to be familiar with all the terms
and concepts that are discussed in [RFC5988] and
[I-D.shelby-core-resource-directory]. Readers should also be
familiar with the terms and concepts discussed in
[I-D.ietf-core-coap] and [I-D.ietf-core-link-format]. This
specification makes use of the following additional terminology:
Sleeping endpoint (SEP): A sleeping network node that participates
in a constrained REST environment but can only act as a CoAP
client endpoint due to limited energy budget.
Mirror Proxy (MP): A web entity that caches, serves and advertises
content on behalf of a sleeping endpoint.
3. Architecture
The Mirror Proxy architecture is shown in Figure 1. A Mirror Proxy
(MP) hosts resources in its own resource tree on behalf of other web
entities which are called sleeping endpoint (SEP). For energy
efficiency a SEP is a client-only CoAP endpoint and hence is not able
to serve content by itself. The MP implements REST interfaces
Vial Expires September 3, 2012 [Page 3]
Internet-Draft CoRE Mirror Proxy March 2012
allowing a SEP to maintain a set of cached resources that will be
served in turn by the MP. A CoAP client discovers resources from the
SEP hosted on the MP using traditional mechanisms such as /.well-
known/core [I-D.ietf-core-link-format] or Resource Directory
[I-D.shelby-core-resource-directory].
SEP are assumed to proactively register and maintain mirror entries
on the MP, which are soft state and need to be periodically
refreshed. A SEP is provided with interfaces to register, update and
remove a mirror entry with associated resources. Furthermore, a
mechanism to discover a MP using the CoRE Link Format is defined.
Registration Mapping
+-----+ | |
| SEP |---- | | +--------+
+-----+ ---- | ....|.....| RD |
--|- +------+. | +--------+
+-----+ | ----| | | +--------+
| SEP | ---------|-----| MP |----|-----| Client |
+-----+ | ----| | | +--------+
--|- +------+ |
+-----+ ---- | |
| SEP |---- | |
+-----+
Figure 1: Mirror Proxy architecture
3.1. Resource mapping in a Mirror Proxy
The resources that a SEP wishes to be served are described using
link-format [I-D.ietf-core-link-format]. The description is
identical to the /.well-known/core resource found on a typical CoRE
web server. Upon successful registration a MP allocates a mirror
entry resource for a SEP. The resources specified by the SEP during
registration are created as sub-resources of the mirror entry on the
MP. The MP updates its own /.well-known/core resource to reflect the
changes in its resource tree. When the web server of the MP
registers its resources in a Resource Directory (RD), the MP must
also register the resources of the SEP with the RD. A MP MUST
register the resources of a SEP in a separate resource directory
entry. Once a mirror entry has expired, the MP deletes the resources
associated to that entry, clears the content cache accordingly and
finally updates its /.well-known/core resource. The RD and MP
entries are supposed to have the same lifetime so the MP don't need
to explicitly delete the RD entry except when the SEP uses the
Removal interface.
Once the resources have been created on the MP, the SEP can refresh
Vial Expires September 3, 2012 [Page 4]
Internet-Draft CoRE Mirror Proxy March 2012
the content of its resources at its own pace. The SEP updates the
cached content on the MP using PUT requests. The SEP may also poll
its writable resources using GET requests. When a SEP registers with
a MP, the REST interface defined with the Interface Description (if)
attribute is only valid from a client point of view. A Mirror Proxy
MUST accept PUT requests coming from a SEP even if the Interface
Description attribute doesn't allow this method.
The MP may accept to establish an observation relation between a
mapped resource from a SEP and a client using
[I-D.ietf-core-observe].
3.2. Cache refresh strategies
For non periodic cache refresh, confirmable PUT requests are
preferable for reliability. But most of the SEP can't stay awake
while waiting for a response. This is especially true when the MP is
not in the direct neighborhood of the SEP and the latency is higher.
A link layer (L2) like 802.15.4 supports low-level buffering that
allows a SEP to poll its parent router for incoming traffic and sleep
between poll requests. Figure 2 is an example of reliable cache
refresh with L2 buffering.
SEP Router MP
| [sleep] | |
| | |
| --- (CON) PUT /mp/0/val --------> | ---PUT---> |
| [sleep] | |
| | |
| --- L2 poll request -------------> | |
| [sleep] | |
| | |
| [CoAP retransmissions if necessary] | |
| | |
| --- L2 poll request -------------> | |
| [sleep] [L2 buffering] | <--2.04--- |
| | |
| --- L2 poll request -------------> | |
| <-- (ACK) 2.04 Changed ----------- | |
| [sleep] | |
| | |
Figure 2: Confirmable cache refresh with L2 buffering
When no L2 buffering is available another solution is to send a burst
of non confirmable PUT requests and come back to sleep mode without
waiting for a response. Unfortunately there is currently no option
in CoAP to indicate that the client endpoint is not interested in the
Vial Expires September 3, 2012 [Page 5]
Internet-Draft CoRE Mirror Proxy March 2012
response to the request. Figure 3 shows that the MP generates "2.04
Changed" even if the client endpoint is not able to process them
because it is sleeping.
SEP MP
| [long sleep] |
| |
| --- (NON) PUT /mp/0/val ---------------------> |
| [short sleep] |
| X-- (NON) 2.04 Changed ----- |
| --- (NON) PUT /mp/0/val ---------------------> |
| [short sleep] |
| X-- (NON) 2.04 Changed ----- |
| --- (NON) PUT /mp/0/val ---------------------> |
| [long sleep] |
| X-- (NON) 2.04 Changed ----- |
| |
Figure 3: Non-confirmable cache refresh without response suppression
Figure 4 depicts how a new suppression option in CoAP could improve
network efficiency. This mechanism is also valuable for periodic
refresh but in that case there is no compelling need to repeat the
request at each round.
SEP MP
| [long sleep] |
| |
| --- (NON) PUT /mp/0/val (Suppr-Rsp: All) ----> |
| [short sleep] |
| --- (NON) PUT /mp/0/val (Suppr-Rsp: All) ----> |
| [short sleep] |
| --- (NON) PUT /mp/0/val (Suppr-Rsp: All) ----> |
| [long sleep] |
| |
Figure 4: Non-confirmable cache refresh with response suppression
Note: The registration and update procedures between the SEP and the
MP must also be reliable. Moreover POST requests used for
registration are not idempotent so it is not possible to repeat them
as non-confirmable requests. In that regard, a CoAP option
indicating the sleeping constraints of a SEP might help to
synchronize with a MP. Also the response suppression mechanism may
delay the time needed for a SEP to detect that its mirrored resources
are unreachable.
Vial Expires September 3, 2012 [Page 6]
Internet-Draft CoRE Mirror Proxy March 2012
3.3. Placing a Mirror Proxy
The Mirror Proxy functionality can be distributed over multiple
server endpoints in the network or centralized on a more powerful web
server. The closest the Mirror Proxy is from the sleeping endpoint,
the shortest is the round-trip time (RTT). A shorter RTT gives
better energy efficiency for CoAP transactions. And a Mirror Proxy
in the direct neighborhood of a sleeping endpoint may even avoid
having to configure global connectivity for the latter. However in a
wireless sensor network relying on local connectivity may result in
fragility due to device mobility or radio fluctuations. This could
lead a constrained endpoint to frequently try to discover another
suitable Mirror Proxy. In that regard, a centralized Mirror Proxy
gives more stability but usually at the expense of energy
performance. A centralized Mirror Proxy also concentrates network
traffic on a central point and may cause network congestion in a
wireless sensor network. However data flow of a sleeping endpoint is
expected to be low hence mitigating the risk of network congestion.
A sleeping endpoint MAY register with more than one Mirror Proxy but
in that case the resources of a sleeping endpoint appear duplicated
during resource discovery. Since there is currently no way to de-
duplicate the resources, multiple registrations are discouraged.
4. Mirror Proxy interfaces
The interface is mostly identical to that of a Resource Directory
[I-D.shelby-core-resource-directory] so this document only points out
the differences.
4.1. Discovery
The discovery procedure is identical except that the resource type is
replaced with "core-mp".
4.2. Registration
The registration interface is identical and the following additional
actions are required.
The MP MUST check it has enough memory to create the resources for
the new SEP before accepting the registration. If the MP is out of
memory it MUST reply with a status code 5.03 "Service Unavailable".
In that case the SEP SHOULD try to find another MP.
Upon successful registration, a Mirror Proxy MUST update its /.well-
known/core resource to reflect the changes in its resource tree. If
Vial Expires September 3, 2012 [Page 7]
Internet-Draft CoRE Mirror Proxy March 2012
the web server of a Mirror Proxy is publishing its own resources in a
Resource Directory, it MUST also register the resources of the
sleeping endpoint.
Since each SEP may register resources with different lifetimes, the
MP MUST register each SEP as a separate resource directory entry in
the RD. The MP creates different RD entries by reusing the SEP name
provided during MP registration. If no name was provided, the MP can
use its own name and a new Instance identifier.
4.3. Update
The update interface is identical.
Upon successful update, /.well-known/core and the Resource Directory
(if applicable) MUST be updated accordingly.
4.4. Validation
The validation interface is not supported on a Mirror Proxy since the
sleeping endpoint is not a server endpoint.
4.5. Removal
The removal interface is identical.
Upon successful removal, /.well-known/core and the Resource Directory
(if applicable) MUST be updated accordingly.
4.6. Lookup
The lookup interface is not supported. An endpoint can discover the
resources associated to a sleeping endpoint by getting the /.well-
known/core resource of the Mirror Proxy or using the lookup interface
of the Resource Directory if any is available.
5. Examples
The following example details the typical message flow between a SEP
and a MP.
The SEP is here a light switch providing the content below:
</dev/>;rt="ipso:dev",
</dev/mfg >;rt="ipso:dev-mfg",
</dev/mdl>;rt="ipso:dev-mdl",
</lt/>;rt="ipso:lt",
Vial Expires September 3, 2012 [Page 8]
Internet-Draft CoRE Mirror Proxy March 2012
</lt/ctr>;rt="ipso:lt-ctr"
5.1. Discovery
SEP MP
| |
| ----- GET /.well-known/core?rt=core-mp ------> |
| |
| |
| <---- 2.05 Content "</mp>; rt="core-mp" ------ |
| |
Req: GET coap://[ff02::1]/.well-known/core?rt=core-mp
Res: 2.05 Content
</mp>;rt="core-mp"
5.2. Registration
SEP MP
| |
| --- POST /mp "</dev..." --------------------> |
| |
| |
| <-- 2.01 Created Location: /mp/0 ------------- |
| |
Req: POST coap://mp.example.org/mp?h=switch<=1024
Etag: 0x3f
Payload:
</dev/>;rt="ipso:dev",
</dev/mfg >;rt="ipso:dev-mfg",
</dev/mdl>;rt="ipso:dev-mdl",
</dev/n>;rt="ipso:dev-name",
</lt/>;rt="ipso:lt",
</lt/ctr>;rt="ipso:lt-ctr"
Res: 2.01 Created
Location: /mp/0
The resources below have been created on the MP.
</mp/0/dev/>;rt="ipso:dev",
</mp/0/dev/mfg >;rt="ipso:dev-mfg",
</mp/0/dev/mdl>;rt="ipso:dev-mdl",
</mp/0/dev/n>;rt="ipso:dev-name",
</mp/0/lt/>;rt="ipso:lt",
</mp/0/lt/ctr>;rt="ipso:lt-ctr"
Vial Expires September 3, 2012 [Page 9]
Internet-Draft CoRE Mirror Proxy March 2012
Then the MP registers those new resources in the RD.
MP RD
| |
| --- POST /rd "</mp/0..." -------------------> |
| |
| |
| <-- 2.01 Created Location: /rd/6534 ---------- |
| |
Req: POST coap://rd.example.org/rd?h=switch<=1024
Etag: 0x6a
Payload:
</mp/0/dev/>;rt="ipso:dev",
</mp/0/dev/mfg >;rt="ipso:dev-mfg",
</mp/0/dev/mdl>;rt="ipso:dev-mdl",
</mp/0/dev/n>;rt="ipso:dev-name",
</mp/0/lt/>;rt="ipso:lt",
</mp/0/lt/ctr>;rt="ipso:lt-ctr"
Res: 2.01 Created
Location: /rd/6534
5.3. Content refresh
Just after registration, the SEP refreshes the content of static
resources such as the manufacturer name (/dev/mfg) and model name
(/dev/mdl). These resources are updated with almost infinite max-age
so there is no need to send more PUT requests afterward as long as
the mirror proxy entry is refreshed on the MP.
SEP MP
| |
| --- PUT /mp/0/dev/mfg "Exa..." -------------> |
| |
| |
| <-- 2.04 Changed ----------------------------- |
| |
Req: PUT coap://mp.example.org/mp/0/dev/mfg (Max-Age: 0xFFFFFFFF)
Payload: Example.Com
Res: 2.04 Changed
When the switch is activated the SEP wakes up and sends a request to
refresh the light control resource. The Max-Age option in the
request indicates the maximum time between two PUT requests even if
the switch keeps the same state.
Vial Expires September 3, 2012 [Page 10]
Internet-Draft CoRE Mirror Proxy March 2012
SEP MP
| |
| --- PUT /mp/0/lt/ctr "1" -------------------> |
| |
| |
| <-- 2.04 Changed ----------------------------- |
| |
Req: PUT coap://mp.example.org/mp/0/lt/ctr (Max-Age: 1 hour)
Payload: 1
Res: 2.04 Changed
A client may have subscribed to change of values for the resource
/mp/0/lt/ctr on the MP. In that case, the MP would have to notify
the CoAP client right after a PUT request from the SEP. A typical
exchange would be:
SEP MP Client
| | |
| | <-- GET /mp/0/lt/ctr -- |
| | (observe) |
| | |
| | -- 2.05 Content "0" --> |
| | |
| - PUT /mp/0/lt/ctr "1" -> | |
| | |
| <- 2.04 Changed --------- | |
| | |
| | -- 2.05 Content "1" --> |
5.4. Polling
A SEP may ask a MP to mirror writable resources. In that case the
SEP needs to poll the MP to detect whether the resources have been
updated. The example below shows a SEP polling a writable resource
once a day to update its name.
Vial Expires September 3, 2012 [Page 11]
Internet-Draft CoRE Mirror Proxy March 2012
SEP MP Client
| | |
| - GET /mp/0/dev/n ------> | |
| | |
| <- 2.03 Valid ----------- | |
| | |
| | <-- PUT /mp/0/dev/n --- |
| [1 day] | |
| | -- 2.04 Changed ------> |
| | |
| - GET /mp/0/dev/n ------> | |
| | |
| <- 2.05 Content --------- | |
| | |
6. TODO
We need a way to identify a SEP registered in multiple proxies as a
single entity. Otherwise clients may have a wrong view of the
available services during resource discovery. The duplicate
resources are indeed seen as new devices.
We need a simple mechanism to define allowed methods on mirrored
resources that is independant of the resource profile. A second
Interface Description attribute with the CRUD letters might work.
We may add a CoAP option that would permit a MP to indicate in a
response that a client has updated another writable resource in the
cache for the requesting SEP. This would gives better response time
than polling.
When a SEP registers with multiple MP and each MP reuses the same
SEP's name to register with the RD, the resource directory entry
might be overwritten. We need to figure out what piece of
information is the handler for a resource directory entry in a RD
database.
6.1. Extensions
Implicit registration could be useful for highly constrained SEP that
don't have enough energy to maintain soft state in a MP. Like the
proposition in [I-D.arkko-core-sleepy-sensors], we could use a
multicast address to infer a resource type. Alternatively we could
allow explicit registration from a third-party endpoint.
Vial Expires September 3, 2012 [Page 12]
Internet-Draft CoRE Mirror Proxy March 2012
7. Acknowledgements
Thanks to Zach Shelby who is the author of the Resource Directory
interface.
8. IANA Considerations
"core-mp" resource type needs to be registered if an appropriate
registry is created.
This document suggest the creation of a new CoAP option to suppress
an undesired response to a request. But this new option should be
detailed in a separate draft.
9. Security Considerations
This document needs the same security considerations as described in
Section 7 of [RFC5988] and Section 6 of [I-D.ietf-core-link-format].
Unrestricted access to mirrored resources may allow a malicious web
client to poison the cache on a MP. A MP SHOULD authenticate the SEP
and restrict allowed methods according to the interface description
supplied during resource registration.
A malicious client could start a denial of service attack by trying
to mirror a large resource on a MP. Memory exhaustion would prevent
the other sleeping endpoints from mirroring their resources.
A malicious client could trigger the removal or the update interface
on a MP to delete mirrored resources. This would cause an
interruption of service for the targeted SEP until it registers again
its resources. A MP SHOULD authenticate client endpoints using the
interfaces that can modify a SEP description.
A MP could loose or delete the mirror proxy entry associated to a SEP
without sending an explicit notification (e.g. after reboot). A SEP
SHOULD be able to detect this situation by processing the response
code while sending requests to the proxy. Especially an error code
"4.04 Not Found" SHOULD cause the SEP to register again. A SEP MAY
also register with multiple proxies to alleviate the risk of
interruption of service.
10. References
Vial Expires September 3, 2012 [Page 13]
Internet-Draft CoRE Mirror Proxy March 2012
10.1. Normative References
[I-D.ietf-core-coap]
Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-11 (work in progress),
January 2012.
[I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP",
draft-ietf-core-observe-04 (work in progress),
February 2012.
[I-D.shelby-core-resource-directory]
Krco, S. and Z. Shelby, "CoRE Resource Directory",
draft-shelby-core-resource-directory-02 (work in
progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
10.2. Informative References
[I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors",
draft-arkko-core-sleepy-sensors-01 (work in progress),
July 2011.
Author's Address
Matthieu Vial
Schneider-Electric
Grenoble,
FRANCE
Phone: +33 (0)47657 6522
Email: matthieu.vial@schneider-electric.com
Vial Expires September 3, 2012 [Page 14]