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: ;rt="ipso:dev", ;rt="ipso:dev-mfg", ;rt="ipso:dev-mdl", ;rt="ipso:lt", Vial Expires September 3, 2012 [Page 8] Internet-Draft CoRE Mirror Proxy March 2012 ;rt="ipso:lt-ctr" 5.1. Discovery SEP MP | | | ----- GET /.well-known/core?rt=core-mp ------> | | | | | | <---- 2.05 Content "; rt="core-mp" ------ | | | Req: GET coap://[ff02::1]/.well-known/core?rt=core-mp Res: 2.05 Content ;rt="core-mp" 5.2. Registration SEP MP | | | --- POST /mp " | | | | | | <-- 2.01 Created Location: /mp/0 ------------- | | | Req: POST coap://mp.example.org/mp?h=switch<=1024 Etag: 0x3f Payload: ;rt="ipso:dev", ;rt="ipso:dev-mfg", ;rt="ipso:dev-mdl", ;rt="ipso:dev-name", ;rt="ipso:lt", ;rt="ipso:lt-ctr" Res: 2.01 Created Location: /mp/0 The resources below have been created on the MP. ;rt="ipso:dev", ;rt="ipso:dev-mfg", ;rt="ipso:dev-mdl", ;rt="ipso:dev-name", ;rt="ipso:lt", ;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 " | | | | | | <-- 2.01 Created Location: /rd/6534 ---------- | | | Req: POST coap://rd.example.org/rd?h=switch<=1024 Etag: 0x6a Payload: ;rt="ipso:dev", ;rt="ipso:dev-mfg", ;rt="ipso:dev-mdl", ;rt="ipso:dev-name", ;rt="ipso:lt", ;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]