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