Re: [Coma] Reprogramming Protocols

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 17 July 2012 06:47 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: coma@ietfa.amsl.com
Delivered-To: coma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7071111E80A2 for <coma@ietfa.amsl.com>; Mon, 16 Jul 2012 23:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level:
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxIDVhVL1eyH for <coma@ietfa.amsl.com>; Mon, 16 Jul 2012 23:47:23 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D1F3E11E809C for <coma@ietf.org>; Mon, 16 Jul 2012 23:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=15393; q=dns/txt; s=iport; t=1342507689; x=1343717289; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=r4gutMya7kFcX6s/M4YFbSlPDIeWzQM0KKq/zEl1h/s=; b=UdIJzExiyhvBhMAWlSaubJspARR94dyhwB8KAY36ECxEB8lpXsR/XaZO 0rgwLJi2ncMwVJpNycJ1RxT8VQ6GGZ3unC5TjAAKz97N91tARvrmyq6U0 5Wns1h3ejow5Eaikptf3ouvHCtHXves8s+0seMLhiKfYT0tv2wSB9wYog w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFALAJBVCtJXG9/2dsb2JhbABFgkq3D4EHgiABAQEEEgEaWgICAQgRBAEBCx0HFhwUCQgBAQQBEggah2ucMqAfBIs6FAQDhUxgA6NbgWaCX4FWCQ
X-IronPort-AV: E=Sophos; i="4.77,599,1336348800"; d="scan'208,217"; a="102532260"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jul 2012 06:48:09 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6H6m9QP000440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 06:48:09 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.219]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 01:48:08 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>, "Jonathan.Hansford@generaldynamics.uk.com" <Jonathan.Hansford@generaldynamics.uk.com>, "coma@ietf.org" <coma@ietf.org>
Thread-Topic: [Coma] Reprogramming Protocols
Thread-Index: Ac1Fc5UBo1X6J4eTSCi4A/yrOIdUnAAAlDEAB5xMBUA=
Date: Tue, 17 Jul 2012 06:48:08 +0000
Deferred-Delivery: Tue, 17 Jul 2012 06:48:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD807D3AA4C@xmb-rcd-x01.cisco.com>
References: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net>
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.81.214]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000
x-tm-as-result: No--40.818300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD807D3AA4Cxmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: Re: [Coma] Reprogramming Protocols
X-BeenThere: coma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <coma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coma>, <mailto:coma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coma>
List-Post: <mailto:coma@ietf.org>
List-Help: <mailto:coma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coma>, <mailto:coma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 06:47:25 -0000

Hum... I do not necessarily agree.

RPL, which is probably a protocol of choice for such environment, defines Objective functions that handle metric interpretation and some logic to tie multiple metrics and policies together.
I'd think that as long as we stay at the abstract (interface) level we can push some hints to an existing OF to twist its behavior, and tell RPL to support a new instance based on a new OF that needs to be installed.

There is probably a way to define:
- an abstract interface between RPL and the OF so that we can dynamically plug an OF in.
- abstract behavior specifications on which metric are supported and how they are handled (eg additive, weighted, etc) by an existing OF so we can tune the graph generation.
- abstract policies specifications so we can control peering, size, power, you name it.

What do you think?

Cheers,

Pascal

From: coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: vendredi 8 juin 2012 15:02
To: Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org
Subject: Re: [Coma] Reprogramming Protocols

Hi Jonathan,

this could be seen under the SW/firmware distribution, however reprogramming protocol code is a device specific logic and not a management task.

Cheers,
Mehmet

From: coma-bounces@ietf.org<mailto:coma-bounces@ietf.org> [mailto:coma-bounces@ietf.org]<mailto:[mailto:coma-bounces@ietf.org]> On Behalf Of ext Jonathan.Hansford@generaldynamics.uk.com<mailto:Jonathan.Hansford@generaldynamics.uk.com>
Sent: Friday, June 08, 2012 2:38 PM
To: coma@ietf.org<mailto:coma@ietf.org>
Subject: [Coma] Reprogramming Protocols

Hi,

One thing that hasn't yet been mentioned (unless I missed it) is the issue or reprogramming protocols for adding new applications or modifying/patching existing applications/firmware. I imagine this is of particular interest in Sensor Nets but may also be beneficial in other scenarios. Will this also be considered within coma?

Thanks,

Jonathan

________________________________
This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.