This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Comments should
be submitted to the appliances@research.telcordia.com
mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use nternet-Drafts
as reference material or to cite them other than as work in
progress.
This document introduces the concept of the Internet Personal
Appliance (IPA) and the relationships between it and control
entities in the Internet for command and control, and communication
purposes.
Within this document a number of issues to be addressed in
the area of IPAs are outlined. This document is not intended
to be an exhaustive treatment of all of these issues, but
merely to introduce them for discussion in the widest possible
context of using Internet protocols to communicate with small
computation and I/O devices.
1.1. What Are Internet Personal Appliances (IPAs)?
The definition of an IPA is difficult in that the exact limitations
of applicability of the term are poorly defined. The authors
consider simple, dedicated purpose, limited configuration,
devices such as washing machines, refrigerators, lamps, and
televisions as IPAs. Other devices such as personal computers
(PCs), workstations, and personal digital assistants (PDAs)
have much more general applicability and higher levels of
configurability and are normally considered as computational
devices. These would not meet the definition of an IPA. Devices
such as Digital Cameras and MP3 players are in the 'grey space'
between an IPA and general purpose device. Of
course, there is no reason why general computation devices
cannot use the capabilities that are defined for IPAs, but
it is important to design for the IPA target.
We consider that Internet Personal Appliances (IPAs) are networked
devices which have the following characteristics:
Dedicated functionality with limited configurability and
optimized user interface - an Internet connected Calculator
might be considered an IPA, a Palm Pilot running a calculator
application would not.
The ability to interact with the physical environment
through sensors and actuators; thus, a Network Attached
Storage (NAS) device would not be considered an IPA.
Limited (or restricted) general purpose computational
power, though the devices may possess high-computation power
for specific tasks such as image processing, or audio processing
as in the case of an MP3 player.
In general, IPAs will be devices with sensors and/or actuators
with limited computational power, but they will always have
some form of permanent or temporary network connectivity.
IPAs may be portable and may provide service in multiple locations.
Some may be mobile and may provide service while stationary
or in transit. Note that these portability and mobility issues
may introduce new constraints or novel operational modes for
specific IPAs - a typical example might be a MP3 player capable
of relaying an Internet Radio Station while stationary and
network connected, but only being able to play cached content
when mobile without any network connection.
Note that IPAs are also known as networked appliances, Internet
appliances, IP appliances, and networked devices. In the following,
we will only discuss the computational and network capabilities
of IPAs and ignore their interaction with the physical environment.
1.2. Where Is the Intelligence?
The capabilities of IPAs span a wide range, from 'fat' IPAs,
which contain sufficient processing power and memory to operate
stand-alone (and perhaps only require network connectivity
to collect new content or to enhance their own functionality),
to 'thin' IPAs which can only operate with the aid of another
network-attached host. We will consider the extremes of this
range in order to illustrate the kinds of IPA support that
may be required.
A fat IPA comprises a network interface, computational capabilities,
embedded software, and I/O. The network interface is required
for communication with the Internet. The software allows the
IPA to operate autonomously, providing a degree of independence
from other devices, the network, and the 'intelligence' for
the device. It may provide its own local or networked user
interface, such as a web server.
Furthermore, the embedded software allows the IPA to interact
with other IPAs or applications through the network interface.
I/O enables the IPA to interact with its environment through
actuators and sensors. This is illustrated in Figure 1.
Anatomy of a fat IPA
Figure 2 shows the modes of operation for this autonomous
IPA. It can communicate as a peer with applications and with
other IPAs. This maybe likened to application/application
interaction and collaboration.
Modes of operation for a fat IPA
A thin IPA (see Figure 3) comprises the same elements as
its fat counterpart but the application is reduced to the
absolute minimum necessary to marshal its I/O capabilities
and to allow it to connect to real application functionality
provided outside of it.
Anatomy of a thin IPA
Figure 4 shows the modes of operation for the thin IPA. Since
it does not offer application level functionality, all intelligence
is provided outside of the IPA, normally by a proxy function.
The IPA executes the commands requested by the proxy.
Modes of operation for thin IPA.
1.3. How Do We Want to Interact with IPAs?
We (people, applications, and other IPAs) will need to interact
with IPAs in many ways. The main reason for interacting with
an IPA is to request a service that the IPA provides. This
service could be:
the type of function for which the IPA was primarily designed,
e.g., 'toast the bread', 'make the coffee', 'turn on the
light', 'set the temperature', 'talk with the desired user'
etc.
reporting the status or state of the IPA, e.g., 'what's
the temperature?', 'is the light on?', 'are there any intruders?',
etc.
a function for which the device was not primarily designed,
but capable of anyway, e.g., using a stereo system for a
network-based alarm clock, displaying a text message/page
on a microwave display.
These types of interactions are at the application layer.
To request an IPA service, we don't need to know the IP address
(or DNS name) of the IPA, but rather the service name. Note
that the service name may include a DNS name as part of the
name. This is analogous to a web page URL.
As discussed in the previous sections, people may interact
directly with an IPA, for example, through an application
on a PC. Interactions with IPAs may be automated by host-based
applications that reside either in the network or at the edge
of the network. These host-based applications could be services
offered to IPA owners. In addition, IPAs may interact with
each other. For example, the alarm clock could turn on the
coffee maker or a rain sensor turn off the lawn sprinkler
system. Since not all interactions will be with human operators,
the ability to interact with IPAs in a 'machine-friendly'
manner is necessary. Thus, simply providing a web page interface
to IPAs is not likely to be sufficient.
The type of communication used when interacting with IPAs
will differ depending on the type of service/application.
Some examples are:
Control of an IPA, e.g., 'turn off the light(s)'. This
type of interaction implies a simple control message sequence
- send a command and get a response back.
Queries to an IPA, e.g., 'is there milk in the refrigerator'
or 'what's the temperature?' This type of interaction also
implies a simple message sequence - send a query receive
a reply.
Notification of an event occurring at an IPA, e.g., 'notify
me when the security alarm goes off' or 'notify me when
someone rings the doorbell'. This type of interaction will
probably require an event based communication mechanism.
Media streaming (or sessions), e.g, 'view the front door
camera' or 'talk with Bob (on the phone)'. Supporting media
streaming will most likely require some sort of mechanism
for establishing sessions (e.g., negotiating participants,
transport parameters, media types,
etc.).
Protocols that support these different types of communication
paradigms will need to be implemented in IPAs and/or IPA controllers
and interworking units.
1.4. Where Will IPAs Be Found?
At a minimum, IPAs require access to the Internet in order
to operate and can be located wherever network connectivity
is available. In particular, home networking [2-4,6] and the
increasing interest in providing internet access in automobiles
makes it likely that homes and automobiles are likely locations
for IPAs. In addition, IPAs may visit networks other than
their own. We describe each environment in turn.
1.4.1 The Home Environment (HE)
Many IPAs will be household items (such as refrigerators, televisions,
AC units, or lamps) and will thus reside within a home environment
(HE). The HE is essentially a private LAN with network layer
access to the Internet through a device such as a Residential
Gateway (RGW). The RGW may include firewall and/or network address
translator (NAT) functionality, effectively partitioning the
HE from the rest of the Internet. NAT and firewalls aim to achieve
security, privacy and IP address conservation. IPAs will use
IP at the network layer for packet communication within the
HE.
There will be many appliances that are based on existing home
networking technologies [2-4,6]. These devices will frequently
not be IP capable [6] and will require an Interworking Unit
(IWU) to provide network layer interworking (IP). This is illustrated
in Figure 5.
The IWU may also be an appropriate point to
provide transport and application layer interworking and proxying.
Home Environment with non-IP appliances
1.4.2 Automobile Environment (AE)
Many IPAs will be used within an automobile environment (AE).
Although the AE may be very different from the HE, it is assumed
that at the network layer and above there will be no fundamental
differences. The authors therefore consider that in the automobile
environment, the communication between IPAs and applications
will be the same as in the HE, but with additional limitations
introduced by connectivity issues; for example, the car might
go through a tunnel and thus suddenly or temporarily lose
network connectivity.
1.4.3 Visited Domains
Given that IPAs are personal devices and many will be portable,
it is likely that users will wish to take them wherever they
go. For
example, consider an Internet alarm clock which checks a user's
Internet-based calendar and preferences. It would be convenient
for the Internet alarm clock user to keep their IPA with them
so that they will continue to be reminded of meetings, social
events, and woken up at appropriate times. The visited domain
may be another HE or automobile environment, for example.
This opens the possibility that an IPA may be deployed into
a domain which is owned or administered by another party.
The problems of access to a device installed into such a network
needs to be investigated, especially with respect to the requirements
that such a device may impose upon the network in which it
is installed (for example, it may require more expensive QoS
capabilities than the network would by default provide).
The ownership relationship between IPAs in the home domain
is unclear. The simplest solution is for the responsible authority
for the domain to have administrative control for it and to
control all of the devices within it, but this will potentially
require a significant level of administration.
Several questions in this area remain open:
Subcontract
and rental arrangements - how can transitory ownership relationships
be modeled and accommodated?
Access to owned devices in a non-owned domain.
Impact of non-owned devices on the operation of the owned
environment in which it operates.
Responsibility for maintenance of non-owned IPAs in an
owned network.
2.2. Information Privacy Issues
All communication between IPAs should be secure so that no
unauthorized parties can eavesdrop on the messages to glean
any information about the (type of) IPAs and what is
being done with them. The implication of this requirement
is that not only does the payload (i.e., requested actions/queries)
of the communications need to be protected, but also the name(s)
of the IPAs may need to somehow be obfuscated.
Further, the release of information contained on an IPA is
subject to preferences that the owner of the IPA selects.
Techniques need to be developed to describe the privacy and
security restrictions that the user wishes to place upon this
data.
Appliances could be connected to the Internet through network
level services (IPv4 or IPv6) or through some application
controller (or interworking unit) that resides in the same
premises. Each of these solutions brings its own problems:
IPv4: Typically with IPv4, there will not be enough addresses
for every IPA. IPAs will thus need to go through a network
address translator (NAT) and the NAT will have to configured
for incoming requests.
IPv6: With IPv6, there will be enough addresses, but not
enough networks (yet). As this situation changes, IPAs will
need to go through an IPv6 IWU if not IPv6 native.
Application relay: This approach is typically not transparent,
and encourages stove-piping.
Network connectivity problems can be solved by finding a way
to resolve limitations, such as techniques for providing a
large number of IPv4 addresses, or applying techniques for
actually deploying IPv6. Alternatively, it may be more suitable
to simply cope with the limitations through techniques such
as designing applications that only use the outgoing TCP connections
that NAT and firewalls support.
3.1.2 Issues With Thin and Fat IPAs
IPAs differ significantly in their requirements for network
availability and QoS.
It is often asserted that, because they are less programmable,
it is easier for external parties (other than the owner) to
trust thin clients. Yet, the AT&T DOSA architecture makes
the argument that, since the client is in the user premises
(e.g. a residential gateway for DOSA), then that client cannot
be trusted, no matter how limited its programmability is.
3.1.3 Intermittent Access
Some devices may only be able to communicate intermittently,
e.g., because their batteries are dead. In the automobile
environment (AE), devices that may be continuously reachable
at home, may suddenly show intermittent reachability due to
power being turned off or network connectivity being interrupted.
3.2. Security Issues
3.2.1 Trust Zones and Domains of Control
What trust will the user place on the appliance and appliance
provider when the provider/seller retains some access to the
appliance while it is in the user's domain? For instance,
the washing machine seller might be able to access the washing
machine to detect when it breaks, or the insurance company
might want to access the smoke detectors. Does the person
trust that these devices don't also contain microphones to
record what happens in the house? Or, more likely, that the
washing machine doesn't report back incoming hot water temperature
so that the seller can offer a larger water heater based on
having seen not-so-hot water in the past?
Will all personal appliances within one domain (e.g., behind
one RGW) trust each other? How does that relate to different
entities having different levels of access and control of
different devices? (Do I really want the company I lease the
washing machine from be able to tell what movies I'm watching
or what is in my refrigerator?)
All of these examples motivate the need to authenticate and
authorize each message to an IPA. IPAs may have different
levels of trust and belong to different domains of control.
Therefore, the originator of each communication with an IPA
must be determined and the requested action checked to verify
that the requestor has permission to perform that action.
3.2.2 Authentication of IPAs
In some cases, devices may need to be authenticated, particularly
for sensors. For example, spoofing the output of alarm sensors
may allow intruders to foil a home alarm monitoring system.
3.2.3 Privacy
Messages sent to and from IPAs may reveal intimate details
about a person's actions and behaviors. Thus, they need to
be protected from interception by third parties. In some cases,
even the act of communicating with a particular home or device
may reveal information that a user considers private.
3.3. Operational Issues
3.3.1 Configuration and Provisioning
The issues of provisioning appliances in a multiple-appliance
environment may be considerable. A device needs to be associated
with its owner or user. In addition, the limited human interface
capabilities of the device may mean that an additional entity
needs to be used to configure or control it. For example,
an alarm clock may be configured through a web interface rather
than scrolling through time settings.
3.3.2 Billing
In some deployment scenarios, systems may need to be developed
to allow users to be billed for services. However, this is
not likely to be a subject for IETF standardization or concern,
beyond providing suitable AAA mechanism.
3.3.3 Faults and Remote Diagnosis
Fault diagnosis, fault control and resolution need to be
investigated. Since IPAs interact with each other, an IPA
may appear to behave incorrectly, even though the fault lies
with another IPA.
Thus, it must be possible to diagnose individual IPAs as well
as observe their interaction.
3.3.4 Distributed Agreements
Servers will provide reliable repositories for data. This
data includes user profile, service data, bank balances,
etc. Fat IPAs may cache data. Consider (for example) a PC
phone (IP phone) user whose cache resides on the phone, and
(s)he migrates the call to a cell phone, perhaps wanting to
walk out of the office while continuing the call. In this
case either the cache has to migrate (based on the capability
of the new device) or user queries have to go to another server/cache.
A management system for synchronization and migration of data
will be needed in this circumstance. Synchronization is needed
for cache validation/invalidation. Devices disconnected from
the network will contain newer versions of the data. For instance,
updating data while on an airplane or updating data locally
due to intermittent or slow connection. User data could be
updated in the server when the user is disconnected. Upon
re-connect the network/server, all data should be made consistent.
Distributed database techniques such as two-phase commits
are not suitable for distributed agreement in a disconnected
network. Two-phase commit is extremely slow and conservative
especially in cases on disconnected systems. What is needed
is application and service specific agreement for a network
of intermittently connected 'databases'.
3.3.5 Restricted I/O
A management system has to handle unreliable, slow messaging
as well as limited capabilities to provide an acceptable service
environment. For example, the presentation layer may present
a different view based on device capability and connectivity.
3.3.6 Multiplicity
The number of IPAs may well exceed the current number of 'traditional'
networked devices such as hosts and routers. It remains to
be investigated how well traditional network management approaches
scale to such environments, in particular where these devices
are not externally reachable and may change network addresses.
3.3.7 Initial Deployment
Can we deploy appliances? In order to connect appliances
to the network, we need to invest in a connection device,
such as a residential gateway or a set-top box whose
price may well exceed the price of the appliance itself. There
are a few options for reducing the initial investment for
the end user:
Provide an inexpensive direct connection to an existing
network. This is the approach in the e-book (modem) and
in the Palm VII (wireless).
Reuse an existing computing device as a hub, such as the
home PC. This is the approach chosen by RIO, and by Palm
IIIs and Vs.
Get someone, such as a network provider, to fund the platform
deployment. This approach is common in the CATV industry.
3.3.8 Decomposition of IPAs
An IPA is generally composed of an I/O component, of a logic
component and of a storage component. There are three broad
ways to deploy services between an appliance and network-based
servers:
Everything in same place: autonomy, high security.
Storage in the network: data sharing. In some circumstance,
performance, reliability.
Application in the network: reduced network bandwidth
if lots of data transactions. New services can be deployed
from within the network. Less power in I/O device, improves
portability, reduces price.
Given the issues highlighted in the previous sections, it
is clear that there is a need within the IETF to understand
the issues surrounding IPA application control, and to
define a framework for IPA service-layer communication
which takes these issues into consideration. This work
should also identify or define protocols which will enable
control of service layer communication with IPAs from
the Internet. In particular, the following issues need to
be
resolved:
Service layer naming and addressing for IPAs.
IPA service and application discovery and registration
mechanisms.
Application security for IPAs.
Service/Application layer protocols for IPA communications.
As stated in section 1.3, we are concerned with interactions
with IPAs at the services layer. To enable services layer
communication, network layer communication must first be established.
Therefore, for the purpose of this document, we assume that
all IP-layer networking (e.g., address assignment, DNS configuration,
etc.) has been configured. This could be done either manually
or automatically, using existing tools such as DHCP or server-less
mechanisms as are being discussed in the ZeroConf WG).
OSGi
The Open Services Gateway initiative seeks to define the
Application Programming Interfaces (APIs) of a service execution
platform that interfaces the many wide area networking protocol
standards with the different in-home networking protocols.
As such, an OSGi gateway becomes an integral component in
IPA communication but does not provide any functionality to
enable this communication. Functionality could be deployed
on an OSGi gateway that facilitates this communication and
in fact that is the charter of a new Interest Group with OSGi
on 'device excitation.' This is a newly formed group and nothing
has been agreed upon yet. However, even if a mechanism is
created to enable communication with IPAs behind an OSGi gateway,
the solution will be OSGi gateway-based and require the existence
of a gateway. This is a restriction for the general case deployment
of
IPAs.
UPnP
The Universal Plug and Play (UPnP) forum provides a framework
and a set of open interfaces for controlling appliances within
the home. UPnP proposes a set of application and session layer
protocols built over TCP/IP. These protocols provide device
discovery and control. UPnP uses HTTP for transporting its
control messages.
Salutation
Salutation enables the broadcast and discovery of services
provided by IPAs, but it does not provide for command and
control type communication with IPAs. The service information
provided by Salutation protocols is necessary and useful for
IPA services and applications, but is only solving part of
the puzzle.
Finally, this section provides some brief (high-level) service
examples which illustrate how the capability for controlling
IPAs
over the internet may be used.
6.1. Power Management
With the increasing demand for power consumption (particularly
in North America), and dwindling natural resources, there
is a clear need for intelligent power management. This may
take two forms (or a combination of the two): (1) centralized
power management, by the utility company for example, and
(2) in-home power management by the appliances themselves.
1) Centralized power management
The utility company is aware of two key facets of information:
the
available power for a particular area or region, and the power
demands placed by consumers' homes and appliances. Based on
this information, the utility company could turn on or off
appliances within consumer's homes to reduce the demand. Of
course, this capability must be exercised as part of a service
level contract with the consumer. The consumer may register
high and low priority appliances to control what stays on
during peak demand periods. Fundamentally, this service example
requires that the utility company can query and control the
status of appliances within the home securely from the internet.
2) In-home power management
Another approach is to have the appliances intelligently
control
their power consumption. For example, numerous sensors within
the home could be used to detect the presence of people and
pets. If there is no presence detected, the sensors will send
commands to the appliances within their vicinity to switch
to stand-by mode. Once a presence is detected, the sensors
will command the same appliances to revert to 'on' mode. Users
may choose to have such a service provided and managed remotely
by a third party provider.In this case, the ability to query
and control appliances within the home securely from the internet
is required.
6.2. Security Management
Home security is another important issue in people's lives
today, particularly as we spend so much time either traveling
or working at other locations. Therefore, it may be useful
to maintain a 'virtual' presence within the home, and be able
to monitor who approaches or enters the home.
This could be achieved by placing sensors (e.g. motion or
heat) around the home to detect approaching visitors,
and strategically mounting cameras with streaming media
capabilities. Whenever someone approaches or enters the home,
the sensors will alert the user wherever they may be. The
alert will be sent securely over the internet and will be
rendered according to the user's preferences and devices at
hand. The alert may take the form of a message on a PC, a
PDA pop-up, a telephone ring, lights flashing on and off,
etc. Once alerted, the user may choose to set up a streaming
video session to one or all of the cameras in their home to
assess the threat, and choose an appropriate course of action.
Again, this service may be provided and managed by a third
party provider. In all cases, the ability to query and
control appliances within the home, and set up media sessions
is required. Furthermore it must be possible to do this securely
from the internet.
The authors wish to gratefully acknowledge the ideas, comments
and suggestions provided by Erik Nordmark and Thomas Narten
during the writing of this document.
Home Audio Video
Interoperability:A consortium of audio-visual electronics manufacturers
who have developed a common, openly-licensable specification
for networking digital home entertainment products.
HE
Home Environment
IPA
Internet Personal
Appliance (see NA)
Jini
Java based device
connectivity and discovery framework.
NA
Networked Appliance:
A dedicated function consumer devices containing at least
one networked processor.
NAS
Network Attached
Storage.
NAT
Network Address
Translator.
OSGi
Open Services
Gateway initiative: An industry group working to define
and promote an open standard for connecting smart consumer
and small business appliances with commercial internet
services.
PDA
Personal Digital
Assistant
RGW
Residential Gateway:
Point of networking and control access to/from a home
environment. The RGW may contain additional functions,
such as firewalls and NATs.
Salutation
An open service
discovery and session management protocol developed by
the Salutation Consortium.
UPnP
Universal Plug
and Play: An open architecture for connectivity of PCs
of all form factors, intelligent appliances, and wireless
devices.
VHN
Video Electronics
Standards Association (VESA) Home Networking: Networking
and control for video appliances developed by the VESA
consortium.
X.10
Early power line
based home networking technology.
