Transcript Appliance-Based Computing (October 11)

Networked Appliances
Reference
 Service Portability of Networked
Applicances by S. Moyer, D. Marples, S.
Tsang, A. Ghosh
Introduction
 A network appliance (NA) is a dedicated
function consumer device containing a
network processor.
 Examples:
Lamps, coffee makers, alarm clocks, phones
 The alarm clock should be able to adjust its
wake-up time based on your calendar, current
weather and traffic conditions.
 A refrigerator reports to a service station
when it needs maintenance.

Introduction
Introduction
Introduction
 The end-user service is tied to the actual




appliance (e.g., refrigerator) and provides an
enhancement to the functionality of the device.
However, the service may be separated from the
physical appliance.
The appliance (alarm clock) is considered a
convenient way to present or render the service
for presentation.
The network infrastructure should enable service
portability which allows the service to be
rendered onto any suitable delivery platform.
The service that automatically starts your coffee
maker should work whether you are at home or in a
hotel room.
Network Appliances Today
 A multitude of devices and technologies
with limited interaction with each other
and with the network.
 Examples of some things we cannot do or
can’t do with ease from a remote location:
“Turn off all lamps at home”
 “Enable house alarms”
 Ask “What’s the kitchen temperature?
 Ask “Are all the doors locked”
 Ask “Is there milk in the fridge”
 “Let the plumber in”

View
View
 The RGW provides secure access to the
wide-area network (e.g., the Internet) and
the ASP within that network.
 At a minimum the RGW provides:
Firewall capabilities
 Network Address Translation (NAT),
 NA
 IP interworking capabilities

 Appliances that are IP capable may connect
to the RGW through a home local area
network (LAN).
Issues
 Naming and addressing
 Location of the device and the physical device
can vary; thus it must be possible to support
both location and device independence.
 Devices within the home need to be
unambiguously named and their location
identified from outside of it.
 Can’t assume that all devices are IP addressable
 Selection between multiple instances.
 Must be possible to browse for available NAs.
 Movement of NAs within a given domain and
across domains should not be restricted.
Issues
 Security considerations
 NAs and their users must be authenticated and
authorized when the NA first enters.
 The entity trying to enter into the home needs
to be unambiguously identified prior to
permitting access.
 Wide-Area Accessibility
 Should be possible for NAs to be accessible
from outside of the home.
Issues
 Protocol transparency and independence
 It
must be possible work with different indomain networking technologies transparently.
• Within a single home it is acceptable (not that we
have much choice) that many different protocols are
used for inter-device communication.
Must be lightweight
 Preferably connectionless protocol

Architecture
 Two types of network-based service
providers: Application service provider
(ASP) and Network service provider (NSP).
 The ASPs provides the platform for
service logic execution.
 The NSPs are responsible for the
transport infrastructure from the ASP to
the NA.
Example Architecture
Issues
 Sounds simple, but ….
 The home domain isn’t really going to allow just
anyone to access it.
 Most likely the network service provider will be
the entity that provides a ‘trusted’ Proxy between
the applications provided by the ASPs and the
home domain. Will the trusted proxy be the point
where charges are applied?
 What about portability? There are many different
makers of the same type of appliance (e.g., lamp).
 ASP services may vary based on the current
geographical or logical location of the user at a
given point in time e.g., the user may be on a
business trip in a different city but wants the
same alarm service.
IETF Initiative
 The IETF is developing a network protocol for
Networked Appliances based the Session
Initiation Protocol (SIP).
 SIP is a signalling protocol for Internet
conferencing, telephony, events notification and
instant messaging.
 Address devices in SIP:



Encode a hierarchical device naming scheme (e.g., SLP
URL) to left of “@” sign in a To or From field.
Encrypt encoded address to ensure privacy.
Example: slp:/d=lamp,r=bedroom,u=stsang
IETF Initiative
 SIP was initially created with call set-up in
mind.
 It is intended to establish a relationship or
session between two endpoints
 Important Methods:
INVITE – Used to initiate a session with state
 DO – Indicates the action to be done at
destination.
 SUBSCRIBE & NOTIFY – Enables event
notification from and between networked
appliances

Application Scenario (1)
 The user wishes to turn on a lamp within
their home from their office PC.
 home.net is a NSP.
 co.com is a NSP.
Application Scenario (1)
Application Scenario (1)
 The SIP messages for the remote control
are shown below:
(1) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
Via: SIP/2.0/UDP anypc.co.com
Content-function: render
Content-type: application/dmp
<command><turn>On</turn></command>
This can be sent from any PC in the company. This is
routed to a SIP server on co.com
Application Scenario (1)
(2) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
Via SIP/2.0/UDP co.com
Via SIP/2.0/UDP anypc.co.com
Content-function: render
Content-type: application/dmp
<command><turn>On</turn></command>
The co.com proxy (a SIP server) does lookup in DNS
for [d=lamp,r=bedroom,u=stanm]@home.net for
the SIP server for the destination domain. It
gets the value of home.net.
Application Scenario (1)
(3) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
Via SIP/2.0/UDP home.net
Via SIP/2.0/UDP co.com
Via SIP/2.0/UDP anypc.co.com
Content-function: render
Content-type: application/dmp
<command><turn>On</turn></command>
The user name is unique within the domain of the SIP
server on home.net; This is sent to stan.home.net
which is able to deal with resolving the network
address to the device address and deal with
firewall issues.
Application Scenario (1)
(4) DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
Via SIP/2.0/UDP stan.home.net
Via SIP/2.0/UDP home.net
Via SIP/2.0/UDP co.com
Via SIP/2.0/UDP anypc.co.com
Content-function: render
Content-type: application/dmp
<command><turn>On</turn></command>
This is received by an appliance controller for a lamp.
Application Scenario (2)
 Now let us deal with the case that the lamp
from stan.home.net has temporarily been
moved to simon.home.net
 To accommodate the change, a re-direction
is added to the home.net proxy.
 The SIP messages for this scenario are
shown now shown.
 The first two SIP messages are as before.
Application Scenario (2)
Application Scenario (2)
 The third SIP message is as follows:
(3) DO sip:[d=lamp,r=bedroom,u=stanm]@simon.home.net SIP/2.0
From: sip:[email protected]
To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
Via SIP/2.0/UDP home.net
Via SIP/2.0/UDP co.com
Via SIP/2.0/UDP anypc.co.com
Content-function: render
Content-type: application/dmp
<command><turn>On</turn></command>
The home.net proxy did a look-up and finds that
Stan’s bedroom lamp is now in Simon’s spare room.
Application Scenario (3)
 Stan is riding with Dave in Dave’s car and
remembers that he was expecting a service person
to come and fix the dishwasher and he does not
have his web phone.
 He asks to borrow Dave’s phone and sends a
message to his service provider to notify him if
someone “rings” the doorbell.
 When the service person “rings” the doorbell (and
authenticates themselves with their ID badge), a
message is sent to Dave’s web phone for Stan that
the service person is at the front door.
Application Scenario (3)
Application Scenario (3)
 The SIP messages needed are below:
(1) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[door,r=front,u=stanm]@home.net
Via: SIP/2.0/UDP dave.mobile.net
Contact: sip:[email protected]
Content-type: application/dmp
<event>ring</event>
Application Scenario (3)
(2) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[door,r=front,u=stanm]@home.net
Via: SIP/2.0/UDP mobile.net
Via: SIP/2.0/UDP dave.mobile.net
Contact: sip:[email protected]
Content-type: application/dmp
<event>ring</event>
Application Scenario (3)
(3) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[door,r=front,u=stanm]@home.net
Via: SIP/2.0/UDP home.net
Via: SIP/2.0/UDP mobile.net
Via: SIP/2.0/UDP dave.mobile.net
Contact: sip:[email protected]
Content-type: application/dmp
<event>ring</event>
Application Scenario (3)
(4) SUBSCRIBE sip:[door,r=front,u=stanm]@home.net SIP/2.0
From: sip:[email protected]
To: sip:[door,r=front,u=stanm]@home.net
Via: SIP/2.0/UDP stan.home.net
Via: SIP/2.0/UDP home.net
Via: SIP/2.0/UDP mobile.net
Via: SIP/2.0/UDP dave.mobile.net
Contact: sip:[email protected]
Content-type: application/dmp
<event>ring</event>
Application Scenario (3)
(5) Door Bell Rings; Credentials established
(6) NOTIFY [email protected] SIP/2.0
From: sip:[d=door,r=front,u=stanm]@home.net
To: [email protected]
Via: ua.stan.home.net
Contact: sip:[email protected]
<event>ring</event>
<identity>Maytag Repairman</identity>
Application Scenario (3)
(7) NOTIFY [email protected] SIP/2.0
From: sip:[d=door,r=front,u=stanm]@home.net
To: [email protected]
Via: stan.home.net
Via: ua.stan.home.net
Contact: sip:[email protected]
<event>ring</event>
<identity>Maytag Repairman</identity>
Application Scenario (3)
(8) NOTIFY [email protected] SIP/2.0
From: sip:[d=door,r=front,u=stanm]@home.net
To: [email protected]
Via: mobile.net
Via: stan.home.net
Via: ua.stan.home.net
Contact: sip:[email protected]
<event>ring</event>
<identity>Maytag Repairman</identity>
Application Scenario (3)
 The user is alerted and decides to unlock
the door.
 A DO message to unlock the door is sent
along the same route as the SUBSCRIBE
message sent earlier.
Application Scenario (4)
 A network-based alarm clock service
attempts to deliver a wake-up alert and
announcement to the user.
 Assume that the user has previously
configured the service to be delivered to
him/her.
 The `alarm clock’ used to deliver the
service does not have to be a physical
clock, but simply a device, discovered by
the service, capable of receiving an audio
stream.
Application Scenario (4)
 SIP is used to set-up the audio session.
 The network-based alarm clock service provider
(called alarmclock.net) establishes the audio
session and plays the audio announcement(s) at the
appropriate wake-up time which is configured
through the user’s personal calendar and adjusted
based on current traffic and weather conditions.
 Note the difference between this scenario and
the others: The others were session-less. This is
not.
Application Scenario (4)
Application Scenario (4)
INVITE sip: [d=alarmclock,r=bedroom]@home.net SIP 2.0
From: [email protected]
To: sip[d=lamp,r=bedroom]@stan.home.net
Content-type: application/sdp
[SDP Parameters for uni-directional RTP stream]
Messages 2 and 3 are basically the same with the
additional routing information.
A response is then returned to the alarm clock
service provider with the alarm clock’s RTP
parameters and an audio stream is initiated.
Application Scenario (4)
 Let’s say that Stan is staying over at a
friend’s house and would like the alarm
clock service to wake them up there.
 Stan doesn’t want to bring his clock.
 A redirection is done which is handled by
REGISTER messages.
Security Considerations
 Authentication of all SIP messages is needed.
 There is a need for “trusted” proxies. Network




Service Providers may end up being these
“trusted” proxies.
How do we control access?
Currently, SIP requires some form of public-key
technology. This makes sense for Internet phones
since communication can potentially occur between
any two parties.
Many believe that in the case of remote access to
NAs within the home that shared secret keys are
better. Here communication can’t just occur
between any two parties.
Do we encrypt end-to-end or hop-by-hop? SIP
allows both.
Initiatives
 There are lots of initiatives that focus on making
networked appliances successful. SIP is
specifically focussed on being a network protocol.
Other initiatives include:





Open Services Gateway Initiative (OSGi) – Middleware
for delivering and managing multiple applications.
UPnP – in-home inter-device communication
HAVi for in-home inter-device communication
SLP – Location and identification of services
Salutation – Location and identification of services