Subject: Re: [6lo] draft-chakrabarti-nordmark-6man-efficient-nd - Proposing new use case "Set-and-forget off-line network"

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 15 Oct 2013 02:31:53 +0000

Hi Anders,

Thanks for your detail comments -- those are quite useful!

Please see in-line.

-----Original Message-----
From: Anders Brandt [mailto:[email-masked]] 
Sent: Monday, September 02, 2013 2:44 AM
To: [email-masked]; Pascal Thubert (pthubert); Samita Chakrabarti; Erik Nordmark (nordmark); [email-masked]
Subject: draft-chakrabarti-nordmark-6man-efficient-nd - Proposing new use case "Set-and-forget off-line network"

[cross-posting 6man / 6lo]

Samita Chakrabarti et al,

Great draft which addresses important issues for low-power wireless network technologies.

After reading the draft, it seems to me that you would benefit adding one more use case - and addressing the derived requirement(s).

Proposed use case:
-------
A.7.  Set-and-forget off-line networks
    Home control modules designed for networked environments may be deployed  
    in very simple settings like garden path lighting controlled by wireless  
    light and motion sensors. Once the network has been created and sensors  
    have been associated with the light modules, the installer takes away the  
    configuration tool which was used to set up the network. Most likely a ULA  
    prefix is used, since multiple hops may be needed. None of the sensors and  
    light modules has the capability of handing out fresh prefixes. Thus, for  
    a set-and-forget style off-line network to work, the nodes must be  able to
    operate forever without trying to refresh its address registration.

    In another instance of an off-line network, a key-fob style remote control is paired
    to a few lamp modules. The controller creates its own small off-line network.
    The controller is not only battery powered and sleeping. It is far away in its owner's pocket.
    Address registration is not possible.
 
     The manufacturer of the lamp module wants to sell exactly the same lamp
     module to large network deployments where address registration is used.
     Since this class of devices provide no local configuration interface, the behaviour needs
     to be controlled via some sort of auto-configuration.
-------
(end of proposed use case) 

[SC>]  ===> Added.

One solution could be to introduce a special interpretation of registration lifetime 0xFFFF as infinite and stating that default routers SHOULD NOT advertise this value.

Such an approach would resemble existing text in RFC4861:

 Valid Lifetime
                      32-bit unsigned integer.  The length of time in
                      seconds (relative to the time the packet is sent)
                      that the prefix is valid for the purpose of on-link
                      determination.  A value of all one bits
                      (0xffffffff) represents infinity.  The Valid
                      Lifetime is also used by [ADDRCONF].

The authors may have other preferred solutions?
[SC>] ===> As discussed off-line that , the valid lifetime for the prefix is still valid and the ARO lifetime applies to the registration lifetime.  We have discussed some of the issues with  allowing permanent registration (especially with NCE cache entries). So at this point we have agreed  to keep the ARO lifetime range as it is.

Best regards,
-Samita

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Oct 2013 12:01:28 -0700

Samita and Anders,

I guess I don't understand the correlation between the set-and-forget 
use case and address registrations in Anders' email.

Is the assertion that there can't be any additional nodes appearing in 
the network, hence there is no need to have DAD functionality after the 
initial setup?

Even if that was the case, there is typically a need for someone to send 
RAs to refresh the lifetime on the existing prefix, and some way for a 
host to discover link-layer addresses of other hosts.

Is the assumption that the nodes would take all of that (including the 
IPv6 and link-layer addresses of all the other hosts in the network) and 
save that to persistent storage?
If not, how would the nodes recover if they halt (due to a line power 
failure or running out of battery) and reboot?

For the home automation stuff I've seen a key benefit is to have a 
controller, which allows the user to reprogram the lights and sensors. 
That can be either a dedicated controller or a gateway plus a remote 
app/controller.

In those cases the dedicated controller or gateway would be a natural 
place to perform all the functions relation to address registrations and 
prefixes.

So I don't quite understand where this use case would appear in practice 
- a set of sensors and lights whose functional behavior is frozen in 
time doesn't match what I see in the home automation space.

Regards,
    Erik

On 10/14/13 7:31 PM, Samita Chakrabarti wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 15 Oct 2013 19:36:01 +0000

Hi Erik,

As far as I understand that the controller in Z-wave is not the same behavior as in NEAR router.
The controller is quite specific to the application -- it seems it once configures the network devices and forgets about the device and it is used for one-time configuration. This seems quite product specific function.

I agree that having a controller function based on ND is quite useful where the controller would be responsible for assigning addresses and managing them through registration and the controller may or may not have the routing capabilities.

I am not quite clear why the controller in Ander's example would need the registration  for one time.
The use case was added in the appendix since the application partially uses the efficient-ND mechanisms.

Anders can explain the reasons behind  the particular function and relationship with registration.

Thanks for bringing it up.
-Samita

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Tuesday, October 15, 2013 12:01 PM
To: Samita Chakrabarti; Anders Brandt
Cc: [email-masked]; Pascal Thubert (pthubert); [email-masked]; [email-masked]
Subject: Re: [6lo] draft-chakrabarti-nordmark-6man-efficient-nd - Proposing new use case "Set-and-forget off-line network"

Samita and Anders,

I guess I don't understand the correlation between the set-and-forget use case and address registrations in Anders' email.

Is the assertion that there can't be any additional nodes appearing in the network, hence there is no need to have DAD functionality after the initial setup?

Even if that was the case, there is typically a need for someone to send RAs to refresh the lifetime on the existing prefix, and some way for a host to discover link-layer addresses of other hosts.

Is the assumption that the nodes would take all of that (including the
IPv6 and link-layer addresses of all the other hosts in the network) and save that to persistent storage?
If not, how would the nodes recover if they halt (due to a line power failure or running out of battery) and reboot?

For the home automation stuff I've seen a key benefit is to have a controller, which allows the user to reprogram the lights and sensors. 
That can be either a dedicated controller or a gateway plus a remote app/controller.

In those cases the dedicated controller or gateway would be a natural place to perform all the functions relation to address registrations and prefixes.

So I don't quite understand where this use case would appear in practice
- a set of sensors and lights whose functional behavior is frozen in time doesn't match what I see in the home automation space.

Regards,
    Erik