Subject: [recipe] Application layer

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 11 Feb 2010 22:55:44 -0500

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?

(There is some work in the SIP Forum context, but this is not [just] about a particular protocol.)

Henning

---

From: Tom Herbst <[email-masked]>
Date: Fri, 12 Feb 2010 00:25:35 -0800 (PST)

Not sure I understand Zigbee vs v6/lowpan since all of the
work being done on Smart Energy 2.0 is v6/6lowpan and 
either tcp/http or COAP provided RESTful api.

Several of the people defining this will be in Anaheim. 

tom

--- On Thu, 2/11/10, Henning Schulzrinne <[email-masked]> wrote:

> From: Henning Schulzrinne <[email-masked]>
> Subject: [recipe] Application layer
> To: [email-masked]
> Date: Thursday, February 11, 2010, 7:55 PM
> 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.)
> 
> _______________________________________________
> recipe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/recipe
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 12 Feb 2010 19:54:10 +0100

Hi,

> Several of the people defining this will be in Anaheim.

+1. SE 2.0 brings the convergence that we were looking for.
SE 2.0 is using IP.

JP.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Feb 2010 14:31:17 -0500

Who defines/defined "SE 2.0"?

---

From: JP Vasseur <[email-masked]>
Date: Fri, 12 Feb 2010 20:35:12 +0100

The Zigbee alliance.

---

From: Tom Herbst <[email-masked]>
Date: Fri, 12 Feb 2010 18:49:43 -0800 (PST)

Zigbee is doing the heavy lifting in terms of putting
the pieces together, but it is intended to be all 
standards based elements including data elements from 
the IEC CIM (IEC 61968).   

I doubt the output will be prefect, but the effort is good
enough that a completely parallel effort seems silly.  

I might even be willing to buy beer for a bar BOF where 
the people working on SE 2.0 introduce their work and look for
assistance.  Service discovery has been especially tricky.  
Just do mDNS is an easier discussion on devices beyond
802.15.4, sometimes sleeping or otherwise constrained devices. 

tom

--- On Fri, 2/12/10, JP Vasseur <[email-masked]> wrote:

> From: JP Vasseur <[email-masked]>
> Subject: Re: [recipe] Application layer
> To: "Henning Schulzrinne" <[email-masked]>
> Cc: [email-masked], "Tom Herbst" <[email-masked]>
> Date: Friday, February 12, 2010, 11:35 AM
> The Zigbee alliance.
> 
> >>> --- On Thu, 2/11/10, Henning Schulzrinne
> <[email-masked]> 
> 
> >>> wrote:
> >>>
> >>>> (There is some work in the SIP Forum
> context, but this is
> >>>> not [just] about a particular protocol.)
> >>>>
> >>>> Henning
> >>>>

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 15 Feb 2010 23:34:04 -0800

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.)
>
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

-- 
Bruce Nordman
Lawrence Berkeley National Laboratory
[email-masked] -- 510-486-7089
eetd.lbl.gov/ea/nordman/