From mehmet.ersue@nsn.com Fri Aug 3 18:59:24 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE5721F8D8B for ; Fri, 3 Aug 2012 18:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.422 X-Spam-Level: X-Spam-Status: No, score=-106.422 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTwZgGSNEtjB for ; Fri, 3 Aug 2012 18:59:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C46FD21F8D87 for ; Fri, 3 Aug 2012 18:59:22 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q741xJ2k014125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 4 Aug 2012 03:59:19 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q741xI5Z023719; Sat, 4 Aug 2012 03:59:19 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Aug 2012 03:56:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Aug 2012 03:56:35 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64041838B4@DEMUEXC006.nsn-intra.net> In-Reply-To: <7CB5848F-CDFA-4634-B8DC-3CC18F50A270@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] Automated Metering Infrastructure (AMI) use case Thread-Index: AQHNb3oFUupeIbwJkU2PS1Xa9CzeRJdI5w9g References: <7CB5848F-CDFA-4634-B8DC-3CC18F50A270@cisco.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Gilman Tolle (gtolle)" , X-OriginalArrivalTime: 04 Aug 2012 01:56:40.0055 (UTC) FILETIME=[63912070:01CD71E4] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8776 X-purgate-ID: 151667::1344045559-00002E58-7BD4A8F4/0-0/0-0 Subject: Re: [coman] Automated Metering Infrastructure (AMI) use case X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 01:59:24 -0000 Hi Gilman, thank you for your contribution. AMI and smart metering are important use cases.=20 We partly addressed this in section 3.6. We probably should separate Energy Management and Smart Grid and merge Smart Grid with AMI. Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman-bounces@ietf.org [mailto:coman-bounces@ietf.org] On Behalf Of ext > Gilman Tolle (gtolle) > Sent: Tuesday, July 31, 2012 5:10 PM > To: coman@ietf.org > Subject: [coman] Automated Metering Infrastructure (AMI) use case >=20 > Hi all, >=20 > I've been developing a constrained device network management application for my > customers, and I've been following the COMAN list. >=20 > I support the work that's happening here, and am ready to help improve it. >=20 > Automated Metering Infrastructure (AMI) is one use case that should be added to the > requirements document. Here is some text that describes this use case, as well as > some constrained network management requirements derived from it. >=20 > I'm not at the IETF this week, but will be participating in the COMAN effort via the > mailing list. >=20 > Gil >=20 > Automated Metering Infrastructure (AMI) Use Case > ------------------------------------------------ >=20 > An AMI network enables an electric utility to retrieve frequent electric usage data from > each electric meter installed at a customer's home or business. With an AMI network, a > utility can also receive immediate notification of power outages when they occur, > directly from the electric meters that are experiencing those outages. In addition, if the > AMI network is designed to be open and extensible, it could serve as the backbone for > communicating with other distribution automation devices besides meters, which could > include transformers and reclosers. >=20 > In this use case, each meter in the AMI network contains a constrained device. These > devices are typically Class 2 devices. Each meter connects to a constrained mesh > network with a low-bandwidth radio. These radios can be 50, 150, or 200 kbps at raw > link speed, but actual network throughput may be significantly lower due to forward > error correction, multihop delays, MAC delays, lossy links, and protocol overhead. >=20 > The constrained devices are used to connect the metering logic with the network, so > that usage data and outage notifications can be sent back to the utility's headend > systems over the network. These headend systems are installed in a data center > managed by the utility, and may include meter data collection systems, meter data > management systems, and outage management systems. >=20 > The meters are connected to a mesh network, and each meter can act as both a > source of traffic and as a router for other meters' traffic. In a typical AMI application, > smaller amounts of traffic (read requests, configuration) flow "downstream" from the > headend to the mesh, and larger amounts of traffic flow "upstream" from the mesh to > the headend. But, during a firmware update operation, larger amounts of traffic might > flow downstream while smaller amounts flow upstream. Other applications that make > use of the AMI network may have their own distinct traffic flows. >=20 > 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) 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. >=20 > 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. As a result of this continuous optimization, PAN > membership can change frequently throughout the life of the network. >=20 > Each PAN may be configured to share an encryption key, providing confidentiality for > all data traffic within the PAN. This key may be obtained by a meter only after an end- > to-end authentication process based on certificates, ensuring that only authorized and > authenticated meters are allowed to join the PAN, and by extension, the mesh network > as a whole. >=20 > After joining the PAN, each endpoint obtains a private routable IPv6 address that > enables end-to-end communication between the headend systems and each meter. In > this use case, the meters are always "on", and should have a ping round trip time of > roughly 200ms per hop. But, due to lossy links and network optimization, not every > meter will be immediately ping-able, though eventually every meter will be able to > exchange data with the headend. >=20 > In a large AMI deployment, there may be 10 million meters supported by 10,000 > routers, spread across a very large geographic area. Within a single PAN, the meters > may range between 1 and 20 hops from the router. >=20 > During the deployment process, these meters are installed and turned on in large > batches, and those meters must be authenticated, given addresses, and provisioned > with any configuration information necessary for their operation. During deployment > and after deployment is finished, the network must be monitored continuously and > failures must be handled. Configuration parameters may need to be changed on large > numbers of devices, but most of the devices will be running the same configuration. > And, eventually, the firmware in those meters will need to be upgraded, and this must > also be done in large batches because most of the devices will be running the same > firmware image. >=20 > Because there may be thousands of routers, this operational model (batch deployment, > automatic provisioning, continuous monitoring, batch reconfiguration, batch firmware > update) should also apply to the routers as well as the constrained devices. The scale is > different (thousands instead of millions) but still large enough to make individual > management impractical for routers as well. >=20 > AMI Management Requirements > --------------------------- >=20 > 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. >=20 > 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. >=20 > 2. Provide routable IPv6 addresses for a large number of constrained devices after > they have joined the network. >=20 > 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. >=20 > 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. >=20 > 5. Support group-based firmware update of those constrained devices, with eventual > consistency and coordinated reload times. >=20 > 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. >=20 >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From cabo@tzi.org Thu Aug 9 15:57:46 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B4C11E80A6; Thu, 9 Aug 2012 15:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJOMDY72ZS81; Thu, 9 Aug 2012 15:57:46 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E38F711E808A; Thu, 9 Aug 2012 15:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q79MvbOQ017867; Fri, 10 Aug 2012 00:57:37 +0200 (CEST) Received: from [192.168.217.105] (p548943BE.dip.t-dialin.net [84.137.67.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AFD7772F; Fri, 10 Aug 2012 00:57:36 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Carsten Bormann Date: Fri, 10 Aug 2012 00:57:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <462C27CF-98BB-4C77-AE8F-8C0669B3FE9F@tzi.org> To: lwip@ietf.org X-Mailer: Apple Mail (2.1485) Cc: coman@ietf.org Subject: [coman] New terminology section for LWIG and COMAN X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:57:46 -0000 I have submitted a new version of the LWIG guidance document, with a new section 2 on terminology. This tries to reflect the need for clearer terminology that became apparent in the discussion we had during the COMAN ad-hoc meeting at IETF 84.=20 http://tools.ietf.org/html/draft-ietf-lwig-guidance-02#section-2 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lwig-guidance-02 I'm looking forward to your comments. Gr=FC=DFe, Carsten From j.schoenwaelder@jacobs-university.de Fri Aug 10 03:56:28 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DD421F861D; Fri, 10 Aug 2012 03:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vIT68Giz1WS; Fri, 10 Aug 2012 03:56:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12321F84E4; Fri, 10 Aug 2012 03:56:27 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B42B320C06; Fri, 10 Aug 2012 12:56:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RWZpAIGAZC1T; Fri, 10 Aug 2012 12:56:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5483920C02; Fri, 10 Aug 2012 12:56:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B011C2114866; Fri, 10 Aug 2012 12:56:25 +0200 (CEST) Date: Fri, 10 Aug 2012 12:56:25 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20120810105625.GB3122@elstar.local> Mail-Followup-To: Carsten Bormann , lwip@ietf.org, coman@ietf.org References: <462C27CF-98BB-4C77-AE8F-8C0669B3FE9F@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <462C27CF-98BB-4C77-AE8F-8C0669B3FE9F@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: coman@ietf.org, lwip@ietf.org Subject: Re: [coman] New terminology section for LWIG and COMAN X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 10:56:28 -0000 On Fri, Aug 10, 2012 at 12:57:35AM +0200, Carsten Bormann wrote: > I have submitted a new version of the LWIG guidance document, with a > new section 2 on terminology. This tries to reflect the need for > clearer terminology that became apparent in the discussion we had > during the COMAN ad-hoc meeting at IETF 84. > > http://tools.ietf.org/html/draft-ietf-lwig-guidance-02#section-2 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-guidance-02 > > I'm looking forward to your comments. This is useful, thanks for writing it down. I am not sure what the term "challenged network" really buys us. I did not see the term "challenged network" actually used in RFC4838, but I do understand that the DTN community used this term. My preference would be to move the three bullets currently in 2.2.1 up to section 2.2. and to collapse 2.2.1 into a note that simply explains that the term "challenged network" has been used for a certain subset of constrained networks as part of the DTN work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cabo@tzi.org Fri Aug 10 06:06:01 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80721F8567; Fri, 10 Aug 2012 06:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kay9WbDV8SzK; Fri, 10 Aug 2012 06:06:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CC06A21F8569; Fri, 10 Aug 2012 06:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q7AD5r1j002246; Fri, 10 Aug 2012 15:05:53 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CA4E590F; Fri, 10 Aug 2012 15:05:52 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20120810105625.GB3122@elstar.local> Date: Fri, 10 Aug 2012 15:05:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <462C27CF-98BB-4C77-AE8F-8C0669B3FE9F@tzi.org> <20120810105625.GB3122@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1485) Cc: coman@ietf.org, lwip@ietf.org Subject: Re: [coman] New terminology section for LWIG and COMAN X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 13:06:01 -0000 On Aug 10, 2012, at 12:56, Juergen Schoenwaelder = wrote: > This is useful, thanks for writing it down.=20 Thanks. > I am not sure what the term "challenged network" really buys us. I did > not see the term "challenged network" actually used in RFC4838, but I > do understand that the DTN community used this term. My preference > would be to move the three bullets currently in 2.2.1 up to section > 2.2. and to collapse 2.2.1 into a note that simply explains that the > term "challenged network" has been used for a certain subset of > constrained networks as part of the DTN work. I was mostly trying to declare the really challenged networks out of = scope and delegate to RFC 4838. Apparently I'll need to clarify this. Gr=FC=DFe, Carsten From mehmet.ersue@nsn.com Fri Aug 10 06:24:40 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC7521F8620; Fri, 10 Aug 2012 06:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qktXYO8Gurfg; Fri, 10 Aug 2012 06:24:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C576121F861F; Fri, 10 Aug 2012 06:24:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7ADOZua031441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2012 15:24:35 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7ADOXao008301; Fri, 10 Aug 2012 15:24:34 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Aug 2012 15:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2012 15:24:30 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64041CD7C7@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] New terminology section for LWIG and COMAN Thread-Index: Ac12+OcAETFQH+LlS0Cl+AND/L8LuQAAUBmQ References: <462C27CF-98BB-4C77-AE8F-8C0669B3FE9F@tzi.org><20120810105625.GB3122@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Carsten Bormann" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 10 Aug 2012 13:24:31.0588 (UTC) FILETIME=[79CBCA40:01CD76FB] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1821 X-purgate-ID: 151667::1344605077-00003184-C0AC0E13/0-0/0-0 Cc: coman@ietf.org, lwip@ietf.org Subject: Re: [coman] New terminology section for LWIG and COMAN X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 13:24:40 -0000 Hi Carsten, the terminology section is very useful. It makes also sense if our = document refers to draft-ietf-lwig-guidance concerning the terminology = and network management sections but also for the technologies described. Are you actually planning to describe the self-configuration of hosts in = section 5.4., which I assume is an essential issue for constrained = nodes. I think the authors of draft-nieminen-core-service-discovery could help = here. Cheers,=20 Mehmet=20 > -----Original Message----- > From: coman-bounces@ietf.org [mailto:coman-bounces@ietf.org] On Behalf = Of ext > Carsten Bormann > Sent: Friday, August 10, 2012 3:06 PM > To: Juergen Schoenwaelder > Cc: coman@ietf.org; lwip@ietf.org > Subject: Re: [coman] New terminology section for LWIG and COMAN >=20 > On Aug 10, 2012, at 12:56, Juergen Schoenwaelder = university.de> wrote: >=20 > > This is useful, thanks for writing it down. >=20 > Thanks. >=20 > > I am not sure what the term "challenged network" really buys us. I = did > > not see the term "challenged network" actually used in RFC4838, but = I > > do understand that the DTN community used this term. My preference > > would be to move the three bullets currently in 2.2.1 up to section > > 2.2. and to collapse 2.2.1 into a note that simply explains that the > > term "challenged network" has been used for a certain subset of > > constrained networks as part of the DTN work. >=20 > I was mostly trying to declare the really challenged networks out of = scope and delegate > to RFC 4838. > Apparently I'll need to clarify this. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From mehmet.ersue@nsn.com Fri Aug 17 01:41:09 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881421F852E for ; Fri, 17 Aug 2012 01:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KPoIf-4H6kr for ; Fri, 17 Aug 2012 01:41:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D821121F852D for ; Fri, 17 Aug 2012 01:41:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8f4kR002678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Aug 2012 10:41:04 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8evIE016387 for ; Fri, 17 Aug 2012 10:41:04 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 10:40:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Aug 2012 10:40:54 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404219C0E@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMAN Discussion during IETF 84 Thread-Index: Ac18VAPguFEn2JwhS16POKnPq0WIkw== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Aug 2012 08:40:56.0923 (UTC) FILETIME=[052832B0:01CD7C54] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3960 X-purgate-ID: 151667::1345192864-00003184-070EED41/0-0/0-0 Subject: [coman] COMAN Discussion during IETF 84 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:41:09 -0000 Hi All, Coman as an activity has been introduced at IETF 84 with a 1-slider in the Core WG session (see slide 53, 54 in http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf).=20 Coman document development has been also discussed in the OPS Area open session (see http://www.ietf.org/proceedings/84/slides/slides-84-opsawg-3.pptx).=20 There was an ad-hoc discussion on the COnstrained MANanagement (Coman) activity during IETF 84 on Wednesday, August 1, 2012.=20 Participants: Dominique Barthel, Carsten Bormann, Martin Bjorklund, Zhen Cao, Benoit Claise, Bob Cole, Mehmet Ersue, Ulrich Herberg, Dan Romascanu, Juergen Schoenwaelder, Peter van der Stok=20 * The discussion on the scope of the work was concerning whether it should be focused on the networks with constrained devices only or should also cover the management of constrained networks with non-constrained devices. The group agreed to describe the use case for constrained networks but exclude it for the detailed requirements discussion. The requirements for the constrained network use case can be put into the annex.=20 o However the behavior of a constrained networks with constrained devices is interesting to look at to understand how a constrained network (the constrainedness) changes the requirements on the management of constrained devices. Carsten Bormann proposed to address the management of constrainedness.=20 * Currently the document gives a top-down application-view with use case descriptions. Compared to the top-down view it has been proposed to look at the use cases from the bottom-up view to understand the requirements of very constrained devices. It would be useful to understand the requirements on simplifying the management protocols for very constrained devices.=20 * The deployment type should be discussed, e.g. HAN and AMI have different requirements, depending on the size of the network there are different requirements.=20 * Class of networks should be discussed, where different type of radio and communication technologies are in use.=20 * Zach Shelby is interested in the M2M and cellular scenario. We should also look at other SDOs and what they have been doing so far, e.g. ETSI device model, OMA device management, or OBIX from OASIS.=20 * Chen Zao from China Mobile stated that he finds the cellular and mobile network use case as important. Chen can possibly contribute to the mobile application use case and requirements.=20 * One related draft is the configuration draft in the Core WG (http://tools.ietf.org/html/draft-nieminen-core-service-discovery-02), which defines the basic model for configuration and initial authentication. The model in this draft has been integrated into the IPSO configuration profile.=20 * It has been proposed to list requirements but also features per use case. Furthermore the size of a network should be discussed per use case.=20 * Classifying devices based on features:=20 o provide a list of management features and level of features to be matched to device classes and use cases,=20 o different devices in a device class might use different subsets. * Matching use cases to device classes:=20 o agreed to list the device categories and the assumed network size in a use case=20 o provide examples for device classes=20 * Giving specific requirements per use case and device class=20 o planned to address in section 4.=20 o series of requirements based on FCAPS=20 * It has been suggested to reference available work on constrained networks/devices (e.g. FP7 EU project Butler-SmartLife). Note that Levent Gurgen (cea.fr) kindly provided draft documents (not available publicly) of the EU project Butler-SmartLife, which we will use as an input for the next version.=20 * A conclusion section will summarize the gaps and highlight potential need for new work.=20 I would appreciate any comments. Thank you. Cheers,=20 Mehmet=20 From mehmet.ersue@nsn.com Fri Aug 17 01:54:48 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F0621F8593 for ; Fri, 17 Aug 2012 01:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdgEnh1k6rJS for ; Fri, 17 Aug 2012 01:54:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3121F84F2 for ; Fri, 17 Aug 2012 01:54:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8sY3b031785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Aug 2012 10:54:36 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8sTkJ002550 for ; Fri, 17 Aug 2012 10:54:34 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 10:54:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Aug 2012 10:54:24 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404219C16@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: COMAN Discussion during IETF 84 Thread-Index: Ac18VeZ0h3wi7jhyQHeZdIT6v8X17Q== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Aug 2012 08:54:24.0796 (UTC) FILETIME=[E6AFD5C0:01CD7C55] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4035 X-purgate-ID: 151667::1345193676-00003184-03173D91/0-0/0-0 Subject: [coman] FW: COMAN Discussion during IETF 84 X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:54:48 -0000 (making it a bit easier to read) Hi All, Coman as an activity has been introduced at IETF 84 with a 1-slider in the Core WG session (see slide 53, 54 in http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf).=20 Coman document development has been also discussed in the OPS Area open session (see http://www.ietf.org/proceedings/84/slides/slides-84-opsawg-3.pptx).=20 There was an ad-hoc discussion on the COnstrained MANanagement (Coman) activity during IETF 84 on Wednesday, August 1, 2012.=20 Participants: Dominique Barthel, Carsten Bormann, Martin Bjorklund, Zhen Cao, Benoit Claise, Bob Cole, Mehmet Ersue, Ulrich Herberg, Dan Romascanu, Juergen Schoenwaelder, Peter van der Stok=20 * The discussion on the scope of the work was concerning whether it should be focused on the networks with constrained devices only or should also cover the management of constrained networks with non-constrained devices. The group agreed to describe the use case for constrained networks but exclude it for the detailed requirements discussion. The requirements for the constrained network use case can be put into the annex.=20 - However the behavior of a constrained networks with constrained devices is interesting to look at to understand how a constrained network (the constrainedness) changes the requirements on the management of constrained devices. Carsten Bormann proposed to address the management of constrainedness. =20 * Currently the document gives a top-down application-view with use case descriptions. Compared to the top-down view it has been proposed to look at the use cases from the bottom-up view to understand the requirements of very constrained devices. It would be useful to understand the requirements on simplifying the management protocols for very constrained devices.=20 * The deployment type should be discussed, e.g. HAN and AMI have different requirements, depending on the size of the network there are different requirements.=20 * Class of networks should be discussed, where different type of radio and communication technologies are in use.=20 * Zach Shelby is interested in the M2M and cellular scenario. We should also look at other SDOs and what they have been doing so far, e.g. ETSI device model, OMA device management, or OBIX from OASIS.=20 * Chen Zao from China Mobile stated that he finds the cellular and mobile network use case as important. Chen can possibly contribute to the mobile application use case and requirements.=20 * One related draft is the configuration draft in the Core WG (http://tools.ietf.org/html/draft-nieminen-core-service-discovery-02), which defines the basic model for configuration and initial authentication. The model in this draft has been integrated into the IPSO configuration profile.=20 * It has been proposed to list requirements but also features per use case. Furthermore the size of a network should be discussed per use case.=20 * Classifying devices based on features:=20 - provide a list of management features and level of features to be matched to device classes and use cases,=20 - different devices in a device class might use different subsets.=20 * Matching use cases to device classes:=20 - agreed to list the device categories and the assumed network size in a use case=20 - provide examples for device classes=20 * Giving specific requirements per use case and device class=20 - planned to address in section 4.=20 - series of requirements based on FCAPS=20 * It has been suggested to reference available work on constrained networks/devices (e.g. FP7 EU project Butler-SmartLife). Note that Levent Gurgen (cea.fr) kindly provided draft documents (not available publicly) of the EU project Butler-SmartLife, which we will use as an input for the next version.=20 * A conclusion section will summarize the gaps and highlight potential need for new work.=20 I would appreciate any comments. Thank you. Cheers,=20 Mehmet From dromasca@avaya.com Tue Aug 21 09:23:54 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EA621F8779 for ; Tue, 21 Aug 2012 09:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faa01J+zaj1O for ; Tue, 21 Aug 2012 09:23:52 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7F19421F876D for ; Tue, 21 Aug 2012 09:23:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANO1M1CHCzI1/2dsb2JhbABFhgGzcHKBB4IgAQEBAQECAQEBDxENBDoXBgEIDQQBAwEBAwIGAgQMBwQBAgIDASUfAwQBAQUEAQQTCAEQCYdrC5dkhCOKHZMrgSGJZxqDZoIKMmADm1CKFYJjgV8 X-IronPort-AV: E=Sophos;i="4.77,803,1336363200"; d="scan'208";a="363017414" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Aug 2012 12:19:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Aug 2012 12:03:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 21 Aug 2012 18:23:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Non-WG Mailing List: solace -- Smart Object LifecycleArchitecture for Constrained Environments discussion list thread-index: Ac17w7ikSLM+3ZmNQYSoV+Wwzqt/YgD9U6/Q From: "Romascanu, Dan (Dan)" To: Subject: [coman] FW: New Non-WG Mailing List: solace -- Smart Object LifecycleArchitecture for Constrained Environments discussion list X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:23:54 -0000 RG9lcyBhbnlib2R5IGtub3cgbW9yZSBhYm91dCB0aGlzIGFjdGl2aXR5IGFuZCBkb2VzIGFueWJv ZHkgaGF2ZSBhbiBvcGluaW9uIGFib3V0IGhvdyBpdCByZWxhdGVkIHRvIGNvbWFuPyANCg0KRGFu DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwg MjAxMiA2OjI3IFBNDQpUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KQ2M6IGNhYm9AdHppLm9y Zzsgc29sYWNlQGlldGYub3JnDQpTdWJqZWN0OiBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDogc29s YWNlIC0tIFNtYXJ0IE9iamVjdCBMaWZlY3ljbGVBcmNoaXRlY3R1cmUgZm9yIENvbnN0cmFpbmVk IEVudmlyb25tZW50cyBkaXNjdXNzaW9uIGxpc3QNCg0KDQpBIG5ldyBJRVRGIG5vbi13b3JraW5n IGdyb3VwIGVtYWlsIGxpc3QgaGFzIGJlZW4gY3JlYXRlZC4NCg0KTGlzdCBhZGRyZXNzOiBzb2xh Y2VAaWV0Zi5vcmcNCkFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9zb2xhY2UvDQpUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29sYWNlDQoNClB1cnBvc2U6IFRoaXMgbGlzdCBpcyBmb3IgZGlzY3Vzc2lvbnMgcmVs YXRpbmcgdG8ga2lja2luZyBvZmYgYW5kIHRoZSBpbml0aWFsIHdvcmsgb24gdGhlICJTbWFydCBP YmplY3QgTGlmZWN5Y2xlIEFyY2hpdGVjdHVyZSBmb3IgQ29uc3RyYWluZWQgRW52aXJvbm1lbnRz IiAoU09MQUNFKSBpbml0aWF0aXZlLiBUaGVyZSBpcyBhIG5lZWQgZm9yIHN0YW5kYXJkaXphdGlv biB3b3JrIGFyb3VuZCB0aGUgc2V0dXAgcHJvY2Vzc2VzICgiaW5zdGlsbGluZyBpdHMgbWVhbmlu ZyBpbiBsaWZlIikgYW5kIGJvb3RzdHJhcHBpbmcgc2VjdXJpdHkgb2Ygc21hcnQgb2JqZWN0cywg Y2YuIHRoZSBQYXJpcyBTbWFydCBPYmplY3QgU2VjdXJpdHkgd29ya3Nob3AgKHNlZSBodHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgzL3NsaWRlcy9zbGlkZXMtODMtc2FhZy0zLnBkZiku ICBUaGUgSUVURiBzbyBmYXIgaGFzIGJvdW5jZWQgYXJvdW5kIHRoZSByZWxhdGVkIHdvcmsgYmV0 d2VlbiB3b3JraW5nIGdyb3VwcyBzdWNoIGFzIDZMb1dQQU4sIFJPTEwsIG9yIENvUkUsIHdpdGhv dXQgYWNoaWV2aW5nIHRhbmdpYmxlIHByb2Nlc3MsIGFuZCB0aGlzIGluaXRpYXRpdmUgc2Vla3Mg dG8gZmluZCBhIG1vcmUgZm9jdXNlZCBob21lIGZvciBpdCwgbGlrZWx5IHNwaW5uaW5nIG9mZiBz b21lIHJlbGF0ZWQgd29yayB0byBvdGhlciB3b3JraW5nIGdyb3Vwcy4NCg0KRm9yIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0IHRoZSBsaXN0IGFkbWluaXN0cmF0b3JzLg0K From cabo@tzi.org Tue Aug 21 09:35:18 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4F21F876C for ; Tue, 21 Aug 2012 09:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaQND+7KbeB4 for ; Tue, 21 Aug 2012 09:35:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1451921F8775 for ; Tue, 21 Aug 2012 09:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q7LGZ05w001561; Tue, 21 Aug 2012 18:35:00 +0200 (CEST) Received: from [192.168.20.20] (m213-103-255-209.cust.tele2.lt [213.103.255.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0DEFEA0F; Tue, 21 Aug 2012 18:34:55 +0200 (CEST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <9F4F5F83-13B1-4C55-8B3E-C93C8DFC95D4@tzi.org> Content-Transfer-Encoding: quoted-printable X-Mailer: iPod Mail (9B206) From: Carsten Bormann Date: Tue, 21 Aug 2012 19:34:41 +0300 To: "Romascanu, Dan (Dan)" Cc: "" Subject: Re: [coman] FW: New Non-WG Mailing List: solace -- Smart Object LifecycleArchitecture for Constrained Environments discussion list X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:35:19 -0000 yes. I kicked this off at the end of IETF 84 in the ROLL meeting, but time w= as too short before my vacation started to properly initiate work on this. = For now, please view slides/minutes of ROLL. I hope to do a proper kick-off w= hen I'm back on September 1st. Sorry for this hiatus. How do COMAN and SOLACE relate? I hope a lot. SOLACE is probably more abou= t the lifecycles and the architecture for asserting and maintaining ownershi= p and authorization, less about day-to-day management. But one of the jobs o= f SOLACE will be to find out which of the large set of existing components c= an be put together to do the work for one or more scenarios. So I hope we h= ave a better answer once we have moved forward a bit. Sorry for the terseness, but an iPod is a rather painful platform for long e= -mail... Sent from Mobile On 21.08.2012, at 19:23, "Romascanu, Dan (Dan)" wrote: > Does anybody know more about this activity and does anybody have an opinio= n about how it related to coman?=20 >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.or= g] On Behalf Of IETF Secretariat > Sent: Thursday, August 16, 2012 6:27 PM > To: IETF Announcement List > Cc: cabo@tzi.org; solace@ietf.org > Subject: New Non-WG Mailing List: solace -- Smart Object LifecycleArchitec= ture for Constrained Environments discussion list >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: solace@ietf.org > Archive: http://www.ietf.org/mail-archive/web/solace/ > To subscribe: https://www.ietf.org/mailman/listinfo/solace >=20 > Purpose: This list is for discussions relating to kicking off and the init= ial work on the "Smart Object Lifecycle Architecture for Constrained Environ= ments" (SOLACE) initiative. There is a need for standardization work around t= he setup processes ("instilling its meaning in life") and bootstrapping secu= rity of smart objects, cf. the Paris Smart Object Security workshop (see htt= p://www.ietf.org/proceedings/83/slides/slides-83-saag-3.pdf). The IETF so f= ar has bounced around the related work between working groups such as 6LoWPA= N, ROLL, or CoRE, without achieving tangible process, and this initiative se= eks to find a more focused home for it, likely spinning off some related wor= k to other working groups. >=20 > For additional information, please contact the list administrators. > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From hannes.tschofenig@gmx.net Tue Aug 21 09:38:54 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CB821F862B for ; Tue, 21 Aug 2012 09:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqdp3jMBBUuG for ; Tue, 21 Aug 2012 09:38:54 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8AD2021F8534 for ; Tue, 21 Aug 2012 09:38:53 -0700 (PDT) Received: (qmail invoked by alias); 21 Aug 2012 16:38:52 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 21 Aug 2012 18:38:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Qzb0zK/MQ+eK92ByBvSKK56qNKpywJePyvJOfL5 XTQJvm5sasxpWC Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 21 Aug 2012 19:38:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: coman@ietf.org, Hannes Tschofenig Subject: Re: [coman] FW: New Non-WG Mailing List: solace -- Smart Object LifecycleArchitecture for Constrained Environments discussion list X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:38:54 -0000 During the March 2012 Smart Object Security workshop we had a discussion = about imprinting, associating access control policies with the device, = and change of ownership of a device.=20 During the workshop we said that we should get some standardization work = started in that area (given that specific protocol mechanisms were = proposed and extensively discussed).=20 Carsten, as it seems, has pushed the ball forward. Good to see that = happening.=20 Ciao Hannes PS: We are working on the workshop report and it will discuss these = issues.=20 Sorry for the long delay.=20 On Aug 21, 2012, at 7:23 PM, Romascanu, Dan (Dan) wrote: > Does anybody know more about this activity and does anybody have an = opinion about how it related to coman?=20 >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org = [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: Thursday, August 16, 2012 6:27 PM > To: IETF Announcement List > Cc: cabo@tzi.org; solace@ietf.org > Subject: New Non-WG Mailing List: solace -- Smart Object = LifecycleArchitecture for Constrained Environments discussion list >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: solace@ietf.org > Archive: http://www.ietf.org/mail-archive/web/solace/ > To subscribe: https://www.ietf.org/mailman/listinfo/solace >=20 > Purpose: This list is for discussions relating to kicking off and the = initial work on the "Smart Object Lifecycle Architecture for Constrained = Environments" (SOLACE) initiative. There is a need for standardization = work around the setup processes ("instilling its meaning in life") and = bootstrapping security of smart objects, cf. the Paris Smart Object = Security workshop (see = http://www.ietf.org/proceedings/83/slides/slides-83-saag-3.pdf). The = IETF so far has bounced around the related work between working groups = such as 6LoWPAN, ROLL, or CoRE, without achieving tangible process, and = this initiative seeks to find a more focused home for it, likely = spinning off some related work to other working groups. >=20 > For additional information, please contact the list administrators. > _______________________________________________ > coman mailing list > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman From ulrich@herberg.name Wed Aug 22 15:09:23 2012 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C866321F8686 for ; Wed, 22 Aug 2012 15:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF0i-Mu7yU-a for ; Wed, 22 Aug 2012 15:09:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8BA421F8644 for ; Wed, 22 Aug 2012 15:09:19 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so106075vbb.31 for ; Wed, 22 Aug 2012 15:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=omrbzaZQ1DXRYFij67xuFSgMBjNEWJrgIgZGlpZ//VY=; b=LPvwHvJSuhHRwdTatqEo5V3rHWXiHEzKh5JcS/yElhQmpY0zmugUUl62vyr0uDg1s/ OS6Pa4jbzJMw8ZiusMneRVvjdFzAUyfsP7JgbSa2GJwi5zSqj68uivLfAOO9RKe8mYuY FDvMEz08xF10aNjvApA1EocFSeGWHp1h9ZEyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=omrbzaZQ1DXRYFij67xuFSgMBjNEWJrgIgZGlpZ//VY=; b=iMpXag1abzPuVC2KbYe3/mI8Lz9ctAHxBg57L+Gc+kjyqVYqCLqqpgh782mQEk4R1A eytv4FsiO1qq7Eg3QlQl5jnCW4vdsKcXQ8PPEWgeWi/KG0Acj+pWzoKi9khOhkEP2+67 w6x3GamokJdaQFJC5q/maVeAeq53829u+k+FJS3SG+OHdrftrCEG+shPxPCidP1NXeSr uPWjv4peSIBaFgfw73YUy0ocS7g/QDnLj7Bb12tvHHQKybHku7CgnX6k2b1n3kB1vfnI KPghOQxECHyjNHNFcJsXe5FvLX3ZUwhOkfP1aBfkYEpmvnLf79l28RQvuWtL50sv2eMp 6p0Q== MIME-Version: 1.0 Received: by 10.221.11.71 with SMTP id pd7mr18293170vcb.45.1345673357799; Wed, 22 Aug 2012 15:09:17 -0700 (PDT) Received: by 10.58.187.78 with HTTP; Wed, 22 Aug 2012 15:09:17 -0700 (PDT) In-Reply-To: <7CB5848F-CDFA-4634-B8DC-3CC18F50A270@cisco.com> References: <7CB5848F-CDFA-4634-B8DC-3CC18F50A270@cisco.com> Date: Wed, 22 Aug 2012 15:09:17 -0700 Message-ID: From: Ulrich Herberg To: "Gilman Tolle (gtolle)" Content-Type: multipart/alternative; boundary=bcaec54fb0c079b1e804c7e1fe8e X-Gm-Message-State: ALoCoQnJkDZ2HNFc68eu2eiH/GYtsnAbvEtvV3lo4wqEhTFzthV4TEhCQNLW5tzqvPUVZUctEQgM Cc: "coman@ietf.org" Subject: Re: [coman] Automated Metering Infrastructure (AMI) use case X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:09:23 -0000 --bcaec54fb0c079b1e804c7e1fe8e Content-Type: text/plain; charset=ISO-8859-1 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) wrote: > Hi all, > > I've been developing a constrained device network management application > for my customers, and I've been following the COMAN list. > > I support the work that's happening here, and am ready to help improve it. > > Automated Metering Infrastructure (AMI) is one use case that should be > added to the requirements document. Here is some text that describes this > use case, as well as some constrained network management requirements > derived from it. > > I'm not at the IETF this week, but will be participating in the COMAN > effort via the mailing list. > > Gil > > Automated Metering Infrastructure (AMI) Use Case > ------------------------------------------------ > > An AMI network enables an electric utility to retrieve frequent electric > usage data from each electric meter installed at a customer's home or > business. With an AMI network, a utility can also receive immediate > notification of power outages when they occur, directly from the electric > meters that are experiencing those outages. In addition, if the AMI network > is designed to be open and extensible, it could serve as the backbone for > communicating with other distribution automation devices besides meters, > which could include transformers and reclosers. > > In this use case, each meter in the AMI network contains a constrained > device. These devices are typically Class 2 devices. Each meter connects to > a constrained mesh network with a low-bandwidth radio. These radios can be > 50, 150, or 200 kbps at raw link speed, but actual network throughput may > be significantly lower due to forward error correction, multihop delays, > MAC delays, lossy links, and protocol overhead. > > The constrained devices are used to connect the metering logic with the > network, so that usage data and outage notifications can be sent back to > the utility's headend systems over the network. These headend systems are > installed in a data center managed by the utility, and may include meter > data collection systems, meter data management systems, and outage > management systems. > > The meters are connected to a mesh network, and each meter can act as both > a source of traffic and as a router for other meters' traffic. In a typical > AMI application, smaller amounts of traffic (read requests, configuration) > flow "downstream" from the headend to the mesh, and larger amounts of > traffic flow "upstream" from the mesh to the headend. But, during a > firmware update operation, larger amounts of traffic might flow downstream > while smaller amounts flow upstream. Other applications that make use of > the AMI network may have their own distinct traffic flows. > > 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". > 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. > 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. There could be other means of establishing confidentiality than a shared key (e.g. using x509 certificates, ...). > This key may be obtained by a meter only after an end-to-end > authentication process based on certificates, or by manual distribution (not that this is what I suggest, but I think we should not restrict too much how the AMI network is set up). > ensuring that only authorized and authenticated meters are allowed to join > the PAN, and by extension, the mesh network as a whole. > > After joining the PAN, each endpoint obtains a private routable IPv6 > address that enables end-to-end communication between the headend systems > and each meter. Why "private" IPv6 address? I believe that in many deployments addresses are statically assigned (because of the lack of standardized autoconfiguration mechanisms). > In this use case, the meters are always "on", What does that mean? Does that consider duty-cycle? > and should have a ping round trip time of roughly 200ms per hop. That depends on the link layer. I would suggest to avoid using precise numbers. > But, due to lossy links and network optimization, not every meter will be > immediately ping-able, I would prefer to not use the word "ping", since this is just an application name. > though eventually every meter will be able to exchange data with the > headend. > > In a large AMI deployment, there may be 10 million meters supported by > 10,000 routers, spread across a very large geographic area. Within a single > PAN, the meters may range between 1 and 20 hops from the router. > That seems to preclude deployments with hop counts of 21. > > During the deployment process, these meters are installed and turned on in > large batches, and those meters must be authenticated, given addresses, and > provisioned with any configuration information necessary for their > operation. During deployment and after deployment is finished, the network > must be monitored continuously and failures must be handled. Configuration > parameters may need to be changed on large numbers of devices, but most of > the devices will be running the same configuration. And, eventually, the > firmware in those meters will need to be upgraded, and this must also be > done in large batches because most of the devices will be running the same > firmware image. > > Because there may be thousands of routers, this operational model (batch > deployment, automatic provisioning, continuous monitoring, batch > reconfiguration, batch firmware update) should also apply to the routers as > well as the constrained devices. The scale is different (thousands instead > of millions) but still large enough to make individual management > impractical for routers as well. > > 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. > > 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 > coman@ietf.org > https://www.ietf.org/mailman/listinfo/coman > --bcaec54fb0c079b1e804c7e1fe8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gilman,

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

On Tu= e, Jul 31, 2012 at 5:10 PM, Gilman Tolle (gtolle) <gtolle@cisco.com>= wrote:
Hi all,

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

I support the work that's happening here, and am ready to help improve = it.

Automated Metering Infrastructure (AMI) is one use case that should be adde= d to the requirements document. Here is some text that describes this use c= ase, as well as some constrained network management requirements derived fr= om it.

I'm not at the IETF this week, but will be participating in the COMAN e= ffort via the mailing list.

Gil

Automated Metering Infrastructure (AMI) Use Case
------------------------------------------------

An AMI network enables an electric utility to retrieve frequent electric us= age data from each electric meter installed at a customer's home or bus= iness. With an AMI network, a utility can also receive immediate notificati= on of power outages when they occur, directly from the electric meters that= are experiencing those outages. In addition, if the AMI network is designe= d to be open and extensible, it could serve as the backbone for communicati= ng with other distribution automation devices besides meters, which could i= nclude transformers and reclosers.

In this use case, each meter in the AMI network contains a constrained devi= ce. These devices are typically Class 2 devices. Each meter connects to a c= onstrained mesh network with a low-bandwidth radio. These radios can be 50,= 150, or 200 kbps at raw link speed, but actual network throughput may be s= ignificantly lower due to forward error correction, multihop delays, MAC de= lays, lossy links, and protocol overhead.

The constrained devices are used to connect the metering logic with the net= work, so that usage data and outage notifications can be sent back to the u= tility's headend systems over the network. These headend systems are in= stalled in a data center managed by the utility, and may include meter data= collection systems, meter data management systems, and outage management s= ystems.

The meters are connected to a mesh network, and each meter can act as both = a source of traffic and as a router for other meters' traffic. In a typ= ical AMI application, smaller amounts of traffic (read requests, configurat= ion) flow "downstream" from the headend to the mesh, and larger a= mounts of traffic flow "upstream" from the mesh to the headend. B= ut, during a firmware update operation, larger amounts of traffic might flo= w downstream while smaller amounts flow upstream. Other applications that m= ake use of the AMI network may have their own distinct traffic flows.

The mesh network is anchored by a collection of higher-end devices which co= ntain a mesh radio that connects to the constrained network as well as a ba= ckhaul 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 &= quot;routers" in this use case)

=A0

I am not sure this term is clearly differentiati= ng 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&qu= ot;/"border gateway"? I think that later in the text you use &quo= t;headend".


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

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

=A0

In this use case, the utility typically installs on the order of 1000 meter= s 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 th= e optimal meters in that PAN to route through when sending data to the head= end. After joining the PAN, the meter is designed to continuously monitor a= nd optimize its connection to the PAN,=A0
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 defaul= t route.

=A0
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 confidenti= ality for all data traffic within the PAN.

There coul= d be other means of establishing confidentiality than a shared key (e.g. us= ing x509 certificates, ...).
=A0
This key may be obtained by a meter= only after an end-to-end authentication process based on certificates,

or by manual distribution (not that this is what I suggest, but I = think we should not restrict too much how the AMI network is set up).
= =A0
ensuring that only authorized and authenticated meters are allowed to join = the PAN, and by extension, the mesh network as a whole.

After joining the PAN, each endpoint obtains a private routable IPv6 addres= s that enables end-to-end communication between the headend systems and eac= h meter.

Why "private" IPv6 address? I beli= eve that in many deployments addresses are statically assigned (because of = the lack of standardized autoconfiguration mechanisms).

=A0
In this use case, the meters ar= e always "on",

What does that mean? Does th= at consider duty-cycle?
=A0
and should have a ping round trip t= ime of roughly 200ms per hop.

That depends on the lin= k layer. I would suggest to avoid using precise numbers.
=A0
But, due to lossy links and network= optimization, not every meter will be immediately ping-able,
=

I would prefer to not use the word "ping", since this is just= an application name.


=A0
th= ough eventually every meter will be able to exchange data with the headend.=

In a large AMI deployment, there may be 10 million meters supported by 10,0= 00 routers, spread across a very large geographic area. Within a single PAN= , the meters may range between 1 and 20 hops from the router.

That seems to preclude deployments with hop counts of 21.

= =A0

During the deployment process, these meters are installed and turned on in = large batches, and those meters must be authenticated, given addresses, and= provisioned with any configuration information necessary for their operati= on. During deployment and after deployment is finished, the network must be= monitored continuously and failures must be handled. Configuration paramet= ers may need to be changed on large numbers of devices, but most of the dev= ices will be running the same configuration. And, eventually, the firmware = in those meters will need to be upgraded, and this must also be done in lar= ge batches because most of the devices will be running the same firmware im= age.

Because there may be thousands of routers, this operational model (batch de= ployment, automatic provisioning, continuous monitoring, batch reconfigurat= ion, batch firmware update) should also apply to the routers as well as the= constrained devices. The scale is different (thousands instead of millions= ) but still large enough to make individual management impractical for rout= ers as well.

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 m= ay fall outside the typical definition of "network management system&q= uot; 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 bett= er fitting in the new IETF discussion group SOLACE.
=A0

1. Securely authenticate a large number of constrained devices as they atte= mpt 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 device= s after they have joined the network.

3. Support group-based provisioning and coordinated reconfiguration of a la= rge-scale network of constrained devices with automatic synchronization and= eventual consistency to handle lossy links and temporarily unavailable dev= ices.

4. Collect network status, performance metrics, and fault event information= for a large-scale network of constrained devices into a central location w= ith user interfaces that enable monitoring and troubleshooting of large net= works (millions of devices) by a single person or small team.

5. Support group-based firmware update of those constrained devices, with e= ventual 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 si= ngle network, including constrained mesh endpoints and less constrained rou= ters.

Best
Ulrich

=A0


_______________________________________________
coman mailing list
coman@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/coman

--bcaec54fb0c079b1e804c7e1fe8e--