Re: [core] Group Communication published as RFC 7390

"Dijk, Esko" <esko.dijk@philips.com> Tue, 11 November 2014 09:57 UTC

Return-Path: <esko.dijk@philips.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAF71A8978 for <core@ietfa.amsl.com>; Tue, 11 Nov 2014 01:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.632
X-Spam-Level: **
X-Spam-Status: No, score=2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_GUARANTEE1=4.533, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t0kyqnS6PdA for <core@ietfa.amsl.com>; Tue, 11 Nov 2014 01:57:02 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::724]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC611A1B47 for <core@ietf.org>; Tue, 11 Nov 2014 01:56:59 -0800 (PST)
Received: from AM3PR04CA0031.eurprd04.prod.outlook.com (10.242.16.31) by DB4PR04MB0637.eurprd04.prod.outlook.com (10.242.221.15) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 11 Nov 2014 09:54:52 +0000
Received: from DB3FFO11FD029.protection.gbl (2a01:111:f400:7e04::196) by AM3PR04CA0031.outlook.office365.com (2a01:111:e400:8814::31) with Microsoft SMTP Server (TLS) id 15.1.16.15 via Frontend Transport; Tue, 11 Nov 2014 09:54:53 +0000
Received: from mail.philips.com (206.191.242.68) by DB3FFO11FD029.mail.protection.outlook.com (10.47.217.60) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Tue, 11 Nov 2014 09:54:52 +0000
Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.174]) by AMSPRD9003HT002.MGDPHG.emi.philips.com ([141.251.33.79]) with mapi id 14.16.0472.000; Tue, 11 Nov 2014 09:54:51 +0000
From: "Dijk, Esko" <esko.dijk@philips.com>
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, weigengyu <weigengyu@bupt.edu.cn>
Thread-Topic: [core] Group Communication published as RFC 7390
Thread-Index: Ac/0+7S3LtGeIPJdQa6cxMGPmNNqiwABz7vFAMK1+YAAB3l1AAADgMEAAB5O4oAAGC1/AAAAeZgAAR9wMmA=
Date: Tue, 11 Nov 2014 09:54:51 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED61836E9AF99@AMSPRD9003MB066.MGDPHG.emi.philips.com>
References: <36F5869FE31AB24485E5E3222C288E1F05AADF@NABESITE.InterDigital.com> <m0r3xoe97d.fsf@tzi.org> <D0AA5BD11132436C9888F30BEF6B8C5F@WeiGengyuPC> <36F5869FE31AB24485E5E3222C288E1F05BD59@NABESITE.InterDigital.com> <FF436DF43CFA484DB766BB3C0D995F87@WeiGengyuPC> <36F5869FE31AB24485E5E3222C288E1F05C27D@NABESITE.InterDigital.com> <8FF2CB13C7E94ED3818089FF2576E061@WeiGengyuPC> <36F5869FE31AB24485E5E3222C288E1F05C527@NABESITE.InterDigital.com>
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F05C527@NABESITE.InterDigital.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [83.85.143.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(428002)(13464003)(374574003)(377454003)(164054003)(199003)(85714005)(189002)(120916001)(77096003)(77156002)(64706001)(62966003)(84676001)(105586002)(47776003)(20776003)(54356999)(50986999)(76176999)(50466002)(19580405001)(19580395003)(93886004)(15975445006)(66066001)(95666004)(44976005)(99396003)(46102003)(4396001)(6806004)(68736004)(69596002)(55846006)(21056001)(107046002)(81156004)(23676002)(92726001)(92566001)(31966008)(101416001)(86362001)(15202345003)(106466001)(104016003)(2171001)(33656002)(2656002)(97736003)(87936001)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR04MB0637; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0637;
X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:(7)(6);SRVR:DB4PR04MB0637;
X-Forefront-PRVS: 0392679D18
Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=esko.dijk@philips.com;
X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB0637;
X-OriginatorOrg: philips.com
Archived-At: http://mailarchive.ietf.org/arch/msg/core/UPLOXObyTBEZET_aykz1lVo1BSg
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] Group Communication published as RFC 7390
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 09:57:05 -0000

Hi Akbar, Gengyu,

As typical in many standards it starts with a wide range of use cases. In the end not all these cases can be supported because trade-offs have to be made, or because a person/company pushing the use case is not participating. So I do not think special effort was done in LWM2M to support an authorization+multicast use case. And many cellular communication networks may not have IP multicast enabled.

From my work background I can confirm that for the use case of streetlight control, both individual control and group control is required. Group control can be implemented using multicast or serial unicast. Multicast has some advantages (lower traffic from controller node, lower latency, better synchrony). However, security (integrity, replay protection, sometimes authentication) is typically required for such multicast control - which current CoAP multicast can't provide. For more information see the discussion on https://tools.ietf.org/html/draft-keoh-dice-multicast-security-08 which aims to adapt DTLS to be suitable for CoAP multicast.

Regards
Esko

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: Wednesday, November 05, 2014 17:29
To: weigengyu; Carsten Bormann; Zach Shelby
Cc: core@ietf.org
Subject: Re: [core] Group Communication published as RFC 7390

Thanks, Gengyu.

It would be good to also hear Zach's opinion on this as he was active in the development of the LWM2M spec.  Also Carsten is very knowledgeable about multicast in general.

Zach/Carsten - Can you give your opinion on Gengyu's interpretation of OMA multicast requirements?



Best Regards,


Akbar

-----Original Message-----
From: weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Wednesday, November 05, 2014 11:15 AM
To: Rahman, Akbar
Cc: core@ietf.org; Carsten Bormann
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

RFC7390 is important and useful for many application.
But  it does not meet the requirements  as OMA specifies.
The application requiring the gurranteed reliable group communications has to handle the reliability issue by itself.

Suppose that OMA's applications are common in the future, it might be a better alternative to have CoAP with the garanteed reliable group communication facility.

Best Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Rahman, Akbar
Sent: Wednesday, November 05, 2014 12:42 PM
To: weigengyu
Cc: core@ietf.org ; Carsten Bormann
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,


Thank you for the references and the discussion.


>We believe that reliable communications are required for turning on/off
>electrical switches.

Yes, but there are also other alternatives including what was identified in RFC 7390 Section 2.4:


2.4. RESTful Methods

   Group communication most often uses the idempotent CoAP methods GET
   and PUT.  The idempotent method DELETE can also be used.  The non-
   idempotent CoAP method POST may only be used for group communication
   if the resource being POSTed to has been designed to cope with the
   unreliable and lossy nature of IP multicast.  For example, a client
   may resend a multicast POST request for additional reliability.  Some
   servers will receive the request two times while others may receive
   it only once.  For idempotent methods, all these servers will be in
   the same state while for POST, this is not guaranteed; so, the
   resource POST operation must be specifically designed to take message
   loss into account.

http://tools.ietf.org/html/rfc7390#section-2.4



Best Regards,

Akbar

-----Original Message-----
From: weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Tuesday, November 04, 2014 9:15 AM
To: Rahman, Akbar; Carsten Bormann
Cc: core@ietf.org
Subject: Re: [core] Group Communication published as RFC 7390

Hi Akbar,

In the use cases B.1 and B.2 requirements are to turn on/off a specific swtich or a group of switches.
We believe that reliable communications are required for turning on/off electrical switches.

The following words are from an OMA document.

Lightweight Machine to Machine Requirements Candidate Version 1.0 – 02 Oct
2012

Appendix B. Use Cases (Informative)
B.1 Streetlight Control
B.1.1 Short Description
John is a streetlights supervisor – responsible to manage streetlights system at his home town. There are thousands of streetlights in the city and he expects to have low-cost M2M sensors embedded in these streetlights. He needs a capability to remotely turn on/off a specific streetlight or a group of streetlights. He needs a capability to know the control status of each streetlight. He needs a capability to make sure that remote instructions sent to these streetlights are only accepted from authorized users (such as himself).

B.2 Air Condition
B.2.1 Short description
Ted is a HVAC supervisor – responsible to manage air-conditioning systems at his multi-story corporate office. There are multiple air-conditioning systems in his office for full HVAC support. He expects to have low-cost M2M sensors embedded in these HVAC systems. He needs a capability to remotely turn on/off a specific air conditioning system or a group of systems. He needs a capability to specify the air-conditioning system to provide its metering data. He needs a capability to configure the temperature threshold for turning on/off the air-conditioning systems.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Rahman, Akbar
Sent: Tuesday, November 04, 2014 8:34 PM
To: weigengyu ; Carsten Bormann
Cc: core@ietf.org
Subject: RE: [core] Group Communication published as RFC 7390

Hi Gengyu,


Can you give some more description of why you think this is required?  Can you give a reference to a section in the OMA LWM2M spec where they reference reliable group communications?


Best Regards,


Akbar


-----Original Message-----
From: weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Tuesday, November 04, 2014 4:01 AM
To: Carsten Bormann; Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] Group Communication published as RFC 7390

Hi,

Whether the CoRE WG is interested in Reliable Group Communications.
It is required in the scenarios given by OMA.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件-----
From: Carsten Bormann
Sent: Friday, October 31, 2014 8:04 PM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] Group Communication published as RFC 7390

"Rahman, Akbar" <Akbar.Rahman@InterDigital.com> writes:

> http://tools.ietf.org/html/rfc7390

Thanks, Akbar and Esko, for keeping up the flame on this subject!

I have seen considerable interest in making group communication over CoAP more useful, and this document is a good first start.
I expect that more people will come to the IETF with work in this area.

Gruesse, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.