VESA Home Networks "RFI"

[Paul Walker <paul@xxxxxxxxxxxxxxxxxx>]

Draft 0 Response to VESA Home Networks RFI on protocols for the Home
Network.

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

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

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

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 
occam processes?)

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

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?

and finally

Does it make sense, or am I talking rubbish?

Am I flogging a dead horse?

Paul
-- 
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