Internet-Draft A. Roychowdhury Intended status: Informational Hughes Systique Expires: April 18,2010 S. Gouran Home Jinni Inc. October 18, 2009 Motivation for SIP as an application protocol for 6lowpan devices draft-roychowdhury-6lowappsip-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The Smart Grid [8] initiative is an effort in modernization of the electricity grid using communication technology with the primary goals of reducing energy consumption, reducing cost (utilities and consumers), increasing reliability and the creation of new services for all participants in the value chain. The core focus of this initiative is the specification of a 'Communications Overlay' network which can help facilitate intelligent communication (discovery, session establishment, routing, addressing to name a few) between various nodes of the heterogeneous Smart Grid network. Roychowdhury Expires - April 2010 [Page 1] Motivation for SIP as an application protocol for 6lowpan devices One of the 'network segments' of the Smart Grid network is the Home Area Network (HAN) and how residential and/or commercial devices (such as TV, washing machine, surveillance camera, etc.) interact with the smart meter/energy management system and vice-versa. This draft is an initial input for consideration of SIP as an appropriate application protocol for use inside devices that operate over low powered IP networks. The authors do NOT propose the use of SIP for all HAN devices. Rather, the authors believe that SIP is an appropriate protocol for certain categories of devices and therefore, the 6lowapp group should consider SIP as an appropriate protocol for the same. The final protocol that is ideal for a particular device communication will always be determined by the use-case(s) that are envisioned for the same. This draft does NOT discuss the use of SIP inside the smart meter (while the authors believe that the smart meter would also benefit from SIP, that is the scope of another draft and does not apply to the 6lowapp work). Therefore, in all diagrams and references, the authors have used the term 'Energy Management System (EMS)' to refer to the customer premise EMS that may or may not be the smart meter itself. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. The term EMS refers to the customer premise Energy Management System which may be the smart meter or an adjunct devices that communicates with the utility core network for the purposes of energy management and billing. Table of Contents 1. Introduction...................................................3 2. A response to the 6Lowapp problem statement....................3 2.1 Advantages of SIP..........................................5 3. Debunking some SIP myths.......................................7 3.1 SIP has VoIP baggage and is therefore complicated..........7 3.2 SIP requires too many messages.............................7 3.3 We already use XXX protocol. Do I need to replace XXX?.....7 4. Sample Home Area Network with SIP devices......................8 Roychowdhury Expires April 2010 [Page 2] Motivation for SIP as an application protocol for 6lowpan devices Figure 1: Sample HAN..............................................9 5. Conclusion.....................................................9 6. Security Considerations........................................9 7. References.....................................................9 Author's Addresses...............................................10 1. Introduction A 'smart home' is a modern day home in which a significant portion of physical objects have built-in intelligence and communications capability. Naturally, different devices in the home will require different levels of intelligence. Furthermore as devices get more intelligent, the mechanisms used to interact with them will also get more complex. Furthermore, home area network applications will not be about limiting and relating objects to specific homes, but rather need to be capable and open to much more complex relationships. For example, if a guest is charging their electric car at a friends house, we should consider applications that will understand that the charge should appear on the guests electric bill and not that of the the friend. As another example, it is entirely possible that your home IPTV interacts with the EMS and monitors the current price of electricity and when it reaches a particular threshold, automatically negotiates a lower bit rate codec as well as steps down brightness a few notches. Continuing this line of thought, your thermostat could be more than just a programmable 'time-of-day' device. Consider for example, your cell phone being the 'location updater' for your thermostat and when the owner is a few miles away from home, the heating automatically starts. Much better than you arriving early one evening and freezing for 15 minutes before your thermostat warms up, isn't it? The examples above all show why the authors feel that the future home services will not just be limited to traditional home appliances but which will also involve other communication devices such as your 3G/GSM/CDMA phone, your electric car and others. SIP is an excellent choice for middleware in building out these sort of applications as this I-D will describe. 2. A response to the 6Lowapp problem statement This section provides a brief response to relevant sections of the 6lowapp problem statement as specified in [7]. Roychowdhury Expires April 2010 [Page 3] Motivation for SIP as an application protocol for 6lowpan devices Section 1, Problem Statement: "In addition, some of the applications may require optimizations in terms of bandwidth usage; for example, the usual data formats both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs. Their interpretation and generation may require too much code for the 8-bit and 16-bit processors dominating LoWPAN nodes" Response: The authors agree that there is a large set of limited processing power devices for which an appropriate compression mechanism may be required. It should be noted that any compression scheme that applied to HTTP payload can also be applied to SIP. The authors also believe that there will be devices classes that can accommodate more bandwidth and where a new compression mechanism may or may not be needed. Section 2, Node and Network Characteristics: "As mentioned in the introduction, the 6LowApp application protocol requirements are strongly influenced by the specific characteristics of LoWPAN nodes and networks." Response: The authors completely agree and further believe that there are several use cases where SIP will be the appropriate protocol. The authors also believe that since SIP has the capability to encapsulate any payload as part of its message structure, other protocols, such as ZigBee SE profile can also be extended and can benefit from the added advantages that SIP provides. Section 2, Node and Network Characteristics: "Constrained LoWPAN nodes often only have a few KiB of RAM, and their code size tends to be limited to a value between 48 KiB and 128 KiB. Their processing speed may be limited by energy considerations to a few million instructions per second (which, at a duty cycle of 0.1 % or less, may mean a thousand instructions per second!)." Response: The authors believe these numbers likely depict the low end of loWPAN devices. Furthermore, the authors also know, from past experience that it is entirely possible to write a robust SIP stack in under 40K footprint (ANSI-C, compiler optimized), with sufficient functionality to meet the requirements of a HAN device. Section 3, Application Protocols: Roychowdhury Expires April 2010 [Page 4] Motivation for SIP as an application protocol for 6lowpan devices "The use of UDP and the limited packet sizes efficiently supported by LoWPANs make relatively verbose protocols such as HTTP less desirable. On the other hand, key principles of the web such as resource identifiers (URIs), content types (MIME), statelessness, proxy support etc. are most desirable." Response: SIP works well over both TCP as well as UDP (SIP has its own application level re-transmission logic). Furthermore, SIP supports URIs, MIME, statelessness, proxy support and more, making it well suitable. Section 4, Supporting protocols Response: SIP as a protocol is designed to be able to either encapsulate or initiate sessions that may need other protocols. For example, an SLP query could be embedded inside a SIP request and take advantages of the routing flexibility of SIP. On the other hand, SIP could be used to initiate a subsequent session, say a TFTP session that executes immediately after the SIP session without any encapsulation requirements. Similarly, data formats like ANSI C12.18 etc. can be encapsulated inside SIP. 2.1 Advantages of SIP SIP brings in a lot of advantages for HAN devices, only some of which are described below: o Addressing: SIP devices are addressed by a URI scheme (example sip:mycar@myhome.net) and are independent of their current IP address. This means that the device can be reached anywhere as long as it is connected and the IP address will be resolved as part of routing at that instance of communication o Groups and Forking: The architecture of SIP allows for multiple devices to be addressable (grouped) using a single id (example: clocks@myhome.net). This makes it simple to issue one command that gets "forked" (i.e. sent in parallel) to multiple devices (example an IM "set dst on" to clocks@myhome.net, or, say "set max heating 72F" to thermostats@myhome.net) o Events - Subscriptions and Notifications: SIP allows for any device to subscribe and be notified of any event that is triggered on that device. For example, your thermostat could subscribe to the "EnergyRate" event of the smart meter and if the rate/kwh were to increase beyond a point, the thermostat would be notified and may choose to adjust its setting of heating automatically. Roychowdhury Expires April 2010 [Page 5] Motivation for SIP as an application protocol for 6lowpan devices o Mobility: SIP supports mobility at the application layer, primarily due to its use of URIs for addressing. A device can 're- register' its current location dynamically with its home proxy and can be reached even if its real address is different from the known address. o Security: SIP integrates well with security. It supports a variety of security mechanisms such as TLS, MD5-Auth, AKA, PKI etc. Furthermore, different devices can use different security protocols (or none) depending on their need with SIP which serves very well for limited capability devices/networks o Offer-Answer: SIP is modeled around an offer-answer model which ensures that a session is established using capabilities that both endpoints support. For example, if a homeowner were to monitor his home nanny cam using his desk phone, it would automatically detect the phone does not support video and would only provide an audio stream o Discovery: SIP natively supports both device and capability discovery. For example, clocks@myhome.net may result in the initial communication reaching all the clocks of the house (alarm clock, radio clock, oven clock). Similarly, the SIP OPTIONS method can be used to discover the capabilities of multiple devices before initiating a communication with a selected device. As another specific example, even though UPnP is the consumer electronics industries' de-facto standard for discovery and control, the architecture does not meet the requirements for use on a pervasive network or lend to mobility. In addition, there is general consensus that its SOA architecture is unnecessarily complex. For this reason, the industry is in the process of standardizing the concept of a UPnP to SIP interface[11] as the preferred mechanism for pervasive device control and discovery. o Presence: SIP, specifically the work done in SIMPLE [10] brings in a strong concept of presence to SIP. A SIP device can advertise its current presence state (busy, online, offline, DND, lowpower- sleep etc.) which can both help communicating entities know the current state of the device before reaching out to it, as well as open up a lot of innovative service creation possibilities (example: if my house TV is in 'transmitting' state for 3 hours, and I am on travel, I may decide to switch it off, not just to save power, but to ensure my kids are not taking advantage of their parent-free-time) o Converged communication: SIP has the ability to interwork multiple devices to execute a single service. Consider for example, a Roychowdhury Expires April 2010 [Page 6] Motivation for SIP as an application protocol for 6lowpan devices situation where your EMS has detected a sudden rise in power usage that is not the norm based on your past trends. It may choose to alert you of this situation both by email, as well as a digital signage overlay on your TV that gives you more information and then allow you to rectify the situation appropriately. o Extensible: The architecture of SIP easily enables new methods and extensions as applicable. This means that if SIP needs to be modified to fit into a particular network/device characteristic it can easily be done. 3. Debunking some SIP myths This section debunks some common myths that follow SIP and may be especially applicable for 6lowapp work 3.1 SIP has VoIP baggage and is therefore complicated SIP can be used completely independent of VoIP. For example, one can just use SIP IM messages to communicate between devices which does not need a session to be established 3.2 SIP requires too many messages As described in 3.1, depending on functionality requirements, SIP messages can be significantly reduced. Furthermore, SIP has a concept of implicit registrations/subscriptions where for a defined and secure network, certain operations can be 'provisioned' automatically without the actual messages flowing. 3.3 We already use XXX protocol. Do I need to replace XXX? Not really. As described before, SIP works very well with many protocols. The architecture goals of SIP is not to annihilate other protocols but to work with as many protocols as are appropriate. If any other protocol does a better job than SIP for a particular role, so be it. SIP can be used to initiate the 'setup session' after which XXX can take over, or, XXX can be encapsulated inside SIP. Why you would choose to use SIP in this mode would depend on whether the advantages of SIP (2.1) are beneficial to you. Roychowdhury Expires April 2010 [Page 7] Motivation for SIP as an application protocol for 6lowpan devices 4. Sample Home Area Network with SIP devices This section illustrates a sample home area network where both SIP and non-SIP devices co-exist. This section is informational only. Roychowdhury Expires April 2010 [Page 8] Motivation for SIP as an application protocol for 6lowpan devices +-------------------------------------------------------------+ | Home Area Network | | /--\ | | +---------+ --+ | | | / SIP- | ---- \--/ | | //| xxx +-- | | SIP // | IWF | ---- /--\ | | / | | ---| | | | // +---------+ \--/ | +-+---+ // | |EMS | SIP +----------/+ non SIP | |or +------+ SIP Proxy | appliances| |meter| +------.----*- SIP | +--+ | . \\--- | | | | +------.----+ \\ --- | | | |.......firewall | \\\ ----+--+ | | +-+---+ +-----------+ \ \ +- | | | | \ \ +--+ | | | \ \\ | | | \ \ +--+ | | | \ \\| | | | | \ *--+ | | | \ | | | \ +--+ | | | \| | | | | +--+ | | | SIP appliances | | +-------------------------------------------------------------+ | Roychowdhury Expires April 2010 [Page 9] Motivation for SIP as an application protocol for 6lowpan devices | ----- | ///- -\\\ |/ \ | | +------------------+ | WAN | | | | -+----------+ | | | | utility core | | | | network | \ / | | \\\- -/// +------------------+ ----- \ \\ \ \\ +-------------------------------+ \ SIP | Roaming Network | \\ | | \ | -------- | \\ | ----------------+ | \| | PEV | | | +//\\--------//\* | | \/ \/ | | | | | | +----+ | | | | other mobile | | +----+ appliances (?) | +-------------------------------+ Figure 1: Sample HAN 5. Conclusion The authors hope to have presented some key advantages of SIP and why we believe SIP should be a candidate protocol for consideration for the 6lowapps group. 6. Security Considerations All the security considerations of [3] will also apply to this draft. Furthermore, it is likely that the role of private networks and stronger security mechanisms will be more important here do to the nature of devices being controlled (typically personal home devices). 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] J. Rosenberg, et. Al "SIP: Session Initiation Protocol", RFC RFC 3261, June 2002 [4] R.Price, et. Al "Signaling Compression", RFC 3320, Jan 2003 [5] J. Adamo, "SIP-Open Communications for Smart Grid devices", June 2009 [6] S. Moyer et al "Framework draft for Network Appliances using SIP", draft-moyer-sip-appliances-framework-02.txt, June 2001 [7] C. Bormann et al "6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols", draft-bormann-6lowpan-6lowapp-problem- 01, July 2009 [8] NIST smartgrid interoperability standards project, http://www.nist.gov/smartgrid/ Roychowdhury Expires April 2010 [Page 9] Motivation for SIP as an application protocol for 6lowpan devices [9] NIST Framework and Roadmap for Smart Grid Interoperability Standards Release 1.0 (Draft), http://www.nist.gov/public_affairs/releases/smartgrid_interopera bility.pdf [10] IETF SIMPLE Charter, http://www.ietf.org/dyn/wg/charter/simple- charter.html [11] Open IPTV (SIP-Upnp profile), http://www.openiptvforum.org 5. IANA Considerations None Authors' Addresses Arjun Roychowdhury Hughes Systique Corp. 15245 Shady Grove Rd, Suite 330 Rockville, MD 20850 USA Phone: +1.301.527.1629 Email: arjun@hsc.com Shidan Gouran Home Jinni Inc. 2200 4950 Yonge St. M2N-6K1 Toronto, Ontario Canada Phone: +1.416.854.3017 Email: shidan@homejinni.com Roychowdhury Expires April 2010 [Page 10] Motivation for SIP as an application protocol for 6lowpan devices