[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

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.


   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

   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

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",
   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

   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

   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

   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,

  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),

     [10] IETF SIMPLE Charter, http://www.ietf.org/dyn/wg/charter/simple-

     [11] Open IPTV (SIP-Upnp profile), http://www.openiptvforum.org

5.   IANA Considerations

Authors' Addresses

   Arjun Roychowdhury
   Hughes Systique Corp.
   15245 Shady Grove Rd, Suite 330
   Rockville, MD 20850

   Phone: +1.301.527.1629
   Email: arjun@hsc.com

   Shidan Gouran
   Home Jinni Inc.
   2200 4950 Yonge St.
   M2N-6K1 Toronto, Ontario

   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

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/