Re: [6lowapp] Architecture Sketch in Charter

["Don Sturek" <[e-mail]>]

Hi Shidan,

 

All of this sounds fantastic, however:

1)       The Smart Metering work is not going to wait while we sort out all
of this and then figure out what standards we need.

 

The reality is that early smart metering deployments need to start next
year.  We need to figure out how to supply a "Generation 1" solution that
allows scalability.

 

I have provided what we (the ZigBee and utility team) think is
possible/practical for us to deploy in the short term.  If what is proposed
(RESTfull HTTP, Extensions to SLP for tokenization, W3C EXi, etc.) is not a
good starting point, let's discuss. If what you wrote below  builds on what
is proposed for the near term then we are in alignment.   If we have to wait
an extended time to finalize a series of new standards to redefine HAN
automation, then we will miss our window of relevance (at least in my
opinion).


Don

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Shidan
Sent: Saturday, October 31, 2009 3:42 PM
To: Cullen Jennings
Cc: [e-mail]
Subject: Re: [6lowapp] Architecture Sketch in Charter

 

Hi Fluffy, 

 

I definitely agree with your overall sentiment, but one thing that I always
find dissapointing is when people give me the "turn on and off" garage
doors, thermostats, etc as the only examples of what a HAN should be about.
I think this is part of the reason some, specially me, are a little confused
by the WG.

 

The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX,
etc replacement; they do a fine job of turning things on and off. Let me
list a few things I would like in my HAN:

 

1) I want a network that goes beyond enabling me to discover and control a
device to one that enables devices to discover, control and communicate with
each other and mixed groups of devices and people. 

 

2) I want devices to do things based on time and other arbitrary policies as
part of the network

 

3) I want mobile & secure smart objects to take advantage of pervasive
global networks and objects that are location aware.

 

4) I want a system that can evolve so that when it makes economic sense, the
physical components of a smart appliance are "smart components" themselves.
I also see a day when people will be upgrading the features and
functionality of their washing machine through a

firmware upgrade.The last two are probably sound silly now, but they're real
considerations of how things can evolve.

 

The truth of the matter is that even with X10 and gateways, except for
device mobility, most of this is possible. It's further true that the most
difficult challenge of HANs is not the networking but end user
programmability and moving intelligence to the network will help in
developing these systems.

 

Right now, the difficulty I'm having is that it almost seems, and this could
be a wrong interpretation I hope, that this working group is saying "let's
forget about addressing the greater problem of HANs through network
intelligence and let's just focus on satisfying the bare minimum needs of
the energy industry so they can move to IP" and "then we will let the system
evolve." 

 

Another approach could be that this working group could start by considering
the HAN application layers like UPnP and see how they need to evolve for
pervasive access, where they have gone wrong for developers and so on and
then see how much of this better system you define can be brought down to
LoPANs. This is something I think can be done in the time frames this WG has
proposed and anything that comes out of it would work great for the energy
industry as well.

 

Of course, even better would be a general application layer framework for
LoPANS, but since this is technological limitation, I think looking at
requirements is absolutely necessary. 

 

A side note, I definitely think SIP and XMPP are relevant in this field
Cullen, there is a reason why so many M2M applications are using XMPP,
specially in BRIC countries. There is also a reason why the leading demand
response provider is using XMPP today, if you can take this all the way to
the home and on AMI networks then why not? There is also a reason why the
few MSOs and incumbents that I know of who are offering home media
management  and media delivery to connected devices are switching to
SIP-DLNA gateways. Again, this is not even the real issue, who really cares
what you name a protocol as long as it works and the proper requirements
have been considered. My concern above is much more important.

 

Shidan Gouran

 

On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings <[e-mail]> wrote:


Right now the draft charter has a sketch of some of the key parts of the
architecture. I'd like to talk about the pro's and cons of putting this in a
charter. Typically charters don't have this. Many BOFs fail when all the
people in the room don't lave having a common idea of what the group will
do. Typically  the architecture is developed in a draft and often can take
considerable time however there's nothing stopping this type of information
form being in a charter. Now this effort is a bit different from your
typically BOF. Let me list some differences:

1) This is not meant to run on normal networks. We've told the transport
folks, yah, we are going to have to make different assumptions than normal
application protocols make because there some special stuff going on here.
That makes the Transport and INT people very nervous.

2) We told the security people, none of your off the shelf security
approaches will work for us because we have special requirements. We are not
even 100% sure it is feasibly to simultaneously satisfy all the
requirements. That makes the Security people, uh, prickly.

3) Some people have suggest that SIP might be just the thing to build on
over for things like controlling a garage door opener.  Many (but not all)
SIP folks feel that SIP is for User to User communications and often use SIP
to control the garage door and the prototypical example of what should *not*
be done with SIP. This makes the RAI people want to come and say "hi". I'm
not saying we could not use SIP but I am saying the SIP people would want to
come and talk about the issues before that decision got made. Hopefully they
won't ask if any of this has any real time application properties or
infrastructure they could help with.

4) The OAM folks must be thinking, so how is this different from what we do
every single day?

5) The INT and Routing guys want to know how this related to work they are
doing.

6) I've had a few questions that loosely translated to "so what feature of
IPv6 are you using to guarantee that this will only work on a v6 network".

If we told the DNS guys we were consider doing all our senor reading use DNS
so we could leverage the DNS caching we would have pretty much every area
"concerned".

People have questions. Lots of questions. The challenge for a successful BOF
like this is to put together a coherent story of what the big picture looks
like and how it all hangs together. I believe we have a reasonable chance of
having a WG approved if we can show that there is a group of people that
have

1) a clear idea of what they want to build

2) the same common idea of what it is

3) it is an engineering project, and not science project requiring invention
of new techniques

4) it meets the type of requirements the IETF has for standards track work

The quickest way to do this would be to have in some document that we take
into the BOF use cases, requirements, and a high level architecture. We have
drafts with use case and requirements and we can refine theses int he slides
used in the BOF. If we can agree on an architecture, we can stuff that in
the charter.

I'm probably a bit naive to think we can come up with a sketch of an
architecture and agree to it in the BOF. But if we do, we have a chance at
having the a protocol document finished before 2011.

A more tried and true approach to this would be to work on the requirement,
use case, and architecture in some ad-hoc meetings then go for a BOF. The
P2PSIP WG had problems similar to this WG in that they were going to have
some harder than average transport and security issues. They meant for
multiple hours at every IETF for multiple years *before* the WG was
approved. Lots of the meetings had around 100 people with pretty substantial
effort.

Another approach would be to charter just to do requirements then recharter
to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle
of scotch that would not finish before 2011 and even odds on a bottle of
scotch it would not finish before 2012.

Many people have expressed that time is of the essence on this work and
something that delivers in 2012 will be of very little deployment value. I'm
not in a good position to evaluate how quickly something is needed here but
I'm happy to take everything people tell m at when this is needed at face
value.

The sponsoring AD has read me the riot act on scope for the initial set of
work, make this a small bite size chunk that meets a reasonable set of needs
and we can complete quickly. As that completes, I'm sure there would be no
problem re-charting to expand the scope for more things or forming other WG
to take on related work.

So bottom line, I'm trying to drive this to figure out what is small bite
size chunk that everyone could live with for the initial stuff to be worked
on. If we are lucky, we can end up agreeing on requirements, uses cases, and
a high level sketch of the architecture without a long drawn out process.
If this fails, and I admit it very well could, well then we can just move
back to some other way of dealing with this.

A good charter is a plan for work as well as something that constrains the
number of possibilities a WG has to consider. Now clearly we can't constrain
things beyond what is needed. If we can mange to agree on a tight charter,
the WG will be able to progress work very rapidly. If we fail to do this in
the next few week, having tried will not set back the work in any
significant way.

I hope this explains, I'm not  trying to convince anyone the architecture in
the draft is the right one.  I'm just trying to convince people to fix it
before the BOF.

Sorry for such a long email,
Cullen





_______________________________________________
6lowapp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowapp