Re: [Coma] Reprogramming Protocols

"Ersue, Mehmet (NSN - DE/Munich)" <> Tue, 17 July 2012 10:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED47121F85C0 for <>; Tue, 17 Jul 2012 03:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.272
X-Spam-Status: No, score=-106.272 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hRfQ19pzaMoI for <>; Tue, 17 Jul 2012 03:09:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8534421F855B for <>; Tue, 17 Jul 2012 03:09:00 -0700 (PDT)
Received: from ([]) by ( with ESMTP id q6HA9h4g002114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jul 2012 12:09:43 +0200
Received: from ([]) by ( with ESMTP id q6HA9hBf007707; Tue, 17 Jul 2012 12:09:43 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jul 2012 12:09:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6404.46BFE66D"
Date: Tue, 17 Jul 2012 12:09:38 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Coma] Reprogramming Protocols
Thread-Index: Ac1Fc5UBo1X6J4eTSCi4A/yrOIdUnAAAlDEAB5xMBUAABl/5UA==
References: <> <> <>
From: "Ersue, Mehmet (NSN - DE/Munich)" <>
To: "ext Pascal Thubert (pthubert)" <>, <>, <>
X-OriginalArrivalTime: 17 Jul 2012 10:09:42.0942 (UTC) FILETIME=[48E7F3E0:01CD6404]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-size: 19771
X-purgate-ID: 151667::1342519783-000055D8-4252E63F/0-0/0-0
Subject: Re: [Coma] Reprogramming Protocols
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jul 2012 10:09:04 -0000

Dear Pascal,


I am wondering whether this has to do with network management. I think
we should differentiate between the management and operation of the


A programmable routing functionality which improves the operational
behavior might be useful but not in our focus. Coma(n) especially raises
the questions on and discusses the use cases and requirements for the
management of networks with constrained devices.


I can imagine policy management as a requirement on the management of
networks with constrained devices. If you think so, please formulate it
and describe the use case from the application pov. However, I think
optimizing routing functionality is on another level.


Please read also the problem statement in -01 draft which hopefully
describes the focus of Coma(n): 

Comments are welcome.




From: ext Pascal Thubert (pthubert) [] 
Sent: Tuesday, July 17, 2012 8:48 AM
To: Ersue, Mehmet (NSN - DE/Munich);;
Subject: RE: [Coma] Reprogramming Protocols


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


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?






From: [] On Behalf Of
Ersue, Mehmet (NSN - DE/Munich)
Sent: vendredi 8 juin 2012 15:02
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.




From: [] On Behalf Of
Sent: Friday, June 08, 2012 2:38 PM
Subject: [Coma] Reprogramming Protocols




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?







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.