[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
VESA Home Networks "RFI"
Draft 0 Response to VESA Home Networks RFI on protocols for the Home
The VESA Home Networks working group has put out what they call an RFI,
(Request for Input?) on protocols for the home network. The RFI can be
found at URL ftp://ftp.lexmark.com/pub/vostpub/index.html
which refers to a couple of image files in the same directory.
In some respects, we should probably let them continue. While they ask
many useful questions in the RFI, they say that they have already
decided to use 1394 as "the backbone" of the network, and Colin can
testify to the weight of support for that decision --- whether it is
sensible or not.
Because I believe not only that 1355 is a much better solution but also
that they will come to regret the 1394 decision, I sent out today a note
comparing 1394 with the factories of the 1950s, before the manufacturing
and quality revolutions which brought the Japanese consumer goods
companies their domination. It is ironic that it is these same companies
who are supporting technology that their manufacturing colleagues would
have thrown out 40 years ago.
(if you are not on the ieee-hic reflector and would like a copy of the
analogy note, it is at URL http://www.walker.demon.co.uk/1394anlg.txt)
The VHN RFI gives the occam/transputer/1355 community an opportunity,
and so I have agreed to respond to it. As the response needs to be in by
the end of March and I am away next week, here is a short description of
what I'd like to respond with, and some questions that probably need
We could, of course, go in with occam channels as THE protocol and 1355
as the means of carrying them, but that would not exactly be politically
The protocols they want include how traffic is sent around the network,
and how the network is configured. We have an opportunity with both of
Currently, "plug and play" configuration is normally done by defining a
set of registers in an address space, so called "CSRs" (Control and
Status Registers). PCI has these and they are specific to the PC so that
a PCI board needs a different set of EEPROMs to work in anything other
than a PC. For anything else they don't actually use the CSRs, but use a
program written in FORTH, a technique borrowed from SUN's SBus boards.
We can argue, and will in our response to the RFI, that the CSR approach
is unacceptable on the grounds of privacy and security in the home
network. The FORTH solution at least has the benefit of running on
heterogeneous machines, but is also insecure.
(The following paragraph has been provided by Peter Welch)
We therefore propose an adaptation of SUN's FORTH/OpenBoot
mechanism to use SUN's secure language JAVA instead of FORTH. A class
library providing high-level primitives for thread communication and
synchronisation is added to the basic JAVA language. These primitives
upgrade Java semantics from Hoare's Monitors to Hoare's CSP, giving
explicit control of non-determinacy and considerably easing the task
of programming concurrent and distributed applications. The combination
language and class library is referred to as JavaPP.
Many components on the network will have processing power enough to
process the configuration applet. A nice feature of the applet though is
that if there are no resources at the node to process it, it can be
shipped to another node for processing and the results shipped back. It
may, indeed, be desirable to consider the applet model more widely than
for configuration, but I'd prefer to leave it as with occam that a
channel, once set up, follows a protocol understood by the two ends with
complete freedom as to what that protocol actually is.
For the network routing protocol, we propose to use Path Identifiers and
Channel Identifiers like ATM's VPI and VCI, with the exception that
within the bounds of the home network they do not need to be virtual. We
also use them very much like the URLs of the www, except perhaps they
are best seen back-to-front. For example there could be a path ID
Kitchen.Closet.LightSwitch, where the Kitchen component of the URL is
stripped as soon as it is used, and so on until the whole of the Path ID
is stripped. At each node there is then at least one configuration
channel, which holds the configuration applet, and one or (many) more
operation channels, which may of course themselves used to multiplex
further groups of channels a la URL.
Of course the JavaPP is very heavily based on occam, and is inferior to
occam in many respects, but we might get an audience with JavaPP which
we would never get with occam. And the routing protocol is exactly what
Barry Cook and I have filed as a patent application on for a 1355
routing switch, which is currently being designed at Nottingham Trent
University. But again, describing it in terms of ATM and URLs means that
people with other prejudices might have a chance to understand and open
their minds to it.
There are plenty more points in the RFI where the occam/transputer/1355
community has excellent answers which others will find difficulty in
matching, but the JavaPP configuration and the ATM/URL based routing
protocol are probably the strongest USPs.
Discussing this has opened up a whole range of rather exciting
possibilities, such as a light switch or a TV being an "object".
(Remember the discussions we had ten years ago about these things being
Meanwhile I've a number of questions:
What do we do if they like it and say they want it all tomorrow? (WoTUG
might be an opportunity to discuss that as it is just a week after the
What do we do if they like it and go off and develop it all themselves
without further reference (or income) to us?
The heterogeneity of the network is of course ideal for 1355, but
heterogeneity is also what CORBA aims to address. I'm presuming that OMG
as an institution has too much inertia to provide a solution here, and
that CORBA implementations are too big and too slow. Of course for the
configuration, within limits, speed does not matter. So should we be
talking CORBA instead?
Does it make sense, or am I talking rubbish?
Am I flogging a dead horse?
Paul Walker 4Links phone/fax
paul@xxxxxxxxxxxxxxxxxx P O Box 816, Two Mile Ash +44 1908
http://www.walker.demon.co.uk Milton Keynes MK8 8NS, UK 566253