MANET H. Rogge
Internet-Draft Fraunhofer FKIE
Intended status: Informational E. Baccelli
Expires: January 9, 2014 INRIA
July 8, 2013
Packet Sequence Number based directional ETT Metric for OLSRv2
draft-rogge-baccelli-olsrv2-ett-metric-02
Abstract
This document specifies an Estimated Travel Time (ETT) link metric
for usage in OLSRv2.
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 January 9, 2014.
Copyright 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.
Rogge & Baccelli Expires January 9, 2014 [Page 1]
Internet-Draft Directional ETT for OLSRv2 July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Directional Packet-Size Agnostic ETT . . . . . . . . . . . . . 5
5. Metric Functioning & Overview . . . . . . . . . . . . . . . . 6
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 7
8. Initial Values . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 8
9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 9
9.3. HELLO Message Processing . . . . . . . . . . . . . . . . . 10
10. HELLO Timeout . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Periodic Metric Update . . . . . . . . . . . . . . . . . . . . 10
12. Proposed Values for Parameters and Constants . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
16.1. Normative References . . . . . . . . . . . . . . . . . . . 13
16.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Rogge & Baccelli Expires January 9, 2014 [Page 2]
Internet-Draft Directional ETT for OLSRv2 July 2013
1. Introduction
The Funkfeuer [FUNKFEUER] and Freifunk networks [FREIFUNK] are OLSR-
based [RFC3626] wireless community networks with hundreds of routers
in permanent operation. The Vienna Funkfeuer network in Austria, for
instance, consists of 400 routers (around 600 routes) covering the
whole city of Vienna and beyond, spanning roughly 40km in diameter.
It has been in operation since 2003 and supplies its users with
Internet access. A particularity of the Vienna Funkfeuer network is
that it manages to provide Internet access through a city wide, large
scale Wi-Fi mesh cloud, with just a single Internet uplink.
Operational experience with these networks have revealed that the use
of hop-count as routing metric leads to unsatisfactory network
performance. Experiments with the ETX metric [MOBICOM03] were
therefore undertaken in parallel in the Berlin Freifunk network as
well as in the Vienna Funkfeuer network, and found satisfactory,
i.e., sufficiently easy to implement and providing sufficiently good
performance. This metric has now been in operational use in these
networks for many years.
The ETX metric of a link is the estimated number of transmissions
required to successfully send a packet (each packet equal to or
smaller than MTU) over that link, until a link-layer acknowledgement
is received. The ETX metric is additive, i.e., the ETX metric of a
path is the sum of the ETX metrics for each link on this path.
While the ETX metric delivers a reasonable performance, it doesn't
handle networks with heterogeneous links that have different bitrates
well. Since every wireless link, when using ETX metric, is
characterized only by its packet loss ratio, the ETX metric prefers
long-ranged links with low bitrate (with low loss ratios) over short-
ranged links with high bitrate (with higher but reasonable loss
ratios). Such conditions, when they occur, can degrade the
performance of a network considerably by not taking advantage of
higher capacity links.
Based on the ETX metric this document describes an Estimated Travel
Time (ETT) metric [MOBICOM04] for the Optimized Link State Routing
Protocol Version 2. This ETT metric also takes the bitrate into
account. More precisely, this document specifies the processing for
NHDP [RFC6130] in order to establish the ETT metric value for a link.
2. Terminology
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT','SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY',
Rogge & Baccelli Expires January 9, 2014 [Page 3]
Internet-Draft Directional ETT for OLSRv2 July 2013
and 'OPTIONAL' in this document are to be interpreted as described in
[RFC2119].
The terminology introduced in [RFC5444], [OLSRV2] and [RFC6130],
including the terms "packet", "message" and "TLV" are to be
interpreted as described therein.
Additionally, this document uses the following terminology and
notational conventions:
QUEUE - a first in, first out queue of integers.
QUEUE[TAIL] - the most recent element in the queue.
add(QUEUE, value) - adds a new element to the TAIL of the queue.
remove(QUEUE) - removes the HEAD element of the queue
sum(QUEUE) - an operation which returns the sum of all elements in a
QUEUE.
diff_seqno(new, old) - an operation which returns the positive
distance between two elements of the circular sequence number
space defined in section 5.1 of [RFC5444]. Its value is either
(new - old) if this result is positive, or else its value is (new
- old + 65536).
MAX(a,b) - the maximum of a and b.
UNDEFINED - a constant for -1.
airtime - the time a transmitted packet blocks a shared medium,
e.g., a wireless link.
ETX - Expected Transmission Count, a link metric proportional to the
number of transmissions to sucessfully send an IP packet over a
link.
ETT - Estimated Travel Time, a link metric proportional to the
amount of airtime needed to transmit an IP packet over a link, not
considering layer-2 overhead created by preamble, backoff time and
queuing.
3. Applicability Statement
The mechanism specified in this document is based on the ETX metric
used daily by hundreds of routers in the Funkfeuer network
Rogge & Baccelli Expires January 9, 2014 [Page 4]
Internet-Draft Directional ETT for OLSRv2 July 2013
[FUNKFEUER], as well as in similar OLSR-based wireless community
networks which use the OLSR.org [OLSR.org] code base, such as
[FREIFUNK], [AWMN], [NINUX], [GUIFI] and [OPENAIR]. Operational
experience suggests that this mechanism is viable in (at least) these
kinds of networks.
The ETT metric, used in the OLSR.org implementation of [OLSRV2], is a
refinement of the ETX metric that was used in the earlier [RFC3626]
implementation. It provides a directional metric that takes packet
loss and bitrate of the link into account to compute the link cost.
The ETX metric value of a link is established by measuring the rate
of successful exchange of OLSRv2 control packets over that link,
which uses the format defined in [RFC5444]. ETX metric computation
is thus based only on layer 3 signaling, and is therefore independent
from underlying link layer technologies. Moreover, ETX metric
computation does not require inspection of data traffic.
The bitrate of the incoming link traffic MUST be known by a router,
performing the ETT calculation defined in this specification; either
through direct measurement or indirectly delivered by an external
source as operation system API, external processes or a configuration
file.
Both ETX and ETT metric have been designed for networks with link-
layer acknowledgement and retransmission mechanisms for user traffic.
4. Directional Packet-Size Agnostic ETT
The metric specified in this document is based on the Estimated
Travel Time (ETT) metric published in [MOBICOM04].
[MOBICOM04] describes the metric as 'ETX divided by bitrate', but
also introduce a 'packet size' variable in the formula
representation, describing the metric as 'ETX times packet-size
divided by bitrate'.
This document specifies the use of a variant of the ETT metric
without any packet-size integrated into the link costs. There are
multiple reasons for this design choice:
o The original ETT metric was designed for a DSR derived source-
routed protocol. Typical link-state protocols like OSLRv2 do not
process each data-plane packet on its own, which makes it
difficult to integrate the size of the data-plane packets into the
routing metric.
Rogge & Baccelli Expires January 9, 2014 [Page 5]
Internet-Draft Directional ETT for OLSRv2 July 2013
o The original ETT metric assumes that the airtime spent on a link
is proportional to the size of the packet transmitted over the
link.
o Multiplying all topology edge costs 'ETX divided by bitrate' with
the size of a packet would not change the result of the shortest
path calculation, independently of the packet size. This means
both description of ETT should result in the same next-hop
decision.
In addition to this, the metric described in this document is
directional, it does calculate the ETX value only based on the packet
loss at the receiver.
5. Metric Functioning & Overview
Router A computes the ETX value of a link between an interface of
router A and an interface of router B by continuously estimating the
loss rates for incoming traffic over this link.
To measure the loss rate of a link, this metric stores the packet
sequence number of the last incoming [RFC5444] packet of this link.
If one or more consecutive numbers are missing between a received
packet and the last one, the metric considers this packets to be
lost.
The incoming link bitrate is defined external to this specification,
either by measurement or through an administrative process. The
bitrate should reflect the datarate of the unicast traffic traveling
over this link.
The ETT metric is calculated as the ETX metric, divided by the
normalized bitrate of the incoming traffic from the neighbor. This
value is then used as L_in_metric of the Link Set (as defined in
section 8.1. of [OLSRV2]).
6. Protocol Parameters
This specification defines the following parameters:
ETT_MEMORY_LENGTH - ETT algorithm queue length. All received and
lost packets within the queue are used to calculate the ETT cost
of the link.
Rogge & Baccelli Expires January 9, 2014 [Page 6]
Internet-Draft Directional ETT for OLSRv2 July 2013
ETT_REFRESH_INTERVAL - interval in seconds between two metric
recalculations as described in Section 11.
ETT_SEQNO_RESTART_DETECTION - threshold in number of missing packets
(based on received packet sequence numbers) at which point the
router considers the neighbor has restarted.
ETT_HELLO_TIMEOUT_FACTOR - timeout factor for HELLO interval at
which point a HELLO is definitely considered lost. The value must
be a floating point number larger than 1.0.
ETT_WORST_ETX - Maximum ETX value used in this routing metric.
ETT_BEST_BITRATE - Maximum bitrate in bits/s of used in routing
metric.
ETT_WORST_BITRATE - Minimum bitrate in bits/s used in this metric.
ETT_WORST_NO_LOSS_METRIC_VALUE - metric value for ETX 1.0 and
ETT_WORST_BITRATE bitrate.
7. Data Structures
This specification extends the Link Set Tuples of the Interface
Information Base, as defined in [RFC6130] section 7.1, with the
following additional elements for each link tuple:
L_ETT_received is a QUEUE with ETT_MEMORY_LENGTH integer elements.
Each entry contains the number of successfully received [RFC5444]
packets within an interval of ETT_REFRESH_INTERVAL.
L_ETT_total is a QUEUE with ETT_MEMORY_LENGTH integer elements.
Each entry contains the estimated number of [RFC5444] packets
transmitted by the neighbor, based on the received packet sequence
numbers within an interval of ETT_REFRESH_INTERVAL.
L_ETT_last_pkt_seqno is the last received packet sequence number
received from this link.
L_ETT_hello_time is the time when the next hello will be expected.
L_ETT_hello_interval is the interval between two hello messages of
the links neighbor as signaled by the INTERVAL_TIME TLV [RFC5497]
of NHDP messages [RFC6130].
Rogge & Baccelli Expires January 9, 2014 [Page 7]
Internet-Draft Directional ETT for OLSRv2 July 2013
L_ETT_lost_hello_messages is the estimated number of lost hello
messages from this neighbor, based on the value of the hello
interval.
L_ETT_rx_bitrate is the current bitrate of incoming unicast traffic
for this neighbor.
Methods to obtain the value of L_ETT_rx_bitrate are out of scope for
this specification. Such methods may be static configuration via a
configuration file, or dynamic measurement through mechanisms
described in a separate specification. Any Link tuple with L_status
= HEARD or L_status = SYMMETRIC MUST have a specified value of
L_ETT_rx_bitrate if it is to be used by this routing metric.
8. Initial Values
When generating a new tuple in the Link Set, as defined in [RFC6130]
section 12.5 bullet 3, the values of the elements specified in
Section 7 are set as follows:
o L_ETT_received := 0, ..., 0. The queue always have
ETT_MEMORY_LENGTH elements.
o L_ETT_total := 0, ..., 0. The queue always have ETT_MEMORY_LENGTH
elements.
o L_ETT_last_pkt_seqno := UNDEFINED.
o L_ETT_hello_time := EXPIRED.
o L_ETT_hello_interval := UNDEFINED.
o L_ETT_lost_hello_messages := 0
9. Packets and Messages
Generated packets and messages use the format defined in [RFC5444].
This ETT metric does neither create RFC5444 messages on its own, nor
does it define new TLV types for existing message types.
An implementation of OLSRv2, using the metric specified by this
document, MUST include the following parts into its [RFC5444] output:
o an interface specific packet sequence number as defined in
[RFC5444] section 5.1 which is incremented by 1 for each outgoing
[RFC5444] packet on the interface.
Rogge & Baccelli Expires January 9, 2014 [Page 8]
Internet-Draft Directional ETT for OLSRv2 July 2013
o an INTERVAL_TIME message TLV in each Hello message, as defined in
[RFC6130] section 4.3.2.
9.1. Definitions
For the purpose of this section, note the following definitions:
o "pkt_seqno" is defined as the [RFC5444] packet sequence number of
the received packet.
o "interval_time" is the time encoded in the INTERVAL_TIME message
TLV of a received [RFC6130] HELLO message.
9.2. Packet Processing
For each incoming [RFC5444] packet, additional processing MUST be
carried out after the packets messages have been processed as
specified in [RFC6130] and [OLSRV2].
[RFC5444] packets without packet sequence number MUST NOT be
processed by this metric.
The router MUST update the Link Set Tuple corresponding to the
originator of the packet:
1. If L_ETT_last_pkt_seqno = UNDEFINED, then:
1. L_ETT_received[TAIL] := 1.
2. L_ETT_total[TAIL] := 1.
2. Otherwise:
1. L_ETT_received[TAIL] := L_ETT_received[TAIL] + 1.
2. diff := seq_diff(pkt_seqno, L_ETT_last_pkt_seqno).
3. If diff > ETT_SEQNO_RESTART_DETECTION, then:
1. diff := 1.
4. L_ETT_total[TAIL] := L_ETT_total[TAIL] + diff.
3. L_ETT_last_pkt_seqno := pkt_seqno.
4. If L_ETT_hello_interval != UNDEFINED, then:
Rogge & Baccelli Expires January 9, 2014 [Page 9]
Internet-Draft Directional ETT for OLSRv2 July 2013
1. L_ETT_hello_time := current time + (L_ETT_hello_interval *
ETT_HELLO_TIMEOUT_FACTOR).
5. L_ETT_lost_hello_messages := 0.
9.3. HELLO Message Processing
For each incoming HELLO Message, after it has been processed as
defined in [RFC6130] section 12, the Link Set Tuple corresponding to
the incoming HELLO message must be updated.
Only HELLO Messages with an INTERVAL_TIME message TLVs must be
processed.
1. L_ETT_hello_interval := interval_time.
10. HELLO Timeout
When L_ETT_hello_time has timed out, the following step MUST be done:
1. L_ETT_lost_hello_messages := L_ETT_lost_hello_messages + 1.
2. L_ETT_hello_time := L_ETT_hello_time + L_ETT_hello_interval.
11. Periodic Metric Update
This metric stores the number of received packets per link from a
neighbor and use the packet sequence number to calculate the total
number of sent packets from the neighbor. The total number of
packets divided by the number of received packets is used as an ETX
value for the link.
If connectivity of link with a node is lost, no packets are received
anymore and neither the received nor total value of packets will
change. To prevent a constant result in this case, the metric stores
the number of HELLO message interval timeouts since the last received
packet from a neighbor and uses this value to reduce the received
packet count proportionally to the length of the metric memory
ETT_MEMORY_LENGTH.
Once every ETT_REFRESH_INTERVAL, this protocol MUST recalculate all
L_in_metric values in all Link Set entries:
1. sum_received := sum(L_ETT_total).
Rogge & Baccelli Expires January 9, 2014 [Page 10]
Internet-Draft Directional ETT for OLSRv2 July 2013
2. sum_total := sum(L_ETT_received).
3. If L_ETT_hello_interval != UNDEFINED and L_ETT_lost_hellos > 0,
then:
1. penalty := L_ETT_hello_interval * L_ETT_lost_hellos /
ETT_MEMORY_LENGTH.
2. sum_received := sum_received * MAX ( 0, 1 - penalty );
4. If sum_received < 1, then:
1. L_ETT_r_etx := UNDEFINED.
2. L_in_metric := MAXIMUM_METRIC, as defined in [OLSRV2] section
5.6.1.
5. Otherwise:
1. etx := sum_total / sum_received.
2. If etx > ETT_WORST_ETX, then:
1. etx := ETT_WORST_ETX.
3. bitrate := L_ETT_rx_bitrate.
4. If bitrate > ETT_BEST_BITRATE, then:
1. bitrate := ETT_BEST_BITRATE.
5. If bitrate < ETT_WORST_BITRATE, then:
1. bitrate := ETT_WORST_BITRATE.
6. L_in_metric := ETT_WORST_NO_LOSS_METRIC_VALUE * etx /
(bitrate / ETT_WORST_BITRATE).
6. remove(L_ETT_total)
7. add(L_ETT_total, 0)
8. remove(L_ETT_received)
9. add(L_ETT_received, 0)
Rogge & Baccelli Expires January 9, 2014 [Page 11]
Internet-Draft Directional ETT for OLSRv2 July 2013
12. Proposed Values for Parameters and Constants
This section proposes values for various parameters used in this
specification.
o ETT_MEMORY_LENGTH := 64
o ETT_REFRESH_INTERVAL := 1 second
o ETT_SEQNO_RESTART_DETECTION := 256
o ETT_HELLO_TIMEOUT_FACTOR := 1.5
o ETT_WORST_ETX := 16
o ETT_BEST_BITRATE := 256 MBit/s
o ETT_WORST_BITRATE := 1 MBit/s
o ETT_WORST_NO_LOSS_METRIC_VALUE := 4096
With this values this ETT metric will go from 16 (256+ MBit/s, ETX
1.0) over 4096 (1 MBit/s, ETX 1.0) to a maximum of 65536 (1 MBit/s,
ETX 16.0).
The settings were chosen based on the deployment of the original ETX
metric in the Funkfeuer community mesh network. They allow the
existence of both priority links (links faster than any ETT link) and
backup links (links slower than any ETT link) and should deliver a
reasonable performance for non-moving mesh networks.
For mobile mesh deployments the administrator should decrease both
the memory length and refresh interval to allow a faster metric
change.
13. IANA Considerations
This document contains no actions for IANA.
14. Security Considerations
Artificial manipulation of metrics values can drastically alter
network performance. In particular, advertising a higher L_in_metric
value may decrease the amount of incoming traffic, while advertising
lower L_in_metric may increase the amount of incoming traffic. By
artificially increasing or decreasing the L_in_metric values it
Rogge & Baccelli Expires January 9, 2014 [Page 12]
Internet-Draft Directional ETT for OLSRv2 July 2013
advertises, a rogue router may thus attract or repulse data traffic.
A rogue router may then potentially degrade data throughput by not
forwarding data as it should or redirecting traffic into routing
loops or bad links.
An attacker might also inject packets with incorrect packet-level
sequence numbers, pretending to be somebody else. This attack could
be prevented by the true originator of the RFC5444 packets by adding
a [RFC6622] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.
This allows the receiver to drop all incoming packets which have a
forged packet source, both packets generated by the attacker or
replayed earlier packets by the original sender.
15. Acknowledgements
The authors would like to acknowledge the network administrators from
Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for
endless hours of testing and suggestions to improve the quality of
the original ETX metric for the olsr.org routing daemon.
This effort/activity is supported by the European Community Framework
Programme 7 within the Future Internet Research and Experimentation
Initiative (FIRE), Community Networks Testbed for the Future Internet
([CONFINE]), contract FP7-288535.
The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): Teco Boot
(Infinity Networks), Thomas Clausen, Christopher Dearlove (BAE
Systems Advanced Technology Centre), Ulrich Herberg (Fujitsu
Laboratories of America), Markus Kittenberger (Funkfeuer Vienna) and
Joseph Macker (Naval Research Laboratory).
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", RFC 3626, October 2003.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009.
Rogge & Baccelli Expires January 9, 2014 [Page 13]
Internet-Draft Directional ETT for OLSRv2 July 2013
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011.
[RFC6622] Ulrich, U. and T. Clausen, "Integrity Check Value and
Timestamp TLV Definitions for Mobile Ad Hoc Networks
(MANETs)", RFC 6622, May 2012.
16.2. Informative References
[CONFINE] "Community Networks Testbed for the Future Internet
(CONFINE)", 2013, <http://www.confine-project.eu>.
[OLSRV2] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized
Link State Routing Protocol version 2",
draft-ietf-manet-olsrv2-19 , March 2013.
[MOBICOM03]
De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A
High-Throughput Path Metric for Multi-Hop Wireless
Routing", Proceedings of the MOBICOM Conference , 2003.
[MOBICOM04]
Richard, D., Jitendra, P., and Z. Brian, "Routing in
Multi-Radio, Multi-Hop Wireless Mesh Networks",
Proceedings of the MOBICOM Conference , 2004.
[OLSR.org]
"The olsr.org OLSR routing daemon", 2013,
<http://www.olsr.org/>.
[FREIFUNK]
"Freifunk Wireless Community Networks", 2013,
<http://www.freifunk.net>.
[FUNKFEUER]
"Austria Wireless Community Network", 2013,
<http://www.funkfeuer.at>.
[AWMN] "Athens Wireless Community Network", 2013,
<http://awmn.net>.
[GUIFI] "Barcelona Wireless Community Network", 2013,
<http://www.guifi.net>.
Rogge & Baccelli Expires January 9, 2014 [Page 14]
Internet-Draft Directional ETT for OLSRv2 July 2013
[NINUX] "Roma Wireless Community Network", 2013,
<http://www.ninux.org>.
[OPENAIR] "Boston Wireless Community Network", 2013,
<http://openairboston.net>.
Authors' Addresses
Henning Rogge
Fraunhofer FKIE
Email: henning.rogge@fkie.fraunhofer.de
URI: http://www.fkie.fraunhofer.de
Emmanuel Baccelli
INRIA
Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Rogge & Baccelli Expires January 9, 2014 [Page 15]