Re: [Coma] Possible topics?

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

Hi Ulrich,

your comments and suggestions are valuable. See below for a few
comments.

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

I think we should list the relevant topologies, use cases and scenarios
for management first. Deriving the requirements would be than more easy.
 
> >
> >> - 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).

Yes, Manet-like networks are also in scope for this discussion. Power
and bandwidth consumption are important criteria in a network of
constrained devices. These criteria has implications on the efficiency
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.

Multicast is an essential mechanism e.g. in M2M scenarios. Let's discuss
it further whether a reliable multicast should be a requirement.
 
> >> - 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>, ...").

Agree, we need such a classification at least as a hint on what is
possible to integrate into the device. E.g. SSH might not be possible
because of the code size. DTLS is more compact.

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

And a frequent message exchange results to more energy consumption,
which is bad. We might need a light version of energy monitoring which
could result to a dynamic definition of the message exchange frequency.
 
> >> - 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.

Excellent point. The optimal case would be if the mapping is pretty easy
like between HTTP and CoAP. If the constrained device uses any light
version of the protocol which is already in use in the core network this
would be perfect. However, it is not that easy to use a reduced version
of SNMP or Netconf together with the application logic etc. in one
C1-device with little memory.

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

This is exactly what we should do as a first step.
 
> > 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.

It is too early to think on a BoF. Let's do a gap analysis at the end
and point to new work. Let's see how much work is necessary to do and
where it belongs to. I assume the rest will be then discussed in
OPS-DIR, Core WG or a Bar BoF. As you know IETF does only work which can
be defined concretely and happens soon. If we don't know how to do it,
it belongs to IRTF or somewhere else.
  
> Best
> Ulrich

Cheers,
Mehmet