Re: [Coma] Reprogramming Protocols

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

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
network.

 

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):
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-01 

Comments are welcome.

 

Cheers, 
Mehmet 

 

From: ext Pascal Thubert (pthubert) [mailto:[e-mail]] 
Sent: Tuesday, July 17, 2012 8:48 AM
To: Ersue, Mehmet (NSN - DE/Munich);
[e-mail]; [e-mail]
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
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: [e-mail] [mailto:[e-mail]] On Behalf Of
Ersue, Mehmet (NSN - DE/Munich)
Sent: vendredi 8 juin 2012 15:02
To: [e-mail]; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of
ext [e-mail]
Sent: Friday, June 08, 2012 2:38 PM
To: [e-mail]
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.