\maketitle
\input{sec-intro.tex}
-
%% Prerequisites
\section{Prerequisites}\label{sec:prereq}
address that can be reached from the network that the device wants to connect
to. Letting the user choose and configure IP addresses manually is a cumbersome
when it comes to several devices. Deploying a central server for assigning IP
-addresses automatically from a pre-configured address pool is possible (e.~g.
-using the DHCP protocol~\cite{rfc2131}), however, there is also the alternative
+addresses automatically from a pre-configured address pool is possible (e.~g. by
+using DHCP~\cite{rfc2131}), however, there is also the alternative
to use a distributed protocol which enables the devices on a network to choose
-addresses in accordance with each other so no IP address is used twice.
+addresses in accordance with each other, so no IP address is used twice.
In respect to the Internet of Things, this decentralized approach has the
-advantage that devices can easily be used in different scenarios, even when
-central deployment does not exist, and it also allows them to change their
+advantage that devices can easily be used in different desployments, even where
+central infrastructures do not exist, and it also allows them to change their
addresses dynamically in order to react to changes in the network.
There are two major protocols which are used for dynamic configuration of IP
which can be random, or based on the interface's MAC address. Most likely, this
interface identifier is unique in the network, so a unique IPv6 address is
obtained by combining the subnet prefix and the interface identifier.
-Nonetheless, to ensure that no other device use the generated IPv6 address, the
+Nonetheless, to ensure that no other device uses the generated IPv6 address, the
device performs \term{Duplicate Address Detection} on the network by
-broadcasting
-its generated address with \term{Neighbor Advertisement} messages and listening
-for \term{Neighbor Solicitation} messages. If such a message is received from
-another hosts, the generated address cannot be used by the device and must be
-discarded, and the address generation process is repeated until a unique
-address has been found.
+broadcasting its generated address with \term{Neighbor Advertisement} messages
+and listening for \term{Neighbor Solicitation} messages. If such a message is
+received from another hosts, the generated address cannot be used by the device
+and must be discarded, and the address generation process is repeated until a
+unique address has been found.
In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
-Autoconfiguration can also be used with a central server. In this case, a
-central server broadcasts \term{Router Solicitation} messages on the network
+Autoconfiguration can also be used with a central server. In this case, the
+server broadcasts \term{Router Solicitation} messages on the network
which contain a global network prefix. The hosts on the network can then use
that prefix instead to configure a global IPv6 address.
the system architecture which Klauck and
Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
-\pages{3}
\subsection{Service Provisioning Sublayer}
Considering the application in deeply embedded systems and the special needs of
the Internet of Things on the one hand, the protocol stack needs to fulfil
certain technical requirements.
-First, memory, computing resources and bandwith on embedded systems are limited,
+First, memory, computing resources and bandwidth on embedded systems are limited,
which demands for a lightweight protocol stack without too much overhead and
predictable memory consumption, while also retaining enough flexibility for
future development. The authors therefore provide only the most essential
realized as separate modules to allow enabling and disabling them at runtime,
thus further reducing the memory footprint of a running system:
-\todo{minimize space between list items}
\begin{itemize}
\item support for IPv6
\item support for Multi-User Chats (XEP-0045), which are used for information
filtering
\item support for SASL ANONYMOUS login for XMPP servers \cite{xep0175}
\item a new publish-subscribe mechanism called Temporary Subscription for
- Presence (see \ref{sec:tsp})
+ Presence (see Section~\ref{sec:tsp})
\item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
underlying mDNS/DNS-SD implementation for Contiki.
\end{itemize}
the XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
encryption is not yet implemented, and with this method, the server assigns a
random JID to the client, which does not need to exist on the server. However, a
-server must exist and must be configured to use this login method in order to
-use this method.
+server must exist and must be configured to supply this login method in order
+for this approach to work.
With a server, information filtering is achieved by creating topic-based
Multi-User Chats where multiple devices can be grouped. A user can then simply
join the chat with a standard XMPP client on her machine and interact with all
-devices of a topic, or she can also interact with them directly.
+devices of a topic, or she can also interact with single devices directly.
In scenarios without an XMPP server, the XEP-0174 module is activated and
devices talk directly with the user or with other devices. This method has the
Bootstrapping a Chatty Thing therefore incorporates three steps:
\begin{enumerate}
- \item Activate uBonjour and try to discover an XMPP server
+ \item Activate uBonjour and try to discover an XMPP server.
\item If a server is found, connect to it using ANONYMOUS login, join
topic-based Multi-User Chats, deactivate the uBonjour client
- \term(Infrastructure mode).
- \item If no server is found, activate the XEP-0174 client \term{Ad-hoc mode}.
+ \term{(Infrastructure mode).}
+ \item If no server is found, activate the XEP-0174 client \term{(Ad-hoc
+ mode)}.
\end{enumerate}
-During runtime, a device can then react to changes in network infrastructure:
+During runtime, a device can then react to changes in network infrastructure by
+changing from one mode to the other:
\begin{itemize}
\item In Infrastructure mode: when connection to the server is lost, enable
Messaging and uBonjour and join topic-based Multi-User Chats.
\end{itemize}
-\todo{short conclusion?}
-
\subsection{Temporary Subscription for Presence}\label{sec:tsp}
To further reduce the message overhead and allow more fine-grained control over
which requires further communication between the clients. Since the network can
change rapidly, and clients can frequently join and leave the network,
subscriptions would often be outdated and must be renewed, leading to overhead
-of subscriptions and unsubscription packets, which would inhibit the flow of the
-actual information.
+of subscriptions and unsubscription messages, which would inhibit the flow of
+the actual information.
To solve this problem, a dynamic, topic-based roster is implemented on top of
Multi-User Chats (XEP-0045). Every topic corresponds with a chat room, and nodes
\section{Discussion}\label{sec:discussion}
-%\todo
-\pages{3}
\subsection{Future Work}
\paragraph{Concentrators (XEP-0326)~\cite{xep0326}}
In contrast to sensor nodes which are focused on collecting data, concentrators
-can be used to control and serve as proxy for a subset of the network. The XEP
+can be used to serve as a proxy and control a subset of the network. The XEP
defines messages to query a sensor node for data sources, and subscribing to
them, while subscription is loosely modeled after the Publish-Subscribe
-mechanism (XEP-0060). It also specifies how clients can request data from or
+mechanism (XEP-0060). It also specifies how clients can request data or
control certain nodes over a concentrator.
This approach can be practical in large-scale sensor networks, where usually not
sensor node. It allows to specify multiple data sources (e.~g. temperature,
humidity) as well as multiple types of data (e.~g., momentary values, historical
values, peak values).
-As a simple use case, the client sends an \code{<iq>} stanza containing the request and a
+As a simple use case, the client sends an IQ stanza containing the request and a
sequence number used to identify the request. The sensor node then rejects or
-accepts the request by returning a corresponding \code{<iq>} stanza. If it has
+accepts the request by returning a corresponding IQ stanza. If it has
accepted the request, it reads out the requested data and returns it in a
-subsequent \code{<message>} stanza to the client.
+subsequent message stanza to the client.
-\paragraph{Control (XEP-0325)~\cite{xep0325}}
-In this document, a way of controlling sensor nodes is specified, which allows a
-client to get and set control values on the node over
-\code{<message>} or \code{<iq>} stanzas. As an example, in this way a sensor
-node can be instructed to return data in a different unit or range, or can be put
-into power-safe mode.
+\paragraph{Control (XEP-0325)~\cite{xep0325}} In this document, a way of
+controlling sensor nodes is specified, which allows a client to get and set
+control values on the node over message or IQ stanzas. As an example, in this
+way a sensor node could be instructed to return data in a different unit or
+range, or be put into power-safe mode.
\paragraph{Provisioning (XEP-0324)~\cite{xep0324}}
To protect the integrity of a sensor network and securing the data being
-collected, this document specifies a way of implementing access rights and user
+collected, this XEP specifies a way of implementing access rights and user
privileges. Since a single sensor node is usually very restricted in user input and
output, the approach is very simple and can be implemented e.~g. using a button
and an LED for interaction, while presentation of data takes places on a
button press in the next 30 seconds. If the user presses the button, the node
confirms the friendship to the server. The server then remembers this sensor
node and generates a token which must be used in all further communication
-between the server and the sensor node or the communication is rejected.
+between the server and the sensor node, else communication is rejected.
\paragraph{Efficient XML Interchange Format (EXI, XEP-0322)~\cite{xep0322}}
Finally, EXI describes how XMPP stanzas sent between nodes can be compressed,
\subsection{Related Approaches}
-Chatty Things is not the only approach to implement communication in embedded
-networks. This section gives a short overview of related protocols for the
-Internet of Things and shows their advantages and disadvantages, which are
+``Chatty Things'' is not the only approach to implement communication in
+embedded networks. This section gives a short overview of related protocols for
+the Internet of Things and shows their advantages and disadvantages, which are
summarized in Table~\ref{tab:comparison}.
\begin{table}
The Constrained Application Protocol~\cite{draft-ietf-core-coap-18} focuses on
machine-to-machine communication and originates from the IETF Constrained
-Resources Working Group, but still has been only in draft status since 2010.\ It
-allows a mapping to HTTP, and is therefore stateless, but it specifies a binary
-protocol, which makes it neccessary to deploy application-level gateways and
-special client software to communicate with its environment. It relies on UDP,
-but emulates congestion control, message confirmation and message IDs, since –
-in contrast to HTTP – messages can be sent asynchronously. Discovery is also
-specified and done over multicast, service discovery is then done over a
-well-known URI on the host. Since it is a binary protocol and mostly
-self-contained, it has low protocol overhead and parsing complexity.
+Resources Working Group\footnote{\url{http://datatracker.ietf.org/wg/core/}},
+but still has been only in draft status since 2010.\ It allows a mapping to
+HTTP, and is therefore stateless, but it specifies a binary protocol, which
+makes it neccessary to deploy application-level gateways and special client
+software to communicate with its environment. It relies on UDP, but emulates
+congestion control, message confirmation and message IDs, since – in contrast to
+HTTP – messages can be sent asynchronously. Discovery is also specified and done
+over multicast, service discovery is then done over a well-known URI on the
+host. Since it is a binary protocol and mostly self-contained, it has low
+protocol overhead and parsing complexity.
\paragraph{MQ Telemetry Transport (MQTT)}
be used in existing infrastructures, and is also focused on multiple platforms
like embedded systems and servers. Web Services can be very flexible and
composable, and discovery is already specified, however, this also comes at a
-cost: web services are enclosed in SOAP, which is enclosed in HTTP, which is
-transported over TCP, which introduces very much overhead, especially with SOAP
-being based on verbose XML. IPv6 support is only partially implemented.
+cost: messages are enclosed in SOAP, which is enclosed in HTTP, which is
+transported over TCP, which introduces a substantial overhead, especially with
+SOAP being based on verbose XML. IPv6 support is only partially implemented.
For communication, standard APIs can be used.
\subsection{Conclusion}
which is caused by the lack of support for Multi-User Chats in XEP-0174
(Serverless Messaging). If this gap can be closed, or a different way for topic
filtering in distributed networks is found, the server can be
-eliminated and what remains is truly distributed network without the need for
-any central infrastructure, therefore eliminating most single points of failure
+eliminated and what remains is a highly distributed network without the need for
+much central infrastructure, therefore eliminating most single points of failure
in the system.
It is always hard to trade flexibility and accessibility for efficiency. The
Chatty Things approach is probably not one of the most efficient, and not the
most flexible, but it has the big advantage that users can interact with their
things using standard chat clients, without the need for application gateways or
-specialized software. In terms of efficiency, it chooses a common ground between
-binary protocols and Web Services, which were originally developed for servers
-with much less resource constraints as embedded systems.
+specialized software. In terms of efficiency, it chooses a compromise between
+binary protocols and Web Services, latter which were originally developed for
+servers with much less resource constraints as embedded systems. However, with
+additional XEPs focusing on the Internet of Things, enough flexibility can be
+achieved for this use case.
% vim: set ft=tex et ts=2 sw=2 :
The first problem is addressed with \term{Multicast DNS}, and since DNS is
basically a key-value store, it can also be used for service discovery, which is
achieved using \term{DNS-Based Service Discovery}. Both techniques were first
-developed by Apple as part of the \term{Bonjour} project, and are now maintained
-by the IETF Zeroconf working group.
+developed by Apple as part of the \term{Bonjour}
+project\footnote{\url{https://developer.apple.com/bonjour/}}, and are now
+maintained by the IETF Zeroconf working
+group\footnote{\url{http://zeroconf.org}}.
\subsubsection{Multicast DNS}
-\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
+\term{Multicast DNS} (mDNS)~\cite{rfc6762} describes an extension to the Domain
Name System that allows DNS resource records to be distributed on multiple hosts
in a network, therefore avoiding central authorities and enabling every host to
publish its own entries. For that purpose, a special domain, usually
not generate a response, thus reducing the messages in the network and saving
bandwidth, which is usually a scarce resource in wireless networks.
+\enlargethispage{2\baselineskip}
Finally, hosts may also send unsolicited responses. This can be used to notify
the network of new services available on a host.
-\pages{1}
-
\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
As another recent extension for the Domain Name System, \term{DNS-Based Service
Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
-\code{SRV}~\cite{rfc2782} and \code{PTR} in a way that allows hosts to browse
-for services in a domain. As an example, Figure~\ref{fig:dnssd} shows the
-process of browsing for all XMPP clients in the domain \code{example.org}.
-This is a two-step process, consisting of \term{Service Instance Enumeration}
-and \term{Service Instance Resolution}.
-
-\todo{XMPP is a probably not the best example here, use IPP instead}
-\begin{figure}[top]
- \centering
- \includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg}
- \caption{DNS-SD: Service Instance Enumeration and Resolution}
- \label{fig:dnssd}
-\end{figure}
+SRV~\cite{rfc2782} and PTR in a way that allows hosts to browse
+for services in a domain. This is a two-step process, consisting of
+\term{Service Instance Enumeration} and \term{Service Instance Resolution}.
-\paragraph{Service Instance Enumeration} At first, to enumerate the available
+%\todo{XMPP is a probably not the best example here, use IPP instead}
+%\begin{subfigure} \end{subfigure} \begin{figure}[top] \centering
+%\includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg} \caption{DNS-SD:
+%Service Instance Enumeration and Resolution} \label{fig:dnssd} \end{figure}
+\paragraph{1. Service Instance Enumeration} At first, to enumerate the available
services in a domain for a given protocol, a DNS-SD-enabled client queries
-resources of type \code{PTR} of the form \code{\_service.\_proto.domain}. The
-result of this query is then a list of \term{instance names} of the form
-\code{name.\_service.\_proto.domain} which provide the specified service. For
-example, in Figure~\ref{fig:dnssd}, by querying for
-\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol in the
-domain \code{example.org} are enumerated, and as a result, the instance names of
-three hosts are returned.
+PTR resources of the form \code{\_service.\_proto.domain}. The result of
+this query is then a list of \term{instance names} of the form
+\code{name.\_service.\_proto.domain} which point to the hosts providing the
+service. For example, by querying for \code{\_ipp.\_tcp.\_example.org}, the
+instance names for all printers supporting the IPP protocol in the domain
+\code{example.org} are returned.
-\paragraph{Service Instance Resolution} As a second step, the returned instance
-names are resolved as \code{SRV} records to retrieve the actual host names and
-port numbers of a service. In the example, resolution of one instance name shows
+\paragraph{2. Service Instance Resolution} As a second step, the returned instance
+names are resolved as SRV records to retrieve the actual host names and
+port numbers of a service. For example, resolution of one instance name shows
that an IPP server is running at host \code{gutenberg.example.org} on port 5222.
-Additionally, an optional \code{TXT} record with the same instance name can
-contain further information about the service (e.~g., information about the
+Additionally, an optional TXT record with the same instance name can
+contain further information about the service (e.~g. information about the
supported paper sizes).
-Through the usage of \code{SRV} records, it is easily possible for a service to
+Through the usage of SRV records, it is easily possible for a service to
inform clients about non-standard port numbers, and especially in connection
-with Multicast DNS makes it easy to deploy decentralized systems for the
-Internet of Things~\cite{Klauck:2012:BCC:2352852.2352881}.
+with Multicast DNS, this makes it easy to deploy decentralized systems for the
+Internet of Things. \cite{Klauck:2012:BCC:2352852.2352881}
-\pages{1}
% vim: set ft=tex et ts=2 sw=2 :
%% Introduction
\section{Introduction}
-\todo{asdf}
-\pages{0-1}
Following the vision of the ``Internet of Things'', the amount of wireless
devices is steadily increasing, which not only improves our standard of living
\subsection{XMPP}
-\pages{3-4}
The \term{Extensible Messaging and Presence Protocol (XMPP)} is a distributed,
XML-based protocol for real-time communication. Its core functionalities are
-specified in RFCs~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
+specified in RFC~6120~\cite{rfc6120} and RFC~6122~\cite{rfc6121}, while protocol
extensions are usually defined by the XMPP community in \term{XMPP Extension
Proposals (XEPs)}.
\subsubsection{Addressing}
+\enlargethispage{2\baselineskip}
Every user account in XMPP is addressed by a globally unique identifier, called
the \term{Jabber ID (JID)}~\cite{rfc6122}. It has the form
-\code{localpart@domainpart/resource}, where \code{domainpart} is the DNS name of
-an XMPP server, and \code{localpart} is the name of a user account on that
-server. Since a user can be logged in from multiple clients, the \code{resource}
-part is a string chosen by the user to distinguish those clients. Only the part
-\code{localpart@domainpart} (the \term{bare JID}) is needed to identify a user,
-the resource is only needed for routing between client and server.
+\code{localpart@domain/resource}, where \code{domain} is the DNS name of an XMPP
+server, and \code{localpart} is the name of a user account on that server. Since
+a user can be logged in from multiple clients at the same time, the
+\code{resource} part is a string chosen by the user to distinguish those
+clients. Only the part \code{localpart@domain} (the \term{bare JID}) is
+needed to identify a user, the resource is only needed for routing between
+client and server.
\subsubsection{Architecture}
\begin{wrapfigure}{r}{0.5\textwidth}
The original architecture underlying XMPP strongly leans on the established
design of Internet Mail, and an example is depicted in Fig.~\ref{fig:xmpparch}.
The distributed network is formed by \term{XMPP servers} on one hand, which make
-up the always-on backbone of the network used for message routing, and manage
-user accounts and statuses. On the other hand, \term{XMPP clients} represent a
-single logged-in user and make up the interface for communication with other
-users.
+up the always-on backbone of the network used for message routing, and which
+manage user accounts and statuses. On the other hand, \term{XMPP clients}
+represent a single logged-in user and make up the interface for communication
+with other users.
Every client communicates only with the server that manages the respective user
account which is configured in the client, as given in the user's JID. The
an opening \code{<stream>} tag. The client then performs SASL authentication and
binds its stream to a resource for proper addressing. If this process succeeded,
both client and server can send an unlimited number of stanzas, until the
-connection is closed by one side by sending an closing \code{</stream>} tag. The
+connection is closed by one side by sending a closing \code{</stream>} tag. The
other side then has the chance to send all outstanding stanzas and then likewise
closes its stream. If both streams are closed, the underlying TCP connection is
terminated.
+%\todo{see section... for example stream}
+
\subsubsection{Publish/Subscribe and Presence}
Typically, a user wants to chat with a more or less fixed set of other users,
whose JIDs she needs to know, so she needs some kind of ``address book'' that
-remembers the JIDs for her. In XMPP, this is address book is called
+remembers the JIDs for her. In XMPP, this address book is called
\term{roster}, and it also shows the users' willingness to chat (``presence'').
In order to see their chat status (which can be one of ``online'', ``offline'',
and several ``away'' or ``do not disturb'' states), a user needs to subscribe to
Besides one-to-one messaging, XMPP also allows users to create multi-user chat
rooms, which is specified in XEP-0045~\cite{xep0045}. Each chat room is given a
-unique JID to which the users send their messages to. Each incoming message is
-then dispatched to all users which have joined the room.
+unique JID on the server managing the room to which the users send their
+messages to. Each incoming message is then dispatched to all users which have
+joined the room.
To join a room, the user sends a \code{<presence>} stanza to the room JID, where
the resource part of the room JID specifies the desired nick name.
\subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
-\pages{1}
To overcome the need for a central server and authentication, XMPP Serverless
Messaging~\cite{xep0174} allows XMPP clients on a network to build a
peer-to-peer mesh network and chat directly with each other. This feature was
-first introduced by Apple as part of their \term{Bonjour}\footnote{see
-\url{https://developer.apple.com/bonjour/}} project, and nowadays it is also
-available in many other XMPP clients.
-
-With XMPP Serverless Messaging, XMPP clients simply open a port on the host, and
-then rely on mDNS and DNS-SD (see Section~\ref{sec:dns})
-to publish instance names in the domain \code{\_presence.\_tcp.local}. For
-example, if Juliet uses her machine (named \code{capulet}) with serverless
-messaging, her client would publish the following four mDNS records:
+first introduced by Apple as part of their \term{Bonjour} project, and nowadays
+it is also available in many other XMPP clients.
+
+%\begin{wrapfigure}{R}{0.4\textwidth}
+ %\tikzstyle{iconlabel}=[text width=2cm, align=center, font=\footnotesize]
+ %\tikzstyle{label}=[font=\footnotesize]
+ %\begin{tikzpicture}[node distance=0pt,scale=1.2,>=stealth,thick]
+ %\def\nodelist{
+ %juliet/{(-1,-1)}/\code{juliet@\ balcony.local}/below/computer,
+ %tybalt/{(-1,1)}/\code{tybalt@\ montague.local}/above/computer,
+ %mercutio/{(1,1)}/\code{mercutio@\ capulet.local}/above/computer,
+ %romeo/{(1,-1)}/\code{romeo@\ romeo.local}/below/computer%
+ %}
+ %\foreach \name/\pos/\text/\tpos/\icon in \nodelist {
+ %\node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
+ %\node[\tpos=of \name,iconlabel] (\name text) { \text };
+ %}
+ %\draw[<->,dashed] (juliet) -- (tybalt);
+ %\draw[<->,dashed] (juliet) -- (romeo);
+ %\draw[<->,dashed] (juliet) -- (mercutio);
+ %\draw[<->,dashed] (romeo) -- (mercutio);
+ %\draw[<->,dashed] (romeo) -- (tybalt);
+ %\draw[<->,dashed] (mercutio) -- (tybalt);
+ %\end{tikzpicture}
+ %\centering
+ %\caption{XMPP architecture with Serverless Messaging}
+ %\label{fig:xmpparch2}
+%\end{wrapfigure}
+
+With XMPP Serverless Messaging, XMPP clients simply open a port on their host,
+and then rely on mDNS and DNS-SD (see Section~\ref{sec:dns}) to publish instance
+names in the domain \code{\_presence.\_tcp.local}. For example, if Juliet uses
+her machine (named \code{capulet}) with serverless messaging, her client would
+publish the following four mDNS records:
\begin{itemize}
\item an A record \code{capulet.local}, specifying her IP address,
projects / skm-ma-ws1314.git / commitdiff