Re: [recipe] Application layer

Bruce Nordman <bnordman@lbl.gov> Tue, 16 February 2010 07:33 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 339F03A7171 for <recipe@core3.amsl.com>; Mon, 15 Feb 2010 23:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 K3h1Ki85Ii+x for <recipe@core3.amsl.com>; Mon, 15 Feb 2010 23:33:44 -0800 (PST)
Received: from ironport1.lbl.gov (ironport1.lbl.gov [128.3.41.47]) by core3.amsl.com (Postfix) with ESMTP id D73B03A7A96 for <recipe@ietf.org>; Mon, 15 Feb 2010 23:33:44 -0800 (PST)
X-Ironport-SBRS: None
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAK/ZeUtLZVjT/2dsb2JhbACbGHWxUgmMfYJigXkEgxQ
X-IronPort-AV: E=Sophos; i="4.49,482,1262592000"; d="scan'208,217"; a="127537284"
Received: from 75-101-88-211.dsl2dy.lmi.net (HELO bruce-nordmans-computer.local) ([75.101.88.211]) by ironport1.lbl.gov with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2010 23:35:16 -0800
Message-ID: <4B7A4A6C.5050209@lbl.gov>
Date: Mon, 15 Feb 2010 23:34:04 -0800
From: Bruce Nordman <bnordman@lbl.gov>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: recipe@ietf.org
References: <C2AFA516-0CBE-4326-8004-C0129AD03CDE@cs.columbia.edu>
In-Reply-To: <C2AFA516-0CBE-4326-8004-C0129AD03CDE@cs.columbia.edu>
Content-Type: multipart/alternative; boundary="------------040501090202060702050208"
Subject: Re: [recipe] Application layer
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: Tue, 16 Feb 2010 07:33:46 -0000

This email to cover Tom and JP's comments, and fill in some background.

On 2/11/10 7:55 PM, Henning Schulzrinne wrote:
> Bruce Nordman and I have been discussing whether we should re-convene a Bar BOF in Anaheim, focusing on topics beyond the usual Zigbee-vs.-IPv6 or LowPAN discussions. In particular, I think that the current stovepipe application layers (e.g., in BACS and the other control-oriented building networks) are not very helpful as a *long-term architecture*. We also might want to think about the interfaces that need to be exposed - we don't want our architecture to look like the 3GPP diagram... (If you've taken a look at the NIST interface diagram for the smart grid, this comparison is not purely theoretical, although obviously the protocols are completely different.)
>
> Does this sound like something of interest?
>   
A key point in this (emphasis added above) is "*long-term architecture*" 
- in contrast
to efforts for near-term deployment (next month or next year).  My 
heuristic for planning
horizon is to target what networks we want to have in 20 years, then 
work backwards
to determine what has to be in place when to realize that.

Zigbee Smart Energy 2.0 is probably what people should use in the 
near-term, and
I would characterize it as "digitizing current functionalities".  The 
Bar BOF would
address a different topic - what architecture do we need/want to enable 
much different
and better functionalities in the future.

As an analogy, I think of SE 2.0 as like basic FTP - it was (and still 
is) useful,
and emerged early on.  What I have in mind is more analogous to rich web 
content.
Sure in both cases you are transferring data, but the user experience - 
and necessary
architecture - are enormously different.  We should not have burdened 
FTP design
with web issues, and not have tried to constrain the web by FTP.

As an issue of architecture, we need to consider what will be the key 
layers for
networking the physical world (organized around building networks), 
including the
data model(s) and the role of people as active nodes on the network, 
with a need
for standard interfaces.  Also in play are institutional issues - does 
IETF play any
role in this?  ISOC? what other orgs?

I assume most of the existing IETF (and related) work in this area as a 
given.  The only
topic I think may need updating from an architectural standpoint is 
discovery, to
ensure that physical context is part of that.  The Bar BOF I hope will 
focus on higher
layers.

The comments seem to primarily note that we should not attempt to plow 
ground
already being addressed in other contexts.  I think Henning and I would 
completely
agree.  I don't see any current process which addresses long-term needs, 
and it
seem clear that they are quite different from those in the near-term.

A "smart grid" presentation of mine is on my web page (below).

--Bruce
> (There is some work in the SIP Forum context, but this is not [just] about a particular protocol.)
>
> Henning
> _______________________________________________
> recipe mailing list
> recipe@ietf.org
> https://www.ietf.org/mailman/listinfo/recipe
>   

-- 
Bruce Nordman
Lawrence Berkeley National Laboratory
BNordman@LBL.gov -- 510-486-7089
eetd.lbl.gov/ea/nordman/