sync: chatty things: service provisioning, bootstrap

diff --git a/biblio.bib b/biblio.bib
index 7f1a489..fff80b7 100644 (file)
--- a/biblio.bib
+++ b/biblio.bib
@@ -159,6 +159,17 @@
        year = "2010"
 }
 
+@misc{xep-0175,
+       abstract = "This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.",
+       author = "Saint-Andre, Peter",
+       howpublished = "\url{http://xmpp.org/extensions/xep-0175.html}",
+       month = sep,
+       organization = "{XMPP Standards Foundation}",
+       series = "{XMPP Extension Protocols}",
+       title = "{XEP-0175: Best Practices for Use of SASL ANONYMOUS}",
+       year = "2009"
+}
+P
 @misc{xep-0045,
        abstract = "This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc.",
        author = "Saint-Andre, Peter",

diff --git a/main.tex b/main.tex
index bd1cb9b..51d61f4 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -30,6 +30,11 @@ short overview, not too long: what do we want, what are we
 going to do
 
 basically: how do we talk to our smart home?
+\paragraph{Human-to-Machine Communication:} especiall in the Internet of Things,
+       Chatty Things need to be accessible for the user and should be easy to talk
+       to.
+\paragraph{Interoperability} integration into already existing
+infrastructure.
 
 %% Prerequisites
 \section{Prerequisites}
@@ -54,7 +59,7 @@ Middleware, Application protocol gateways:
                \item everything-built-in
                \item discovery over multicast, service discovery over /.well-known
                        entry-point
-               \item maps to HTTP => stateless
+               \item maps to HTTP => stateless => relies on application gateway
                \item low protocol overhead and parsing complexity (binary messages)
                \item only draft status
                \item UDP with Ack and IDs instead of TCP... (limited state machine)
@@ -66,7 +71,7 @@ Middleware, Application protocol gateways:
                \item TCP/IP
                \item small overhead: 2 byte header + variable header length
                \item publish-subscribe with topic names
-               \item binary protocol
+               \item binary protocol => application-level gateway
                \item discovery?
        \end{itemize}
        \item Devices Profile for Web Services \cite{zeeb-moritz-ws4d}

diff --git a/sec-chatty-things.tex b/sec-chatty-things.tex
index 5be64d4..01f0bb2 100644 (file)
--- a/sec-chatty-things.tex
+++ b/sec-chatty-things.tex
@@ -1,7 +1,127 @@
 \section{System Architecture of ``Chatty Things''}
+
+After the underlying techniques have been explained, we can have a look at the
+system architecture which Klauck and
+Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
+
+
 \todo
 \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,
+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
+functions of XMPP (presence and message exchange, multi-user chats) to achieve
+basic communication, grouping of devices, and information filtering to prevent
+information overflow.
+
+Their solution builds on the \term{Contiki} operating system on an MSP430 board,
+and uses the \term{uXMPP} project, which already implements core XMPP features
+and serves as a starting point for implementing further XEPs. However, as the
+uXMPP project was still in early development, they first needed to enhance its
+functionality to comply with the limited resources. In particular, they
+optimized the message flow and enabled uXMPP to fully use the available payload
+instead of sending one TCP packet per message and reduced the code footprint
+through compiler flags and refactoring.
+
+Furthermore, Klauck and Kirsche implemented new features for uXMPP, which were
+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 item]
+\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 \ref{xep-0175}
+  \item a new publish-subscribe mechanism called Temporary Subscription for
+    Presence (see \ref{sec:tsp})
+  \item XMPP Serverless Messaging (XEP-0174), using \term{uBonjour} as
+    underlying mDNS/DNS-SD implementation for Contiki.
+\end{itemize}
+
+The resulting implementation (uXMPP and uBonjour) gets by with 12{.}2\ kBytes of
+ROM and 0{.}63\ kBytes of RAM, which was about the size of the original,
+unoptimized uXMPP implementation while also implementing new features.
+
+\todo[figure of example network structure with and without central server]
+
+In order to react to different network infrastructures, their implementation
+allows both communication with a central XMPP server as well as peer-to-peer
+communication over XMPP Serverless Messaging. When a central XMPP server is
+detected over uBonjour, it is used instead with the ANONYMOUS login method, and the
+XEP-0174 module is disabled. The ANONYMOUS login method is chosen since TLS
+encryption is not yet implemented, and it assigns random JID to the client,
+which do not need to exist on the server. However, a server must exist and must
+be configured in order to use this method.
+
+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.
+
+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
+drawback that Multi-User Chats cannot be used for topic filtering, since no
+method is specified to do XEP-0045 and XEP-0174 at the same time. \todo[temporary subscription presence here?]
+In this case,
+a user must have an XEP-0174-compliant chat client, but it also gives her the
+opportunity to interact with things spontaneously on an ad-hoc basis (e.~g. when
+entering a room) without need for any additional gateway on the application
+level.
+
+%low bandwith in IEEE~802.15.4 (less than 250 kib/s at a maximum of 122 byte per
+%packet\footnote{according to the maximum MAC payload size in the IEEE~802.15.4-2011
+%specification}
+
 \subsection{Bootstrapping}
-\subsection{Presence Subscription}
 
+In a distributed context like the Internet of Things, devices need to be ready
+to use out of the box. Users often do not want to set up configurations for each
+device they use, and when using several of those devices, it is often not
+reasonable having to configure every single one.
+
+With the given approach, bootstrapping new Chatty Things is easy and no
+configuration is neccessary: on the network layer, IP addresses can simply be
+obtained using IPv4 Link-Local Addressing or IPv6 Stateless Address
+Autoconfiguration. On the transport layer, all needed ports can be obtained over
+DNS-Based Service Discovery. Finally, on the application layer, host names can
+be resolved over Multicast DNS; and for the actual communication between devices
+it is possible to use auto-generated JIDs with the ANONYMOUS login method on an
+existing XMPP server, or if no server is found, use peer-to-peer communication
+over XMPP Serverless Messaging.
+
+Bootstrapping a Chatty Thing therefore incorporates three steps:
+
+\begin{enumerate}
+  \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}.
+\end{enumerate}
+
+During runtime, a device can then react to changes in network infrastructure:
+
+\begin{itemize}
+  \item In Infrastructure mode: when connection to the server is lost, enable
+    the uBonjour client, try to find a server, and when none is found, enable
+    Serverless Messaging.
+  \item In Ad-hoc mode: if uBonjour detects a new XMPP server joining the
+    network, try to connect to it. If this succeeds, disable Serverless
+    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
+
+% vim: set ft=tex et ts=2 sw=2 :

diff --git a/sec-xmpp.tex b/sec-xmpp.tex
index 451a317..f1b57b4 100644 (file)
--- a/sec-xmpp.tex
+++ b/sec-xmpp.tex
@@ -81,7 +81,7 @@ terminated.
 
 \cite{rfc6121}
 
-\subsubsection{XMPP Serverless Messaging}
+\subsubsection{XMPP Serverless Messaging}\label{sec:xsm}
 \todo
 
 To overcome the need for a central server and authentication, XMPP Serverless