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