Subject: [Coma] Possible topics?

From: Ulrich Herberg <[email-masked]>
Date: Thu, 7 Jun 2012 14:26:48 -0700

Hi,

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.
- Should we support a distributed approach or a enforce a centralized
NMS? (or support both modes of operation?)
- Which transport protocols do we want to use? TCP/UDP or something like COAP?
- Do we need efficient, reliable multicast (like NORM, but
lightweight) to distribute control traffic more efficiently?
- Can we provide sufficient levels of security without putting too
much burden on constrained devices? Which authentication modes do we
need?
- 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?
- Will there be a mapping to existing management protocols like SNMP
for border gateways?
- 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?)

Best
Ulrich

[Coma] Subject: New Non-WG Mailing List: coma -- Management of
Constrained Networks and Devices

    From: IETF Secretariat <ietf-secretariat at ietf.org>
    To: IETF Announcement List <ietf-announce at ietf.org>
    Cc: bclaise at cisco.com, coma at ietf.org
    Date: Wed, 16 May 2012 10:39:36 -0700
    List-id: Management of Constrained Networks and Devices <coma.ietf.org>

A new IETF non-working group email list has been created.

List address: coma at ietf.org
Archive:  http://www.ietf.org/mail-archive/web/coma/
To subscribe:  https://www.ietf.org/mailman/listinfo/coma

Purpose: This list is for the discussion related to the management of
constrained networks and devices. The IETF so far has not developed
specific technologies for the management of constrained networks.
There is a need to
understand the requirements for the management of such a constrained
network and its devices.

For additional information, please contact the list administrators.

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 8 Jun 2012 13:27:07 +0200

Hi Ulrich,

> (and manage) the performance of a whole network, rather than just a

Our aim is to look also at constrained networks and groups of devices.

> NMS? (or support both modes of operation?)

Based on the size and type of the network both approaches could make
sense.

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

> terms of memory? CPU? network connection?)

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

> Ulrich

Cheers,
Mehmet
  
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 8 Jun 2012 14:30:57 -0700

Hi Mehmet,

please see my answer inline.

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

> Based on the size and type of the network both approaches could make

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

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

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

>> much burden on constrained devices? Which authentication modes do we

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

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

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.

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

> stating why you think these should be requirements on constrained

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

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Jun 2012 19:50:41 +0200

Hi Ulrich,

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

> for management. In the SNMP world, that is somewhat simpler

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

> information on the (constrained) device, or having a more frequent

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.
 
> 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 already discussed in some of the other email threads).

This is exactly what we should do as a first step.
 
> the intention to consider having a BOF later on? I think that would be

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.

Cheers,
Mehmet