CORE WG Z. Cao
INTERNET-DRAFT R. Jadhav
Intended Status: Informational Huawei
Expires: April 26, 2016
October 27, 2016
CoAP Delegated Observe
draft-cao-core-delegated-observe-00
Abstract
This document discusses the scenarios for "delegated observe", in
which a subscriber needs to register some resources on behalf of some
other entities. This document also presents a CoAP protocol
extension for the delegated observe operation.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Zhen Cao, et al. Expires <April 26, 2016> [Page 1]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
Copyright and License Notice
Copyright (c) 2016 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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Scenarios for Delegated Observe . . . . . . . . . . . . . . . . 3
2.1 Multiple Devices . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Delegation to Cloud . . . . . . . . . . . . . . . . . . . . 3
2.3 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Overview of Delegated Observe . . . . . . . . . . . . . . . . . 4
4 The Delegated Observe Option . . . . . . . . . . . . . . . . . . 5
5 Handling Delegated Observe . . . . . . . . . . . . . . . . . . 6
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zhen Cao, et al. Expires <April 26, 2016> [Page 2]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
1 Introduction
CoAP [RFC7252] is a light-weight application protocol for constrained
networks. To avoid keeping polling devices, CoAP supports the
'observe' operation defined in [RFC7641], in which a subscriber can
register its interest to certain resources and then be updated with
their representation. However, in the current "observe" protocol,
the subscriber can only register interests on behalf of itself, and
therefore, updated information of the represented resources could not
be notified to any parties other than the one who sends the observe
request.
This document discusses the scenarios for "delegated observation", in
which a subscriber needs to register some resources on behalf of
other entities or a group of entities including itself. This
document also presents a CoAP protocol extension for the delegated
observe operation.
2 Scenarios for Delegated Observe
This section describes scenarios that needs delegated observe.
2.1 Multiple Devices
In a typical smart home network setup, a user with multiple devices
wants to observe some sensor resource (e.g., thermometer, bulbs).
Instead of sending CoAP Observe requests from every single device,
one of the them can send an Observe Registration on behalf of that
group of devices, so that all of them will be notified at once.
2.2 Delegation to Cloud
A user wants its mobile device to be notified of a certain sensor
information both in-home and off-home. When the device moves out of
its smart home network coverage, it is normally hidden behind NAT and
FW that keep it being reached for such notification messages. In
this case, the normal observe-notification scheme may fail. A walk-
around for this case is to let the device send a delegated observe
request while at home, asking the home sensors send notifications to
the device's representative cloud server, so that the device can
always fetch the information from it cloud service while off-home.
This scenario is depicted in Fig. 1.
Zhen Cao, et al. Expires <April 26, 2016> [Page 3]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
dev Cloud dev
Sensor in-home Server off-home
| | | |
| Delegated | | |
|<--Observe --| | |
| | | |
|--------Notification-------->| |
| | |
| |<-- GET--------|
| |----- ACK----->|
Figure 1: Delegation to Cloud
2.3 Multicast
A group of devices would like to observe the location information on a
motion sensor. This is a useful case when a number of light bulbs need
to adjust its lighting intensity based on the location of the observed
motion object. Instead of let each device register an interest on the
motion sensor, one of them could simply delegate the observe to this
multicast group, so that the location update notifications will be send
to the multicast address that they belong to. This scenario is
visualized in Fig.2.
Motion
Sensor Bulb_1 Bulb_2 Bulb_n
| | | |
| Delegated | | |
|<-Observe-----| | |
| | | |
| Multicast | | |
|--Notify ---->|----------->|----------->|
| | | |
| | | |
Figure 2: Delegation to a Multicast Group
3 Overview of Delegated Observe
As show in Fig.3, we name the node that has the direct representation of
the CoAP resource as the "Source node"; and the immediate node as the
'Delegate node' that will send delegated Observe request to the Source
node, on behalf of the "Delegated node" who will be notified by the
Source Node.
Zhen Cao, et al. Expires <April 26, 2016> [Page 4]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
Source Delegate Delegated
Node Node Node
| | |
| Delegated | |
|<-Observe-----| |
| | |
| | |
|--Notify ---->|----------->|
| | |
| | |
Figure 3: Overview of Delegated Observe
4 The Delegated Observe Option
The properties of the Delegated Observe Option are defined in Fig. 4.
In a GET request:
+-----+---+---+---+---+------------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+------------------+--------+--------+---------+
| TBD | | x | - | | Delegated Observe| string | 0-256 | (none) |
+-----+---+---+---+---+------------------+--------+--------+---------+
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
In a Response:
+-----+---+---+---+---+------------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+------------------+--------+--------+---------+
| TBD | | x | - | | Delegated Observe| uint | 0-3 B | (none) |
+-----+---+---+---+---+------------------+--------+--------+---------+
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
Figure 4: CoAP Delegated Observe Option
When included in a GET request, the Delegated Observe Option extends the
GET method so it does not only retrieve a current representation of the
target resource, but also requests the server to add an entry in the
list of observers of the resource. This entry maps the target resource
to an identifier of the observer contained in the value of this option.
When used to register the representation, the value of Delegated Observe
in a GET request is the identifier of the nodes that will be notified,
in the format of "IP:port" or "domain_name:port".
When used to de-register the representation, the value of Delegated
Zhen Cao, et al. Expires <April 26, 2016> [Page 5]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
Observe in the GET is a special string, e.g., in the format of ":::",
the specific format needs further discussion. [TBD]
When included in a response, the Delegated Observe Option identifies the
message as a notification. The Option value is used as a sequence number
used to infer the order of the notifications. The ordering inference is
the same as what has been discussed in Section 3.4 of [RFC7641].
5 Handling Delegated Observe
Before sending the delegated observe, the "Delegate node" needs to know
which address:port on the Delegated node will be open to receive the
subsequent notification from the source node. This negotiation is out of
scope of this document.
Upon receiving the delegated observe request, the "Source Node" will
create an entry based on the identifier of the Delegated Node contained
within the request. The Source Node can decide if it needs to verify
the validity of the Delegated node, per its own policy. The validation
way is also out of the scope of this document.
The Delegated Node, once being delegated and verified by Source Node,
will be notified subsequently, although it does not send the request for
that resource. The Delegated Node interprets the CoAP message, and will
handle this message if the CoAP message contains a Delegated Observe
option defined in Section 4.
6 Security Considerations
The security considerations in [RFC7252] and [RFC7641] apply.
Delegated observe may increase the risk of amplification attacks, given
the source node will send notifications to delegated nodes who have not
requested the resource directly. This negative effect can be controlled
by several implementation considerations: a) the delegating node can
negotiate with the delegated node before sending delegated observe, out
of band; b) the source node will strictly control the rate of the
notifications, so that flooding will be avoided; c) the delegated node
can block any notifications beyond a certain data rate.
7 IANA Considerations
If approved, an Option Number for the defined Delegated Observe Option
for CoAP will be needed.
Zhen Cao, et al. Expires <April 26, 2016> [Page 6]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
| Number | Name | Reference |
+--------+--------------------+-----------+
| TBD | Delegated Observe | [thisdoc] |
7 References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
[RFC7641] K. Hartke, "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, September 2015.
Appendix A. Examples
Source Delegate Target
Node Node Node
| | |
| Delegated | | Header: GET 0x 86868686
|<-Observe-----| | Token: 0x55
| | | Uri-Path: temp
| | | D-Observe: 10.0.0.2:5683
| | |
| | |
| | | Header: GET 0x 86868686
|--Notify(2.05)------------>| Token: 0x55
| | | D-Observe: 9
| | | Max-age: 15
| | | Payload: "18.8 Cel"
| | |
| | | Header: GET 0x 8686ab99
|--Notify(2.05)------------>| Token: 0x55
| | | D-Observe: 16
| | | Max-age: 15
| | | Payload: "19.2 Cel"
Figure A.1: Example of Delegated Observe
Authors' Addresses
Zhen Cao, et al. Expires <April 26, 2016> [Page 7]
INTERNET DRAFT draft-cao-core-delegated-observe <Issue Date>
Zhen Cao
Huawei Tech
Beijing, China
EMail: zhencao.ietf@gmail.com
Rahul Arvind Jadhav
Huawei Tech,
Kundalahalli Village,
Bangalore, India
EMail: rahul.jadhav@huawei.com
Zhen Cao, et al. Expires <April 26, 2016> [Page 8]