Subject: Re: [Coma] Reprogramming Protocols

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Jul 2012 06:48:08 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: vendredi 8 juin 2012 15:02
To: [email-masked]; [email-masked]
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: Friday, June 08, 2012 2:38 PM
To: [email-masked]<mailto:[email-masked]>
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.

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 17 Jul 2012 12:09:38 +0200

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:[email-masked]] 
Sent: Tuesday, July 17, 2012 8:48 AM
To: Ersue, Mehmet (NSN - DE/Munich);
[email-masked]; [email-masked]
Subject: RE: [Coma] Reprogramming Protocols

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.

- 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: [email-masked] [mailto:[email-masked]] On Behalf Of
Ersue, Mehmet (NSN - DE/Munich)
Sent: vendredi 8 juin 2012 15:02
To: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Friday, June 08, 2012 2:38 PM
To: [email-masked]
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.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 17 Jul 2012 09:27:44 -0700

Hi,

I agree with Mehmet. I don't see how this is related to management of
networks and devices. RPL is a routing protocol, not a network management
protocol.

Best
Ulrich

On Tue, Jul 17, 2012 at 3:09 AM, Ersue, Mehmet (NSN - DE/Munich) <
[email-masked]> wrote:

> 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.*
> ***
>
> ** **
>
> management of networks with constrained devices.****
>
> ** **
>
> 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.****
>
> ** **
>
> http://tools.ietf.org/html/draft-ersue-constrained-mgmt-01 ****
>
> Comments are welcome.****
>
> ** **
>
> Cheers,
> Mehmet ****
>
> ** **
>
> *From:* ext Pascal Thubert (pthubert) [mailto:[email-masked]]
> *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 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.****
>
> 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:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Ersue, Mehmet (NSN - DE/Munich)
> *Sent:* vendredi 8 juin 2012 15:02
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [Coma] Reprogramming Protocols****
>
> ** **
>
> Hi Jonathan,****
>
> ** **
>
> reprogramming protocol code is a device specific logic and not a management
> task.****
>
> ** **
>
> Cheers,
> Mehmet ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext [email-masked]
> *Sent:* Friday, June 08, 2012 2:38 PM
> *To:* [email-masked]
> *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
> scenarios. Will this also be considered within coma?****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Jonathan****
>
> ** **
> ------------------------------
>
> 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. ****
>
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma
>
>