Internet DRAFT - draft-cao-core-delegated-observe

draft-cao-core-delegated-observe



 



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]