year = "2013"
}
-
+@misc{rfc2131,
+ author="R. Droms",
+ title="{Dynamic Host Configuration Protocol}",
+ series="Request for Comments",
+ number="2131",
+ howpublished="RFC 2131 (Draft Standard)",
+ publisher="IETF",
+ organization="Internet Engineering Task Force",
+ year=1997,
+ month=mar,
+ note="Updated by RFCs 3396, 4361, 5494, 6842",
+ url="http://www.ietf.org/rfc/rfc2131.txt",
+}
what are the challenges? (interoperability, H2M interface, self-configuration,
information filtering to prevent information overflow)
+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.
+
+
%\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.
\subsection{Address allocation}
-Considering the TCP/IP protocol suite, in order to be able to communicate on the
-IP layer, a device needs to configure one of its network interfaces with
-an IP address that can be reached from the network that the device wants to connect
-to. There are several ways of achieving this:
-
-\begin{itemize}
- \item The IP address is pre-selected by a human and stored in the device
- configuration. This process is cumbersome when more than one device needs to
- be configured, and humans have to remember which addresses are configured on
- which device, and which addresses are still free to use on additional
- devices.
-
- \item Deploying a central server that assigns network addresses
- to the devices in the network, which in order query the server (for example
- via broadcast or on a lower layer) for a unique address before they use the
- IP layer for the first time. This technique supersedes the dependency of
- human memory for mapping IP addresses to devices, and can easily be combined
- with additional central configuration management, like the automatic
- assignment of a static gateway, or a DNS resolver.\\
- The DHCP protocol is one example of central IP address management.
- \item A third alternative is the use of a distributed protocol which enables
- the devices on the network to choose addresses in accordance with other
- devices on the same network, so no IP address is used more than once. In
- respect to the Internet of Things, this approach has the advantage that
- those devices can easily be used in different scenarios without needing
- central deployment at all, and also allowing them to change their addresses
- dynamically, therefore easily reacting to changes in the network. \\
- There are two major protocols which are used for dynamic configuration of IP
- addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often
- used, and in IPv6 networks, Stateless Address
- Autoconfiguration~\cite{rfc4862} is a fundamental feature built into every
- device.
-
-\end{itemize}
+Considering the TCP/IP protocol suite, in order to be able to communicate on the
+IP layer, a device needs to configure one of its network interfaces with an IP
+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
+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.
+
+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
+addresses dynamically in order to react to changes in the network.
+
+There are two major protocols which are used for dynamic configuration of IP
+addresses. In the IPv4 world, Link-Local Addressing~\cite{rfc3927} is often
+used, and in IPv6 networks, Stateless Address Autoconfiguration~\cite{rfc4862}
+is a fundamental feature specified in the IPv6 protocol.
\paragraph{IPv4 Link-Local Addressing}
address is not used on the network (e.~g. no device returned an ARP response
during a random time interval), the device claims its chosen address and uses it
for communication on the IPv4 layer. If the chosen address is already used, the
- device continues the process, subsequently choosing a new random address and
- trying to claim it, until a free address has been found.
+device continues the process, subsequently choosing a new random address and
+trying to claim it, until a free address has been found.
\paragraph{IPv6 Stateless Address Autoconfiguration}
Similar to IPv4 Link-Local Addressing, devices configured with \term{IPv6
-Stateless Addressing Autoconfiguration} use an IPv6 address from the subnet
-\code{fe80::/64}. First, an \term{interface identifier} is generated using the
-interface's MAC address. Since MAC addresses must be unique in the network, a
-unique IPv6 address is obtained by combining the subnet prefix and the interface
-identifier. To ensure that no other device exists with this generated IPv6
-address, the device performs \term{Duplicate Address Detection} on the network
-through \term{Neighbor Advertisement} messages and listening for \term{Neighbor
-Solicitation} messages. If such messages are received from other hosts, the
-configured address cannot be used by the device and must be discarded.
-Therefore, in order to use IPv6 effectively, it must be guarranteed that MAC
-addresses are unique on the network.
+Stateless Address Auto\-configuration} use an IPv6 address from the subnet
+\code{fe80::/64}. First, a 64-bit \term{interface identifier} is generated,
+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
+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.
In contrast to IPv4 Link-Local Addressing, IPv6 Stateless Address
Autoconfiguration can also be used with a central server. In this case, a
\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
+After the underlying techniques have been explained, we can now have a look at
+the system architecture which Klauck and
Kirsche~\cite{Klauck:2012:BCC:2352852.2352881} use to build Chatty Things.
\pages{3}
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.
+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 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.
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
\subsection{Bootstrapping}
-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
\subsection{Temporary Subscription for Presence}\label{sec:tsp}
-To further reduce the message overhead and allow more fine-grained controls over
+To further reduce the message overhead and allow more fine-grained control over
information filtering, \term{Temporary Subscription for Presence} is introduced.
-This technique builds on top of presence stanzas as defined in core XMPP. These
-presence stanzas are sent without a \code{to} or \code{from} attribute, and
-therefore fit into a single TCP/IP packet over IEEE~802.15.4. However, to be
-able to receive these stanzas, a client must manually subscribe to those
-information in their roster, which requires further communication between nodes. As the network
-can change rapidly, subscriptions would be often outdated, and there would be
-much overhead of subscriptions and unsubscription packets, which would inhibit
-the flow of the actual information.
+This technique builds on top of presence stanzas as defined in core XMPP, which
+are sent by default without a \code{to} or \code{from} attribute, and therefore
+fit into a single TCP/IP packet over IEEE~802.15.4. However, a drawback of the
+presence mechanism defined by core XMPP is the fact that a client must manually
+subscribe to presence information of another client in order to receive it,
+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.
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
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, except with SOAP
+transported over TCP, which introduces very much overhead, especially with SOAP
being based on verbose XML. IPv6 support is only partially implemented.
For communication, standard APIs can be used.
which comes with protocol overhead and increased code size. However Klauck and
Kirsche show that with good optimization (in the code as well as in the
procotol), a complete stack can be implemented in 12 kByte of ROM, which leaves
-enough space for other applications to build onto it. As compared to Web
+enough space for other applications to be built onto it. As compared to Web
Services, Chatty Things are probably not as flexible, but they have less
overhead, even when using XML, while MQTT and CoAP provide less flexibility for
-future enhancement, therefore less protocol overhead and easier parsing.
+future enhancement, but less protocol overhead and easier parsing.
With TCP, mDNS, DNS-SD and XMPP as foundation, the proposed architecture builds
on reliable and established standards, which allows it to reuse Chatty Things in
(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 every single point of failure
+any central infrastructure, therefore eliminating most single points of failure
in the system.
It is always hard to trade flexibility and accessibility for efficiency. The
\term{Known-Answer Suppression}. It allows a querying host to specify already
known resources in its query when querying resources that could exist on more
than one host (e.~g., SRV records). The hosts matching those resources then do
-not generate a response.
+not generate a response, thus reducing the messages in the network and saving
+bandwidth, which is usually a scarce resource in wireless networks.
Finally, hosts may also send unsolicited responses. This can be used to notify
the network of new services available on a host.
\subsubsection{Architecture}
\begin{wrapfigure}{r}{0.5\textwidth}
\tikzstyle{iconlabel}=[text width=3cm, align=center, font=\footnotesize]
+ \tikzstyle{label}=[font=\footnotesize]
\begin{tikzpicture}[node distance=0pt,scale=1.5,>=stealth,thick]
\def\nodelist{
juliet/{(-1,-1)}/XMPP client \code{juliet@example.net}/below/computer,
romeo/{(1,-1)}/XMPP client \code{romeo@im.example.org}/below/computer%
}
\foreach \name/\pos/\text/\tpos/\icon in \nodelist {
- \node (\name) at \pos { \includegraphics[width=1.2cm]{icon-\icon.pdf} };
+ \node (\name) at \pos { \includegraphics[width=1cm]{icon-\icon.pdf} };
\node[\tpos=of \name,iconlabel] (\name text) { \text };
}
- \draw[<->,dashed] (juliet) -- node[anchor=east]{s2c} (examplenet);
- \draw[<->] (examplenet) -- node[anchor=south]{s2s} (imexampleorg);
- \draw[<->,dashed] (imexampleorg) -- node[anchor=west]{s2c} (romeo);
+ \draw[<->,dashed] (juliet) -- node[anchor=east,label]{s2c} (examplenet);
+ \draw[<->] (examplenet) -- node[anchor=south,label]{s2s} (imexampleorg);
+ \draw[<->,dashed] (imexampleorg) -- node[anchor=west,label]{s2c} (romeo);
\end{tikzpicture}
\centering
\caption{XMPP architecture, showing server-to-server (s2s) and
- server-to-client (s2c, dashed) connection types}
+ server-to-client (s2c) connections}
\label{fig:xmpparch}
\end{wrapfigure}
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 routing message, and manage
+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 are the interface for communication with other users.
+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
All communication over XMPP is based on XML. To minimize communication overhead,
only fragments of XML, called \term{stanzas}, are sent between hosts. A stanza
-is always well-formed as a whole; it consist of a root element, which also
-includes routing attributes (\code{to} and \code{from}), and its optional child
-elements.
+is always well-formed as a whole; it consists of a root element, which in most
+cases also includes routing attributes (\code{to} and \code{from}), and its
+optional child elements.
On top of that, living connections between hosts are represented by \term{XML
streams}. The client initiates a connection by sending an XML declaration
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
-other side then has the chance to send all outstanding stanzas and likewise
+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.
the other user's status. The mechanism behind this is called
\term{Publish-Subscribe} and is specified in XEP-0060~\cite{xep0060}. It can
be used to notify interested users about changes in personal information, and
-implements the classic Observer pattern.
+implements the well-known Observer pattern.
A user publishes information by creating a \term{node} on the XMPP server, which
acts as a handle for the data. Interested users can then query the server for
\subsubsection{Multi-User Chats}
-Besides one-to-one messaging, XMPP also allows users to create multi-user
-chat rooms, which is specified in \cite{xep0045}. Each chat room is given a
+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.
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} project, and nowadays
-it is also available in many other XMPP clients.
+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})
\item a PTR record \code{\_presence.\_tcp.local} for service discovery,
pointing to \code{juliet@capulet.\_presence.\_tcp.local}
\item and a TXT record \code{juliet@capulet.\_presence.\_tcp.local} specifying
- more information about her (e.~g. her online status, contact data, etc.)
+ more information about her (e.~g. her online status, contact data, etc.) in
+ standardized key-value pairs.
\end{itemize}
When other clients in the same network enumerate the available services by
projects / skm-ma-ws1314.git / commitdiff