Re: [Coma] Possible topics?

[Ulrich Herberg <[e-mail]>]

Hi Mehmet,

please see my answer inline.

On Fri, Jun 8, 2012 at 4:27 AM, Ersue, Mehmet (NSN - DE/Munich)
<[e-mail]> wrote:
> Hi Ulrich,
>
>> I just discovered this mailing list. Some aspects I have in mind about
>> the topic of managing constrained devices and networks:
>>
>> - Do we actually manage single devices or whole networks (or groups of
>> devices)? At least in MANETs, it may be of equal interest to monitor
>> (and manage) the performance of a whole network, rather than just a
>> single router.
>
> Our aim is to look also at constrained networks and groups of devices.

That is good, and I think very important. My background is in MANETs
and LLNs, where I think such a thing is missing but very important.
IMO, it would be very valuable to both monitor and manage whole
networks. Two examples could be:
  - Change a router parameter for several routers at the same time
(instead of multiple unicast connections
  - Acquire state or (performance-related) statistics from a group of
routers. E.g., in MANETs, the information from a single router may not
give enough information about bottlenecks, inefficiencies etc. of the
whole network.


>
>> - Should we support a distributed approach or a enforce a centralized
>> NMS? (or support both modes of operation?)
>
> Based on the size and type of the network both approaches could make
> sense.

I also think this is reasonable. A distributed approach is, of course,
much more difficult to do right, but would be very interesting in
cases where no single NMS is part of the network architecture. In
order to generalize this requirement, it seems to me that there could
be a discussion about different use cases, scenarios and topologies
for management. In the SNMP world, that is somewhat simpler
(client/server).


>
>> - Which transport protocols do we want to use? TCP/UDP or something
> like COAP?
>
> As Benoit stated we are talking on requirements and not on solutions;
> especially we will not propose to use a specific protocol or solution.

Right, that is certainly a good idea to start with requirements first.
So, let me have another try:
- A requirement is that a management protocol for constrained devices
supports light-weight transport protocols, both in terms of code
complexity and suitability for constrained channels.
In LLNs and MANETs, TCP is known to not perform well, which was one of
the reasons to develop COAP. (I assume that other types of networks
are also in scope for this discussion, but nevertheless, we may want
to discuss requirements of the transport layer).

>
>> - Do we need efficient, reliable multicast (like NORM, but
>> lightweight) to distribute control traffic more efficiently?

Let me elaborate on this one a bit more. Let's assume that a network
operator wants to set a parameter on 10 routers at the same time. One
could of course establish 10 unicast connections to each router and
set the parameter. But (in particular with regards to inefficiency of
TCP in mesh networks), that may not be feasible. For monitoring
performance or state of a larger number of networks, multicast could
also be useful. I am not sure if multicast operations should be
reliable, but in some scenarios that may be required.

>> - Can we provide sufficient levels of security without putting too
>> much burden on constrained devices? Which authentication modes do we
>> need?

I think that security will be a major point in this discussion. The
problem with security is that it always comes at a cost (code
complexity, CPU resource requirements for de-/encryption, memory
requirements, message overhead). If we have a classification of
devices with regards to their resources, maybe we should have some
conformance requirements for security in each device class? (e.g.,
"class 0 devices MUST support <low-level-of-security>, class devices 1
MUST in addition support <higher-level-of-security>, ...").


>> - Should there be a proxy functionality like RMON (or something like
>> the currently developed REPORT-MIB in MANET), in order to record
>> performance related values locally and then send to a NMS later?

The REPORT-MIB is currently under development in the MANET group. The
idea was essentially that we want to collect performance related (or
other kinds of) information on a router over time, and then return it
to a management station for evaluation, without the need to
periodically poll the router. It is a tradeoff between storing such
information on the (constrained) device, or having a more frequent
message exchange.


>> - Will there be a mapping to existing management protocols like SNMP
>> for border gateways?

I think that this would be extremely important. Since SNMP and NETCONF
are already widely used, some kind of mapping would allow
compatibility and end-to-end information exchange. Of course, it would
be some work to create such mappings. It could also be challenging
with regards to (end-to-end) security.


>> - Is there any assumption for this work about the reliability of the
>> channel, the kind of the link layer (e.g., wireless/wired), mobility
>> etc? Or is the only assumption that the devices are "constrained" (in
>> terms of memory? CPU? network connection?)

I believe this is important for several of the above mentioned issues
(e.g., requirements for transport protocols, limitations for security
overhead on messages etc). I suggest that before we dig into all the
requirements, we need to get a clear idea which kinds of networks and
devices we want to consider, and what "constrained" means (the latter
is already discussed in some of the other email threads).

> Good questions. It would be helpful if you could start a discussion by
> stating why you think these should be requirements on constrained
> networks.

I hope that helped to make this (certainly non-exhaustive) list
clearer. I suggest that we first come up with more requirements,
filter out those we believe are interesting and then classify them
into different topics. If some of the mailing list participants find a
few of the above listed items interesting, I could move (some of) them
into a separate email thread each for making it easier to read.

I have not followed the mailing list since the very beginning, but is
the intention to consider having a BOF later on? I think that would be
a good idea.

Best
Ulrich