Subject: [Roll] On Operation and Management of Large Scale MPL Network (Fwd: I-D Action: draft-doi-roll-mpl-nan-requirements-00.txt)

From: Yusuke DOI <[email-masked]>
Date: Tue, 10 Dec 2013 15:30:09 +0900

Dear roll folks, especially for the chairs:

Let me introduce my issue (again). I would appreciate if I can have some comments on the idea or suggestion for alternate approaches.

The issue I have is how to deploy a mesh network over even larger network, maybe up to 10,000 nodes, with very low application traffic. At the same time, we need communication channels for relatively-low latency (few seconds) broadcast for commanding and enough reliable broadcast file transfer. The draft draft-doi-roll-mpl-nan-requirements-00 introduces the requirement.

For the objective, MPL seems to be the only choice for us. But it lacks some functionarities for operation and management. One of the spec we need is to configure and/or update MPL forwarder after deployment. My proposal for configuration and re-configuration is DHCPv6 option: http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-03

I expect this would be a part of a ZigBee profile. I would appreciate if the WG can discuss the topic as WG item.

Best Regards,

Yusuke

-------- Original Message --------
Subject: I-D Action: draft-doi-roll-mpl-nan-requirements-00.txt
Date: Tue, 03 Dec 2013 04:22:15 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Neighborhood Area Network Requirements for MPL
	Author(s)       : Yusuke Doi
	Filename        : draft-doi-roll-mpl-nan-requirements-00.txt
	Pages           : 6
	Date            : 2013-12-03

Abstract:
    Neighborhood area networks (NAN) is expected to use MPL to distribute
    information over wireless mesh network with 6lowpan/802.15.4.  This
    document is to describe expected use case and requirements of NAN,
    based on OpenSG requirements.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-doi-roll-mpl-nan-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-doi-roll-mpl-nan-requirements-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 16 Dec 2013 11:49:13 +0900

Hi,

(2013-12-10 15:30), Yusuke DOI wrote:
> The issue I have is how to deploy a mesh network over even larger
> network, maybe up to 10,000 nodes, with very low application traffic.
> At the same time, we need communication channels for relatively-low
> latency (few seconds) broadcast for commanding and enough reliable
> broadcast file transfer. The draft
> draft-doi-roll-mpl-nan-requirements-00 introduces the requirement.
>
> For the objective, MPL seems to be the only choice for us. But it
> lacks some functionarities for operation and management. One of the
> spec we need is to configure and/or update MPL forwarder after
> deployment. My proposal for configuration and re-configuration is
> DHCPv6 option:
> http://tools.ietf.org/html/draft-doi-roll-mpl-parameter-configuration-03

Let me describe little bit more on this topic.

The following issues are what I need to solve.

1) MPL configuration and reconfiguration
  - New domains may appear after deployment
  - Existing domain configuration may be changed
  - Of course, it should be scalable
    (Peter suggested me to use SNMP, but we're going to scale out up to 10k)

2) Management I/F of MPL nodes, especially, seeds.
  - MIBs? Netconf? CoAP???
  - How many 'active transmitting data messages'? for rate control

I did preliminary analysis on MPL reconfiguration after ML discussion two-months ago, and now nearly-confident that the only problem is unbalanced transmission and almost no message will be lost just because of parameter update. Timers for running transmissions can be 'reset' as if there are some inconsistency detected, just after parameter update.

Here's list of parameters and expected effects after reset. Assumption is the forwarder is the only one with the updated parameter set:

PROACTIVE_FORWARDING false->true:
  the forwarder is almost always have to send the first data messages

PROACTIVE_FORWARDING true->false:
  the forwarder will not send the data message at the first interval

SEED_SET_ENTRY_LIFETIME increased:
  the forwarder will continue to keep old data message and bitmap, if
  there are some transmission happend after neighbor's expiry and
  before the node's expiry, the forwarder may need to send old messages
  again (should not happen frequently)

SEED_SET_ENTRY_LIFETIME decreased:
  vice versa, the forwaeder may receive old messages.

IMIN, IMAX decreased or K increased:
  more chance to send messages

IMIN, IMAX increased or K decreased:
  less chance to send messages

TIMER_EXPIRATIONS incresed:
  more messages to send. At the end of consistent intervals before
  expiration, the forwarder may be the only node to send the message

TIMER_EXPIRATIONS decreased:
  less messages to send.

So, as far as I can recognize, parameter update is possible for implementations that can accept temporal unbalanced load of transmission. For battery-powered devices it may not be acceptable, but for power-supplied devices it should be acceptable as far as it does not harm the mesh network itself.

Regards,

Yusuke

p.s. I'll be on winter vacation on later this week, and many of you weel be in holiday week when I'm back to office, so please accept longer latency on communication. Happy hollidays!