Subject: [core] COAP and DHCP

From: "Mani, Mehdi" <[email-masked]>
Date: Wed, 17 Jul 2013 08:10:29 -0700

I'm wondering if in Core WG there has ever been a discussion about obtaining IPv6 address using COAP instead of using DHCP.
In LLN, if we consider that COAP is used as management protocol which configure end-points, why not using that for configuring a node for its IP address. This could be especially interesting to reduce the registration transactions for LLN end-points.

Looking forward to hearing the interesting comments.
Thanks
-Mehdi

---

From: Don Sturek <[email-masked]>
Date: Wed, 17 Jul 2013 09:32:58 -0700

Hi Mehdi,

In lieu of DHCP, why wouldn't a device simply use SLAAC?

Don

From:  "Mani, Mehdi" <[email-masked]>
Date:  Wednesday, July 17, 2013 8:10 AM
To:  "[email-masked]" <[email-masked]>
Subject:  [core] COAP and DHCP

I¹m wondering if in Core WG there has ever been a discussion about obtaining
IPv6 address using COAP instead of using DHCP.
In LLN, if we consider that COAP is used as management protocol which
configure end-points, why not using that for configuring a node for its IP
address. This could be especially interesting to reduce the registration
transactions for LLN end-points.
 
Looking forward to hearing the interesting comments.
Thanks
-Mehdi
_______________________________________________ core mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/core

---

From: Paul Duffy <[email-masked]>
Date: Thu, 18 Jul 2013 13:31:04 -0400

Hi Medhi

What specific advantages do you see in using CoAP versus DHCP for 
address management?

On 7/17/2013 11:10 AM, Mani, Mehdi wrote:
>
> I'm wondering if in Core WG there has ever been a discussion about 
> obtaining IPv6 address using COAP instead of using DHCP.
>
> configure end-points, why not using that for configuring a node for 
> its IP address. This could be especially interesting to reduce the 
> registration transactions for LLN end-points.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Mani, Mehdi" <[email-masked]>
Date: Fri, 19 Jul 2013 07:36:58 -0700

Don,

SLAAC is not efficient in meshed LLNs. First you have to broadcast your neighbor discovery message. Second you have to go through DAD process.
-Mehdi

From: Don Sturek [mailto:[email-masked]]
Sent: mercredi 17 juillet 2013 18:33
To: Mani, Mehdi; [email-masked]
Subject: Re: [core] COAP and DHCP

Hi Mehdi,

Don

From: "Mani, Mehdi" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 17, 2013 8:10 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [core] COAP and DHCP

Looking forward to hearing the interesting comments.
Thanks
-Mehdi
_______________________________________________ core mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/core

---

From: "Mani, Mehdi" <[email-masked]>
Date: Fri, 19 Jul 2013 07:44:13 -0700

Paul,
To answer to your question let's look at the whole process a node should go through to be registered with a meshed LLN:

1)      First it should go through link discovery

2)      Authentication (802.1x)

3)      Route establishment (for instance RPL)

4)      DHCPv6

5)      Register with network management system (COAP) to obtain configuration parameters etc.

I'm looking at these steps and see that IPv6 assignment is as well a kind of configuration why not doing that via COAP and skip one step; keeping in mind that each of these 5 step transactions need message exchange which is a burden on LLN node and network.
-Mehdi

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Duffy
Sent: jeudi 18 juillet 2013 19:31
To: [email-masked]
Subject: Re: [core] COAP and DHCP

Hi Medhi

What specific advantages do you see in using CoAP versus DHCP for address management?

_______________________________________________

core mailing list

[email-masked]<mailto:[email-masked]>

---

From: Don Sturek <[email-masked]>
Date: Fri, 19 Jul 2013 07:45:15 -0700

Hi Mehdi,

We used SLAAC for ZigBee IP and did not find it "inefficient".   First, the
neighbor advertisements are 1 hop broadcasts.   The DAD process was not an
issue since you form your proposed address and send it to the border router
which either approves/disapproves of the address (failure means you try
again).

I don't see how CoAP would make this process more efficient

Don

From:  "Mani, Mehdi" <[email-masked]>
Date:  Friday, July 19, 2013 7:36 AM
To:  Don Sturek <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  RE: [core] COAP and DHCP

Don,
 
SLAAC is not efficient in meshed LLNs. First you have to broadcast your
neighbor discovery message. Second you have to go through DAD process.
-Mehdi

Hi Mehdi,

Don

---

From: Paul Duffy <[email-masked]>
Date: Fri, 19 Jul 2013 11:06:11 -0400

Of the entire example flow you have described, the DHCPv6 overhead is 
but a small piece.  Its a binary encoding moved over UDP, and Rapid 
Commit will usually limit the exchange to a single request/response.  
DHCP is often further used to provide other bootstrap details to the 
device ... like the address of the management system.

Cheers

On 7/19/2013 10:44 AM, Mani, Mehdi wrote:
>
> Paul,
>
> To answer to your question let's look at the whole process a node 
> should go through to be registered with a meshed LLN:
>
> 1)First it should go through link discovery
>
> 2)Authentication (802.1x)
>
> 3)Route establishment (for instance RPL)
>
> 4)DHCPv6
>
> 5)Register with network management system (COAP) to obtain 
> configuration parameters etc.
>
> I'm looking at these steps and see that IPv6 assignment is as well a 
> kind of configuration why not doing that via COAP and skip one step; 
> keeping in mind that each of these 5 step transactions need message 
> exchange which is a burden on LLN node and network.
>
> -Mehdi
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Paul Duffy
> *Sent:* jeudi 18 juillet 2013 19:31
> *To:* [email-masked]
> *Subject:* Re: [core] COAP and DHCP
>
> Hi Medhi
>
>     In LLN, if we consider that COAP is used as management protocol
>     which configure end-points, why not using that for configuring a
>     node for its IP address. This could be especially interesting to
>     reduce the registration transactions for LLN end-points.
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Mani, Mehdi" <[email-masked]>
Date: Mon, 22 Jul 2013 03:26:48 -0700

Hi Don,

It really is a matter of size of the network and the application. There are scenarios with limited number of nodes in a network where SLAAC can work but in the populated meshed LLNs, DAD process is really inefficient and it is  preferable that a server assigns the IP addresses to the nodes since the probability of address conflict in SLAAC is high. Moreover the server can assign the addresses which can be compressed more efficiently by 6LowPan. What I'm saying is that if COAP is going to be standardized as a protocol for managing/configuring LLNs and has the ability of service/resource discovery, why not using that as well for address assignment.

-Mehdi

From: Don Sturek [mailto:[email-masked]]
Sent: vendredi 19 juillet 2013 16:45
To: Mani, Mehdi; [email-masked]
Subject: Re: [core] COAP and DHCP

Hi Mehdi,

We used SLAAC for ZigBee IP and did not find it "inefficient".   First, the neighbor advertisements are 1 hop broadcasts.   The DAD process was not an issue since you form your proposed address and send it to the border router which either approves/disapproves of the address (failure means you try again).

Don

From: "Mani, Mehdi" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 19, 2013 7:36 AM
To: Don Sturek <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] COAP and DHCP

Don,

From: Don Sturek [mailto:[email-masked]]
Sent: mercredi 17 juillet 2013 18:33
To: Mani, Mehdi; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] COAP and DHCP

Hi Mehdi,

Don

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 22 Jul 2013 20:03:50 +0900

Dear Mehdi,

I think if LLN nodes require some 'rich system-wide configuration' (an example is MPL parameter), something like CoAP resource binding to DHCPv6 option settings may work as replacement of stateless DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN devices). However, I have no idea on how to let clients know default CoAP server address to send 'Information-request' messages to.

Regards,

Yusuke

(2013-07-18 00:10), Mani, Mehdi wrote:
> I’m wondering if in Core WG there has ever been a discussion about obtaining IPv6 address using COAP instead of using DHCP.
>

---

From: "Mani, Mehdi" <[email-masked]>
Date: Mon, 22 Jul 2013 06:19:03 -0700

Hi Yusuke,

It is in fact one of the advantages to get rid of DHCP codes on LLN end-point. I don't know either if COAP is able to provide a kind of autonomous service discovery for LLN devices but it could be one of the interesting aspects that can be added to COAP feature; especially that COAP is supposed to help the end-points with their resource and service discovery.

Thanks
-Mehdi

-----Original Message-----
From: Yusuke DOI [mailto:[email-masked]] 
Sent: lundi 22 juillet 2013 13:04
To: Mani, Mehdi
Cc: [email-masked]
Subject: Re: [core] COAP and DHCP

Dear Mehdi,

Regards,

Yusuke

---

From: Don Sturek <[email-masked]>
Date: Mon, 22 Jul 2013 07:11:46 -0700

Hi Mehdi,

I did see your earlier post regarding address assignment via CoAP.....

I have to say, I think it is not wise to overload address assignment on
CoAP (which is really an application support protocol).   CoAP does
support service discovery on ".well-known" (sorry if I got the syntax
wrong, this is from memory).   If a richer service discovery is
wanted/needed, we should consider adding in a different standard rather
than try to add those features directly into CoAP.

Don

On 7/22/13 6:19 AM, "Mani, Mehdi" <[email-masked]> wrote:

>Hi Yusuke,
>
>It is in fact one of the advantages to get rid of DHCP codes on LLN
>end-point. I don't know either if COAP is able to provide a kind of
>autonomous service discovery for LLN devices but it could be one of the
>interesting aspects that can be added to COAP feature; especially that
>COAP is supposed to help the end-points with their resource and service
>discovery.
>
>Thanks
>-Mehdi
>
>
>I think if LLN nodes require some 'rich system-wide configuration' (an
>example is MPL parameter), something like CoAP resource binding to DHCPv6
>option settings may work as replacement of stateless DHCPv6 (to get rid
>of stateless DHCP code from CoAP-based LLN devices). However, I have no
>idea on how to let clients know default CoAP server address to send
>'Information-request' messages to.
>
>Regards,
>
>Yusuke
>
>>configure end-points, why not using that for configuring a node for its
>>IP address. This could be especially interesting to reduce the

---

From: Zach Shelby <[email-masked]>
Date: Mon, 22 Jul 2013 17:42:38 +0300

Mehdi,

I agree with Don here, it is not a great idea to mix basic IP network configuration services over a generic web protocol like CoAP.  We can't really depend on having CoAP available to do something basic like address assignment. That needs to work even when no application layer is present, e.g. in a pure router. That said, we surely can manage a device, e.g. perform firmware updates, update application configuration parameters etc. over CoAP. For example the OMA Lightweight M2M standard does exactly this over CoAP using Object definitions (like a MIB). That works great for things that are independent of the IP network.

The discovery built into CoAP is meant to be used for resource discovery, i.e. discovering what web resources a CoAP server has available. It was not designed to be used as a generic service discovery mechanism. If you don't even know what protocol to use for your service, then you probably need something like DNS-SD first.

Regards,
Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: DOI Yusuke <[email-masked]>
Date: Tue, 23 Jul 2013 01:06:08 +0900 (JST)

Dear Zach, Don,

I also agree it would be not a good idea to do address configuration over CoAP. But I think, especially for SLAAC-based LLNs, we don't have a handy channel to distribute non-essential configurations, such as DNS server address or MPL parameters to be used in the network. DNS-SD could not be a good choice for, to say, 1000 nodes of LLN with 5 hops or more.

The choice in my mind is to deploy DHCP-relay over nodes and to use stateless DHCP to distribute such configuration parameters. It should work well and I'm okay with it (so far, not tried to implement it yet). At the same time I wonder if there is other choices such as Stateless-DHCP-Option-to-CoAP-Resource mapping. 

Regards,

Yusuke

From: Zach Shelby <[email-masked]>
Subject: Re: [core] COAP and DHCP
Date: Mon, 22 Jul 2013 17:42:38 +0300

---

From: "Mani, Mehdi" <[email-masked]>
Date: Mon, 22 Jul 2013 09:11:27 -0700

Zach,

I also agree that we should not depend only on a generic web protocol like COAP for the basic network configuration services; but we may have such option to use or not to use. I think the process of network discovery and address acquisition in IoT and LLN should be more efficient than what it is today defined for conventional IPv6 networks and end-points. Maybe Core and COAP is not the right place to address this issue. 

The other thing about OMA Lightweight M2M that I didn't get is that you mentioned it is great for things that are independent of IP; but isn't COAP defined to work on IP?

Regards,
-Mehdi

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: lundi 22 juillet 2013 16:43
To: Don Sturek
Cc: Mani, Mehdi; Yusuke DOI; [email-masked]
Subject: Re: [core] COAP and DHCP

Mehdi,

Regards,
Zach

On Jul 22, 2013, at 5:11 PM, Don Sturek <[email-masked]> wrote:

> wanted/needed, we should consider adding in a different standard 
> rather than try to add those features directly into CoAP.
> 
> Don
> 
> 
> 
>> autonomous service discovery for LLN devices but it could be one of 
>> the interesting aspects that can be added to COAP feature; especially 
>> that COAP is supposed to help the end-points with their resource and 
>> service discovery.
>> 
>> Thanks
>> -Mehdi
>> 
>> 
>> I think if LLN nodes require some 'rich system-wide configuration' 
>> (an example is MPL parameter), something like CoAP resource binding 
>> to DHCPv6 option settings may work as replacement of stateless DHCPv6 
>> (to get rid of stateless DHCP code from CoAP-based LLN devices). 
>> However, I have no idea on how to let clients know default CoAP 
>> server address to send 'Information-request' messages to.
>> 
>> Regards,
>> 
>> Yusuke
>>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 22 Jul 2013 21:52:30 +0300

> I also agree that we should not depend only on a generic web protocol like COAP for the basic network configuration services; but we may have such option to use or not to use. I think the process o…

Exactly. I think we all agree that network bootstrapping can be improved, but CoRE is not the right place. This would be something to bring up in upcoming 6LO WG for example? Do come to Berlin and support that BOF.

> The other thing about OMA Lightweight M2M that I didn't get is that you mentioned it is great for things that are independent of IP; but isn't COAP defined to work on IP?

Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and CoAP for communication of course (although it does support CoAP over SMS too…).The point is that a device management solution over CoAP is great for managing devices and application parameters, and even for monitoring networks. However it isn't a solution for network bootstrapping. Even the deployment scenario is wrong, typically the Lightweight M2M Server is located in a backend server several IP networks removed from the endpoint. 

Regards,
Zach

---

From: Don Sturek <[email-masked]>
Date: Mon, 22 Jul 2013 12:03:00 -0700

Hi Mehdi (and Zach),

In addition to the 6LO BOF that Zach mentioned, there is this draft in
6MAN:
http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-6man-efficient-n
d/

Participating in evolving the above draft on efficient ND within 6MAN
might also be an avenue towards simplifying network bootstrapping
(including address assignment)

Don

On 7/22/13 11:52 AM, "Zach Shelby" <[email-masked]> wrote:

>> I also agree that we should not depend only on a generic web protocol
>>like COAP for the basic network configuration services; but we may have
>>such option to use or not to use. I think the process of network
>>discovery and address acquisition in IoT and LLN should be more
>>efficient than what it is today defined for conventional IPv6 networks
>>and end-points. Maybe Core and COAP is not the right place to address
>>this issue. 
>
>Exactly. I think we all agree that network bootstrapping can be improved,
>but CoRE is not the right place. This would be something to bring up in
>upcoming 6LO WG for example? Do come to Berlin and support that BOF.
>
>> The other thing about OMA Lightweight M2M that I didn't get is that you
>>mentioned it is great for things that are independent of IP; but isn't
>>COAP defined to work on IP?
>
>Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and
>CoAP for communication of course (although it does support CoAP over SMS
>tooŠ).The point is that a device management solution over CoAP is great
>for managing devices and application parameters, and even for monitoring
>networks. However it isn't a solution for network bootstrapping. Even the
>deployment scenario is wrong, typically the Lightweight M2M Server is
>located in a backend server several IP networks removed from the
>endpoint. 
>
>Regards,
>Zach
>
>> Regards,
>> -Mehdi
>> 
>> I agree with Don here, it is not a great idea to mix basic IP network
>>configuration services over a generic web protocol like CoAP.  We can't
>>really depend on having CoAP available to do something basic like
>>address assignment. That needs to work even when no application layer is
>>present, e.g. in a pure router. That said, we surely can manage a
>>device, e.g. perform firmware updates, update application configuration
>>parameters etc. over CoAP. For example the OMA Lightweight M2M standard
>>does exactly this over CoAP using Object definitions (like a MIB). That
>>works great for things that are independent of the IP network.
>> 
>> The discovery built into CoAP is meant to be used for resource
>>discovery, i.e. discovering what web resources a CoAP server has
>>available. It was not designed to be used as a generic service discovery
>>mechanism. If you don't even know what protocol to use for your service,
>>then you probably need something like DNS-SD first.
>> 
>> Regards,
>> Zach
>>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 23 Jul 2013 09:07:03 +0200

Hi all,

I do agree that for interoperability, we should stick to those generally 
accepted standards which are around, proven, and involve the basic IP 
network infrastructure.
In my opinion ND, DNS, DHCP, ..... are part of this infrastructure.

However, things are different when we talk management of devices. Here 
it concerns interoperability between some, possibly private, tool and 
and the nodes belonging to a given management organisation, like the 
campus IT department.
Currently, we do have SNMP and MIBs, where the standardized naming in 
the MIB provides interoperability between nodes from different 
manufacturers and SNMP provides standardized protocol between client and 
servers.

For coap devices, the disadvantage of SNMP, IMO, is that it doubles the 
security handling protocol of CoAP.
Providing a CoAP interface for management, including a coap interface to 
MIBs, will probably reduce the code size on the restricted nodes and 
profits from much available work on MIBs.
New MIBs for MPL, RPL intialization can be standardized and look 
sufficient for these purposes.
A CoAP interface instead of the SNMP interface will help making these 
management data more accessible within the context of the security 
architecture of CoAP.

My draft draft-vanderstok-core-comi-00 discusses two CoAP approaches for 
access to MIBs and future management data, of which one approach should 
be selected.

Concerning service discovery and resource discovery, I am much 
interested in the work that will relate the RD to DNS-SD and the 
proposals coming from the DNSSDext proposed BoF. It is clear that for 
service discovery we need a naming scheme that is interoperable between 
devices from different manufacturers, and the DNS-SD repository of 
service names looks like a good starting point.

Do we want a discussion during coap on these standardization aspects 
concerning the operation, setting-up, initialization, maintenance, and 
commissioning of these LLN devices? Possibly we could come to some 
agreement which aspects are typically within the responsibility of IETF.

Peter

DOI Yusuke schreef op 2013-07-22 18:06:
> Dear Zach, Don,
> 
> I also agree it would be not a good idea to do address configuration
> over CoAP. But I think, especially for SLAAC-based LLNs, we don't have
> a handy channel to distribute non-essential configurations, such as
> DNS server address or MPL parameters to be used in the network. DNS-SD
> could not be a good choice for, to say, 1000 nodes of LLN with 5 hops
> or more.
> 
> The choice in my mind is to deploy DHCP-relay over nodes and to use
> stateless DHCP to distribute such configuration parameters. It should
> work well and I'm okay with it (so far, not tried to implement it
> yet). At the same time I wonder if there is other choices such as
> Stateless-DHCP-Option-to-CoAP-Resource mapping.
> 
> Regards,
> 
> Yusuke
> 
> 
> 
> address assignment. That needs to work even when no application layer 
> is present, e.g. in a pure router. That said, we surely can manage a 
> available. It was not designed to be used as a generic service 
> discovery mechanism. If you don't even know what protocol to use for 
> your service, then you probably need something like DNS-SD first.
> 
> Regards,
> Zach
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jul 2013 09:15:41 +0200

On Tue, Jul 23, 2013 at 09:07:03AM +0200, peter van der Stok wrote:
> 
> For coap devices, the disadvantage of SNMP, IMO, is that it doubles
> the security handling protocol of CoAP.

RFC 5953 details how to run SNMPv3 over DTLS.

/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: Robert Cragie <[email-masked]>
Date: Tue, 23 Jul 2013 13:52:02 +0100

One of the issues is that each protocol which exists for its own reason 
has its own set of configuration information which nodes need to perform 
a function using that protocol. In some respects, other protocols could 
be used to distribute configuration information as they may provide a 
more appropriate vehicle.

There were two occasions which I recall when we were working on ZigBee 
IP where it did seem to make sense to consider using other protocols to 
distribute certain configuration information:

1) Use of PANA to distribute 802.15.4 MAC short address configuration 
information
2) Use of RPL DIO to distribute information typically disseminated using RA

In the case of (1), it seems logical as at the point of authentication, 
a secure delivery mechanism can also be deployed. Therefore, a "blob" of 
configuration information can be easily and securely delivered to a node 
which is being bootstrapped. We even worked through a case whereby the 
802.15.4 MAC short address was delivered using this mechanism and then 
SLAAC used to form the IPv6 address. DAD was not needed due to 
centralised allocation and indeed 6lowpan DAR/DAC was not needed. 
However, this was not adopted primarily for the reason that it was 
considered to be overloading the purpose of PANA and PANA relay to 
provide authentication and to deliver a network key. Whilst that can't 
be disputed, it did demonstrate that the authentication mechanism is a 
logical place for a trusted server to deliver bootstrapping 
configuration information to an authenticated client in a controlled 
manner. Note something like 802.1X/RADIUS could also be used instead - 
it is more the general model of point-to-point of untrusted node to 
enforcement point, then through network to authentication server model. 
As DHCP has the relay model as well, it would also seem appropriate to 
use DHCP. It may even make sense to consider extending DHCP to carry 
authentication traffic, although that may be considered heresy :-).

In the case of (2), the way DIOs are disseminated using the DODAG 
provide a logical way to disseminate information from a root to all 
RPL-aware nodes. Therefore it seemed logical to use RPL to disseminate 
this information throughout the routers in the mesh. Then traditional RA 
could be used between router and host.

Note that neither mechanism was adopted in ZigBee IP because it was 
considered to be overloading the primary purpose of the protocol 
messages. However, it may be worth considering these ideas again 
especially in constrained environments where to some extent any 
reduction in the amount of code and complexity would help. However, in 
both cases, IMHO it is more important to consider the way it is 
delivering or disseminating information than the actual protocol itself 
and to tie that to the configuration data.

With regard to CoAP, I tend to agree with other comments here that it is 
more appropriate for distributing application-layer configuration - and 
that doesn't mean address assignment.

Robert

---

From: "Mani, Mehdi" <[email-masked]>
Date: Tue, 23 Jul 2013 07:01:20 -0700

Robert,

It's interesting what you describe. I also think it is a great idea to get some basic bootstrapping configuration information in the time of authentication. In DHCP you have an authentication option which can be used. 

Finally I hope we find the right place to address bootstrapping process for LLNs and IoT in IETF.
-Mehdi 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: mardi 23 juillet 2013 14:52
To: [email-masked]
Subject: Re: [core] COAP and DHCP

One of the issues is that each protocol which exists for its own reason has its own set of configuration information which nodes need to perform a function using that protocol. In some respects, other protocols could be used to distribute configuration information as they may provide a more appropriate vehicle.

There were two occasions which I recall when we were working on ZigBee IP where it did seem to make sense to consider using other protocols to distribute certain configuration information:

1) Use of PANA to distribute 802.15.4 MAC short address configuration information
2) Use of RPL DIO to distribute information typically disseminated using RA

In the case of (1), it seems logical as at the point of authentication, a secure delivery mechanism can also be deployed. Therefore, a "blob" of configuration information can be easily and securely delivered to a node which is being bootstrapped. We even worked through a case whereby the
802.15.4 MAC short address was delivered using this mechanism and then SLAAC used to form the IPv6 address. DAD was not needed due to centralised allocation and indeed 6lowpan DAR/DAC was not needed. 
However, this was not adopted primarily for the reason that it was considered to be overloading the purpose of PANA and PANA relay to provide authentication and to deliver a network key. Whilst that can't be disputed, it did demonstrate that the authentication mechanism is a logical place for a trusted server to deliver bootstrapping configuration information to an authenticated client in a controlled manner. Note something like 802.1X/RADIUS could also be used instead - it is more the general model of point-to-point of untrusted node to enforcement point, then through network to authentication server model. 
As DHCP has the relay model as well, it would also seem appropriate to use DHCP. It may even make sense to consider extending DHCP to carry authentication traffic, although that may be considered heresy :-).

In the case of (2), the way DIOs are disseminated using the DODAG provide a logical way to disseminate information from a root to all RPL-aware nodes. Therefore it seemed logical to use RPL to disseminate this information throughout the routers in the mesh. Then traditional RA could be used between router and host.

Note that neither mechanism was adopted in ZigBee IP because it was considered to be overloading the primary purpose of the protocol messages. However, it may be worth considering these ideas again especially in constrained environments where to some extent any reduction in the amount of code and complexity would help. However, in both cases, IMHO it is more important to consider the way it is delivering or disseminating information than the actual protocol itself and to tie that to the configuration data.

With regard to CoAP, I tend to agree with other comments here that it is more appropriate for distributing application-layer configuration - and that doesn't mean address assignment.

Robert

On 22/07/2013 17:06, DOI Yusuke wrote:
>>>> the interesting aspects that can be added to COAP feature; 
>>>> especially that COAP is supposed to help the end-points with their 
>>>> resource and service discovery.
>>>>
>>>> Thanks
>>>> -Mehdi
>>>>
>>>>
>>>> to DHCPv6 option settings may work as replacement of stateless 
>>>> DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN 
>>>> devices). However, I have no idea on how to let clients know 
>>>> default CoAP server address to send 'Information-request' messages to.
>>>>
>>>> Regards,
>>>>
>>>> Yusuke
>>>>

---

From: "Mani, Mehdi" <[email-masked]>
Date: Tue, 23 Jul 2013 07:03:22 -0700

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: lundi 22 juillet 2013 20:53
To: Mani, Mehdi
Cc: [email-masked] WG
Subject: Re: [core] COAP and DHCP

I'll be in Berlin and if necessary I can raise this point in 6LO WG.

> The other thing about OMA Lightweight M2M that I didn't get is that you mentioned it is great for things that are independent of IP; but isn't COAP defined to work on IP?

Sorry, I wasn't clear enough. You are right, OMA Lightweight uses IP and CoAP for communication of course (although it does support CoAP over SMS too...).The point is that a device management solution over CoAP is great for managing devices and application parameters, and even for monitoring networks. However it isn't a solution for network bootstrapping. Even the deployment scenario is wrong, typically the Lightweight M2M Server is located in a backend server several IP networks removed from the endpoint. 

Regards,
Zach

>>> DHCPv6 (to get rid of stateless DHCP code from CoAP-based LLN devices).

---

From: Maciej Wasilak <[email-masked]>
Date: Thu, 25 Jul 2013 12:36:49 +0200

Hello Everyone,

I think if we want CoAP to become popular for network device management and
configuration we should market it as "Linux approach". In Linux there is
one big directory tree:

/etc -> device configuration
/home -> user data
/dev -> device status

It is easy to mimic this approach with CoAP: there is one resource tree,
and both application resources and device configuration resources are on
it. And every Linux programmer in the world immediately understands what
it's all about.

Best Regards
Maciek

2013/7/23 Mani, Mehdi <[email-masked]>

> such option to use or not to use. I think the process of network discovery
> and address acquisition in IoT and LLN should be more efficient than what
> it is today defined for conventional IPv6 networks and end-points. Maybe
> Core and COAP is not the right place to address this issue.
>
> mentioned it is great for things that are independent of IP; but isn't COAP
> defined to work on IP?
>
> too...).The point is that a device management solution over CoAP is great
> located in a backend server several IP networks removed from the endpoint.
>
> Regards,
> Zach
>
> > Regards,
> > -Mehdi
> >
> really depend on having CoAP available to do something basic like address
> assignment. That needs to work even when no application layer is present,
> e.g. in a pure router. That said, we surely can manage a device, e.g.
> perform firmware updates, update application configuration parameters etc.
> over CoAP. For example the OMA Lightweight M2M standard does exactly this
> over CoAP using Object definitions (like a MIB). That works great for
> things that are independent of the IP network.
> >
> discovery, i.e. discovering what web resources a CoAP server has available.
> It was not designed to be used as a generic service discovery mechanism. If
> you don't even know what protocol to use for your service, then you
> probably need something like DNS-SD first.
> >
> > Regards,
> > Zach
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jul 2013 16:38:55 +0200

> /etc -> device configuration

/dev is not 'device status'. That said, if CoAP people want to
reinvent network management as well, you may want to take a look at
other stuff done in the past - perhaps there is something to learn
from it (e.g. the notion of separation of config state from
operational state).

/js

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Jul 2013 17:32:09 +0200

On Jul 25, 2013, at 16:38, Juergen Schoenwaelder <[email-masked]> wrote:

> /dev is not 'device status'.

No.  And the analogy also lacks because in a REST world, clients are discovering URIs, while in a UNIX file system, the file system structure is pretty much a given.

> That said, if CoAP people want to

I don't know all "CoAP people", but I hope we don't re-invent as much as we simplify.
Just as CoAP was a radically simplifying, but in the end conservative revisit of the principles of HTTP and the Web, maybe we can do something as radically conservative for network management.  If the CoAP protocol itself turns out to be useful for that, that is great, but it should not be the driving consideration.

Grüße, Carsten

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 08:42:55 -0700

Hi Carsten,

+1 on "Just as CoAP was a radically simplifying, but in the end
conservative revisit of the principles of HTTP and the Web, maybe we can
do something as radically conservative for network management".

I realize that CORE is maybe not the place for this, however, I believe
for IoT that an analagous simplication of SNMP is needed (much like what
CoAP did for HTTP).

Where could these proposals take place?  My fear is that implementers will
stretch CoAP to address network management which will be the wrong thing
to do.

Don

On 7/25/13 8:32 AM, "Carsten Bormann" <[email-masked]> wrote:

>On Jul 25, 2013, at 16:38, Juergen Schoenwaelder
><[email-masked]> wrote:
>
>No.  And the analogy also lacks because in a REST world, clients are
>discovering URIs, while in a UNIX file system, the file system structure
>is pretty much a given.
>
>Just as CoAP was a radically simplifying, but in the end conservative
>revisit of the principles of HTTP and the Web, maybe we can do something
>as radically conservative for network management.  If the CoAP protocol
>itself turns out to be useful for that, that is great, but it should not
>be the driving consideration.
>
>Grüße, Carsten
>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 25 Jul 2013 19:15:24 +0300

> stretch CoAP to address network management which will be the wrong thing

CoAP is great for doing general device management (app configuration, location monitoring, firmware updates, security management etc.), as that is usually an integral function of the same application on a contained device being used for application specific purposes (e.g. a street light). OMA Lightweight M2M enables this kind of functionality using Objects over CoAP. It would not make any sense to deploy yet another protocol on a constrained device for that purpose.

What are the network management needs on a constrained device really? If you only need to do some simple network status monitoring, then by all means just add one more Object to your CoAP endpoint and you are done. There is already a nice Connectivity Monitoring Object defined by OMA that can be used for that purpose.

However I agree with Don for complex network management, e.g. getting into border routers and deep troubleshooting and configuration of multiple protocols, you might need a specialised protocol. But at the same time, running SNMP in a border router is no problem. When do we really need complex network management on a constrained device? 

This thread started with address configuration, and now we're treading on the COMAN discussion. But since we're there... In my opinion there will not be a one-size-fits-all protocol solution for network management on the Internet of Things. For network infrastructure SNMP works just fine, for many Web based devices HTTP is already in use, and yes, for simple constrained devices folks can just use CoAP. What we need is a common way to express a MIB and then easily use that over any of these protocols. That makes network management protocol independent as it should be - and would be a very worthwhile output from the IETF. CORE is not the right place to do that obviously.

Zach

---

From: Don Sturek <[email-masked]>
Date: Thu, 25 Jul 2013 09:26:27 -0700

Hi Zach,

Agree that CoAP works well for general device management.

What I was thinking of is a network of sensors (say on an oil pipleline)
where it would be useful to treat these sensor devices much as you would
as a managed set of devices using SNMP.   Things like alarms (eg, low
battery, etc.), status collection, etc.   For the lower end of device
complexity, it would seem that SNMP might be a bit of overkill.......

Don

On 7/25/13 9:15 AM, "Zach Shelby" <[email-masked]> wrote:

>CoAP is great for doing general device management (app configuration,
>location monitoring, firmware updates, security management etc.), as that
>is usually an integral function of the same application on a contained
>device being used for application specific purposes (e.g. a street
>light). OMA Lightweight M2M enables this kind of functionality using
>Objects over CoAP. It would not make any sense to deploy yet another
>protocol on a constrained device for that purpose.
>
>What are the network management needs on a constrained device really? If
>you only need to do some simple network status monitoring, then by all
>means just add one more Object to your CoAP endpoint and you are done.
>There is already a nice Connectivity Monitoring Object defined by OMA
>that can be used for that purpose.
>
>However I agree with Don for complex network management, e.g. getting
>into border routers and deep troubleshooting and configuration of
>multiple protocols, you might need a specialised protocol. But at the
>same time, running SNMP in a border router is no problem. When do we
>really need complex network management on a constrained device?
>
>This thread started with address configuration, and now we're treading on
>the COMAN discussion. But since we're there... In my opinion there will
>not be a one-size-fits-all protocol solution for network management on
>the Internet of Things. For network infrastructure SNMP works just fine,
>for many Web based devices HTTP is already in use, and yes, for simple
>constrained devices folks can just use CoAP. What we need is a common way
>to express a MIB and then easily use that over any of these protocols.
>That makes network management protocol independent as it should be - and
>would be a very worthwhile output from the IETF. CORE is not the right
>place to do that obviously.
>
>Zach 
>
>--

---

From: peter van der Stok <[email-masked]>
Date: Fri, 26 Jul 2013 08:58:30 +0200

Hi Zach,

I agree with the phrase:

> What
> we need is a common way to express
parts of <peter addition>
> a MIB and then easily use that over
> any of these protocols. That makes network management protocol
> independent as it should be - and would be a very worthwhile output
> from the IETF. CORE is not the right place to do that obviously.

What is an obvious place to do this? Coman?

Peter

Zach Shelby schreef op 2013-07-25 18:15:
> location monitoring, firmware updates, security management etc.), as
> that is usually an integral function of the same application on a
> contained device being used for application specific purposes (e.g. a
> street light). OMA Lightweight M2M enables this kind of functionality
> using Objects over CoAP. It would not make any sense to deploy yet
> another protocol on a constrained device for that purpose.
> 
> What are the network management needs on a constrained device really?
> If you only need to do some simple network status monitoring, then by
> all means just add one more Object to your CoAP endpoint and you are
> done. There is already a nice Connectivity Monitoring Object defined
> by OMA that can be used for that purpose.
> 
> This thread started with address configuration, and now we're treading
> on the COMAN discussion. But since we're there... In my opinion there
> will not be a one-size-fits-all protocol solution for network
> management on the Internet of Things. For network infrastructure SNMP
> works just fine, for many Web based devices HTTP is already in use,
> and yes, for simple constrained devices folks can just use CoAP. What
> we need is a common way to express a MIB and then easily use that over
> any of these protocols. That makes network management protocol
> independent as it should be - and would be a very worthwhile output
> from the IETF. CORE is not the right place to do that obviously.
> 
> Zach
> 
> --

---

From: Zach Shelby <[email-masked]>
Date: Fri, 26 Jul 2013 11:01:04 +0300

> What is an obvious place to do this? Coman?

The OPS Area sounds like the right place. Coman really isn't a place yet, as it has been an e-mail discussion so far. Could either be an existing working group (is there a suitable one?), or a new working group with a narrow scope. The thing that worries me about a new WG is that we have the tendency at the IETF to invent a new protocol every time we do that :-) 

Zach

---

From: peter van der Stok <[email-masked]>
Date: Fri, 26 Jul 2013 10:38:06 +0200

Zach Shelby schreef op 2013-07-26 10:01:

I share your worry.
However, just a few things need to be standardized here:
a naming convention, a path, a discovery procedure, different viable 
encodings and their spec,..

It is more about choices between existing solutions and how to specify 
them in the requests over the network,
and ..... making sure that it is extensible, usable for other 
organisations.

Having written that, an existing wg is fine with me, and netconf looks 
the closest to the subject.

Peter

> The OPS Area sounds like the right place. Coman really isn't a place
> yet, as it has been an e-mail discussion so far. Could either be an
> existing working group (is there a suitable one?), or a new working
> group with a narrow scope. The thing that worries me about a new WG is
> that we have the tendency at the IETF to invent a new protocol every
> time we do that :-)
> 
> Zach

---

From: "Mani, Mehdi" <[email-masked]>
Date: Fri, 26 Jul 2013 12:40:26 +0000

Zach,

I share your opinion. LLN and IoT are fuzzy concepts. The constraints and priorities in one use case scenario and application could be very different from others; so it is not useful (and even harmful) to define a "one-size-fits-all" network management protocol. Defining MIBs which cover essential needs can help or at least alleviate network management issues. However, as you mentioned we started the discussion from address assignment and basic configuration processes a node need to go through to be connected to the network and not network management. I believe there are two issues here for LLNs: 1) network protocol with light message exchange which tolerates delay and packet loss. We are almost good for this issue in IETF; however the problem is that for each step of bootstrapping there is a specific protocol (which is optimized by itself if we look at it alone) and you cannot use one protocol to carry the information that you were supposed to get in next step. This comes from the fact that each protocol says I'm not designed for this purpose and hence this takes us to the second issue:  2) node stack complexity: that being said, today a node needs to have the codes of different application modules (designed for a specific purpose) installed on it to be able to connect to the network and discover the services. For instance in many scenarios LLN node with constrained resources just need to have the address of one server to get rid of DHCP code but it cannot.

I believe what is lacking is a document that recommends protocols/options/configurations that are scattered in different WGs (which are not necessary IoT WGs) and says this is IETF protocol solutions that cover A to Z steps a LLN node need to go through to be functional. Once we do so, we can see what is missing which WGs need to be involved... I personally am volunteer to start such activity but I hope I get help of some IETF mentors.
Regards
-Mehdi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: jeudi 25 juillet 2013 18:15
To: Don Sturek
Cc: [email-masked] WG
Subject: Re: [core] COAP and DHCP

On Jul 25, 2013, at 6:42 PM, Don Sturek <[email-masked]> wrote:

> conservative revisit of the principles of HTTP and the Web, maybe we 
> can do something as radically conservative for network management".
> 
> I realize that CORE is maybe not the place for this, however, I 
> believe for IoT that an analagous simplication of SNMP is needed (much 
> like what CoAP did for HTTP).
> 
> Where could these proposals take place?  My fear is that implementers 
> will stretch CoAP to address network management which will be the 
> wrong thing to do.

Zach

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Jul 2013 20:09:26 +0200

> encodings and their spec,..

This is roughly the plan for another network management protocol plus
data model. If the notion of constrained devices causes us to reinvent
everything, then we are not talking about the Internet of Things but
instead about Another Internet of Things. I hope we can avoid AIoT in
favour of an IoT. (And contrary to some of you here, I believe that
there will be many "things" in the future that use some form of 802.11
link layer instead of this severly limited 802.15.4 link layer and
which will afford systems-on-a-ship capable to run embedded Linux
systems, take the Belkin WeMo as an example. If we go down the path of
reinventing everything for the AIoT, then by the time we are done, the
constrained nodes may have disappeared. But hey, this is probably a
bar talk topic. ;-)

For many monitoring and trouble-shooting purposes, SMIv2 MIB modules
have worked fine and if needed it is possible to carry the data in
other formats over other protocols via automatic translations. The key
of many MIB modules is to find agreement which counters need to be
instrumented and on the precise semantics of the counters (e.g., how
they all relate to each other). 

I would prefer if people concentrate on getting the instrumentation
specification right instead of going off inventing a new network
management framework or a new protocol independent data modeling
language (there even was a WG once upon a time to do just that and
people learned that it is much harder than you think). For those with
access to IEEE xplore, you can read [1] or search for SMIng in the
RFC index.

/js

[1] http://dx.doi.org/10.1109/MCOM.2008.4511663

---

From: Rick Bullotta <[email-masked]>
Date: Sat, 27 Jul 2013 18:20:29 +0000

+1

"Constrained" is a relative and ever changing term.