Subject: Re: [coman] Automated Metering Infrastructure (AMI) use case

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 17 Sep 2012 15:58:20 +0200

Hi Gilman, Ulrich,

I also find this use case as useful.

Please find my comments below with [me].

Cheers, 
Mehmet 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Ulrich Herberg
Sent: Thursday, August 23, 2012 12:09 AM
To: Gilman Tolle (gtolle)
Cc: [email-masked]
Subject: Re: [coman] Automated Metering Infrastructure (AMI) use case

Hi Gilman,

I think this use case is very important and I like the suggested text.
Some comments inline:

On Tue, Jul 31, 2012 at 5:10 PM, Gilman Tolle (gtolle)
<[email-masked]> wrote:

Hi all,

I've been developing a constrained device network management application
for my customers, and I've been following the COMAN list.

[. . .]

The mesh network is anchored by a collection of higher-end devices which
contain a mesh radio that connects to the constrained network as well as
a backhaul link that connects to a less-constrained network. The
backhaul link could be cellular, WiMAX, or Ethernet, depending on the
backhaul networking technology that the utility has chosen. These
higher-end devices (termed "routers" in this use case) 

I am not sure this term is clearly differentiating these devices, since
you mention above that all meters may also serve as routers. I am not
sure which term is best to use... maybe "gateway"/"border gateway"? I
think that later in the text you use "headend".

[me]: Common entities (terms) which could have a router functionality in
the context of AMI are: HAN gateway, AMI Data Aggregation Point or AMI
Concentrator and AMI Headend. 

	are typically installed on utility poles throughout the service
territory. Router devices are typically less constrained than meters,
and often contain the full routing table for all the endpoints routing
through them, but this may vary depending on the routing protocol in
use.

Yes, indeed. I wonder if that is not too specific for this use case
draft.

	In this use case, the utility typically installs on the order of
1000 meters per router. The collection of meters that are routing
through a specific router is called a "PAN". When powered on, each meter
is designed to discover the nearby PANs, select the optimal PAN to join,
and select the optimal meters in that PAN to route through when sending
data to the headend. After joining the PAN, the meter is designed to
continuously monitor and optimize its connection to the PAN, 

	and it will change routes and change PANs as needed.

I would suggest to change "will" to "may", as this depends on the
routing protocol that is used. The meter could also be more "dumb" and
just use a single default route.

[me]: I know PAN as Personal Area Network. Can you pls write it out? 

	As a result of this continuous optimization, PAN membership can
change frequently throughout the life of the network.
	
	Each PAN may be configured to share an encryption key, providing
confidentiality for all data traffic within the PAN. 

[ . . .]

AMI Management Requirements
---------------------------

To support the use case above, the headend must contain a set of
management systems that meet the following requirements. The first two
requirements may fall outside the typical definition of "network
management system" and into authentication and provisioning systems
(e.g. RADIUS, DHCPv6), but the full use case does require all six.

I think we may indeed need some discussion if the first two items fit
into this draft (and COMAN in general). It may be better fitting in the
new IETF discussion group SOLACE.

[me]: Secure bootstrapping of a network with constrained devices is
interesting for COMAN as part of different use cases, however I think
simple authentication and authorization fits more to SOLACE. I tend to
think that the second one is a generally an issue for large networks.

	1. Securely authenticate a large number of constrained devices
as they attempt to join the network at the link layer, and check those
devices against a master list of authorized devices.
	
	2. Provide routable IPv6 addresses for a large number of
constrained devices after they have joined the network.
	
	3. Support group-based provisioning and coordinated
reconfiguration of a large-scale network of constrained devices with
automatic synchronization and eventual consistency to handle lossy links
and temporarily unavailable devices.
	
	4. Collect network status, performance metrics, and fault event
information for a large-scale network of constrained devices into a
central location with user interfaces that enable monitoring and
troubleshooting of large networks (millions of devices) by a single
person or small team.
	
	5. Support group-based firmware update of those constrained
devices, with eventual consistency and coordinated reload times.
	
	6. Support this kind of group-based provisioning, configuration,
monitoring, and firmware update functionality for multiple device
classes within a single network, including constrained mesh endpoints
and less constrained routers.

Best
Ulrich

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

---

From: peter van der Stok <[email-masked]>
Date: Thu, 20 Sep 2012 09:42:46 +0200

Hi mehmet,

attached my contribution to the mgmt-01 draft
I copied section 3.5 to word and edited with change tracking
Also some text for sec 4.2 is added.

let me know if this is convenient, I can add more sec 4.2 cases on 
grouping for example.

Peter