6LoWAPP G. Moritz
Internet-Draft University of Rostock
Intended status: Informational December 18, 2009
Expires: June 21, 2010
DPWS for 6LoWPAN
draft-moritz-6lowapp-dpws-enhancements-00
Abstract
This draft describes adaptions and enhancements for deploying the
Devices Profile for Web Service (DPWS) in 6LoWPAN networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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.
This Internet-Draft will expire on June 21, 2010.
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Moritz Expires June 21, 2010 [Page 1]
Internet-Draft Abbreviated Title December 2009
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discovery optimizations . . . . . . . . . . . . . . . . . . . 5
2.1. General adaptions . . . . . . . . . . . . . . . . . . . . 5
2.2. Discovery addressing . . . . . . . . . . . . . . . . . . . 5
2.3. Discovery proxy . . . . . . . . . . . . . . . . . . . . . 6
2.4. Heartbeat message . . . . . . . . . . . . . . . . . . . . 6
2.5. Device registry . . . . . . . . . . . . . . . . . . . . . 7
3. Message compression . . . . . . . . . . . . . . . . . . . . . 7
3.1. HTTP compression . . . . . . . . . . . . . . . . . . . . . 7
3.2. SOAP compression . . . . . . . . . . . . . . . . . . . . . 8
3.3. Compression integration . . . . . . . . . . . . . . . . . 9
3.3.1. Payload compression . . . . . . . . . . . . . . . . . 9
3.3.2. TCP vs. UDP . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Moritz Expires June 21, 2010 [Page 2]
Internet-Draft Abbreviated Title December 2009
1. Introduction
In August 2008 a technical committee (TC) at OASIS was formed for the
Web Services Discovery and Web Services Devices Profile(WS-DD)
[WS-DD]. WS-DD standardizes a lightweight subset of the Web services
protocol suite that makes it easy to find, share, and control devices
on a network.
The work of this TC is based on the former DPWS, WS-Discovery, and
SOAP-over-UDP specifications. DPWS makes use of existing Web
services protocols, but also adds several extensions to enable Web
services based communication on embedded devices also. Thereby, DPWS
includes features like (1) discovery of devices and metadata exchange
with services even in dynamic changing environments (2) eventing
about state changes by WS-Eventing (3) security and integrity for
discovery, metadata exchange and service usages. Because DPWS bases
on existing Web services standards, it is fully capable of being
integrated in the Web services framework.
This draft describes several adaptions and enhancements to expand
DPWS deployments to 6LoWPAN networks, but is far away from a
comprehensive specification. It only presents a basis for further
discussions. Main scope is the definition of a profile, to describe:
message compression and bidirectional message reduction, while
staying fully compliant with existing WS-DD specifications. The
deployment of this profile is fully transparent for existing DPWS
implementations and describes extension to be considered by 6LoWPAN
networks only.
Readers of this draft should have a basic knowledge about the
specifications DPWS [DPWS], WS-Discovery [WS-Discovery], SOAP-over-
UDP [SOAP-over-UDP] and related standards like SOAP, HTTP, XML and
XML Schema.
1.1. Requirements Language
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 [RFC2119].
1.2. Terminology
DPWS
In the remainder of this draft, DPWS is used as general term
for the WS-DD specifications DPWS [DPWS], WS-Discovery
[WS-Discovery], and SOAP-over-UDP [SOAP-over-UDP].
Moritz Expires June 21, 2010 [Page 3]
Internet-Draft Abbreviated Title December 2009
DPWS specification
Points to the DPWS [DPWS] specification directly.
Device
A device is an endpoint implementing DPWS device
functionalities as specified by WS-DD [WS-DD].
Client
A client is an endpoint implementing DPWS client
functionalities as specified by WS-DD [WS-DD].
Hello
The Hello message of a device as defined in WS-Discovery
[WS-Discovery].
Bye
The Bye message of a device as defined in WS-Discovery
[WS-Discovery].
Probe
The Probe message of a client as defined in WS-Discovery
[WS-Discovery].
Probe Match
The Probe Match message of a device as defined in WS-
Discovery [WS-Discovery].
Resolve
The Resolve message of a client as defined in WS-Discovery
[WS-Discovery].
Resolve Match
The Resolve Match message of a device as defined in WS-
Discovery [WS-Discovery].
WSDL
Acronym for the document describing the services in Web
Services Description Language [WSDL] format.
Edge Router
Edge Routers are the routers that connect LoWPANs to an IPv6
infrastructure via backhaul or backbone links when such an
infrastructure is available. (Defined in 6LoWPAN Neighbor
Discovery [I-D.ietf-6lowpan-nd]
Moritz Expires June 21, 2010 [Page 4]
Internet-Draft Abbreviated Title December 2009
2. Discovery optimizations
DPWS describes two different modes for discovery of devices: ad-hoc
mode and managed mode. In managed mode, a registry called Discovery
Proxy is applied to suppress multicast messages. This section
describes adaptions for both of these modes.
2.1. General adaptions
A DEVICE MUST include the transport specific addresses in its Hello
and Probe Match messages.
In accordance to DPWS, embedding of a transport specific address in
Hello and Probe messages is not mandatory. This behavior is
counterproductive for WSN, with the constraints for energy
consumption and limited bandwidth. Thus, the optional fields for the
transport specific addresses are now mandatory to avoid Resolve
messages.
A DEVICE SHOULD include all device types in Hello and Probe Match
messages.
In the current version of DPWS it is not mandatory to include the
type field in the Hello and Probe Match messages. A client MAY infer
to services provided by the device with the help of the device type.
Inclusion of the device type can avoid further discovery and metadata
exchange messages.
A SERVICE SHOULD NOT provide the WSDL file for CLIENTS at run time.
Providing the WSDL during the discovery phase is optional in DPWS.
WSDL are used in general at development time only for code
generation. These WSDL files have a size of several kB in most
analyzed scenarios. The expensive and memory consuming storage of
these WSDL files on the device and on the client node is not
applicable for WSN. Furthermore, the exchange itself consumes a high
bandwidth.
2.2. Discovery addressing
o All SOAP-over-UDP messages inside the 6LoWPAN network MUST use the
port 61616 as target port. (Exact port to be defined)
o Devices inside the 6LoWPAN network MUST listen to the IPv6
multicast address: FF02::C0. (Exact address to be defined)
o Clients inside the 6LoWPAN network MUST listen to the IPv6
multicast address: FF02::C1. (Exact address to be defined)
Moritz Expires June 21, 2010 [Page 5]
Internet-Draft Abbreviated Title December 2009
In RFC4944, a UDP port compression is described which works most
efficient when using ports in a specific range. Thus, the used ports
should be changed to fit in this range. The ports have to be mapped
on the edge router of the 6LoWPAN network for incoming and outgoing
SOAP-over-UDP messages.
DPWS defines one IPv4 and one IPv6 multicast addresses to be used for
discovery message exchange. But DPWS differentiates between device
and client roles. Usage of one and the same address for addresses
exclusively to be processed by clients or devices implies overhead in
sending and receiving these messages to all DPWS nodes independent of
their role. Inside 6LoWPAN networks, different addresses have to be
used. The mapping into compliant addresses is done by the edge
router of the 6LoWPAN network.
For a transparent integration, in ad-hoc mode, edge routers of
6LoWPAN networks SHOULD forward incoming and outgoing link-local
scope multicast discovery messages.
2.3. Discovery proxy
In managed mode, a device and service registry is applied. It is
possible, to use more than one discovery proxy in a network. In
managed mode, one discovery proxy SHOULD be deployed at the edge
router to hide expensive external multicast messages from the 6LoWPAN
network and omit multicast flooding.
2.4. Heartbeat message
Wireless Sensor Networks are unreliable due to low power radio
communication and limited battery capacities. Clients and discovery
proxies might use a heartbeat message to ask for a device and its
status. This heartbeat message can use a pull exchange pattern or a
push mechanism similar to eventing functionalities. DPWS defines
Directed Probe and includes WS-Eventing, which might fulfill the
requirements of the heartbeat message or if a new message has to be
defined. The device MUST answer to this heartbeat signal with a
unicast Hello including the WS-Discovery Metadata Version indicating
state changes of the device or the services.
The definition of the heartbeat mechanisms may be out of scope of a
specification and might be included in a domain specific profile
(e.g. healthcare scenarios). But the mechanism is required by the
device registry described in this draft.
Moritz Expires June 21, 2010 [Page 6]
Internet-Draft Abbreviated Title December 2009
2.5. Device registry
For simple services as provided in 6LoWPAN networks (basic sensors),
device metadata messages are almost the most bandwidth consuming
messages. Metadata of a device (Model, Manufacturer, Version Number,
etc.) of a device are stable in most cases over lifetime of a device.
A device registry located at the edge router of a 6LoWPAN network MAY
store information about device metadata exchanged through this edge
router by sniffing messages. External metadata exchanged requests to
devices in the 6LoWPAN network MAY be answered representative by the
device registry. This is transparent to the devices and the clients.
The device registry is a hidden intermediate in contrast to the
discovery proxy. To provide end-to-end reliability and a guaranty
about correct data for the response, the device registry SHOULD
invoke the device by using the heartbeat message mechanism described
in this draft, before answering the client. The heartbeat message
and the response are much smaller compared to the device metadata
messages.
3. Message compression
Because DPWS bases on SOAP and thus on XML for data representation,
XML compression techniques and/or encoding concepts have to be used
to reduce message sizes.
3.1. HTTP compression
DPWS for 6LoWPAN requires HTTP header compression. While CHOPAN
[I-D.frank-6lowapp-chopan] describes a general and generic HTTP
compression, this draft focuses on a more DPWS specific compression
scheme as described here.
DPWS uses SOAP-over-HTTP binding for unicast messaging. All messages
are using the POST method of HTTP in version 1.1. The transport
specific addresses (target host) can be elided and derived from
transport layer. In accordance to HTTP 1.1, all connection marked
not explicit as close are keep-alive connections. But keep-alive
connections are not applicable for WSN. The SOAPAction field is
mandatory when using the SOAP-over-HTTP binding, but can be empty.
Because DPWS includes usage of WS-Addressing, the SOAPAction field is
redundant. The content-type of SOAP-over-HTTP is always application/
soap+xml; charset=utf-8. To sum up, only few fields are left, which
are analyzed by devices and clients and which provide useful
information. A specific compression scheme is required to omit
unnecessary HTTP header fields and allow a compression (optimized
binary format) of the remaining required fields. The fields which
have to be left are:
Moritz Expires June 21, 2010 [Page 7]
Internet-Draft Abbreviated Title December 2009
Content-length: This is required to allow resource constrained sensor
nodes to know about length of data to be analyzed and thus e.g.
required memory allocations.
HTTP Status Codes: The status code may be analyzed in error and fault
cases. Status code 200/OK can be implied if this field is missing,
to use it only in error/fault cases.
3.2. SOAP compression
Different XML specific and XML non-specific compression schemes are
already known. The following table presents an overview about
existing schemes and compressors, including the EXI format of the
W3C. The table shows resulting sizes of different compressors applied
to DPWS messages. The values present the sizes of the SOAP envelopes
(excluding HTTP headers) after compression and in the last line pure
XML messages for comparison. The messages were recorded in a
realistic scenario, implemented by using compliant DPWS toolkits. An
overall number of 18 different message types are included in the
evaluations and the table shows the averages over all these message
types. Most of the compressors suffer from the simple XML
structures. Sensor nodes will not provide complex services and thus
simple message have to be assumed. These measurements might provide
a basis for further discussions on message size optimizations.
For the measurements of EXI schema-informed format, separated results
are presented: optimized and default. The default format used XML
schema files as defined in DPWS without optimizations. This includes
an inconsistency of different namespaces and versions used by DPWS
and among Web services specifications (especially WS-Addressing and
WS-Eventing). For the optimized format, some improvements are added.
Most values of the XML tags and attributes in DPWS are well-known
URIs. If these values are included in the XML schema files and with
corrected dependencies, the average message size is reduced
significantly as presented in the table.
Moritz Expires June 21, 2010 [Page 8]
Internet-Draft Abbreviated Title December 2009
+-------------------+-----------+----------+-----------+------------+
| Compressor | Average | Average | Minimum | Maximum in |
| | in Byte | in % | in Byte | Byte |
+-------------------+-----------+----------+-----------+------------+
| EXI | 153,72 | 19,97 | 66,00 | 349,00 |
| schema-informed | | | | |
| (optimized) | | | | |
| EXI | 206,61 | 26,49 | 122,00 | 415,00 |
| schema-informed | | | | |
| (default) | | | | |
| EXI schema-less | 315,67 | 40,31 | 192,00 | 633,00 |
| gzip (C=9) | 419,83 | 54,54 | 271,00 | 749,00 |
| XMLPPM | 427,44 | 55,61 | 274,00 | 755,00 |
| gzip (C=1) | 437,83 | 56,96 | 297,00 | 799,00 |
| Xmill (C=9) | 457,89 | 59,46 | 300,00 | 824,00 |
| Xmill (C=1) | 463,56 | 60,14 | 303,00 | 852,00 |
| bzip2 (C=1) | 472,94 | 61,41 | 304,00 | 852,00 |
| bzip2 (C=9) | 474,78 | 61,82 | 315,00 | 852,00 |
| Fast Infoset | 561,89 | 69,70 | 315,00 | 1301,00 |
| XML | 814,89 | 100,00 | 418,00 | 2089,00 |
+-------------------+-----------+----------+-----------+------------+
Table 1: DPWS SOAP envelope compression comparison
3.3. Compression integration
This section describes a general point, which might be discussed more
in general in 6LoWAPP.
3.3.1. Payload compression
Many protocols (like DPWS) already provide concepts for discovery of
devices (ad-hoc networking), data dissemination, eventing, etc.
6LoWPAN protocols allow a seamless connectivity of IP networks with
wireless sensor networks, without the need for application layer
gateways. These gateways must be aware of application layer data and
need an understanding of semantics of payload. The communication
with existing networking devices or other existing implementations
must be transparent for these external hosts. Application layer data
compression and encoding should only affect the 6LoWPAN network and
communication inside the network, like 6LoWPAN does with IPv6
headers. But payload on application layer is not self-contained in
one packet like IP, TCP and UDP headers. Defining new extension to
be implemented by the external nodes is not a proper solution and
violates the core concept of 6LoWPAN protocols.
New possibilities for application layer data encoding must be found,
to allow efficient data encoding for traffic inside the 6LoWPAN
Moritz Expires June 21, 2010 [Page 9]
Internet-Draft Abbreviated Title December 2009
network without affecting external communication. A new Encoding
Router (ER) role might be defined. This ER is located at the edge
router and not only translates compressed network and transport layer
protocols, but also standardized application layer encoding and
compression (e.g. EXI format in compliant XML/SOAP envelopes). This
requires no understanding of semantics of the payload, but allows a
seamless connectivity. The deployment of an ER might violate the
layered model, because the ER must receive external message as
representative to the 6LoWPAN nodes, encodes the messages and
forwards them (outgoing traffic vice versa). But protocols might
require correct transport layer addresses for origin and target
hosts. Thus, adaptions to transport layer header fields (TCP and
UDP) are required at runtime to hide the transparent intermediate ER.
3.3.2. TCP vs. UDP
TCP makes use of mechanisms like sliding window and flow control, to
optimize throughput. These mechanisms are questionable in wireless
sensor networks. Hence, the above described Encoding Router (ER)
might also allow an throughput optimized external communication all
the way to the ER and more optimized mechanisms in the 6LoWPAN
networks. To reduce TCP overhead, also UDP might be used inside
6LoWPAN networks instead. But most application layer protocols base
on TCP because of the required end-to-end reliability. The usage of
the lightweight UDP for internal communication instead of TCP would
require additional mechanisms to assure end-to-end reliability
between endpoints. Also definition of an extension for UDP to
provide this functionality is possible, but reinventing TCP must be
omitted.
4. IANA Considerations
The new defined discovery addresses have to be registered at IANA.
5. Security Considerations
No security issues have been identified in this draft.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Moritz Expires June 21, 2010 [Page 10]
Internet-Draft Abbreviated Title December 2009
6.2. Informative References
[DPWS] Driscoll and Mensch, "OASIS Devices Profile for Web
Services (DPWS) Version 1.1", 2009,
<http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01>.
[EXI-format]
Scheider and Kamiya, "W3C Efficient XML Interchange (EXI)
Format 1.0 Candidate Recommendation", December 2009,
<http://www.w3.org/TR/2009/CR-exi-20091208/>.
[I-D.frank-6lowapp-chopan]
Frank, B., "Chopan - Compressed HTTP Over PANs",
draft-frank-6lowapp-chopan-00 (work in progress),
September 2009.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S.,
Bormann, C., and E. Nordmark, "6LoWPAN Neighbor
Discovery", draft-ietf-6lowpan-nd-07 (work in progress),
October 2009.
[SOAP-over-UDP]
Jeyaraman, "OASIS SOAP-over-UDP Version 1.1", 2009, <http:
//docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/
wsdd-soapoverudp-1.1-spec-os.html>.
[WS-DD] OASIS Open, "OASIS Web Services Discovery and Web Services
Devices Profile (WS-DD) TC", 2009, <www.oasis-open.org/
committees/ws-dd/>.
[WS-Discovery]
Modi and Kemp, "OASIS Web Services Dynamic Discovery (WS-
Discovery) Version 1.1", 2009,
<http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01>.
[WSDL] Christensen, Curbera, Meredith, and Weerawarana, "W3C Web
Services Description Language (WSDL) 1.1", March 2001,
<http://www.w3.org/TR/2009/CR-exi-20091208/>.
Moritz Expires June 21, 2010 [Page 11]
Internet-Draft Abbreviated Title December 2009
Author's Address
Guido Moritz
University of Rostock
18051 Rostock,
Germany
Phone: +49 381 498 7269
Email: guido.moritz@uni-rostock.de
Moritz Expires June 21, 2010 [Page 12]