[ Date Next] [ Date Prev] [Thread Prev][Thread Next][Date Index][Thread Index]

Update (draft 0.0a) of STRAWMAN architecture/problem statement


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.


Internet Personal Appliance Control (IPAC) 
Problem Statement (Strawman) draft 0.0a 
Simon Tsang, March 28, 2001. 
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:  
   (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 
              +--------|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 
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 
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 
   [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.  

S. Tsang                                                      [Page 4]