Subject: [coman] Device Classes?

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 02 Apr 2014 09:43:51 +0200

A question out of curiosity:

The LWIG terminology document defines classes of devices and makes
statements about what can and cannot be done for each class.

IMHO these classes are about end devices rather than constrained routers
and switches. Guys in the network management environment seem to care a
lot about the management of network nodes.

What are the expectations about RAM, flash size, CPU requirements, etc.
for these constrained routers/switches?

Ciao
Hannes

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 3 Apr 2014 22:47:16 -0700

Hannes,

I would really like a solution which allows monitoring and management of C1
devices [1]. If built around protocols which have been designed for these
types of devices (e.g. CoAP), I don't believe adding this functionality to
a node will have a large impact on code footprint.

What do others think?

Thomas

[1] http://tools.ietf.org/html/draft-ietf-lwig-terminology-07#section-3

On Wed, Apr 2, 2014 at 12:43 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> coman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coman
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Apr 2014 09:24:27 +0200

On 02 Apr 2014, at 09:43, Hannes Tschofenig <[email-masked]> wrote:

> and switches.

Actually, the device classes are about nodes in general (hosts and routers).  The document then goes on to say:

   (An alternative name, when the properties as a network node are not
   in focus, is "constrained device”.)

Protocols such as RPL take great care to enable the use of class-1 devices as routers (non-storing mode).
Constrained management will need to match that.

A more important dichotomy than host vs. router may be monitoring vs. configuration.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2014 11:04:41 +0200

Hi Carsten,

I am getting more and more uncomfortable with these classes due to the
fuzzy definition.

I wonder whether someone has tried to implement a router with
* an IPv6 stack
* RPL
* security stuff (such as DTLS, EAP, PANA)
* network management protocol (as Thomas was asking for)
* CoAP
* DNS
* software update mechanism
* + the actual application

on a class 1 device.

Ciao
Hannes

---

From: "Sehgal, Anuj" <[email-masked]>
Date: Fri, 4 Apr 2014 09:55:55 +0000

Hi,

> * + the actual application

After fitting all this in, there really is no space left for security (DTLS, etc.). 

Fitting DNS should not be too complicated provided we knock off something from this list (either CoAP or network management protocol, SNMP in our case), but I say this based on experience with an mDNS implementation we did a few years ago that works on AVR Raven devices (closer to Class 2). 

In general, a basic Contiki 2.6 system (minus CoAP from above) takes up about 85% of Flash and statically allocated RAM on a TelosB (Class 1). Adding CoAP and a network management protocol will push this further, with nearly no space left. In fact, if the data model is too large or complicated for the network management protocol, then chances are that it too would not fit either. Similar constraints apply to CoAP as well. Working with CoAP up to Contiki 2.6, while using TelosB (Class 1), was also quite a struggle. At best we were able to work with a handful of resources, since the amount of memory left over was not too much.

I have not checked while writing this email, but at least in the past it was the RPL implementation that would take a significant amount of resources. This was largely due to non-storing mode not being implemented, but it would seem that Contiki 2.7 does have the option to enable non-storing mode. This might help reduce resource consumption further.

When we attempted an implementation of DTLS, we used the AVR Raven (Class 2) because TelosB (Class 1) did not have enough resources to function with it.

Regards,
Anuj

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Apr 2014 12:25:18 +0200

> * + the actual application

Well, that exactly is the problem.
The biggest issue here is the software update mechanism, if you want that to work over the air.
(Generally, to make a full over the air software update work on a system with in-place execution from Flash and very small amounts of RAM you need to structure the Flash-based code in a very special way.)
Apart from that, leave out EAP/PANA, DNS, and this is doable.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2014 13:32:52 +0200

For me the software update mechanism is extremely important since it is
not just a way to replace the entire firmware but also to provision
certain protocol parameters.

For example, in the DICE DTLS Profile document there are various
information elements that may need to be changed over the lifetime of
the device, such as trust anchors and CRL-related information.

You also cannot omit EAP/PANA from that list since many devices will
likely need to have a way to authenticate to the network. Of course,
with a properly chosen EAP method the additional code requirements can
be kept fairly small but it will not be zero.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Apr 2014 14:08:38 +0200

> certain protocol parameters.

Provisioning protocol parameters is one CoAP PUT to the right resource.  Cf. OMA LWM2M.
(They also do define a firmware update mechanism, but that seems to presume the device has space for a complete firmware image.)

Replacing the software that is running during the software update is the fun part, and that is somewhat expensive to support (add the requirement for a rollback capability for a realistic scenario).

> likely need to have a way to authenticate to the network.

If you want to do this the SEP2.0 way, you need EAP/PANA.
(SEP2.0 is targeting class-2+, not class-1.)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2014 13:45:47 +0200

Hi Carsten.

> (They also do define a firmware update mechanism, but that seems to presume the device has space for a complete firmware image.)

That is exactly the question I raised when it comes to network management.

I don't understand what network management protocol add beyond what is
already there with CoAP.

Of course, you could replace CoAP entirely with SNMP (as Juergen had
suggested).

> Replacing the software that is running during the software update is the fun part, and that is somewhat expensive to support (add the requirement for a rollback capability for a realistic scenario).
Sure. Software updates are not fun.

> (SEP2.0 is targeting class-2+, not class-1.)

With devices that are in direct connection with each other you could
argue that there is no need for DTLS and alike since you will have to
deal with the pairing procedure at the lower layer. Many devices fall
into that category.

If that's not the case I believe you cannot assume that no network
access authentication will be needed.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2014 13:48:36 +0200

Hi Anuj,

Thanks for the feedback. Your data confirmed my guess.

To me it would make sense to make different assumptions about end
devices and routers since they have different requirements. For a router
I might even be convinced that network management protocols are useful
but I am not at all convinced that end devices should run them.

Also, as I argued on other lists before I see a lot of overlap between

* network management when also used to retrieve the actual data of the
application (+ the management of the software)

* CoAP

(when a software update mechanism has to be implemented anyway).

If we ever want any interoperability then the approach of letting
thousand flowers bloom isn't going to work very well.

Sometimes saying "no" to some protocols is a good thing. (Btw, I am also
included to say no to all the IPsec/IKEv2 efforts for constrained devices.)

Ciao
Hannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Apr 2014 15:04:09 +0200

> Of course, you could replace CoAP entirely with SNMP (as Juergen had

I did not suggest to replace CoAP with SNMP. What I said is:

1) We have done an SNMP only implementation and we know it works and
   what the resource consumption is.

2) I see potential in a RESTCONF to CoAP mapping for devices that do
   CoAP.

3) I agree with the desire to keep code down to a minimum and thus to
   keep the number of protocols needed to a minimum.

4) In our experience, the biggest chunk of code and memory goes to
   security and in particular crypto algorithms. Being able to exploit
   crypto hardware is a major plus as is using the same security and
   crypto mechanisms for all protocols supported.

It would be really nice if we would all have a common understanding of
what roughly the code and storage requirements of the various
protocols involved are. Is LWIG producing something a kind of a survey
like this? If so, this would be great I think.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Apr 2014 15:49:08 +0200

> I don't understand what network management protocol add beyond what is

Assuming we continue to use the client-server model of network management, to use CoAP for this we need to define

1) What are the URIs that can be used for management?  How does the client learn them (combination of discovery, URI templates, HATEOAS)?

2) What are the representations being exchanged (data format, data modeling method).

3) What is the security model.

There has been a strong argument that we should not start from scratch with (2) (and probably not entirely with (1) either), even if we are not using the other parts of existing management protocols.

Proposals to address (1) and (2) are, for instance:
http://tools.ietf.org/html/draft-vanderstok-core-comi-03
http://www.tzi.de/~cabo/noms2014.pdf

(My assumption is that ACE will be good enough to cover (3); we’ll have to make sure the lessons learned from management security go into ACE.)

> Of course, you could replace CoAP entirely with SNMP

SNMP is a bit more specialized and will not fit all applications that CoAP is designed to cover.
But, yes, SNMP has been used successfully as an application protocol in certain environments.

> deal with the pairing procedure at the lower layer. Many devices fall

(Defining single-hop security only is not very useful for the Internet of Things.)

> access authentication will be needed.

Indeed, most wireless networks will need network access control.  
Maybe there are ways to authorize (!) access to a network that are more appropriate for the Internet of Things.
But this is outside the scope of COMAN.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Apr 2014 17:16:43 -0700

On Fri, Apr 4, 2014 at 6:49 AM, Carsten Bormann <[email-masked]> wrote:

> >> (They also do define a firmware update mechanism, but that seems to
> presume the device has space for a complete firmware image.)
> >
> 1) What are the URIs that can be used for management?  How does the client
> learn them (combination of discovery, URI templates, HATEOAS)?
>
RESTCONF addresses (1) and (2).
It replaces HATEOAS with YANG in order to be extensible,
modular, and predictable. The target use-case is programmatic
control.  HATEOAS seems more appropriate when human eyeballs and
brain power are part of the state machine.

IMO YANG would be a better long-term decision than SMIv2.
It may seem that features like custom operations are too
heavy-weight and over-kill for constrained networks, but it
could be just the opposite.  Custom operations allow expensive
generic operations to be condensed and 'packaged' to be as
small as possible.

> There has been a strong argument that we should not start from scratch
> with (2) (and probably not entirely with (1) either), even if we are not
> using the other parts of existing management protocols.
>
> (My assumption is that ACE will be good enough to cover (3); we'll have to
> make sure the lessons learned from management security go into ACE.)
>

Andy

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 4 Apr 2014 21:01:16 -0700

Andy, all,

If CoAP is already in nodes for the applications running on, you have a
monitoring/management solution almost for free. Want to monitoring the
state of some attribute of your protocol? Use CoAP observe. Want to change
a parameter of your protocol? CoAP PUT. On top of that, the work from
CORE/DICE/DTLS/ACE, will ensure security, including authentication and
authorization of management entities.

For nodes where CoAP is present for the application, proposing an
additional protocol will be a very hard sell.

Of course, as pointed out by Carsten, we need to agree on the resources.
What is the URI, what methods are supported, what's the payload format,
etc. YANG is a data modeling language which enables exactly that. RESTCONF
has a RESTful approach to monitoring/management which is aligned with CoAP.
What we would need is a constrained version of RESTCONF. This could be (and
should be) very simple.

At 6TiSCH, we have started this work, with YANG based data model [1] and a
CoAP-based protocol built around that [2], any URI starting with "/6t" is
to monitoring and manage the 6top sublayer. I believe there would be a huge
benefit to having a more general solution, to which we all agree, i.e. a
CoAPified version of RESTCONF. COMAN looks like the right place to do this.

Thomas

[1] http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-00
[2] http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01

On Fri, Apr 4, 2014 at 5:16 PM, Andy Bierman <[email-masked]> wrote:

>> Assuming we continue to use the client-server model of network
>> management, to use CoAP for this we need to define
>>
>> 1) What are the URIs that can be used for management?  How does the
>> client learn them (combination of discovery, URI templates, HATEOAS)?
>>
>> (My assumption is that ACE will be good enough to cover (3); we'll have
>> to make sure the lessons learned from management security go into ACE.)
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Apr 2014 08:07:07 +0200

> CoAPified version of RESTCONF. COMAN looks like the right place to do this.

Well, what you have in [1] is not really YANG and surely not RESTCONF
either. I think [1] essentially illustrates that having no agreement
(or standard) how to do NM in this space is a problem. Don't get me
wrong, I appreciate the direction of this work but claiming it is a
YANG based data model I think is not quite right.

/js

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 4 Apr 2014 23:59:44 -0700

Juergen,
The goal of this -00 is to kick things off and spark interest beyond
6TiSCH, especially in COMAN. Glad to see this worked and that you agree
with the general direction.
One of 6TiSCH's milestones for August 2014 is to ask for help from "YANG
people". Could I ask you to provide feedback to the authors or the 6TiSCH
ML? The 6top authors are holding a ad-hoc webex discussion on Tuesday [1],
maybe a good first venue for feedback.
Please note that [2] was written specifically because there is
no constrained version of RESTCONF. It doesn't claim to be that, and, if
there were such a thing, we'd be more than happy to consider it.
Thomas

[1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02114.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Apr 2014 09:16:33 +0200

Thomas,

I know pretty much nothing about 6TiSCH. But you should definately
write a complete YANG data model so that tools can be used. You need
to distinguish configuration from state. The term "MIB" does not exist
in the YANG world - or what is the 6top MIB? Since I do not have
IEEE802154e, I can't really make much sense of things (descriptions
like "Defined in IEEE802154e." don't help much).

I am not understanding what 6top commands are (defined by IEEE?) and
how they relate to the YANG fragments. Are you re-modeling command
frames coming from IEEE? If so, what is the value of this? If there is
value in this, why do you not use YANG defined rpcs? In short, I am
confused what problem this document and the YANG fragment are trying
to solve. To me, it looks like you are remodeling 6top and it is
unclear what the value of this is. A section more clearly describing
what the problem is to be solved and how the data model is intended
to be used would be useful.

I won't be able to join the Webex (and I have enough other things I am
late with already...).

/js

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 5 Apr 2014 00:37:07 -0700

Juergen,
Thanks for the feedback.
Thomas

On Sat, Apr 5, 2014 at 12:16 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > > At 6TiSCH, we have started this work, with YANG based data model [1]
> and
> > > a
> > > > to monitoring and manage the 6top sublayer. I believe there would be
> a
> > > huge

---

From: Andy Bierman <[email-masked]>
Date: Sat, 5 Apr 2014 10:08:45 -0700

> additional protocol will be a very hard sell.
It isn't another protocol.
It is a mapping of the RESTCONF data model framework onto CoAP.

A RESTCONF mapping would really just describe what the server was
expected to do wrt/ the content layer.

Andy

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 5 Apr 2014 10:19:03 -0700

Andy,
+1.
I'm meant "proposing an additional protocol *not using CoAP* will be a very
hard sell". I personally believe mapping RESTCONF onto CoAP is a good
approach, sorry if that wasn't clear.
Thomas

On Sat, Apr 5, 2014 at 10:08 AM, Andy Bierman <[email-masked]> wrote:

>
>
>
> On Fri, Apr 4, 2014 at 9:01 PM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Andy, all,
>>
>> At 6TiSCH, we have started this work, with YANG based data model [1] and
>> a CoAP-based protocol built around that [2], any URI starting with "/6t" is

---

From: peter van der Stok <[email-masked]>
Date: Mon, 07 Apr 2014 08:38:33 +0200

> like this? If so, this would be great I think.

+1
Peter van der Stok

---

From: Paul Duffy <[email-masked]>
Date: Mon, 07 Apr 2014 11:57:06 -0400

>     what the resource consumption is.

Please more detail?  SNMP version?  Security? Implemented MIBs, etc?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Apr 2014 19:28:46 +0200

> Please more detail?  SNMP version?  Security? Implemented MIBs, etc?

http://dx.doi.org/10.1109/MCOM.2012.6384464
http://dx.doi.org/10.1109/GreenCom.2012.21
http://dx.doi.org/10.1007/978-3-642-21484-4_13

In short, we implemented all three versions of SNMP including USM
security. We also did our own DTLS implementation but did not find the
time to integrate it into the SNMP code. Anyway, if you do security in
software, this is a big hit - far bigger than the protocol stuff.

Concerning MIBs, we did a bit of the IF-MIB, the LOWPAN-MIB and the
RPL-MIB plus bits and pieced of the ENTITY-MIB and the
ENTITY-SENSOR-MIB (the later we used to expose an energy sensor
attached to a mote).

Fitting all the MIB modules plus SNMPv3 on the modes is getting tough
since RPL eats quite some resources (but things may have improved
meanwhile).

/js

PS: No additional standards were needed to do any of the SNMP stuff. ;-)