[ Date Next]
[ Date Prev]
[Thread Prev][Thread Next][Date Index][Thread Index]
Update (draft 0.0a) of STRAWMAN architecture/problem statement
Folks,
Based on discussions today (thanks to everyone who got involved), I have
made some minor changes to the strawman architecture (in figure 1). The
updated document is attached (see file ipac-problem-00a.txt). Only section
2 is affected.
1. the Internet Gateway has been removed altogether, as have notions of a
'home' environment
2. an IPA location service has been added to the architecture
Please review the new draft and post your comments to the mailing list.
Thanks,
Simon
+1.973.829.4511
Internet Personal Appliance Control (IPAC)
Problem Statement (Strawman) draft 0.0a
Simon Tsang, March 28, 2001.
stsang@research.telcordia.com
1. Introduction
There has been a lot of discussion about Internet Personal Appliance
Control (IPAC), and an IPAC BoF was held at IETF 50 to focus this
discussion. This document represents the author’s attempt to address
some of the points and issues raised at the BoF and subsequent
discussions. For reference, [8] provides some more background
information on IPAC.
This document is a STRAWMAN and is therefore intended to be roundly
flamed and torn apart for the purposes of discussion. Please post
comments to the Appliances mailing list at:
appliances@research.telcordia.com.
(To subscribe to this list, either go to the Appliances Research web
page: http://www.argreenhouse.com/iapp/ipac or send an e-mail with
subject ‘subscribe’ to appliances-request@research.telcordia.com.)
2. STRAWMAN: IPAC Reference Architecture
In order to put some kind of context around the notion of IPAC, we
need to have a reference architecture. Figure 1 provides a strawman
architecture.
+------------+
+--------|IPA location|<--------------+
| |Service |<---------+ |
| +------------+ | |
| (b) | | (c)
| +---+ |
V +-->|IPA| |
+-----------+ | +---+ |
|Controlling|<----------------------+ |
|Application|<----------------------+ |
+-----------+ | +-------+ +------+
+-->|IPA | |Legacy|
|Gateway|- - - |IPA |
+-------+ +------+
<-------------------------> <---->
(a) IPAC protocols (d) legacy protocols
Figure 1: IPAC reference architecture
S. Tsang et al [Page 1]
IPAC Problem Statement draft 0.0 March 27, 2001
IPAC protocols will be employed by applications sending commands over
the Internet to IPAs in the home environment. In cases when ‘legacy’
IPA technologies are deployed in the home environment, an IPA Gateway
may provide application-layer, transport-layer, network-layer, link-
layer or even physical-layer interworking between IPAC and legacy
protocols (labeled as (d) in Figure 1).
In order to locate and identify IPAs, a controlling application may
employ an IPA location service. The protocol used by this service is
labeled (b) in Figure 1. Correspondingly, some IPAs may be able to
register themselves with the IPA location service when they are
activated or move into different administrative domains. The
protocol used by IPAs (and IPA gateways) is labeled (c) in Figure 1.
3. Why Does the World Need IPAC Anyway?
As with many technical endeavours, the need for Internet Personal
Appliance Control (IPAC) is being highlighted not by real-world
consumers, but by the companies designing and manufacturing IPAs or
researchers interested in the area. To be fair, it must be noted
that the increasing deployment of broadband access to homes, and the
increasing number of homes with LANs and other networking technology
plays a factor in the interest with IPAs. This document does not
therefore attempt to justify work in this area in terms of consumer
interest or potential service offerings, as this is the remit of
marketing organizations.
Having said that, there are some clear technical challenges which may
deserve further attention and study. These are now outlined.
3.1. Interoperability
Far from being a ‘green-field’ research area, there are in fact many,
many competing technologies (and associated protocols) in the
appliances space (and particularly in the home networking space),
some of which are mature and some already deployed. All of these
protocols provide varying degrees of control, and some even provide
device registration and discovery. Many assume a particular physical
or link layer implementation. Some examples of these technologies
include: the UPnP [1] suite of protocols, Jini [2], X.10 [3], IEEE
1394, HAVi [4], VESA Home Networking [5], Bluetooth [6]. There are
also numerous other examples which are not mentioned here.
Since many of these technologies are specialized toward particular
application areas (e.g. audio/video), it seems likely that more than
one technology will eventually be deployed into the user’s
environment (which may be a home, car, office, factory etc.). This
leads to interoperability difficulties, particularly if capabilities
(such as IPA discovery) are available (and assumed) in one
technology, and not present in another.
S. Tsang [Page 2]
IPAC Problem Statement draft 0.0 March 27, 2001
Taking this into consideration, there appears to be a need for a
unifying set of protocols to provide interoperability between the
heterogeneous IPA technologies. Another issue with the existing
technologies is that they work within a single domain and not in the
wide-area or across domains. Therefore, adopting an Internet
application-level protocol for interoperability appears to be
beneficial.
3.2. Fundamental IPAC Operations/Capabilities
There are certain operations (or capabilities) which are necessary
for IPA control. There are now outlined in high level.
1. Getting Command Messages to Actuators:
In order to interact with the physical world, an IPA will comprise
one or more actuators. We must have a means of getting command
messages to these actuators. Furthermore, we must be able to carry
the command messages of all the IPA technologies involved, and this
may involve carrying a variety of encoding schemes, presentations and
formats. Many applications will also require responses to command
requests to arrive within specific time constraints.
2. Getting Notifications/Subscriptions from Sensors:
IPAs may comprise sensors which provide information on the physical
world (e.g. temperature or motion sensors). We must have a means of
specifying when or what information to retrieve from the sensors, and
a means for retrieving this information. It is generally more
efficient (in terms of network traffic) if this information can be
sent asynchronously by the IPAs themselves, rather than requiring an
application to ‘poll’ the IPAs.
3. Identifying an IPA:
We need to have a means of uniquely identifying a particular IPA, and
perhaps in some cases, sets or groups of IPAs. Conversely, this may
impose a requirement on IPAs to identify themselves when they are
activated or interrogated.
4. Can’t We Just Use Using Existing Protocols?
The answer to this question is PERHAPS. We need to perform a
detailed requirements study, once consensus is reached on the
strawman architecture, to determine if existing protocols are
applicable to IPAC.
5. Outstanding Issues
S. Tsang [Page 3]
IPAC Problem Statement draft 0.0 March 27, 2001
- Security, and access management: how can we restrict what the
controlling application can do within the home environment?
- IPA mobility: when an IPA moves to another domain, how will the
security and access management issues be managed?
- Do IPAs conform to RFC 1122 and RFC 1123?
(There are probably many others, but these ones spring to mind
immediately.)
6. Some More Reading Material
[1] UPnP, http://www.upnp.org
[2] Jini, http://www.jini.org
[3] X.10, http://www.x10.org
[4] HAVi, http://www.havi.org
[5] ‘VHN Home Network,’ EIA 851, See http://www.vesa.org for further
information.
[6] Bluetooth, http://www.bluetooth.com
[7] Salutation, http://www.salutation.org
[8] S. Tsang et al, ‘Internet Personal Appliance Control (IPAC)
Discussion’, Internet Draft, March 2000.
http://www.ietf.org/internet-drafts/draft-tsang-appliances-
discuss-00.txt
S. Tsang [Page 4]