[recipe] Scope, projects
Bruce Nordman <bnordman@lbl.gov> Thu, 26 March 2009 20:27 UTC
Return-Path: <bnordman@lbl.gov>
X-Original-To: recipe@core3.amsl.com
Delivered-To: recipe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4AD3A6C28 for <recipe@core3.amsl.com>; Thu, 26 Mar 2009 13:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.869
X-Spam-Level:
X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIX9V2aPPnvX for <recipe@core3.amsl.com>; Thu, 26 Mar 2009 13:27:27 -0700 (PDT)
Received: from ironport3.lbl.gov (ironport3.lbl.gov [128.3.41.25]) by core3.amsl.com (Postfix) with ESMTP id 131453A6867 for <recipe@ietf.org>; Thu, 26 Mar 2009 13:27:27 -0700 (PDT)
X-Ironport-SBRS: 3.3
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsBAC+Cy0mAAykYhWdsb2JhbACCU5MuAQEBCgsKGAWvPgmOfYI0EIEzBg
X-IronPort-AV: E=Sophos; i="4.38,428,1233561600"; d="scan'208,217"; a="12198002"
Received: from mta1.lbl.gov ([128.3.41.24]) by ironport3.lbl.gov with ESMTP; 26 Mar 2009 13:28:20 -0700
Received: from eapmac9.lbl.gov (eapmac9.lbl.gov [128.3.13.159]) by mta1.lbl.gov (8.13.8/8.13.8) with ESMTP id n2QKSKIp022613; Thu, 26 Mar 2009 13:28:20 -0700 (PDT)
Message-ID: <49CBE565.2090206@lbl.gov>
Date: Thu, 26 Mar 2009 13:28:21 -0700
From: Bruce Nordman <bnordman@lbl.gov>
Organization: LBNL
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: recipe@ietf.org
Content-Type: multipart/alternative; boundary="------------000203090506020509040006"
Cc: christen@cse.usf.edu
Subject: [recipe] Scope, projects
X-BeenThere: recipe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <recipe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/recipe>
List-Post: <mailto:recipe@ietf.org>
List-Help: <mailto:recipe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2009 20:27:28 -0000
Hi all-- First off, many thanks to Henning for organizing last night's bar BOF and to all of you for listening to my take on things. On my way over to SF yesterday I wrote down: My Goals: - Establish Building Networks as a distinct topic area (and name) - Get some IETF people interested and involved - Get large NSF program established on topic - Proposal: Create Building Network Task Force (BNTF) as sibling to IETF under ISoc Building Network Scope - Nothing special layers 1-4 - Adopt goal of "Universal Interoperability" - Common semantic model for buildings - reflect in UI -draw from this to create model - embed in protocols - Building networks start with "human scale" - can then scale up from that to entire buildings (doesn't work to start with whole building). I am not set on any particular institutional relationship for defining future building networks (that are dynamic, robust, highly functional, and energy efficient); I'm for what works. I suggest that an official 2-track approach is needed. The first is for what can be done today, mostly (or entirely) building on existing protocols. The second is more of a clean slate exercise (again, only layer 5 and up), to define an architecture for building networks, the semantic context, the user interface, and then finally the protocols that implement all of it. The latter will of course take considerable time. Stuart's Measurement (1a) topic seems well-defined and suitable to a quick result. Before dinner, Juergen and Henning both referenced SNMP as a possible approach to this. Ken Christensen of USF proposed this more formally last fall as a "Power MIB", currently item 7 on: http://www.csee.usf.edu/~christen/energy/pubs.html Along these lines, the Energy Star server specification (in development) : "Will require that ENERGY STAR servers have greater ability to monitor and report their power consumption, input air temperature and processor utilization through standard network" (March 16 slides) The Draft 4 of the spec discusses this extensively on page 17 and 18, including noting: "Data must be made available in an open format so as to be readable by third party (non-proprietary) management systems." Energy Star wasn't able to find a suitable standard to reference specifically. IETF could fill this void so that the next version (Tier 2) of the server spec (and other products in future) could reference an SNMP Power MIB as a requirement. The Power MIB Ken describe is oriented to IT products. A much smaller subset of this could be defined for things like lights and appliances; this should probably also include some assessment of accuracy of the value, as for many purposes great accuracy is not required and may not be worth the expense. For control in the short-term, much can be accomplished by simply having a broadcast service for the electricity price, both current, and forecast (e.g. for the next 24 hours), along with other useful information like outdoor temperature (current and forecast) --I believe this would cover Stuart's items 2 and 3. A suitably secure way to do this would be useful; the information could come via the utility/meter, or other ways; probably best if one device in the building was the "price server" for the rest. This could be combined/coordinated with demand response signals, or might be more easily done separately (the DRRC people Chris Lonvick mentioned are upstairs from me). This also seems relatively well-contained, since each device would decide what to do on its own and no coordination among them is required. For what to do generally in the short term for inter-device control (1b), I think it is much less clear, as it is much more complicated and one necessarily begins to define a lot of concepts and capabilities. Worth talking about though. For climate change purposes, I think what is most important is the long-term process of defining a new architecture, etc. I think there will be much more networking of buildings done in 2020-2030 than between now and 2020, so more important to get that design right than to get it done fast. This is the topic I am most focused on, though the others also interest me. It is extremely unlikely that I could be at IETFs in Stockholm or Hiroshima, but I would like to reconnect next March in Anaheim, and of course by email (and phone) in the interim. For what I am up to, my web page: http://eetd.lbl.gov/ea/nordman/ has links to the Efficient Networks projects I am involved in, particularly enabling network-connected devices like PCs to go to sleep but still stay "fully" connected to the network. I think this can save more energy that all network equipment put together. Other aspects of that are Energy Efficient Ethernet. I also have some of my work on Building Networks as "Recent Talks" or the "Buildings as Networks" page. Thanks again, --Bruce -- Bruce Nordman BNordman@LBL.gov 510-486-7089 Lawrence Berkeley National Laboratory http://eetd.lbl.gov/ea/nordman/
- [recipe] Scope, projects Bruce Nordman