[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/