DTN Research Group B. Gernert, S. Schildt
INTERNET-DRAFT IBR, TU Braunschweig
Intended Status: Experimental
Expires: September 12, 2013 March 11, 2013
Delay Tolerant Networking Email Convergence Layer Protocol
draft-gernert-dtnrg-mailcl-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF). Note that
other groups may also distribute working documents as
Internet-Drafts. The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current.
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".
This Internet-Draft will expire on September 12, 2013.
Abstract
This document describes the protocol for the Email-based Convergence
(MCL) Layer for Delay Tolerant Networking (DTN).
Copyright and License Notice
Copyright (c) 2013 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
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 Simplified BSD License.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 1]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in this Document . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the Protocol . . . . . . . . . . . . . . . . . . . 5
3.1 Example Communication . . . . . . . . . . . . . . . . . . . 5
4. Email Format . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 MCL mail headers . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Encoding of the Primary Bundle Block . . . . . . . . . . . . 8
4.2 Encoding the Bundle Payload Block . . . . . . . . . . . . . 9
4.2.1 The Payload Block . . . . . . . . . . . . . . . . . . . 9
4.3 Encoding Extension Blocks . . . . . . . . . . . . . . . . . 10
4.4 Encoding a Status Report Block . . . . . . . . . . . . . . . 11
4.5 Encoding a Custody Signal Block . . . . . . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
B. Gernert, S. Schildt Expires September 12, 2013 [Page 2]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
1. Introduction
This document describes the Mail-based convergence layer protocol for
Delay Tolerant Networking (MCL). MCL is based on SMTP and IMAP.
Delay Tolerant Networking is an end-to-end architecture providing
communications in and/or through highly stressed environments,
including those with intermittent connectivity, long and/or variable
delays, and high bit error rates. More detailed descriptions of the
rationale and capabilities of these networks can be found in the
Delay-Tolerant Network Architecture RFC [RFC4838].
An important goal of the DTN architecture is to accommodate a wide
range of networking technologies and environments. The protocol used
for DTN communications is the Bundling Protocol (BP) [RFC5050], an
application-layer protocol that is used to construct a store-and-
forward overlay network. As described in the bundle protocol
specification, it requires the services of a "convergence layer
adapter" (CLA) to send and receive bundles using the service of some
"native" link, network, or Internet protocol.
This document describes one such convergence layer adapter that uses
SMTP and IMAP to transmit Bundles between BP nodes. With the MCL a
BP node can have a mailbox, allowing for asynchronous DTN
communication across the Internet when communication partners are not
online at the same time. This allows leveraging legacy Internet
services, without the need to deploy a native BP router in the
Internet.
The locations of the MCL and the BP in the Internet model protocol
stack are shown in Figure 1.
1.1. Conventions Used in this Document
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]
B. Gernert, S. Schildt Expires September 12, 2013 [Page 3]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+-------------------------+
| DTN Application | -\
+-------------------------| |
| Bundle Protocol (BP) | |
+-------------------------+ |-> Application Layer
| Email Conv. Layer (MCL) | |
+-------------------------+ |
| SMTP / IMAP | -/
+-------------------------+
| TCP | ---> Transport Layer
+-------------------------+
| IP | ---> Network Layer
+-------------------------+
| Link-Layer Protocol | ---> Link Layer
+-------------------------+
| Physical Medium | ---> Physical Layer
+-------------------------+
Figure 1: The location of the BP and the MCL
in the Internet protocol stack
2. Definitions
The following set of definitions are abbreviated versions of those
which appear in the Bundle Protocol Specification [RFC5050]. To the
extent in which terms appear in both documents, they are intended to
have the same meaning.
Bundle
A bundle is a protocol data unit of the DTN bundle protocol.
Bundle payload
A bundle payload (or simply "payload") is the application data
whose conveyance to the bundle's destination is the purpose for
the transmission of a given bundle.
Bundle node
A bundle node (or simply a "node") is any entity that can send
and/or receive bundles. The particular instantiation of this
entity is deliberately unconstrained, allowing for implementations
in software libraries, long-running processes, or even hardware.
One component of the bundle node is the implementation of a
convergence layer adapter.
Bundle endpoint and EID
B. Gernert, S. Schildt Expires September 12, 2013 [Page 4]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
A bundle endpoint (or simply "endpoint") is a set of zero or more
bundle nodes that all identify themselves for BP purposes by some
single text string, called a "bundle endpoint ID" (EID). The
special case of an endpoint that never contains more than one node
is termed a "singleton" endpoint; every bundle node must be a
member of at least one singleton endpoint.
Extension Blocks
"Extension blocks" are all blocks other than the primary and
payload blocks.
3. Overview of the Protocol
This specification provides a means to exchange bundles through an
E-mail server. It specifies how to encode Bundles within a mail.
To be able to use the MCL a node needs its own email address and
access to a mail server. A node will download received bundles from
the mail server and use it to send bundles to other nodes supporting
the MCL.
How to find the correct mail address for a BP EID is out of scope of
this specification. The mail address for an EID may be configured
statically, retrieved using existing discovery mechanism such as IPND
or BT-DHT or for MCL-only nodes a new EID scheme encoding the mail
address into the EID can be devised.
A bundle that has been successfully transmitted to a mail server will
be considered delivered by the sending node. To ensure end-to-end
acknowledgement of reception BP Bundle Status Reports can be used as
normal.
3.1 Example Communication
Figure 2 shows the communication between two nodes using the MCL.
Once node A's BP implementation comes into possession of a bundle
destined for node B it will search for suitable forwarding
opportunities. If node A gets to know B's MCL email address it will
encode the bundle into a mail and submit it to its SMTP server.
No the standard Internet mail system and protocols take over, finally
delivering the bundle to the inbox of node B's MCL email address.
Once B's MCL compliant BP implementation notices a new mail in its
MCL email address' inbox, it will retrieve the mail and decode the
contained bundle and deliver it to an application or forward it
further according to the BP [RFC5050].
B. Gernert, S. Schildt Expires September 12, 2013 [Page 5]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
Node A SMTP/IMAP servers Node B
====== ================= ======
+-----------------+
| Receives bundle |
| destined for B |
+-----------------+
||
\/
+-----------------+
| Retrieve email |
| address of B |
+-----------------+
||
\/
+-----------------+
| Encode bundle |
| in email |
+-----------------+
||
\/
+-----------------+ +--------------------+
| Send mail via | -> | Accept email |
| SMTP | -> | send to mailserver |
+-----------------+ | responsible for B |
+--------------------+
||
\/
+--------------------+ +-----------------+
| Store email in | <- | Check for new |
| INBOX of Node B | -> | mails via IMAP |
+--------------------+ +-----------------+
||
\/
+--------------------+ +-----------------+
| INBOX of Node B | -> | Receive mails |
| | -> | via IMAP |
+--------------------+ +-----------------+
||
\/
+-----------------+
| Decode Bundle |
| from email |
+-----------------+
Figure 2: Communication between two nodes using MCL
B. Gernert, S. Schildt Expires September 12, 2013 [Page 6]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
4. Email Format
This section describes how to encode a bundle into a mail messages
compliant with [RFC5322].
A mail consists of two parts: The header and the body. Additional
data can be attached to a mail encoded as MIME parts ([RFC2045],
[RFC2046], [RFC2047], [RFC2048], [RFC2049]).
A BP Bundle consists of the Primary Bundle Block, a Bundle Payload
Block and an arbitrary number of Extension Blocks and administrative
blocks (Bundle Status Reports, Custody Signals). The MCL encodes
fields from the Primary Bundle Block in the mail headers. This
allows a MCL implementation to decide whether to accept a bundle by
only fetching the headers from the IMAP server without the need to
download the whole bundle. The header fields form the Bundle Payload
Block will also be written to the [RFC5322] mail header.
The mail header also contains references to the payload data as well
as to all Extension Blocks and Administrative blocks. These blocks
will be attached as MIME Parts. There must be one MIME part of the
type application/octet-stream for each block.
The mails subjects field and the message body should contain some
text explaining that this mail contains a bundle. Information about
the bundle may be given in human-readable form.
Unless otherwise noted all fields have the same meaning content as
described in [RFC5050]. Regardless of type, all fields are encoded as
strings in the mail header. For INTs and SDNVs a decimal
representation is used. Thus
The STRING "somestring" is encoded as "somestring"
The SDNV with the bit pattern 10000001 00001111 is encoded as "143"
The INT with the bit pattern 10000001 00001111 is encoded as
"33039"
4.1 MCL mail headers
Table 1 shows the additional MCL headers that are not derived from
[RFC5050].
B. Gernert, S. Schildt Expires September 12, 2013 [Page 7]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+--------------------------------------------+--------+----------+
| Header-Field | Type | Optional |
+============================================+========+==========+
| Bundle-EMailCL-Version | INT | |
+--------------------------------------------+--------+----------+
| Bundle-Additional-Block-Count | INT | x |
+--------------------------------------------+--------+----------+
| Bundle-Additional-Block-1 | STRING | x |
+--------------------------------------------+--------+----------+
| Bundle-Additional-Block-... | STRING | x |
+--------------------------------------------+--------+----------+
| Bundle-Additional-Block-n | STRING | x |
+--------------------------------------------+--------+----------+
Table 1: MCL specific header fields
Bundle-EMailCL-Version:
Version of the MCL specification. A "1" denotes the version of
the MCL described in this document. Other values are reserved for
further use.
Bundle-Additional-Block-Count:
If a bundle contains any blocks besides the Primary Bundle Block
or the Payload Block, such as extension blocks or administrative
blocks, the total number of blocks is given by the Bundle-
Additional-Block-Count header. If this header is missing, it
implies that the bundle has no additional blocks except the
Primary Bundle Block.
Bundle-Additional-Block-n:
If Bundle-Additional-Block-Count is not zero, the headers Bundle-
Additional-Block-1 up to Bundle-Additional-Block-n where n=Bundle-
Additional-Block-Count must exist in the header. The value for a
Bundle-Additional-Block header is the name of the MIME Part
containing the data for that block.
4.1 Encoding of the Primary Bundle Block
Table 2 shows the header fields of the Primary Bundle Block that will
be put into the mail header. Except the fields marked as optional,
all fields are required in a valid MCL mail.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 8]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+--------------------------------------------+--------+----------+
| Header-Field | Type | Optional |
+============================================+========+==========+
| Bundle-Flags | INT | |
+--------------------------------------------+--------+----------+
| Bundle-Destination | EID | |
+--------------------------------------------+--------+----------+
| Bundle-Source | EID | |
+--------------------------------------------+--------+----------+
| Bundle-Report-To | EID | |
+--------------------------------------------+--------+----------+
| Bundle-Custodian | EID | |
+--------------------------------------------+--------+----------+
| Bundle-Creation-Time | SDNV | |
+--------------------------------------------+--------+----------+
| Bundle-Sequence-Number | SDNV | |
+--------------------------------------------+--------+----------+
| Bundle-Lifetime | INT | |
+--------------------------------------------+--------+----------+
| Bundle-Fragment-Offset | SDNV | x |
+--------------------------------------------+--------+----------+
Table 2: MCL header fields from the Primary Bundle Block
Bundle-Flags:
Processing flags for the Primary Bundle Block. This is a SDNV in
[RFC5050], which is limited to 19 bits. The MCL encodes a INT
representation of this value
4.2 Encoding the Bundle Payload Block
Encoding the Bundle Payload Block is similar to encoding the Primary
Bundle Block. Table 3 list the header fields related to the Bundle
Payload Block. The actual payload data will be attached as MIME
part.
4.2.1 The Payload Block
B. Gernert, S. Schildt Expires September 12, 2013 [Page 9]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+---------------------------------------+--------+----------+
| Header-Fields | Value | Optional |
+=======================================+========+==========+
| Bundle-Payload-Flags | INT | |
+---------------------------------------+--------+----------+
| Bundle-Payload-Block-Length | SDNV | x |
+---------------------------------------+--------+----------+
| Bundle-Payload-Data-Name | STRING | |
+---------------------------------------+--------+----------+
Table 3: Header fields from the Payload Block
Bundle-Flags:
Processing flags for the Payload Block. This is a SDNV in
[RFC5050], which is limited to 19 bits in [RFC5050]. The MCL
encodes a INT representation of this value.
Bundle-Payload-Block-Length:
Length of the payload data in bytes.
Bundle-Payload-Data-Name:
Name of the MIME part which contains the payload data. Similar to
Bundle-Additional-Block-n fields.
4.3 Encoding Extension Blocks
Other Bundle Blocks (Extension Blocks, Status Reports, Custody
Signals) must be attached as MIME parts. The headers for Extension
Blocks are listed in table 4. These headers must be encoded in the
headers of the MIME part and not in the general mail header.
Every extension block MUST be referenced in the mail header using the
Bundle-Additional-Block-n and Bundle-Additional-Block-count fields.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 10]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+---------------------------------------+---------+----------+
| Header-Fields | Value | Optional |
+=======================================+=========+==========+
| Block-Type | STRING | |
+---------------------------------------+---------+----------+
| Block-Processing-Flags | INT | |
+---------------------------------------+---------+----------+
| Block-EID-Count | INT | x |
+---------------------------------------+---------+----------+
| Block-EID-1 | EID | x |
+---------------------------------------+---------+----------+
| Block-EID-... | EID | x |
+---------------------------------------+---------+----------+
| Block-EID-n | EID | x |
+---------------------------------------+---------+----------+
Table 4: MIME-part header fields for Extension Blocks
Block-Type:
Bundle Block type code as specified in [RFC5050].
Block-Processing-Flags:
Processing flags for the Payload Block. This is a SDNV in
[RFC5050], which is limited to 19 bits. The MCL encodes a INT
representation of this value.
Block-EID-Count:
The number of Block-EID-n fields. If this header is missing, it
implies that there are no Block-EID-n fields.
Block-EID-n:
If the Block-EID-Count is not zero, the headers Block-EID-1 up to
Block-EID-n where n=Block-EID-Count must exist in the header. If
the block references EID from the Primary Bundle Block Dictionary,
the EIDs will be directly encoded to Block-EID fields.
4.4 Encoding a Status Report Block
The encoding of a Status Report Block is similar to the general
encoding of Extension Blocks with some additional fields shown in
table 5.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 11]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+---------------------------------------+---------+----------+
| Header-Fields | Value | Optional |
+=======================================+=========+==========+
| Block-Type | STRING | |
+---------------------------------------+---------+----------+
| Block-Processing-Flags | INT | |
+---------------------------------------+---------+----------+
| Block-EID-Count | INT | x |
+---------------------------------------+---------+----------+
| Block-EID-1 | EID | x |
+---------------------------------------+---------+----------+
| Block-EID-... | EID | x |
+---------------------------------------+---------+----------+
| Block-EID-n | EID | x |
+---------------------------------------+---------+----------+
| Status-Flags | INT | |
+---------------------------------------+---------+----------+
| Status-Reason-Code | INT | |
+---------------------------------------+---------+----------+
| Status-Fragment-Offset | SDNV | x |
+---------------------------------------+---------+----------+
| Status-Fragment-Length | SDNV | x |
+---------------------------------------+---------+----------+
| Status-Receipt-Time | DTNTIME | x |
+---------------------------------------+---------+----------+
| Status-Acceptance-Time | DTNTIME | x |
+---------------------------------------+---------+----------+
| Status-Forwarding-Time | DTNTIME | x |
+---------------------------------------+---------+----------+
| Status-Delivery-Time | DTNTIME | x |
+---------------------------------------+---------+----------+
| Status-Deletion-Time | DTNTIME | x |
+---------------------------------------+---------+----------+
| Status-Creation-Time | DTNTIME | x |
+---------------------------------------+---------+----------+
| Status-Sequence-Number-Time | DTNTIME | |
+---------------------------------------+---------+----------+
| Status-Source-EID | EID | |
+---------------------------------------+---------+----------+
Table 5: MIME-part header fields for Status Report Blocks
4.5 Encoding a Custody Signal Block
The encoding of a Custody Signal Block is similar to the general
encoding of Extension Blocks with some additional fields shown in
table 6.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 12]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
+---------------------------------------+---------+----------+
| Header-Fields | Value | Optional |
+=======================================+=========+==========+
| Block-Type | STRING | |
+---------------------------------------+---------+----------+
| Block-Processing-Flags | INT | |
+---------------------------------------+---------+----------+
| Block-EID-Count | INT | x |
+---------------------------------------+---------+----------+
| Block-EID-1 | EID | x |
+---------------------------------------+---------+----------+
| Block-EID-... | EID | x |
+---------------------------------------+---------+----------+
| Block-EID-n | EID | x |
+---------------------------------------+---------+----------+
| Custody-Reason-Code | SDNV | |
+---------------------------------------+---------+----------+
| Custody-Fragment-Offset | SDNV | x |
+---------------------------------------+---------+----------+
| Custody-Fragment-Length | SDNV | x |
+---------------------------------------+---------+----------+
| Custody-Signal-Time | DTNTIME | |
+---------------------------------------+---------+----------+
| Custody-Creation-Time | DTNTIME | |
+---------------------------------------+---------+----------+
| Custody-Creation-Sequence-Number | SDNV | |
+---------------------------------------+---------+----------+
| Custody-Source-EID | EID | |
+---------------------------------------+---------+----------+
Table 6: MIME-part header fields for Custody Signal Blocks
5. Example
The following example shows a correctly encoded mail with just a
payload block. This bundle comes from "dtn://second/eid" with the
mail address "sender@server" and was delivered to "dtn://some/eid"
with the mail address "recv@server". The payload can be found in the
attachment named "payload.data".
B. Gernert, S. Schildt Expires September 12, 2013 [Page 13]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
Return-path: <sender@server>
Envelope-to: recv@server
Delivery-date: Wed, 23 Jan 2013 19:44:25 +0100
From: sender@server
To: recv@server
Subject: Bundle for dtn://some/eid
Bundle-EMailCL-Version: 1
Bundle-Flags: 144
Bundle-Destination: dtn://some/eid
Bundle-Source: dtn://second/eid
Bundle-Report-To: dtn:none
Bundle-Custodian: dtn:none
Bundle-Creation-Time: 412281870
Bundle-Sequence-Number: 1
Bundle-Lifetime: 3600
Bundle-Fragment-Offset: 0
Bundle-Total-Application-Data-Unit-Length: 0
Bundle-Payload-Flags: 8
Bundle-Payload-Block-Length: 35
Bundle-Payload-Data-Name: payload.data
Content-Type: multipart/mixed;
boundary="=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6"
Bundle-Additional-Block-Count: 0
This is a multi-part message in MIME format. Your mail reader does
not understand MIME message format.
--=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6
--=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=payload.data
VGVzdA==
--=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6--
7. IANA Considerations
This document has no actions for IANA at the moment.
8. Security Considerations
To secure the transmission to and from an emailserver you can use
SMTP and IMAP over TLS [RFC3207] and [RFC2595]. However it is still
possible that an outstanding person sends manipulated mails to an
inbox of one node. Therefore additional tasks to secure the inbox of
a node may be required.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 14]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
9. References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration Procedures",
RFC 2048, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking
Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
B. Gernert, S. Schildt Expires September 12, 2013 [Page 15]
INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013
Authors' Addresses
Bjoern Gernert
Technische Uninversitaet Braunschweig
Institute of Operating Systems and Computer Networks
Muhlenpfordtstr. 23
38106 Braunschweig
Germany
Email: mail@bjoern-gernert.de
Sebastian Schildt
Technische Uninversitaet Braunschweig
Institute of Operating Systems and Computer Networks
Muhlenpfordtstr. 23
38106 Braunschweig
Germany
Phone +49 531 391 3285
Email: schildt@ibr.cs.tu-bs.de
B. Gernert, S. Schildt Expires September 12, 2013 [Page 16]