Rui Lopes Campos Joint Path and Address Auto- on guration : an Approa h to Multi-te hnology Personal Area Networks and 802.11-based Stub Wireless Mesh Networks Dissertação apresentada à Fa uldade de Engenharia da Universidade do Porto para obtenção do grau de Doutor em Engenharia Ele troté ni a e de Computadores, realizada sob a orientação do Prof. Doutor Manuel Alberto Pereira Ri ardo, Professor Asso iado da Fa uldade de Engenharia da Universidade do Porto
Departamento de Engenharia Ele troté ni a e de Computadores Fa uldade de Engenharia da Universidade do Porto 2010
To Manuela and my parents
A knowledgements First of all, I would like to thank my supervisor, Prof. Manuel Ri ardo. Right from the start he was always available to help, dis uss, and give suggestions on the resear h work presented herein.
His help was espe ially
important in the early days, when I was a young, inexperien ed resear her. He helped me to de ne the resear h problem and gave me fruitful insights on the state of the art whi h made my resear h task easier. Along the PhD, he was always an outstanding mentor. His tireless support, the valuable advi es and reviews, and his enthusiasm, made me feel on dent that I would make it, despite the multiple problems always popping up.
Also, his emphasis
on publi ations right from the beginning was very important.
On the one
hand, it ontributed to improve my CV and make the PhD thesis writing pro ess easier. On the other hand, it ontributed to improve the quality of my resear h work, namely due to the feedba k re eived from the anonymous reviewers of the published papers. I would like to express my thanks to Ri ardo Duarte and Filipe Sousa for their ontribution in the design, implementation, and evaluation of the WiFIX solution, and for the pro ient and intensive dis ussions. Also, many thanks to Daniel Sousa, João Maia, and Sérgio Lopes, that ontributed with their programming skills to implement the ideas I have developed along this PhD. I would also like to thank Prof.
José Ruela for his institutional and
personal support. As the dire tor of the Tele ommuni ations and Multimedia Unit (UTM) at INESC Porto, he always guaranteed that the required material and work onditions were available to develop my resear h work. Personally, as a resear her, he also ontributed to the su
ess of this work by means of dis ussions, suggestions, and paper reviews. I am grateful to Fundação para a Ciên ia e a Te nologia (FCT) for its support under the s holarship SFRH/BD/19429/2004. Without it this PhD
would not be possible. I would like to thank namely the nan ial support to present three papers at international onferen es I attended during the
ourse of this PhD. I also thank to all my olleagues at UTM who have ontributed for a good work environment and have provided valuable omments on the work presented herein. Thanks to Carlos Pinho, Filipe Abrantes, Gustavo Carneiro, Jaime Cardoso, Jaime Dias, Pedro Fortuna, Ri ardo Morla, and Tânia Calçada, for their help, feedba k, and onstru tive omments. A spe ial thanks goes to Jaime Dias for helping me with the translation of the abstra t to Fren h. I would like to thank my parents for their support. They always tried to make me feel on dent and en ouraged me to never give up. Furthermore, they made me see that work is not everything in life and that we must keep some balan e between work and the other sides of life. Many thanks to my girlfriend, Manuela, for always omforting and supporting me with her love, namely in the bad moments.
She was ru ial
to keep me emotionally balan ed throughout this journey and to make me feel on dent, mainly in those moments when things were not going well. Without her beside me it would be a very mu h harder path. Finally, I would like to thank God for always showing me the path forward, even when no way out seemed to exist.
Abstra t The Internet an be a
essed using multiple devi es. Besides, users now own multiple devi es with a number of network interfa es, supporting dierent ommuni ation te hnologies, whi h enable the reation of Personal Area Networks (PANs).
Complementary, IEEE 802.11 is be oming a universal
te hnology for Internet a
ess; from laptops to MP3 players, all are equipped with 802.11 radios, whi h in reases the demand for 802.11 networks.
Due
to the 802.11 limited radio range, solutions to extend the overage of 802.11 infrastru tures have been sought.
Wireless Mesh Networks (WMNs) are
onsidered a exible and ost-ee tive solution. Network auto- on guration is important for the su
ess of PANs and 802.11-based WMNs. In PANs, the devi es shall self-organize to form the PAN and enable its onne tion to the Internet with minimal user on guration. In WMNs, nodes shall also self-organize to form the WMN and enable data ex hange between the wired infrastru ture and the terminals atta hed to the WMN. The Internet Proto ol (IP) a ts as the enabler to inter onne t these networks to the Internet and as the ommon ground for intra-network
onne tivity. Path and IP address on guration are required for this purpose. State of the Art (SoA) solutions address path and IP address on guration problems separately, introdu e omplexity, are ine ient, and most of them are not ba kwards ompatible. In this thesis we propose a simple, exible, and ba kwards ompatible network auto- on guration framework, the Simple and Flexible Auto on guration (SFA), that jointly addresses path and IP address on guration. Two instan es of SFA are de ned targeting multi-te hnology PANs and 802.11-based WMNs, ASPAN and WiFIX, respe tively. By means of theoreti al, simulation, and experimental analysis we demonstrate the ASPAN and WiFIX feasibility, higher e ien y, and good performan e. IP address
on guration overhead is redu ed up to 90%, path on guration delay in PANs is redu ed by one order of magnitude and PAN setup time an be 10% of the setup time in urred by SoA solutions, and path on guration overhead in WMNs is redu ed up to 70% with respe t to the referen e SoA solution, IEEE 802.11s.
Resumo A Internet pode ser a edida usando múltiplos dispositivos. Além disso, os utilizadores possuem hoje múltiplos dispositivos om múltiplas interfa es de
omuni ação, que permitem a riação de redes pessoais (PANs). Por outro lado, a te nologia IEEE 802.11 tornou-se na te nologia sem os universal para o a esso à Internet.
Desde omputadores portáteis até leitores MP3,
todos estão equipados om interfa es 802.11, aumentando a ne essidade de redes 802.11. Devido ao al an e rádio limitado da te nologia 802.11, têm sido investigadas soluções para estender a sua obertura.
As redes emalhadas
(WMNs) 802.11 são onsideradas uma solução exível e e onomi amente e iente. A auto- on guração é importante para o su esso das PANs e WMNs. Nas primeiras, os dispositivos devem auto organizar-se para formar a rede e permitir a ligação à Internet om intervenção mínima do utilizador. Nas WMNs, os nós devem auto organizar-se para riar a rede emalhada e possibilitar a
omuni ação entre a infra-estrutura e os terminais ligados à rede emalhada. O proto olo IP (
Internet Proto ol )
permite a interligação destas redes à In-
ternet e serve de base à omuni ação intra-rede.
Para isso é ne essária a
auto- on guração quer de rotas quer de endereços IP. As soluções do estado da arte lidam om estes problemas separadamente, introduzem ex essiva
omplexidade, são ine ientes e a maioria não é retro- ompatível. Nesta tese propomos um modelo simples, exível e retro- ompatível para a auto- on guração de redes, designado
tion (SFA),
Simple and Flexible Auto- on gura-
que aborda o problema da auto- on guração de rotas e de en-
dereços IP onjuntamente.
Duas instân ias do modelo são de nidas para
a auto- on guração de PANs multi-te nologia e WMNs 802.11, designadas ASPAN and WiFIX, respe tivamente.
Com base em análise teóri a e ex-
perimental e simulação demonstramos a viabilidade, e iên ia e bom desempenho das soluções propostas. O
overhead
de on guração de endereços IP
é reduzido em 90%, o atraso na on guração de rotas numa PAN é reduzido uma ordem de grandeza, o tempo de riação de uma PAN diminui até 10% do tempo envolvido nas soluções de estado da arte e o
overhead
de on g-
uração de rotas numa WMN é reduzido até 70% relativamente à solução de estado da arte de referên ia IEEE 802.11s.
Résumé L'Internet peut être onsulté en utilisant plusieurs appareils. En outre, a tuellement les utilisateurs possède plusieurs dispositifs ave de multiples interfa es de ommuni ation, qui permettent la réation de réseaux personnels (PAN). D'autre part, 802.11 est devenue une te hnologie universel pour a
éder à Internet. Des ordinateurs portables aux le teurs MP3, tous deviennent équipés ave 802.11, e qui augmente la demande de 802.11 réseaux. En raison de la portée radio limitée de 802.11, des solutions permettant d'étendre la ouverture de 802.11 infrastru tures ont été re her hés. Les réseaux sans l maillés (WMNs) sont onsidérés une solution rentable pour ela. La auto- on guration est essentielle au su
ès des PANs et WMNs. Dans des PANs, les dispositifs doivent se auto-organiser pour former le réseau et permettre de onne ter à l'Internet ave un minimum d'eorts de on guration pour le utilisateur. Dans des WMNs, les noeuds doivent se auto-organiser pour former le WMN et pour permettre l'é hange de données entre le infrastru ture et les terminaux atta hés aux WMN. Le proto ole IP permit la inter onnexion de es réseaux à l'Internet et fournit la base de onne tivité intra-réseau. Cela né essite de la on guration automatique des routes et des adresses IP. Les solutions a tuel fa e les problèmes d'auto- on guration des routes et des adresses IP séparément, introduit une trop grande omplexité, sont ine a es, et la plupart d'entre eux ne sont pas rétro- ompatibles. Dans ette thèse nous proposons un simple, exible et rétro- ompatible modèle de on guration automatique
Simple and Flexible Auto- on gura-
tion (SFA), qui traite la on guration des routes et des adresses IP onjointement. Deux instan es du modèle sont dé nies pour traiter le problème de la auto- on guration des PANs et WMNs (ASPAN et WiFIX, respe tivement). Au moyen dune analyse théorique et expérimentale et de la simulation nous démontrons la faisabilité, bonne performan e et e a ité des solutions pro-
overhead
posées. L'
de on guration des addresses IP est réduite jusqu'à 90%,
le délai de on guration de route dans des PANs est réduite par un ordre de grandeur, le temps de réation d'un PAN peut être de 10% du temps
réation en ourus par les solutions a tuel et le
overhead
de on guration de
routes dans des WMNs est réduite jusqu'à 70% par rapport aux solution de référen e IEEE 802.11s.
Contents 1 Introdu tion
1
1.1
S ope
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Problem Statement . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Thesis Work . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Stru ture of the Thesis . . . . . . . . . . . . . . . . . . . . . .
10
2 PAN and LAN Wireless Communi ation Te hnologies
11
2.1
IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Bluetooth
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3
IEEE 802.15 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4
WiMedia Ultra Wide Band
. . . . . . . . . . . . . . . . . . .
26
2.5
Wireless USB . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.6
WirelessHD . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.7
Summary
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Graphs, Spanning Trees and Spanning Tree Algorithms
33
3.1
De nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2
Spanning Tree Types . . . . . . . . . . . . . . . . . . . . . . .
36
3.3
Shortest Paths Spanning Tree Algorithms
. . . . . . . . . . .
41
3.4
Minimum Spanning Tree Algorithms
. . . . . . . . . . . . . .
45
3.5
Minimum Routing Cost Spanning Tree Algorithms
3.6
Summary
. . . . . .
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4 Network Auto- on guration 4.1
Chara terization Approa h
4.2
Ethernet Networks
59 . . . . . . . . . . . . . . . . . . .
60
. . . . . . . . . . . . . . . . . . . . . . . .
60
4.3
IP Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.4
Underlay Networks . . . . . . . . . . . . . . . . . . . . . . . .
94
i
CONTENTS
ii
4.5
Personal Area Networks
. . . . . . . . . . . . . . . . . . . . .
4.6
Stub Wireless Mesh Networks . . . . . . . . . . . . . . . . . . 114
4.7
Summary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5 Simple and Flexible Auto- on guration Framework
127
5.1
Ar hite ture of the SFA Framework . . . . . . . . . . . . . . . 127
5.2
Solution for Personal Area Networks
5.3
Solution for Stub Wireless Mesh Networks . . . . . . . . . . . 157
5.4
Summary
. . . . . . . . . . . . . . 132
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6 Evaluation
173
6.1
Evaluation Methodology . . . . . . . . . . . . . . . . . . . . . 173
6.2
ASPAN Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 174
6.3
WiFIX Evaluation
6.4
Dis ussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
6.5
Summary
. . . . . . . . . . . . . . . . . . . . . . . . 207
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
7 Con lusion
A
99
239
7.1
Overview of the Work Developed
7.2
Original Contributions . . . . . . . . . . . . . . . . . . . . . . 240
7.3
Future Work
Campos's
. . . . . . . . . . . . . . . . 239
. . . . . . . . . . . . . . . . . . . . . . . . . . . 243
algorithm
247
A.1
Illustrative Example
A.2
Simulation Results for Slightly Heterogeneous Graphs
A.3
Dependen e of
A.4
Spanning Tree Computation using
spv
. . . . . . . . . . . . . . . . . . . . . . . 248
and
wdv
from the Coe ients
Campos's
. . . . 250
. . . . . . . 253
algorithm and
the IEEE algorithm . . . . . . . . . . . . . . . . . . . . . . . . 254
B WiFIX Proofs
259
B.1
Overhead Expression Demonstration
. . . . . . . . . . . . . . 259
B.2
Loop Free Topology Demonstration . . . . . . . . . . . . . . . 261
C PBC and SBC Evaluation: Further Details C.1
Messages Ex hanged and Normalized Overhead . . . . . . . . 263
D Pure Flooding Expression D.1
263 267
Expression Demonstration . . . . . . . . . . . . . . . . . . . . 267
CONTENTS
iii
E NS-2 Simulations: Further Results E.1
Route Request
269
Collisions . . . . . . . . . . . . . . . . . . . . . 269
List of Figures 1.1
New Personal Communi ation S enario.
. . . . . . . . . . . .
2
1.2
Stub Wireless Mesh Networking S enario.
. . . . . . . . . . .
3
2.1
Illustration of the IEEE 802.11 operation modes.
2.2
IEEE 802.11 MAC frame format with the number of bytes
. . . . . . .
per- eld on top. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3
14
15
Ethernet frame mapped into an IEEE 802.11 MAC frame (adho mode).
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4
Bluetooth network types.
. . . . . . . . . . . . . . . . . . . .
18
2.5
Bluetooth PAN pro le networking s enarios. . . . . . . . . . .
19
2.6
IEEE 802.15.3 pi onet formed by ve DEVs. . . . . . . . . . .
22
2.7
WiMedia radio platform and the multiple lient proto ol sta ks it an support by means of PALs. . . . . . . . . . . . . . . . .
Ge .
. . . . . . . . . . . .
3.1
Example weighted undire ted graph
3.2
The spanning tree
3.3
Set of possible spanning trees omputed from the graph
3.4
Computation of an SPST for
3.5
Computation of an SPST
Te
omputed from graph
Ge .
. . . . . . . .
Ge .
.
Ge using Dijkstra's algorithm. . for Ge using the Bellman-Ford al-
gorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ge using Prim's algorithm. . . . Ga and an approximate MRCST
3.6
Computation of an MST for
3.7
Unweighted example graph obtained using the
Add
algorithm.
Ga .
3.8
Spanning trees omputed from
3.9
Metri losure of the example graph
v
27 34 36 39 43
45 46
. . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . .
53
Ge .
55
. . . . . . . . . . . .
LIST OF FIGURES
4.1
vi
Illustration of the learning bridge me hanism, with the station STA1 transmitting a frame for the rst time and bridges BR1 , BR2 , and BR3 learning the path to STA1 automati ally.
4.2
. . .
62
Illustration of the RSTP operation in a bridged Ethernet network in luding four IEEE 802.1D bridges, with the tree a tive topology represented in bold.
4.3
. . . . . . . . . . . . . . . . . .
Illustration of the DSR Route Dis overy pro edure, with the route between Node 1 and Node 4 in bold. . . . . . . . . . . .
4.4
72
Illustration of the AODV-DR Route Dis overy pro edure and the established route (in bold).
4.5
65
. . . . . . . . . . . . . . . . .
77
Illustration of the MPR sele tion for two example input graphs, where the nodes sele ted as MPRs are depi ted in bold.
. . .
84
4.6
Current IPv4 auto- on guration me hanism. . . . . . . . . . .
89
4.7
Current IPv6 Link-lo al auto- on guration me hanism. . . . .
91
4.8
Current IPv6 Global auto- on guration me hanism.
92
4.9
Illustration of the address assignment used in IEEE 802.15.3
. . . . .
and IEEE 802.15.4 mesh WPANs and the orresponding tree topology established, with the address pool available at ea h node shown between square bra kets. . . . . . . . . . . . . . . 102 4.10 The Personal Hub Con ept.
. . . . . . . . . . . . . . . . . . . 106
4.11 Illustration of the joint use of the IEEE 802.11s tree-based proa tive and rea tive path dis overy solutions. . . . . . . . . 118 5.1
The Simple and Flexible Auto- on guration Framework Ar hite ture, where the dotted arrows mean optional intera tions.128
5.2
The two networking s enarios addressed by the SFA framework.129
5.3
The exe ution sequen e of the SFA me hanisms for a PAN and a Stub WMN, where the dashed arrow between ST and BC me hanisms means that BC runs only after ST has run. . 132
5.4
ASPAN the SFA instan e for PANs.
. . . . . . . . . . . . . 133
5.5
The ASPAN referen e s enario. . . . . . . . . . . . . . . . . . 134
5.6
Illustration of the ASPAN topology dis overy pro edure for a 5-node PAN and the ontrol tree onstru ted during the topology dis overy pro edure (in bold). . . . . . . . . . . . . . 137
LIST OF FIGURES
5.7
vii
Message sequen e hart illustrating the ASPAN a tive topology re on guration pro edure when a non-leaf node leaves the PAN (h-hop means trol tree and
H
h
hops away from the master in the on-
is the maximum number of hops between the
master and a slave in the ontrol tree). . . . . . . . . . . . . . 140 5.8
Illustration of the ASPAN topology re on guration pro edure when a non-leaf node leaves the 5-node PAN and the new a tive topology. . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5.9
Two example trees with the same set of edge weights but different topologies.
. . . . . . . . . . . . . . . . . . . . . . . . . 144
5.10 PAN BC me hanism pro edure during PAN bootstrapping.
. 151
5.11 PAN BC me hanism pro edure during PoA hange. . . . . . . 152 5.12 WiFIX the SFA instan e for Stub WMNs. . . . . . . . . . . 158 5.13 The WiFIX referen e s enario.
. . . . . . . . . . . . . . . . . 159
5.14 The 802.11 frame format (in ad-ho mode). 5.15 The Eo11 frame format.
. . . . . . . . . . 160
. . . . . . . . . . . . . . . . . . . . . 160
5.16 The ATCM me hanism for a 4-node Stub WMN. (a) Startup; (b) Node 2 and Node 3 sele t Node 1 as parent; ( ) Eo11 tunnels (Node 1
↔ Node 2 and Node 1 ↔ Node 3) established;
(d) Node 4 sele ts Node 2 as parent; (e) Eo11 tunnel (Node 2
↔
Node 4) established. . . . . . . . . . . . . . . . . . . . . . . 164
5.17 Illustration of the WiFIX path re on guration pro edure.
. . 166
5.18 The Learning Bridge running in ea h MAP whose ports are the Eo11 tunnel endpoints.
. . . . . . . . . . . . . . . . . . . 168
5.19 Illustration of the Stub WMN BC me hanism. . . . . . . . . . 170 6.1
Routing osts for ea h spanning tree algorithm under analysis when
homogeneous
onsidered. 6.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Routing osts for ea h spanning tree algorithm under analysis when
highly heterogeneous
are onsidered. 6.3
input graphs of 10, 30, and 50 verti es are
input graphs of 10 and 50 verti es
. . . . . . . . . . . . . . . . . . . . . . . . . . 183
Exe ution time for ea h spanning tree algorithm under analysis onsidering input graphs of 10, 30, and 50 verti es. . . . . 185
LIST OF FIGURES
6.4
viii
Normalized ASPAN and AODV average TCP throughput for 10-node and 20-node PANs, when the average number of NICs per node and the number of pairs ommuni ating simultaneously is varied (n denotes the number of nodes forming the PAN and
np
denotes the number of pairs ommuni ating si-
multaneously). 6.5
. . . . . . . . . . . . . . . . . . . . . . . . . . 190
Normalized ASPAN and AODV average one-way delay (OWD) for 10-node and 20-node PANs, when the average number of NICs per node and the number of pairs ommuni ating simultaneously is varied. . . . . . . . . . . . . . . . . . . . . . . . . 192
6.6
ASPAN path establishment delay for 10-node and 20-node PANs normalized to AODV path establishment delay, when the average number of NICs per node is varied.
6.7
. . . . . . . . 192
Path on guration load for 10-node and 20-node PANs, when the average number of NICs per node and the number of pairs
ommuni ating simultaneously is varied (n denotes the number of nodes forming the PAN and
np
pairs ommuni ating simultaneously). 6.8
denotes the number of . . . . . . . . . . . . . 194
Number of pa kets transmitted by ASPAN per broad ast pa ket normalized to the number of pa kets transmitted when pure ooding is used. . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.9
ASPAN IP on guration overhead normalized to the overhead of the state of the art approa h (trial-and-error me hanism plus pure ooding), taking into a
ount the number of bytes and the number of frames ex hanged. . . . . . . . . . . . . . . 198
6.10 Intera tion between ASPAN and its related Linux modules.
. 201
6.11 S enarios used in the ASPAN experimental evaluation. . . . . 203 6.12 Overhead of WiFIX normalized to the PREQ me hanism.
. . 213
6.13 Overhead of WiFIX normalized to the RANN me hanism. . . 214 6.14 Number of pa kets transmitted by WiFIX per broad ast pa ket normalized to the number of pa kets transmitted when using pure ooding. . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 6.15 Example of a WiFIX node failure ae ting a node with a
andidate parent node unae ted by the failure; Node 4, the node ae ted by the failure of Node 2, has a andidate parent unae ted by the node failure (Node 3).
. . . . . . . . . . . . 217
LIST OF FIGURES
ix
6.16 Re on guration timeline for the WiFIX nodes that have andidate parent nodes unae ted by the node failure, where a
ross means that the orresponding message is not re eived.
. 218
6.17 Example of a WiFIX re on guration when there is a node ae ted by the node failure without any unae ted andidate parent node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 6.18 Cumulative distribution fun tion for the ina tivity intervals asso iated to an STA (WiFIX). . . . . . . . . . . . . . . . . . 220 6.19 WiFIX IP on guration overhead normalized to the overhead of the state of the art approa h (trial-and-error me hanism plus pure ooding). . . . . . . . . . . . . . . . . . . . . . . . . 221 6.20 Intera tion between WiFIX and its peer Linux modules.
. . . 223
6.21 Setup of the testbed used in the WiFIX evaluation. . . . . . . 226 6.22 WiFIX and 802.11s average throughput versus oered load
onsidering UDP tra .
. . . . . . . . . . . . . . . . . . . . . 228
6.23 Average pa ket loss ratio for WiFIX and 802.11s.
. . . . . . . 229
6.24 Average UDP throughput per MAP when the oered load is 480 kbit/s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 6.25 One-way delay for WiFIX and 802.11s. . . . . . . . . . . . . . 231 A.1
Example graph and the orresponding approximate MRCST
omputed using
A.2
Campos's
algorithm (in bold).
. . . . . . . . 248
Routing osts for ea h spanning tree algorithm under analysis when
slightly heterogeneous
input graphs of 10, 30, and 50
verti es are onsidered. . . . . . . . . . . . . . . . . . . . . . . 251 A.3
Spanning tree obtained using the standard IEEE algorithm for the example graph of Fig. A.1, when vertex 5 is sele ted as the root.
A.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Normalized routing ost for dierent values of the oe ients
C1 , C2 , C3 , C4 , and C5 , obtained for n = 10 (left hand side) and n = 30 (right hand side), when S = {1, 2, 3} . . . . . . . . A.5
Normalized routing ost for dierent values of the oe ients
C1 , C2 , C3 , C4 , and C5 , obtained for n = 10 (left hand side) and n = 30 (right hand side), when S = {1, 10, 100}. . . . . . A.6
256
257
Normalized routing ost for dierent values of the oe ients
C1 , C2 , C3 , C4 , and C5 , obtained for n = 10 (left hand side) and n = 30 (right hand side), when S = {1, 10, 100, 1000, 10000}.258
LIST OF FIGURES
B.1
x
Ring graph used as a basis to prove the loop free a tive topology reated by the ATCM me hanism. . . . . . . . . . . . . . 261
E.1
Number of
Route Request
ollisions for 10-node and 20-node
PANs, when the average number of NICs per node and the number of pairs ommuni ating simultaneously is varied. . . . 270
List of Tables 2.1
Summary of the main hara teristi s of the wireless te hnologies, with the optional features between parentheses.
. . . . .
32
. . . . . . . . . . . . . . . . . . .
37
3.1
Summary of the de nitions.
3.2
Set of paths (and orresponding osts) between vertex 2 and its peer verti es in
3.3
Ge .
. . . . . . . . . . . . . . . . . . . . . .
Total ost and routing ost for ea h possible spanning tree
omputed from the input graph
3.4
Iterations of
Dijkstra's
rooted at vertex 2 for 3.5
Iterations of the
Iterations of
3.7
Iterations
Ge .
Ge .
. . . . . . . . . . . . . . . . . . . .
Bellman-Ford
4.1
41
42
algorithm when omputing an
Ge .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 47
49
Routing ost for ea h spanning tree omputed (a) from the
Ga . . . . . . . . . . . . for Ga and the routing
50
ost of the SPST sele ted as the MRCST (in bold). . . . . . .
54
unweighted version of 3.9
. . . . . . . . . . . . . .
Prim's algorithm when omputing an MST for Ge . of Kruskal's algorithm when omputing an MST
3.6
for
Ge . .
algorithm when omputing an SPST
SPST rooted at vertex 2 for
3.8
38
Ge
and (b) from
Routing ost for ea h SPST omputed
Summary of the main hara teristi s of the state of the art network auto- on guration solutions. . . . . . . . . . . . . . . 124
5.1
Length of the elds of the messages used in the topology dis overy and a tive on guration pro edures.
5.2
. . . . . . . . . . 139
Length of the elds of the messages used in the PBC and PGC me hanisms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
xi
LIST OF TABLES
5.3
xii
Length of the elds of the me hanism.
5.4
TR
message used in the ATCM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Notations used in the formal des ription of the ATCM me hanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.1
Summary of the input parameters onsidered in our NS-2 simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.2
PAN setup time for dierent on gurations in S enario 1.
. . 205
6.3
Average TCP throughput for the three possible intra-PAN ows in S enario 2. . . . . . . . . . . . . . . . . . . . . . . . . 206
6.4
PAN PoA re on guration time in S enario 4.
6.5
Parameters used in the WiFIX overhead analysis. . . . . . . . 208
6.6
Average number of hops between master MAP and MAPs. . . 210
6.7
Probability of lifetime expiration of the forwarding table entries.212
6.8
Average TCP throughput for WiFIX and 802.11s. . . . . . . . 231
A.1
Values of the parameters
dv , sv , and mv
. . . . . . . . . 206
and the orresponding
spanning potential (spv ) for ea h vertex
v.
. . . . . . . . . . . 247
L.
A.2
Tables representing the dierent instan es of
C.1
Messages ex hanged by ea h me hanism when DHCPv4 is a -
. . . . . . . . 249
tually used and the orresponding PBC/SBC normalized overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 C.2
Messages ex hanged by ea h me hanism when DHCPv6 is a tually used and the orresponding PBC/SBC normalized overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
C.3
Messages ex hanged by ea h me hanism when IPv6 SLAC is a tually used and the orresponding PBC/SBC normalized overhead.
C.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Messages ex hanged by ea h me hanism when DynLL is a tually used and the orresponding PBC normalized overhead.
C.5
265
Messages ex hanged by ea h me hanism when IPv6 LL is a tually used and the orresponding PBC normalized overhead.
265
A ronyms ABNF ACK
Augmented Ba kus-Naur Form
A knowledgment
AHCP ALM
Airtime Link Metri
ALSR AN
Ad-Ho Con guration Proto ol
AWDS Link State Routing
Ambient Network
AODV
Ad-ho On-demand Distan e Ve tor
AODV-DR AP
AODV Data Rate
A
ess Point
API
Appli ation Programming Interfa e
ARP
Address Resolution Proto ol
ASPAN
Auto- on guration and Self-management of Personal Area Networks
ATCM
A tive Topology Creation and Maintenan e
AWDS
Ad-ho Wireless Distribution Servi e
BC
Basi Conne tivity
BGL
Boost Graph Library
BGP
Border Gateway Proto ol
BNEP BP
Bluetooth Network En apsulation Proto ol
Ba ko Period
BPDU BSID BSS
Bridge Proto ol Data Unit
Bea on Sour e Identi er
Basi Servi e Set
BSSID
BSS Identi er
CAP
Contention A
ess Period
CFP
Contention Free Period
CSMA/CA
Carrier Sense Multiple A
ess with Collision Avoidan e
CSMA/CD CSS
Carrier Sense Multiple A
ess with Collision Dete tion
Chirp Spread Spe trum
CTA
Channel Time Allo ation
CTB
Channel Time Blo k
DAD
Dupli ate Address Dete tion
DEV
IEEE 802.15.3 Devi e
DIFS
Distributed Inter Frame Spa e
DHCP DNS
Dynami Host Con guration Proto ol
Domain Name System
DSAP
Destination Servi e A
ess Point
DSDV
Destination-Sequen ed Distan e Ve tor
DSR
Dynami Sour e Routing
DVNI
Distributed Virtual Network Interfa es
D-WVAN
Drone Wireless Video Area Network
DYMO
Dynami MANET On-demand
DynLL
Dynami Con guration of IPv4 Link-Lo al Addresses
ECMA
European Computer Manufa turers Asso iation
EIFS
Extended Inter Frame Spa e
Eo11
Ethernet-over-802.11
ESS
Extended Servi e Set
ESSID
Extended Servi e Set Identi er
FCSL
Frame Convergen e Sublayer
FEUP
Fa uldade de Engenharia da Universidade do Porto
FFD
Full Fun tion Devi e
FQDN
Fully Quali ed Domain Name
GC
Gateway Con guration
GN
Gateway Node
GPRS GSM
Global System for Mobile Communi ation
GTS HD
General Pa ket Radio Servi e
Guaranteed Time Slot High De nition
HNA
Host and Network Asso iation
HRP
High Rate Physi al Layer
HWMP IBSS IC
Independent Basi Servi e Set
IP Auto- on guration
ICON ID
Hybrid Wireless Mesh Proto ol
Integrated Convergen e
Identi er
IDR
Internet DYMO Router
IEEE
Institute of Ele tri al and Ele troni s Engineers
IETF
Internet Engineering Task For e
IMS
IP Multimedia Subsystem
INESC Porto IP
Instituto de Engenharia de Sistemas e Computadores do Porto
Internet Proto ol
ISO
International Organization for Standardization
LAN
Lo al Area Network
LLC
Logi al Link Control
LLMNR
Link Lo al Multi ast Name Resolution
LPNC
LR-WPAN Coordinator
LQSR
Link Quality Sour e Routing
LRP
Low Rate Physi al Layer
LR-WPAN LUNAR MAC
Low Rate WPAN
Lightweight Underlay Network Ad-ho Routing
Medium A
ess Control
MAGNET MANET
My Personal Adaptive Global Net
Mobile Ad-ho NETwork
MAP
Mesh A
ess Point
MAS
Medium A
ess Slot
MC
Mesh Coordinator
MCL
Mesh Conne tivity Layer
mDNS
Multi ast Domain Name System
MIPS
Mi ropro essor without Interlo ked Pipeline Stages
MLD
Multi ast Listener Dis overy
MP
Mesh Point
MPLS
Multi-Proto ol Label Swit hing
MPNC
Mesh Pi onet Coordinator
MPP
Mesh Point Portal
MPR
Multi-Point Relay
MRCST
Minimum Routing Cost Spanning Tree
MS
Master of S ien e
MST
Minimum Spanning Tree
MSTP MTU NA
Multiple Spanning Tree Proto ol Maximum Transfer Unit
Neighbor Advertisement
NAP
Network A
ess Point
NAT
Network Address Translation
NDP
Neighbor Dis overy Proto ol
NGN
Next Generation Network
NHDP
NeighborHood Dis overy Proto ol
NIC
Network Interfa e Card
NID
Node Identi ation
NS
Neighbor Soli itation
NS-2
Network Simulator 2
OLSR OS
Optimized Link State Routing
Operating System
OSPF OUI
Open Shortest Path First
Organizationally Unique Identi er
OWD PaC
One-way Delay
Path Con guration
PACWOMAN
Power Aware Communi ation for Wireless Optimized PANs
PAL
Proto ol Adaptation Layer
PAN
Personal Area Network
PANU PBC
PAN User
PAN Basi Conne tivity
PC
Personal Computer
PD
Pre x Delegation
PDA
Personal Digital Assistant
PGC
PAN Gateway Con guration
PGW
PAN Gateway
PhD
Do tor of Philosophy
PHY
Physi al
PMH
Personal Mobile Hub
PNC
Pi onet Coordinator
PNID
Pi onet Identi er
PNRP PoA
Personal Network Routing Proto ol
Point of Atta hment
PREP
Path Reply
PREQ
Path Request
PSK
Pre-Shared Key
PSMA/CA PXE
Preamble-sense Multiple A
ess with Collision Avoidan e
Preboot Exe ution Environment
QoS
Quality of Servi e
RA
Router Advertisement
RANN RFD
Root Announ ement
Redu ed Fun tion Devi e
RIP
Routing Information Proto ol
RSTP
Rapid Spanning Tree Proto ol
SBC
Stub WMN Basi Conne tivity
SFA
Simple and Flexible Auto- on guration
SIFS SIG
Short Inter Frame Spa e Spe ial Interest Group
SLAC SMC
StateLess Address Auto-Con guration Self-Managed Cell
SNAP
Subnetwork A
ess Proto ol
SPST
Shortest Path Spanning Tree
SSAP
Sour e Servi e A
ess Point
SSID ST
Servi e Set Identi er
Spanning Tree
STA
Station
STP
Spanning Tree Proto ol
STS
Spanning Tree Simulator
TC
Topology Change / Topology Control
TCP
Transmission Control Proto ol
TDD
Time Division Duplex
TDMA
Time Division Multiple A
ess
TG
Task Group
TR
Topology Refresh
TRILL
Transparent Inter onne tion of Lots of Links
TTL
Time-To-Live
UDP
User Datagram Proto ol
UMTS
Universal Mobile Tele ommuni ations System
USB
Universal Serial Bus
UWB
Ultra Wide Band
VLAN
Virtual Lo al Area Network
VLR
Virtual Link Routing
VoIP
Voi e over IP
WDS
Wireless Distribution System
WG
Work Group
Wi-Fi
Wireless Fidelity
WiFIX
Wi-Fi network Infrastru ture eXtension
WiNet
WiMedia Network
WLAN
Wireless LAN
WLP
Wireless Link Layer Control Proto ol
WMN
Wireless Mesh Network
WPA
Wireless Prote ted A
ess
WPAN WSS
Wireless PAN
WiMedia Servi e Set
WUSB
Wireless USB
WU-WPAN WVAN
WiMedia UWB WPAN
Wireless Video Area Network
Chapter 1
Introdu tion 1.1 S ope The Internet plays today a entral role in the global ommuni ation paradigm, supporting multimedia data and servi es, from the lassi al su h as web browsing and e-mail, to more QoS demanding servi es su h as Voi eover-IP (VoIP) and video- onferen ing. The Internet is the global ommuni ation platform to whi h an in reasing number of users is onne ted to. The type of devi es apable of onne ting to the Internet has hanged during the last de ade.
In the past, a
ess to it was ex lusive to personal omputers
at xed lo ations su h as o e, home, or Internet afés; urrently, Internet
an be a
essed by using portable and mobile devi es.
The ost-ee tive
a
ess to su h devi es is leading to a hange in the personal ommuni ation paradigm.
There is an ongoing migration to a s enario where users own
several personal devi es mobile phone, laptop, tablet PC, digital amera, MP3 players with (1) a number of network interfa es supporting dierent ommuni ation te hnologies, e.g., IEEE 802.11, Bluetooth [SIG10℄, and UMTS [3GP℄, (2) in reasing omputation and storage apabilities, and (3) support of networking fun tionalities whi h were only present in dedi ated network devi es in the past.
In addition, thanks to their high storage a-
pa ity, huge amounts of data, su h as videos, text messages, and audio les,
an be stored in personal devi es.
The a
ess to all this data, regardless
of the devi e used, demands easy data transfer among personal devi es; for instan e, users may want to easily a
ess the musi s stored within the MP3 player from the laptop or they may want to upload some photos to the home data enter. The reation of multi-te hnology, IP-based PANs is envisioned
1
CHAPTER 1.
INTRODUCTION
2
PAN PAN videos
photos
UWB
videos
audio files
Bluetooth
UWB Wi-Fi
audio files docs Wi-Fi
docs
Ethernet
UWB
Internet UMTS
PAN videos audio files Bluetooth USB
videos audio files docs
Figure 1.1: New Personal Communi ation S enario.
as the enabler to make this happen and bring into the PAN domain the ap-
+
+
pli ations and servi es running over the Internet [MAC 04℄ [J 08℄. Fig. 1.1 illustrates the envisioned personal ommuni ation s enario. On the other hand, with the rapid growth of the Internet as well as the demand for broadband servi es, a
ess networks have been re eiving intense investments in re ent years. In this ontext, the IEEE 802.11 standard [Gro07℄, also known as Wi-Fi (the two terms will be used inter hangeably in this thesis), is assuming a prominent role. Wi-Fi infrastru tures are being widely deployed around the world in university ampus, orporations, in entire ities, or even in trains and planes, as a means to provide wireless and broadband a
ess to the Internet; this is mainly due to the integration of Wi-Fi in portable devi es, from laptops to MP3 players, whi h in turn leads to an in reasing demand of IEEE 802.11 networks. limited radio range.
Still, Wi-Fi has
The overage of large geographi al areas an only be
a hieved by installing multiple Wi-Fi A
ess Points (APs) that need to be dire tly onne ted to the wired ba khaul Ethernet infrastru ture. In some
CHAPTER 1.
INTRODUCTION
3
wired terminal
Internet IP Gateway
wired infrastructure
MAP MAP MAP MAP MAP MAP
Figure 1.2: Stub Wireless Mesh Networking S enario.
ases, this may require the installation of a large number of APs and wires, whi h introdu es omplexity, may imply high nan ial osts, and may involve onsiderable te hni al manpower to deploy the network. Also, the need to onne t ea h AP to the wired infrastru ture limits exibility.
Thereby,
new solutions to extend the overage of Wi-Fi infrastru tures have been sought.
IEEE 802.11 Wireless Mesh Networks (WMNs) are onsidered a
ost-ee tive and exible solution.
In WMNs, nodes ooperate with ea h
other so that data an be wirelessly forwarded between sour es and destinations. WMNs may be de ned in dierent ways. In this thesis, an 802.11 WMN is assumed to be a wireless network used to extend the overage of a wired infrastru ture. Throughout the thesis we all this WMN a Stub WMN. A Stub WMN onsists of stati Mesh A
ess Points (MAPs) that perform multi-hop bidire tional forwarding between the wired infrastru ture and the wireless terminals atta hing to MAPs. The latter are assumed to have two Network Interfa e Cards (NICs), one used for onne ting to the WMN and the other used to serve the wireless terminals. The referen e s enario for an 802.11 Stub WMN is illustrated in Fig. 1.2. Network auto- on guration is a ru ial on ept for the su
ess of multite hnology PANs and 802.11 Stub WMNs.
In PANs, the devi es around
the user shall self-organize to form the network and enable its onne tion to the Internet with minimal user on guration eorts. In Stub WMNs, wire-
CHAPTER 1.
INTRODUCTION
4
less a
ess points shall also self-organize to automati ally form the network and enable data ex hange between the wired infrastru ture and the wireless terminals atta hed to the Stub WMN. The Internet Proto ol (IP) is a base proto ol in this ontext. It a ts as the enabler to inter onne t these networks to the Internet and/or as the ommon ground for intra-network onne tivity. Thereby, in this thesis network auto- on guration means both path and IP address auto- on guration. Existing solutions ope with path and IP address auto- on guration separately and assume a single IP version paradigm.
In addition, they are
omplex, ine ient, and most of them are not ba kwards ompatible. Our resear h hypothesis is that it is possible to de ne simple, e ient, and ba kwards ompatible joint path and IP address auto- on guration solutions for multi-te hnology PANs and 802.11-based Stub WMNs.
1.2 Problem Statement The main problem addressed in this thesis is the auto- on guration of multi-te hnology PANs and 802.11-based Stub WMNs; hen eforth, the a ronym PANs and the term Stub WMNs stand for multi-te hnology PANs and 802.11-based Stub WMNs, respe tively. Network auto- on guration an be des ribed as a twofold problem: (1) the automati on guration of network paths and (2) the on guration of IP addresses, so that network onne tivity is established and the IP-based servi es and appli ations running on top of it are enabled. Fig. 1.1 illustrates a set of multi-te hnology PANs. In this s enario, the wireless and wired te hnologies enabling single-hop ommuni ations between PAN devi es are not enough to reate multi-te hnology PANs; su h te hnologies alone simply enable a set of ommuni ation islands, where only devi es supporting the orresponding wired/wireless te hnology an ommuni ate. On the other hand, the Internet a
ess te hnologies supported by the devi es forming a PAN work in isolation and are unaware of ea h other. Also, the dynami s asso iated to a PAN, due to the user movement, may trigger membership hanges and indu e (1) hanges in the underlying topology and (2) hanges in the Point of Atta hment (PoA) to the Internet.
Thus, the
following spe i network auto- on guration problems arise:
•
the on guration of any-to-any network paths within the PAN;
CHAPTER 1.
•
INTRODUCTION
5
the on guration of IP addresses at ea h PAN devi e for enabling intraPAN and global IP onne tivity;
•
the on guration of the best PAN PoA based on some metri (e.g., pri e, bandwidth);
•
the on guration of the PAN IP gateway (i.e., the devi e providing the PoA to the Internet);
•
the on guration of the PAN IP gateway address and optional information, su h as the DNS server IP address, at ea h PAN devi e;
•
the re on guration of all required items when topology hanges o
ur.
In Fig. 1.2 we have illustrated the referen e s enario for a Stub WMN. While in PANs multiple in ompatible ommuni ation te hnologies need to be inter onne ted somehow, in Stub WMNs a single ommuni ation te hnology is used to extend the overage of the wired infrastru ture based on multi-hop wireless ommuni ations. However, the fundamental network auto- on guration problem is the same: the inter onne tion of a set of ommuni ation islands, whose boundaries are in this ase established by radio range, in order to reate network paths between the wireless terminals atta hing to the Stub WMN and the wired infrastru ture. formed by stati MAPs.
Stub WMNs are
Topology hanges may o
ur due to hanges in
the Stub WMN membership or due to the wireless terminals moving within its radio overage. The ultimate purpose of a Stub WMN is to extend Internet a
ess to wireless terminals.
Then, the following spe i network
auto- on guration problems arise:
•
the on guration of many-to-one network paths within the Stub WMN;
•
the on guration of IP addresses, default IP gateway, and optional information, su h as the DNS server IP address, at the wireless terminals;
•
the re on guration of the network paths when topology hanges o
ur.
Regarding IP address auto- on guration, the oexisten e of two IP versions (IPv4 and IPv6) brings up a further problem. The ommon thinking that the transition to IPv6 would be based on the dual-sta k model, where
CHAPTER 1.
INTRODUCTION
6
most devi es (terminals, routers, servers) would be ome dual-sta k, before
+
running out of IPv4 addresses, was not on rmed [DDH 10℄. The fast ap-
+
proa hing exhaustion of IPv4 addresses [DDH 10℄ will lead to the in reasing deployment of IPv6-only networks. Also, IPv6 has not been the subje t of widespread adoption so far; IPv4-only networks are still dominant. Thereby, IPv4-only and IPv6-only networks are envisioned to oexist for a long time. This leads and will lead to ine ient IP networking when dual-sta k IP devi es are onsidered.
1
Within a PAN, a set of dual-sta k devi es
will run
two IP versions in parallel for intra-PAN and global onne tivity, when only a single IP version will ultimately be used. Similarly, the dual-sta k wireless terminals atta hing to a Stub WMN, used to extend an IPv4-only or IPv6only wired network, will unne essarily run two IP versions for obtaining global onne tivity. So, the additional problem to solve is the on guration of the IP-related items mentioned for PANs and Stub WMNs a
ording to the networking ontext. The dieren es between PANs and Stub WMNs have mainly to do with the roles played by the network members and the tra patterns involved. In PANs, ea h node is simultaneously an internetworking node and a terminal, and tra may be ex hanged between peers within the PAN or between PAN devi es and the Internet. In Stub WMNs, MAPs a t only as internetworking nodes, terminals are simply terminals, and tra is mostly ex hanged between terminals and the Internet. However, both network types have the same fundamental auto- on guration problems: path auto- on guration and IP address on guration for IP onne tivity establishment.
The approa h
followed in this thesis is then to onsider a ommon framework to solve these auto- on guration problems, with the ultimate purpose of enabling plug and play operation for PANs and Stub WMNs.
1.3 Thesis Work 1.3.1 Motivation The motivation for this PhD thesis omes rst and foremost from the ongoing migration to a new personal ommuni ation paradigm, the prominent role of 802.11-based Stub WMNs as a means for extending IEEE 802.11 1
Mainstream operating systems, su h as Windows Mobile, Windows XP/Vista/7, Linux, Android, and Symbian, support both IPv4 and IPv6.
CHAPTER 1.
INTRODUCTION
7
overage to an in reasing number of 802.11-enabled terminals, and the relevan e of the Internet as a means to have a
ess to valuable servi es and appli ations. Se ondly, the need for network auto- on guration solutions that enable the plug and play deployment of PANs and Stub WMNs. Thirdly, the personal ommuni ation
status quo,
where ooperation among personal de-
vi es is almost absent, and the limited radio range and the limited exibility of urrent Wi-Fi networks, due to the need to onne t Wi-Fi APs dire tly to the ba khaul wired infrastru ture.
Fourthly, the all-Ethernet paradigm
established within the ontext of PANs and WMNs, whi h allows importing the Ethernet LANs' networking prin iples into these networks. Fifthly, the
oexisten e of two IP versions and the ine ien y and omplexity problems it brings up. Finally, the la k of simple, ba kwards ompatible, and e ient network auto- on guration solutions targeting PANs and Stub WMNs and addressing the network auto- on guration problems holisti ally.
1.3.2 Obje tives This PhD thesis has the goal of designing a simple, ba kwards ompatible, and e ient network auto- on guration solution addressing multite hnology PANs and 802.11-based Stub WMNs. The network auto- on guration solution to be designed has three major obje tives:
•
to support lega y network devi es;
•
to minimize the required hanges to network devi es;
•
to support the lega y IP-based appli ations and servi es running in
urrent LANs and single-te hnology PANs.
1.3.3 Overview of the Proposed Solution We propose the Simple and Flexible Auto- on guration (SFA) framework, whi h addresses the establishment of paths and the IP on gurations required to establish the network onne tivity enabling IP-based appli ations and servi es; from the SFA framework we derive two instan es, one developed for PANs and the other for Stub WMNs. SFA assumes that one-hop onne tivity is pre-established and extends onne tivity beyond the single-hop domain. SFA onsists of two major modules: the Path Con guration (PaC) module and the IP Con guration (IC) module. The PaC module addresses
CHAPTER 1.
INTRODUCTION
8
the on guration of multi-hop onne tivity by means of the establishment of network paths. The IC module deals with the establishment of IP onne tivity by on guring the needed IP parameters at ea h network devi e, taking into a
ount the heterogeneities envisioned for IP networks, where two IP versions and the orresponding IP auto- on guration me hanisms oexist. The PaC and IC modules do not ne essarily run within the same node. It depends on the s enario addressed. In the PAN s enario, where ea h devi e may simultaneously be a terminal and a relay node, the two modules run in the same node. In Stub WMNs, the MAPs forming the mesh network run the PaC module and the terminals atta hing to the Stub WMN run the IC module. SFA obeys to a fundamental prin iple: the easy migration from lega y networks.
Two basi requirements drove its design: 1) whenever possible
use lega y me hanisms; 2) avoid modi ations to the data plane. For this reason, learning bridges and lega y IP auto- on guration me hanisms are the pillars of the proposed framework. The PaC module is based on learning bridges [Ba 98℄ and on a solution for on guring the a tive spanning tree required for their proper operation; the spanning tree on guration solution may vary with the s enario wherein the SFA framework is employed. After a single a tive spanning tree is on gured, learning bridges are able to learn automati ally the path towards any network devi e belonging to the network; due to the use of a single a tive spanning tree, broad ast tra is handled in an optimal and e ient way.
The use of learning bridges enables the
transparent operation of lega y IP-based appli ations and servi es over PANs and Stub WMNs, as desired. The IC module sele ts the proper lo al auto on guration me hanism, su h as DHCP [Dro97℄ or IPv6 Stateless Address Auto- on guration [TN07℄, and relies on it for establishing IP onne tivity. In PANs, IC is also in harge of performing the on gurations required to (re) on gure the PAN gateway a
ording to the networking ontext. Although the PaC and IC modules are proposed as part of the SFA framework, they an run as stand-alone modules. The PaC module may be used to auto- on gure multi-hop paths, but IP onne tivity may be left to a lega y me hanism, su h as DHCP or the urrent trial-and-error me hanism used by dual-sta k IP devi es. On the other hand, the IC module may be used alone on top of a single-hop network or in onjun tion with another
ompatible path on guration solution.
CHAPTER 1.
INTRODUCTION
9
1.3.4 Original Contributions The ontributions provided by this PhD thesis are the following:
A Network Auto- on guration Framework for Multi-te hnology PANs and 802.11-based Stub WMNs. We propose the SFA framework to auto- on gure multi-te hnology PANs and 802.11-based Stub WMNs. The novelty of the framework omes from the reuse of lega y te hnology, namely Learning Bridges and lega y IP auto- on guration me hanisms, as a basis for a simple and ba kwards ompatible joint path and IP address network auto- on guration solution. This is in ontrast to state of the art solutions whi h de ne new solutions from the s rat h, introdu e unne essary
omplexity, and make migration from lega y systems hard or even impossible.
An Algorithm for Computing Minimum Routing Cost Spanning Trees. Con erning the on guration of the a tive spanning tree in PANs, we propose a new spanning tree algorithm
Campos's
algorithm.
Cam-
pos's algorithm omputes an approximate Minimum Routing Cost Spanning
Tree (MRCST). By ombining dierent approa hes followed by state of the art algorithms, su h as
Prim's
[Pri57℄,
Add
[Gro05b℄, and
Dijkstra's
[Dij59℄
algorithms, it represents the urrent fastest known approximation MRCST algorithm, providing results similar to the fastest approximation MRCST algorithm known,
Wong's
[Won80℄ algorithm.
This ontribution has been
published in [CR08℄.
An IP Auto- on guration Me hanism for Dual-sta k Nodes.
As
part of the SFA framework we propose an IP auto- on guration me hanism that enables the e ient oexisten e of two IP versions. The proposed me hanism sele ts the proper IP auto- on guration a
ording to the networking
ontext and enables the establishment of IP onne tivity in a more e ient and simpler way than using the state of the art trial-and-error me hanism employed by dual-sta k IP devi es; less number of signaling messages are involved and the address auto- on guration pro edure may be ompleted with shorter delays. This ontribution has been published in [CR09℄ and [CR10℄.
CHAPTER 1.
INTRODUCTION
10
A Network Auto- on guration Solution for Multi-te hnology PANs. The Auto- on guration and Self-management of Personal Area Networks (ASPAN) solution is proposed regarding the network auto- on guration of multi-te hnology PANs. ASPAN uses
Campos's
algorithm to ompute the
a tive PAN topology, de nes a new entralized spanning tree proto ol, onsiders the IP on guration me hanism referred above for e iently on guring IP onne tivity, and de nes a me hanism for sele ting the best PoA for a PAN. ASPAN represents a simple and ba kwards ompatible solution for multi-te hnology PANs, that is more e ient than state of the art solutions and exhibits the same or better performan e.
This ontribution has been
published in [CR05℄ and [CR06℄.
A Network Auto- on guration Solution for 802.11-based Stub WMNs. The Wi-Fi network Infrastru ture eXtension (WiFIX) solution is proposed to address 802.11-based Stub WMNs.
WiFIX uses a new dis-
tributed single-message signaling proto ol to reate the a tive spanning tree and onsiders the IP on guration me hanism referred above to e iently a
omplish the IP auto- on guration of the wireless terminals atta hing to the Stub WMN. WiFIX represents a simple and ba kwards ompatible solution for auto- on guring 802.11-based Stub WMNs that exhibits good performan e and is more e ient than the referen e state of the art solution,
+
IEEE 802.11s [Gro09a℄. This ontribution has been published in [CDS 09℄
+
and [CDS 11℄.
1.4 Stru ture of the Thesis This thesis is organized in seven hapters. Chapter 2 looks into the set of wireless te hnologies in the PAN and LAN s opes. Chapter 3 introdu es
on epts de ned in graph theory and presents the spanning tree algorithms employed in data networks to derive the a tive network topologies. Chapter 4 reviews the state of the art on network auto- on guration.
Chapter 5
presents our network auto- on guration solution and Chapter 6 opes with its evaluation. Finally, Chapter 7 draws the main on lusions, reviews the work developed and the original ontributions of the thesis, and dis usses the future work.
Chapter 2
PAN and LAN Wireless Communi ation Te hnologies Wireless ommuni ation an be de ned as the transfer of information over a distan e without using wires.
In PANs and LANs, this distan e is
usually onsidered to be limited to about ten meters and a few hundred meters, respe tively.
Wireless ommuni ation te hnologies provide exibility
and, usually, enable mobility. In PAN and LAN s opes, ommuni ations are in reasingly performed using wireless te hnologies, due to these advantages and the in reasing number of devi es supporting one or more wireless te hnologies. Devi es su h as smart phones, personal omputers, and portable gaming onsoles, ome with built-in wireless te hnologies. This hapter looks into the state of the art on wireless ommuni ation te hnologies in the PAN/LAN s ope. The prominent te hnologies are hara terized. Within the WLAN s ope, Wi-Fi is the WLAN te hnology des ribed.
de-fa to
standard and the
For wireless PAN (WPAN) te hnologies we
address Bluetooth, Bluetooth Low Energy, IEEE 802.15.3, IEEE 802.15.4, WiMedia UWB, Wireless USB, and WirelessHD. The hara terization of ea h wireless te hnology onsiders the following riteria: frequen y bands, data rates, medium a
ess method, and Ethernet emulation support.
2.1 IEEE 802.11 The IEEE 802.11 [Gro07℄ (Wi-Fi) te hnology is the standard solution for WLANs and devi es su h as laptops, smart phones, and digital ameras are
11
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
12
already IEEE 802.11-enabled. Wi-Fi networks are widely deployed around the world in university ampus, orporations, homes, as a means of providing wireless and broadband a
ess to the Internet. IEEE 802.11 uses the 2.4 GHz and 5 GHz unli ensed frequen y bands to transmit data; the frequen y band used depends on the IEEE 802.11 variant utilized. The rst version of the standard operated in the 2.4 GHz frequen y band and provided up to 2 Mbit/s of raw data rate.
With the advent of IEEE
802.11b [Gro07℄, IEEE 802.11a [Gro07℄, and IEEE 802.11g [Gro07℄ the raw data rates in reased signi antly. The IEEE 802.11b standard uses the 2.4 GHz band and an provide up to 11 Mbit/s. IEEE 802.11a uses the 5 GHz frequen y band and an provide up to 54 Mbit/s. IEEE 802.11g over ame the IEEE 802.11a overage problems, while providing the same data rates (up to 54 Mbit/s); IEEE 802.11g uses the 2.4 GHz band and is ba kwards
ompatible with IEEE 802.11b.
IEEE 802.11b and IEEE 802.11g are the
most used variants in Wi-Fi devi es today. More re ently, the IEEE 802.11n variant was rati ed [Gro09b℄. IEEE 802.11n provides data rates up to 600 Mbit/s and up to two times the radio range of IEEE 802.11a/b/g. Also, it is
ompatible with IEEE 802.11a/b/g and, as su h, works in both 2.4 GHz and 5 GHz frequen y bands.
Due to the wide deployment of IEEE 802.11b/g
devi es, the 2.4 GHz frequen y band is expe ted to dominate, so that IEEE 802.11n devi es and IEEE 802.11b/g devi es an interoperate. Re ently, two new IEEE 802.11 variants are being studied within the IEEE 802.11 working group, the IEEE 802.11a [a ℄ and the IEEE 802.11ad [ad℄. The former will operate in the 5 GHz band, while the latter will operate in the 60 GHz unli ensed frequen y band. They are expe ted to be released by the end of 2012 [Groa℄ and will further in rease raw data rates up to several Gbit/s, based on wider frequen y hannels. The IEEE 802.11 variants have dierent physi al (PHY) layer spe i ations, while the Medium A
ess Control (MAC) layer is ommon.
The
mandatory medium a
ess method is based on arrier sense multiple a
ess but, unlike Ethernet, it uses ollision avoidan e, given the impossibility to send and re eive simultaneously using a single radio.
The Carrier Sense
Multiple A
ess with Collision Avoidan e (CSMA/CA) used by IEEE 802.11 [Gro07℄ is de ned as follows.
A wireless station with a frame to transmit
he ks if the hannel is free, waits for DIFS (Distributed Inter Frame Spa e) interval, if the last frame dete ted on the medium was re eived orre tly, or
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
13
EIFS (Extended Inter Frame Spa e) interval, if the last frame dete ted on the medium was not re eived orre tly, and then it transmits the frame if the medium is still free. Upon su
essfully re eiving the frame, the destination station sends ba k an ACK frame after the SIFS (Short Inter Frame Spa e) interval. If the transmitting station senses the hannel busy, it waits until it be omes free.
After the DIFS interval, the station randomly hooses a
ba ko interval de ned by an integer
[0, CW ],
and ounts down for
b
b
belonging to a ontention window
SLOT intervals before attempting to trans-
mit. The initial value of the upper limit of the ontention window is equal to
CWmin
(for example,
for IEEE 802.11g).
CWmin = 31
for IEEE 802.l1b and
CWmin = 15
The SLOT interval is dierent for ea h IEEE 802.11
variant too (for IEEE 802.11b it is 20
µs
and for IEEE 802.11g it is 9
µs).
If another station transmits before the end of the ba ko interval, the ount down freezes and the remaining time is used in the next transmission attempt.
A station assumes that there was a ollision if it does not re eive
an ACK for a previously sent frame. In that ase, the exponential ba ko algorithm is employed; for ea h ollision in a row, the to the maximum value
CWmax . CW
returns to
CW
CWmin
is doubled up
after a su
essful
transmission. In spite of using the same MAC layer, the IEEE 802.11n variant introdu es e ien y improvements by onsidering frame aggregation and blo k a knowledgments. Frame aggregation improves the e ien y of transport, sin e the higher the frame size the higher the IEEE 802.11 transport e ien y; IEEE 802.11n in reases the maximum frame size from 2304 bytes to 8192 bytes.
The use of blo k a knowledgments allows sending a single
ACK frame to on rm the re eption of multiple frames and, onsequently, redu es overhead. The IEEE 802.11 standard de nes two operation modes, the infrastru turebased mode and the ad-ho mode, illustrated in Fig. 2.1. In the infrastru turebased mode there is a spe ial station, the A
ess Point (AP), that is in harge of managing the wireless network the Basi Servi e Set (BSS) formed by the AP and the stations (STAs) onne ted to it.
The AP sends periodi
bea ons that enable namely timing syn hronization within the BSS and advertisement/dis overy of the wireless network. A BSS is uniquely identi ed by a BSS Identi er (BSSID), whi h is equal to the MAC address of the AP belonging to it. An IEEE 802.11 network an be omposed of one or more BSSs, forming an Extended Servi e Set (ESS); a BSS is then the smallest
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
wired terminal
14
STA1
Internet
STA2 STA3
IP Gateway
IBSS1
wired infrastructure
STA5 STA4
AP STA1
BSS
STA6
STA2
(a) Infrastru ture-based mode (two stations atta hing to the AP).
IBSS2
(b) Ad-ho mode (two IBSSs formed by three stations).
Figure 2.1: Illustration of the IEEE 802.11 operation modes.
ESS. An ESS is identi ed by an Extended Servi e Set Identi er (ESSID), usually shortened to SSID. The SSID is a text string with up to 32 hara ters that de nes the name of the IEEE 802.11 network.
In this mode,
data tra is always sent to and re eived from the AP. There is no dire t
ommuni ation between stations. The AP a ts as a relay between wireless stations, enabling ommuni ation even between stations that are not within radio range. An AP is usually atta hed to a ba khaul wired Ethernet infrastru ture and works as a IEEE 802.1D bridge [Gro04℄ between the wireless and wired parts. In ad-ho mode, there is no spe ial station de ned to manage the ad-ho network. Bea on frame generation is a
omplished in a distributed manner. The rst ad-ho station a tive establishes an Independent Basi Servi e Set (IBSS) and starts sending bea on frames.
Other ad-ho stations are able
to join the network after re eiving a bea on and a
epting the IBSS parameters (e.g., bea on interval) in luded in the bea on frame. All members of an IBSS parti ipate in the bea on generation pro ess. If a station does not hear a bea on within a short random delay period (2.SLOT.CWmin ), it assumes that no other stations are a tive and sends a bea on; the random delay minimizes the transmission of bea ons from multiple stations. In an IBSS, stations ommuni ate dire tly with ea h other in a peer-to-peer manner if they are in radio range. The IBSS is identi ed by an SSID and a MAC address randomly generated by the station that reates the IBSS. Membership in an IBSS does not imply that ommuni ation with all peers is possible. There may be some peers that are unable to ommuni ate dire tly.
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
2
2
6
6
6
Frame Control
Duration
Address 1
Address 2
Address 3
2
2
1
1
1
3
2
0 - 2312
4
QoS Control
DSAP “0xAA”
SSAP ”0xAA”
Control “0x03”
OUI “0x000000”
Ethertype
Data
FCS
6
Seq. Address 4 Control
15
IEEE 802.11 MAC header
LLC header
SNAP header
Figure 2.2: IEEE 802.11 MAC frame format with the number of bytes per eld on top. Destination address
Frame Duration Control
Address 1
Address 2
Address 3
Seq. Control
IEEE 802.11 MAC header
Source address
Address 4
Ethertype
QoS Control
DSAP “0xAA”
Data
FCS
SSAP ”0xAA”
Control “0x03”
LLC header
OUI “0x000000”
Ethertype
Data
FCS
SNAP header
Figure 2.3: Ethernet frame mapped into an IEEE 802.11 MAC frame (ad-ho mode).
For instan e, in Fig. 2.1b, IBSS2 is formed by three stations that are not all in radio range; the two laptops are out of ea h other's radio range. The family of IEEE 802 standards divides the Data Link Layer of the OSI model in two sublayers: the MAC sublayer and the Logi al Link Control (LLC) sublayer, with LLC running on top of the MAC sublayer [Gro02℄. The IEEE 802.11 MAC de nes a possible MAC sublayer; LLC (also known as IEEE 802.2 [Gro98℄) represents the sublayer ommon to all IEEE 802 standards [Gro02℄. Multiple proto ols may run on top of LLC. As su h, upon the LLC sublayer re eives a frame, it needs to gure out the upper layer proto ol to whi h the frame has to be delivered. For that purpose, the IEEE 802 ar hite ture de nes the Subnetwork A
ess Proto ol (SNAP) [Gro02℄, whi h in reases the number of upper layer proto ols that an be distinguished, from 256 (when using LLC alone) to at least 65536, and supports the identi ation of proto ols by Ethernet type (Ethertype). The SNAP header is appended to the LLC header in IEEE 802 frames. Fig. 2.2 shows an IEEE 802.11 MAC frame with the LLC and SNAP headers. This format is ompatible with the Ethernet frame format and enables Ethernet over LLC/SNAP, as spe i ed in the IEEE 802 ar hite ture [Gro02℄. The mapping between the two formats is illustrated in Fig. 2.3 for an IEEE 802.11 MAC frame in ad-ho mode, where Address 1 and Address 2 are used as destination address and sour e address,
1
respe tively ; the mapping for any IEEE 802 MAC is spe i ed in the IEEE 1
The mapping would be dierent in infrastru ture-based mode. In that ase, for an 802.11 MAC frame sent by an STA to the AP, for example, Address 2 and Address 3
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
16
802 ar hite ture [Gro02℄. The value 0xAA in the Destination Servi e A
ess Point (DSAP) and Sour e Servi e A
ess Point (SSAP) elds of the LLC header indi ate the presen e of the SNAP header; the value 0x000000 in the Organizationally Unique Identi er (OUI) eld indi ates that the proto ol running on top is identi ed by an Ethertype. In pra ti e, given the straightforward mapping from an Ethernet frame
2
to an IEEE 802.11 MAC frame , IEEE 802.11 NIC devi e drivers internally translate Ethernet frames into IEEE 802.11 MAC frames (and vi e-versa) before passing them downwards/upwards in the proto ol sta k. Thereby, an IEEE 802.11 NIC simply appears to upper layers as an Ethernet NIC enabling ommuni ation over the air. This makes the presen e of IEEE 802.11
ompletely transparent to upper layers, namely IP and IP-based servi es and appli ations, and guarantees full ompatibility with the standard IP over Ethernet behavior [Hor84℄ [Cra98℄.
2.2 Bluetooth Bluetooth [SIG10℄ is the most ommonly used WPAN te hnology. As it happens with IEEE 802.11, it is almost ubiquitous among personal devi es su h as laptops and mobile/smart phones, whi h are sold with built-in Bluetooth radios. Bluetooth, spe i ed by the Bluetooth Spe ial Interest Group (SIG), de nes a set of pro les aimed at being used for dierent appli ations, for instan e, transfer of a stereo audio stream, le transfer, and Ethernet emulation.
The support of multiple pro les makes the Bluetooth proto ol
sta k unusual when ompared to IEEE networking sta ks. The Bluetooth sta k de nes omponents above the PHY and MAC layers, whi h an vary a
ording to the pro les supported by a given devi e. As most of the IEEE 802.11 variants, Bluetooth operates in the 2.4 GHz frequen y band. In its
urrent version, it an support up to 3 Mbit/s of raw data rate. Nonetheless, with the re ent in orporation of IEEE 802.11 in the Bluetooth proto ol sta k [SIG10℄, the raw data rate provided an in rease up to the levels oered by IEEE 802.11. The use of IEEE 802.11 is usually limited to appli ations requiring high data rates, due to the lower energy e ien y of an IEEE 802.11 radio.
Whenever the use of IEEE 802.11 is needed, Bluetooth devi es are
would be used as sour e and destination addresses, respe tively. 2 This is true for any IEEE 802 MAC (see Se tion 10.5 in [Gro02℄)
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
17
able to negotiate IEEE 802.11 parameters, e.g., frequen y hannel, using the lassi Bluetooth MAC and PHY layers. Upon the IEEE 802.11 link is established, Bluetooth peers are able to ex hange data at high data rates. More re ently, the Bluetooth SIG spe i ed the Bluetooth Low Energy, now in luded in the Bluetooth spe i ation [SIG10℄ and originally alled Wibree, a proprietary WPAN te hnology developed by Nokia.
The main purpose
is to enable WPAN ommuni ation with ten times less energy onsumption and providing 1 Mbit/s of raw data rate. This variant targets devi es and s enarios not appropriately addressed by the lassi Bluetooth, su h as the
onne tion of a wristwat h to a laptop or the inter onne tion of health are sensors. The basi Bluetooth WPAN is alled a pi onet. A pi onet is formed by a master and up to seven slaves. Fig. 2.4a shows a Bluetooth pi onet formed by four devi es, one master and three slaves.
The master is in harge of
managing a pi onet; its MAC address and internal lo k uniquely identify the pi onet. It provides the needed time syn hronization within the pi onet,
ontrols data ex hange between pi onet members, and deals with the pi onet membership. Time syn hronization at the slaves is a
omplished based on any pa ket re eived from the master, thanks to a 64-bit syn hronization word in luded in the pa kets; for ea h pa ket re eived, slaves update their oset with respe t to the master's lo k. The physi al wireless hannel is shared among the pi onet members using a Time Division Multiple A
ess (TDMA) / Time Division Duplex (TDD) s heme ontrolled by the master. The wireless hannel is divided in numbered time slots, ea h with 625
µs duration.
A
time slot is assigned to one and only one devi e. All ommuni ation happens through the master. Slaves annot ommuni ate dire tly, as depi ted in Fig. 2.4a. Full-duplex ommuni ation is possible due to the alternate assignment of time slots to ea h ommuni ation dire tion, i.e., master to slave and slave to master. Master transmission always starts at even numbered time slots; slave transmission o
urs in odd numbered time slots. The master s hedules the transmission based on tra demands to and from the dierent slaves. It attempts to poll a slave's transmission no less often than on e every
Tpoll ,
whi h is de ned as the maximum time between transmissions from the master to a parti ular slave. Slaves listen to even time slots for pa kets. In order to avoid ollisions, a slave is only allowed to transmit in an odd time slot if it was addressed in the pre eding even slot.
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
18
M3 M1
M
S1
S8
S5/S7 S2
S1
S6
S3/M2 Piconet3
S3
Piconet1
S4
S2
Piconet2
(a) Bluetooth pi onet with the master and three slaves.
(b) Bluetooth s atternet omposed of three pi onets; devi es in red represent bridges/routers between pi onets.
Figure 2.4: Bluetooth network types.
The pi onet represents the basi Bluetooth network. Still, multiple pi onets an oexist within a given geographi area and form a s atternet, i.e., a set of inter onne ted pi onets.
A devi e an parti ipate in two or
more pi onets by using time division multiplexing.
This requires that the
devi e a quires the proper syn hronization at ea h pi onet, maintained by the orresponding master. A devi e may be a slave in multiple pi onets, but it an a t only as the master of one pi onet. In order to form a s atternet, some devi es need to belong to multiple pi onets and a t as bridges/routers between two or more pi onets.
The Bluetooth standard does not spe ify
any bridging/routing solution for reating a s atternet. Fig. 2.4b illustrates a s atternet formed by three pi onets.
There are two devi es that belong
to two distin t pi onets, shown in red olor.
S3 /M2 is a slave in Pi onet1
and the master of Pi onet2 , while S5 /S7 is a slave in both Pi onet2 and Pi onet3 . In order to enable s atternet-wide onne tivity both devi es a t as bridges/routers, S3 /M2 between Pi onet1 and Pi onet2 , and S3 /M2 between Pi onet2 and Pi onet3 . Among the multiple Bluetooth pro les, the PAN pro le enables easy reation of IP-based WPANs by providing Ethernet emulation over Bluetooth. Unmodi ed Ethernet payloads an be transmitted between Bluetooth devi es using the Bluetooth Network En apsulation Proto ol (BNEP); to upper layers Bluetooth appears as a lassi Ethernet link.
The PAN pro le
de nes the formation of a WPAN in the following situations: (1) ad-ho IP networking by two or more Bluetooth devi es in a single pi onet; (2) external network a
ess for one or more Bluetooth devi es. devi e may implement one of the following servi es:
Ea h Bluetooth
PAN User (PANU),
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
19
PANU1
External Network PANU5 PANU1
he rn et
Li nk
NAP
ul at ed
Et
late Emu
he d Et
rnet
Link
GN
Em
PANU2 PANU3
PANU4
PANU2
PANU3
(a) Network A
ess Point.
PANU1
(b) Group Ad-ho Network.
Emulated Ethernet Link PANU2
( ) PAN User to PAN User. Figure 2.5: Bluetooth PAN pro le networking s enarios.
Gateway Node (GN), or Network A
ess Point (NAP). The pro le spe i es three s enarios: Network A
ess Points, Group Ad-ho Networks, and PAN User to PAN User. In the rst s enario, illustrated in Fig. 2.5a, there is a devi e deploying the NAP servi e, whi h is able to provide a
ess to some external network, su h as Ethernet or ellular network. This devi e a ts as a bridge or router between the Bluetooth PAN and the external network; the other devi es onne t to it as PANUs.
This s enario is similar to the
infrastru ture-mode de ned in IEEE 802.11. In the se ond s enario, shown in Fig.
2.5b, devi es ooperate to reate a stand-alone PAN. One of the
devi es a ts as the master and implements the GN servi e; the other devi es are slaves and are onne ted to the master as PANUs.
In this ase,
the emulation of an Ethernet LAN is possible by running a bridge in the GN to inter onne t the multiple point-to-point emulated Ethernet links established between ea h PANU and the GN. The third s enario, presented in Fig. 2.5 , onsiders a point-to-point onne tion between two PANUs and enables dire t ommuni ation between them only; this s enario is equivalent to onne ting two devi es using an Ethernet ross-over able. By using one of these s enarios Bluetooth appears to upper layers as an Ethernet link and be omes ompatible with the IP over Ethernet model.
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
20
2.3 IEEE 802.15 In the s ope of the IEEE, the IEEE 802.15 Working Group (WG) for WPAN [Grob℄ is in harge of developing standards for Personal Area Networks. These WPANs address wireless networking of portable and mobile
omputing devi es su h as laptops, PDAs, mobile phones, and peripherals at the data link layer. The IEEE 802.15 WG has been partitioned in Task Groups (TG) that deal with spe i sub-areas within the Personal Area Networking area. The IEEE 802.15.1 Task Group (TG1) has reviewed and provided a standard adaptation of the Bluetooth Spe i ation version 1.2 for the MAC and PHY layers [Gro05a℄. The IEEE 802.15.3 (TG3) works on the standardization of high throughput WPANs, whereas the IEEE 802.15.4 (TG4) is hartered to spe ify low throughput, low energy onsumption, and low omplexity WPAN wireless solutions, whose potential appli ations are sensors, intera tive toys, smart badges, remote ontrols, and home automation.
In what follows, we refer to ea h of the spe i WPAN te hnologies
spe i ed in these TGs. The IEEE 802.15.1 is based on Bluetooth and simply spe i es the Bluetooth MAC and PHY layers, whi h were already des ribed in Se tion 2.2; so, we do not refer to it here again. Along this se tion, the terms IEEE 802.15.1 and Bluetooth are used inter hangeably.
2.3.1 IEEE 802.15.3 Taking into a
ount new personal area appli ations, su h as large le transfer of high-de nition videos, the IEEE 802.15.3 TG spe i ed the IEEE 802.15.3 standard, a new wireless te hnology overing use ases not addressed by IEEE 802.15.1. In spite of addressing dierent appli ation s enarios, the standard was developed having in mind the oexisten e with other IEEE 802 wireless standards, namely IEEE 802.11 and IEEE 802.15.1 [Gro05a℄. IEEE 802.15.3 provides a data throughput higher than Bluetooth, up to 55 Mbit/s of raw data rate, and it operates in the 2.4 GHz frequen y band. The in reasing demand for broadband wireless te hnologies, namely as a means to substitute wired te hnologies providing high data rates, led to the de nition of a new IEEE 802.15.3 variant, the IEEE 802.15.3a, that was intended to provide a high speed Ultra Wide Band (UWB) physi al layer amendment to IEEE 802.15.3. The IEEE 802.15.3a TG was dissolved in January 2006 due to the ompetition between two on urrent proposals
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
21
supported by two onsortiums, the UWB Forum and the WiMedia Allian e. The UWB Forum is now dissolved. The WiMedia Allian e standardized its proposal as two European Computer Manufa turers Asso iation (ECMA) standards (see Se tion 2.4). Re ently, a new IEEE 802.15.3 variant, IEEE 802.15.3 [Gro09 ℄, has been spe i ed in the IEEE 802.15 TG3 .
IEEE
802.15.3 operates in the 60 GHz frequen y band and provides data rates higher than 2 Gbit/s at the physi al layer. The basi IEEE 802.15.3 network is alled a pi onet, as in Bluetooth. A pi onet is a wireless ad-ho network formed by a number of independent devi es (DEVs) willing to ex hange data. In a pi onet one DEV is the pi onet
oordinator (PNC); Fig. 2.6 illustrates an IEEE 802.15.3 pi onet with ve DEVs, where DEV3 a ts as the PNC. An IEEE 802.15.3 pi onet is identi ed by a pi onet identi er (PNID), a 16-bit identi er, and a bea on sour e identi er (BSID), a text string with up to 32 hara ters. Both IDs are assigned at the PNC. Only the PNID has to be unique among neighbor pi onets. As the name implies, the PNC manages the WPAN, playing a role similar to the master in a Bluetooth network. A hybrid medium a
ess method is employed in IEEE 802.15.3; a ombination of CSMA/CA and TDMA a
ess methods is used. Communi ation within an IEEE 802.15.3 WPAN is performed based on superframes.
A superframe onsists of a bea on, a Contention A
ess
Period (CAP), and a Channel Time Allo ation (CTA) period. The bea on is sent by the PNC to the other members of the WPAN, for example for time syn hronization and hannel time allo ation purposes. CAP is used for
ontrol tra and data transmissions without any Quality of Servi e (QoS) guarantees; the CSMA/CA medium a
ess method is used during this period. The remaining duration of the superframe, the CTA period, is reserved for QoS-guaranteed transmissions. To provide QoS, the PNC assigns time slots, alled hannel time allo ations (CTAs), with xed start time and duration, to pi onet members during the CTA period, enabling ontention-free a
ess to the medium. During this period, the medium a
ess is ontrolled using the TDMA method. In an IEEE 802.15.3 pi onet, data ex hange is performed in a peer-topeer manner, as illustrated in Fig. 2.6. When CAP is used, DEVs simply employ the distributed CSMA/CA method des ribed in Se tion 2.1. In the CTA period, DEVs transmit data in the CTAs assigned by the PNC, whi h are announ ed in the bea on of the superframe.
In ontrast to CAP, the
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
DEV1
data
data
beacon
da ta
DEV4
be ac on
be
on ac
data
PNC/ DEV3
a dat
DEV2
22
DEV5
beacon
Figure 2.6: IEEE 802.15.3 pi onet formed by ve DEVs.
transmission using CTAs requires pre-signaling ex hange between DEVs and the PNC. CTAs announ ed in the bea on provide the CTA start time, duration, and the sour e and destination IDs for frames sent in the urrent CTA. In this way the devi es be ome aware of the time interval they an transmit on and the time intervals they need to be listening to tra from peer DEVs. The length of CAP in a superframe is determined by the PNC and ommuni ated to the other DEVs through the bea ons.
If no QoS-
guaranteed transmissions are onsidered, only the CAP is de ned and the medium a
ess method used in IEEE 802.15.3 is equal to that used in IEEE 802.11. The IEEE 802.15.3 standard allows a DEV to request the formation of a subsidiary pi onet. The already formed pi onet is alled the parent pi onet, while the subsidiary pi onet is alled either a hild or neighbor pi onet, depending on the method the DEV used to asso iate with the parent PNC. Child and neighbor pi onets are also referred to as dependent pi onets, sin e they rely on the parent PNC to allo ate hannel time for the operation of the dependent pi onet. A hild pi onet is a pi onet whose PNC belongs to the parent pi onet. A neighbor pi onet is a pi onet ontrolled by a devi e that does not belong to the parent pi onet. The reation of a hild pi onet is arried out with the PNC of the parent pi onet allo ating a private CTA, reserved for all transmissions within the
hild pi onet.
Thus, the superframe of the hild pi onet has a maximum
3
duration equal to the duration of the private CTA . Multiple hild pi onets 3
The pi onet. pi onet. valid for
duration of the superframe is a tually equal to the superframe of the parent Yet, only the private CTA interval is used for transmissions within the hild The remaining time is reserved for parent pi onet ommuni ation; this is also neighbor pi onets.
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
23
an be reated from a parent pi onet. Also, the establishment of a pi onet hierar hy is possible; a hild pi onet an have its own hild or neighbor pi onets. However, while simple, this hierar hy is failure prone; for instan e, if the parent PNC fails, all dependent pi onets will stop working. The hild PNC is a member of both the hild and parent pi onets. As su h, it may work as an interworking devi e between the hild and parent pi onets, enabling the reation of IEEE 802.15.3 s atternets. Nonetheless, the standard does not de ne any me hanism to do it. A neighbor pi onet is established by a DEV that is apable of be oming the PNC of a new pi onet in the same hannel. From the data ex hange point of view, the neighbor pi onet and the parent pi onet are isolated networks. The neighbor PNC simply asks for a private CTA within the parent PNC superframe, wherein all transmissions within the neighbor pi onet an o
ur. Data ex hange between the members of the neighbor and parent pi onets is by no means possible, sin e the neighbor PNC is not a member of the parent pi onet. So, s atternets are not possible in this ase. The des ription provided in the two previous paragraphs refers to the original version of the IEEE 802.15.3 standard. The IEEE 802.15.3b standard [PR07℄, published two years later, represents an amendment to IEEE 802.15.3 providing some orre tions and improvements. Among the amendments are the support of the LLC/SNAP format for data frames, the support of multiple CAPs within a superframe, and a method for relinquishing time in a CTA to enable transmission from another DEV belonging to the same pi onet. On the other hand, the IEEE 802.15.3 variant de nes a MAC sublayer based on the IEEE 802.15.3b, but adapted to the 60 GHz frequen y band, as well as to appli ations requiring several Gbit/s data rates.
The
IEEE 802.15.3 MAC de nes bea ons with additional elds to support dire tional antennas and more a
urate time resolution to in rease transmission e ien y.
In addition, due to the mu h higher transmission rate enabled,
the maximum payload length is in reased from 2 kbyte to 1 Mbyte. Also, further MAC throughput improvement is a hieved by the support of frame aggregation and blo k a knowledgments, as for IEEE 802.11n (see Se tion 2.1). The support of the LLC/SNAP format for data frames enables the adoption of an Ethernet ompatible frame format, as mentioned in Se tion 2.1. In this way, it be omes straightforward to transport Ethernet frames over
CHAPTER 2.
IEEE 802.15.3.
PAN AND LAN TECHNOLOGIES
24
The mapping between the Ethernet frame elds and the
IEEE 802.15.3 MAC frame elds is performed a
ording to what is spe i ed in the 802 ar hite ture [Gro02℄; the destination and sour e addresses of the Ethernet frame are mapped into the destination and sour e addresses in the IEEE 802.15.3 MAC frame, the Ethertype is mapped into the SNAP Ethertype, and the Data eld is mapped into the Data eld of the IEEE 802.15.3 MAC frame. The IEEE 802.15.3 MAC frame onsiders 8-bit IDs for the destination and sour e addresses, whi h are assigned by the PNC when DEVs join the pi onet. The onversion from 48-bit MAC addresses into the 8-bit IDs, and vi e-versa, is ensured by the 802.2 Frame Convergen e Sublayer (FCSL) de ned in IEEE 802.15.3 [Gro03℄.
Thus, in pra ti e, as it hap-
pens with IEEE 802.11 NICs, an IEEE 802.15.3 NIC an appear to upper layers as an Ethernet NIC enabling wireless ommuni ation. However, the deployment of IEEE 802.15.3-based produ ts was minimal or inexistent so far, namely due to the advent of other te hnologies, su h as WiMedia UWB and Wireless USB, now assuming the role envisioned for IEEE 802.15.3.
2.3.2 IEEE 802.15.4 IEEE 802.15.4 is a low data rate, low energy onsumption wireless te hnology widely adopted in sensor nodes [Gro06b℄. It is developed for appli ations with low throughput requirements and that annot handle the power
onsumption of other wireless te hnologies, su h as Bluetooth and IEEE 802.11.
IEEE 802.15.4 an operate at the following unli ensed frequen y
bands: 868 MHz (Europe), 915 MHz (US), and 2.4 GHz (worldwide). The data rates provided at the physi al layer are 20 kbit/s at 868 MHz, 40 kbit/s at 915 MHz, and 250 kbit/s at 2.4 GHz. More re ently, IEEE 802.15.4a was released as an amendment to IEEE 802.15.4. IEEE 802.15.4a an operate in several frequen y bands: 0.7-1 GHz, 2.4 GHz, 3-5 GHz, and 6-10 GHz. It de nes two alternative PHY layers to IEEE 802.15.4 providing higher data rates: the UWB PHY and the Chirp Spread Spe trum (CSS) PHY. The UWB PHY an operate in one of the last three frequen y bands; the CSS PHY operates in the 2.4 GHz band. IEEE 802.15.4a de nes mandatory data rates and optional data rates.
If using
the UWB PHY, the mandatory data rate is 851 kbit/s, with optional data rates of 110 kbit/s, 6.81 Mbit/s, and 27.24 Mbit/s. The CSS PHY spe i es a mandatory data rate of 1 Mbit/s and optionally supports 250 kbit/s. The
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
25
PHY layer to use in pra ti e depends on lo al regulations with respe t to frequen y bands, the appli ation, and user preferen es. An IEEE 802.15.4 network is alled a Low Rate WPAN (LR-WPAN). Two dierent ategories of IEEE 802.15.4 devi es an belong to an LRWPAN: Full Fun tion Devi es (FFDs) and Redu ed Fun tion Devi es (RFDs). FFDs an ommuni ate dire tly with any other devi e in the same LRWPAN; RFDs ommuni ate with FFDs only. RFDs are intended to be used in very simple appli ations, su h as a light swit h or an infrared sensor. An LR-WPAN shall have at least one FFD, a ting as the LR-WPAN Coordinator (LPNC). An LR-WPAN is uniquely identi ed by a 16-bit PAN Identi er (PNID) generated by the LPNC. LR-WPANs an operate in non-bea onenabled mode or optionally in bea on-enabled mode. In non-bea on-enabled mode, the LPNC does not broad ast any bea ons and CSMA/CA is used as the medium a
ess method. In bea on-mode, the LPNC broad asts bea ons and ommuni ation is based on superframes. The superframe in ludes an a tive part, omposed of the bea on period, a CAP, and a Contention Free Period (CFP) and an optional ina tive part.
The a tive part is di-
vided into 16 equal time slots; the bea on is always transmitted in the rst slot. CAP begins right after the bea on. Slotted CSMA/CA is used as the medium a
ess method during CAP. A Ba ko Period (BP) similar to the SLOT interval in IEEE 802.11 is de ned; the boundaries of the BP must be aligned with the boundaries of the time slots of the superframe. In slotted CSMA/CA, hannel a
ess shall always start at the beginning of a BP. In addition, upon the hannel is found idle after a ontention period, instead of transmitting immediately, as in CSMA/CA, a devi e waits for two further BPs, by default, before transmitting in the beginning of the next BP. The CFP period in the superframe is optional. The allo ation of time slots,
alled Guaranteed Time Slots (GTSs), is ontrolled by the LPNC. As in IEEE 802.15.3, the use of GTSs requires pre-signaling between the LPNC and the devi e requesting the GTS; the assignment of GTSs to LR-WPAN devi es is announ ed by the LPNC in the bea ons. GTSs are only used for
ommuni ation between the LPNC and a LR-WPAN devi e. An LR-WPAN may operate in two topologies: star and peer-to-peer. In the former, ommuni ation happens between devi es and the LPNC, similarly to the Bluetooth ommuni ation pattern.
In the latter, ea h devi e
an ommuni ate with any other devi e as long as they are in ea h other's
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
26
range, with the ex eption of RFDs that an only ommuni ate with FFDs. The topology used in pra ti e depends on the s enario. The star topology may be used, for instan e, to support ommuni ation between a PC and some peripherals. The peer-to-peer topology may be used to enable wireless sensor networks, for example. As an IEEE 802 standard, and a
ording to the IEEE 802 ar hite ture [Gro02℄, IEEE 802.15.4 ould also support the LLC/SNAP format. Nevertheless, the IEEE 802.15.4 MAC frame has a quite limited payload length; the maximum is 118 bytes [Gro06b℄. Then, the in lusion of the LLC/SNAP headers would redu e the payload length to a maximum of 110 bytes.
As
su h, while theoreti ally possible, the support of an Ethernet ompatible frame format over IEEE 802.15.4 is not spe i ed by IEEE 802.15.4. It simply de nes the use of LLC on top of the MAC sublayer.
2.4 WiMedia Ultra Wide Band The WiMedia UWB te hnology is a standard that ame out after the abortion of the IEEE 802.15.3a standardization pro ess. It was standardized by the WiMedia Allian e [All℄ as an ECMA standard (ECMA-368) and as an International Organization for Standardization (ISO) standard (ISO/IEC 26907) [ECM05℄. WiMedia UWB operates in the 3.1-10.7 GHz unli ensed frequen y band and enables raw data rates up to 480 Mbit/s. A WiMedia UWB WPAN (WU-WPAN) is a wireless ad-ho network formed by WiMedia UWB devi es without any oordinator. The network is managed in a distributed way; all devi es perform equivalent fun tions, as in the 802.11 ad-ho mode (see Se tion 2.1). Like in IEEE 802.15.3, ommuni ation is performed based on superframes. A superframe is divided into 256 Medium A
ess Slots (MASs). The superframe enables time syn hronization and transmission oordination among the WU-WPAN devi es. Similarly to IEEE 802.15.3, the superframe is divided into three periods: a bea on period, a CAP, and an CFP. The bea on period has variable length formed by a number of MASs; its length depends on the number of devi es within a WU-WPAN. In WiMedia UWB bea ons are generated in a distributed manner.
To prevent that ea h WU-WPAN devi e de nes its own bea on
period, devi es s an the medium for bea ons before beginning operation. If a devi e dete ts another devi e already in operation by re eiving its bea ons,
CHAPTER 2.
Client Protocols
PAN AND LAN TECHNOLOGIES
27
Wireless USB
Bluetooth
IP
Other
PAL
PAL
WLP
PAL
WiMedia UWB Radio Platform
MAC PHY
Figure 2.7: WiMedia radio platform and the multiple lient proto ol sta ks it an support by means of PALs.
it aligns its operation with that devi e. If it does not dete t any bea ons it will reate a new bea on period by sending its own bea on. Medium a
ess o
urs in the subsequent periods of the superframe. During CAP, a prioritized CSMA/CA a
ess method is used, whi h supports prioritized a
ess to medium a
ording to four ategories; if a single ategory is onsidered this is a pure CSMA/CA method. In CFP, MASs are reserved by devi es in a distributed way. Information ex hanged during the bea on period supports the negotiation and maintenan e of the reservations. The WiMedia UWB supports multiple Proto ol Adaptation Layers (PALs), in luding a PAL for Wireless USB, a PAL for Bluetooth, and the Wireless Link Layer Control Proto ol (WLP), whi h is a PAL for supporting IP-based appli ations [All08℄. This enables multiple lient proto ols on top of the WiMedia radio platform, as shown in Fig. 2.7. Wireless USB and its integration with the WiMedia UWB radio platform is des ribed in Se tion 2.5. The integration of Bluetooth with WiMedia UWB was sele ted by the Bluetooth SIG [SIGa℄, so that the WiMedia UWB radio platform was used as an alternative MAC layer and PHY layer. WiMedia UWB was not yet integrated as part of the re ent Bluetooth 3.0 that sele ted IEEE 802.11 instead. However, this integration is expe ted to happen in the future [SIGb℄. WLP provides Ethernet emulation over WiMedia UWB [All08℄, as it happens with BNEP in Bluetooth, and it supports a shared wireless media ommuni ation pattern. A WLP network is alled a WiMedia Servi e Set (WSS). In a WSS, devi es an ommuni ate dire tly as long as they are in ea h other's radio range. A WSS is similar to an IBSS in IEEE 802.11 terms (see Se tion 2.1). In pra ti e, a WiMedia UWB NIC supporting the WLP appears as an Ethernet NIC to upper layers [Gon07℄. In this way, WiMedia UWB is also in
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
28
agreement with the standard IP over Ethernet behavior.
2.5 Wireless USB Wireless Universal Serial Bus (WUSB) [For05a℄ represents an evolution of the standard wired USB 2.0 [For00℄, hereafter abbreviated to USB 2.0. From the viewpoint of end-users WUSB appears as USB 2.0, just without the wires. WUSB works on top of the WiMedia UWB MAC and PHY layers for wireless transmissions, as mentioned in Se tion 2.4. As su h, it supports up to 480 Mbit/s, the same data rate provided by USB 2.0 [For00℄, and operates in the 3.1-10.7 GHz frequen y band. WUSB supports data ex hange between a WUSB host (usually a PC) and a set of WUSB devi es, hereafter simply named as host and devi es, respe tively.
A WUSB network, alled WUSB Cluster, onsists of a tree
topology formed by point-to-point links between the host and all the devi es it manages. A single host is de ned per WUSB Cluster. Data ex hange is enabled through a WUSB hannel mapped onto the WiMedia UWB MAC superframes. The WUSB hannel is reated by the host by means of a set of MAS reservations in the CFP of the superframe. In turn, the host and the devi es share the WUSB hannel by using a TDMA-based a
ess method
ontrolled by the host. Data transfers are always host-initiated. The host is in harge of sending information on the spe i time ea h devi e should listen for a pa ket from the host or transmit a pa ket to it; this announ ement are
arried out using ontrol pa kets sent over the WUSB hannel as well. Wired USB spe i es the support of IP-based data ommuni ations by means of Ethernet emulation over the USB hannel [For05b℄.
As a pure
wireless extension of wired USB, WUSB inherently supports it as well, despite being less e ient than the WLP, due to the higher number of layers involved Ethernet over WUSB over WiMedia UWB radio platform. WUSB may also be used in pra ti e as an Ethernet-like NIC and be transparently integrated in the proto ol sta k.
2.6 WirelessHD WirelessHD [Con℄ is an industry-led eort to de ne a standard providing very high data rates for enabling the transmission of high-de nition mul-
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
29
timedia ontents, for example, between a digital video amera and a personal video re order.
Although fo used on this type of appli ations, it is
envisaged as an enabler for other appli ations too, su h as le transfer. The rst WirelessHD-enabled produ ts are already deployed [Con℄, but the WirelessHD spe i ation is not publi ly available. The WirelessHD onsortium only published an overview of the WirelessHD spe i ation. The des ription presented herein is based on su h summary and the information provided in the WirelessHD o ial website [Con℄. In its urrent version, WirelessHD enables data rates at the physi al layer up to 4 Gbit/s and operates in the 60 GHz unli ensed frequen y band. WirelessHD de nes two PHY layers: the High Rate Physi al layer (HRP) and the Low Rate Physi al layer (LRP). The HRP provides multi-Gbit/s data rates by using dire tional antennas Be ause of this HRP is only used for uni ast ommuni ations.
The LRP
is a multi-Mbit/s PHY layer. For lower data rates it uses omni-dire tional antennas, while for higher data rates dire tional antennas are used.
LRP
an be used for both uni ast and broad ast ommuni ations. A WirelessHD network, alled Wireless Video Area Network (WVAN), is an ad-ho network formed by one Coordinator and zero or more Stations. The Coordinator is usually a devi e that is a sink for audio or video data, for instan e, a personal video re order. The Coordinator provides time syn hronization and deals with the WVAN membership. A WVAN is identi ed by a WVAN ID, whose length is not spe i ed in the WirelessHD overview [Con07℄.
Communi ation within a WVAN is based on superframes.
Like
in IEEE 802.15.3 and IEEE 802.15.4, the superframe begins with a bea on sent by the oordinator, and in ludes a CAP and a CFP. The size of the CAP (and inherently the size of the CFP) is de ned by the Coordinator. In the CAP the Preamble-sense Multiple A
ess with Collision Avoidan e (PSMA/CA) method is used. PSMA/CA is similar to CSMA/CA. The differen e has only to do with the way the medium is dete ted to be idle or busy. PSMA/CA relies on the dete tion of the preamble of a transmitted frame instead of using arrier sense [Con07℄.
In the CFP, Channel Time Blo ks
(CTBs) are assigned to Stations. Ea h CTB is assigned to a spe i sour e and destination. Stations request for CTBs by sending the required signaling to the Coordinator. Information on erning the CTBs assigned to Stations is announ ed by the Coordinator in the bea on.
In WirelessHD, data ex-
hange is performed dire tly between sour e and destination regardless of
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
30
the medium a
ess method used. WirelessHD does not de ne any Ethernet emulation solution and does not make any referen e to the support of IP-based appli ations on top. Nevertheless, if the te hnology su
eeds and is widely adopted, we believe that these are features that may in the future make part of the te hnology, as it happens with most of the wireless te hnologies in this domain.
2.7 Summary Wireless ommuni ations are assuming a entral role in the PAN/LAN s ope.
Multiple ommuni ation te hnologies have been de ned.
In this
hapter we fo used on the most prominent, whose main hara teristi s are summarized in Table 2.1. These te hnologies operate in dierent frequen y bands and are heterogeneous with respe t to the data rates they provide; the dieren es an rea h ve orders of magnitude. However, when it omes to the support of IP-based appli ations, they are rather homogeneous: all of them, but WirelessHD and IEEE 802.15.4, support Ethernet emulation. On the other hand, CSMA/CA is or an be used in most of te hnologies as medium a
ess method; ex eptions are Bluetooth and WUSB whi h de ne a TDMA-based method.
Some of these te hnologies target similar appli-
ation s enarios (IEEE 802.15.3 , WiMedia UWB, and WirelessHD), while others are omplementary (WiMedia UWB, IEEE 802.11, Bluetooth, and IEEE 802.15.4).
In the medium to long-term only the subset de ned by
omplementary te hnologies will probably survive. The simultaneous deployment of IEEE 802.11 and Bluetooth radios in the same devi e is nowadays ommon in laptops and smart phones, for example. With the advent of new omplementary te hnologies, the number of
oexisting te hnologies is expe ted to in rease and devi es with IEEE 802.11, Bluetooth, and WUSB radios, for instan e, may be ome ommon. This will enable the reation of multi-te hnology PANs/LANs.
For instan e, LANs
may be reated based on IEEE 802.11 and WiMedia UWB, where the latter may be used for overing dense areas [CSM09℄, and multi-te hnology PANs
an be brought up by taking advantage of the set of wireless te hnologies available in personal devi es. The prevalen e of CSMA/CA as the medium a
ess method makes the
oexisten e of dierent WPAN/WLAN te hnologies in the same frequen y
CHAPTER 2.
PAN AND LAN TECHNOLOGIES
31
band easier [Gro03℄. On the other hand, the onvergen e to an all-Ethernet paradigm enables easy integration of te hnologies that are dierent at the MAC and PHY layer by means of Ethernet bridging [Ba 98℄; for example, the integration of WiMedia UWB A
ess Points in urrent LANs be omes straightforward. Also, the deployment of multi-te hnology WPANs is made simple.
It an be performed without modifying the networking prin iples
assumed by upper layers proto ols, namely IP and its ompanion proto ols, by using Ethernet bridging available in mainstream operating systems, su h as Windows
4 and Linux5 .
While ea h wireless te hnology was de ned with some appli ations in mind, a given te hnology is in pra ti e a pipe through whi h bits an be ex hanged ba k and forth, regardless of the appli ation running on top. This is the perspe tive taken in this PhD thesis. Herein, underlying wireless te hnologies are onsidered as the means that enable the transportation of upper layer pa kets with full ompatibility with the standard IP over Ethernet behavior.
4 5
http://www.mi rosoft. om/windowsxp/using/networking/expert/ rawford_02april22.mspx http://www.linuxfoundation.org/en/Net:Bridge
Freq. band (GHz)
Data rate (Mbit/s)
MAC method
Ethernet emulation
IEEE 802.11a IEEE 802.11b IEEE 802.11g
5 2.4 2.4 2.4 5 2.4 2.4 2.4 57-64 0.868 0.915 2.4 2.4 3-5 6-10 <1 3.1-10.6 3.1-10.6 60
54 11 54
CSMA/CA CSMA/CA CSMA/CA
X X X
600
CSMA/CA
X
3 1 55 > 2000 0.02 0.04 0.25 0.851 (0.11; 6.81; 27.24) 1.0 (0.25) 480 480 4000
TDMA TDMA CSMA/CA + TDMA
X X X X
CSMA/CA
CSMA/CA (slotted CSMA/CA + TDMA)
CSMA/CA + TDMA TDMA CSMA/CA + TDMA
X X
IEEE 802.11n Bluetooth Bluetooth Low Energy IEEE 802.15.3b IEEE 802.15.3 IEEE 802.15.4
IEEE 802.15.4a WiMedia UWB Wireless USB WirelessHD
PAN AND LAN TECHNOLOGIES
Te hnology
CHAPTER 2.
Table 2.1: Summary of the main hara teristi s of the wireless te hnologies, with the optional features between parentheses.
32
Chapter 3
Graphs, Spanning Trees and Spanning Tree Algorithms Graphs nd appli ation in multiple knowledge areas. In the networking area, they have been widely used as a means to model ommuni ation networks.
By using graphs it is possible to model the network topology and
the ommuni ation ost to traverse the links onne ting the network nodes, while abstra ting from the unne essary details about the nodes and the links. The graph modeling a ommuni ation network is named topology graph. In the topology graph, the verti es model the network nodes, the edges model the network links onne ting the network nodes, and the weights assigned to the edges represent osts omputed based on metri s, su h as link bandwidth and link delay. The topology graph is then used as input to a routing algorithm that is in harge of omputing the a tive network topology. The a tive topology is de ned by the links sele ted to ex hange data, whi h may form a single or multiple spanning trees. In this hapter we present the on epts of graph, tree, and spanning tree, as well as other related on epts as de ned in graph theory. In addition, we de ne three well known spanning trees: Shortest Paths Spanning Tree (SPST), Minimum Spanning Tree (MST), and Minimum Routing Cost Spanning Tree (MRCST), that an be omputed from an input graph
G,
and employed in pra ti e to de ne the a tive topology of a network. Afterwards, we present the relevant algorithms designed to ompute ea h type of spanning tree. At the end of the hapter we summarize the major on epts presented and we draw the main on lusions.
33
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
34
1 10
2 5
2 4
3 3
4
Figure 3.1: Example weighted undire ted graph
Ge .
3.1 De nitions Dierent types of graphs are de ned in graph theory: dire ted and undire ted graphs, weighted and unweighted graphs as well as their ombinations. Here, we onsider weighted undire ted graphs. Fig. 3.1 illustrates an example weighted undire ted graph. Cir les represent the verti es of the graph, lines represent the edges of the graph, and the numbers next to the lines spe ify the weights assigned to the orresponding edge. Formally, a weighted undire ted graph set of verti es
V
onne ted by a set of edges
G = (V, E, w) is de ned as a E ⊆ V × V (i.e., the elements
(i, j) ∈ E , where i, j ∈ V ); w(i, j) de nes the weight assigned to the edge (i, j) and takes an integer value. The number of verti es in G is n = |V | and the number of edges is m = |E|. The graph in Fig. 3.1 has n = 4 and m = 5. The set of verti es adja ent to a vertex v is denoted by Av . The degree of a vertex v (dv ) is de ned as its number of adja ent edges, where an edge adja ent to v is an edge onne ting v to a neighbor vertex. In Fig. 3.1 vertex 2, for example, has degree 3. A graph where all verti es have degree
n−1
is a
omplete graph.
P in G is de ned as a sequen e of onne ted adja ent verti es {v1 , v2 , ..., vi }; the path starts at the rst vertex of the sequen e and ends at the last vertex of the sequen e, here alled verti es v1 and vi , respe tively. The ost of a path P in G between v1 and vi , cP,G (v1 , vi ), is equal to the sum A path
of the weights of the edges belonging to the path and is formally de ned as:
cP,G (v1 , vi ) =
i−1 X
w(vj , vj+1 )
(3.1)
j=1
In Fig. 3.1, the sequen e
{1, 2, 4, 3}
represents a path
P
between verti es 1
CHAPTER 3.
and 3 and in
G
SPANNING TREES AND ALGORITHMS
cP,G (1, 3) = 10 + 4 + 3 = 17 represents the ost of path P .
35
A y le
is de ned as a path where the rst and the last vertex in the sequen e
v1 = vi . In Fig. 3.1, the sequen e {1, 2, 4, 3, 1} de nes G in whi h edge weights satisfy the triangle inequality is
are the same, i.e., a y le. A graph
alled a
metri graph.
The triangle inequality is de ned as follows:
cP1 ,G (i, j) ≤ cP2 ,G (i, k) + cP2 ,G (k, j), k ∈ / {i, j} whi h states that the dire t path in
G
P1
between two adja ent verti es
has always a ost lower or equal than any other indire t path
(3.2)
i and j P2 in G
between the two verti es. The graph of Fig. 3.1 is not a metri graph, sin e the ost of the dire t path between vertex 1 and 2, for instan e, is higher than the ost of the indire t path A tree
T = (VT , ET , wT ) a set of verti es VT
{1, 3, 2}.
is a onne ted graph without y les.
T
is
ET , with weights wT representing osts assigned to the set of edges ET ; wT (ek ) de nes the weight assigned to the edge ek = (i, j) ∈ ET , where i, j ∈ VT . The number of verti es in T is |VT | and the number of edges is |ET | = |VT | − 1. Any two verti es in T are onne ted by exa tly one path. In Fig. 3.1 if the edges (1, 3) and (3, 4) are removed we get the tree of Fig. 3.2. A spanning tree for a graph G = (V, E, w) is de ned as a subgraph of G that is a tree, ontains all verti es of G, and has |V | − 1 edges. Some ost fun tions an be de ned for a tree T . Here, we refer to three
ost fun tions, with appli ation in pra ti e. The ost of the path P in T between a sour e vertex v1 and a vertex vi , with v1 , vi ∈ VT , is given by de ned by
onne ted by a set of edges
cP,T (v1 , vi ) =
i−1 X
wT (vj , vj+1 )
(3.3)
j=1
a
ording to Eq. 3.1. The total ost for
T
is given by
|ET |
Ct (T ) =
X
wT (ek )
(3.4)
k=1
The routing ost for
T
is
Cr (T ) =
|VT | |VT | X X i=1 j=1 j6=i
cP,T (i, j)
(3.5)
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
36
1 10 5
2
3
4
4
Figure 3.2: The spanning tree
Te
omputed from graph
Ge .
These ost fun tions be ome learer using an example. Fig. 3.2 shows a spanning tree
Te
omputed from the example graph in Fig. 3.1. The ost of
a path between two given verti es was already illustrated. We now illustrate the total ost and the routing ost for
Te .
The total ost for
Te
is
Ct (Te ) = wTe (e1 ) + wTe (e2 ) + wTe (e3 ) = wTe (1, 2) + wTe (2, 3) + wTe (2, 4) = 10 + 5 + 4 = 19 while the routing ost for
Te
an be omputed using the following expression:
Cr (Te ) = cP,Te (1, 2) + cP,Te (1, 3) + cP,Te (1, 4) +cP,Te (2, 1) + cP,Te (2, 3) + cP,Te (2, 4) +cP,Te (3, 1) + cP,Te (3, 2) + cP,Te (3, 4) +cP,Te (4, 1) + cP,Te (4, 2) + cP,Te (4, 3) = 10 + 15 + 14 + 10 + 5 + 4 + 15 + 5 + 9 + 14 + 4 + 9 = 114 Table 3.1 summarizes the notation introdu ed in this se tion.
3.2 Spanning Tree Types Based on the minimization of the ost fun tions de ned in Eq. Eq. 3.5, three spanning trees have been de ned for an input graph
3.3 to
G:
the
Shortest Paths Spanning Tree, the Minimum Spanning Tree, and the Minimum Routing Cost Spanning Tree.
These types of trees only represent a
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
37
Notation
De nition
G = (V, E, w)
weighted undire ted graph with a set of verti es V onne ted by a set of edges E , with weights w weight assigned to edge (i, j) ∈ E number of verti es in G number of edges in G set of verti es adja ent to vertex v degree of of a vertex v path in a graph G or a tree T , de ned as a sequen e of onne ted adja ent verti es {v1 , v2 , ..., vi } tree with a set of verti es VT onne ted by a set of edges ET , with weights wT weight assigned to edge (i, j) ∈ ET number of verti es in T number of edges in T
ost of a path P in G between verti es v1 and vi (Eq. 3.1)
ost of the path P in T between verti es v1 and vi (Eq. 3.3) total ost of a tree T (Eq. 3.4) routing ost of a tree T (Eq. 3.5)
w(i, j) n m Av dv P T = (VT , ET , wT ) wT (i, j) |VT | |ET | cP,G (v1 , vi ) cP,T (v1 , vi ) Ct (T ) Cr (T )
Table 3.1: Summary of the de nitions.
small subset of the wide set of spanning trees that may be omputed from a graph A
G.
Still, they are the types nding wide appli ation in data networks.
Shortest Paths Spanning Tree (SPST) rooted at a vertex s de nes
a tree omposed by the union of the paths between verti es in
G
su h that the ost of the path
P
from
s and s to v
ea h of the other is given by
cP,SP ST (s, v) = min(cP1 ,G (s, v), cP2 ,G (s, v), ..., cPn ,G (s, v)) with
v∈V
v 6= s and where {P1 , P2 , ..., Pn } de nes the set of s and v in G. Considering the graph Ge of Fig.
and
paths between
(3.6) possible 3.1, we
illustrate how an SPST ould be omputed using exhaustive sear h. Before
omputing the SPST, a sour e vertex needs to be sele ted; vertex 2 is sele ted in this ase. The most simplisti approa h to ompute the SPST is to identify every possible path between vertex 2 and the other verti es in
Ge .
The paths
with lowest ost are then sele ted to reate the SPST. Table 3.2 provides the set of paths (and the orresponding osts) between vertex 2 and its peer verti es in
Ge ;
the shortest paths are in bold. The SPST from the point of
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Path
Cost
{2,1}
10
{2, 4, 3, 1}
9
{2, 3, 1}
38
7
{2, 3}
5
{2, 1, 3} {2, 4, 3}
12 7
{2, 3, 4} {2, 1, 3, 4}
8 15
{2, 4}
4
Table 3.2: Set of paths (and orresponding osts) between vertex 2 and its peer verti es in
Ge .
view of vertex 2 is given by the union of the shortest paths that inter onne t every pair of verti es; the resulting SPST is shown in Fig. 3.3h. A
Minimum Spanning Tree (MST)
represents a spanning tree
T∗
su h that:
Ct (T ∗ ) = min (Ct (T )) for all spanning trees
T
that an be omputed from
sear h approa h to nd an MST for spanning tree from
Ge .
an be omputed using
Ge
(3.7)
G.
The exhaustive
onsists of omputing every possible
The number of spanning trees of an input graph
Kir hho's
theorem) [HHM08℄. Let
L(G)
theorem (also known as the
be the
n×n
G
Matrix-Tree
matrix whose entry lij is de ned
as follows:
di lij = −1 0
if if
i=j i 6= j
and
(i, j) ∈ E
otherwise
di is the degree of vertex i. L(G) is alled the Lapla ian matrix for G. Let L∗ (G) de ne the matrix obtained after removing any row and any
olumn from L(G). The number of spanning trees of G is equal to the ∗ ∗ determinant of L (G) (|L (G)|). In our example, the Lapla ian matrix for Ge is de ned by: where
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
1 10
3
2
3
3 4
1
10
2
2
10
2
3 4
3
2
2
3
3 4
4
4
4
4
(a)
(b)
( )
(d)
1
1
1
1
10
2
10 5
2
1
1 2
39
5
2
3
2
3
2 5 3
3
4
3
5
2
3
4
4
4
4
4
(e)
(f)
(g)
(h)
Figure 3.3: Set of possible spanning trees omputed from the graph
Ge .
2 −1 −1 0 −1 3 −1 −1 L(Ge ) = −1 −1 3 −1 0 −1 −1 2
In order to obtain
L∗ (Ge )
we remove one row and one olumn from
L(Ge ).
Here, the rst row and the rst olumn are removed. However, any other row or olumn ould be removed without ae ting the absolute value |L
L∗ (Ge )
∗ (G )|. e
is then de ned by:
3 −1 −1 L∗ (Ge ) = −1 3 −1 −1 −1 2
|L
∗ (G )| is equal to 8. So, eight spanning trees an be omputed from e
(as seen in Fig.
3.3).
Table 3.3 provides the total ost for ea h spanning
tree. The MST is spanning tree (b), with total ost A
Ge
Ct (T ∗ ) = 9.
Minimum Routing Cost Spanning Tree (MRCST) represents a
spanning tree
T∗
su h that:
Cr (T ∗ ) = min (Cr (T )) for all spanning trees
T
that an be omputed from
(3.8)
G.
An MRCST for
Ge
an be found from the set provided in Fig. 3.3. The routing ost for ea h
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
40
spanning tree is provided in Table 3.3. In this ase, two spanning trees mat h the routing ost minimization riterion: spanning tree (b) and spanning tree
Ge
(f ). Any of them de nes an MRCST for
with routing ost
Cr (T ∗ ) = 60.
The SPST, MST, and MRCST are related with ea h other. An MRCST is a generalization of an SPST. While an SPST de nes the optimal spanning
s, an MRCST represents of n sour es. Interestingly,
tree from the point of view of a single sour e vertex the optimal spanning tree from the point of view when a single sour e at
s
s
is de ned in the MRCST problem, the SPST rooted
and the MRCST oin ide. In Eq. 3.5, if a single sour e
s
is onsidered,
the outer sum disappears and the equation is simpli ed to:
Cr,s (T ) =
n X
cP,T (s, j)
(3.9)
j=1 j6=s
In turn, Eq. 3.8 is simpli ed to:
n X Cr,s (T ∗ ) = min cP,T (s, j)
(3.10)
j=1 j6=s
Eq. 3.10 is simply another way of formalizing the SPST problem. On the other hand, any SPST rooted at a vertex
v ∈V,
the MST, and the MRCST
onverge to the same spanning tree as the heterogeneity of the input graph in reases, i.e., as the varian e of the set of edge weights was on luded by Mieghem
et al.
using a modi ed example graph to 1.
w of G in reases.
G
This
in [ML05℄ [MM05℄ and an be illustrated
G′e
derived from
Ge
by hanging
w(2, 4)
If we try to ompute all possible SPSTs, an MST, and an MRCST,
we on lude that the spanning tree (b), with
w(2, 4)
updated to 1, is the
′ solution for all of them. So, for Ge the three spanning trees oin ide. Shortest Paths Spanning Trees, Minimum Spanning Trees, and Minimum Routing Cost Spanning Trees are not ne essarily unique for a given input graph
G,
as exempli ed here for the MRCST. For instan e, a unique MST
is only guaranteed when the weights of the input graph are all dierent; otherwise, there an be multiple spanning trees that mat h the minimum total ost riterion.
The exhaustive sear h approa h used to ompute the
three spanning trees (SPST, MST, and MRCST) from an input graph may only be used if
G
has a few verti es.
G
For bigger input graphs, more
e ient approa hes are needed. The relevant algorithms used in pra ti e for
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Spanning Tree
Total Cost
a
15
9
60
d e
17 16 19 10 18 11
110 116 114
b
f
g h
41
Routing Cost 94
60
118 87
Table 3.3: Total ost and routing ost for ea h possible spanning tree omputed from the input graph
Ge .
omputing these spanning trees are des ribed in the following se tions. For better understanding the algorithms, their des ription is a
ompanied by an example.
3.3 Shortest Paths Spanning Tree Algorithms This se tion des ribes the two prominent shortest paths spanning tree algorithms. Both allow the omputation of an SPST in a more e ient way than the exhaustive sear h algorithm used in Se tion 3.2.
3.3.1
Dijkstra's
Dijkstra's
Algorithm
algorithm [Dij59℄, by Edsger Dijkstra, is the lassi al shortest
paths algorithm used in network routing proto ols for de ning shortest uni ast paths between pairs of nodes. It is a greedy algorithm, sin e it sear hes for the lo al optimal hoi e at ea h stage, in order to nd the global optimum at the end. A greedy algorithm annot always nd the global optimum. This is not the ase for
Dijkstra's algorithm, whi h an always nd the SPST
for a weighted input graph, provided that the latter has no negative-weight edges.
Dijkstra's
algorithm grows from a sour e vertex
s
and extends out-
wards within the graph, until all verti es have been spanned and a shortest paths spanning tree
T
has been found.
maintains two attributes:
δv ,
For ea h vertex
v
the algorithm
the shortest path estimate from the sour e to
v , and pv , whi h stores the parent vertex of v
in the SPST. At the beginning,
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Iteration 0 1 2 3 Table 3.4:
v
δv
pv
1 ∞ 0 3 ∞ 4 ∞ 1 10 (∞) 2 2 3 5 (∞) 2 4 4 (∞ ) 2 1 10 2 2 3 7 (5) 4 (2) 4 1 7 (10) 3 (2) 2 3 4 2
Iterations of
rooted at vertex 2 for
Dijkstra's
S
42
T
2
{1, , 3, 4}
VT = {2} ET = ∅
4
{1, 3, }
3
{1, }
1
{ }
VT = {2, 4} ET = {(4, 2)}
VT = {2, 3, 4} ET = {(4, 2), (3, 2)}
VT = {1, 2, 3, 4} ET = {(4, 2), (3, 2), (1, 3)}
algorithm when omputing an SPST
Ge .
the shortest path estimates for all verti es other than the sour e are set to
∞;
the estimate for the sour e is set to 0. The algorithm also maintains a
set
S
of verti es whose nal shortest path osts from the sour e have not
yet been determined. Initially, this set ontains all verti es of
G.
Starting
with the sour e vertex, the algorithm repeatedly sele ts the vertex
u ∈ S
δu . Furthermore, it re-evaluates the shortest path estimates for ea h vertex a ∈ Au ; if δu + w(u, a) < δa , δa is updated to δa = δu + w(u, a), where w(u, a) de nes the weight of edge (u, a). On e a vertex is removed from S , its shortest path ost from the sour e has been found. When the algorithm nishes, δv will be the ost of the shortest path from the sour e to v . The union of the edges (v, pv ) de nes the nal spanning tree T . A naive implementation that examines all nodes in S to 2 nd the minimum has time omplexity O(n ). If binary heaps or Fibona
i heaps [FT87℄ are used, O(m.log(n)) and O(m + n.log(n)) running times an with the minimum shortest path estimate
be a hieved, respe tively. An example helps to better explain the algorithm. The example graph
Ge
of Fig. 3.1 is used again for this purpose. In order to be onsistent with the SPST omputed in Se tion 3.2 using exhaustive sear h, vertex 2 is sele ted as the sour e vertex.
Table 3.4 illustrates the iterations of the algorithm
and the values for the various parameters:
δv , pv , S ,
and
T
( hara terized
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
10
2 5
2
1
1
1 10
4
5
2 5
2
3
4
3
1
10
2
2
3
43
3
4
3
10
2 5
2
3
4
3 3
4
4
4
4
(a) Iteration 0
(b) Iteration 1
( ) Iteration 2
(d) Iteration 3
Figure 3.4: Computation of an SPST for
by
VT
and
ET ).
T
The spanning tree
Ge
using
S
and the value
δv
δv
and
pv
sele ted to be removed
Vertex 2 is extra ted from
δv
in the previous iteration are provided
between parentheses. At iteration 0, the set
δv
v
that made it happen appear in bold. Whenever
is re-evaluated, the values of
1,
algorithm.
at ea h iteration of the algorithm is
illustrated in Fig. 3.4. At ea h iteration, the vertex from
Dijkstra's
S
ontains all verti es in
S , sin e it is the vertex with lowest δv .
Ge .
At iteration
for ea h vertex adja ent to vertex 2 is re-evaluated and, again, the vertex
with lowest
δv
(in this ase vertex 4) is removed from
S;
the edge
(4, 2)
is
T . At iteration 2, δ3 is re-evaluated. The new value found when p3 = 4 (δ3 = 7) is higher than the previous value (δ3 = 5); so, it is not updated. Vertex 3 is removed from S and the edge (3, 2) is added to T . At iteration 3, δ1 is re-evaluated. A shorter path is found if p1 = 3; so, δ1 is updated to 7. Vertex 1 is removed from S and the edge (1, 3) is added to T . The nal spanning tree T is provided in Table 3.4 and shown in Fig. 3.4d. It added to
is onsistent with the SPST found in Se tion 3.2 using the exhaustive sear h approa h.
3.3.2 The The
Algorithm
Bellman-Ford
Bellman-Ford
algorithm [Bel58℄ [FF62℄, by Ri hard Bellman and
Lester Ford, is another lassi al shortest paths algorithm, whi h nds wide appli ation in pra ti e.
It is more generi than
has higher time omplexity
O(n.m),
Dijkstra's
algorithm, but
due to the re-evaluation, at ea h
iteration, of the shortest path estimates asso iated to ea h peer vertex of the sour e vertex. The input graph
algorithm an nd an SPST even when the
G has negative-weight
algorithm. As for attributes:
Bellman-Ford
δv
and
Dijkstra's pv .
edges; this is not possible using
algorithm, for ea h vertex
v,
Dijkstra's
it maintains two
Initially, the shortest path estimates for all verti es
other than the sour e are set to
∞;
the estimate for the sour e is set to 0.
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
44
n − 1 iterations (remember that n stands for the number of verti es in the input graph G), until an SPST or a negative y le is found. At ea h iteration, for ea h edge (u, v) ∈ E , if δu + w(u, v) < δv , where w(u, v) de nes the weight of edge (u, v), δv is updated to δu + w(u, v) and pv is set to u. If, after the n − 1 iterations, there is an edge (u, v) su h that δv > δu + w(u, v), a negative y le has been found and no SPST exists th iteration, an SPST is de ned by the for G. Otherwise, at the (n − 1) set of verti es VT and the union of the edges (v, pv ). Due to its higher time The algorithm goes through
omplexity than
Dijkstra's algorithm, the Bellman-Ford
used only when the input graph
G
algorithm is usually
has negative edge weights. However, in
pra ti e, a distributed variant of the algorithm has been onsidered in wellknown distan e-ve tor routing proto ols, su h as the Routing Information Proto ol (RIP) [Mal98℄, the Border Gateway Proto ol (BGP) [RL95℄, and the Rapid Spanning Tree Proto ol (RSTP) [Gro04℄.
Bellman-Ford algorithm is illustrated usGe , as for Dijkstra's algorithm. Ge is an undire ted
The exe ution of the entralized ing the example graph
Ge an be traversed in any dire tion. In the
omputation of an SPST for Ge using the Bellman-Ford algorithm, we then have E = {(1, 2), (2, 1), (1, 3), (3, 1), (2, 3), (3, 2), (2, 4), (4, 2), (3, 4), (4, 3)}. For graph. Therefore, an edge of
the sake of onsisten y, vertex 2 is sele ted as the sour e vertex. Table 3.5 shows the values for
δv
and
pv
along
n−1
iterations of the algorithm. At
ea h iteration, the shortest path estimate and the parent sele ted for vertex
v
appear in bold. Whenever
δv
is re-evaluated, the values of
δv
and
pv
in the
previous iteration are provided between parentheses. Fig. 3.5 illustrates the
T ; the shortest path estimates appear next to ea h vertex. At iteration 0, every vertex v has δv = ∞, ex ept the sour e vertex. At iteration 1, after onsidering every edge (u, v) ∈ E , the shortest path estimates for verti es 1, 3, and 4 are re-evaluated to δ1 = 10, δ3 = 5, and δ4 = 4. This is due to the edges (2, 1), (2, 3), and (2, 4). The edge (2, 1) leads to δ2 + w(2, 1) < δ1 , so δ1 is updated to 10 and p1 is set to 2. The edge (2, 3) leads to δ2 + w(2, 3) < δ3 , so δ3 is updated to 5 and p3 is set to 2; the same ondition holds for vertex 4. The rest of the edges in E do not lead to any further update at this stage. At iteration 2, the edges (1, 3) and (4, 3) lead to δ3 = 12 and δ3 = 7, respe tively, whi h are higher estimates than 5, the previous value for δ3 . On the other hand, the edge (3, 1) leads to δ3 + w(3, 1) < δ1 , so δ1 is updated to 7 and p1 is set to 3; the rest of the
onstru tion of the spanning tree
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Iteration
v
pv
1 2 3
Iterations of the
SPST rooted at vertex 2 for
VT = {1, 2, 3, 4} ET = {(1, 3), (3, 2), (4, 2)}
Bellman-Ford
algorithm when omputing an
Ge . 7
10
∞ 1
1
10
2 3
4
3
∞
2
10
0 5
2
3
4
4
5
2
5
3
4
5
5
2
3
4
( ) Iteration 2
Figure 3.5: Computation of an SPST for
Ge
5
3
4
4
3
4
4
4
(b) Iteration 1
2
0
3
∞
(a) Iteration 0
1
10
2
0 5
7
1
10
0 2
T
1 ∞ 2 0 3 ∞ 4 ∞ 2 1 10 (∞) 2 0 2 3 5 (∞) 4 4 (∞) 2 1 7 (10) 3 (2) 2 0 3 12, 7 (5) 1, 4 (2) 4 8 (4) 3 (2) 1 7 3 2 3 5 2 4 4 2
0
Table 3.5:
δv
45
using the
4
(d) Iteration 3
Bellman-Ford
algo-
rithm.
edges in
E
do not lead to any improvement in the shortest path estimates.
At iteration 3, no further redu tions in the ost of the paths are possible, and the nal spanning tree using
Dijkstra's
T
is found. It is onsistent with the SPST found
algorithm.
3.4 Minimum Spanning Tree Algorithms This se tion des ribes the two most used MST algorithms.
In data
networks, MST algorithms nd appli ation in multi ast routing proto ols [WC04℄.
Rather than the exhaustive sear h approa h followed in Se tion
3.2, they onsider an expeditious and e ient approa h to nd an MST for
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
1 10 5
2 4
1
1
2
10
3
10
2 5
2
3
4
3 3
1
2 5
2 4
10
3 3
2 5
2 4
3 3
4
4
4
4
(a) Iteration 1
(b) Iteration 2
( ) Iteration 3
(d) Iteration 4
Figure 3.6: Computation of an MST for
an input graph for
46
Dijkstra's
3.4.1
G.
Ge
using
Prim's
algorithm.
Both algorithms are greedy in nature. Nevertheless, as
algorithm, they an always nd the optimal solution.
Prim's
Algorithm
Prim's algorithm [Pri57℄ by Robert Prim is, in onjun tion with Kruskal's algorithm, one of the lassi al greedy algorithms used to ompute an MST for an input graph
G.
Initially,
Prim's
algorithm sele ts an arbitrary vertex
u (initial vertex) as the urrent andidate to make part of the spanning tree T . u is then added to the list of verti es L that in ludes the verti es andidates to make part of the spanning tree T at ea h step of the algorithm; at the beginning, u is the unique element in L. A vertex v in L is hara terized by the weight wv of the edge onne ting v to its andidate parent vertex in T , pv ; the initial vertex has wu = 0 and its andidate parent vertex pu is unde ned, sin e it is the root of the spanning tree T . At ea h step the algorithm works as follows. The vertex v with the lowest weight is removed from L, and de ned as the urrent spanned vertex. Ea h vertex a adja ent to v in G that does not belong yet to T is added to L; v represents the andidate parent vertex in T for ea h vertex a added to L. If a already belongs to L but the weight w(v, a) < wa , wa and the andidate parent vertex pa are updated a
ordingly, i.e., wa = w(v, a) and pa = v . This pro ess is repeated until the n verti es have been added to T . At that stage T de nes an MST, whose edges are de ned by the union of the edges (v, pv ). Prim's algorithm 2 runs in O(nm) in its more naive implementation and in O(n ) time when ensuring that for ea h iteration at most n edges are sear hed; this is guaranteed when G is represented using an adja en y matrix. Yet, if binary heaps in onjun tion with adja en y lists or Fibona
i heaps in onjun tion with adja en y lists are used, the time omplexity an be improved to and
O(m + nlog(n)),
respe tively [WC04℄.
O(mlog(n))
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Iteration 0 1 2 3 4
v
wv
1 0 2 3 4 1 0 2 10 3 2 4 1 0 2 5 (10) 3 2 4 3 1 0 2 4 (5) 3 2 4 3 1 0 2 4 3 2 4 3
Table 3.6: Iterations of
pv
L
{1} 1 1 {1, 2, 3} 3 (1) {2,3, 4} 1 3 4 (3) {2,4} 2 3 4 { 2} 2 3
Prim's
47
T
VT = ∅ ET = ∅
VT = {1} ET = ∅
VT = {1, 3} ET = {(1, 3)}
VT = {1, 3, 4} ET = {(1, 3), (3, 4)}
VT = {1, 2, 3, 4} ET = {(1, 3), (3, 4), (4, 2)}
algorithm when omputing an MST for
In the following, we illustrate the omputation of an MST using algorithm.
Ge
Ge .
Prim's
is used again as the input graph. Vertex 1 is sele ted as the
initial vertex. Table 3.6 provides the values taken in ea h iteration by the parameters onsidered in the algorithm: re-evaluated, the values of
wv
and
pv
wv , pv , L,
and
T.
Whenever
wv
is
in the previous iteration are provided
between parentheses. A snapshot of the spanning tree shown in Fig. 3.6. At iteration 1, vertex 1 (w1
= 0)
T
at ea h iteration is
is removed from
L
and
L. At iteration 2, vertex 3 (the vertex in L with lowest wv ) is removed from L and its adja ent verti es are added to L. Only vertex 4 is added to L, sin e vertex 2 already belongs to it. However, w(3, 2) < w2 , so w2 and p2 are updated to 5 and 3, respe tively. At iteration 3, vertex 4 is the one with lowest ost in L. No further vertex is added to L, sin e vertex 2 already belongs to L and vertex 3 already makes part of T . Still, w(4, 2) < w2 , so w2 and p2 are set to 4. At iteration 4, the only vertex in L (vertex 2) is removed and the nal spanning tree T is its adja ent verti es (2 and 3) are added to
found. It is the same MST found in Se tion 3.2.
CHAPTER 3.
3.4.2
SPANNING TREES AND ALGORITHMS
Kruskal's
Kruskal's
48
Algorithm
algorithm [Kru56℄ by Joseph Kruskal is another well-known
algorithm targeting the same problem. whi h onsists of
The algorithm starts with a forest
n trees, where ea h vertex is initially a separate tree.
After-
wards, the edges in the input graph are sorted by weight in non-de reasing order. At ea h step of the algorithm, the edge is sele ted. If verti es
u
and
v
(u, v)
with the lowest weight
belong to two dierent trees, the two trees
are ombined into a single tree. If the sele ted edge onne ts verti es whi h belong to the same tree the edge is reje ted and not examined again, as it would produ e a y le. While running the algorithm, less and bigger trees are a hieved until a single tree is found, an MST; the algorithm nishes when either all verti es have been spanned or all edges have been pro essed. Sorting the edges in non-de reasing order takes
O(m.log(m))
time.
de nes the asymptoti running time of the algorithm. In pra ti e,
This
Kruskal's
algorithm has been implemented using priority queues, whose elements are the edges of the graph. The appli ation of the algorithm to the example graph
Ge
is now illus-
trated. Table 3.7 shows the iterations of the algorithm. The edges of
Ge
are
sorted in non-de reasing order. At ea h iteration, the edge with the lowest weight is sele ted to make part of
T.
At the third iteration, all verti es have
been spanned. Therefore, the remaining edges are ignored and the algorithm nishes. Fig. 3.6b, Fig. 3.6 , and Fig. 3.6d illustrate the spanning tree ea h iteration of
Kruskal's
T
at
algorithm.
3.5 Minimum Routing Cost Spanning Tree Algorithms The omputation of an MRCST is known to be an NP-hard problem [WC04℄. A problem is NP-hard if an algorithm for solving it an be translated into one for solving any NP-problem (non-deterministi polynomial time) problem.
NP-hard therefore means at least as hard as any NP-problem.
In turn, an NP-problem is a problem that an only be solved by exhaustive sear h, in the worst ase.
Exhaustive sear h is impra ti al for omputing
an MRCST, even for small input graphs. Thereby, approximation MRCST algorithms have been designed. These algorithms allow the omputation of a spanning tree for an input graph
G
su h that the ost of the path between
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Iteration
(u, v)
(1, 3)
1
(3, 4) (2, 4) (2, 3) (1, 2)
2
(3, 4) (2, 4) (2, 3) (1, 2)
w(u, v)
3
(2, 4) (2, 3) (1, 2)
Table 3.7: Iterations of
2 3 4 5 10 3 4 5 10 4 5 10
Kruskal's
49
T
VT = {1, 3} ET = {(1, 3)}
VT = {1, 3, 4} ET = {(1, 3), (3, 4)}
VT = {1, 2, 3, 4} ET = {(1, 3), (3, 4), (2, 4)}
algorithm when omputing an MST for
Ge . any two verti es in
G
is minimized. In data networks, MRCST algorithms
nd appli ation in bridged Ethernet networks, for instan e, as we shall see in Chapter 5. This se tion presents two approximation MRCST algorithms based on
Prim's
and
Dijkstra's
algorithms, and it brie y refers to a set of better
approximation MRCST algorithms.
3.5.1 The The version
Add
algorithm
Add algorithm [Gro05b℄ by Vi Grout represents a vertex oriented of Prim's algorithm. It onsiders that the way to approximate an
MRCST for ning tree
T.
G
is by minimizing the number of relay nodes in the nal span-
The
Add
algorithm ignores the edge weights and onsiders as
the de ision riterion the degree of the verti es in
G.
A spanning relay (a
vertex with more than one adja ent edge) is hosen initially as the vertex of highest degree to start the onstru tion of the spanning tree
T.
Next, all its
adja ent edges as well as the adja ent verti es are sele ted to make part of
T.
From the verti es urrently spanned, a new spanning relay is sele ted, adja ent to the maximum number of unspanned verti es; when a tie exists, the new spanning relay is arbitrarily sele ted, among the verti es with the same maximum number of adja ent unspanned verti es. The pro ess is repeated
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
Spanning Tree Routing Cost a 20 b 20
20 d 20 e f
Spanning Tree Routing Cost a 104 b 104
100 d 96 e 100
18 18
g h
50
20 20
(b)
(a) Table 3.8: Routing ost for ea h spanning tree omputed (a) from the unweighted version of
Ge
and (b) from
until all verti es belong to
T.
Ga .
If an adja ent edge of the urrent spanning
T,
the edge is reje ted. At the end,
Add
algorithm is not an exa t greedy
relay onne ts two verti es already in
T
is the approximate MRCST. The
algorithm, as it does not provide the optimal number of relays, in general [Gro05b℄; nonetheless, it performs well in pra ti e. The in
O(n.log(n))
Add
algorithm runs
time in the worst ase. Still, usually, it runs faster due to the
tenden y for many nodes to be added to
T
at ea h iteration.
An example helps to better explain the algorithm. Consider the example graph
Ge .
Firstly, an initial spanning relay is sele ted. Either vertex 2 or
vertex 3 an be sele ted as the initial vertex, given that both have degree equal to 3. Vertex 2 is sele ted here and its adja ent edges (2, 1), (2, 3), and (2, 4), as well as its adja ent verti es 1, 3, and 4 are added to
T.
Given that
at this stage all verti es have already been spanned, the algorithm nishes. In this ase, a single iteration was su ient to ompute the spanning tree. Sin e this algorithm ignores edge weights, it annot be used to ompute an approximate MRCST for a weighted input graph, su h as order to ompare the spanning tree omputed using the
Add
Ge .
Yet, in
algorithm with
the MRCST that ould be found using exhaustive sear h, we onsider a version of
Ge
where all the edges have weight equal to 1, named
G′e .
The
eight spanning trees shown in Fig. 3.3 still represent the possible spanning trees for tree.
G′e .
In Table 3.8a we provide the routing ost for ea h spanning
Either spanning tree (e) or spanning tree (f ) de ne an MRCST for
G′e . Spanning tree (e) is pre isely the spanning tree found using the
Add
algorithm; spanning tree (f ) would be found if vertex 3 was sele ted as the
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
initial vertex.
In this ase, due to the small size of the input graph, the
Add
51
algorithm ould nd the exa t MRCST. In general, however, it only
provides an approximate MRCST. In what follows, we use a more omplex input graph to illustrate su h a ase. Consider the unweighted example graph
Ga an be found L(Ga ) is de ned by: 3 −1 −1 1 0 0 L(Ga ) = 0 0 −1 0 −1 0 0 0
spanning trees for Se tion 3.2,
using
Ga
of Fig. 3.7a. The number of
Kir hho's
theorem. As shown in
0 0 −1 −1 0 0 0 0 0 0 1 −1 0 0 0 −1 3 0 −1 −1 0 0 2 0 −1 0 −1 0 2 0 0 −1 −1 0 2
After removing the last row and the last olumn from
L(Ga ),
for example,
∗ we obtain matrix L (Ga ):
3 −1 0 0 −1 −1 −1 1 0 0 0 0 0 0 1 −1 0 0 L∗ (Ga ) = 0 0 −1 3 0 −1 −1 0 0 0 2 0 −1 0 0 −1 0 2 |L
∗ (G )| is equal to 5. Therefore, ve spanning trees an be omputed for a
Ga
(see Fig. 3.8). Table 3.8b provides the routing ost for ea h spanning tree. Spanning tree (d) de nes the MRCST of
Ga .
The
Add
algorithm an be
used to obtain an approximate MRCST. Figs. 3.7b3.7e show the spanning
T at ea h iteration of the algorithm. Either vertex 1 or vertex 4, with d1 = d4 = 3, an be sele ted as the initial spanning relay; vertex 1 is hosen.
tree
Edges (1, 2), (1, 5), and (1, 6), and verti es 2, 5, and 6 (adja ent to vertex 1) are added to
T.
From the verti es already spanned at this iteration, vertex
5 and vertex 6, with
dv = 1,
are andidates to be the new spanning relay.
Vertex 5 is sele ted and edge (5, 7) and vertex 7 are added to
T.
Afterwards,
there are again two andidates to be the new spanning relay: vertex 6 and vertex 7. Vertex 7 is pi ked up and edge (7, 4) and vertex 4 are added to
T.
At this iteration, vertex 4 is sele ted as spanning relay, sin e vertex 6 has
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
1
2
5
1
2
4
3
7
3
7
4
(b) 1
2
5
1
2
4
7
3
4
7
(e)
Unweighted example graph
Add
5
6
(d)
obtained using the
7
( )
6
3
5
6
4
(a)
Figure 3.7:
1
2
6
6
3
5
52
Ga
and an approximate MRCST
algorithm.
no adja ent unspanned verti es. Edge (4, 3) and vertex 3 are added
omplete the reation of the spanning tree. In this ase, the
Add
T
to
algorithm
provided an approximate MRCST with routing ost 104, whi h is higher than 96, the routing ost of the MRCST (see Table 3.8b).
3.5.2
Wong's
algorithm
Rather than the
Add
algorithm,
Wong's
algorithm by Ri hard Wong
[Won80℄ is able to ompute an approximate MRCST for a weighted input graph
G.
Also, it has asymptoti guaranteed performan e.
It is a
2-approximation algorithm, whi h means that the resulting spanning tree has at most two times the routing ost of the exa t MRCST. rithm is on eptually simple.
It de nes (1) the omputation of
ea h one rooted at a dierent vertex su h as
Dijkstra's
Wong's n
algo-
SPSTs,
v ∈ G, using a shortest paths algorithm
algorithm, and (2) the al ulation of the routing ost for
ea h SPST. The SPST with lowest routing ost is then sele ted as the 2approximate MRCST. Still,
omplexity than the
Add
Wong's
algorithm has signi antly higher time
algorithm. If
Dijkstra's
algorithm is used to om-
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
1
2
5
1
2
1
2
6
6
3
5
4
3
7
(a) Cr (T1 ) = 104
7
3
(b) Cr (T2 ) = 104 5
4
1
2
5
6
4
3
7
(d) Cr (T4 ) = 96
4
7
(e) Cr (T5 ) = 100
Figure 3.8: Spanning trees omputed from
pute the SPSTs, its time omplexity is we use the example graphs
7
( ) Cr (T3 ) = 100
6
3
5
6
4
1
2
53
Ge
and
Ga
Ga .
O(n2 .log(n) + m.n).
In the following,
of Fig. 3.1 and Fig. 3.7a respe tively,
as a basis to demonstrate two examples of appli ation of the algorithm. We start by onsidering
Ge
as the input graph.
Ge
has four verti es,
Dijkstra's algorithm ould be used for Wong's algorithm, we do not illustrate the
so four SPSTs have to be omputed; that. Sin e our fo us here is on
omputation of ea h SPST. The spanning tree of Fig 3.3f represents the SPST rooted at vertex 1 and, simultaneously, the SPST rooted at vertex 3. The SPSTs rooted at verti es 2 and 4 are de ned by the spanning trees of Fig. 3.3h and Fig. 3.3b, respe tively. The routing ost asso iated to ea h
Wong's
SPST is provided in Table 3.3.
algorithm sele ts the SPST with the
lowest routing ost. Any SPST but the SPST rooted at vertex 2 de nes the approximate MRCST. In this ase, the approximate MRCST is the exa t MRCST. The appli ation of
Wong's
algorithm to
Ga
(Fig.
3.7a) requires more
omputation. Seven SPSTs and their orresponding routing osts have to be
omputed. The SPSTs rooted at verti es 1, 2, and 5 are equal and de ned by the spanning tree of Fig.
3.8e.
The SPSTs rooted at verti es 3 and 4
are de ned by the spanning tree of Fig. 3.8 . The SPST rooted at vertex 6 and the SPST rooted at vertex 7 are shown in Fig. 3.8d and Fig. 3.8b,
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
54
SPST Routing Cost 1 100 2 100 3 100 4 100 5 100 6 96 7 104 Table 3.9: Routing ost for ea h SPST omputed for
Ga
and the routing
ost of the SPST sele ted as the MRCST (in bold).
respe tively.
Table 3.9 provides the routing osts for ea h SPST; the root
vertex of the SPST de nes its identi er in the table. The SPST rooted at vertex 6 is the spanning tree with the lowest routing ost. So, it is sele ted as the approximate MRCST. Interestingly, also in this ase, the approximate MRCST de nes the exa t MRCST.
3.5.3 Better Approximation Algorithms Better approximation MRCST algorithms have been proposed in the literature, with guaranteed asymptoti performan e. In [WC04℄, 15/8- approximation and 3/2-approximation algorithms running in time
1
respe tively, have been proposed .
In addition, Wu
O(n3 ) and O(n4 ),
et al.
+
[W 99℄ have
demonstrated that to nd an MRCST for a given weighted graph is equivalent to solving the same problem in a omplete graph in whi h edge weights satisfy the triangle inequality (see de nition in Se tion 3.2), i.e., a omplete metri graph. For metri graphs they have proposed the Polynomial Time Approximation S heme (PTAS) for nding an (1+ε)-approximate MRCST in time
2
O(n2⌈ ε ⌉−2 ),
with
MRCST an be omputed graph
G,
rstly
G
ε ∈ ]0, 1]. Using this s heme 2 in time O(n ). However, for a
a 2-approximate non-metri input
has to be onverted into its metri losure. The metri
losure of a graph
G = (V, E, w) is de ned as = (V, V × w′ (i, j) is equal path between i and j in G; to better illustrate
the omplete metri graph
G′
to the ost of the shortest
Fig. 3.9 the metri losure of the example graph
Ge .
V, w′ ) su h that
1
the on ept, we provide in The metri losure an
An α-approximation algorithm omputes an approximate MRCST whose routing ost is, at most, α times higher than the exa t MRCST.
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
55
1 7
2 5
2 5
4
3 3
4 Figure 3.9: Metri losure of the example graph
be found in time
O(n2 log(n) + mn)
using
Dijkstra's
Ge .
algorithm. After this
onversion, an approximate MRCST an be omputed using the PTAS; with PTAS a 2-approximate MRCST an be found in time
O(n2 ).
Finally, the
′ approximate MRCST found for G an be transformed into a spanning tree for
G
in time
O(n3 ),
using the algorithm presented in [WC04℄. This leads
to an overall time omplexity
O(n3 )
[WC04℄ for omputing a 2-approximate
MRCST, onsidering a non-metri input graph. For metri graphs, PTAS is the urrent fastest known 2-approximation algorithm.
In pra ti e, however, non-metri input graphs are ommon, as
it frequently happens that the dire t path between two adja ent verti es is longer than some indire t path between them. For non-metri input graphs, the three-step methodology des ribed in the previous paragraph has to be used to ompute the approximate MRCST. In su h ases,
Wong's
algo-
rithm runs faster than the PTAS when it omes to the omputation of a 2-approximate MRCST. While the solutions mentioned in this se tion provide better approximations to the MRCST problem, this is a hieved at a ost of higher time
omplexities. In pra ti e, the use of simpler algorithms may be preferable, namely when the omputation of the spanning tree has to be as fast as possible, as it happens in a network routing proto ol, for instan e.
3.6 Summary In this hapter we rst looked into some fundamental on epts in graph theory, namely the on epts of graph, tree, and spanning tree, and de ned three ost fun tions for a tree
T:
the ost of a path in
T,
the total ost of
CHAPTER 3.
T , and
SPANNING TREES AND ALGORITHMS
the routing ost of
T.
56
The minimization of these ost fun tions leads
to the de nition of three spanning trees: the Shortest Paths Spanning Tree (SPST), the Minimum Spanning Tree (MST), and the Minimum Routing Cost Spanning Tree (MRCST). These spanning trees are related to ea h other. The MRCST is a generalization of the SPST and oin ides with the latter when a single sour e is assumed in the MRCST problem. other hand, for a SPST rooted at a vertex
v ∈V,
On the
the MST and the MRCST
onverge to the same spanning tree as the heterogeneity of the input graph
G
in reases. The omputation of an SPST, MST, or MRCST is, in general,
unfeasible using exhaustive sear h. E ient algorithms for omputing ea h type of spanning tree were presented.
Bellman-Ford algorithm were dis ussed; both an nd the optimal solution. While the BellmanFord algorithm has higher time omplexity than Dijkstra's algorithm, its For nding an SPST,
Dijkstra's
algorithm and the
distributed variant nds wide appli ation in network routing proto ols, su h as RIP, BGP, and RSTP.
Dijkstra's
algorithm is also widely employed by
routers running routing proto ols, su h as Open Shortest Path First (OSPF) [Moy98℄ and Optimized Link State Routing (OLSR) [CJ03℄, to nd the optimal uni ast paths towards their peers within a network.
Prim's
and
Kruskal's
algorithms were presented as the algorithms usu-
ally employed to nd an MST. Although they have dierent time omplex-
Prim's algorithm has lower time Still, Kruskal's algorithm implementa-
ities, both provide the optimal solution.
omplexity if properly implemented.
tion is simpler and has similar time omplexity for sparse input graphs, i.e., input graphs where nodes have degree
Θ(1).
MST algorithms nd appli a-
tion namely in multi ast routing proto ols. Finally, we fo used on algorithms to ompute an MRCST. Given the NP-hardness of the problem, various approximation algorithms have been designed. We presented two algorithms whi h are based on
jkstra's
algorithms the
Add
algorithm and
Wong's
Prim's
and
Di-
algorithm. The former
an only be used for unweighted graphs while the latter is generi . Their time
omplexities are also dierent. The have any guaranteed performan e.
Add algorithm runs faster, but does not Wong's algorithm requires more time to
nd the nal spanning tree, but ensures that the approximate MRCST has routing ost at most 2 times the routing ost of the exa t MRCST. Better approximation MRCST algorithms were brie y mentioned. Nonetheless, to
CHAPTER 3.
SPANNING TREES AND ALGORITHMS
57
have better performan e they require higher omputation time. As su h, in pra ti e, the
Add
algorithm and
Wong's
algorithm may be a better hoi e.
At the end of this hapter, the reader must bear in mind the on epts of graph, tree, spanning tree, and ost of a path, as well as the three spanning trees de ned (SPST, MST, and MRCST) and the algorithms that an be used to ompute them. These on epts will be important to understand the remaining hapters.
Chapter 4
Network Auto- on guration The proper operation of any network implies a set of on guration pro edures that ensure network-wide onne tivity and, when needed, its inter onne tion with the outside world. This in ludes the on guration of network paths and the assignment of addresses to network devi es, as well as the proper on guration of the peripheral nodes a ting as gateways between the
urrent network and neighbor networks. Manual on gurations may be hard, or even unfeasible, time- onsuming, error-prone, and be ome a te hnologi al barrier from the viewpoint of end-users. Therefore, they are not seen as a solution in pra ti e. This applies in parti ular to the two types of networks addressed in this thesis. In PANs, nodes shall self-organize to form the network and enable its onne tion to the Internet without user on guration eorts.
In Stub WMNs, wireless a
ess points shall self-organize to auto-
mati ally form the mesh and enable bidire tional onne tivity between the wired infrastru ture and the wireless terminals atta hing to the Stub WMN. In this hapter we present the state of the art on network auto- on guration of PANs and Stub WMNs. Before des ribing the PAN and Stub WMN spe i network auto- on guration solutions, we go through the solutions available for Ethernet networks, IP networks, and underlay
1
networks in
general. At the end of the hapter we summarize the main hara teristi s of ea h solution and dis uss their limitations. Along the hapter the terms station and terminal are used with the same meaning. 1
Underlay here means under IP and above Layer-2, i.e., Layer-2.5.
59
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
60
4.1 Chara terization Approa h Throughout this hapter the hara terization of ea h solution is made using a set of riteria that mat h the problem and the obje tives listed in Chapter 1. The following riteria are taken into a
ount:
•
support of multiple Layer-2 te hnologies;
•
network layer proto ols supported;
•
uni ast and broad ast path auto- on guration approa h;
•
support of a
ess to external networks;
•
support of lega y nodes;
•
dual-sta k IP auto- on guration approa h;
•
omplexity.
In the des ription of ea h solution a riterion is dis ussed only if appli able. The riteria here enumerated are onsidered either expli itly or impli itly; at the end of the hapter we make their values lear for ea h solution.
4.2 Ethernet Networks In bridged Ethernet networks (from now on simply alled Ethernet networks), upon onne ting the Ethernet able, end-terminals get onne tivity immediately and do not require any on guration sin e transparent bridging is adopted.
However, the bridges used to inter onne t dierent Ethernet
physi al links do require on gurations. The paths towards other nodes onne ted to the network have to be on gured at ea h bridge, so that pa kets are orre tly forwarded. This onsists in the on guration of pairs (destination address, lo al network interfa e). Upon re eiving a pa ket with a given destination address, using su h information, the bridge knows the lo al port through whi h it must forward the pa ket. In prin iple, this set of on gurations ould be a
omplished manually. Manual on gurations would have to be performed at ea h bridge to establish the ommuni ation paths within the network. This may be time- onsuming, error-prone, or even unfeasible. Suppose that every time a terminal atta hes to an Ethernet network the network administrator had to go to ea h bridge and on gure manually the
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
61
paths towards that spe i terminal. Sin e everything would be done manually, this pro ess would have to be repeated for ea h new terminal atta hed to the network. Moreover, every time a network topology hange o
urred, it ould be the ase that paths had to be re on gured. This would lead to large delays both for terminal initial atta hment and path re on gurations. In order to over ome these drawba ks, a set of solutions was developed to make it possible to auto- on gure paths within an Ethernet network. In the next se tions we refer to the prominent auto- on guration solutions in this ontext, starting by the very rst solution proposed, whi h is still the basis for today's Ethernet networks operation. Next, we refer to more re ent solutions proposing enhan ements to the urrent solution for path auto- on guration in Ethernet networks.
4.2.1 Learning Bridges With the in reasing importan e of LANs in the eighties and the limited apa ity of a single shared physi al link [Ba 98℄, bridges were proposed as the solution to extend LANs for supporting a higher number of stations
onne ted to multiple LAN segments.
In order to avoid modi ations to
stations, bridges should make the extended LAN appear as if it was omposed of a single link, from a logi al point of view. Taking this requirement into a
ount, the Transparent Bridge was proposed by Hawe
et al.
[HKS84℄.
Transparent Bridges, also alled Learning Bridges, are able to run without any manual intervention.
By analyzing all data frames passing through,
Learning Bridges learn automati ally the paths towards every station atta hed to the network. However, this solution requires that the underlying physi al network topology de nes a tree (loop-free) [Per85℄; otherwise, the automati learning of the paths to the stations does not work and frames would be forwarded inde nitely. The learning me hanism works as follows.
Upon re eiving a frame a
Learning Bridge analyzes the sour e MAC address of the frame and nds out the lo al port (network interfa e) through whi h the frame was re eived. If su h information is not yet available lo ally, the bridge stores it in a forwarding table whose entries are formed by the tuple (destination address, lo al port, lifetime). sour e station.
In this way, the bridge learns the path towards su h
Thus, when a frame destined to that address is re eived
at the bridge, it already knows the path.
Sin e stations may deta h from
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
Dst MAC
Port
Lifetime (s)
STA1
2
30
62
1 Dst MAC
Port
Lifetime (s)
STA1
1
30
2 BR2
frame
2 1 BR1 3
STA1
1 Dst MAC
STA1
Port
1
2
Lifetime (s)
30
BR3
Figure 4.1: Illustration of the learning bridge me hanism, with the station STA1 transmitting a frame for the rst time and bridges BR1 , BR2 , and BR3 learning the path to STA1 automati ally.
the network, forwarding table entries have a lifetime.
In urrent Ethernet
networks the typi al value is 30 se onds. When this lifetime expires the entry is removed. If an entry orresponding to the frame sour e address already exists in the lo al forwarding table, and the table indi ates this address was last seen on a dierent bridge port, then the port number for the entry is modi ed a
ordingly.
If the information is the same, only the lifetime of
the entry is reset. The learning me hanism is illustrated in Fig. 4.1. In this example, it is assumed that station STA1 transmits a frame for the rst time and the bridges have no forwarding table entries yet.
When BR1 re eives
the frame it reates a new entry (with the default lifetime) in its forwarding table. The new entry states that the path to STA1 is through lo al port 1. At this stage, BR1 does not know the path to the destination, so the frame is forwarded to ports 2 and 3, a
ording to the forwarding algorithm explained in the next paragraph. Based on the re eived frame, bridges BR2 and BR3
reate a new forwarding table entry too, in luding the information shown in Fig. 4.1. At this point, the three bridges have learned the path to STA1 . Upon paths to the stations have been auto- on gured by means of the learning algorithm, the forwarding algorithm an operate based on the forwarding table onstru ted by the former. If there is a forwarding table entry, the frame will be transmitted on the port spe i ed in that entry unless it is the in oming port; otherwise, the frame will be forward to every lo al port, ex ept the port the frame was re eived from. Regarding broad ast tra ,
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
63
the same a tive spanning tree is used to forward frames to every node atta hed to the network. Upon re eiving a broad ast frame, ea h bridge simply forwards it through every lo al port, ex ept the port the frame was re eived from.
By using this me hanism, the frame an be re eived by every node
atta hed to the network in an e ient way; one frame per link is transmitted. While Learning Bridges represented a revolution by the time they were deployed, they had the limitation of requiring a loop-free underlying topology. This pre luded any support of redundan y and was subje t to humanerrors when deploying the network, due to the possible formation of loops when plugging a able into the wrong pla e. There was then a need to deploy a solution that, while keeping the simpli ity of the learning bridge algorithm, was able to over ome the need to always have a physi al loop-free topology. For that purpose, Radia Perlman proposed an algorithm [Per85℄ to enable arbitrary physi al topologies.
By running that algorithm, whi h does not
require any pre- on guration, bridges are able to ompute a spanning tree on top of whi h the learning algorithm an run safely. In this way, physi al loops in the underlying topology do not bring up any problem. Perlman's algorithm deals with that and eliminates them; the a tive topology will always be a tree, as required. On the other hand, topology hanges and link or bridge failures are automati ally addressed by this algorithm. So, Perlman's algorithm enables automati and dynami on guration of an a tive tree network topology while ensuring redundan y.
4.2.2 IEEE 802.1D Bridges IEEE 802.1D bridges [Gro04℄ are an evolution from Learning Bridges. They inherited the learning algorithm from Learning Bridges and in orporated the original Perlman's algorithm in the Spanning Tree Proto ol (STP). STP was initially used to automati ally on gure the a tive network topology.
Still, due to its slow onvergen e, whi h an take 30 to around 50
se onds, if default values are onsidered, an evolution to a new spanning tree proto ol was onsidered. The Rapid Spanning Tree Proto ol (RSTP), an improved and faster version of the STP, has been proposed and in luded in the latest version of the standard.
STP and RSTP are similar and the
latter interoperates with former [Gro04℄. Yet, RSTP enables faster re on guration of the spanning tree de ning the a tive topology. Here, only RSTP is des ribed in detail.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
64
RSTP omputes a spanning tree in a distributed manner by means of Bridge Proto ol Data Units (BPDUs), also alled
Hello
messages, whi h are
periodi ally sent out by ea h bridge. The rst step in RSTP is the ele tion of a root bridge. The bridge with the lowest priority value is ele ted as the root; the priority value may be the default one (32768) or manually assigned by the network administrator. When there is more than one bridge with the same priority value, the bridge with the lowest MAC address is ele ted as root. The root ele tion is performed based on the BPDUs sent by ea h bridge. Initially, ea h bridge ele ts itself as the root bridge and in ludes its own priority and MAC address in the BPDUs it sends out. Every time a BPDU with lower priority value, or with the same priority value but lower MAC address, is re eived, these two parameters are updated in the subsequent BPDUs. In this way, the bridge with the lowest priority is ultimately ele ted as the root bridge. Afterwards, ea h bridge sele ts a lo al port to get onne ted to the ele ted root bridge; this is alled the root port. The root port is the lo al port enabling the lowest path ost to the root bridge (see de nition in Chapter 3); the lowest path ost to the root bridge known by ea h bridge is in luded in the BPDUs it sends out. Within ea h link, the bridge sending the BPDU with the lowest path ost is ele ted as the designated bridge; if there is more than one bridge announ ing the same path ost, the one with the lowest priority value is ele ted. The designated bridge for ea h link is the bridge a ting as gateway towards the root bridge.
Finally, the bridges set their
root and designated ports to forwarding state and a tree a tive topology rooted at the ele ted root bridge is established. The spanning tree reated is a Shortest Path Spanning Tree (SPST) from the root bridge perspe tive (see the SPST de nition in Chapter 3). Fig. 4.2 illustrates the RSTP operation for a bridged Ethernet network with four IEEE 802.1D bridges.
In this example, we assume that (1) the
bridges have the default priority assigned and (2) all links have the same
ost.
The bridge with the lowest MAC address is BR1 , so it is ele ted as
the root bridge. BR2 is ele ted as the designated bridge for the link between BR2 and BR4 , sin e BR2 is the bridge enabling the lowest path ost to the root bridge. The a tive spanning tree topology is represented with bold lines; the same tree in luding the link between BR3 and BR4 instead of the link between BR2 and BR4 would be another possibility. The periodi
Hello
messages enable the dete tion of topology hanges.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
Priority: 32768 MAC address: 1
BR1
D BP
Priority: 32768 MAC address: 2
65
U
BR2
Priority: 32768 MAC address: 3
Priority: 32768 MAC address: 4
BR3 designated port root port BR4
Figure 4.2: Illustration of the RSTP operation in a bridged Ethernet network in luding four IEEE 802.1D bridges, with the tree a tive topology represented in bold.
After three hello times without re eiving any BPDU from a neighbor, a bridge assumes that it has lost the onne tion with that neighbor. By default, the hello timer is set to 2 se onds.
This means that, in the worst
ase, a bridge will only dete t a topology hange after 6 se onds.
When
a topology hange happens, the information stored in the forwarding table may be ome invalid. As su h, in order to forward frames to the orre t stations, bridges need to learn the new paths. In RSTP, a bridge that dete ts a topology hange sends out a BPDU with the Topology Change (TC) ag set through all its ports and ushes its forwarding table entries immediately. Every bridge that re eives a BPDU with the TC ag set, ushes its own table entries and relays the BPDU to other bridges through all ports, ex ept the one it re eived the BPDU from. After the link failure is dete ted, the re on guration will usually take less than 1 se ond [Sof09℄. Upon being aware of the topology hange, bridges try to hange their new root and designated ports to forwarding state as fast as possible. This is performed using a hopby-hop agreement/proposal handshake me hanism, whi h avoids loops and enables onsistent assignment of port roles a ross the network. The bridge dete ting a failure of its root port starts the re on guration pro edure and
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
66
immediately hanges its designated ports to dis arding state. Afterwards, it sele ts the port enabling the lowest path ost to the root to be the new
Proposal BPDU on all its designated ports. A neighbor bridge re eiving the Proposal on a designated port does not hange its
on guration. A bridge re eiving the Proposal on its previous root port
root port and sends a
immediately pla es its designated ports into dis arding state, sele ts the root port and puts it in forwarding state, and responds with an BPDU. Upon re eiving the
Agreement
BPDU, the
Proposal
Agreement
BPDU sender
hanges the orresponding port to forwarding state. This pro edure is repeated hop-by-hop along the network for ea h bridge willing to hange a lo al port to forwarding state, until the new a tive topology is formed. An illustrative example of the RSTP re on guration pro edure an be found in [Sof09℄. RSTP keeps Perlman's algorithm advantages and enables fast topology re on guration, namely in omparison with the original STP proto ol. However, the faster re on guration is only appli able when IEEE 802.1D bridges are inter onne ted using point-to-point links; for shared links the large STP re on guration times hold (30 to 50 se onds). Additionally, unless there is some manual pre- on guration of the priorities assigned to ea h bridge, the root bridge will be arbitrarily sele ted. This leads to the establishment of an arbitrary SPST as the a tive network topology. In pra ti e, the arbitrary SPST does not de ne the best solution for minimizing the average path ost within the network, whi h is de ned by the Minimum Routing Cost Spanning Tree (MRCST), as shown in Chapter 3.
On the other hand, RSTP
has well-known problems [ECE07℄, su h as ount-to-in nity and forwarding loops, when dealing with topology hanges. This may lead to onvergen e times of up to 6 se onds [Sof09℄.
4.2.3 Solutions enabling non-single spanning tree Proposals for improving the performan e of Ethernet networks have been made. They mostly fo us on over oming the need to use a single spanning tree as the a tive network topology. In the following we refer to the most relevant solutions proposed in this ontext.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
67
Multiple Spanning Tree Proto ol The Multiple Spanning Tree Proto ol (MSTP), now integrating the IEEE 802.1Q standard [Gro06a℄, aims at being used in Ethernet networks in whi h Virtual LANs (VLANs) are onsidered. When using RSTP, all VLANs are mapped into a single a tive spanning tree. With MSTP, links blo ked for a given VLAN an be used for other VLANs, sin e it is possible to de ne a unique a tive spanning tree for ea h VLAN or for a set of VLANs. Broad ast tra is managed per VLAN; thereby, the spanning tree sele ted for a given VLAN will also be used as the means to deliver broad ast frames. While this solution ontributes to a better use of the available resour es (i.e., physi al links), it is only useful if VLANs are a requirement.
On the other hand,
MSTP introdu es more omplexity when ompared to the traditional solution using a single spanning tree instan e. Bridges need to handle multiple spanning tree instan es, whi h are managed by running an RSTP instan e per spanning tree instan e, and manual intervention is required to on gure the mapping between VLANs and the various spanning tree instan es.
Shortest Path Bridging Shortest Path Bridging [Sof09℄ (also known as Provider Link State Bridging [ASBF08℄) is urrently being de ned by the IEEE 802.1aq Working
2
Group (WG) . This solution de nes the omputation of shortest paths within a bridged Ethernet network for uni ast tra ; for broad ast tra no information is available. For that purpose, it de nes the use of one Shortest Path Spanning Tree (SPST) instan e per bridge. In order to establish the SPSTs, where
n
n
represents the number of bridges belonging to the network,
a link state routing approa h is followed; urrently, the IS-IS [Sof09℄ link state routing proto ol is used. Through the routing proto ol, bridges learn the network topology and are able to ompute lo ally their SPST instan e using, for example,
Dijkstra's algorithm (see Chapter 3).
The lo ation of the
stations is learnt using a me hanism similar to the original learning bridge me hanism.
If there is no forwarding information available, the frame is
sent to all bridges. The bridge the nal destination station is atta hed to will eventually deliver the frame. When a frame from the destination station omes in the opposite dire tion, the sour e bridge impli itly learns its 2
http://www.ieee802.org/1/pages/802.1aq.html
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
68
lo ation. This standard targets the use of bridging in ore, provider networks, where links with bandwidths of tens of Gbit/s or more are being used. In these s enarios, the de nition of a single spanning tree approa h may in fa t represent a resour e wastage. Also, the use of a routing approa h results in faster onvergen e, when topology hanges o
ur.
Nevertheless, the addi-
tional omplexity introdu ed when ompared to the original single spanning tree solution, the need to use MAC-in-MAC en apsulation for frame transportation within the network, and the possible establishment of asymmetri paths, whi h may ompromise the me hanism employed for learning the stations' lo ation, are major disadvantages of this solution [Sof09℄.
RBridges +
RBridges [P 10℄ are urrently being spe i ed within the Transparent Inter onne tion of Lots of Links (TRILL) working group
3 as another solution
enabling shortest path ommuni ation within a bridged Ethernet network. RBridges onsider a hybrid routing approa h mixing together Layer-2 and Layer-3 forwarding on epts.
In order to learn the addresses of lo al sta-
tions, ea h RBridge uses the lega y learning me hanism. On the other hand, a link-state routing proto ol
4 is run among RBridges to ex hange information
about (1) the lo al stations atta hed to ea h RBridge and (2) the paths available between the RBridges. Based on this information, RBridges ompute shortest paths for uni ast tra and al ulate distribution trees for delivering tra to unknown destination stations or to ope with broad ast tra , using
Dijkstra's
algorithm. Although a single distribution tree was su ient
to deal with broad ast tra , RBridges onsider the omputation of multiple distribution trees for two reasons. Firstly, it enables multi-pathing for multidestination frames. Se ondly, it guarantees the sele tion of shorter paths for broad ast tra and for uni ast tra sent a ross a distribution tree when the destination is unknown; this redu es out-of-order delivery when the uni ast shortest path is eventually used. Ea h RBridge advertises in the routing proto ol messages the maximum number of distribution trees it is able to
ompute and the number of trees it wants all RBridges in the network to
ompute (default value is 1). 3 4
The a tual number of distribution trees to
http://www.ietf.org/dyn/wg/ harter/trill- harter.html Currently, an extension of IS-IS routing proto ol is used as the routing proto ol.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
69
5
be on gured is set by the RBridge with the highest priority value , also advertised in the routing proto ol messages. This number is not higher than the maximum number of trees supported by the less apable RBridge. The distribution trees are omputed by ea h RBridge based on the link state information, where ea h distribution tree is an SPST rooted at a sele ted RBridge. The establishment of shortest paths among RBridges for uni ast tra forwarding, the auto- on guration of distribution trees for broad ast, and the use of a routing approa h enabling faster onvergen e times represent the main advantages of RBridges. Still, this is a hieved at the ost of more
omplexity and further overhead. RBridges introdu e more omplexity for broad ast, due to the omputation of multiple distribution trees, whi h however do not guarantee shortest paths. Moreover, RBridges need to expli itly ex hange information about the lo ation of stations and disseminate all the learnt stations' addresses whether they are being used or not. It may happen that the stations' addresses disseminated to a given RBridge will never be used be ause no stations atta hed to that RBridge will ommuni ate with those destinations; this introdu es unne essary overhead and omplexity. Finally, RBridges may still require manual on gurations for setting the values for some parameters, su h as the number of distribution trees to be
omputed.
Other Solutions Other solutions similar to those presented in this se tion an be found in [Sof09℄. As stated above, their major disadvantage is that they are more omplex than the auto- on guration solution de ned for standard IEEE 802.1D bridges, whose simpli ity has been one of the reasons for the su
ess Ethernet networks have a hieved. There is a trade-o between the inherent additional
omplexity and the performan e improvement brought up by these solutions. As su h, their use has to be assessed taking into a
ount the spe i s enario being addressed. 5
This is a 16-bit unsigned integer.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
70
4.3 IP Networks While in Ethernet networks the auto- on guration problem is limited to path auto- on guration, in IP networks it has a broader s ope. Apart from path auto- on guration (in this ontext alled route auto- on guration), IP addresses and other optional information, su h as DNS server address and default gateway address, have to be on gured at ea h IP node parti ipating in the network. Upon an IP address and optional information is on gured, a terminal has IP onne tivity. Con erning IP routers, other on gurations are required. Routers are nodes whose task is to forward pa kets ba k and forth between the IP subnetworks they are onne ted to. In order to enable
onne tivity between network sour es and destinations, they have to learn the routes between endpoints. This onsists in on guring pairs of the form (destination address, next hop) at ea h network router, so that upon re eiving a pa ket with a given destination address ea h router knows the next hop in the route towards the destination. If performed manually, these on gurations are in pra ti e umbersome, time- onsuming, and error-prone, as mentioned in Se tion 4.2 for bridges. In addition, they represent a te hnologi al barrier from end-users standpoint, namely when it omes to the
on guration of IP terminals. Consider, for instan e, the example of a terminal onne ting to an IP network. The on guration of IP addresses and additional information would imply that either end-users needed to manually
on gure their nodes to get network onne tivity, or network administrators needed to on gure every omputer on the network manually. Several solutions have been proposed for IP network auto- on guration. In this se tion we go through the major IP routing proto ols enabling route auto- on guration, with fo us on wireless networks, and we present the IP address and optional information auto- on guration me hanisms proposed for IPv4, IPv6, and both.
4.3.1 Routing Proto ols A myriad of IP routing proto ols has been de ned.
Examples are the
Routing Information Proto ol (RIP) [Mal98℄ and Open Shortest Path First (OSPF) proto ol [Moy98℄, used in ampus-wide and enterprise-wide wired IP networks. In the last de ade and a half, a new set of routing proto ols has been proposed targeting wireless ad-ho networking s enarios. This is
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
71
the set we will fo us on. Wireless ad-ho routing proto ols an be lassi ed in two main ategories: rea tive and proa tive.
In this se tion we present
a set of representative routing proto ols falling in these two ategories. In these proto ols nodes are assumed to a t as both routers and terminals. The reader is referred to the survey paper by Abolhasan
et al.
[AWD04℄ regarding
further ad-ho routing proto ols.
Dynami Sour e Routing The Dynami Sour e Routing (DSR) proto ol [JHM07℄ is a rea tive proto ol based on sour e routing. This means that it is up to the sour e node to inform intermediate nodes about the route towards the destination. This is performed by in luding in ea h pa ket the list of intermediate nodes the pa ket shall pass through towards the nal destination. nds the route to a destination
D
A sour e node
S
using the following pro edure. Upon re-
eiving a data pa ket from the upper layer, and if there is no route available for
D
in the lo al route a he,
Request,
S
queues the data pa ket and issues a
whi h is sent to the IP broad ast address. A
Route Request
Route iden-
ti es the sour e and the destination of the message and in ludes a unique
request id
set by the sour e. At ea h moment, this message in ludes a list
of the addresses of the nodes already traversed; the list is empty when the message is issued at the sour e.
If the urrent node is the destination
Route Reply to S with a opy of the Route Request. If it is an intermediate
D,
it sends ba k a
list of addresses in-
luded in the
node whi h already
Route Reply to S Route Request plus the
has a route a hed for the target destination, it sends a with a opy of the list of addresses in luded in the
list of a hed addresses spe ifying the route from the urrent node to the destination. Otherwise, the urrent node inserts its own address in the list
Route Request and retransmits it. If the urrent node has re ently re eived a Route Request with the same request id, or its address is already listed in the message, the Route Request is dis arded. In pra ti e,
in luded in the
this leads to the establishment of a route between to the route taken by the rst
Route Request
S
D D.
and
rea hing
that orresponds In order to send
Route Reply, D sear hes in its lo al route a he for a possible route to S . If found, that route is used to forward the Route Reply. Otherwise, D simply reverses the order of addresses in luded in the Route Request re eived to send the Route Reply towards S . When S re eives the Route Reply, it ba k the
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
(id=1;[2])
2
3 ( id
2 [3,
,3]
)
])
)
;[2
[2 1;
=1
=1
[3,2] ([2,3])
=
(id
[2 ](
) , 3]
(id
72
[3, 2] (
1 ( id
[2, 3])
4
= 1)
5
6 (id=1;[5])
(i
d=
,6 [5 1;
])
Route Request Route Reply Figure 4.3:
Illustration of the DSR Route Dis overy pro edure, with the
route between Node 1 and Node 4 in bold.
reates a new route a he entry with the list of addresses needed to rea h
D
and dequeues the data pa kets waiting to be transmitted. The entire DSR route dis overy pro edure is illustrated in Fig. 4.3 for the establishment of a route between Node 1 and Node 4, depi ted in bold. The
Route Request and Route Reply ) are shown Route Reply the list of addresses used in the
ontents of the DSR messages ( between parentheses. For the
sour e routing of the message along the route towards Node 1 is depi ted.
Route Reply to Node 3, sin e it the orresponding Route Request was the rst to arrive at Route Request messages re eived with the same request id
In the example of Fig. 4.3, Node 4 sends a is assumed that Node 4; further
are silently dis arded (this happens at Node 4 and Node 6). After route establishment, DSR nodes arry out a pro edure. In the
Route Maintenan e
Route Maintenan e
pro edure, ea h DSR node is respon-
sible for ensuring that the next hop in the route re eives a data pa ket in transit. The on rmation of re eption may be performed impli itly or expli itly.
Impli it on rmation may be enabled using either the underlying
MAC on rmations, su h as the ACK messages in IEEE 802.11, or a passive a knowledgment approa h, whi h onsists in overhearing the pa ket when it
DSR A knowledgement sent by the urrent node upon re eiving a DSR A knowledgement Request from the previous node in the route. To redu e overhead,
is retransmitted by the next hop. Expli it on rmation onsists in a
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
73
DSR a knowledgement per data pa ket. Within a given period of time, a single DSR A knowledgement is enough to a DSR node may avoid requesting a
on rm that the link is still on; the DSR spe i ation does not de ne any value for this parameter. If no on rmation is re eived, after the maximum
DSR A knowledgement Request retries, the urrent node returns a Route Error to the sour e of the data pa ket, informing it about the broken
number of
link. In its basi form, ea h DSR node maintains the following set of data stru tures:
the Route Ca he, the Route Request Table, the Maintenan e
Buer, and the Send Buer.
The Send Buer is a queue ontaining the
pa kets waiting to be forwarded while a route is being dis overed.
The
Maintenan e Buer stores the pa kets sent by the urrent node awaiting
on rmation from the next hop; pa kets are added to the Maintenan e buer after the rst transmission attempt is made and removed as soon as the
on rmation is re eived.
The Route Request Table is used by ea h node
to keep tra k of the Route Request messages re ently listened to; based on this information ea h node is able to drop any dupli ate
Route Request
messages.
The Route Ca he stores the routes learned by the node upon
re eiving a
Route Request, a Route Reply, or a data pa ket.
DSR de nes a solution for inter onne ting a DSR ad-ho network to an external network, e.g., the Internet; however, no on rete solution is de ned for supporting lega y nodes. A DSR node may a t as the gateway between the ad-ho network and the external network. Upon re eiving a
quest, a DSR gateway sends a Route Reply
Route Re-
to the sour e; the riterion used
Route Request is than one Route Reply
by the gateway for de iding whether or not to reply to a not de ned [JHM07℄. The sour e may re eive more
message, from the gateway and from the destination node, if it belongs to the DSR network. In the latter ase, the sour e will onsider the reply re eived dire tly from the destination. Otherwise, the route towards the gateway will be used, sin e the destination is assumed to be outside the DSR network. In spite of enabling (1) load balan ing and multi-path, due to the possibility of storing more than one route for a given destination, (2) rapid rea tion to a route failure, thanks to the immediate use of an alternative route, and (3) passive a knowledgment to keep tra k of the a tiveness of the links along a route, whi h avoids periodi other proto ols, DSR has some disadvantages.
Hello
messages de ned by
The in lusion of the DSR
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
74
Options header in every pa ket may represent onsiderable overhead and leads to a redu tion of the payload size. On the other hand, DSR requires that ea h node stores information lo ally about the omplete route to be followed by ea h pa ket, bringing up more memory omplexity. In addition, DSR requires pa ket overhearing or link layer feedba k to enable passive a knowledgment. Passive a knowledgment based on pa ket overhearing is only possible for single-te hnology DSR networks and, in pra ti e, feedba k from link layer for impli it on rmation of pa ket re eption is unavailable [CB02℄. So, the expli it on rmation me hanism may be the only means available. Finally, sour e routing may in fa t be redundant, sin e intermediate nodes
reate and/or refresh their lo al route a he as DSR pa kets are re eived.
Ad-ho On-demand Distan e Ve tor Routing +
The Ad-ho On-demand Distan e Ve tor (AODV) [P 03℄ proto ol is a rea tive routing proto ol inspired on DSR. The route dis overy me hanism is
S
similar to that de ned by DSR.
broad asts a
Route Request
in luding the
sour e and target addresses, a sequen e number that uniquely identi es the request, a destination sequen e number, whi h is used by intermediate nodes to know whether they have fresh enough information to reply on behalf of the destination, and a Time-To-Live (TTL) value, whi h ontrols the maximum number of hops the message an traverse.
Route Request
An AODV node re eiving the
for the rst time reates a new routing table entry for
S
or
updates an existing entry with the fresh routing information. If the urrent node has re ently re eived the
Route Request,
or the TTL value is 0, the
message is silently dis arded. If the urrent node is the nal destination or an intermediate node whi h has a route to routing table, it sends ba k to
S
in rements the Hop Count eld
D,
D,
after updating the lo al
Route Reply ; otherwise, the urrent node in the Route Request and retransmits the
a
Route Reply is then forwarded ba k to S along the route taken Route Request. Ea h intermediate node is able to forward the
message. The by the rst
Route Reply based on the routing table entries reated while pro essing the Route Request. Note that in this ase the routing proto ol messages do not
in lude any route information and pa kets are forwarded hop-by-hop based on the routing state installed at ea h hop. No overhead is introdu ed in ea h data pa ket subsequently sent. The route dis overy me hanism illustrated in Fig. 4.3 for DSR is the me hanism used by AODV, if we ex lude the list
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
of addresses in the
Route Request
and
Route Reply
75
messages.
Regarding route maintenan e, AODV de nes that ea h node involved in an a tive route shall send out periodi ally a
Hello
message through all lo al
network interfa es involved in a tive routes. By default, one
Hello is sent per
se ond per a tive network interfa e. Theoreti ally, link layer feedba k ould be used instead. Still, as stated for DSR, this is not available in pra ti e. After three
Hello intervals, if the urrent node did not re eive any Hello from
the next node in the route towards
D,
it assumes that the link has failed.
The urrent node may then de ide to make a lo al repair by issuing a
Request without
Route
D. If a Route Reply is re eived, the route is re-established involving S . Otherwise, the urrent node sends a Route Error to its towards
pre ursors, whi h in turn forward the
Route Error
to their own pre ursors
6 until eventually the message rea hes S . After re eiving the Route Error, S triggers a new route dis overy to nd a new path to
D.
Besides the data stru tures maintained by DSR, AODV maintains the Pre ursor List and the Neighbors List, whi h are used for route maintenan e purposes. The Pre ursor List stores information about the nodes that must be noti ed when a link failure is dete ted, while the Neighbor List ontains the set of a tive neighbors. The Neighbor List is periodi ally he ked and if the lifetime of a given element has expired, the orresponding link is assumed to be broken and all lo al routing table entries for whi h that neighbor is used as the next hop are set invalid. AODV provides the means to enable the inter onne tion of an AODV network with external networks.
AODV nodes interfa ing with external
networks a t as gateways between the AODV network and the external networks.
From the AODV viewpoint, this means that the gateways have to
a t as proxies for the external networks. Every time a
Route Request
is is-
sued for an IP address belonging to an external network, the gateway replies on behalf of the true destination. This makes the onne tion of an AODV network to the Internet feasible; for that purpose, the gateway would have to be on gured to reply to the default route 0.0.0.0/0. However, in AODV no me hanism is spe i ed to enable (1) the auto- on guration of the nodes a ting as gateways and (2) the auto- on guration of the set of addresses ea h gateway will be replying for. The external networks or nodes to whi h the AODV network is onne ted have to be added manually at ea h gateway. 6
A pre ursor node is a neighbor of the urrent node sitting behind it in a route.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
AODV over omes some of the DSR problems.
76
It avoids the overhead
in every single pa ket and enables lo al route repair. Lo al route repair is however enabled at the ost of more omplexity. On the other hand, AODV is simpler than DSR sin e it does not store multiple routes to the same destination; it simply stores the shortest route, whi h is usually enough in pra ti e. This simpli es the routing table management and redu es its size. AODV still has the same disadvantage as DSR. The route established during the route dis overy pro edure is that traversed by the rea hes the destination rst. route (see below).
Route Request
that
This does not guarantee the use of the best
The lo al route repair is spe i ed with the purpose of
redu ing the number of pa kets dropped while the route is being repaired. The lo al route repair avoids pa ket dropping, sin e data pa kets are queued in the node doing the route repair while the The travel time for a
Route Error
Route Error travels to the sour e.
towards the sour e is three or more orders
of magnitude lower than the time required to dete t the route failure. As su h, the amount of pa kets possibly dropped as the
Route Error
travels to
the sour e is negligible when ompared to the number of pa kets dropped while the route failure is not dete ted. So, in pra ti e, the lo al route repair does not bring any signi ant gains. It may be preferable to have the sour e doing the route repair immediately.
AODV using Data Rate Metri The route dis overy pro edure used by AODV does not ensure the establishment of the shortest route. The rst route is not guaranteed to be
omposed of the best links [JPSS04℄. The main reason for this is that the rst route to be found is essentially the result of a random pro ess. The simultaneous retransmission of
Route Request
messages by neighbor nodes
during a route dis overy may result in pa ket ollisions in the wireless media where they an o
ur; this is the usual ase for the wireless te hnologies presented in Chapter 2. The ollision of
Route Request
messages at intermediate
nodes may lead to a situation where the destination fails to re eive some or even all
Route Request
messages [CDA08℄.
is re ommended that the retransmission of
To over ome this problem, it
Route Request
messages at ea h
intermediate node is randomly delayed [CDA08℄. Although this solves the pa ket ollision problem, it has impa t on the quality of the route found. The introdu tion of random delays at ea h intermediate node implies that
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
77
(1)
2 ) (1
0) (2
) (0
3
(1 1)
(10)
(0 )
1
4 (0 )
) (0
(2 )
1) (1
(1)
5
) (2
6 (1)
Route Request Route Reply Figure 4.4: Illustration of the AODV-DR Route Dis overy pro edure and the established route (in bold).
the rst
Route Request
to rea h the destination is not ne essarily the one
traveling a ross the fastest links. The authors in [JPSS04℄ proposed a modi ation to AODV to a tually nd the shortest route; hereafter this solution is alled AODV-DR. For that purpose, they de ne the use of a Data Rate metri . The route ontaining the set of links with the highest data rates is sele ted.
This implies the
following modi ations to the original proto ol. At ea h intermediate node, the ost of traversing a link is onsidered to be equal to the inverse of the link data rate.
Upon re eiving a
Route Request
the urrent node adds to
the ost in the message the ost due to the link between itself and the node from whi h it re eived the the
Route Request
Route Request.
This pro ess is repeated until
rea hes the destination. The proto ol is further modi ed
in order to (1) allow intermediate nodes to forward more than one
Request
Route
Route Reply messages, (2) allow the destination to a
ept more than one Route Request, and (3) allow the sour e to a
ept more than one Route Reply, if it leads to the establishment of a better route. In [JPSS04℄ and
the authors showed by simulation the performan e gains of AODV-DR. Fig.
4.4 illustrates the AODV-DR route dis overy pro edure, when a
route between Node 1 and Node 4 is established; the value next to ea h edge represents its ost and the value next to ea h
Reply
Route Request
or
Route
message represents the ost of the route (CR) towards the sender of
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
78
the message. In order to dis over the route to Node 4, Node 1 broad asts a
Route Request
with
CR = 0.
This message is re eived by Node 2 and Node 5;
Request. Node 3 re eives the Route Request from Node 2, while Node 6 gets two Route Request messages,
after updating
CR, both rebroad ast the Route
one from Node 2 and one from Node 5.
After updating
CR,
Node 3 and
Route Request messages re eived; in this example, Node 6 rebroad asts rst the Route Request re eived from Node 5. Like in Fig. 4.3, the Route Request traveling through the route {1, 2, 3, 4} is the rst to arrive at Node 4. Sin e Node 4 is the destination of the Route Request it sends ba k a Route Reply. This message goes through the same route followed by the Route Request, and a route with CR = 21 is rst found by Node 1. When Node 4 re eives the Route Request from Node 6 it realizes that a better route an be established, so it sends a new Route Reply via Node 6. Ultimately, the Route Reply arrives at Node 1 and a route with CR = 3 is established instead; the additional Route Request re eived from Node 6 rebroad ast the
Node 6 is silently dis arded, as it does not lead to a better route (12
> 3).
The nal established route is depi ted in bold in Fig. 4.3. The main disadvantage of AODV-DR is that the route dis overy pro edure may generate a signi ant amount of overhead, due to the multiple
Route Request
and
Route Reply
messages that may be retransmitted by in-
termediate nodes. For this reason, in [JPSS04℄ the authors de ne that the number of
Route Request
and
Route Reply
mediate nodes may be limited.
messages forwarded by inter-
However, there is a trade-o between the
maximum number of messages retransmitted and the quality of the route found. If the maximum number of messages retransmitted is too low, just a few alternative routes will be explored and the sele ted route may be suboptimal. So, the optimal route is only guaranteed to be found when there are no limitations in the number of retransmitted messages.
AODVjr The AODVjr routing proto ol [CB02℄ is a simpli ed version of the original AODV proto ol. In AODVjr only the destination replies to a
Route Request ;
this means that the Pre ursor List and the Neighbors List are not needed. Also, sin e in AODV the destination only replies to the rst re eived, AODVjr does not onsider any expli it metri . the need for a metri eld in the
Route Request
and
Route Request
This eliminates
Route Reply
messages
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
79
as well as in the Routing Table maintained by ea h node. Finally, when it
omes to route maintenan e, AODVjr eliminates the
Route Error
and
Hello
messages. Route maintenan e is performed dire tly between the endpoints of a route. This involves a new message, alled
Conne t, whi h is sent out by
the destination periodi ally to inform the sour e that the route is still alive. However, this is only required if data tra is unidire tional.
Regarding
bidire tional ommuni ation, the data pa kets ex hanged ba k and forth keep the route alive. If a route failure o
urs, the sour e is able to dete t it by the absen e of pa kets from the destination, either data pa kets or
Conne t
messages. This triggers a new route dis overy. Despite being simpler than AODV, AODVjr keeps the same major problem as the original proto ol: the rst route may not be the shortest route.
Dynami MANET On-demand Routing
7 On-demand (DYMO) routing proto ol [CP10℄ is
The Dynami MANET
another rea tive routing proto ol ombining the DSR, AODV, and AODVjr approa hes. The route dis overy me hanism is equal to that used by DSR. The
Route Request
traveling from the sour e to the destination a
umulates
the addresses of the set of nodes traversed.
Route a
umulation enables
Route Request and for ea h intermediate node previously traversed by the Route Request ; the same happens with the Route Reply sent ba k to the sour e, whi h a
umulates the ea h node to install routing state for the sour e of the
addresses in the opposite dire tion. In this way, using a single route dis overy multiple routes an be found. DYMO de nes an optional eld the
Route Request
and
Distan e
in
Route Reply messages that an be used to in orporate
any routing metri . If this eld is absent, DYMO behaves similarly to AODV, i.e., the rst route found is used; otherwise, the shortest route, in terms of the sele ted routing metri , is found.
Note that if a Data Rate metri
is used, DYMO works as AODV-DR, leaving aside the route a
umulation enabled by DYMO. When it omes to route maintenan e, as AODVjr, DYMO does not de ne the use of a Pre ursor List for route repair. In addition, it spe i es the use
+
of the NeighborHood Dis overy Proto ol (NHDP) [C 10℄, a generi proto ol
8 for
proposed within the ontext of the IETF MANET Work Group (WG) 7 8
Mobile Ad-ho NETwork http://datatra ker.ietf.org/wg/manet/ harter
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
80
neighborhood dis overy. The NHDP enables the monitoring of the links with the urrent node's neighbors, stores the information about the set of a tive neighbors in a database and makes it a
essible to other proto ols, namely ad-ho routing proto ols. The monitoring me hanism is based on the usual periodi ex hange of
Hello
messages. On the other hand, in DYMO, when
a route failure o
urs, ea h ae ted node is in harge of repairing the route by itself; no lo al route repair me hanism is de ned. DYMO supports the onne tion of a DYMO network to the Internet through a node alled Internet DYMO router (IDR). The IDR is responsible for replying to route requests for IP addresses within the Internet as well as to dis over routes to nodes within the DYMO network on behalf of nodes lo ated in the Internet. Upon re eiving a pa ket from the Internet, the IDR issues a
Route Request
for the orresponding destination address, if it does
not know a route yet. When a DYMO node wants to send a pa ket to the Internet, it employs the usual route dis overy pro edure. The
Route Request
for the destination address in the Internet will eventually rea h the IDR; the other DYMO nodes will simply forward the message sin e they will not be able to send a
Route Reply.
The DYMO spe i ation imposes that all
DYMO nodes running behind the IDR shall be asso iated to the same IP pre x. So, ea h time the IDR re eives a
Route Request
for an address that
does have su h pre x, it knows that it must reply on behalf of some node lo ated in the Internet. In spite of (1) simplifying the original AODV route repair pro edure, (2) de ning route a
umulation to nd multiple routes with a single route dis overy, and (3) enabling the use of any routing metri , DYMO has some weak points. Route a
umulation has the disadvantage of in reasing ontrol message size. Also, the dis overy of multiple routes during the route dis overy is useless if the routes are not used while in the Routing Table. This is the
ommon ase for ad-ho networks, su h as PANs, where at most only a small subset of nodes is envisioned to be ommuni ating simultaneously and most probably the multiple routes dis overed will not be used. So, the additional
omplexity added to the
Route Request
and
Route Reply
messages may be
worthless. When using an expli it routing metri , signi ant overhead may be introdu ed in the route dis overy pro ess, as mentioned for AODV-DR; the urrent DYMO spe i ation does not de ne any limitation on the number of
Route Request
and
Route Reply
messages that may be forwarded by
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
81
intermediate nodes. Finally, the use of the NHDP proto ol makes DYMO a less e ient proto ol when ompared to AODV. While in AODV only the nodes involved in a tive routes send out
Hello
messages, in NHDP
Hello
messages are sent out by every single node, whether it is a tively involved in a route or not.
Destination-Sequen ed Distan e Ve tor The Destination-Sequen ed Distan e Ve tor (DSDV) [PB94℄ is a proa tive proto ol based on the
Bellman-Ford
algorithm (see Chapter 3). DSDV
is mainly inspired on RIP [Mal98℄, a traditional distan e ve tor proto ol used in wired networks. Ea h DSDV node maintains an up to date Routing Table ontaining routes towards all the other nodes. Ea h routing table entry in ludes the destination address, the number of hops required to rea h the destination (hop ount), and a sequen e number set by the destination. For enabling the onstru tion of omplete routing tables, ea h node periodi ally broad asts routing table updates to its neighbors; initially the Routing Table has a single entry orresponding to a route to the node itself, whose hop ount is 0. Upon re eiving a routing table update from a neighbor, the
urrent node in rements the hop ount for ea h route entry in luded in the routing update. Afterwards, it updates the lo al routing table entries if the re eived routing information leads to a fresher or shorter route, or it adds them to its lo al Routing Table if they do not exist yet. A fresher route is identi ed if the re eived routing entry has a sequen e number higher than the sequen e number of the routing entry lo ally stored. If one or more entries are being added to the Routing Table, the urrent node advertises its table immediately to its neighbors; otherwise, the node does it in the next period.
This pro ess is repeated until eventually all nodes be ome aware
of the shortest routes.
Pa ket forwarding is then performed a
ording to
the routing tables proa tively onstru ted. So, when a route is needed, it is immediately available; no delay is introdu ed for route dis overy. DSDV maintains three tables: the Forwarding Routing Table, the Advertised Routing Table, and the Settling Time Table. The Forwarding Routing Table is used for pa ket forwarding. The Advertised Routing Table ontains the routing table entries announ ed to the neighbors.
The Settling Time
Table is used for preventing route u tuations and redu ing overhead.
It
may happen that a given node re eives, for instan e, two updates for a given
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
82
destination in two onse utive update periods. Consider that both updates
ome with the same sequen e number. If the update with higher hop ount is re eived rst, two in remental updates will be issued to inform the neighbors about the same route; this auses route u tuations and additional overhead. To avoid the problem, DSDV nodes delay advertisement of routes for whi h a better metri is envisioned to be re eived soon. The Settling Time Table stores the average settling time for ea h destination; the advertisement delay is set to twi e this value. DSDV an also be employed for a
essing external networks, e.g., the Internet. In that setup, the DSDV node onne ted to the external network appears in the routing tables of the other nodes as a default gateway. In this way, every time a pa ket is destined to a lo ally unknown destination, the
urrent node forwards it to the DSDV gateway. This impli itly enables the
onne tion of lega y nodes or networks running behind some DSDV node. Consider, for example, a lega y node onne ted to a DSDV node with two network interfa es.
One of the DSDV network interfa es an be used for
onne ting to the peer DSDV nodes and the other to onne t to the lega y node. As long as the DSDV node forwards pa kets between its two interfa es, the lega y node is able to a
ess the Internet without expli itly parti ipating in the DSDV network. Nevertheless, in DSDV, no me hanism is spe i ed to announ e the default gateway within the DSDV network. DSDV provides routes immediately when they are needed, metri s other than hop ount an be onsidered, it uses in remental routing updates for redu ing signaling overhead, and it solves the well-known routing loop problem [PB94℄ by introdu ing the use of sequen e numbers for routing table entries. Its main disadvantages are (1) the size of DSDV ontrol messages, whi h in reases linearly with the number of nodes parti ipating in the network, (2) the ex hange of all possible routes, whi h may be useless if just a few routes are used, (3) its slow onvergen e, due to both the possible delayed advertisement of routes and the dependen y on periodi routing updates for having routing tables up to date after a link breakage, whi h usually takes multiple update periods, and (4) the management of unstable routes, whi h introdu es further omplexity.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
83
Optimized Link State Routing The Optimized Link State Routing (OLSR) proto ol [CJ03℄ is another proa tive proto ol.
In OLSR, instead of ex hanging routing tables, nodes
inform ea h other periodi ally about the links maintained with its neighbors. Using this information ea h node is able to reate the same topology graph.
Dijkstra's
algorithm is then applied to the topology graph to ompute a
Shortest Path Spanning Tree (SPST) rooted at the urrent node (see Chapter 3).
The SPST provides the required information to build the forwarding
table, whi h is re omputed every time the topology graph hanges. OLSR itself does not forward pa kets. Rather, it lls in the routing table sitting in the data plane, a
ording to the SPST found. OLSR operates based on two
ontrol messages: the
Hello
Hello message and the Topology Control (TC) message.
messages are used in the advertisement/dis overy of the 1-hop and 2-
hop neighbors, and impli itly for dete ting link failures. used by ea h node to notify the other While
Hello
n−1
messages are
nodes about its neighborhood.
messages are only advertised to neighbors,
broad ast throughout the network.
TC TC
messages are
Both are sent out periodi ally, whi h
enables ea h node to be up to date with respe t to the network topology. Traditional link-state proto ols, su h as OSPF [Moy98℄, use pure ooding to distribute topology updates.
OLSR proposes an optimization based on
the ele tion of Multi-Point Relays (MPRs). MPRs are the only nodes that forward
TC
messages.
Ea h node sele ts its own set of MPRs among its
1-hop neighbors. The MPR sele tion is based on the information gathered from the
Hello
messages; the MPRs sele ted by a given node are announ ed
through these messages too.
An MPR sele tion algorithm is spe i ed in
[CJ03℄. It works as follows. Based on the information extra ted from
Hello
messages the urrent node reates two sets: the 1-hop Neighbor Set (N ) and the 2-hop Neighbor Set (N 2). node
x ∈ N . D(x)
D(x) for ea h of x, ex ept the
It then omputes the degree
is de ned as the number of neighbors
urrent node and any node whi h is neighbor of
x
and of the urrent node
simultaneously. The rst nodes to be sele ted as MPRs are those neighbors that are the only means to rea h one or more 2-hop neighbors.
They are
then added to the MPR set and the 2-hop neighbors overed by a node in the MPR set are removed from
R(x) for to N 2 that
al ulates the rea hability neighbors of
x
belonging
N 2.
N 2 is not empty, the urrent node ea h x ∈ N , de ned as the number of If
are not neighbors of the urrent node;
CHAPTER 4.
1
NETWORK AUTO-CONFIGURATION
2
3
5
1
4
84
2
5
3
4
(a)
(b)
Figure 4.5: Illustration of the MPR sele tion for two example input graphs, where the nodes sele ted as MPRs are depi ted in bold.
the node with the highest the same
R(x),
R(x)
is added to the MPR set or, if all have
the node with the highest
D(x)
is onsidered.
neighbors overed by the new sele ted MPR are removed from pro ess is repeated until
N2
The 2-hop
N 2.
This
is empty.
Fig. 4.5 illustrates the MPRs sele ted for two example networks using this MPR sele tion algorithm. In Fig. 4.5a we show a sparse network, where the nodes sele ted as MPRs are depi ted in bold. All nodes were sele ted as MPRs; Node 1 sele ted nodes 2 and 3 as its MPRs, Node 2 sele ted 1 and 5, Node 3 sele ted 1 and 4, Node 4 sele ted 3 and 5, and Node 5 sele ted nodes 2 and 4. This means that pure ooding is used and the ele tion of MPRs has no ee t. Fig. 4.5b illustrates a dense network and the MPR set after applying the MPR sele tion algorithm. Only Node 2 was sele ted as MPR. These two examples stress one important issue: the use of MPRs does not always lead to a solution better than pure ooding. Their use is bene ial for dense networks, as stated in [CJ03℄, but they may be of no help for sparse networks. OLSR maintains the following data stru tures:
the Multiple Interfa e
Asso iation Table, the Link Table, the Neighbor Table, the 2-hop Neighbor Table, the MPR Table, the MPR Sele tor Table, and the Topology Information Table.
In OLSR, one IP address is used as the main address for
uniquely identifying ea h node.
The Multiple Interfa e Asso iation Table
ontains a set of entries mapping network interfa e addresses into the main addresses of the nodes; this table is only maintained by ea h node if one or more multi-interfa e nodes parti ipate in the network.
The Link Table
stores a set of tuples asso iating a lo al interfa e address with an interfa e address of a neighbor. This de nes a set of links whose endpoints are the
urrent node and ea h of its neighbors. The Neighbor Table lists the set of
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
85
neighbors of the urrent node, identi ed by their main addresses. Together the Link Table and the Neighbor Table de ne the 1-hop neighborhood of a node.
The 2-hop Neighbor Table stores the set of 2-hop neighbors identi-
ed by their main addresses. The MPR Table spe i es the list of neighbors sele ted as MPRs of the urrent node.
The MPR Sele tor Table in ludes
tuples identifying the set of neighbors that have sele ted the urrent node as their MPR. Finally, the Topology Information Table stores the network topology. OLSR provides the means to integrate lega y nodes and networks with an OLSR network. OLSR nodes with non-OLSR interfa es inje t external routing information in the OLSR network. The inje tion of routing information in the non-OLSR nodes is out of s ope for OLSR; other routing proto ol or manual on gurations have to be used [CJ03℄. Ea h node having non-OLSR interfa es issues, periodi ally, a sage. The
Host and Network Asso iation (HNA)
mes-
HNA arries the required information for installing routes at ea h
OLSR node towards the external nodes or networks. Furthermore, ea h node maintains an additional table, the Host and Network Asso iation Information Table, whi h mat hes the external IP addresses, or IP pre xes, with the OLSR node a ting as the gateway for that external node or network. In this way it is possible, for example, to use an OLSR network to extend an infrastru ture providing a
ess to the Internet. In that ase, the OLSR node
onne ted to the infrastru ture simply advertises an
HNA message with the
IP address 0.0.0.0 asso iated to its own IP address. This informs the other OLSR nodes about the default gateway. OLSRv2 [CDJ10℄, still in draft form, keeps the fundamental prin iples of OLSR. The dieren es are related to the more exible signaling framework and the simpli ation of the ontrol messages ex hanged. For instan e, the
HNA message is no more used and the TC
message is de ned for arrying the
host and network asso iation information too. In addition, the neighborhood monitoring is performed by the NHDP proto ol. This is due to the urrent eort in the IETF MANET WG to de ne a ommon signaling framework for the routing proto ols under standardization, namely DYMO and OLSRv2. OLSR is not limited to the (default) hop ount metri [RBK10℄. Another advantage is that OLSR is a pure ontrol-plane solution. This is in ontrast to what happens with most of the routing proto ols aforementioned, whi h
annot dire tly use the routing table sitting in the data plane in urrent
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
86
systems. In addition, routes are immediately available when needed and the use of MPRs may enable more e ient diusion of information throughout a network. However, as illustrated in the two examples showed in Fig. 4.5, the use of MPRs is bene ial as far as dense networks are onsidered, but almost useless for sparse networks, where they may just bring up unne essary omplexity. Also, in OLSR ea h node has to maintain several tables, whi h makes it more omplex than DSDV or the rea tive proto ols aforementioned; for an OLSR network where one or more nodes have multiple network interfa es and some of these interfa es are onne ted to external nodes or networks, ea h node has to maintain 8 tables. This makes OLSR memory and pro essing demanding and, overall, a omplex solution. Finally, as referred to for DSDV, OLSR proa tively keeps routes between any pair of nodes independently of those routes being needed or not; this may be a waste of bandwidth, memory spa e, and pro essing time.
4.3.2 IP Auto- on guration Me hanisms This se tion des ribes the ommon me hanisms for IP address and optional information auto- on guration regarding IPv4 and IPv6, the trialand-error me hanism urrently used by dual-sta k nodes, the solutions oping with auto- on guration in IP multi-hop networks, and the proposals for dealing with IPv4 and IPv6 auto- on guration simultaneously.
Dynami Con guration of IPv4 Link-Lo al Addresses The dynami auto- on guration of IPv4 link-lo al addresses (DynLL)
9
[CAG05℄ was deployed by the IETF Zero onf Work Group . Multiple OSs, su h as Windows XP/7 and Linux, already implement it as an alternative solution to DHCP. DynLL de nes how a host an automati ally on gure an IPv4 address within the 169.254/16 pre x being valid for ommuni ation with other nodes in the same link.
First, the host generates a random IP
address in the 169.254/16 range. Next, it performs Dupli ate Address Dete tion (DAD) by sending out multiple (usually three) gratuitous address resolution proto ol (
ARP REQUEST )
messages [Plu82℄, in order to assess
whether the address is already in use; if a reply is re eived, the address is being used by other terminal and a new address must be tried. 9
http://www.zero onf.org
Finally,
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
87
the host assigns the IP address to the lo al network interfa e, and link-lo al
onne tivity be omes possible.
IPv6 Stateless Auto- on guration The IPv6 Stateless Auto- on guration (SLAC) solution [TN07℄ de nes the steps arried out by a host to auto- on gure its network interfa es in IPv6, without using a entralized servi e.
The auto- on guration pro ess
omprises the generation of a link lo al and a global address, and a DAD pro edure.
(NS)
The DAD pro edure is performed using
Neighbor Soli itation
messages of the Neighbor Dis overy Proto ol (NDP) [NNSS07℄, in or-
der to verify the uniqueness of the tentative address; if a reply is re eived a
Neighbor Advertisement (NA)
message the tentative address must be
onsidered to be in use by other node and it annot be on gured. Before sending out the NS message, the host must join the soli ited-node multi ast address of the tentative address, omputed as a fun tion of the tentative address, so that it is able to dete t the presen e of a peer using the address [TN07℄. This is performed by sending out multiple Multi ast Listener Dis overy (MLD) Report messages [VC04℄. The auto- on guration of a link-lo al address is arried out upon network interfa e a tivation, and after ombining the well-known pre x FE80::0/10 with the interfa e identi er (ID), based on the MAC address. The on guration of a global address is a
omplished by
ombining the pre x announ ed by a lo al router, using the
tisement (RA)
Router Adver-
messages de ned in [NNSS07℄, with the interfa e ID. Still,
this is only a
omplished if the M ag in luded in the
RA message
is ina -
tive; otherwise, the host is supposed to use DHCPv6 (see below). The
RA
message also in ludes a so- alled O ag, whi h informs the host whether it should use DHCPv6 to obtain optional information, when the IP address auto- on guration is performed based on the pre x announ ed in the
RA
message.
Dynami Host Con guration Proto ol DHCP [Dro97℄ provides a framework for passing on guration information to terminals, using a lient/server model. It is based on the ex hange
DHCP DISCOVER message in order to dis over available servers; it may re eive one or more DHCP OFFER messages. Based on the on guration parameters in luded in these
of four signaling messages. The lient broad asts a
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
88
messages, the DHCP lient sele ts one of the DHCP servers. Afterwards, it broad asts a
DHCP REQUEST
ontaining the identi ation of the sele ted
server. Finally, the server will reply with a
DHCP ACK
ing the assigned address and optional information.
message ontain-
Before on guring the
assigned IPv4 address, terminals have to run the DAD pro edure.
With
+ the advent of IPv6, a new DHCP version (DHCPv6) [D 03℄ ame up, onsidering a dierent operation model: (1) a well-known multi ast address is used by lients to address all the servers in the link, instead of broad asts; (2) unlike DHCPv4, whi h is used to perform the whole host on guration, DHCPv6 an be used to just omplement the stateless me hanism; (3) the messages de ned for DHCPv6 are equivalent to DHCPv4 messages but different in name and format. In real implementations, DHCPv4 and DHCPv6 are used independently for dual-sta k nodes. In DHCPv4 and DHCPv6, instead of using the default 4-message pro edure, it is possible to use a minimalist 2-message pro edure, alled Rapid Commit. This enables faster auto- on guration and makes the DHCP auto on guration pro ess more e ient.
In DHCPv4, this means that upon
DHCP DISCOVER with the Rapid Commit option the server replies with a DHCP ACK. In DHCPv6, it means that if the server re eives a DHCP Soli it with the Rapid Commit option, it replies with a DHCP Reply. Apart from being used for IP address auto- on guration, DHCPv6 re eiving a
an also be used for IP Pre x Delegation (PD) [TD03℄. A requesting router
an run a DHCPv6 lient to a quire an IPv6 pre x, whi h an then be used for IP address auto- on guration within a network where it a ts as a default gateway. For that purpose, the requesting router may run a DHCPv6 server or use the Stateless IPv6 Auto- on guration me hanism to enable the auto- on guration of the nodes running in the lo al link.
Trial-and-error Me hanism Currently, a dual-sta k node runs both IPv4 and IPv6 auto- on guration me hanisms, whether two IP versions are supported by its ommuni ating peer(s) or not. A trial-and-error me hanism is employed. In what follows, we des ribe the IPv4 and IPv6 auto- on guration me hanisms ommonly used today, based on the auto- on guration solutions just dis ussed. The ow hart of Fig.
4.6 shows the urrent auto- on guration pro e-
dure for IPv4, when a node is atta hing to a given peer node or network.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
89
Start
send DHCP DISCOVER
DHCP OFFER received before timeout?
Yes
send DHCP REQUEST No
No
No
max DHCP DISCOVER retrans. reached?
Yes
DHCP ACK received before timeout?
max DHCP REQUEST retrans. reached?
No
Yes generate IPv4 link-local address
run DAD procedure send ARP REQUEST
Successful DAD? ARP REPLY received before timeout?
Yes
Yes
No
(unsuccessful DAD)
No
No
max ARP REQUEST retrans. reached? Yes (successful DAD)
IPv4 address configured
End
Figure 4.6: Current IPv4 auto- on guration me hanism.
Yes
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
90
The node starts the auto- on guration pro ess by sending a
DHCP DIS-
COVER message. If one or more DHCP OFFER messages are re eived, the node sends a DHCP REQUEST to the sele ted DHCP server and awaits for the orresponding DHCP ACK message sent by the server; if no DHCP ACK is re eived before a timeout, a new DHCP REQUEST is sent if the maximum number of DHCP REQUEST messages has not yet been rea hed. Otherwise, it keeps sending DHCP DISCOVER messages until DHCP OFFER messages are re eived or the maximum number of retransmissions for DHCP DISCOVER is rea hed. In the latter ase, the DynLL pro edure is invoked. In both ases, DAD is performed in order to he k the uniqueness of the IPv4 address to be on gured.
The DAD pro edure onsists of the
following steps. The node testing the uniqueness of the IP address, either
ARP REARP REPLY is
lo ally generated or assigned by the DHCP server, broad asts an
QUEST
with that IP address as the target address. If an
re eived before a timeout, the DAD pro edure ends with the result Unsu
essful DAD. Otherwise, after the timeout a new the maximum number of
ARP REQUEST
ARP REQUEST
is sent if
messages was not yet rea hed. If
the maximum number is rea hed, the DAD pro edure ends with the result Su
essful DAD. When no dupli ate address is dete ted the IP address is assigned to the orresponding network interfa e. The ow harts of Fig. 4.7 and Fig. 4.8 illustrate the IPv6 auto- on guration me hanism.
The auto- on guration of a link-lo al address is always
performed rst (Fig. 4.7). Before the address is assigned, a DAD pro edure is also run, this time using the NDP proto ol. If the DAD pro edure ends with the result Su
essful DAD the IPv6 link-lo al address is assigned to the lo al network interfa e; otherwise, no IPv6 link-lo al address is on gured. Afterwards, the node starts the auto- on guration of a global IPv6 address (Fig.
4.8).
orresponding
M
Router Soli itation (RS) and awaits for the Router Advertisement (RA). If an RA is re eived, the ag
Firstly, it sends a
in luded in this message is he ked, so that the node knows the means
available to on gure the global IPv6 address:
RA ag M
1) using the
sent out by the on-link IPv6 router; 2) using DHCPv6. If
message is equal
to 0, the rst option is used; otherwise, DHCPv6 shall be used. If an is not re eived after a given timeout, a new repeated until the maximum number of
RS
RS
RA
is issued; this pro ess is
messages is rea hed.
In that
ase, DHCPv6 is tried. The pro edure using DHCPv6 is similar to DHCPv4,
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
91
Start generate IPv6 link-local address
send MLD Report
No
max MLD Report retrans. reached? Yes
send Gratuitous NS
NA received before timeout?
Yes (unsuccessful DAD)
No max NS retrans. reached?
No
Yes (successful DAD)
IPv6 link-local address configured
End
Figure 4.7: Current IPv6 Link-lo al auto- on guration me hanism.
as it an be veri ed in the ow hart. However, if the DAD pro edure ends with the result Unsu
essful DAD, the DHCPv6 lient will issue a
DECLINE
DHCP
message, so that the server is informed that the lient ould not
on gure the assigned address. The auto- on guration me hanisms illustrated in Fig. 4.6, Fig. 4.7, and Fig. 4.8 are run in parallel by a dual-sta k node. Therefore, if, for instan e, the node is atta hing to an IPv4-only a
ess network supporting DHCP, a set of signaling messages will be wasted in the auto- on guration pro ess. On the other hand, if the node is atta hing to a peer that only supports the DynLL me hanism, both time and signaling messages will be wasted; similar reasoning ould be elaborated regarding an IPv6-only peer.
The
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
92
Start
send RS
RA received before timeout?
M_flag = 1?
No
generate IPv6 address (based on received info)
Yes Yes
1
No No
run DAD procedure
max RS retrans. reached?
Successful DAD?
Yes 2
DHCP ADVERTISE received before timeout? No max DHCP SOLICIT retrans. reached?
No
Yes
No
send DHCP DECLINE
Yes IPv6 address configured
send DHCP SOLICIT
No
M_flag=1?
Yes
send DHCP REQUEST No
Yes
DHCP REPLY received before timeout?
max DHCP REQUEST retrans. reached?
Yes
No 1
2
End
Figure 4.8: Current IPv6 Global auto- on guration me hanism.
urrent IP auto- on guration approa h onsiders a dual-sta k model and the need to have IPv4 and IPv6 onne tivity established simultaneously. Within the urrent and the future IP ommuni ation paradigm this may not be required, due to the deployment of IPv4-only and/or IPv6-only networks. Additionally, in the urrent approa h it is assumed that in general a node will atta h to a network infrastru ture running a DHCPv4/v6 server or IPv6 stateless auto- on guration.
This is not aligned with the new envisioned
peer-to-peer, symmetri ommuni ation paradigm, where any node an run a DHCP server, for instan e, as it may happen within a PAN.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
93
Auto- on guration in Multi-hop Networks Existing IP auto- on guration solutions, su h as DHCP, fo us on auto on guration within a single link. Therefore, they annot be dire tly applied in IP multi-hop networks, where multiple links are inter onne ted by IP routers; this is the ase of the IP networks running the ad-ho routing proto ols des ribed in Se tion 4.3.1. New auto- on guration solutions have been proposed to address auto- on guration in this type of networks. seminal work [MMMW01℄ Manousakis
et al.
In their
proposed a two-proto ol solu-
tion that enables the auto- on guration of addresses for IP routers. However, the solution does not work for routers with more than two network interfa es. In addition, the underlying rigid auto- on guration stru ture, based on the establishment of an hierar hy among the routers, suites mainly wired and stati networks, as every time there is a topology hange address re on gurations are needed. The auto- on guration solutions that have been proposed in the IETF for IP multi-hop wireless and mobile ad-ho networks (also known as MANETs) over ome this problem by onsidering at address-
+
ing [C 07℄. This avoids address re on gurations when topology hanges. A multitude of address auto- on guration solutions have been proposed for MANETs, but no standard is spe i ed yet. posals an be found in [BCM10℄. have been de ned.
A survey of the urrent pro-
Solutions onsidering IPv4 and/or IPv6
Still, these solutions essentially ope with IP address
and IP gateway auto- on guration, leaving apart the auto- on guration of optional information, su h as DNS server addresses; this is a strong limitation, sin e end-users work with Fully Quali ed Domain Names (FQDNs), not with IP addresses dire tly.
On the other hand, no solution addresses
the ine ien ies oming up when two IP versions oexist.
Using urrent
solutions either the IP version to be used is pre-de ned or separate me hanisms are run in parallel for ea h IP version, leading to ine ient address auto- on guration, as it already happens for dual-sta k nodes running the trial-and-error me hanism. The DHCPv6 PD solution mentioned above also represents an auto- on guration solution for IP multi-hop networks. Still, it is IPv6-only and targets spe i (stati ) s enarios.
IPv4 and IPv6 Simultaneous Auto- on guration The trial-and-error me hanism urrently employed by dual-sta k nodes is not the most e ient solution. Taking this into a
ount, solutions have
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
94
been proposed to auto- on gure IPv4 and IPv6 simultaneously in dual-sta k nodes.
The dual-sta k DHCP solution [CVS06℄ enables the simultaneous
auto- on guration of IPv4 and IPv6 addresses and optional information using a modi ed DHCPv6 version.
The Ad-Ho Con guration Proto ol
(AHCP) [Chr10℄ is a re ent proto ol inspired on DHCP proposed to address IP auto- on guration in IP multi-hop networks, whi h also enables IPv4 and IPv6 simultaneous auto- on guration.
However, while these solutions
are more e ient when the two IP versions are simultaneously available and used, they still do not solve the auto- on guration problem e iently in the future envisioned IP heterogeneous s enario, where ommonly only one IP version will be available and/or used (see Chapter 1). On the other hand, for IPv4-only and IPv6-only nodes and networks a dual-sta k auto- on guration me hanism is useless. For instan e, in a network deploying dual-sta k DHCP, IPv6-only nodes would re eived useless IPv4-related information; further limitations of using dual-sta k DHCP are listed in [CVS06℄.
Also, in AHCP,
while IPv4-only, IPv6-only, or dual-sta k auto- on guration is possible, there is no me hanism de ned to sele t the type of auto- on guration to be performed for ea h network ontext.
4.4 Underlay Networks An underlay network is a network formed by nodes at Layer-2.5 (under IP). This approa h has the advantage of making it transparent to IP whether a single or multiple physi al links are present underneath, as it urrently happens in Ethernet networks.
In this se tion we present ad-ho routing
solutions that follow this approa h and over ome some of the limitations of the IP routing proto ols presented in Se tion 4.3. Namely, they do not require new IP address and optional auto- on guration me hanisms.
4.4.1 Lightweight Underlay Network Ad-ho Routing The Lightweight Underlay Network Ad-ho Routing (LUNAR) proto ol [TGRW04℄ is a hybrid routing proto ol. It is rea tive sin e routes are dis overed when needed and it is proa tive be ause routes are periodi ally (every 3 se onds) re-dis overed by the sour e, whether topology hanges o
ur or not.
The proa tive route re-dis overy enables simpli ations in the route
maintenan e pro edure; no
Hello
messages need to be periodi ally broad-
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
95
ast and there is no need to notify the pre ursors or the sour e about a route failure. LUNAR works based on the inter eption of signaling oming
ARP REQUEST is inter epted and translated into a LUNAR Route Request, whi h is then ooded into the network. When the rst Route Request rea hes the destination, a Route Reply is sent ba k to the sour e. LUNAR de nes the
from the upper layers, namely ARP and DHCP signaling.
An
use of sele tors, whi h are lo al s ope 64-bit identi ers working similarly to the Multi-Proto ol Label Swit hing (MPLS) labels [RVC01℄. During the route dis overy pro ess ea h node installs state whi h binds the IP address of the sour e with the MAC address and the sele tor of the next hop in the route.
This is performed based on the information in luded in the
Request ;
thanks to the
Route Reply
Route
sent ba k by the destination, the same
kind of state is reated at ea h node regarding the destination. Upon a route is established, pa kets are forwarded based on the sele tors.
Sele tors are
ex hanged at ea h node, as it happens with labels in MPLS. Besides oping with uni ast route establishment, LUNAR de nes a pro edure for establishing a distribution tree for broad ast. with a broad ast pa ket to send issues a
Route Request
A sour e node
to the broad ast ad-
dress, so that all the other nodes reply; ea h node replies to the rst
Request
re eived. The
Route Reply
S
Route
at ea h node is delayed, in order to wait
for any replies oming from downstream nodes, with respe t to the sour e of the request, and onsequently minimize overhead. Like in the uni ast route establishment, this pro edure installs state at ea h node, whi h is used as a basis for subsequently delivering the broad ast pa ket. domness of the forwarding pro ess of the
Route Request
Due to the ran-
messages, a random
spanning tree is on gured. LUNAR assumes the use of the DHCP proto ol for IP address and optional information auto- on guration. Ea h node implements a fake DHCP server, whi h replies to the request from the lo al DHCP lient. The fake DHCP server assigns an IP address randomly sele ted from a pre-de ned address pool. In order to verify the uniqueness of the assigned IP address, the node tries to establish a route towards that IP address. If no
ply
Route Re-
is re eived, the address is assumed to be unused and it is passed to the
DHCP lient; otherwise, a new IP address is sele ted. Optional information, su h as IP default gateways, is rstly dis overed using a me hanism similar to the route dis overy pro edure. That information is subsequently in luded
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
96
in the DHCP reply sent to the lient. LUNAR maintains the following tables: the Mapping Table, the Route Request Table, and the Routing Table. The Mapping Table stores the mapping between IP addresses and sele tors; note that this table is only maintained by the sour e. pli ate
Route Request
The Route Request Table is used for dete ting dumessages.
Finally, the Routing Table is utilized for
pa ket forwarding. LUNAR forwards pa kets based on sele tors. As su h, the Routing Table onsists of entries in luding the mat hing between input and output sele tors; this is similar to the input and output labels de ned in MPLS. The Send Buer normally maintained for storing pa kets during route dis overy is not needed; LUNAR relies on the ARP queue for buering the pa kets while a route is being found. When it omes to the onne tion of a LUNAR network to external networks and nodes, the proto ol is limited to the onne tion to external networks, e.g., the Internet. By using DHCP, ea h LUNAR node an a quire the address of the IP default gateway and the LUNAR route dis overy pro edure an be used to establish a bidire tional route to the gateway. LUNAR does not support the onne tion to external nodes. pro edure is run for an external node, the
If the route dis overy
Route Request
will target a node
that does not belong to the network. As su h, no LUNAR node sends ba k a
Route Reply
and no route is established.
LUNAR simply de nes the route dis overy pro edure.
No additional
route maintenan e pro edure and route repair a tions are required. Nonetheless, it introdu es a new address spa e, the sele tors.
This means that at
the sour e, every time there is a pa ket to send, the Mapping Table has to be looked up to nd the sele tor asso iated to the destination.
Also, the
periodi route dis overy, while useful for very dynami networks, is a waste of resour es for networks where most probably the established routes will still be valid when a re-dis overy is issued. The sele tion of the rst route to be found does not guarantee the establishment of shortest route and leads to a random distribution tree for broad ast. On the other hand, the use of ha ks to support dierent upper layer proto ols requires that every time a new upper layer proto ol needs to be in orporated new ha ks have to be implemented. This means that, for instan e, if the support of IPv6 is required, the solution has to be modi ed to take DHCPv6 and NDP into a
ount. Finally, LUNAR does not support the integration of external nodes into the
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
97
LUNAR network, and the distribution tree reated on-demand for delivering broad ast tra , despite being more e ient than ooding, introdu es additional overhead and omplexity.
4.4.2 Link Quality Sour e Routing The Link Quality Sour e Routing (LQSR) [DPZ04℄ is a routing proto ol, whi h together with the Mesh Conne tivity Layer (MCL) [DPZ04℄ sitting in
et al.
data plane, represents another Layer-2.5 solution proposed by Draves
The MCL supports multiple network interfa es underneath and hides them from IP; IP only sees the virtual network interfa e presented by the MCL. The LQSR proto ol is based on DSR, it works at Layer-2.5, it de nes the use of 48-bit virtual MAC addresses to identify the nodes instead of the 32bit IP addresses, and it is a link-state routing proto ol. The 48-bit virtual MAC address is distin t from the MAC address(es) of the network interfa e(s) running underneath; it is randomly generated by ea h node [DPZ04℄. While keeping the fundamental me hanisms, LQSR introdu es modi ations to DSR. During route dis overy, upon re eiving a
Route Request,
the ur-
rent node appends a link metri for the link over whi h the pa ket arrived. The
Route Reply
sent ba k in ludes the omplete list of link metri s for the
route when it rea hes the sour e.
To keep tra k of the state of the links,
ea h node maintains a Link Ca he. The Link Ca he is lled in based on the route dis overy pro edure and the link information ooded into the network by ea h node. In LQSR, whenever possible nodes piggyba k on the
Request
messages a
Link Info
Route
message that advertises the link metri s for
ea h lo al link. If for a long time (10 se onds) the urrent node did not send any
Link Info, a
Info.
dummy
Route Request
is generated to piggyba k the
Link
The dissemination of this information throughout the network enables
the reation of a topology graph at ea h node, whi h is used as a basis for
omputing the sour e routes using
Dijkstra's
algorithm.
Route dis overy is also used for route re-dis overy when some link fails. Upon dete ting the failure, the urrent node penalizes the metri of that link and sends a
Route Error
to notify the sour e. The sour e may then perform
a route dis overy if no alternative route an be found lo ally based on the Link Ca he. LQSR maintains the same data stru tures as DSR plus the Neighbor Ca he and the Link Ca he. The Neighbor Ca he is used for mapping virtual
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
98
MAC addresses into physi al MAC addresses. The Link Ca he repla es the Route Ca he used by DSR and it is used for maintaining the set of links dis overed. These links together enable the reation of the topology graph. The MCL/LQSR solution does support any upper layer proto ols; it supports the onne tion of external nodes and networks and, in ontrast to LUNAR, it enables the use of link metri s. Nevertheless, LQSR also de nes a new addressing spa e. This introdu es additional omplexity sin e an additional table needs to be maintained for mapping virtual MAC addresses into physi al MAC addresses, when ompared to DSR. On the other hand, LQSR keeps the DSR disadvantages, namely when it omes to the use of sour e routing (see Se tion 4.3) and the use of alternative routes. Finally, while simple, the use of ooding for dealing with broad ast data is an inef ient solution.
4.4.3 Further Solutions In this se tion we refer to further Layer-2.5 solutions. MyMANET [PV09℄ is from an ar hite tural standpoint similar to the MCL/LQSR solution. It de nes the so- alled Wireless De ision Layer, whi h is equivalent to the MCL, and a ustomized proa tive distan e ve tor routing proto ol that di tates the routes for data pa kets; the solution is exible and an support a routing proto ol other than the default. Still, MyMANET does not de ne any new address spa e. Physi al MAC addresses are used to identify the nodes; this is a
omplished at the ost of supporting single-interfa e nodes only. Lilith [UHRD04℄ is analogous to LUNAR. It uses MPLS for pa ket forwarding and relies on a rea tive proto ol for route and label establishment.
As in
MyMANET, the a tual routing proto ol an be dierent from the default, whi h is based on AODV. Lilith uses ooding for broad ast data delivery. Virtual Link Routing (VLR) [KPT07℄ de nes the use of 64-bit identi ers,
alled Virtual Link Identi ers (VLIs), and uses a ustomized rea tive routing proto ol similar to AODV. VLIs have the same role as MPLS labels or sele tors in LUNAR, and are used for pa ket forwarding; however, VLIs are set by the sour e of a route request and are valid network-wide.
The
Ana4 solution [BCF05℄ is analogous to MCL/LQSR. It supports multiple interfa es and de nes the use of 64-bit ad-ho addresses to identify nodes at Layer-2.5. The ad-ho addresses are used as a basis for pa ket forwarding. Ana4 supports any routing proto ol for route establishment, in parti ular
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
99
those de ned in Se tion 4.3, whi h however have to be modi ed to support ad-ho addresses instead of IP addresses. Apart from their spe i drawba ks, the general disadvantages of the Layer-2.5 solutions dis ussed in this se tion are (1) the de nition of a new proto ol layer, (2) the absen e of any support for lega y nodes, and (3) the de nition of a new address spa e and the orresponding mapping me hanism required in most of the ases. Overall, this brings up omplexity and makes deployment more di ult.
4.5 Personal Area Networks Despite their drawba ks, the generi solutions presented in the previous se tions are andidates for solving, at least, part of the auto- on guration problem in IP-based PANs. The onvergen e to an all-Ethernet paradigm in the PAN domain makes it feasible to use the auto- on guration solutions proposed so far for Ethernet networks, together with the existing IP auto- on guration me hanisms for address and optional information auto on guration; the same reasoning an be applied with respe t to most of the Layer-2.5 solutions dis ussed in Se tion 4.4. At another level, the IP adho routing proto ols, espe ially the rea tive proto ols su h as AODV, also represent a possible solution for path establishment within a PAN, whi h however require new IP address auto- on guration me hanisms. In this se tion we dis uss auto- on guration solutions addressing PANs. They onsider the generi solutions as a basis and a
ount for the PANs' idiosyn rasies.
4.5.1 Single-te hnology Solutions Bluetooth Bluetooth [SIG10℄ has be ome the
de fa to
standard for enabling PANs.
It de nes a set of pro les aimed at being used for dierent appli ations, su h as transfer of a stereo audio stream and le transfer. However, the relevant pro le from personal area networking viewpoint is the PAN pro le, as we have referred in Chapter 2. The Ethernet emulation provided by this pro le enables easy reation of IP-based PANs on top of Bluetooth; for more details about the PAN pro le please refer to Chapter 2. Using the PAN pro le, from the upper layers point of view, the Bluetooth PAN appears as if it was an Ethernet LAN. At the Bluetooth level, a set of emulated Ethernet links are
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
100
established between the slaves and the master a ting as NAP or GN, as illustrated in Fig.
2.5.
In order to truly emulate the LAN behavior, the
GN/NAP a ts as an IEEE 802.1D bridge between the emulated Ethernet links. Thanks to the emulated LAN reated, the traditional IP address and optional information auto- on guration me hanisms an work transparently over the Bluetooth PAN. Despite the means provided by the Bluetooth te hnology to reate IPbased PANs, these are still in ipient PANs. The formation of the PAN is not fully automati . For instan e, a PAN devi e has to be manually on gured as an IEEE 802.1D bridge between the emulated Ethernet links and the links themselves have to be established by means of manual on gurations. Furthermore, if the Bluetooth PAN is onne ted to an external network, e.g., the Internet, the devi e a ting as the IP gateway has to be on gured manually. On the other hand, in the PAN pro le the roles of the PAN devi es are stati .
This is not ompatible with the new personal ommuni ation
paradigm where devi es may have dynami roles and a PAN moves around with the user, leading to hanges in the Point of Atta hment (PoA) and in the node a ting as the PAN gateway; networking expertise and umbersome manual re on gurations are needed every time the PAN PoA hanges.
In
addition, from IP standpoint, the IP auto- on guration ine ien ies mentioned in Chapter 1, due to the oexisten e of two IP versions, are still a problem not solved.
Bluetooth S atternets.
In its basi form, Bluetooth only enables om-
muni ation if the slaves are in the master's radio range.
The s atternet
on ept de ned in the Bluetooth spe i ation [SIG10℄ over omes this limitation by enabling the inter onne tion of neighbor pi onets (see Chapter 2).
Although the Bluetooth spe i ation does not de ne any routing so-
lution for reating s atternets, solutions have been proposed [WHC05℄, for instan e inspired on ad-ho routing proto ols su h as DSR and AODV. Yet, these solutions are fo used on the pi onet inter onne tion problem. They do not over ome the auto- on guration limitations pointed out in the previous paragraph. In addition, their integration with the Bluetooth PAN pro le is not de ned.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
101
IEEE 802.11, WiMedia UWB, and others Most of the other wireless te hnologies presented in Chapter 2 enable Ethernet emulation, namely IEEE 802.11 and WiMedia UWB. Similarly to Bluetooth, WiMedia UWB PANs and IEEE 802.11 PANs an appear as an Ethernet LAN to upper layers and enable the IP over Ethernet model. For IEEE 802.11 PANs, the underlying wireless network may be either a BSS or an IBSS. In a BSS, one PAN devi e may a t as an 802.11 AP and the others an onne t to it as STAs.
In an IBSS, there is no entral point;
stations ommuni ate dire tly with ea h other in a peer-to-peer manner. This is also the model used by WiMedia UWB PANs, where devi es in radio range an form a WSS. When the BSS, IBSS, or WSS is formed, IP and its related address and optional information auto- on guration me hanisms an run transparently on top, and everything just works as in urrent Ethernet LANs. The onne tion to an external network an be performed by simply
on guring one of the devi es as the PAN gateway, for instan e to share the Internet onne tion of that devi e with the other members of the PAN. While some of the limitations inherent to Bluetooth are over ome by these te hnologies, for instan e there is no need to expli itly establish the emulated Ethernet links, they still assume stati roles for the PAN devi es and require manual on gurations for onne ting the PAN to an external network, whi h brings up the same problems mentioned for Bluetooth. In addition, the IP auto- on guration ine ien ies are still present.
IEEE 802.15.5 IEEE 802.15.5 [Gro09d℄ is a re ent standard that enables the reation of multi-hop IEEE 802.15.3 and IEEE 802.15.4 wireless PANs, also alled mesh WPANs, with the same purpose of s atternets in Bluetooth.
IEEE
802.15.5 de nes spe i solutions for IEEE 802.15.3 and IEEE 802.15.4 mesh WPANs, namely when it omes to the frame formats and spe i signaling messages involved. Con erning path establishment and pa ket forwarding it de nes a ommon me hanism for both te hnologies, alled tree routing, and an optional routing solution for IEEE 802.15.3 mesh WPANs, alled server routing. The server routing solution enables shortest path routing, but at the ost of further omplexity and additional signaling overhead.
In what
follows we only refer to the simpler tree routing solution. In a mesh WPAN there is a oordinator, alled Mesh Coordinator (MC).
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
102
[0, 20] A [9, 16]
[1, 8] B
C
D [2, 5] Figure 4.9: Illustration of the address assignment used in IEEE 802.15.3 and IEEE 802.15.4 mesh WPANs and the orresponding tree topology established, with the address pool available at ea h node shown between square bra kets.
The mesh WPAN is stru tured around the MC. Apart from the addresses used in ea h wireless te hnology for intra-pi onet operation, an additional 16bit mesh address is de ned. Note that only the PNCs, in this ontext alled Mesh PNCs (MPNCs), are involved in a mesh WPAN. So, the MPNCs are the only nodes with a mesh address. Initially, the mesh WPAN is formed by the MC only. At this point, the MC maintains the whole pool of mesh addresses. When atta hing to the mesh, a MPNC sele ts a parent MPNC; the parent MPNC may be the MC, if it is in the urrent MPNC's vi inity, or another MPNC already belonging to the mesh. The MC splits the pool of addresses among its hildren MPNCs.
In turn, the MPNCs split their
own pools and assign sub-pools to their hildren MPNCs.
Through this
me hanism a stru tured address hierar hy and a tree rooted at the MC are reated, as illustrated in Fig.
4.9; in this example, Node A, a ting as
MC, reserves the addresses 17 to 20 and Node B reserves addresses 6 to 8, regarding future assignments. Pa ket forwarding is then based on the tree rooted at the MC and on the Neighbor Table, whi h is lled in based on
Hello messages sent out periodi ally by ea h MPNC. If the destination node is in the Neighbor Table, the data frame is sent dire tly. If the destination address falls in one of the address blo ks assigned to a hild MPNC, the pa ket is forwarded to that hild. Otherwise, the pa ket is sent to the parent MPNC. In fa t, in the solution for IEEE 802.15.4 mesh WPANs the pa ket does not need to be ne essarily sent to the parent MPNC; if available, other upstream neighbor may be used for load balan ing purposes.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
103
While the approa h followed by IEEE 802.15.5 guarantees a simple routing solution, it has some disadvantages.
It is does not guarantee that the
shortest path is sele ted. In this ase an SPST rooted at the MC is formed; in pra ti e, this represents the establishment of an arbitrary SPST, as it happens in STP and RSTP proto ols.
Moreover, the mesh WPAN is reated
among MPNCs. How DEVs within a pi onet learn the path to the devi es lo ated in other pi onets is not spe i ed in the standard. On the other hand, in spite of enabling shortest path routing, the server routing me hanism de ned for IEEE 802.15.3 mesh WPANs introdu es further omplexity and additional signaling overhead. Finally, on e again the IEEE 802.15.5 solution only targets the inter onne tion of IEEE 802.15.3 and IEEE 802.15.4 pi onets to form a mesh network.
The limitations related to the dynami
and automati onne tion to external networks still exist.
IEEE 802.11s IEEE 802.11s [Gro09a℄ is urrently a draft standard to enable the reation of IEEE 802.11 multi-hop networks, also alled 802.11 mesh networks. The Hybrid Wireless Mesh Proto ol (HWMP) is proposed for automati path establishment.
The HWMP is a hybrid proto ol that ombines rea -
tive path dis overy and tree-based proa tive routing in the same solution. The rea tive path dis overy solution is essentially a MAC layer version of the AODV proto ol (see Se tion 4.3). The tree-based proa tive routing solution is analogous to that adopted in IEEE 802.15.5. There is a Mesh Point (MP) that a ts as the root of the tree, alled root MP. A message broad ast periodi ally by the root MP enables the other MPs to establish proa tively a path towards the root; as a result, an SPST from the root MP perspe tive is reated. The HWMP proto ol onsiders two me hanisms for reating the SPST: the PREQ me hanism and the RANN me hanism.
The tree-based
proa tive solution targets mainly Stub WMNs, so these me hanisms are des ribed in Se tion 4.6.2. The rea tive path dis overy by itself is appropriate for ad-ho networks, su h as PANs. Yet, it an also work in onjun tion with the tree-based proa tive solution; we will also refer to this in Se tion 4.6.2. The HWMP rea tive path dis overy works as the AODV proto ol. The dieren es have to do with the name of the messages, the default routing metri used, and the way dupli ate The
Route Request
and
Route Reply
Path Request
messages are pro essed.
are here alled
Path Request
and
Path
CHAPTER 4.
Reply,
NETWORK AUTO-CONFIGURATION
104
respe tively. The default routing metri is the Airtime Link Metri
(ALM). The ALM metri is omputed per link as the result of a mathemati al expression in luding two onstant and two variable parameters. The variable parameters are the rate at whi h the wireless NIC is running and the frame error probability for a test frame whose size is onsidered in the metri too; for more details please refer to [Gro09a℄. In addition, rather than a
epting the rst
Path Request
as the message to establish the path between the
sour e and destination mesh nodes, the HWMP path dis overy pro edure uses the same approa h as AODV with data rate metri and DYMO, i.e., dupli ate
Path Request
messages with a better umulative ALM metri lead
to an update of the routing table; as in DYMO, no limitation is imposed on the number of dupli ate
Path Request
messages that an be forwarded at
intermediate nodes or a
epted at the destination. An IEEE 802.11s mesh behaves as a LAN, ompatible with the IEEE 802.1D standard. In this sense, an IEEE 802.11s mesh network appears to upper layers as a single logi al link. So, when it omes to the formation of IP-based PANs, everything happens as in a single-hop IEEE 802.11 network. Given the ompatibility with the IEEE 802.1D standard, the IEEE 802.11s mesh network an be onne ted to other 802 networks transparently.
For
that purpose, one or more MPs may a t as portals between the mesh network and an IEEE 802 external network or node. In the portals, an IEEE 802.1D bridge runs between the mesh and the 802 external network(s). Six addresses are used in this on guration. Four addresses are used for mesh forwarding purposes and the two remaining addresses refer to the sour e and destination of the pa ket, whi h may be both outside the mesh; this approa h avoids the maintenan e of routing information at intermediate MPs for any IEEE 802 node outside the mesh. To nd the path to an external node, MPs use the rea tive dis overy me hanism too.
If the sour e or the destination is an
external node, the MP a ting as portal to that external network issues a
Path Request
or a
Path Reply
on its behalf, respe tively. If both the sour e
and the destination are outside the mesh, the orresponding portals issue a
Path Request
and a
Path Reply, respe tively.
IEEE 802.11s enables the extension of the limited radio overage provided by IEEE 802.11. From a logi al perspe tive, an IEEE 802.11s network appears as a LAN and an be transparently onne ted to 802 external networks using IEEE 802.1D bridges. As su h, we an say that IEEE 802.11s
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
105
provides the means to form multi-te hnology PANs and, on the other hand, it enables the integration of lega y nodes. Still, this is a hieved at the ost of using a 6-address format in the header of ea h pa ket forwarded a ross the mesh network, whi h introdu es additional overhead and omplexity. Besides, the advantage of avoiding the maintenan e of routing information at intermediate MPs does not hold in networks where just a few nodes are expe ted to be a tive at a given moment, su h as in PANs. IEEE 802.11s maintains the same disadvantage as AODV using the data rate metri and DYMO, when it omes to the possible exponential growth of signaling messages during path dis overy. Also, while providing the shortest path in terms of the ALM metri , it maintains the omplexity of the AODV route maintenan e pro edure due to the use of pre ursor lists. Finally, the limitations related to the dynami and automati onne tion to external networks are still present; portals to external networks have to be manually on gured.
Personal Hub Husemann
et al.
[HNN04℄ proposed the on ept of Personal Mobile Hub
(PMH) to support both inter-devi e ommuni ation within a PAN and Internet a
ess sharing among PAN devi es.
For intra-PAN ommuni ation
some short-range wireless te hnology, su h as Bluetooth and IEEE 802.11, may be used. Regarding Internet a
ess, the use of GSM/GPRS is proposed. The PMH represents the entral point through whi h the other devi es onne t to ea h other and have a
ess to the Internet. In [HNN04℄ the authors report the hardware and software implementation of a ustomized PMH using Bluetooth for intra-PAN onne tivity. a ommer ial produ t by Intel, alled
A similar on ept is urrently
My Wi-Fi. My Wi-Fi
is a wireless
driver and software update to Intel's Centrino 2 pro essor-based laptops. It allows the virtualization of the laptop's built-in 802.11 NIC; two virtual 802.11 NICs are reated.
This enables the NIC to be both onne ted to
an 802.11 AP and, simultaneously, parti ipate in an 802.11 ad-ho network. Also, it enables the reation of a Wi-Fi PAN among the user's personal devi es; up to eight devi es may onne t to the laptop. At the same time, the laptop's Wi-Fi Internet a
ess may be shared with the other PAN devi es. A DHCP server is run within the laptop for IP address and optional information on guration and Network Address Translation (NAT) [SH99℄ is used for translating the IP private addresses used within the PAN to the IP pub-
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
106
Internet DEV1 GPRS, Wi-Fi, ...
DEV2
Personal Hub
Wi-Fi, UWB, Bluetooth, ... DEV3
DEV4
DEVn
Figure 4.10: The Personal Hub Con ept.
li address on gured for the laptop's Wi-Fi Internet a
ess. The Personal Router Proje t
10 also proposed an equivalent solution, where a so- alled per-
sonal router plays the same role as the personal mobile hub or the laptop in the
My Wi-Fi
solution. Fig. 4.10 illustrates the personal hub on ept with
the wireless te hnologies that may be used for inter-devi e ommuni ation and for atta hing the personal hub to the Internet. These solutions have the merit of enabling plug and play deployment of PANs using a short-range te hnology, su h as IEEE 802.11 and Bluetooth. While this represents a step further with respe t to the basi IEEE 802.11 and Bluetooth PANs supported by the wireless te hnologies alone, it is still not enough to enable the IP-based PANs a
ording to the new PAN paradigm mentioned in Chapter 1. The PAN gateway is xed and we are limited to the wireless te hnologies supported by the PMH, laptop, or Personal Router. Using these solutions it is not possible to take advantage of the multiple wireless a
ess te hnologies that may be available in a PAN, provided by dierent devi es. In addition, these solutions are limited to one IP version.
Personal Mesh The Personal Mesh solution was proposed by Nguyen
et al.
[NMA06℄ to
enable the plug and play onne tion of a PAN to the Internet, taking into a
ount the multiple wireless a
ess links that may be available among the 10
http://pr.l s.mit.edu/
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
107
PAN members. In Personal Mesh a devi e a ting as gateway between the PAN and the Internet is alled Personal Gateway (PGW). PGWs ooperate with ea h other in a distributed manner to olle t information on all a
ess links available; ea h PGW maintains a list of all a
ess links available in the PAN. For onstru ting this list ea h PGW onsiders its own a
ess links and the a
ess links the other PGWs learnt by means of the
Noti ation
A
ess Link
messages sent by PGWs. A PGW dete ting a hange in some
of its a
ess links noti es the other PGWs immediately.
Upon atta hing
to the PAN, a node re eives an IPv4 private address and the address of a default PGW; how this is performed and whi h proto ol is used for onveying the information to the PAN devi es is not spe i ed in [NMA06℄.
A PAN
devi e willing to ommuni ate with some node in the Internet establishes a ommuni ation session through the default PGW. The default PGW is in harge of nding out the appropriate a
ess link for that ommuni ation session.
If an a
ess link belonging to another PGW is to be used, the
devi e's default PGW triggers a PGW hange pro ess by notifying the PAN devi e with a standard
ICMP Redire t
[Pos81℄.
The Personal Mesh solution is solely fo used on the onne tion of the PAN to external networks and assumes any short-range wireless te hnology for intra-PAN onne tivity.
It enables the exploration of the set of a
ess
links that may be available in a PAN and, in that sense, over omes the limitations of the personal hub model. Also, it avoids the modi ation of the PAN devi es that are not PGWs. However, it does require modi ations to the orresponding nodes ommuni ating with PAN devi es. This means that every peer devi e ommuni ating with a PAN devi e has to be modi ed; an alternative pointed out in [NMA06℄ is to have a PGW in the destination network, whi h still implies modi ations. This brings up deployment problems due to the modi ation of all devi es or networks the PAN devi es want to ommuni ate with. In pra ti e, the nan ial osts that may be involved and the potential residual bene ts in terms of bandwidth, may make the simultaneous use of multiple a
ess links worthless and may simply introdu e omplexity. For most appli ations a single a tive link to the Internet will be enough, namely due to the in reasing bandwidth available for ea h a
ess te hnology. Finally, Personal Mesh is limited to IPv4 and the a tual IP address and optional information auto- on guration solution used within the PAN is not spe i ed.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
108
A Method For Providing A
ess in a PAN +
In a patent by Eri sson [JRP 06℄ the inventors de ne a method and spe ify a devi e, the PAN managing devi e, to manage the a
ess links of the PAN to the Internet. This solution is also fo used on the onne tion of a PAN to the Internet and it assumes that some short range wireless te hnology provides the means for intra-PAN onne tivity. Multiple PAN devi es may be used for managing the PAN. However, only one of them is sele ted as the PAN managing devi e at a given moment; the user is in harge of de ning whi h devi e is sele ted.
The PAN managing devi e olle ts information
about the available a
ess links by querying the PAN gateways (PGWs), whi h reply with information about their lo al a
ess links.
Based on the
manual intervention of the user or based on per-devi e pre- on gurations de ned by the user, the PAN managing devi e instru ts PGWs about the PAN devi es using them as the default PGW. As in the
My Wi-Fi
solution,
the PGWs may run a DHCP server and NAT; the IPv6 solution de nes that the PAN gateways may run a DHCPv6 server and assumes that the external network provides an IPv6 pre x to the PAN gateways. As in Personal Mesh, this avoids modi ations to nodes that are not PGWs.
A PAN devi e is
indire tly instru ted about its default PGW when performing IP address and optional information auto- on guration using DHCP. Upon re eiving a
DHCP DISCOVER
message, the urrent PGW takes into a
ount the
instru tions re eived from the PAN managing devi e.
If it is the default
DHCP OFFER and the rest of the DHCP pro edure is exe uted; otherwise, it silently dis ards the DHCP DISCOVER. Upon the DHCP pro edure ends, the PAN devi e is on gured PGW for that PAN devi e, it will reply with a
to use the PGW de ned by the PAN managing devi e. More re ently, the
+
same inventors patented a related solution [JPR 08℄ where PAN devi es may either be dire tly instru ted by the PAN managing devi e about the PGW to use or they an even de ide by themselves whi h PGW to use, based on the available PAN a
ess links. This solution enables the seamless integration of lega y PAN devi es and the simultaneous utilization of the multiple a
ess links that may be present in a PAN. Furthermore, it supports both IPv4 and IPv6. Yet, the following drawba ks an be identi ed.
As stated for the Personal Mesh solution, in
pra ti e, the simultaneous use of multiple a
ess links may not be a great advantage and it may just introdu e unne essary omplexity. The proposed
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
109
solution requires user involvement when it omes to the sele tion of the PAN managing devi e. Moreover, the user may be involved in the on guration of the spe i a
ess links to be used for ea h PAN devi e.
Finally, the
urrent IP auto- on guration ine ien ies when two IP versions oexist are not addressed.
4.5.2 Multi-te hnology Solutions This se tion refers to the state of the art PAN auto- on guration solutions onsidering multiple wireless te hnologies for intra-PAN onne tivity.
Distributed Virtual Network Interfa es The Distributed Virtual Network Interfa es (DVNI) solution was proposed by Sethom
et al.
+
[S 05℄ to address PAN-to-Internet onne tivity.
DVNI follows an underlay approa h, similarly to the underlay solutions dis ussed in Se tion 4.4. It de nes a virtual MAC layer sitting between the IP and MAC layers. This layer abstra ts upper layers from the multiple physi al NICs, su h as Bluetooth and IEEE 802.11, that may be running in ea h PAN devi e and, at the same time, provides the means to share the a
ess links to the Internet among PAN devi es. DVNI omprises two major parts: a dis overy me hanism, for learning the a
ess links to the Internet available within the PAN, and a Layer-2.5 routing solution. The dis overy me hanism works as follows. The PAN gateways periodi ally announ e their presen e by issuing
Hello
messages. The
Hello
message in ludes the list of the a tive
a
ess links at the orresponding gateway.
Upon re eiving a
devi e stores su h information in the gateways lo al table.
Hello
a PAN
The Layer-2.5
routing solution de nes the reation of the routes between the PAN devi es and the gateways. The routes are reated based on the
Hello messages trav-
eling a ross the PAN, onsidering, for example, the hop ount routing metri ; this is similar to the me hanism used, for instan e, in AODV when a
Request
Route
is ooded into the network and the nodes re eiving the message
reate a route towards the sour e of the
Route Request.
Pa ket forwarding
is then based on the Routing Table maintained at Layer-2.5 by ea h PAN devi e with the mapping between ea h gateway and the lo al interfa e that has to be used to rea h it. DVNI does not introdu e any new addressing spa e the MAC address of one of the underlying physi al network interfa es is sele ted as the virtual
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
110
MAC address, it is not limited to a spe i routing metri , and it enables
ooperation among PAN devi es to make a
ess links sharing possible. Nevertheless, it takes IP address and optional information auto- on guration for granted and no lue is provided about the way IP auto- on guration would be performed with DVNI. Also, it does not support lega y devi es; to bene t from DVNI, PAN devi es need to understand the by the gateways.
Hello
messages sent out
On the other hand, the Layer-2.5 routing solution only
works for PAN-initiated ommuni ation sessions. Unidire tional routes are established between PAN devi es and the PAN gateways, and it is assumed that the routes in the opposite dire tion are impli itly established when the PAN devi e sends its rst pa ket towards the gateway. This means that the routing solution does not work when ommuni ation sessions are initiated by some node in the Internet.
IP-based Personal Area Networks with On-Demand Routing Engelstad [Eng05℄ proposed the deployment of IP-based PANs based on AODV and a PAN middleware that presents the PAN as a virtual devi e to the user and appli ations. In addition, he de ned a new name resolution me hanism, whi h is integrated with the AODV route dis overy pro edure; this is required sin e existing link-lo al name resolution me hanisms, su h
+
as Link Lo al Multi ast Name Resolution (LLMNR) [A 07℄ and multi ast DNS (mDNS) [CK10℄, do not work over IP multi-hop networks. Regarding the onne tion of the PAN to the Internet, he proposed modi ations to the default AODV me hanism for a
essing external networks. AODV onsiders that any
Route Request
for a destination outside the AODV network is
transparently answered by an AODV node a ting as gateway. gateways are available, the sour e node will get multiple sages. It may happen that more than one metri value.
Route Reply
If multiple
Route Reply
mes-
ontains the same
In that ase, the gateway will be randomly sele ted by the
sour e node. This may be a problem when using, for instan e, NAT at the gateways. On e a tive, a ommuni ation session established with an external node through a gateway should not hange to another gateway; otherwise, the ommuni ation session will fail due to the NAT state hange. Gateway
hange may o
ur if the route to the urrent gateway expires and a new route dis overy pro edure is initiated. Engelstad proposed a solution to make the gateway sele tion a deterministi pro ess, so that this problem is over ome.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
111
His solution de nes that the sour e node is aware of the gateway being used for routing tra to the external node. As su h, when the route to the urrent gateway expires or fails, the sour e node is able to re-establish the route to the spe i gateway being used. Despite oping with both intra-PAN onne tivity and a
ess to external networks, over oming the AODV limitation when it omes to the a
ess to external networks, and de ning a pioneer name resolution me hanism for IP multi-hop ad-ho networks, Engelstad's proposal has some disadvantages. It does not address the heterogeneity found in urrent IP networks and it de nes a PAN middleware, whi h is a disadvantage from lega y appli ations standpoint, sin e they have to be modi ed to take advantage of the proposed solution.
Also, the use of an IP routing approa h has the disadvantage
of requiring the de nition of new me hanisms for name resolution and IP address and optional information auto- on guration, while the use of AODV has the disadvantages pointed out in Se tion 4.3. Finally, in ontrast to some of the solutions des ribed in Se tion 4.5.1, the sele tion of the PAN gateway does not onsider the hara teristi s of the a
ess links they an oer (e.g., bandwidth, ost), whi h is a disadvantage inherited from the original AODV me hanism.
Poli y-driven Middleware for Personal Area Networks In [Mad04℄ Madhvani proposed a new on ept alled Self-Managed Cell (SMC). The SMC in ludes the PAN devi es themselves as well as the software modules required for self-managing the PAN, su h as Poli y Management Agent and Dis overy Server whi h maintains a list of the devi es belonging to the SMC. The SMC is deployed by means of a PAN middleware, whi h enables the user's devi es to be integrated in a PAN and hides their distributed nature from the user and appli ations. A poli y-driven management approa h is adopted. User-de ned poli ies govern the behavior of the devi es and the servi es supported within the SMC. For instan e, a possible poli y may be: Forward all in oming alls to PDA when mobile phone has less than 10% battery harge. The solution over omes the limitations of the
urrent personal ommuni ation model, where this is not possible, at least, without manual user intervention. The main merit of Madhvani's solution is to go a step further when it omes to the integrated and ooperative behavior of personal devi es.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
112
However, in ontrast to Engelstad's solution, it does not fo us on network auto- on guration.
It simply assumes that a rea tive IP ad-ho routing
proto ol an be used. AODV and DSR are pointed out as andidates, with their inherent disadvantages dis ussed in Se tion 4.3.
Besides, the use of
a PAN middleware has the drawba ks pointed out for Engelstad's solution. On the other hand, the Madhvani's solution is fo used on the intra-PAN perspe tive; no referen e is made to the integration with external networks. Finally, Madhvani's solution opes with auto- on guration problems at a dierent level, when ompared to the problems onsidered in this thesis. Auto- on guration is onsidered at the appli ation/servi e level, whi h is something out of s ope for this thesis.
PACWOMAN Proje t The Power Aware Communi ation for Wireless Optimized PANs (PACWOMAN) proje t
11
was an European resear h proje t, belonging to the
5th Framework Program, whi h nished in 2005.
PACWOMAN proposed
a solution for reating IP-based multi-te hnology PANs based on DSR. The solution opes with both intra-PAN onne tivity and PAN-to-Internet onne tivity through a possibly multi-homed PAN gateway. A middleware omponent is also de ned to abstra t appli ations from the distributed nature of the PAN. Besides the middleware disadavantage, the solution is limited to IPv6 and it does not ope with the IP address and optional information auto- on guration. This is a relevant point given that urrently there is no standard solution for IP multi-hop address auto- on guration, as mentioned in Se tion 4.3. The use of DSR has the disadvantages pointed out in Se tion 4.3. Finally, the PACWOMAN's solution de nes a dedi ated devi e as the PAN gateway, whi h is stati ally set and annot hange along the PAN lifetime. This in urs all the limitations already mentioned for the Personal Hub on ept.
MAGNET Proje t
12
The My Personal Adaptive Global Net (MAGNET) proje t
was an
European resear h proje t, belonging to the 6th Framework Program, whi h nished in 2008. MAGNET fo used on the Personal Network (PN) on ept, 11 12
http://www.ime .be/pa woman http://magnet.aau.dk
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
113
whi h is de ned as a PAN that may integrate remote personal devi es together with the devi es around the user. Despite being fo used on PNs, the
+
proje t de ned a solution equally appli able to PANs [JMRA07℄ [J 08℄. It
omprises two parts: the Integrated Convergen e (ICON) layer and the Personal Network Routing Proto ol (PNRP). The ICON is pla ed on top of IP and abstra ts the transport layer and appli ations from the fa t that multiple interfa es may be running underneath. This is similar to the DVNI proposal; the dieren e is that here it is done on top of IP. PNRP is a link-state routing proto ol inspired on existing proa tive ad-ho routing proto ols, su h as OLSR and DSDV, but adapted to the personal networking environment. Ea h devi e is identi ed by a Node Identi ation (NID); NIDs are 128-bit identi ers that appear to the transport and appli ation layers as regular IPv6 addresses. As in OLSR, PNRP de nes the use of dis overy; the dieren e is that, instead of the
Hello
arry the NID of the sour e node.
Hello messages for neighbor IP address, Hello messages
messages enable the reation of a
1-hop Neighbor Table at ea h PN devi e. The information maintained in the 1-hop Neighbor Table is then periodi ally shared with the other PN devi es by means of a
PNtopo
message.
This enables the reation/update of the
Routing Table at ea h PN devi e. In PNRP, the devi es enabling onne tivity to the Internet are alled Gateway Nodes (GNs). GNs announ e the Internet sharing servi e within the PN using a spe i servi e dis overy solu-
+
tion designed in the proje t [J 08℄; the information announ ed is the NID of the GN and the IP address of the DNS server. Communi ation between PN devi es and the GN is performed using IP-in-IP tunneling, where the outer header is used for routing tra between the sour e and the GN and the inner header in ludes the a tual sour e and destination, i.e., the PN devi e and the node in the Internet, respe tively. The MAGNET solution goes a step beyond the PAN paradigm by enabling the extension of a PAN to remote personal devi es, it supports both IPv4 and IPv6, and the NIDs an appear to the transport and appli ation layers as regular IPv6 addresses; this enables lega y appli ations on top. Besides, PNRP is not limited to the default routing metri and guarantees immediate route availability.
Also, in ontrast to Engelstad's solution, for
instan e, the sele tion of a GN takes into a
ount the hara teristi s of the a
ess links it supports [JMRA08℄.
Still, the MAGNET proposal has the
following drawba ks. The use of a proa tive routing approa h has the disad-
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
114
vantages mentioned in Se tion 4.3, namely regarding overhead, omplexity, and the establishment of routes that may never be used. The use of IP-inIP tunnels between PN devi es and GNs introdu es further overhead and
omplexity, namely at GNs, whi h have to maintain state for ea h tunnel established. The de nition of a new naming spa e brings up omplexity too, as referred to in Se tion 4.4 for Layer-2.5 solutions. The introdu tion of the ICON layer and the announ ement of the Internet sharing servi e using a new servi e dis overy solution pre ludes the integration of lega y devi es. Finally, the MAGNET solution does not solve the ine ien ies brought up by the
oexisten e of two IP versions and requires the de nition of new multi-hop IP address and optional information auto- on guration me hanisms.
4.6 Stub Wireless Mesh Networks In general, the solutions dis ussed in Se tion 4.2, Se tion 4.3, and Se tion 4.4 are andidates to solve the auto- on guration problems in Stub WMNs. As mentioned in Chapter 2, an IEEE 802.11 NIC appears in pra ti e as an Ethernet NIC providing onne tivity over the air.
With adjustments, this
makes the solutions for Ethernet networks des ribed in Se tion 4.2 feasible for Stub WMNs. On the other hand, a Stub WMN is essentially a multi-hop ad-ho network wherein routes have to be established to transport tra
oming from/going to external nodes/networks. Most of the solutions dis ussed in Se tion 4.3 and Se tion 4.4 enable this and, as su h, they are also a possibility for solving the Stub WMN path auto- on guration problem. When it omes to IP address and optional information auto- on guration, the lega y me hanisms, su h as DHCP, and the new me hanisms proposed for IP multi-hop networks are andidates too; however, the me hanism used depends on the routing solution adopted.
In this se tion we refer to the
solutions addressing Stub WMNs spe i ally.
4.6.1 IEEE 802.1D-based Solutions In this subse tion we go through a set of solutions addressing Stub WMNs that reuse the auto- on guration prin iples of Ethernet networks, namely IEEE 802.1D bridges. The IEEE 802.11 standard already de nes a way for inter onne ting APs wirelessly using the so- alled Wireless Distributed System (WDS) te hnol-
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
115
ogy [Gro07℄. WDS enables 802.11 APs to ommuni ate wirelessly, instead of using the wired ba khaul infrastru ture, as it is usual in urrent 802.11 networks. WDS uses a 4-address frame format [Gro07℄, works together with IEEE 802.1D bridging supported by urrent 802.11 APs, and is transparent to IEEE 802.11 stations. For ea h neighbor AP, an AP reates a WDS link;
on eptually, a WDS link is a virtual link whose endpoints appear as ports of the IEEE 802.1D bridges. Frame forwarding within the WDS is performed using the learning bridge me hanism. In order to guarantee a loop-free topology, the RSTP proto ol is then run over the network topology de ned. The disadvantage of this solution is that the WDS links between APs need to be
reated manually by software, resembling the Ethernet ables manually atta hed to the APs in the urrent deployment s enario. Thus, network setup and network re on gurations require manual on gurations, whi h makes the solution unsuitable for Stub WMNs. Lazy WDS is proposed as a solution to enable the automati establishment of WDS links. Lazy WDS is not do umented and it was never published as a standard. However, it is available in pra ti e in some APs
13 . The me h-
anism used to automati ally reate WDS links is simple. If an AP re eives a WDS pa ket from a neighbor AP it automati ally reates a WDS link to that node. Still, WDS links are unidire tional, so the same me hanism has to be employed in the opposite dire tion for establishing a bidire tional virtual link; this is performed upon the neighbor AP re eives a WDS pa ket from the urrent AP. No spe i proto ol is spe i ed in Lazy WDS to make this happen. As su h, in pra ti e, a new proto ol needs to be de ned to make the establishment of the WDS links truly automati . After the virtual links are established the usual approa h is to run the RSTP proto ol to guarantee a loop-free a tive topology. Wu
et al.
[WSC08℄ spe ify a proto ol to make
Lazy WDS automati , but this is a solution that does not use IEEE 802.1D bridges for pa ket forwarding; it is similar to the IEEE 802.11s tree-based routing solution des ribed in Se tion 4.6.2. Feuli
et al.
[FOB06℄ de ne a solution that uses IEEE 802.1D bridges
and the MSTP proto ol as basis.
The solution for es the reation of
n
spanning trees rooted at the node a ting as gateway between the WMN and the wired network infrastru ture, where
n
is on gurable.
This leads
to the establishment of alternative paths between ea h WMN node and the 13
http://wiki.laptop.org/go/Mesh_and_WDS
CHAPTER 4.
gateway.
NETWORK AUTO-CONFIGURATION
116
Subsequently, ea h mesh node tags a frame with a given VLAN
identi er, a
ording to the spanning tree sele ted for the urrent frame; a
+
preliminary spanning tree sele tion me hanism is de ned in [V 07a℄. The rest of the operation is a
ording to the standard IEEE 802.1D, taking VLAN bridging into a
ount. Yet, no solution is provided for establishing the virtual Ethernet links between WMN nodes; in [GVT
+ 06℄ another solution reusing
IEEE 802.1D bridges and the MSTP proto ol is proposed, whi h does de ne a solution to establish the virtual links between neighbor WMN nodes. In [YKI07℄ Yanagisawa
et al.
spe ify a modi ed RSTP version targeting Stub
WMNs. As mentioned in Se tion 4.2, in RSTP the bridge with lowest MAC address is sele ted, when the priority values are all equal. Therefore, if a new bridge with a lower MAC atta hes to the network, a hange in the root bridge will o
ur and spanning tree re onstru tions will be required. The modi ed RSTP proposed by Yanagisawa
et al.
represents a possible solution to this
problem. However, again no solution is provided regarding the establishment of the virtual links between WMN nodes. The major disadvantage of all these solutions is the need for a me hanism that opes with the pre-establishment of the virtual links between WMN nodes; otherwise, RSTP and MSTP do not work.
In addition, regarding
the solutions using MSTP as basis, the establishment of redundant spanning trees per gateway does not bring up any advantage in terms of network
apa ity, sin e the bottlene k is imposed by the use of a single gateway [JS03℄. So, unne essary omplexity is involved.
4.6.2 IEEE 802.11s Tree-based Solution As mentioned in Se tion 4.5.1, IEEE 802.11s de nes HWMP for path auto- on guration, whi h ombines rea tive path dis overy and tree-based proa tive routing. The tree-based solution was designed having Stub WMNs in mind. Here, we fo us on it and on its joint operation with the rea tive path dis overy solution. In the tree-based proa tive solution a node in the mesh network is on gured as the root MP. The root MP is usually onne ted to the wired infrastru ture and, in that ase, a ts as a Mesh Point Portal (MPP); an MPP is an MP plus an IEEE 802.1D bridge that enables interworking between the Stub WMN and an IEEE 802 external network. The root MP announ es itself to the other MPs, leading to an a tive topology de ned by an SPST, in terms of the ALM metri , rooted at the for-
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
117
mer. HWMP de nes two me hanisms for reating the SPST: the proa tive Path Request (PREQ) me hanism and the proa tive Root Announ ement (RANN) me hanism. In the proa tive PREQ me hanism the root MP periodi ally and proa tively broad asts a PREQ message with in reasing sequen e numbers. Upon re eiving the PREQ message, an MP reates or updates the path to the root MP in its lo al forwarding table and, if the PREQ re eived allowed the reation of a better or a newer path to the root MP, it broad asts an updated PREQ to its neighbors.
By using this me hanism, the PREQ originated
at the root MP is propagated to all nodes in the mesh network. After the re eption of the PREQ, an MP may need to send a Path Reply (PREP) in response to the PREQ (registration mode) in order to establish a path in the opposite dire tion, i.e., to the root. The need to send this response is de ned by a ag in luded in the PREQ message.
If the ag is not set, a
tree of paths from all MPs to the root MP is set up but the MPs are not registered proa tively at the root.
A sour e MP may alternatively send a
gratuitous PREP before sending the rst data frame, in order to register its address at the root and reate a path in the opposite dire tion; nonetheless, this me hanism only works for ommuni ation sessions initiated in the mesh. In the RANN me hanism the root MP periodi ally broad asts a RANN message with in reasing sequen e numbers.
Unlike what happens in the
PREQ me hanism, the RANN message is only used to disseminate the metri s of the paths from the root MP to the MPs a ross the mesh; it is not used to reate or update any path in the forwarding table. Upon re eiving the RANN message, an MP sends a uni ast PREQ requesting a path to the root MP. This message is sent to the neighbor from whi h the RANN message with lowest metri value has been re eived. The root MP sends a PREP message in response to the uni ast PREQ. This solution ensures the establishment of the best path between the urrent MP and the root MP. Besides registering at the root MP, an MP broad asts the updated RANN to its neighbors. In this way, the information on path hara teristi s (metri ) to the root is disseminated to all nodes in the WMN. In Stub WMNs, a subset of or even all the MPs are also APs; these are
alled Mesh A
ess Point (MAPs), as mentioned in Chapter 1.
In PREQ
and RANN, ea h MAP registers the terminals running behind it at the root MP, so that the latter knows how to forward tra oming from the wired
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
118
Wired network infrastructure
Wired network infrastructure Data Frame
Path Request Path Reply Root
Root
MP1
MP1
MP2
MP2
MP3
MP3
MP4
MP4
(a) indire t path Figure 4.11:
(b) dire t path
Illustration of the joint use of the IEEE 802.11s tree-based
proa tive and rea tive path dis overy solutions.
infrastru ture and destined to a terminal. The PREQ and RANN me hanisms enable the reation of an SPST that only de nes the optimal solution for ommuni ation between ea h MP and the root MP, and
vi e versa.
Therefore, for intra-WMN ommuni ation
HWMP de nes the joint use of the proa tive tree-based and the rea tive path dis overy solutions. In this approa h, two MPs start ommuni ating using the path along the tree, as illustrated in Fig. MP4.
Afterwards, the destination MP, MP4 in Fig.
4.11a for MP3 and 4.11, is informed by
the root MP through a ag in the header of the data frame, that the sour e node belongs to the WMN. Upon re eiving the data frame, the destination MP starts a rea tive path dis overy pro edure to establish a dire t path; in Fig.
4.11b we illustrate the path dis overy pro edure and the dire t path
established between MP3 and MP4.
Note that multiple data frames may
travel along the indire t path, in both dire tions, until the dire t path is set. The IEEE 802.11s tree-based solution is simpler than Feuli's and Greve's solutions, whi h require the maintenan e of multiple spanning trees. Also, it enables the establishment of the virtual links and the reation of the SPST using a single me hanism, PREQ or RANN. On the other hand, regarding intra-WMN ommuni ation, 802.11s de nes an approa h to establish the optimal path between peer MPs. Although simpler, IEEE 802.11s still introdu es unne essary omplexity on erning Stub WMNs. The use of a 6address format introdu es further overhead, when ompared to the 4-address WDS format. The advantage of using a 6-address format is to avoid maintaining routing information at intermediate MPs regarding external nodes.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
119
However, in Stub WMNs, this is not an issue. MPs/MAPs are expe ted to be devi es similar to the urrent 802.11 APs supporting IEEE 802.1D bridging.
802.11 APs already have to maintain routing information for tens or
a few hundreds of nodes. The s enario for MPs/MAPs will be similar, as the Stub WMN will simply be used to repla e an in exible and ostly wired Ethernet infrastru ture.
Moreover, intra-WMN ommuni ation will rarely
happen. As su h, the approa h for intra-WMN ommuni ation just brings up unne essary omplexity and represents an optimization for a marginal
ase. Finally, when ompared to the solutions aforementioned, the 802.11s tree-based solution has a drawba k: it requires the registration of the terminals running behind ea h MAP at the root MP. This implies additional overhead and omplexity.
4.6.3 Other Layer-2 Solutions In this se tion we present additional Layer-2 solutions addressing Stub WMNs. An illoti
et al.
[BCGP06℄ proposed a Layer-2 solution for inter onne t-
ing multi-hop ad-ho networks to the Internet. DHCP is used for assigning global IP addresses to the nodes forming the ad-ho network. noun es the gateway to the Internet based on a
HNA
OLSR an-
message advertising
the 0.0.0.0/0 default route and establishes routes within the ad-ho network and towards the gateway. Given that there is not a single broad ast domain established within the ad-ho network, the solution runs a DHCP Relay on ea h ad-ho node, so that the DHCP proto ol an run between ea h ad-ho node and the DHCP server running in the wired infrastru ture. The main disadvantage of this solution is that it is tied to IPv4 and its ompanion proto ols, su h as DHCP. On the other hand, the proposed ar hite ture does not support the atta hment of lega y nodes. Nodes atta hing to the multihop network have to run OLSR and a new proto ol when they rst atta h to the network, so that the DHCP pro edure is triggered a ross the multi-hop network. Also, the proposed solution is more omplex and less e ient than the IEEE 802.11s tree-based solution. It reates paths between every pair of mesh nodes proa tively. This is a waste of resour es in Stub WMNs, where almost all tra omes from/goes to the gateway. The Ad-ho Wireless Distribution Servi e (AWDS) solution [Pro℄ de nes a routing proto ol based on OLSR as well, alled AWDS Link State Rout-
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
ing (ALSR). Every mesh node sends out
Hello
120
messages periodi ally, whi h
enable neighborhood dis overy. The list of neighbors is then ooded a ross the network by ea h node.
Subsequently, the mesh nodes reate a om-
plete view of the network topology and ompute the shortest paths using
Dijkstra's
algorithm, for instan e.
An AWDS network works similarly to
an IEEE 802.11s network. It behaves as an Ethernet LAN, from the upper layers perspe tive, ompatible with IEEE 802.1D bridging. Yet, the ALSR proto ol is more omplex and less e ient than the IEEE 802.11s tree-based solution. On the other hand, in [Pro℄ the information about AWDS solution is limited. For instan e, no information is provided about how the integration with external networks is a tually performed. Also, details are missing about the address format used in that ase and about the way a mesh node nds out the address of the node a ting as gateway/proxy for the external network. Xu
et al.
[XPN04℄ proposed a solution based on Layer-2 bridging that
runs within an ad-ho network and extends the overage of an 802.11 AP
onne ted to the wired infrastru ture. rooted at the 802.11 AP is established. dierent me hanism.
Hello
As in 802.11s tree-based, an SPST Yet, the SPST is reated using a
Ea h ad-ho node broad asts a
Hello
message.
The
in ludes the MAC address of the urrent node, the MAC address of
the node sele ted as the parent in the tree rooted at the AP, its level in the tree, and a ag stating whether it is the AP; the level represents the depth of a node in the tree. Initially, the level, the parent address, and the ag are set to 0; the ex eption is the AP, whi h sets the ag to 1. As the nodes start re eiving
Hello
messages from their neighbors, they are able to
pi k up a parent node in the tree.
The neighbor with the lowest level is
sele ted; if there are more than one neighbor with the same level, one is randomly sele ted. However, in ontrast to the 802.11s tree-based solution, in pra ti e, this means the solution is impli itly limited to the hop ount metri . Additionally, rather than using 802.1D bridges, the authors de ne their own Layer-2 bridging me hanism at MAC layer. On the other hand, the solution only works when ommuni ation sessions are initiated by ad-ho nodes, it does not provide the means to support lega y nodes, and it does not allow ommuni ation between ad-ho nodes, neither dire tly nor indire tly.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
121
4.6.4 Layer-3 Solutions In the ontext of Mobile Ad ho NETworks (MANETs) several me hanisms have been proposed to extend a wired network infrastru ture [BCM10℄ [TRY08℄. Proposed solutions an be divided in two dierent sets. There are solutions based on routing proto ols, su h as OLSR, whi h announ e the gateway providing a
ess to the Internet within a mesh network and reate the path between ea h node and the gateway. The se ond set in ludes solutions that propose me hanisms independent of the ad-ho routing proto ol in use, where a gateway periodi ally announ es its presen e within the network using some spe i proto ol. The main disadvantage of these solutions is the use of a Layer-3 approa h, whi h requires the de nition of new IP auto- on guration me hanisms to distribute global IP addresses. Also, in a
ommuni ation paradigm where IPv4 and IPv6 will oexist, these solutions are limited sin e they are mostly IPv4-only or IPv6-only. On the other hand, in general, they are too omplex regarding Stub WMNs.
4.7 Summary Network auto- on guration is ru ial for deploying PANs and Stub WMNs. The network auto- on guration problem an be divided in two parts: 1) path auto- on guration and 2) IP address auto- on guration. Along this hapter we dis ussed a set of auto- on guration solutions, whose main hara teristi s are summarized in Table 4.1. In the table, solutions are grouped by Generi solutions, PAN solutions, and Stub WMN solutions a
ording to the organization adopted throughout this hapter. The olumn Single/Multi-te h de nes whether the urrent solution supports a single or multiple Layer-2 te hnologies.
The olumn Network Layer identi es the IP versions sup-
agnosti , IPv4, IPv6, and IPv4 & IPv6 ; in this ontext, agnosti means IP-agnosti and IPv4 & IPv6 means simultaneported, with four possible values:
ous auto- on guration of IPv4 and IPv6 addresses. The olumns UPA and BPA refer to the approa hes followed for uni ast and broad ast path auto on guration, respe tively. For UPA the possible values are
SPST, arbitrary
SPST, shortest path, and rst path, while for BPA the possible values are ooding, SPST, arbitrary SPST, random spanning tree, multiple SPSTs, and MPR-based. The olumns ENA and Lega y nodes state whether the solution enables external network a
ess and supports lega y nodes, respe tively.
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
122
The olumn DSA de nes whether dual-sta k IP address auto- on guration is performed e iently and, nally, the olumn Complexity level states the degree of omplexity as
simple
or
omplex.
When it omes to uni ast path on guration solutions two main types are available: the solutions based on ad-ho routing proto ols (in bold in Table 4.1) and the solutions onsidering a tree-based routing approa h (underlined in Table 4.1).
The rst type omprises rea tive and proa tive proto ols.
Rea tive proto ols do not ensure shortest routes, in terms of a given routing metri , unless a signi ant amount of signaling is involved in the route dis overy pro ess. Also, rea tive proto ols introdu e route dis overy delays, whi h may be harmful for some appli ations.
However, rea tive proto ols
are simpler than their proa tive ounterparts.
Proa tive routing proto ols
enable shortest routes and have them immediately available. This is a hieved at the ost of more signaling overhead and omplexity. The se ond type of uni ast path auto- on guration solutions in ludes simpler solutions de ning a single spanning tree as the a tive network topology. The sele ted spanning tree is not optimal, manual on guration is still required, or the solutions are too omplex for the target s enario. Regarding broad ast path on guration, the majority of the solutions
onsider pure ooding; while simple this is not the most e ient approa h. IEEE 802.1D bridges, OLSR, LUNAR, and the solution proposed by Feuli
et al.
do de ne more e ient broad ast approa hes. However, they either
de ne a sub-optimal spanning tree or introdu e more omplexity. Most of the solutions support IPv4 and IPv6, but none provides the means for e ient path auto- on guration and IP address auto- on guration, when dual-sta k nodes are onsidered (see DSA olumn).
For dual-sta k
nodes, two instan es of the same proto ol run at the same time and no me hanism is urrently de ned to sele t the proper version to be used a
ording to the network ontext; this is both redundant and ine ient. Several solutions provide the means for integrating lega y nodes and networks (see Lega y nodes olumn), but in most of the ases this involves manual on guration or an additional auto- on guration me hanism not spe i ed.
In pra ti e, the majority of solutions do not really support
lega y nodes, whi h makes migration and deployment di ult. In general, state of the art solutions are omplex regarding their target s enario; see Table 4.1 where we qualify the solutions' omplexity level
CHAPTER 4.
NETWORK AUTO-CONFIGURATION
123
a
ording to the orresponding hara terization provided in this hapter. Finally, all the solutions presented in Table 4.1 are fo used either on the path auto- on guration or on the IP address auto- on guration omponents, and do not address the network auto- on guration problem in a holisti way. Therefore, there is a la k of a simple and e ient solution (1) addressing the network auto- on guration problem holisti ally, (2) oping with the ine ien ies oming up with the oexisten e of two IP versions, and (3) supporting lega y nodes for a straightforward deployment.
Table 4.1: Summary of the main hara teristi s of the state of the art network auto- on guration solutions.
Solution
Single/Multi-te h
Network Layer
UPA
BPA
ENA
Lega y nodes
DSA
Complexity level
multi " " " " " " " " " " " " " " " " " " " " " " " " "
agnosti " " " " IPv4, IPv6 " " " " " " IPv4 IPv6 IPv4, IPv6 IPv6 IPv4, IPv6 IPv4 & IPv6 " " IPv4 agnosti " " " "
n/a arbitrary SPST n/a shortest path " rst path " shortest path rst path shortest path " " n/a " " " " " " " rst path shortest path " " rst path unde ned
n/a arbitrary SPST n/a n/a multiple SPSTs ooding " " " " " MPR-based n/a " " " " " " " random spanning tree ooding " " " unde ned
X
X
" " " " " " " " " " "
" " " "
n/a " " " " ine ient " " " " " " n/a " ine ient n/a ine ient " " " n/a " " " " "
simple "
omplex " " " " " simple
omplex " " simple " " " " " " "
omplex " " " " "
Generi solutions
Learning bridge 802.1D bridge MSTP SPB RBridges
DSR AODV AODV-DR AODVjr DYMO DSDV OLSR
DynLL IPv6 SLAC DHCP DHCPv6 PD MANET auto onf Dual-sta k DHCP Trial-and-error AHCP
LUNAR MCL/LQSR MyMANET Lilith VLR Ana4
PAN solutions
Bluetooth PAN pro le 802.11, UWB, ... 802.15.5
802.11s
Personal Hub Personal Mesh Continued on next page . . .
X
" " " " "
" " " " "
X
" " " " " " " " " "
X
"
X
" " unde ned
unde ned
single agnosti n/a n/a X n/a
omplex " " shortest path " " " " simple " " arbitrary SPST ooding " X " " " " shortest path " " " "
omplex " IPv4 n/a n/a " " " simple " " " " " " "
omplex n/a not appli able, not available; UPA Uni ast Path Auto- on guration; BPA Broad ast Path Auto- on guration; ENA External Network A
ess; DSA Dual-Sta k Auto- on guration; X Supported; Not supported; " - equal to the previous ell in the olumn.
Solution
Eri sson's patent DVNI
Engelstad et al. Madhvani PACWOMAN MAGNET Stub WMN solutions
WDS Lazy WDS Feuli et al. Yanagisawa et al. 802.11s (tree-based)
An illoti et al. AWDS Xu et al. MANET solutions
14 15
Single/Multi-te h single multi " " " " single " " " single multi single " multi
From the gateway point of view Rooted at the gateway
Network Layer
Table 4.1 Continued
UPA
BPA
IPv4, IPv6 agnosti IPv4, IPv6 " IPv6 IPv4, IPv6
n/a SPST14 rst path " " shortest path
n/a ooding " " " "
agnosti " " " " IPv4 agnosti " IPv4, IPv6
n/a " shortest path n/a SPST shortest path " SPST unde ned
n/a " SPST15 n/a ooding " " " "
ENA
Lega y nodes
X
X
X
"
" unde ned
X
X
"
X
X
" " "
" " "
X
X
" " " "
X
"
DSA
Complexity level
n/a " n/a n/a n/a " " " ine ient
omplex simple
omplex simple "
omplex " simple
omplex
ine ient n/a ine ient n/a " ine ient
omplex " " " " "
Chapter 5
Simple and Flexible Auto- on guration Framework In Chapter 2, 3, and 4 we reviewed the relevant PAN and LAN wireless te hnologies, the relevant types of spanning trees used to de ne a tive network topologies, the algorithms used to ompute these spanning trees, and the solutions for the network auto- on guration problem. In Chapter 4 we pointed out the problems of existing network auto- on guration solutions; in general, they are in omplete and omplex solutions and they do not support lega y devi es. This hapter des ribes our proposal on network auto- on guration. The auto- on guration framework proposed the Simple and Flexible Auto on guration (SFA) framework de nes network auto- on guration solutions for PANs and Stub WMNs. We start by presenting the ar hite ture of the SFA framework. Then, we des ribe the two instan es of the framework, one developed for PANs the Auto- on guration and Self-management of Personal Area Networks (ASPAN), and the other for Stub WMNs the Wi-Fi network Infrastru ture eXtension (WiFIX).
5.1 Ar hite ture of the SFA Framework SFA is a network auto- on guration framework fo used on multi-te hnology PANs and Stub WMNs, and it deals with the network auto- on guration problem in a holisti way. The two networking s enarios addressed by SFA were introdu ed in Chapter 1 and are illustrated in Fig. 5.2 again. SFA opes
127
CHAPTER 5.
SFA FRAMEWORK
128
IC module optional enforceIPconf()
invokeLegacyMechanism()
Legacy IP auto-configuration mechanisms
PaC module
Learning Bridges
triggerBC()
triggerGC()
configActiveInterfaces()
Figure 5.1: The Simple and Flexible Auto- on guration Framework Ar hite ture, where the dotted arrows mean optional intera tions.
with the establishment of paths and the on guration of the IP parameters required to establish network onne tivity. SFA assumes that one-hop onne tivity is pre-established using one or more of the wireless te hnologies mentioned in Chapter 2 and it extends onne tivity beyond the single-hop domain. As shown in Fig. 5.1, SFA onsists of two modules: the Path Con guration (PaC) module and the IP Con guration (IC) module; the dotted arrows represent optional intera tions between the SFA me hanisms.
The
PaC module addresses the on guration of multi-hop onne tivity by means of the establishment of network paths; sin e SFA uses a Layer-2 approa h for this purpose, we use the term path instead of route, in order to avoid
onfusion with routes established using Layer-3 routing proto ols. The IC module deals with the establishment of IP onne tivity by on guring the needed IP parameters at ea h network node, taking into a
ount the oexisten e of two IP versions and using lega y IP auto- on guration me hanisms for a tually performing the on guration of IP parameters. The PaC module onsiders the use of traditional Learning Bridges together with a Spanning Tree (ST) me hanism tailored to the spe i wireless networking s enario. The ST me hanism deals with all needed pro edures to
CHAPTER 5.
SFA FRAMEWORK
129
PAN PAN
UWB
UWB
Bluetooth
Wi-Fi
Wi-Fi
Ethernet
UWB
Internet UMTS
PAN
Bluetooth USB
(a) PAN s enario
wired terminal
Internet IP Gateway
wired infrastructure
MAP MAP MAP MAP MAP MAP
(b) Stub WMN s enario Figure 5.2: The two networking s enarios addressed by the SFA framework.
CHAPTER 5.
SFA FRAMEWORK
130
establish a spanning tree among the nodes parti ipating in the network; this in ludes a spanning tree algorithm to ompute the a tive spanning tree, the
on guration of the network interfa es that must be a tive at ea h network node, and the re on guration of the spanning tree when topology hanges o
ur. Upon a single a tive spanning tree is on gured, learning bridges are able to (1) learn automati ally the path towards any node belonging to the network, thanks to their built-in learning me hanism, and (2) forward pa kets using the learnt paths. Due to the use of a single a tive spanning tree, broad ast tra is handled in an e ient way. The ST me hanism intera ts with Learning Bridges for enfor ing the a tive network interfa es. When the network has no gateway available to the outside world, the ST me hanism triggers the Basi Conne tivity (BC) me hanism of the IC module. These intera tions are shown in Fig. 5.1. The IC module is omposed of three building blo ks: Lega y IP auto on guration me hanisms, BC me hanism, and GC me hanism.
The IC
module does not implement any IP auto- on guration me hanism by itself. Rather, it uses the lega y IP auto- on guration me hanisms, su h as DHCP and IPv6 SLAC, and de nes the BC me hanism to e iently deal with IP auto- on guration in a networking ontext where two IP versions
oexist but are usually not run simultaneously. The BC me hanism is a meta auto- on guration me hanism that simply or hestrates the IP on guration pro edure. A
ording to the lega y IP auto- on guration me hanisms supported within the network, the BC me hanism sele ts and invokes the proper lega y IP auto- on guration me hanism for a tually on guring the required IP parameters. The BC me hanism assumes dual-sta k nodes and is fo used on IPv4-only and IPv6-only networks. This is aligned with the urrent and future envisioned IP networking s enario. Most of the terminals are already dual-sta k and among the mainstream operating systems su h as Windows XP/Vista/7, Ma OS, Linux OS, Android, Symbian OS, Windows Mobile, and iPhone OS, only the iPhone OS is IPv4-only; on the other hand, the
oexisten e of IPv4-only and IPv6-only is envisioned with the depletion of IPv4 addresses, as mentioned in Chapter 1. The IC module may optionally in lude the on guration of the gateway towards the outside world the Gateway Con guration (GC) me hanism. This is an optional part, sin e in some networks the gateway may not exist or be prede ned. The GC me hanism olle ts information about the a
ess links available within the network,
CHAPTER 5.
SFA FRAMEWORK
131
sele ts the best a
ess link, in terms of bandwidth, and on gures the orresponding node as the gateway; this onsists in turning the node supporting the sele ted a
ess link into an IPv4/IPv6 router. The GC me hanism manages the set of available a
ess links dynami ally. If the a
ess link in use be omes unavailable, it sele ts the new best a
ess link and on gures the new gateway.
Note that, as illustrated in Fig. 5.1, if this optional part is
used, upon nishing its work, the ST me hanism triggers the GC me hanism. In turn, when nished, the GC me hanism intera ts with the BC me hanism to enfor e the IP (re-) on guration a
ording to the on gured gateway; in this ase, the IP version and the lega y IP auto- on guration me hanism to be used are enfor ed by the GC me hanism a
ording to the sele ted a
ess link and the lega y IP auto- on guration me hanisms supported by the gateway node. The PaC and IC modules do not ne essarily run within the same node. It depends on the s enario.
In the PAN s enario, where ea h devi e may
simultaneously be a terminal and a relay node, the two modules run in the same node. In Stub WMNs, the MAPs forming the mesh network run the PaC module and the terminals atta hing to the Stub WMN run the IC module.
Also, the modules may run in sequen e or at dierent moments.
In the PAN s enario, PaC and IC run in sequen e, while in the Stub WMN s enario they run at dierent moments. In PANs, devi es rst perform path
on guration. The result of this pro ess is the establishment of a spanning tree as the a tive network topology. Afterwards, the IC module is run for auto- on guration of IP parameters. In Stub WMNs, we assume that mesh nodes are not IP nodes and that the terminals atta h to the Stub WMN when the mesh network is already formed. So, the PaC module aims at establishing a spanning tree among mesh nodes. The IC module runs for terminal auto on guration only, after the Stub WMN was formed. The exe ution sequen e of the SFA me hanisms for ea h type of network is illustrated in Fig. 5.3, where the lega y building blo ks are shown in gray. In Fig. 5.3a we show the typi al exe ution sequen e for a PAN; on erning a PAN without any a
ess link to the outside world, the GC me hanism is absent and the BC me hanism is triggered by the ST me hanism.
Fig.
5.3b illustrates the
exe ution sequen e for a Stub WMN. The dashed arrow onne ting the ST me hanism to the BC me hanism means that the BC me hanism is exe uted after the ST me hanism has run and set up the mesh network.
CHAPTER 5.
SFA FRAMEWORK
ST Mechanism
Learning Bridges
132
ST Mechanism
Learning Bridges
triggerGC()
GC Mechanism enforceIPconf()
BC Mechanism
Legacy IP auto-configuration mechanisms
Legacy IP auto-configuration mechanisms
BC Mechanism
(a) PAN
(b) Stub WMN
Figure 5.3: The exe ution sequen e of the SFA me hanisms for a PAN and a Stub WMN, where the dashed arrow between ST and BC me hanisms means that BC runs only after ST has run.
The modularity of the SFA framework allows its in remental deployment and its easy adaptation to the target networking s enario. While the PaC and IC modules are proposed as part of the SFA framework, they an run as standalone modules. For instan e, in a given networking s enario, the PaC module may be used to auto- on gure multi-hop paths, but IP onne tivity may be established using some lega y me hanism, su h as DHCP, or the
urrent trial-and-error me hanism used by dual-sta k IP nodes. Modularity is also present in the modules themselves.
For the PaC module, the ST
me hanism is ustomizable a
ording to the target s enario. On the other hand, the IC module is exible enough to enable the in lusion of new IP auto- on guration me hanisms. Also, the BC me hanism is fundamentally de ned for e ien y reasons; IP on guration an still work without it. This modular property of SFA broadens the s ope of the framework and makes it useful for networks other than those onsidered herein.
5.2 Solution for Personal Area Networks In this se tion we instantiate SFA with respe t to multi-te hnology PANs. This instantiation is named Auto- on guration and Self-management of Personal Area Networks (ASPAN). Fig. 5.4 shows the SFA instan e onsidered for PANs and used to de ne the ASPAN solution.
ASPAN assumes that
PAN devi es work simultaneously as terminals and Learning Bridges, and it de nes the transportation of all signaling messages on top of Layer-2 frames.
CHAPTER 5.
SFA FRAMEWORK
133
IC module enforceIPconf()
invokeLegacyMechanism()
Legacy IP auto-configuration mechanisms
PaC module
Learning Bridges
triggerBC()
triggerGC()
configActiveInterfaces()
Figure 5.4: ASPAN the SFA instan e for PANs.
The ASPAN referen e s enario, shown in Fig. 5.5, onsists in a PAN formed by devi es using multiple wireless te hnologies and using two a
ess links Wi-Fi and Ethernet available at two time instants
T1
and
T2 , and support-
ing dierent IP versions.
5.2.1 Master-Slave Paradigm ASPAN follows a master-slave paradigm, for three major reasons. Firstly, in PANs devi es may be heterogeneous in terms of apabilities; for instan e, a laptop is more powerful than a PDA whi h, in turn, is more powerful than a Bluetooth wristwat h.
So, it is suitable to sele t the most apable
devi e as the PAN master, in order to minimize the eort employed by less
apable devi es in ontrol and management tasks. Se ondly, there are PAN devi es that are arried everywhere with the user. Examples are the mobile phone, the PDA, the Tablet PC, or even the Personal Hub proposed by some solutions des ribed in Chapter 4; also, these devi es have urrently high memory and pro essing power. The ubiquity and the high apability are two
hara teristi s that make them good andidates for being PAN masters in a master-slave paradigm. Thirdly, the adoption of a master-slave paradigm enables the use of entralized solutions, whi h are usually simpler and more
CHAPTER 5.
SFA FRAMEWORK
134
DHCPv6 server
PAN Wi-Fi
(IPv6)
T1
Video Camera
AP
UWB Wi-Fi
Access Router Bluetooth Laptop
Tablet
Mobile phone
T2
DHCP server
(IPv4)
Ethernet Access Router
Figure 5.5: The ASPAN referen e s enario.
e ient than their distributed ounterparts. In ASPAN, the PAN master is de ned stati ally and is kept along the time. The PAN master may be a mobile phone or other devi e always arried by the user. The other devi es are alled PAN slaves and rea t to the
ommands of the master.
The PAN master ould also be ele ted among
the devi es forming the PAN, but, from our point of view, this would add
omplexity to the solution. The PAN master manages the PAN on guration, in luding (1) the dis overy and maintenan e of the network topology, (2) the enfor ement of the a tive tree topology required by Learning Bridges, (3) the dete tion of the potential Points of Atta hment (PoAs) i.e., the a
ess links enabling onne tivity to the outside world, (4) the sele tion of the best PoA, and (5) the announ ement of the IP version and the lega y IP auto- on guration me hanism that shall be used to establish IP onne tivity. The master has global knowledge about the PAN; the slaves a t a
ording to the ommands of the master. A PAN gateway an be either the master or a slave.
CHAPTER 5.
SFA FRAMEWORK
135
5.2.2 PAN Spanning Tree Me hanism Topology Dis overy and Maintenan e A single me hanism is used for topology dis overy and topology maintenan e.
It onsists in an adapted version of the me hanism proposed by
Vasudevan
et al.
[VKT04℄ for ele ting a leader within a MANET. In the
proposed me hanism, PAN devi es are identi ed by MAC addresses.
If a
PAN devi e has multiple interfa es, the lowest MAC address is sele ted as its identi er. The me hanism works as follows.
Topology Refresh (TR) message through The TR is uniquely identi ed by the mas-
The PAN master broad asts a all its lo al network interfa es.
ter's MAC address and a sequen e number, whi h is in remented ea h time a new
TR
is sent. When a PAN slave re eives a
TR,
its behavior depends
on the number of network interfa es it supports. If the PAN slave is a single interfa e node, it immediately sends an bor from whi h it re eived the
TR.
A k
message in uni ast to the neigh-
In this ase, the
A k
simply in ludes
the urrent node's MAC address and the lo al network interfa e identi er, whi h is an integer value with lo al meaning only; this information is subsequently used by the PAN master to enfor e the a tive spanning tree. If the PAN slave has multiple network interfa es and it is the rst time it re eives the
TR
message, the slave retransmits the
through all lo al network
TR messages with the same sequen e number are silently dis arded and an A k is sent to ea h neighbor from whi h a dupli ate TR was re eived. In order to make the topology dis overy pro edure e ient, the A k messages are interfa es, ex ept that from whi h the
TR
TR
was re eived; all subsequent
aggregated at ea h intermediate slave instead of dire tly being sent by ea h slave to the master. Ea h multi-interfa e slave waits for a timeout interval, set by the PAN master using the
TR message, for the A k
messages oming
from its neighbors. In order to set the timeout values, the master in ludes in the
TR
message two elds: the
slave-wait-time
and the
de rement-time ;
slave-wait-time eld is de remented by the value in luded in the de rement-time eld. Upon re eiving the TR the urrent slave knows that it must wait slave-wait-time milise onds before sending an A k. During
at ea h hop, the
its timeout period, ea h slave olle ts the topologi al information in luded in the
A k
messages re eived from its neighbors. When timeout expires, the
urrent slave aggregates all that information into an
A k
message and sends
CHAPTER 5.
SFA FRAMEWORK
136
it in uni ast to the neighbor from whi h it re eived the rst
TR. Ea h A k
message in ludes a set of edges modeling the links between neighbor devi es in the PAN topology; an edge is hara terized by the MAC addresses of the
onne ting nodes, the lo al interfa es IDs, and the link metri . The data rate of the link is onsidered as metri , similarly to what is de ned in AODV-DR. This pro ess is repeated at ea h slave until eventually the master be omes aware of the whole PAN topology. The
TR
and
A k
messages are de ned as follows, using ABNF syntax
[CO97℄:
TR = message-type sequen e-number master-addr slave-wait-time ; timeout for slave re eiving the TR de rement-time ; value that must be subtra ted from ; slave-wait-time at ea h hop ; traversed by TR A k = message-type sequen e-number sour e-addr ifa e-ID ; lo al interfa e identifier *edge ; set of edges between PAN devi es The length of ea h eld is provided in Table 5.1. The
A k
edge
eld in luded in
is de ned by two MAC addresses (12 bytes), two interfa e IDs (1 byte),
and a metri hara terizing the link it models (2 bytes). Note that an may in lude zero or more
edge
A k
elds; in ABNF syntax this is represented by
the `∗' symbol. The topology dis overy pro edure is impli itly used by ASPAN to establish a ontrol tree, whi h is then used by the PAN master to distribute
on guration information to the slaves. The ontrol tree is reated as follows. Ea h slave sele ts the node from whi h it re eives the rst
TR message
as its parent node in the ontrol tree. In the opposite dire tion, ea h slave is informed that it was sele ted as a parent node of a node an aggregate
A k
message from
X.
X,
upon re eiving
The ontrol tree is dynami and may
hange per topology refresh period. Still, this is not a problem, as the tree is
CHAPTER 5.
SFA FRAMEWORK
137
Master TR 1 0
Ack 1
0
0
2
3 1
1
0
2
1
4
0
5
Figure 5.6: Illustration of the ASPAN topology dis overy pro edure for a 5-node PAN and the ontrol tree onstru ted during the topology dis overy pro edure (in bold).
only used for distributing ontrol information and it does not hange during the transmission of su h information. The topology dis overy pro edure is illustrated in Fig. 5.6 for a 5-node PAN, where Node 1 is the PAN master and the interfa e IDs for ea h node are shown next to ea h edge endpoint. Node 1 broad asts two per interfa e. Upon re eiving the
TR messages, one
TR message, Node 2 and Node 3 retransmit
it a ross interfa e 1 and interfa es 1 and 2, respe tively. In this example, we assume that the
TR
message retransmitted by Node 2 is the rst re eived
by Node 4, and that, before Node 4 retransmits the from Node 3. an
A k
The latter is a dupli ate
TR,
TR, it re eives the TR
so Node 4 immediately sends
to Node 3. After timeout, Node 4 sends an aggregate
information about the edge it re eives the
TR
(4, 3).
A k
in luding
Node 5 is a single interfa e slave. When
from Node 3, it immediately sends an
timeouts, Node 2 and Node 3 transmit their aggregate
A k
A k.
After their
messages to the
A k in ludes information about the edges (3, 4) and (3, 5), A k in ludes information about the edges (4, 3) and (2, 4).
master. Node 3's while Node 2's
Upon re eiving these messages, the master is able to onstru t the topology graph. The ontrol tree onstru ted during the topology dis overy pro edure is shown in Fig. 5.6 using bold lines. In ASPAN, topology maintenan e is a
omplished by simply running the topology dis overy pro edure periodi ally; by default, on e per se ond.
CHAPTER 5.
SFA FRAMEWORK
138
If some topology hange is dete ted, a new a tive topology is on gured a
ording to the pro edure des ribed in the next subse tion.
The master
assumes that a topology hange has o
urred if it does not re eive any information regarding some edge or node after three
TR
periods. During the
topology dis overy pro edure, if after the timeout period an sequen e number of the urrent
TR
A k
with the
is re eived by a given slave, the
A k
is
dire tly forwarded to the master. In pra ti e, this ontributes to in rease the topology dis overy overhead. So, when this o
urs, the
de rement-time
slave-wait-time
and
parameters an be adjusted by the PAN master, in order to
avoid su h event in the next topology dis overy period.
A tive Topology Con guration and Path Establishment At the PAN master, the PAN topology is represented by a graph. The graph is then used as a basis for omputing the a tive network topology using a new spanning tree algorithm alled
Campos's
algorithm, whi h is
presented in the next subse tion. After the omputation of the a tive spanning tree, the required on gurations need to be enfor ed throughout the PAN. For that purpose, the PAN master issues a
Con g
message with the
per-slave on gurations. The ontrol tree reated during topology dis overy is used to forward a
Con g
message.
Con g
in ludes a set of tuples of the
form (slave MAC address, set of interfa es to a tivate). In order to redu e
Con g messages, the PAN master sends dierent Con g messages network interfa e; the Con g message sent through a given lo al inter-
the size of per
fa e only in ludes on gurations for the PAN slaves a
essible through that
Con g is further redu ed as it travels down the ontrol re eiving Con g, ea h PAN slave sear hes for its on guration
interfa e. The size of tree. Upon
tuple, extra ts the tuple from the message, so that it is not unne essarily propagated downwards, and forwards the message to its hildren in the ontrol tree, if it is not a leaf node in the ontrol tree. The
Con g
message is
transmitted in uni ast. For the wireless te hnologies onsidered in Chapter 2, this provides message delivery guarantee. In order to on rm that the a tive topology on guration is omplete, upon re eiving the
Con g
message and performing the orresponding lo al
on gurations, the leaf slaves in the ontrol tree send an soon as a non-leaf slave re eives the
A k
A k
upwards. As
messages from all its hildren, it
knows that the new a tive topology ordered by the PAN master is fully
CHAPTER 5.
SFA FRAMEWORK
Message TR
A k
Con g
Fields message-type sequen e-number master-addr slave-wait-time de rement-time message-type sequen e-number sour e-addr ifa e-ID edge message-type sequen e-number master-addr node-addr a tive-ifa es
139
Size (bytes) 1 2 6 2 1 1 2 6 1 15 1 2 6 6 1
Table 5.1: Length of the elds of the messages used in the topology dis overy and a tive on guration pro edures.
on gured. It then noti es its parent in the ontrol tree by means of an
A k
too. This pro ess is repeated until the master is nally noti ed. At the end of the a tive topology on guration, ea h PAN devi e triggers the PAN BC me hanism to on gure IP onne tivity. As soon as the a tive topology is on gured, ASPAN runs the topology dis overy pro edure periodi ally to keep tra k of the PAN topology. Data frames themselves an be used to establish the paths between peer PAN devi es, due to the use of Learning Bridges. Re all that if a Learning Bridge does not know the path towards the destination, it simply sends the frame through all lo al ports ex ept that from whi h it re eived the frame. However, in shared media su h as IEEE 802.11, this pro edure requires that ea h PAN devi e pla es its NICs in promis uous mode. The operation in promis uous mode brings up some problems. On the one hand, the PAN devi es have to pro ess every single frame observed in the medium; this in urs (1) more pro essing than in non-promis uous mode and (2) energy wastage. On the other hand, some NICs may not support the promis uous mode. ASPAN does not rely on the promis uous mode. Instead, it uses the lega y proto ols ARP or NDP, depending on the IP version being used by the PAN, for impli it path establishment.
CHAPTER 5.
SFA FRAMEWORK
PAN Master
140
PAN h-hop slaves
PAN H-hop slaves
computeST() disableFF() configAI() Config disableFF() configAI() Config configAI()
Ack Ack
enableFF()
enableFF() flushAT()
Config flushAT() Config flushAT()
FF — Frame Forwarding ST — Spanning Tree AI — Active Interfaces AT — ARP Table Figure 5.7:
Message sequen e hart illustrating the ASPAN a tive topol-
ogy re on guration pro edure when a non-leaf node leaves the PAN (h-hop means
h
hops away from the master in the ontrol tree and
H
is the maxi-
mum number of hops between the master and a slave in the ontrol tree).
Every time an IP node wants to ommuni ate with a peer it needs to know the destination MAC address related to the destination IP address. In IPv4, the ARP proto ol is used for this purpose. When the sour e does not know the destination MAC address, it broad asts an the
ARP REQUEST
ARP REQUEST. In ASPAN,
is sent a ross the a tive spanning tree and enables
Learning Bridges to learn the path to the sour e of the the
ARP REPLY
ARP REQUEST ;
sent ba k by the destination impli itly establishes the path
in the opposite dire tion. In order to for e the use of the ARP pro edure for path establishment, ASPAN sets the lifetime of the ARP table entries with the same lifetime as the Learning Bridges forwarding table entries. During the PAN lifetime, one or more PAN devi es may leave the network. The PAN master is responsible for dete ting those events and re on guring the a tive topology, if required.
If the node leaving the PAN is a
CHAPTER 5.
SFA FRAMEWORK
141
leaf node in the a tive topology, no re on guration is needed. If the node leaving the PAN is a non-leaf node, a new a tive spanning tree needs to be
on gured. ing
In this ase, the master omputes the new spanning tree us-
Campos's
algorithm, disables frame forwarding, on gures its new set
of a tive interfa es, and informs the slaves about the new set of interfa es they shall a tivate by means of a
g
Con g
message. Upon re eiving the
Con-
message the slaves re ognize that a re on guration pro edure is taking
pla e. The slaves on gure the new set of a tive interfa es in luded in the
Con g
message and disable frame forwarding until it is guaranteed that the
new loop-free a tive topology is on gured. This is guaranteed when a PAN devi e, a slave or the master, re eives the
A k
or if it is the last hop in the ontrol tree.
messages from all its hildren
At that point, the PAN devi e
enables frame forwarding. When the PAN master has re eived all
A k
mes-
sages from its hildren, it ushes the lo al ARP table (or NDP table) and sends a
Con g
message without any per-slave on guration. This message
is transmitted a ross the ontrol tree to inform the slaves that they an ush their ARP tables (or NDP tables) too, so that new address resolutions, and impli itly path re on gurations, an safely take pla e for the a tive ows in the PAN. The ASPAN a tive topology re on guration pro edure is illustrated in the Message Sequen e Chart (MSC) of Fig. 5.7. A
h-hop
slave is
h hops away from the PAN master in the ontrol tree, where 1 ≤ h ≤ H − 1, and H is the maximum number of hops between the master and a slave in the ontrol tree. The H -hop slaves are the leaf nodes in the a PAN devi e
ontrol tree, whi h terminate the propagation of the
Con g
message. Using
this approa h, ASPAN ensures that a loop free a tive topology is always established, sin e ea h PAN devi e enables frame forwarding only after it is guaranteed that the
Con g
message rea hed all PAN devi es and, onse-
quently, the new a tive PAN topology was set. At rst glan e, this approa h may seem to in ur signi ant signaling overhead. However, within a PAN it is envisioned that a small number of ows are a tive simultaneously.
As su h, in the worst ase, a few address
resolution pro edures will take pla e simultaneously. On the other hand, this is not dierent from what happens in any of the rea tive routing proto ols referred to in Chapter 4, when a node leaves the network and paths are broken. The
Con g
message is de ned as follows:
CHAPTER 5.
SFA FRAMEWORK
142
Master Config 1
2
Ack
3
4 5
Figure 5.8: Illustration of the ASPAN topology re on guration pro edure when a non-leaf node leaves the 5-node PAN and the new a tive topology.
Config = message-type sequen e-number master-addr *(node-addr a tive-ifa es) ; node MAC addr and ; interfa es to a tivate The length of ea h eld is provided in Table 5.1. In Fig. 5.8 we illustrate the a tive topology re on guration when Node 2 leaves the PAN shown in Fig. 5.6. By means of the topology maintenan e pro edure, the master (Node 1) dete ts that Node 2 left the PAN. It then triggers the omputation of the new a tive spanning tree using algorithm.
Campos's
Consider that the previous a tive spanning tree was the tree
illustrated in Fig.
5.6 using bold lines.
When Node 2 leaves the PAN,
the resulting a tive spanning tree is pre isely the graph without Node 2, as shown in Fig. 5.8. Yet, sin e Node 2 was a non-leaf node in the previous a tive spanning tree, a re on guration is needed. The master issues a
Con g
message in order to instru t the slaves about the set of network interfa es they shall a tivate. Nodes 4 and 5, whi h are leaf nodes in the new ontrol tree, send an
A k
message to their parent node when the re on guration of
their lo al interfa es is nished. Upon re eiving the
A k
messages from both
hild nodes, Node 3 does the same and noti es the master. Finally, Node 1 sends a
Con g
message to inform the PAN slaves that they an safely
perform new address resolution pro edures for path re-establishment; this is only exe uted by the nodes with a tive ows.
CHAPTER 5.
Campos's
SFA FRAMEWORK
143
algorithm
Campos's
algorithm represents a new approximation MRCST algorithm
that improves the performan e of bridged Layer 2 networks, parti ularly when the edges of the graph modeling the network have heterogeneous weights. It aims at improving the routing ost of the a tive spanning tree assumed in these networks, taking into a
ount that an MRCST is by de nition the optimal spanning tree.
Campos's
algorithm de nes the spanning tree algorithm
for the PAN ST me hanism (see Fig. 5.4). In [WC04℄ the routing ost of a spanning tree is shown to depend both on the edge weights and on the tree topology. These two fa tors have impa t on the diameter of the tree the ost of the longest path between any two verti es in the tree whi h in uen es the routing ost of the tree; in general, a spanning tree with lower diameter has lower routing ost. Consider, for example, the trees shown in Fig. 5.9. They have the same set of edge weights but dierent topologies.
The left-hand side tree has routing ost
104 and diameter 7, while the right-hand side tree has routing ost 89 and diameter 5. In this ase, the right-hand side tree has lower routing ost due to its lower diameter. Thus, the omputation of an MRCST for a graph
G
must onsider both edge weights and topology. Nonetheless, when the graph
G
is homogeneous or extremely heterogeneous a single fa tor a tually in u-
en es the sele tion of an MRCST, as demonstrated by Grout [Gro05b℄ and by the analysis and on lusions drawn by Mieghem
Add
et al.
[ML05℄[MM05℄.
G
is homogeneous
algorithm provides an approximate MRCST when
by onsidering the degree of the verti es as the sele tion riterion. On the other hand, an MST approximates or oin ides with an MRCST when links are extremely heterogeneous and is sele ted based on the edge weights only. Between these two extreme ases both fa tors in uen e the sele tion of an MRCST. Therefore, a ombination of the riterion used by MST algorithms (edge weights) and the riterion onsidered by
Add
algorithm (degree of the
verti es) in a single algorithm appears as a promising approa h to approximate an MRCST. That is what
Campos's algorithm does in order to onsider
both topology and edge weights in the general ase; in fa t, it takes into a
ount an additional riterion in order to ontribute to the redu tion of the diameter of the nal spanning tree (see below).
Campos's algorithm takes Prim's algorithm as a basis but introdu es two major modi ations. Firstly, it de nes a deterministi approa h to nd the
CHAPTER 5.
SFA FRAMEWORK
144
1
1 1
1
2 2
4
2
4 2
2
2 5
3
5
1
1
3 1
1
6
6
Figure 5.9: Two example trees with the same set of edge weights but dierent topologies.
initial vertex. Se ondly, it onsiders parameters other than the edge weight to sele t the vertex to be extra ted from the list of verti es of the algorithm.
L
at ea h step
The new parameters are partially imported from other
spanning tree algorithms, namely from
Add
and
Dijkstra's
algorithms. The
algorithm de nes basi parameters and omposed parameters.
The latter
are obtained by ombining the former.
Prim's algorithm, Campos's algorithm starts by sele ting the initial
As in
vertex. Three basi parameters hara terizing a vertex
v∈V
are onsidered
for that purpose:
• dv
degree of the vertex
• sv
sum of adja ent edge weights
• mv
maximum adja ent edge weight
The ombination of the basi parameters de nes the omposed parameter
spv
that hara terizes the potential of
the spanning potential.
spv
v
to span neighbor verti es; we all it
in ludes the three omponents shown in Eq. 5.1:
the degree of the vertex, the inverse of the average adja ent edge weight, and the inverse of the maximum adja ent edge weight. The two last omponents are onsidered in inverse proportion sin e higher weight values imply lower spanning potential.
C1 , C2 ,
and
C3
are oe ients whose values have no
impa t on the routing ost of the approximate MRCST obtained using the algorithm, as demonstrated in Appendix A; for the sake of simpli ity, we
onsider
C1 =C2 =C3 =1.
CHAPTER 5.
SFA FRAMEWORK
145
spv = C1 · dv + C2 ·
dv 1 + C3 · sv mv
(5.1)
where
sv =
|Av | X
w(v, j), j ∈ Av
j=1 j6=v
mv = w(v, l) : w(v, l) ≥ w(v, k), ∀k ∈ Av The vertex
f ∈ V : spf ≥ spj , ∀j ∈ V
is de ned as the initial vertex.
In other words, the vertex with the highest spanning potential is sele ted as the initial vertex, as in
Add
algorithm.
This sele tion riterion represents
Add
a modi ed version of the riterion used by initial spanning relay.
algorithm for sele ting the
Besides onsidering the degree of the verti es, our
algorithm onsiders the average adja ent edge weight and the maximum adja ent edge weight. The two additional parameters are relevant for nonhomogeneous graphs; for homogeneous graphs only the degree of the verti es in uen es the hoi e of the initial vertex sin e the other two parameters are equal for all verti es. In order to sele t the vertex to be extra ted from the list of verti es ea h step of the algorithm,
Campos's
algorithm de nes the following set of
basi parameters to hara terize a vertex
v ∈V:
Prim's
• wv
weight ( onsidered as in
• dv
degree of the vertex
• sv
sum of the adja ent edge weights
algorithm)
• cfv
estimated ost of the path between
• pdv
degree of the andidate parent vertex in
• psv in T
L at
v
and
f
in
T
T
sum of the adja ent edge weights of the andidate parent vertex
By ombining them, the algorithm de nes the following omposed parameters:
wdv = C4 · wv + C5 · cfv
(5.2)
CHAPTER 5.
SFA FRAMEWORK
146
jspv = sdv +
sdv swv
(5.3)
where
sdv = dv + pdv swv = sv + psv The omposed parameter edge onne ting
v
pv .
v
and
f
in
T
pv
v
C5 , as demonstrated C4 =C5 =1.
greater than
and
in
T
and the estimated
impli itly di tated by the andidate
The omposed parameter
the joint spanning potential of
we onsider
(Eq. 5.2) hara terizes the weight of the
and its andidate parent vertex
ost of the path between parent vertex
wdv
pv .
jspv
In Eq.
(Eq. 5.2
C4
5.3) hara terizes shall be equal or
in Appendix A; for the sake of simpli ity,
The algorithm is formally de ned in Alg. 1. In what follows we des ribe the algorithm and relate the des ription with the orresponding lines in Alg. 1. Initially all verti es have
wf
and
cff
wv
and
cfv
set to
∞
(line 6), ex ept
f
that has
set to 0 (line 11); the other basi parameters listed above have
unde ned values at this stage.
At ea h step of the algorithm, the vertex
u ∈ L : wdu < wdj , ∀j ∈ L is sele ted as the next vertex to be extra ted from L (line 14 to 20) that initially only ontains f . If there is more than one vertex in L with the same value of wdv , jspv is onsidered to break the tie. Let S ⊆ L de ne the set of verti es in L having the same lowest value of wdv . The vertex u ∈ S : jspu ≥ jspj , ∀j ∈ S is then the vertex extra ted from L in that ase (line 21 to 25). Afterwards, for every vertex a ∈ Au ∧ a ∈ /T (remember that Au de nes the set of verti es adja ent to u), if wda be omes lower while omputed onsidering u as the andidate parent vertex, wda and jspa are updated a
ording to the new values of the orresponding basi parameters, wa = w(u, a), cfa = cfu + w(u, a), pda = du , and psa = su (line 30 to 31). If wda a hieves the same value but jspa a hieves a greater value if omputed onsidering u as the andidate parent, only jspa is updated a
ording to the new values of pda and psa (line 32 to 33). In both ases u be omes the andidate parent vertex for a, i.e., pa = u. a is then added to L if it does not yet belong to L (line 35 to 36) and the edge (u, pu ) is added to T (line 40). This pro ess is repeated until the n verti es have been added to T . At that stage T is the approximate MRCST.
CHAPTER 5.
SFA FRAMEWORK
Algorithm 1 Campos's
147
algorithm (formal de nition)
Require: A weighted, undire ted graph G=(V,E,w). Ensure: An approximate Minimum Routing Cost Spanning Tree. {The following set of variables is assumed to be initialized to 0: dv , sv , mv , and spmax . The variables wdt and jspt are used to store temporary values.} 1: for ea h (i, j) ∈ E do di ← di + 1; si ← si + w(i, j); mi ← max(mi , w(i, j)) 2: 3: dj ← dj + 1; sj ← sj + w(i, j); mj ← max(mj , w(i, j)) 4: end for 5: for ea h v ∈ V do wv ← ∞; cfv ← ∞; spv ← dv + dv /sv + 1/mv 6: 7: if spv > spmax then f ← v ; spmax ← spv 8: 9: end if 10: end for 11: wf ← 0; cff ← 0; pf ← N IL; L ← L ∪ {f } 12: while L 6= ∅ do 13: wdmin ← ∞; jspmax ← 0 14: for ea h v ∈ L do 15: if wdv < wdmin then 16: S ← ∅ ∪ {v}; wdmin ← wdv 17: else if wdv = wdmin then 18: S ← S ∪ {v} 19: end if 20: end for 21: for ea h v ∈ S do 22: if jspv ≥ jspmax then 23: jspmax ← jspv ; u ← v 24: end if 25: end for 26: for ea h a ∈ Au do 27: if a ∈/ T then 28: wdt ← w(u, a) + (cfu + w(u, a)) 29: jspt ← (da + du ) + (da + du )/(sa + su ) 30: if wdt < wda then 31: wda ← wdt ; jspa ← jspt ; pa ← u 32: else if wdt = wda ∧ jspt ≥ jspa then 33: jspa ← jspt ; pa ← u 34: end if 35: if a ∈/ L then 36: L ← L ∪ {a} 37: end if 38: end if 39: end for T ← T ∪ {(u, pu )} 40: 41: end while
CHAPTER 5.
SFA FRAMEWORK
148
The set of parameters listed above enables the algorithm to take both topology and edge weights into a
ount during the omputation of the approximate MRCST. The
wv
parameter, already onsidered in
rithm, relates to the edge weights.
By onsidering the
Prim's
n−1
algo-
lowest edge
weights the algorithm tries to redu e the osts of the paths between the verti es in the nal spanning tree and, onsequently, redu e the routing ost of the nal spanning tree.
The
cfv
parameter is imported from
algorithm and onsiders both topology and edge weights.
cfv
Dijkstra's
By minimizing
for ea h vertex the algorithm tries to redu e the diameter of the nal
spanning tree and, onsequently, its routing ost; in fa t, if we de ne the initial vertex as the root of the nal spanning tree, a redu tion in the ost of the path towards the root ontributes to the redu tion of the diameter of the tree. The parameters to topology.
sdv (dv + pdv )
swv (sv + psv )
and
are related
They allow the algorithm to hara terize the joint spanning
potential of a vertex
v
and its andidate parent vertex
pdv .
By sele ting
rst the verti es that together with their andidate parent verti es have the highest joint spanning potential, the algorithm redu es the number of relay verti es in the nal spanning tree; this ontributes to the redu tion of its routing ost, as demonstrated by
Campos's
Add
algorithm.
algorithm is formally de ned in Alg.
1.
Sin e the formal
de nition is independent of the a tual implementation, we also de ne it using pseudo ode in Alg. 2, where we in lude the exe ution time for ea h part of the algorithm. The de nition using pseudo ode has two goals: 1) to show how the algorithm an be implemented using Fibona
i Heaps; 2) to analyze the time omplexity of
Campos's
algorithm.
Taking into a
ount the partial time omplexities provided in the pseudo
O(m), O(n), and O(n.log(n)+m), we on lude that Camhas time omplexity O(m + n.log(n)), when implemented
ode in Alg. 2, i.e.,
pos's
algorithm
using Fibona
i heaps [FT87℄ in onjun tion with adja en y lists. In spite of the omputation of additional parameters hara terizing the verti es (O(m) time) and the deterministi sele tion of the initial vertex (O(n) time), the overall time omplexity of the algorithm is of the same order of
Dijkstra's
Prim's
and
algorithms.
Appendix A illustrates the use of
Campos's
algorithm in the omputa-
tion of an approximate MRCST, onsidering an example input graph.
In
addition, for the sake of lear understanding of the gain and the dieren e
CHAPTER 5.
SFA FRAMEWORK
149
introdu ed by the new proposed algorithm, it provides an example omparing the spanning trees obtained using
Campos's
algorithm and the standard
IEEE algorithm used by urrent IEEE 802.1D bridges.
5.2.3 Frame Forwarding using Learning Bridges A Learning Bridge may have multiple physi al NICs. However, this is hidden from the upper layers by means of a logi al NIC. The logi al NIC a ts similarly to the virtual interfa es de ned by most of the Layer-2.5 solutions mentioned in Chapter 4. But, here no new address spa e is de ned. Instead, Learning Bridges sele t the lowest MAC address among its NICs to be ome
1
the MAC address of the logi al NIC presented to the upper layers .
In
pra ti e, the logi al NIC appears to the upper layers as a regular Ethernet NIC. Upon re eiving any frame whose destination is the MAC address of the logi al NIC, the Learning Bridge delivers the frame to the upper layers through the logi al NIC. In the reverse dire tion, any data frame (uni ast or broad ast) re eived from upper layers through the logi al NIC is forwarded a
ording to the forwarding pro edure des ribed in Chapter 4.
5.2.4 PAN Basi Conne tivity Me hanism The PAN BC (PBC) me hanism is used to on gure IP onne tivity within the PAN. Depending on the a tual lega y IP auto- on guration me hanism used, the on gured IP onne tivity may enable intra-PAN onne tivity only or both intra-PAN and PAN-to-Internet onne tivity. PBC onsiders two message types,
Proposal
and
Agreement,
and it may run at two
moments: 1) during PAN bootstrapping; 2) when a PoA hange o
urs. The message ex hange pro ess for ea h ase is illustrated in Fig. 5.10 and Fig. 5.11, respe tively. During PAN bootstrapping, two s enarios may then take pla e: 1) standalone PAN; 2) onne ted PAN. If the PAN does not have any PoA (standalone PAN), the master sele ts the proper IP version and lega y IP auto on guration me hanism to on gure intra-PAN IP onne tivity.
ase, ea h slave sends a
Proposal
In this
to the master, as illustrated in Fig. 5.10a.
This message spe i es the supported IP versions, the supported lega y IP 1
This is the approa h followed in mainstream operating systems, su h as Linux OS and Windows XP/Vista/7, whi h support Learning Bridges.
CHAPTER 5.
SFA FRAMEWORK
Algorithm 2 Campos's
150
algorithm (pseudo ode)
Require: G = (V, E, w) Ensure: An approximate MRCST 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24:
{ omputes degree and sum of weights for ea h vertex → O(m)} for ea h (i, j) ∈ E do d[i] = d[i] + 1; s[i] = s[i] + w(i, j); m[i] = max(m[i], w(i, j)); d[j] = d[j] + 1; s[j] = s[j] + w(i, j); m[j] = max(m[j], w(i, j)); sumWeights = sumWeights + w(i, j); {sumWeights is initialized to 0}
end for
{sele ts the vertex with higher spanning potential as the initial vertex → O(n)} for ea h v ∈ V do w[v] = inf ; {inf stands for a huge integer} color[v] =WHITE; sp[v] = d[v] + d[v]/s[v] + 1/m[v]; if sp[v] > spmax then spmax = sp[v]; f = v;
end if end for
w[f ] = 0; cf [f ] = 0; p[f ] = f ; pd[f ] = 0; ps[f ] = 1; color[f ] = GRAY; {means that f has been added to L} L = INSERT(f ); {insert vertex f into L → O(1) (using Fibona
i Heaps)} spanned_verti es = 0; {partial time omplexity → O(n.log(n) + m)} while spanned_verti es < |V | do u = EXTRACT_MIN(L); {O(log(n)) amortized (using Fibona
i Heaps)} {Adj[u] represents an adja en y list ontaining the adja ent verti es to u} for ea h v ∈ Adj[u] do if color[v] = BLACK then
ontinue; {v already belongs to T }
end if
{t has the same hara teristi s of v , but its andidate parent is u} wd[t] = w(u, v) + (cf [u] + w(u, v)); jsp[t] = (d[v] + d[u]) + (d[v] + d[u])/(s[a] + s[u]); { mp() is the ompare fun tion used to sort elements in L; mp() re eives 2 verti es as argument and ompares them based on wd[] and jsp[] for ea h vertex} if mp(v, t) < 0 then if color[v] = WHITE then wd[v] = wd[t]; jsp[v] = jsp[t]; p[v] = u; color[v] = GRAY; L = INSERT(v); {O(1) amortized (using Fibona
i Heaps)} else if color[v] = GRAY then L =UPDATE(v ); {O(1) amortized (using Fibona
i Heaps)}
25: 26: 27: 28: 29: 30: 31: end if 32: end if 33: end for color[u] =BLACK; spanned_verti es = spanned_verti es + 1; 34: 35: end while 36: T [spanned_verti es] = (u, p[u]); {add edge (u, p[u]) to T de ned by a set of edges}
CHAPTER 5.
SFA FRAMEWORK
PAN Slaves
PAN Master
151
PAN Master
PAN Slaves
Proposal
PAN Gateway
Proposal
Agreement
Agreement
(a) Standalone PAN
(b) Conne ted PAN
Figure 5.10: PAN BC me hanism pro edure during PAN bootstrapping.
auto- on guration me hanisms, and the roles the slave an assume with respe t to ea h lega y IP auto- on guration me hanism, i.e., lient, server, or both, if the sele ted lega y me hanism is based on a lient-server paradigm. The master olle ts all proposals from the slaves and, after onsidering its own apabilities, sends an
Agreement
message with the IP version and the
lega y IP auto- on guration me hanism to be used, as well as the PAN devi e that will a t as server, if appli able. For instan e, the agreement may be to use the DHCP proto ol. The PAN devi e that must run the DHCP server is identi ed in the
Agreement ; the others run a DHCP lient.
The de nition
of an algorithm to sele t the IP version and lega y IP auto- on guration me hanism when there are multiple options is out of s ope of this thesis. In addition, when there are multiple andidates to play a given role, e.g., DHCP server, ASPAN sele ts the devi e with the lowest MAC address to break the tie.
If the PAN has one or more PoAs available ( onne ted PAN), the IP
version and the lega y IP auto- on guration me hanism will be imposed by the sele ted PoA. In this ase, as depi ted in Fig. send the
Proposal
to the master.
5.10b, the slaves also
Nevertheless, upon dete ting that PoAs
are available, the master does not send any
Agreement
message. The PAN
gateway sele ted by the PAN GC me hanism (see Se tion 5.2.5) will do it a
ording to the IP version imposed by the sele ted PoA and the lega y IP auto- on guration me hanism(s) lo ally supported.
A possible agreement
in this ase may be to run a DHCPv4/v6 server at the PAN gateway and the orresponding lient at the rest of the PAN devi es. Another possibility is to run IPv6 SLAC, where the sele ted PAN gateway announ es an IPv6 pre x through the standard
Router Advertisement
messages and the other
PAN devi es use su h information to on gure an IPv6 address based on their MAC addresses.
CHAPTER 5.
SFA FRAMEWORK
152
PAN Gateway
PAN Devices
Agreement
Figure 5.11: PAN BC me hanism pro edure during PoA hange.
For a standalone PAN, the
Con g
Agreement
message is piggyba ked in the
message sent down the ontrol tree by the master.
onne ted PAN, the
Agreement
Regarding a
message is sent along the ontrol tree by
the PAN gateway, upon the a tive topology on guration is omplete. both ases, the
Proposal
slaves in response to the
message is piggyba ked in the
TR.
A k
In
sent by the
It is important to note that, irrespe tive of
the s enario taking pla e, the a tual IP on guration using the lega y IP auto- on guration me hanism is only arried out when the a tive topology
on guration pro edure has ompleted. When a PoA hange o
urs during the PAN lifetime, the PAN devi e sele ted as the new PAN gateway simply sends the
Agreement
along the
ontrol tree, in order to inform the other PAN devi es about the new IP version and the orresponding lega y IP auto- on guration me hanism to be used.
In this ase, the PBC me hanism is triggered by the PAN GC
me hanism, whi h deals with the PAN gateway on guration issues. Note that this pro edure is exe uted even if the new PoA belongs to the PAN gateway that was in use. The
Proposal
and
Agreement
messages are de ned as follows:
Proposal = message-type sender-MAC-addr network-layer-versions-supported auto onf-me hanisms-supported auto onf-me hanisms-roles Agreement = message-type network-layer-version auto onf-me hanism [server-MAC-addr℄
CHAPTER 5.
SFA FRAMEWORK
The length of the elds in luded in
Proposal
153
and
Agreement
are presented
in Table 5.2.
5.2.5 PAN Gateway Con guration Me hanism The PAN GC (PGC) me hanism manages the PAN gateway on guration pro ess. The PAN gateway on guration is arried out a
ording to the PoA sele ted. The sele tion of the PoA is performed by the master based on lo al information and on the information olle ted from the slaves. Ea h slave informs the master about the set of PoAs it has available using the
PGW Announ e
message. A PoA is hara terized by a PoA metri and a
PoA identi er with lo al meaning only, as it happens with the network interfa e IDs. The PoA ID is an integer value in luded in the
PGW Announ e.
The PoA metri is also an integer value that may be omputed based on one or more parameters, su h as nominal bandwidth and ost (in euros). If multiple parameters are onsidered, the metri value will be the result of a linear ombination of the various parameters, possibly onsidering dierent weights for ea h parameter. ASPAN only onsiders the PoA's nominal bandwidth. After reating a list of the available PoAs, the master sele ts the PoA with the highest PoA metri . If the PoA belongs to the master, the required lo al on gurations are performed and no further PGC signaling is required. If the PoA belongs to a PAN slave, the master informs the slave using a
PGW Sele t
message. Upon re eiving su h message the slave performs the
required lo al on gurations.
In both ases, after the lo al on gurations
are done, the PBC me hanism is triggered to inform the other PAN devi es about the IP version and lega y IP auto- on guration me hanism to use. The lo al on gurations arried out by PGC are simple. It sets up an IPv4/v6 router between the lo al NIC orresponding to the PoA sele ted by the master and the logi al NIC maintained by the lo al Learning Bridge. In addition, if the sele ted PoA is running on IPv4, the PAN gateway is
on gured to run NAT between the same NICs.
This is needed sin e in
IPv4 a single publi IPv4 address is assigned to the PAN devi e owning the sele ted PoA; NAT is the solution to share su h address among the PAN devi es. When the sele ted PoA is running on IPv6, IPv6 NAT may also be used [TZL10℄, if a single IPv6 address is assigned. Nonetheless, in IPv6 the address spa e is bigger and the assignment of IPv6 pre xes is standardized, as seen in Chapter 4. As su h, if an IPv6 pre x is delivered to the sele ted
CHAPTER 5.
SFA FRAMEWORK
154
PAN gateway, that IPv6 pre x may be used for auto- on guring global IPv6 addresses within the PAN; IPv6 NAT is not required in this ase. As soon as these on gurations are ompleted, the PGC me hanism triggers the PBC me hanism. The PBC me hanism pro eeds in the way spe i ed in Se tion 5.2.4 for a onne ted PAN. The
PGW Announ e
and
PGW Sele t
messages are de ned as follows:
PGW Announ e = message-type sender-MAC-addr *(PoA-flag PoA-ID metri ) PGW Sele t = message-type PGW-MAC-addr PoA-ID The length of ea h eld onsidered in the messages is provided in Table
PoA- ag is a 1-bit eld whi h (PoA- ag = 1) or not (PoA- ag = 0).
5.2. The
spe i es whether the PoA is a tive
Along the PAN lifetime PoA hanges may happen. This may be aused by (1) the failure of the urrent PoA or (2) by the appearan e of a new PoA with a better metri than the urrent PoA. In the rst ase, if the urrent PoA belongs to the master, it an dete t the failure lo ally. Otherwise, the slave supporting the PoA informs the master by means of a with
PoA- ag = 0.
PGW Announ e
When the master dete ts the failure, it simply sele ts
the se ond best PoA from the PoA Table lo ally maintained, and triggers the needed re on gurations by issuing a
PGW Sele t message; the PGW Sele t is
impli itly used by the previous PAN gateway to undo its lo al on gurations. In the se ond ase, either the master dete ts lo ally that it an support a new better PoA or it is informed through a
PGW Announ e
that a slave an
support a better PoA. The new PoA is added to the PoA Table maintained by the master and sele ted as the new PoA. The rest of the pro ess is similar to the rst ase. On e again, when the PGC me hanism ompletes, it triggers the PBC me hanism for IP onne tivity re on guration. Irrespe tive of the PoA hanges, the intra-PAN IP onne tivity is untou hed, and intra-PAN ommuni ations are not interrupted when a hange of PoA o
urs. If IPv6 is used, two IPv6 addresses are auto- on gured by ea h PAN devi e: the IPv6 link-lo al address on gured by default, whi h
CHAPTER 5.
SFA FRAMEWORK
Message Proposal
Agreement
PGW Announ e
PGW Sele t
Fields
155
Size (bytes)
message-type sender-MAC-addr network-layer-versions-supported auto onf-me hanisms-supported auto onf-me hanisms-roles message-type network-layer-version auto onf-me hanism server-MAC-addr message-type sender-MAC-addr PoA- ag PoA-ID metri message-type PGW-MAC-addr PoA-ID
1 6 1 1 2 1 2 1 6 1 6 1 2 1 6 1
Table 5.2: Length of the elds of the messages used in the PBC and PGC me hanisms.
may be used for intra-PAN ommuni ations and does not hange with the PoA, and the global IPv6 address, whi h is used for PAN-to-Internet ommuni ations. When IPv4 is used, a single private IPv4 address is on gured for both intra-PAN and PAN-to-Internet ommuni ations. In order to keep the same IP address for ea h PAN devi e when a PoA hange happens, the same IPv4 address is always enfor ed when a PoA re on guration is triggered.
This works as follows.
DHCP is the lega y IP auto- on guration
me hanism envisioned to be used in this ase. The same private IPv4 pre x is used at ea h PAN gateway to enable IPv4 address auto- on guration using DHCP. Consider, for instan e, that the 192.168.0.0/24 pre x is used. When the PAN is bootstrapping, the PAN gateway running a DHCP server sele ts one of the 254 assignable addresses with su h pre x (e.g., 192.168.0.254); the other PAN devi es will get an IPv4 address with that pre x too assigned by the DHCP server. When a PoA hange o
urs, the PAN gateway may also hange. The new PAN gateway runs a DHCP server assigning addresses from the same pre x and keeps the IPv4 address it had before the PoA hange. The other PAN devi es run a DHCP lient. They are able to keep their previous IPv4 addresses, thanks to the solution already provided by DHCP. When sending out the
DHCP REQUEST, the
DHCP lient an
CHAPTER 5.
SFA FRAMEWORK
156
request keeping an IPv4 address already assigned. If the DHCP server has su h address available, it an be assigned. In ASPAN this is possible, sin e the DHCP servers, whi h run at the ele ted PAN gateway at ea h moment, use the same IPv4 pre x. Using this approa h the IPv4 addresses are kept, independently of the PoA hange. Whenever possible, the PGC signaling messages are piggyba ked in the messages used in the topology dis overy and a tive topology on guration pro edures.
When the PAN is bootstrapping, PAN slaves piggyba k the
PGW Announ e
in the
A k
sent upwards to the master; the
PGW Sele t
Con g message. During the PAN operation, whenever possible, any PoA Announ e is piggyba ked in the periodi A k messages. The same may happen with a PoA Sele t message, if a Con g message is to be sent by the master. is then piggyba ked by the master in the
5.2.6 Support of Lega y Devi es In pra ti e, it may not be possible to have ASPAN running in every PAN devi e.
For instan e, a digital amera may not allow installation of
new software. Thanks to the approa h followed in ASPAN, the integration of su h digital amera or any lega y devi e an be transparently performed. The lega y devi e atta hes to the PAN through some PAN devi e supporting ASPAN, either through a NIC already added to the lo al Learning Bridge or through a NIC not yet belonging to the Learning Bridge; in the latter ase, the NIC an be automati ally added to the Learning Bridge upon some wellknown signaling messages, su h as
DHCP OFFER and ARP REQUEST, are
re eived through the NIC. Without supporting ASPAN, a lega y devi e an then take advantage of the ASPAN features, namely the PAN PoA to the Internet and the onne tivity established among the PAN devi es. The reason for this is the use of Learning Bridges and lega y IP auto- on guration me hanisms as a basis. From the lega y devi e standpoint, everything happens as if it was onne ted to a LAN. This eases the deployment of the solution.
5.2.7 Tables Maintained Ea h slave maintains two tables only:
the Parent-Children Table and
the Learning Bridge Forwarding Table. The Parent-Children Table is used to store information about the node that was sele ted as the parent node
CHAPTER 5.
SFA FRAMEWORK
157
in the ontrol tree and the lo al interfa e through whi h it is rea hable, as well as the nodes that have sele ted the urrent node as their parent node in the ontrol tree and the interfa es through whi h they are rea hable; the Learning Bridge Forwarding Table is well known. At the PAN master, the Parent-Children Table in ludes entries for all slaves. This table is used as a basis for de iding whi h information shall be in luded in a
Con g
message
sent through a given network interfa e, during the a tive topology on guration (see Se tion 5.2.2). The PAN master maintains two additional tables: the Topology Table and the PoA Table. The Topology Table ontains the whole PAN topology and the PoA Table stores information about the set of PoAs available in the PAN.
5.2.8 Se urity ASPAN does not ope with se urity by itself. Yet, it in orporate existing se urity solutions de ned namely within the ontext of the wireless te hnologies that may be running underneath, su h as IEEE 802.11 and Bluetooth. A possible solution is the use of a ommon pre-shared key, whi h is on gured in ea h PAN devi e by the user. This will ensure that only the devi es the user on gures with the pre-shared key are able to make part of the PAN. Note that this just needs to be performed on e, as it happens in urrent home Wi-Fi networks, for example, when a user on gures a WPA-PSK passphrase.
5.3 Solution for Stub Wireless Mesh Networks This se tion addresses the SFA instan e targeting Stub WMNs, named as Wi-Fi network Infrastru ture eXtension (WiFIX). In Stub WMNs the gateway node is prede ned, so the optional GC me hanism shown in Fig. 5.1 is not required in this SFA instan e. Fig. 5.12 shows the me hanisms
onsidered in this ase. WiFIX assumes two types of nodes the terminals atta hing to the Stub WMN and the MAPs forming the Stub WMN, whi h work as Learning Bridges, and it de nes the transportation of all signaling messages on top of Layer-2 frames. sented in Fig.
5.13.
The WiFIX referen e s enario is pre-
In the left hand side, a wired omponent is shown,
where the network servi es are running and 802.11 APs are atta hed to the wired infrastru ture. In the right hand side, the WiFIX Stub WMN is shown
CHAPTER 5.
SFA FRAMEWORK
158
IC module
invokeLegacyMechanism()
Legacy IP auto-configuration mechanisms
PaC module
Learning Bridges
configActiveInterfaces()
Figure 5.12: WiFIX the SFA instan e for Stub WMNs.
to extend this infrastru ture to wireless terminals, whi h support 802.11 or other 802-like te hnology, su h as Ethernet and UWB.
5.3.1 Hybrid Paradigm WiFIX follows a hybrid ontrol paradigm.
On the one hand, there is
a entral node, the master MAP, whi h is dire tly onne ted to the wired infrastru ture.
The master MAP generates periodi ally a signaling mes-
sage used to reate and maintain the Stub WMN a tive topology; the other MAPs pro ess the message and retransmit it. In addition, the master MAP announ es the IP version and the lega y IP auto- on guration me hanism that shall be used by the terminals atta hing to the Stub WMN, regarding IP
onne tivity establishment. On the other hand, the non-master MAPs form the a tive topology in a distributed manner based on the signaling message sent out periodi ally by the master MAP.
CHAPTER 5.
SFA FRAMEWORK
159
Infrastructure Current Infrastructure Extension
UWB terminals
Services (DHCP, DNS, …) MAP
Internet
MAP
MAP
802.11 terminals
Gateway MAP
Ethernet
Wired terminals
802.11 terminals
802.11 terminals Wired terminals
Figure 5.13: The WiFIX referen e s enario.
5.3.2 Stub WMN Spanning Tree Me hanism Ethernet-over-802.11 En apsulation In order to enable multi-hop forwarding, four MAC addresses are required as de ned in the 802.11 WDS format.
Two addresses are needed to store
the original sour e and the nal destination of a data frame, and the other two are required to identify the intermediate sour e and destination at ea h hop; otherwise, frame forwarding does not work.
The WDS format ould
be onsidered in WiFIX. However, WDS links would have to be manually
on gured for ea h peer MAP. A solution ould be to de ne a me hanism to establish the WDS links, but that approa h would have problems when the mesh topology hanges, sin e ea h MAP would have to perform time onsuming 802.11 s ans to nd its neighbor MAPs and establish new WDS links. On the other hand, the WDS format is not supported by all o-theshelf hardware, whi h is a disadvantage. In order to over ome these problems, WiFIX on gures the NICs of ea h MAP used for intra-mesh ommuni ation in 802.11 ad-ho mode. This has two advantages:
1) ad-ho mode is supported by all 802.11 hardware; 2)
in ad-ho mode, the 802.11 network is maintained in a distributed manner and is identi ed by an SSID, whi h avoids 802.11 s ans. However, the use of the 802.11 ad-ho frame format (Fig.
5.14) has a limitation: only two
MAC addresses are available for frame forwarding purposes.
Sin e multi-
CHAPTER 5.
SFA FRAMEWORK
2
2
6
Frame Control
Duration/ ID
Address 1 = Destination
6
6
Address 2 = Address 3 = Source IBSS
160
2
6
Sequence Control
Address 4 (not used)
2
0 - 2312
QoS Control Frame Body
4 FCS
3
3
2
0 - 2308
LLC
OUI = 0x000000
Ethertype
Original Payload
Figure 5.14: The 802.11 frame format (in ad-ho mode).
IEEE 802.11 MAC header 2 Frame Control
2 Duration/ ID
6
6
Address 1 = Address 2 = Next Hop Current Node
6
2
6
2
0 - 2312
4
Address 3 = IBSS
Sequence Control
Address 4
QoS Control
Frame Body
FCS
3
3
2
6
6
2
0 - 2290
LLC
OUI = 0x000000
Ethertype = Eo11
Original Destination
Original Source
Original Ethertype
Original Payload
LLC + SNAP header
Eo11 header
Figure 5.15: The Eo11 frame format.
hop forwarding using a single NIC requires four MAC addresses, the other two addresses need to be stored somewhere in the data frames. The solution proposed in this thesis onsists in de ning a new header type and en apsulating data frames using a tunneling me hanism, alled Ethernet-over-802.11 (Eo11). Fig. 5.15 shows the Eo11 frame format. The original sour e and destination addresses are stored in the inner header of the data frame, and the outer header ontains the intermediate sour e and destination MAP addresses, whi h are hanged at ea h intermediate MAP, as it happens in 802.11s. The endpoints of a tunnel are lo ated at neighbor nodes in the a tive topology; as su h, the path between ea h MAP and the master MAP an in lude multiple in sequen e, not nested Eo11 tunnels. In this on guration ea h mesh node for es a frame to go through the next hop (intermediate destination).
Creation and Maintenan e of A tive Topology The a tive tree topology rooted at the master MAP is reated and maintained using a new me hanism alled A tive Topology Creation and Maintenan e (ATCM). The ATCM me hanism establishes the virtual links between neighbor MAPs, whi h jointly de ne the Stub WMN a tive topology enabling the operation of Learning Bridges. In ATCM, a
Topology Refresh
(TR) message is broad ast periodi ally by the master MAP. The other MAPs
CHAPTER 5.
SFA FRAMEWORK
161
Message
Fields
Size (bytes)
TR
sequen e-number time-to-live distan e parent-MAC-addr
Table 5.3: Length of the elds of the
2 1 2 6
TR message used in the ATCM me h-
anism.
forward this message, after updating the required elds (distan e and parent MAC address). The
TR
message allows ea h MAP to sele t the parent
providing the best path towards the master.
Also, it enables (1) the par-
ent to be informed about new hild nodes that have hosen it and (2) the establishment of Eo11 tunnels or virtual links (the two terms are used inter hangeably) between the parent and its hildren. By default, the hop ount metri is used to de ne the best path to the master.
The
TR
message is
de ned as follows, using ABNF syntax:
TR = sequen e-number time-to-live distan e parent-MAC-addr The length of ea h eld is presented in Table 5.3. The used to uniquely identify the
TR.
The
number of hops that an be traversed
sequen e-number
is
time-to-live re e ts the maximum by the TR ; if the master sets it 0,
distan e eld de nes the number of hops to the master. Finally, the parent-MAC-addr identi es the parent sele ted by the node transmitting the TR. This information is omplemented by the Address
no limits are enfor ed. The
2 and the IBSS address arried in the header of the 802.11 frame used to
onvey the
TR. Address 2 identi es the transmitter of the TR, whi h hanges
as the message is retransmitted along the Stub WMN. The IBSS identi es the 802.11 ad-ho network formed among the Stub WMN nodes. The ATCM me hanism is similar to the me hanisms of the IEEE 802.11s draft standard des ribed in Chapter 4; however, it in ludes a new feature related to the reation of tunnels between parent and hild nodes. In ATCM the
TR message is used simultaneously to (1) announ e upstream neighbors
and (2) inform upstream neighbors that a given hild has sele ted it as its parent node in the tree; in 802.11s two messages are used instead.
CHAPTER 5.
SFA FRAMEWORK
Algorithm 3 ATCM (formal de nition) Ensure: SPST rooted at Master MAP {TR message reation}
1: for ea h TT R do Hmax ← 0; HM ← 0; Cp ← NIL; SRCT R ← Maddr 2: 3: MASTER_TR_BROADCAST() {Master broad asts TR} 4: SN ← SN + 1 5: end for {TR message re eption}
6: for ea h i ∈ SNR do 7: if SRCT R = Cp then 8: if CSN > P SN then 9: Lp ← MAX_LIFETIME {MAX_LIFETIME = 3 · TT R } 10: if (HM + 1 ≤ Hmax ) ∨ (Hmax = 0) then 11: HM ← HM + 1; Paddr ← Cp 12: P SN ← CSN ; SRCT R ← Caddr 13: BROADCAST_MOD_TR() {broad ast modi ed TR} 14: else 15: DROP_FRAME() 16: end if 17: else 18: DROP_FRAME() 19: end if 20: else if Paddr = Caddr then 21: if SRCT R is unknown then 22: CREATE_TUNNEL_ENDPOINT(SRCTR ) {Asso iate tunnel endpoint to SRCT R } 23: end if Lc [SRCT R ] ← MAX_LIFETIME 24: 25: else Li ← INSERT(SRCT R , CSN , HM ) 26: 27: end if 28: end for {Parent Sele tion}
29: for ea h Dp do 30: for ea h i ∈ SNR do 31: BC ← BEST_CANDIDATES(Li )
{There may be more than one andidate with same HM }
32: if |BU P | > 1 then 33: if Cp ∈ BU P then 34: Cp ← Cp 35: else 36: DELETE_TUNNEL_ENDPOINT(Cp) {deletes tunnel for urrent parent} 37: Cp ← LOWEST_MAC(BU P ) { andidate with lowest MAC addr} 38: CREATE_TUNNEL_ENDPOINT(Cp) { reates tunnel endpoint for new parent} 39: end if 40: else 41: if BU P 6= Cp then 42: DELETE_TUNNEL_ENDPOINT(Cp) {deletes tunnel for urrent parent} 43: Cp ← BU P 44: CREATE_TUNNEL_ENDPOINT(Cp) { reates tunnel endpoint for new parent} 45: end if 46: end if 47: DELETE(Li ) {deletes all entries in Li } 48: end for 49: end for {Tunnel management}
50: for ea h i ∈ SNR do 51: for ea h se ond do Lp ← Lp − 1 52: 53: if Lp = 0 then 54: DELETE_TUNNEL_ENDPOINT(Cp) {deletes tunnel for urrent parent} 55: Cp ← NIL 56: for j ∈ SCi do 57: Lc [j] ← Lc [j] − 1 58: if Lc [j] = 0 then 59: DELETE_TUNNEL_ENDPOINT(j) {deletes tunnel to hild j } 60: end if 61: end for 62: end if 63: end for 64: end for
162
CHAPTER 5.
SFA FRAMEWORK
163
The ATCM me hanism is ompletely de ned in Alg. 3; Table 5.4 summarizes the parameters onsidered in the de nition.
In what follows, we
des ribe ATCM and relate the des ription with the orresponding line(s) in Alg. 3. The master MAP broad asts a
TR
message periodi ally with a
sequen e number whi h uniquely identi es the message; the distan e to the master is equal to 0 and the parent address is unde ned, sin e the master is the root of the tree to be reated (lines 1 to 5). Upon re eiving the other MAP rst he ks if the
TR
TR, every
omes from its urrent parent (line 7). If
no parent has been ele ted yet, the
TR
is only used to olle t information
about andidate parent nodes (line 26). If the
TR
omes from the urrent
parent, the urrent node updates the lifetime of the Eo11 tunnel established with the parent and, if the number of hops traversed by the
TR
did not
ex eed the limit, it updates the distan e to the master, the parent address, and the sour e address of the
TR
TR
and rebroad asts it (lines 9 to 13). If the
rea hed the maximum number of hops that an be traversed (line 14
to 15) or it is a dupli ate (line 17 to 18), the message is silently dis arded. If the parent address in the re eived
TR
is the address of the urrent node
(line 21 to 24), and there is no Eo11 tunnel established with the sour e of the
TR
yet (line 21), a new tunnel endpoint is lo ally reated (line 22), whi h
appears as a virtual NIC and a port of the Learning Bridge running in the MAP; if the Eo11 tunnel is already established with the sour e of the
TR,
the lifetime of the Eo11 tunnel is simply updated (line 24). Every de ision period
Dp
(line 29 to 49) the non-master MAPs he k the list of andidate
parent nodes (line 31). The parent with the best metri is sele ted. When the urrent parent node is among the best upstream neighbors dete ted during the de ision period, the parent node is un hanged (line 34). Otherwise, if more than one andidate has the same metri value, the one with the lowest MAC address is sele ted (line 37). If a better andidate parent is found, the tunnel endpoint for the urrent parent (Cp ) is deleted (line 36) and a new tunnel endpoint is reated for the new sele ted parent (line 38). At the end of this pro ess, the list of andidates is deleted (line 47), so that a new set of andidates is olle ted during the next de ision period
Dp .
The tunnels
established either with the parent or with the hildren have a lifetime. When the lifetime expires the orresponding tunnel endpoint is deleted (line 50 to 64).
CHAPTER 5.
SFA FRAMEWORK
164
wired infrastructure
wired infrastructure
master MAP
1
1
master MAP
Paddr=1
2
3
2
Paddr=1
3
Paddr=1 Paddr=1
4
4
TR
(a)
(b)
wired infrastructure
wired infrastructure
master MAP
1
1
master MAP
Paddr=1
Paddr=1
2
TR
Paddr=1
2
3
Paddr=1
Paddr=1
Paddr=1
3
Paddr=2 Paddr=1
Paddr=1
4
4
TR
( )
TR
(d) wired infrastructure
1
master MAP
Paddr=1
2
Paddr=1
Paddr=1
3
Paddr=2 Paddr=1
4
TR
(e) Figure 5.16: The ATCM me hanism for a 4-node Stub WMN. (a) Startup; (b) Node 2 and Node 3 sele t Node 1 as parent; ( ) Eo11 tunnels (Node 1
↔
Node 2 and Node 1
↔
Node 3) established; (d) Node 4 sele ts Node 2 as
parent; (e) Eo11 tunnel (Node 2
↔
Node 4) established.
CHAPTER 5.
SFA FRAMEWORK
165
The ATCM me hanism is illustrated in Fig.
5.16 for a 4-node Stub
WMN. The set of arrows leaving a node represents the same
TR
message;
this notation is used to easily illustrate the nodes that re eive the message. Node 1 (master MAP) broad asts a
TR
message periodi ally (Fig. 5.16a);
at this point, the master MAP is the only node broad asting After the de ision period
Dp ,
olle ted from the re eived The list
Li
TR
TR
messages.
Node 2 and Node 3 he k the information messages, in order to sele t a parent node.
ontains a single entry orresponding to Node 1. So, both nodes
sele t Node 1 as parent and reate an Eo11 tunnel endpoint for Node 1. When Node 2 and Node 3 re eive the next
TR
start rebroad asting the
message with the
the sele ted parent (see Fig. 5.16b); the in Fig. 5.16 next to the
TR
TR
Paddr
message from Node 1, they
Paddr
eld set a
ording to
value for ea h node is shown
messages rebroad ast. Upon re eiving the
TR
messages rebroad ast by Node 2 and Node 3 for the rst time, Node 1 reates Eo11 tunnel endpoints for both and the Eo11 virtual links are established as shown in Fig. 5.16 ; all subsequent Node 3 in lude the The
Paddr
eld set to 1, so that the Eo11 tunnels are kept on.
TR messages rebroad ast by Node 2 and Node 3 are re eived by Node 4.
After the de ision period the
TR messages rebroad ast by Node 2 and
TR
messages.
Dp ,
Node 4 he ks the information olle ted from
There are two andidate parent nodes.
Sin e both are
1-hop away from the master MAP, Node 2 (with the lowest MAC address) is sele ted. The next time Node 4 re eives a
TR message it sets the Paddr
eld
to 2 before rebroad asting it, as shown in Fig. 5.16d. When Node 2 re eives that message, Node 2 reates a new Eo11 tunnel endpoint for Node 4, and the Eo11 virtual link between Node 2 and Node 4 is nally established as shown in Fig. 5.16e. When a topology hange o
urs, ATCM does not ush the Learning Bridge Forwarding Tables, in order to avoid that uni ast frames are ooded through the new spanning tree, before Learning Bridges learn the new paths. Instead, the data frames ex hanged between the terminals and the wired infrastru ture are used to impli itly update the paths after the new spanning tree is set.
In Stub WMNs, frames are ex hanged between ea h terminal
and the IP gateway, as illustrated in Fig.
5.17.
In addition, frames are
ex hanged very frequently, as will be demonstrated in Chapter 6.
WiFIX
takes advantage of these hara teristi s to establish the new paths when a topology hange o
urs. The path re on guration works as follows. Imme-
CHAPTER 5.
SFA FRAMEWORK
Internet
2
Internet
Internet
IP Gateway
1
166
master MAP
1
2
master MAP
3
1
2
master MAP
3
X
3
IP Gateway
IP Gateway
4
4
4
Lost frame
Data frame terminal
terminal
(a) Initial setup
(b) Link failure
terminal
( ) New setup
Figure 5.17: Illustration of the WiFIX path re on guration pro edure.
diately after a new spanning tree is established, the MAPs with a dierent parent node in the new spanning tree do not know the path to the IP gateway. So, upon re eiving a frame destined to the IP gateway they ood the frame through all the lo al interfa es, ex ept that from whi h the frame was re eived; this is the forwarding pro edure until they re eive a frame from the IP gateway and learn the new path. The MAPs keeping the parent node in the spanning tree keep using the previous path to the IP gateway. Due to the establishment of a new a tive spanning tree, the paths to the terminals may also be ome invalid. The path to a terminal will be updated as soon as it sends out a frame; while the terminal is silent, the old path is wrongly used to forward the frames oming from the IP gateway. Due to the frequent frames ex hanged between the terminals and the IP gateway the new paths
an be established fast. This be omes learer with an example. Consider the 4-node Stub WMN of Fig. 5.17 with a terminal atta hing to the mesh network through Node 4. Fig.
5.17a shows the initial setup; the data frames ex hanged between
the terminal and the IP gateway are represented by the arrows. If the link between Node 2 and Node 4 breaks, as shown in Fig. 5.17b, the path between the terminal and the IP gateway be omes invalid. Upon dete ting the link failure, Node 4 sele ts Node 3 as its new parent node and the a tive topology depi ted in bold in Fig. 5.17 is on gured. At this point, when Node 4 rst re eives a data frame from the terminal destined to the IP gateway, it does
CHAPTER 5.
SFA FRAMEWORK
167
Notation
Des ription
BC Caddr CP CSN Dp HM Hmax LC [i] Li LP Maddr Paddr P SN SCi SNR SRCT R TT R
Set of best andidate parent nodes Address of the urrent mesh node Current parent mesh node in the tree rooted at the master Current sequen e number De ision period (se onds) = 3 · TT R Distan e (number of hops) to the master Maximum number of hops a T R message an traverse Lifetime of the asso iation established with hild i List of andidate parent nodes of node i Lifetime of the asso iation established with CP Address of the master Parent address in the T R message Previously transmitted sequen e number Set of hildren of node i Set of nodes re eiving the T R message T R message sour e T R broad ast interval (se onds)
Table 5.4: Notations used in the formal des ription of the ATCM me hanism.
not know the path to the IP gateway, sin e Node 4's parent hanged. Node 4 then sends the data frame through all lo al interfa es, ex ept that from whi h it re eived the frame. Node 3 kept the same parent node, so it simply forwards the frame re eived from Node 4 a
ording to the lo al Learning Bridge Forwarding Table; the same happens for Node 1.
In the opposite
dire tion, the master MAP learns the new path to the terminal when the terminal rst sends a frame after the new a tive topology is set; before that the frames destined to the terminal are sent by the master MAP to Node 2, as illustrated in Fig. 5.17 , a
ording to the old path. ATCM guarantees that a loop free a tive topology is always established, sin e ea h MAP sele ts one and only one parent MAP at ea h moment; the proof an be found in Appendix B.
5.3.3 Frame Forwarding using Learning Bridges Uni ast The tunnel endpoints reated using the ATCM me hanism a t as ports of the Learning Bridge. The Eo11 en apsulation makes it possible for a node to send a uni ast frame to the neighbor at the other end of the tunnel, while
CHAPTER 5.
SFA FRAMEWORK
168
Learning Bridge
Other Interfaces
tun#0
tun#1
...
tun#n
WiFIX
802.11 NIC
Figure 5.18: The Learning Bridge running in ea h MAP whose ports are the Eo11 tunnel endpoints.
maintaining the original sour e and destination addresses.
Moreover, the
bridge does not need to work in promis uous mode, sin e a uni ast frame destined to a node multiple hops away from the sour e will have as outer destination MAC address the next hop in the path towards the destination. The original uni ast frame is de apsulated at every node. The learning bridge algorithm assumed by WiFIX will then pro ess a uni ast frame a
ording to the following rules:
•
•
tunnel endpoint, add to the bridge forwarding table a pair (frame sour e address on Eo11 header, port orresponding to the tunnel with endpoint equal to Address 2 of 802.11 header); upon re eiving a uni ast frame from a
if the uni ast frame destination address exists in the bridge forwarding
tunnel endpoint indi ated in the bridge forwarding table. The frame is afterwards en apsulated with Eo11 and sent to the asso iated endpoint address;
table, send the frame to the
•
if the uni ast frame destination address does not exist in the bridge forwarding table, send the frame to all
tunnels, ex ept that from whi h
the frame was re eived.
The rules presented are those used in the learning bridge algorithm des ribed in Chapter 4. The dieren es, in bold, have to do with the fa t that the ports of the Learning Bridge are tunnel endpoints, as shown in Fig. 5.18.
CHAPTER 5.
SFA FRAMEWORK
169
Broad ast If the destination address of a frame re eived by the Learning Bridge is the broad ast address, the bridge will send the frame to all ports (tunnel endpoints), ex ept that from whi h the frame was re eived. The forwarding of broad ast tra in the mesh network requires that broad ast frames are en apsulated in uni ast frames, one per neighbor. Sin e a node has a tunnel per neighbor, the broad ast frame is sent with Eo11, where
n
n − 1 times in uni ast en apsulated
is the number of nodes forming the mesh network. This
te hnique is more reliable and e ient than that used by 802.11s. 802.11s uses (unreliable) pure ooding for oping with broad ast tra , whi h leads to
n
transmissions per broad ast frame.
5.3.4 Stub WMN Basi Conne tivity Me hanism The Stub WMN BC (SBC) me hanism is used in the IP auto- on guration of the terminals atta hing to the Stub WMN. In prin iple, the MAPs are not IP-enabled. If needed, they an also run the SBC me hanism. The SBC me hanism aims to improve the e ien y of the IP auto- on guration pro edure, when dual-sta k IP terminals are used. The SBC me hanism runs between the terminals atta hing to the Stub WMN and the master MAP. It
onsists in the same pro edure used by the PBC me hanism when running for
Proposal and Agreement messages are also the same although, in this ase, the auto onf-me hanismsroles eld in Proposal and the server-MAC-addr in Agreement are not de ned. The Proposal and Agreement messages are transported a ross the Stub WMN as any other data frame. The Proposal is sent in broad ast, and the Agreement is sent dire tly to the sour e of the Proposal in uni ast; a standalone PAN, as illustrated in Fig. 5.19. The
both are forwarded a
ording to the frame forwarding pro edure spe i ed in Se tion 5.3.3.
The master MAP is assumed to be pre- on gured with
the IP version and the lega y IP auto- on guration me hanism supported in the infrastru ture it is atta hed to. When the master MAP re eives a
Pro-
posal, it uses that information to onstru t the Agreement. Upon re eiving the Agreement message, the terminal uses the lega y IP auto- on guration me hanism to on gure an IP address and the optional information.
If the wired infrastru ture supports only one IP version and one lega y IP auto- on guration me hanism, the
Agreement
is simply de ned by the
information pre- on gured in the master MAP. However, if multiple IP ver-
CHAPTER 5.
SFA FRAMEWORK
170
Master MAP
Terminal
Proposal Agreement
Figure 5.19: Illustration of the Stub WMN BC me hanism.
sions or lega y IP auto- on guration me hanisms are supported, the master MAP mat hes them with the information in luded in the
Proposal.
If the
out ome of the mat hing pro ess still onsists in multiple options, one of them is randomly sele ted.
5.3.5 Support of Lega y Devi es Any lega y terminal an atta h to the Stub WMN and get a
ess to the wired infrastru ture. This is enabled by the Learning Bridges and the lega y IP auto- on guration me hanisms proposed. WiFIX an also support lega y terminals using te hnologies su h as Ethernet and UWB, as shown in Fig. 5.13. This represents one of its major advantages when ompared with the state of the art solutions, namely the IEEE 802.11s tree-based solution, whi h is limited to 802.11 terminals.
In 802.11s, the terminals
running behind the MAPs need to be registered expli itly at the root MP. For that purpose, 802.11-spe i me hanisms are involved.
A MAP rst
learns the terminals' addresses during their asso iation to the MAP by using standard 802.11 pro edures. Then, the MAP registers the terminals at the root MP by means of the messages ex hanged in the PREQ and RANN me hanisms.
5.3.6 Tables Maintained Ea h MAP maintains three tables: the Parent Candidates Table, ParentChildren Table, and the Learning Bridge Forwarding Table.
The Parent
Candidates Table stores temporarily the set of neighbors that are andidates to be sele ted as the parent node in the tree rooted at the master MAP. The Parent-Children Table stores information about the node sele ted as the
CHAPTER 5.
SFA FRAMEWORK
171
parent node in the tree, the tunnel endpoint through whi h it is rea hable, the hildren in the tree, and the orresponding tunnel endpoints through whi h the hildren are rea hable. is well known.
The Learning Bridge Forwarding Table
The master MAP maintains two tables only:
the Parent-
Children Table and Learning Bridge Forwarding Table, as it has no parent.
5.3.7 Se urity WiFIX does not address se urity issues. Still, it may in orporate existing solutions de ned within IEEE 802.11 networks, su h as IEEE 802.1X [Gro07℄ and WPA-PSK [Gro07℄. WPA-PSK may be used to establish a se ure 802.11 ad-ho network among the MAPs.
This ensures se urity within the Stub
WMN. On the other hand, IEEE 802.1X may be used as in urrent Wi-Fi networks for terminal authenti ation and a
ess ontrol.
Regarding other
wireless te hnologies that may be used by terminals to atta h to the Stub WMN, any built-in se urity me hanisms available may be used as well.
5.4 Summary State of the art solutions are omplex and do not address the network auto- on guration problem thoroughly.
In this hapter we presented the
SFA framework, our proposal for solving the network auto- on guration of multi-te hnology PANs and Stub WMNs. The ar hite ture of the SFA and its main building blo ks were des ribed. SFA is based on two lega y building blo ks, Learning Bridges and lega y IP auto- on guration me hanisms, whi h make it ba kwards ompatible and enable the support of lega y devi es. Subsequently, we presented the two on rete solutions derived from SFA to address multi-te hnology PANs and Stub WMNs, named ASPAN and WiFIX. ASPAN follows a master-slave paradigm, where the master oordinates the me hanisms running within a PAN, namely the a tive topology on guration and the PoA sele tion, managed by the PGC me hanism; the PBC me hanism is used to establish IP onne tivity and may be oordinated by the master or by the devi e sele ted as the PAN gateway. For the omputation of the a tive spanning tree, the PAN master onsiders a new approximation MRCST algorithm,
Campos's
algorithm.
Overall, ASPAN de nes
new me hanisms and inherits the simpli ity of Learning Bridges and lega y
CHAPTER 5.
SFA FRAMEWORK
172
IP auto- on guration me hanisms. WiFIX follows a hybrid approa h. A master MAP broad asts a signaling message periodi ally, whi h is used by the other MAPs to reate and maintain the a tive topology in a distributed way.
The a tive topology is
de ned by a set of virtual links established between neighbor MAPs, whi h together form a spanning tree rooted at the master MAP. A Stub WMN has its gateway prede ned. So, WiFIX does not onsider any gateway on guration me hanism. Con erning IP onne tivity, the master MAP announ es the IP version and the lega y IP auto- on guration me hanism that shall be used by the terminals atta hing to the Stub WMN. Sin e MAPs are, in prin iple, non-IP nodes, IP onne tivity is on gured only at the terminals atta hing to the Stub WMN; the SBC me hanism is de ned for this purpose. WiFIX an support other wireless te hnologies, su h as Ethernet and UWB. This is not possible using state of the art solutions, namely the IEEE 802.11s tree-based routing solution, due to the need of registering the terminals at the root MP expli itly. As instan es of the same framework, ASPAN and WiFIX have similarities; both on gure a single spanning tree a tive topology and sele t the proper lega y IP auto- on guration me hanism to establish IP onne tivity by using a meta auto- on guration me hanism. They have also dieren es that are related mainly to topology and gateway on guration. Regarding topology re on guration, while ASPAN ushes ARP (or NDP) tables to enfor e fast path re on guration, WiFIX impli itly uses the frequent data frames ex hanged between terminals and the IP gateway to fast on gure the new paths. Con erning gateway on guration, while in WiFIX the gateway is prede ned, in ASPAN it is dynami ally on gured a
ording to the available a
ess links to the outside world.
Chapter 6
Evaluation This hapter is devoted to the evaluation of ASPAN and WiFIX. The evaluation is performed based on theoreti al, simulation, and experimental analysis. Se tion 6.1 presents the evaluation methodology. Se tion 6.2 evaluates ASPAN and Se tion 6.3 evaluates WiFIX. Se tion 6.4 dis usses the results and their impli ations for both solutions, and Se tion 6.5 summarizes the ontents of the hapter.
Throughout the hapter, the terms path and
route, devi e and node, and frame and pa ket are used respe tively with the same meaning.
6.1 Evaluation Methodology Firstly, we onsidered the state of the art solutions to whi h ASPAN and WiFIX were to be ompared to.
Sin e there is no solution addressing the
network auto- on guration problem as a whole, we onsidered the state of the art solutions addressing two sub-problems: 1) path on guration; 2) IP
on guration. Path on guration solutions for PANs are mostly based on rea tive ad-ho routing proto ols, in parti ular AODV. For that reason, AODV and AODV-DR were sele ted for omparison purposes; AODV-DR was onsidered, sin e it uses the same routing metri as ASPAN.
Campos's
algo-
rithm, whi h is part of the ASPAN path on guration pro edure, had also its performan e evaluated against the following spanning tree algorithms: the IEEE spanning tree algorithm,
Kruskal's
and
Prim's
Wong's
algorithm, the
Add
algorithm, and
algorithms. WiFIX path on guration was ompared
against IEEE 802.11s tree-based routing.
The ASPAN and WiFIX broad-
ast approa h was ompared to pure ooding. Con erning IP on guration,
173
CHAPTER 6.
EVALUATION
174
ASPAN and WiFIX were ompared against the urrent trial-and-error me hanism. Se ondly, we sele ted the evaluation metri s. Con erning ASPAN, through-
1
put, delay, path establishment delay, path on guration load , and re on guration time due to topology hanges, were used to ompare ASPAN with AODV/AODV-DR. For
Campos's
algorithm, the routing ost and exe u-
tion time were sele ted, with the purpose of demonstrating that our algorithm has lower exe ution time than the fastest known approximation MRCST algorithm and that it has time omplexity of the same order of
Kruskal's, Prim's,
Add,
and IEEE algorithms. For WiFIX we sele ted through-
2
put, delay, path on guration overhead , and re on guration time due to topology hanges. For IP on guration, the number of signaling bytes and messages transmitted and the time required to perform the IP on guration were onsidered. Theoreti al, simulation, and experimental analysis was employed. Theoreti al analysis was used whenever possible. For simulation, two simulators were onsidered: the Spanning Trees Simulator (STS) and the Network Simulator 2 (NS-2). STS was developed from the s rat h to evaluate
Campos's
algorithm against the algorithms mentioned above. NS-2 was used to ompare ASPAN with AODV/AODV-DR. By the time the evaluation work was
arried out, IEEE 802.11s was not supported in NS-2.
As su h, simula-
tion analysis was not onsidered to ompare WiFIX with IEEE 802.11s, and this evaluation was a
omplished by means of theoreti al and experimental analysis.
6.2 ASPAN Evaluation ASPAN was evaluated by means of theoreti al analysis, simulations, and real experiments. We start with the evaluation of
Campos's
algorithm. Af-
terwards, we present the evaluation of the ASPAN path on guration based on simulation results obtained using NS-2. The re on guration time when a node leaves the PAN, the ASPAN broad ast forwarding method, and the 1
The path on guration load is de ned as the number of path on guration pa kets issued per se ond over the number of data pa kets su
essfully re eived at the destination(s). 2 The path on guration overhead is de ned as the number of path on guration pa kets issued per se ond.
CHAPTER 6.
EVALUATION
175
PBC me hanism are studied based on numeri al results. Finally, we refer to the experimental evaluation performed using a proof-of- on ept prototype.
6.2.1
Campos's
algorithm
While employed in the ontext of ASPAN solution,
Campos's
algorithm
is a generi approximation MRCST algorithm that an also be used in other
ontexts. As su h, the evaluation presented here is made generi , although at the end of the subse tion we address s ope.
A possible approa h to evaluate
Campos's Campos's
algorithm in the PAN algorithm ould be to
onsider an asymptoti al analysis from the perspe tive of the routing ost and a time omplexity analysis regarding its exe ution time. However, this analysis provides information only about the worst ase s enario. Thereby, we onsidered a simulation oriented approa h so that the performan e of the algorithm in other ases, namely in pra ti al ases, ould be evaluated. A wide range of randomly generated input graphs, from homogeneous to highly heterogeneous graphs, have been simulated for that purpose.
The Spanning Trees Simulator The Spanning Trees Simulator (STS) is written in C++ and uses the popular Boost Graph Library (BGL) [SLA℄ for the omputation of MSTs and
Dijkstra's, it in ludes the Add, Wong's,
SPSTs a
ording to the lassi al spanning tree algorithms, su h as
Prim's, and Kruskal's algorithms; in addition, and Campos's algorithms. Campos's algorithm
is implemented using Fi-
bona
i heaps in onjun tion with adja en y lists so that a time omplexity
O(m + n.log(n))
an be a hieved. STS generates random graphs, omputes
spanning trees using the aforementioned spanning tree algorithms, and provides the average routing ost and the average exe ution time for ea h spanning tree algorithm simulated. STS a
epts the following input parameters: 1.
smax
the maximum size for the input graphs expressed in number of
verti es. 2.
smin
the minimum size for the input random graph. This parameter
also de nes the granularity in the generation of the input graphs. For instan e, if the maximum size is set to 30 and the minimum size is set to 10, the simulator will simulate input graphs with 10, 20, and 30 verti es.
CHAPTER 6.
3.
emax
EVALUATION
the maximum number of edges to be simulated for ea h input
n
graph with 4.
S
176
verti es.
the set of edge weights onsidered while generating an input ran-
dom graph. 5.
sta
the spanning tree algorithm to be simulated, besides the two
spanning tree algorithms onsidered as referen e by the simulator, i.e.,
Wong's
the urrent IEEE spanning tree algorithm and 6.
nr
algorithm.
the number of simulation runs.
Taking into a
ount these input parameters the simulator de nes the following sequen e of steps for ea h simulation run.
2smin ,
For ea h
n ∈ {smin ,
..., smax }, STS generates
in reasing number of edges
emax − (n − 1) + 1 random graphs with m ∈ {n − 1, n, n + 1, ..., emax }. It employs
one of the variants of the Erdös and Renyi [ER59℄ model for generating the random graphs.
The rst variant onsiders a random graph with
verti es and de nes a probability
p
n
that an edge is present in the graph.
The se ond variant sets an edge between ea h pair of verti es with equal probability, independently of the other edges. STS uses the latter variant. For ea h randomly sele ted edge, STS assigns it a random weight from the set
S
with equal probability.
This results in a graph
G
at random from the olle tion of all graphs whi h have edges.
For ea h
G,
the simulator omputes
n
hosen uniformly
n
verti es and
m
SPSTs, the routing ost for
ea h SPST, and it sele ts the lowest routing ost as the routing ost for the approximate MRCST provided by
Wong's
algorithm.
In addition, it
al ulates the value for the routing ost of an arbitrarily sele ted SPST, as onsidered by the urrent IEEE spanning tree algorithm, and al ulates the routing ost for a spanning tree omputed using the IEEE and
Wong's
sta
algorithm; the
algorithms are onsidered as a referen e by STS, sin e
they represent, respe tively, the urrent used spanning tree algorithm in real networks and the fastest approximation MRCST algorithm.
Besides
the routing ost, the simulator also al ulates the exe ution time for ea h spanning tree algorithm. At ea h simulation run, STS stores the values of the routing ost and exe ution time found for ea h is repeated for
nr
(n, m).
The whole pro ess
simulations.
The STS simulator provides two output parameters: the average routing
ost and the average exe ution time for ea h
(n, m)
and for ea h simulated
CHAPTER 6.
EVALUATION
spanning tree algorithm.
177
These values are omputed onsidering
nr
sim-
ulations; the margin of error for ea h value is also presented regarding a
on den e interval of 95%. STS provides the routing osts and the exe ution times for
Wong's
and
sta
algorithms normalized to the values obtained
for the IEEE spanning tree algorithm, i.e., the time required to ompute an SPST. STS is open sour e and an be downloaded at [Camb℄, where further information about it is provided.
Simulation Setup We onsidered a wide set of simulations to evaluate
Campos's
algorithm
against the spanning tree algorithms referred to in Chapter 3. The following spanning tree algorithms were onsidered as ben hmarks: the urrent IEEE
Wong's algorithm, as the urrent fastest approximation MRCST algorithm, the Add algorithm, as the fastest approximation spanning tree algorithm,
MRCST algorithm for the spe i ase of homogeneous input graphs, and the two most used MST algorithms,
Kruskal's
and
Prim's
algorithms, known to
provide good approximation to an MRCST for highly heterogeneous graphs [ML05℄ [MM05℄.
The omparison between the various spanning tree algo-
rithms was based on the routing ost of the spanning tree returned and the exe ution time of ea h algorithm. The following input parameters were used:
size of the input random
graph; set of edge weights used in the generation of the input random graph. Sin e our fo us is on graphs modeling small s ale networks, we onsidered input random graphs with 10, 30, and 50 verti es. For ea h
n
de ning the
size of the input graph, we performed simulations for ea h possible number of edges, i.e., from
n−1
(tree) to
n.(n − 1)/2
( omplete graph) in order to
over the whole spe trum of topologies for a graph with
n
verti es. A wide
range of input graphs, from homogeneous to highly heterogeneous graphs, have been overed by de ning dierent input sets of edge weights generated using the following dis rete fun tions, for
n ∈ N:
u[n] = K n−1 , 1 ≤ n ≤ 5 v[n] = n, 1 ≤ n ≤ 5
CHAPTER 6.
EVALUATION
1 w[n] = K1 .w[n − 1] K2 .w[n − 1]
178
if if if
n=0 n odd, n even,
1 ≤ n ≤ 10 2 ≤ n ≤ 10
K , K1 , K2 are onstants. In our simulations, K ∈ {1, 10}, K1 = 5, and K2 = 2. For K = 1 the dis rete fun tion u[n] was used to generate homogeneous input graphs; for K = 10 it was used to generate highly hetwhere
erogeneous input graphs with edge weights sele ted from the sets
S1 = {1, 10, 100}; S2 = {1, 10, 100, 1000, 10000} v[n] and w[n] were used to generate slightly heterogeneous and heterogeneous input graphs, respe tively. v[n] was used to generate
The fun tions highly
the sets
S3 = {1, 2, 3}; S4 = {1, 2, 3, 4, 5} and
w[n]
was employed to generate the set
S5 = {1, 5, 10, 50, 100, 1000, 5000, 10000, 50000} There is no parti ular reason to onsider these spe i dis rete fun tions for generating the sets of edge weights. The only obje tive was to onsider sets of edge weights with dierent levels of heterogeneity. Therefore, other sets
ould be onsidered, as long as they ould be used to generate input random graphs with dierent levels of heterogeneity. In the ontext of our simulations a set of edge weights represents the possible values for a given metri , e.g., bandwidth, delay, used to hara terize a link of a ommuni ation network.
In pra ti e, few possible values are
usually de ned for a given metri . Consider, for instan e, the example of an Ethernet network where 1 Gbit/s and 10 Gbit/s links oexist with lega y 100 Mbit/s links. If we hara terize ea h link a
ording to its apa ity, we get values of 1, 10, and 100. The same happens in multi-te hnology PANs where te hnologies su h as UWB, Bluetooth, and IEEE 802.11 may oexist in the same network. If we assign weights to ea h wireless link a
ording to some of the metri s mentioned above, a few possible values will be de ned as well. In that sense, the sets of edge weights onsidered in our simulations in lude just a few values; however, in order to over dierent ases, we took into a
ount dierent sizes for the sets of edge weights by varying the number of values generated through the dis rete fun tions
u[n], v[n],
and
w[n].
CHAPTER 6.
EVALUATION
179
The same set of simulations was performed for ea h spanning tree algorithm under analysis. One hundred simulations were performed for ea h set of input parameters (size of graph, set of edge weights).
Simulation Results This se tion evaluates the various spanning tree algorithms from the perspe tives of the routing ost and exe ution time.
The most relevant
results are presented here and additional results an be found in Appendix A and in [Camb℄. Along the des ription and analysis of the simulation results we use the expressions sparse graph and dense graph to refer to the density of the input graphs; sparse graphs refer to graphs with the number of edges
m = Θ(n),
Routing Cost.
while dense graphs refer to graphs with
m = Θ(n2 )
The routing ost of the spanning trees omputed by ea h
spanning tree algorithm was analyzed for dierent input graphs. Below, we present the simulation results for homogeneous and highly heterogeneous input graphs. The urves for the dierent spanning tree algorithms under analysis, i.e.,
Campos's, Prim's, Kruskal's, the Add, and Wong's
algorithms,
are shown in Fig. 6.1 and Fig. 6.2 with the orresponding 95% on den e intervals. The results were obtained for input random graphs with 10, 30, and 50 verti es.
They are normalized to the routing ost of the spanning
tree obtained by using the IEEE spanning tree algorithm and are presented as a fun tion of the average degree per vertex (the maximum average degree per vertex is equal to
n−1
and orresponds to the omplete input random
graph). For the sake of learness, the urves orresponding to spanning tree algorithms providing similar routing osts are presented in the same plot. The plots shown in Fig. weights
6.1 were obtained onsidering the set of edge
S = {1} as input to the STS simulator;
the simulator uses
sis to generate the input random graphs. In this ase the set by using the dis rete fun tion we an rstly on lude that
u[n]
with
Campos's
n = 1.
S
S
as a ba-
was obtained
From the plots in Fig. 6.1
algorithm provides an approximate
MRCST with the same routing ost as the spanning tree provided by
Wong's
algorithm regardless of the number of verti es of the input graph.
There-
fore, on erning homogeneous input graphs
Campos's
algorithm an in fa t
be used as an approximation MRCST algorithm providing the same routing
ost as
Wong's
algorithm while running in 1/nth of the time. In addition,
CHAPTER 6.
EVALUATION
180
we on lude that, in general, our algorithm provides a spanning tree with the same routing ost as the graph in reases,
Campos's
Add
algorithm. But, as the size of the input
algorithm performs even better than the
gorithm for sparse input graphs. This an be seen in Fig. 6.1 for
Add
al-
n = 50;
the dieren e in the routing ost, on average, rea hes about 7% for an average degree per vertex equal to 4. The dieren e an be explained by the
cfv
parameter onsidered in
Campos's algorithm.
Unlike the
Add
algorithm,
whi h only onsiders the degree of the verti es as the de ision riterion to sele t the next spanning relay,
Campos's algorithm also onsiders the ost of
the path to the initial vertex as riterion. This ontributes to a redu tion of the diameter of the nal spanning tree and, onsequently, of its routing ost, although it only takes relevant ee t for sparse graphs; for dense graphs the
ost of the path between ea h vertex and the initial vertex tends to be similar or equal, as it happens for the omplete graph, and the degree of the verti es
riterion is enough to nd a good approximate MRCST. Finally, algorithm, as well as
Wong's and the Add
Campos's
algorithms, provides lower routing
osts than the urrent IEEE spanning tree algorithm, independently of the size of the input graph, even though the gain in reases with the size of the input graph and is higher for sparse graphs; for 10% while for
n = 50
n = 10 the gain
may a hieve
it may a hieve about 13%.
As expe ted, MST algorithms represent a bad approximate MRCST when the input graph is homogeneous. better than
Kruskal's
Still,
Prim's
algorithm. The routing ost for
algorithm performs
Kruskal's
algorithm
diverges from the routing osts provided by any of the other spanning tree algorithms. The algorithm is only on erned with the sele tion of the
n−1
edges with the lowest weight so that the total ost of the resulting spanning tree an be minimized. Sin e in this ase the weights are all the same, the nal spanning tree will result from the random sele tion of input graph
G that together
form a spanning tree of
G.
n − 1 edges of the
Thus, with no sele -
tion riterion in pla e, the resulting spanning tree tends to have higher diameter and, onsequently, higher routing ost. Regarding
Prim's
algorithm,
for small graphs, it provides routing osts lose or equal to the IEEE algorithm. Nonetheless, on erning sparse graphs, as the number of verti es in the input graph in reases,
Prim's
algorithm tends to provide higher routing
osts and diverges from the routing osts provided by the IEEE algorithm. For dense input graphs
Prim's
algorithm presents the same routing ost as
EVALUATION
1.2
181
Routing Cost (normalized)
Routing Cost (normalized)
CHAPTER 6.
Campos Wong Add
1.1 1 0.9 0.8 0.7 0
2 4 6 8 Average Degree per Vertex
4
Prim Kruskal
3.5 3 2.5 2 1.5 1 0.5
10
0
2 4 6 8 Average Degree per Vertex
1.2
(b) n = 10
Routing Cost (normalized)
Routing Cost (normalized)
(a) n = 10
Campos Wong Add
1.1 1 0.9 0.8 0.7 0
5
10
15
20
25
4
Prim Kruskal
3.5 3 2.5 2 1.5 1 0.5
30
0
Average Degree per Vertex
Routing Cost (normalized)
Routing Cost (normalized)
1 0.9 0.8 0.7 0
10 20 30 40 Average Degree per Vertex
(e) n = 50
10
15
20
25
30
(d) n = 30
Campos Wong Add
1.1
5
Average Degree per Vertex
( ) n = 30
1.2
10
50
4
Prim Kruskal
3.5 3 2.5 2 1.5 1 0.5 0
10 20 30 40 Average Degree per Vertex
50
(f) n = 50
Figure 6.1: Routing osts for ea h spanning tree algorithm under analysis when
homogeneous
input graphs of 10, 30, and 50 verti es are onsidered.
CHAPTER 6.
EVALUATION
182
the IEEE algorithm and, in the extreme ase ( omplete graph), it provides the same routing ost as
Campos's, Wong's, and the Add
algorithms, sin e it
a tually omputes an SPST from the initial vertex's perspe tive that de nes the best SPST (for the omplete graph any SPST is the best SPST). The plots shown in Fig. 6.2 were obtained by onsidering the set of edge weights
S = {1, 10, 100, 1000, 10000}
u[n]
obtained by using the dis rete fun tion Only the plots for
n = 10
and
S was 1 ≤ n ≤ 5. n = 30 the
as input to the STS simulator.
n = 50
K = 10
with
and
are presented, sin e for
results are very similar to the results obtained for
n = 50.
From the plots in Fig. 6.2 we on lude that, when the number of verti es in the input graph is small (n the same results as graph.
Wong's
= 10),
Campos's
algorithm provides
algorithm regardless of the density of the input
As the size of the input graph in reases,
Campos's
algorithm per-
forms dierently depending on the density of the input graph. graphs it provides the same routing osts as lustrated by the plot of Fig. 6.2 for
n = 50;
Wong's for
For sparse
algorithm. This is il-
n = 30
the performan e of
the algorithm is very similar. As the average degree per vertex in the input
Campos's algorithm slightly diverges from the routing osts Wong's algorithm (dieren es of about 10% an be a hieved).
graph in reases, provided by
Then, for highly heterogeneous graphs our algorithm provides the same results as
Wong's
algorithm when the input graph is small or, for bigger input
graphs when it is sparse; for dense graphs it provides slightly worse results. When ompared to the IEEE spanning tree algorithm, it provides lower routing osts independently of the size of the input graph. The gain may rea h about 17% for
n = 50
although, for dense input graphs, it de reases signi -
antly. The worse performan e for dense graphs an be explained as follows. For highly heterogeneous input graphs,
Campos's
algorithm onsiders the
edge weight as the major sele tion riterion. Thereby, it tends to follow the results provided by
Prim's
algorithm, whi h exhibits worse performan e for
dense input graphs; still, the in reasing rate of the routing ost as the input graph be omes denser is attenuated by the other parameters onsidered in our algorithm. Regarding MST algorithms, the simulation results on rm that as the input graph be omes more heterogeneous they tend to approximate the routing
osts provided by
Wong's
algorithm and an a tually be used as an approx-
imate MRCST. This is evident for
n = 10,
with
Prim's
algorithm providing
CHAPTER 6.
EVALUATION
1.2
Campos Wong
Routing Cost (normalized)
Routing Cost (normalized)
1.2
183
1.1 1 0.9 0.8 0.7
Campos Wong
1.1 1 0.9 0.8 0.7
0
2
4 6 8 Average Degree per Vertex
10
0
10
(a) n = 10
50
(b) n = 50 2.5
Prim Kruskal
Routing Cost (normalized)
Routing Cost (normalized)
2.5
20 30 40 Average Degree per Vertex
2
1.5
1
0.5
Prim Kruskal
2
1.5
1
0.5 0
2
4 6 8 Average Degree per Vertex
10
0
( ) n = 10
10
20 30 40 Average Degree per Vertex
50
(d) n = 50
Figure 6.2: Routing osts for ea h spanning tree algorithm under analysis when
highly heterogeneous
input graphs of 10 and 50 verti es are onsidered.
routing osts that an be just 1% higher than the routing osts provided by
Wong's to the
Kruskal's algorithm also shows a results given by Wong's algorithm. For bigger algorithm;
tenden y to onverge input graphs this an
only be observed for sparse graphs. For dense graphs, the heterogeneity inherent to the set of edges weights
S
tends to be less re e ted in the generated random input graphs; that is, the probability of equal weights assigned to the edges of the graph in reases. In order to redu e this probability and in rease the level of heterogeneity in the input graphs, we have performed further simulations using the input edge weight set
S = {1,
5, 10, 50, 100, 500, 1000, 5000, 10000,
using the dis rete fun tion
on rm that both
Prim's
w[n]. and
50000}
generated
The results an be found in [Camb℄. They
Kruskal's
algorithms tend to approximate
Wong's algorithm results also for denser graphs when high heterogeneity is in pla e; for instan e, for n = 30 the routing osts provided by Prim's algorithm are below the routing osts for the IEEE algorithm regardless of the density of the input graph and are only about 10% higher than the routing osts provided by
Wong's
algorithm; the ex eptions are the input graphs with
density lose to the omplete graph, where a bit more from
Wong's
Prim's
algorithm results.
algorithm results diverge
Furthermore, the results show
CHAPTER 6.
that
Campos's
EVALUATION
184
algorithm follows the tenden y of
Prim's
algorithm (used as
a basis of the former) and indeed provides better results for dense graphs as the heterogeneity in the input graph in reases. In fa t, this was already expe ted sin e
Campos's algorithm is basi ally an improved version of Prim's
algorithm, namely for highly heterogeneous input graphs, where the edge weights represent the most relevant riterion in the algorithm. This lets us
on lude that, even for high heterogeneous input graphs, tends to approximate
Campos's algorithm
Prim's algorithm results whi h has been demonstrated
to represent an approximation MRCST algorithm or even the exa t MRCST algorithm in su h ases [ML05℄ [MM05℄.
Add
The simulation results for the
algorithm regarding highly heteroge-
neous input graphs are not presented, sin e the results provided in Appendix A for slightly heterogeneous input graphs on rm that the algorithm does not work for heterogeneous input graphs. In fa t, for highly heterogeneous input graphs, during our simulations we veri ed that, for instan e for the routing osts provided by the
Add
n = 30,
algorithm ould rea h two and even
three orders of magnitude higher than the routing osts of the other spanning tree algorithms under analysis.
Exe ution time.
The results shown in Fig.
6.3 are independent of the
set of edge weights used to generate the input random graphs. In fa t, the exe ution time is in uen ed by the number of verti es and the number of edges of the input graph, as expressed in Chapter 3 for the dierent spanning tree algorithms. Therefore, the results were obtained by only varying these two parameters. The values for ea h algorithm are normalized to the time needed to ompute an SPT using for
Wong's
Dijkstra's
algorithm. The exe ution time
algorithm is not shown sin e it is simply
n
times the exe ution
time needed to ompute one SPST. The results are in a
ordan e with the time omplexities of the algorithms provided in Chapter 3. same exe ution time as of
Prim's
formed by
Dijkstra's
Campos's
algorithm essentially takes the
algorithm and 2 times the exe ution time
algorithm; this is mostly due to the additional al ulations per-
Campos's
algorithm regarding the sele tion of the initial vertex.
As expe ted, the exe ution times of both
Campos's and Prim's algorithms do
not strongly depend on the number of edges in the input graph; the number of verti es has the major impa t as demonstrated by the time omplexities provided in Chapter 3. The
Add
algorithm has exe ution times similar to
CHAPTER 6.
185
3.5
Campos Add Prim Kruskal
3 2.5 2 1.5 1 0.5
Campos Add Prim Kruskal
3
Execution Time (normalized)
Execution Time (normalized)
3.5
EVALUATION
2.5 2 1.5 1 0.5
0
0 0
2
4 6 8 Average Degree per Vertex
10
0
5
10 15 20 Average Degree per Vertex
(a) n = 10
30
(b) n = 30 3.5
Execution Time (normalized)
25
Campos Add Prim Kruskal
3 2.5 2 1.5 1 0.5 0 0
10
20
30
40
50
Average Degree per Vertex
( ) n = 50 Figure 6.3: Exe ution time for ea h spanning tree algorithm under analysis
onsidering input graphs of 10, 30, and 50 verti es.
Prim's
algorithm for sparse graphs, but runs faster when the density of the
input graph in reases. This is aused by the tenden y for many verti es to be added to the spanning tree at ea h step of the algorithm, as explained in [Gro05b℄, in ontrast to what happens in
Prim's
algorithm where a single
vertex is added to the spanning tree at ea h step. A
ording to our simulation results, for
n = 10, n = 30,
about 5 and 10 times faster than
and
Add algorithm an be Campos's algorithms, respe -
n = 50,
Prim's
and
the
tively, on erning dense input graphs; the dieren e is even greater when the number of verti es in the input graph in reases. more time to ompute a spanning tree.
Kruskal's
algorithm takes
Also, its exe ution time in reases
with the number of edges in the input graph; this is onsistent with the time omplexity dis ussed in Chapter 3.
Kruskal's
algorithm is simple to
implement by using a priority queue, but it is the least e ient spanning tree algorithm.
Dis ussion.
Our early idea of ombining the riteria used by the MST al-
gorithms (edge weights) and the
Add
algorithm (degree of the verti es) in
CHAPTER 6.
EVALUATION
186
a single algorithm revealed to be a good approa h to design a new approximation MRCST algorithm. Besides performing well for the extreme ases already overed by the
Add and Prim's algorithms, Campos's algorithm pro-
vides good results for other ases. In fa t, in general it provides results similar to those obtained using
Wong's
algorithm and runs
n
times faster. Never-
theless, regarding in reasing heterogeneous input graphs it tends to perform better for sparse input graphs than for dense graphs, although this tenden y disappears for extremely heterogeneous input graphs. Additionally, for homogeneous input graphs it provides the same routing ost as the spanning tree onstru ted by using the
Add
algorithm, in general, but performs better
for sparse graphs as the number of verti es in the input graph in reases. In pra ti al ases, the
Add
Campos's
algorithm; the gain augments as the number of verti es in the in-
put graph in reases. graphs,
algorithm an provide lower routing osts than
Campos's
On the other hand, on erning highly heterogeneous
algorithm tends to approximate the results provided by
the MST algorithms whi h in su h onditions provide an approximate or the exa t MRCST. In all ases analyzed,
Campos's
algorithm always provides
a spanning tree with lower routing ost than the spanning tree omputed using the urrent IEEE algorithm, regardless the number of verti es or the number of edges in the input graph.
Campos's
algorithm has been de ned within ASPAN with the purpose
of omputing the a tive spanning tree. In pra ti e, the topology of a PAN is envisioned to de ne a sparse graph. The oexisten e of dierent wireless te hnologies and the limited number of network interfa es per network node pre ludes the establishment of dire t links from ea h devi e to all the others. So, ea h PAN devi e is only dire tly linked to a fra tion of the devi es present in the network and this fra tion tends to de rease with the in reasing number of nodes parti ipating in the PAN. On the other hand, due to the heterogeneous hara teristi s of the wireless te hnologies that may oexist within a PAN, namely in terms of data rates, the graph that models the PAN topology is heterogeneous. For sparse, heterogeneous graphs,
Campos's
algorithm onstru ts a spanning tree with routing ost similar to the routing
ost of the spanning tree obtained using
Wong's
algorithm and routing ost
lower than the routing ost of the spanning tree omputed using the urrent IEEE algorithm. alternative to
Thus, for PANs,
Wong's
Campos's
algorithm is indeed a faster
algorithm and it signi antly outperforms the IEEE
CHAPTER 6.
EVALUATION
187
spanning tree algorithm.
6.2.2 Evaluation of Path Con guration The ASPAN path on guration uses
Campos's
algorithm to ompute
the spanning tree that de nes the a tive PAN topology. The evaluation is performed based on simulation results obtained using NS-2 and onsidering AODV and AODV-DR as a basis for omparison.
Implementation under NS-2 The version 2.31 of the NS-2 simulator was used as departing point. NS2.31 does not support (1) multi-interfa e nodes, (2) network interfa es with dierent hara teristi s, namely in terms of nominal data rates, (3) AODVDR, (4) Learning Bridges, nor (5) ASPAN, of ourse. NS-2 had to be improved in order to support our simulation s enarios. Firstly, we modi ed NS-2.31 to support multi-interfa e nodes; the tutorial by Calvo and Campo [CC07℄ was followed for that purpose.
After these
modi ations, nodes ould run with multiple IEEE 802.11 interfa es, but all network interfa es had exa tly the same hara teristi s. So, further modi ations were made to the simulator to support network interfa es running on dierent nominal data rates.
In Chapter 2 we have seen that most of
the wireless PAN te hnologies are based on the CSMA/CA a
ess method. Therefore, we onsidered IEEE 802.11 as a basis and set up dierent nominal data rates to dierent network interfa es. At this stage, we were able to simulate AODV with multiple interfa es running on dierent nominal data rates. In the next step AODV-DR, Learning Bridge, and the ASPAN path on guration me hanisms were addressed. AODV-DR was implemented based on the modi ed AODV version referred to in the previous paragraph. The
ore AODV implementation was kept, and two modi ations were introdu ed a
ording to the spe i ation provided in [JPSS04℄. Firstly, the routing metri used to nd the routes was modi ed; upon re eiving a a
Route Reply,
Route Request
or
an AODV-DR node adds to the metri eld in luded in the
message the inverse of the data rate of the link through whi h it re eived the message. Se ondly, the number of
Route Request
and
Route Reply
messages
forwarded by intermediate AODV-DR nodes and a
epted by the destination AODV-DR node was set unlimited, so that the best route, in terms of the
CHAPTER 6.
EVALUATION
188
data rate metri , ould be found. The Learning Bridge forwarding omponent was implemented by reusing most of the implementation of the AODV forwarding omponent; the learning bridge algorithm was implemented from the s rat h. Finally, the ASPAN topology dis overy and the a tive topology
on guration me hanisms were implemented.
In ASPAN, path establish-
ment is based on ARP or NDP. ARP is already supported in NS-2.31; so, we used it as a basis for our simulations.
on guration me hanism, the
Campos's
Regarding the a tive topology
algorithm implementation in luded
in STS was integrated in NS-2 after some adaptations.
Simulation Setup We onsidered the simulation of PANs with random topologies.
NS-
2.31 does not provide the means to generate random networks when multiinterfa e nodes are onsidered.
Therefore, STS was used.
STS generates
random graphs to simulate spanning tree algorithms; so, it was simply extended to generate random graphs in
T l
format. Su h random graphs were
used as input to NS-2. Table 6.1 summarizes the input parameters onsidered in the simulations. The set
S = {1,
3
10, 100}
was onsidered to generate the heterogeneous
graphs in STS. Based on the
T l
les generated by STS, the NS-2 802.11
NICs were on gured with nominal data rates a
ording to the edge weights set by STS. The base nominal data rate was 11 Mbit/s. Thus, the generated random PANs in luded wireless links with nominal data rates of 11 Mbit/s, 110 Mbit/s, and 1.1 Gbit/s. In pra ti e, the nominal data rate ratios between the wireless PAN te hnologies referred to in Chapter 2 an rea h four orders of magnitude; in our simulations we were onservative and onsidered a maximum of two orders of magnitude only. PANs are envisioned to be small networks. Thereby, we simulated 10-node and 20-node PANs; for ea h ase, 30 random topologies were generated. node,
AN ICs ,
The average number of NICs per
was onsidered as an input parameter too, so that we ould
vary the density of the links between PAN devi es. PANs are expe ted to be sparse, so the maximum value for NICs per node was set to 3; the other values onsidered are shown in Table 6.1. Finally, we onsidered the number of pairs of nodes ommuni ating simultaneously as an input parameter, in 3
Remember that S denotes the set of edge weights onsidered for generating random graphs in STS (see Se tion 6.2.1.)
CHAPTER 6.
EVALUATION
189
Simulation Input Parameters
Values
No. of nodes forming the PAN (n) Average no. of NICs per node (ANICs ) Link nominal data rates No. of pairs ommuni ating simultaneously (np) TCP ow duration Pa ket size
{10, 20} {1.5, 2, 2.5, 3} {11,110,1100} Mbit/s {1, 2, 4} 10 se onds 1500 bytes
Table 6.1: Summary of the input parameters onsidered in our NS-2 simulations.
order to vary the tra demand within the PAN; the values simulated are also shown in Table 6.1.
TCP ows between random pairs of nodes were
simulated; the duration of the TCP ows was set to 10 se onds and the pa ket size was set to 1500 bytes. TCP was sele ted for two reasons. Firstly, it is the most used transport layer proto ol in IP networks.
Se ondly, it
adapts to the available bandwidth and enables easy measurement of the maximum throughput possible between two given nodes. We simulated the s enarios hara terized by the simulation input parameters presented in Table 6.1, in order to obtain the following output parameters: throughput, delay, path establishment delay, and path on guration load.
The NS-2.31 simulator developed in this thesis and the
T l
s ripts used in the simulations are available at [Camb℄.
Simulation Results Throughput and Delay.
The plots in Fig.
6.4 show the average TCP
throughput for ASPAN and AODV, normalized to the average TCP throughput obtained using AODV-DR. The values plotted in Figs. 6.4 6.4f were obtained onsidering TCP ows starting at dierent instants of time. In general, the ASPAN normalized throughput is around 1; this means that ASPAN and AODV-DR are equivalent solutions. This is aligned with our expe tations, taking into a
ount the premise that, for heterogeneous networks, the union of the shortest paths tends to a single spanning tree (refer to Chapter 3). Still, interestingly, as
n and np in rease,
ASPAN an in some
ases outperform AODV-DR. This is explained by the in reasing number of
Route Request
ollisions in AODV-DR, when
n and np in rease, as illustrated
by the plots provided in Appendix E. The higher number of
Route Request
EVALUATION
1.6
190
Normalized Throughput
Normalized Throughput
CHAPTER 6.
ASPAN AODV
1.4 1.2 1 0.8 0.6 0.4 0.2
1.6
ASPAN AODV
1.4 1.2 1 0.8 0.6 0.4 0.2
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
1.6
(b) n = 20, np = 1
Normalized Throughput
Normalized Throughput
(a) n = 10, np = 1
ASPAN AODV
1.4 1.2 1 0.8 0.6 0.4 0.2
1.6
ASPAN AODV
1.4 1.2 1 0.8 0.6 0.4 0.2
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
1.6
(d) n = 20, np = 2
Normalized Throughput
Normalized Throughput
( ) n = 10, np = 2
ASPAN AODV
1.4 1.2 1 0.8 0.6 0.4 0.2 1
Figure 6.4:
1.5
2
2.5
3
1.6
ASPAN AODV
1.4 1.2 1 0.8 0.6 0.4 0.2
3.5
1
1.5
2
2.5
3
3.5
Average No. of NICs per Node
Average No. of NICs per Node
(e) n = 10, np = 4
(f) n = 20, np = 4
Normalized ASPAN and AODV average TCP throughput for
10-node and 20-node PANs, when the average number of NICs per node and the number of pairs ommuni ating simultaneously is varied (n denotes the number of nodes forming the PAN and
ommuni ating simultaneously).
np
denotes the number of pairs
CHAPTER 6.
EVALUATION
191
ollisions has the ee t of preventing the dis overy of the best route in terms of the data rate metri . However, as
AN ICs in reases the limitation of using a
single spanning tree may prevail over the problem of higher number of
Request
Route
ollisions and ASPAN may suer a slight performan e de rease. As
expe ted, AODV performs worse than both ASPAN and AODV-DR, due to the use of the rst route found. The plots in Fig. 6.5 show the average one-way delay (OWD) obtained for the same setup. The ASPAN normalized OWD is again around 1. So, ASPAN and AODV-DR provide similar OWD values; AODV in urs higher OWD. These results are onsistent with the throughput results; in parti ular, the OWD de rease for AODV, as
np in reases, is onsistent with the in rease
observed in the normalized average throughput. The major on lusion is that, despite limiting the a tive PAN topology to a single spanning tree, ASPAN outperforms AODV and performs similarly to AODV-DR.
Path Establishment Delay (PED). The plot in Fig.
6.6 shows the AS-
PAN path establishment delay normalized to the path establishment delay introdu ed by AODV. In general, ASPAN requires less than 20% of the time spent by AODV to nd a route. This o
urs for two reasons. Firstly, AODV introdu es random delays at ea h intermediate node before re-broad asting
Route Request
messages, for the reasons explained in Chapter 4; in NS-2 a
random delay between 0 and 10 ms is onsidered, by default. Se ondly, at ea h hop, it uses ARP before sending the nation.
Route Reply
towards the desti-
Ea h AODV node, ex ept the sour e, invokes ARP to resolve the
IP address of the prede essor into the orrespondign MAC address, before being able to send the
Route Reply
to its prede essor in the route.
Con-
versely, ASPAN impli itly uses ARP to establish the path. Therefore, the
ARP REQUEST to rea h the destination plus the time required by the ARP REPLY to travel from the destination to the sour e.
path establishment delay is simply equal to the time required by the
ASPAN is more e ient than AODV in the establishment of paths. A
ording to our simulation results, the redu tion in the path establishment delay (1
−
ASPAN normalized PED) may be up to about 90%. ASPAN an
be this e ient be ause it maintains an a tive spanning tree, whi h already prede nes the path between any two pairs of nodes; ARP is just used to establish the path on top of the spanning tree.
CHAPTER 6.
10
192
12
ASPAN AODV
Normalized OWD
Normalized OWD
12
EVALUATION
8 6 4 2 0
10 8 6 4 2 0
1
1.5 2 2.5 3 3.5 Average No. of NICs per Node
1
(a) n = 10, np = 1 10
ASPAN AODV
8 6 4 2 0
10 8 6 4 2
1.5 2 2.5 3 3.5 Average No. of NICs per Node
1
( ) n = 10, np = 2
1.5 2 2.5 3 3.5 Average No. of NICs per Node
(d) n = 20, np = 2 12
ASPAN AODV
Normalized OWD
Normalized OWD
10
ASPAN AODV
0 1
12
1.5 2 2.5 3 3.5 Average No. of NICs per Node
(b) n = 20, np = 1 12 Normalized OWD
Normalized OWD
12
ASPAN AODV
8 6 4 2 0
10
ASPAN AODV
8 6 4 2 0
1
1.5
2
2.5
3
Average No. of NICs per Node
(e) n = 10, np = 4
3.5
1
1.5
2
2.5
3
3.5
Average No. of NICs per Node
(f) n = 20, np = 4
Figure 6.5: Normalized ASPAN and AODV average one-way delay (OWD) for 10-node and 20-node PANs, when the average number of NICs per node and the number of pairs ommuni ating simultaneously is varied.
Normalized Path Estab. Delay
1 n=10 n=20
0.8 0.6 0.4 0.2 0 1
1.5 2 2.5 3 Average No. of NICs per Node
3.5
Figure 6.6: ASPAN path establishment delay for 10-node and 20-node PANs normalized to AODV path establishment delay, when the average number of NICs per node is varied.
CHAPTER 6.
EVALUATION
Path Con guration Load.
193
Fig. 6.7 shows the results for the path on g-
uration load. The values for ASPAN are similar to AODV and AODV-DR; the ex eption is when
np = 1.
In ASPAN, the master broad asts one
message per se ond and the slaves reply with the
A k
TR
messages, regard-
less of the number of a tive ows; AODV and AODV-DR only broad ast
Hello
messages when involved in an a tive path. As su h, they tend to be
more e ient when the number of a tive paths is low; this is visible namely in Fig.
6.7b.
As
np
in reases, the signaling overhead for AODV/AODV-
DR in reases, sin e there are more paths to maintain.
At the same time,
the number of data pa kets transported by the network in reases; this ontributes to redu e the ASPAN path on guration load, due to its onstant signaling overhead. Hen e, the similar path on guration loads obtained for
np = 2
np = 4.
and
In on lusion, with a path on guration load similar to AODV and AODV-DR, ASPAN performs similarly to AODV-DR, outperforms AODV, and redu es signi antly the path establishment delay. Thereby, ASPAN is a better path on guration solution.
6.2.3 Path Re on guration Time Analysis In this subse tion we analyze the time needed to re on gure a path between a sour e and a destination devi e, when the urrent path is broken. AODV is used as a referen e; AODV-DR uses the same re on guration me hanism, so we do not onsider it in our analysis.
The goal is to evaluate
the time required to re on gure the path between the two ommuni ating devi es. The evaluation is made by theoreti ally analyzing the delays introdu ed by the re on guration me hanisms de ned in ASPAN and AODV. As we have seen in Chapter 4, in AODV ea h node involved in an a tive route broad asts a
Hello
message every
THello
the interval of time between two onse utive
THello = 1
s.
Hello
THello
de nes
messages; by default,
The prede essor of the leaving node dete ts that the route
is broken after approximately proximately
se onds, where
3 · THello
2 · THello
se onds, in the best ase, and ap-
se onds, in the worst ase. The best ase o
urs when
the node leaves the network right before the time the periodi
Hello
was
supposed to be broad ast; the worst ase, o
urs when the node leaves the network right after a periodi
Hello has been sent.
After dete ting the route
CHAPTER 6.
EVALUATION
0.3
ASPAN AODV AODV-DR
0.25 0.2
Path Conf. Load
Path Conf. Load
0.3
194
0.15 0.1 0.05 0
0.2
1.5
2
2.5
3
1
3
3.5
(b) n = 20, np = 1
ASPAN AODV AODV-DR
0.3
0
0.25 0.2
ASPAN AODV AODV-DR
0.15 0.1 0.05 0
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
( ) n = 10, np = 2
(d) n = 20, np = 2
ASPAN AODV AODV-DR
0.15 0.1 0.05 0
0.3 Path Conf. Load
Path Conf. Load
2.5
(a) n = 10, np = 1
0.05
0.2
2
Average No. of NICs per Node
0.1
0.3
1.5
Average No. of NICs per Node
0.15
0.25
0.1 0.05
3.5
Path Conf. Load
Path Conf. Load
0.3
0.2 0.15
0 1
0.25
ASPAN AODV AODV-DR
0.25
0.25 0.2
ASPAN AODV AODV-DR
0.15 0.1 0.05 0
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
1 1.5 2 2.5 3 3.5 Average No. of NICs per Node
(e) n = 10, np = 4
(f) n = 20, np = 4
Figure 6.7: Path on guration load for 10-node and 20-node PANs, when the average number of NICs per node and the number of pairs ommuni ating simultaneously is varied (n denotes the number of nodes forming the PAN and
np
denotes the number of pairs ommuni ating simultaneously).
CHAPTER 6.
EVALUATION
195
failure, the prede essor noti es the sour e using a
Route Error
message. The
prede essor ould do a lo al repair instead; however, as seen in Chapter 4, the lo al repair pro edure does not signi antly ontribute to speed up the re on guration time.
When the sour e is noti ed, it immediately starts a
new route dis overy pro edure to establish a new route between the two ommuni ating nodes. The total re on guration time is then the sum of (1) the time required to dete t the route failure, (2) the time required to transmit
Route Error
the
a new route.
towards the sour e, and (3) the time required to dis over
In pra ti e, the times (2) and (3) are one or two orders of
+
magnitude lower than time (1); for instan e, in [V 07b℄ it is shown that the pa ket delay for an 802.11 link running at 11 Mbit/s, even under saturation, is around a few tens of millise onds. Thus, the total route re on guration time is approximately equal to the time required to dete t the route failure. In ASPAN, the master monitors the network topology through the topology maintenan e me hanism. This onsists in running the topology dis overy me hanism every
TT R
between two onse utive
TT R = 1
s.
TR
TT R
de nes the interval of time
messages issued by the master; by default,
In the best ase, the master dete ts the topology hange af-
ter approximately
3 · TT R
se onds, where
se onds.
2 · TT R
se onds; in the worst ase, approximately after
Upon dete ting the hange, the master omputes a new
a tive spanning tree using
Campos's
algorithm and noti es the slaves about
the new on gurations required to set up the new a tive topology by means
Con g message. As soon as the leaf slaves in the ontrol tree re eive the Con g, they send upwards an A k message; this pro edure is repeated until the master re eives the A k. Afterwards, the master sends a Con g to of a
inform the slaves that they an safely pro eed to new address resolutions, impli itly enabling path re-establishment. After re eiving su h
Con g
mes-
sage, the sour e devi e starts the establishment of a new path towards the destination devi e using ARP or NDP. The total re on guration time is in this ase equal to the sum of (1) the time required to dete t the topology
hange, (2) twi e the time required to transmit the the ontrol tree, (3) the time required to re eive the
Con g message down A k from the hildren
in the ontrol tree, and (4) the time required to establish the new path using ARP or NDP. Again, the times (2), (3), and (4) are one or two orders of magnitude lower than time (1). As su h, the total path re on guration time is approximately equal to the time required to dete t the topology hange.
CHAPTER 6.
EVALUATION
196
1
n=5 n=10 n=20
Normalized no. of packets
0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 1.5
2
2.5 3 3.5 Average Degree per Node
4
4.5
Figure 6.8: Number of pa kets transmitted by ASPAN per broad ast pa ket normalized to the number of pa kets transmitted when pure ooding is used.
The on lusion is that ASPAN and AODV in ur approximately the same delay when it omes to path re on guration.
6.2.4 Broad ast Frame Forwarding Analysis Due to its simpli ity, most of the state of the art solutions use pure ooding to forward broad ast tra . ASPAN does it using a single spanning tree, the a tive spanning tree omputed using
Campos's
algorithm.
This
method onsists in ooding, but on top of a spanning tree, as it happens in urrent LANs.
The use of a single spanning tree is known to be the
most e ient method for broad ast. We aim to evaluate this e ien y when
ompared to pure ooding, if the network size and the average degree per node is onsidered. In ASPAN, the number of pa kets transmitted per broad ast pa ket is equal to
n − 1, n
being the number of nodes in the network. The number of
broad ast pa kets transmitted when pure ooding is employed (Np ) an be obtained by (the proof an be found in Appendix D):
Np (n, davg ) = (davg − 1) · n + 1,
n ≥ 2, davg ≥ 1
(6.1)
davg
de nes the average degree of the nodes parti ipating in the net-
In Fig.
6.8 we provide the normalized number of pa kets transmitted
where work.
by ASPAN per broad ast pa ket as a fun tion of
n = 10,
and
n = 20.
The e ien y gain (1
−
davg ,
onsidering
n = 5,
normalized no. of pa kets) is
CHAPTER 6.
EVALUATION
197
more signi ant as the average degree of the nodes
davg
in reases. Also, for
the same average degree, it de reases as the number of nodes parti ipating in the network in reases. As the size of the network in reases, and for low average degrees per node, the number of pa kets additionally transmitted using ooding tends to be negligible when ompared to the number of pa kets transmitted using the single spanning tree, as shown in Fig. 6.8. If we look at the plot of Fig.
6.8, this is espe ially visible for low average degrees
per node. In pra ti e, PANs are envisioned to be small networks with low average degree per node. By looking at the plot of Fig. 6.8 we verify that for small, sparse networks the e ien y gains are lower than for small, denser networks, but still signi ant. Thus, the ASPAN approa h does lead to signi ant e ien y gains with respe t to pure ooding; the ex eption is when the physi al network topology is a tree, where the gain is null.
6.2.5 IP Con guration Overhead Analysis The PBC me hanism is run between the slaves and the master, on top of the PAN reated by the ASPAN path on guration me hanisms. PBC me hanism involves broad ast tra .
The
The evaluation presented here
onsiders the broad ast forwarding approa h followed by ASPAN. As a basis for omparison we use the trial-and-error me hanism and the pure ooding approa h used by most of the state of the art solutions to handle broad ast tra (see Chapter 4). The message sizes onsidered in the evaluation, as well as the results when the broad ast forwarding method is the same for both me hanisms, are presented in Appendix C. In Fig. 6.9 we show a set of plots illustrating the overhead of the ASPAN IP on guration pro edure normalized to the overhead of the state of the art approa h, when the average degree per node parti ipating in a PAN is varied.
The urves were obtained onsidering the messages ex hanged by
the PBC and trial-and-error me hanisms (see Appendix C) together with the number of messages transmitted per broad ast message for ASPAN and for pure ooding.
For some ommuni ation media, it is more suitable to
onsider the overhead expressed as the number of frames, instead of the number of bytes, sin e the medium a
ess delay is the main ontributor to the time to transmit a frame; the size of the frame is a se ond-order fa tor. This is pre isely the ase of most of the wireless PAN te hnologies des ribed
CHAPTER 6.
EVALUATION
198
0.8 n=5 n=10 n=20
0.7 0.6 0.5
Normalized Overhead
Normalized Overhead
0.8
0.4 0.3 0.2 0.1 0
n=5 n=10 n=20
0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
1.5
2
2.5
3
3.5
4
4.5
1.5
Average Degree per Node
Normalized Overhead
Normalized Overhead
3.5
4
4.5
0.8 n=5
0.7
n=10 n=20
0.6 0.5 0.4 0.3 0.2 0.1 0
n=5
0.7
n=10 n=20
0.6 0.5 0.4 0.3 0.2 0.1 0
1.5
2
2.5
3
3.5
4
4.5
1.5
Average Degree per Node
2
2.5
3
3.5
4
4.5
Average Degree per Node
( ) IPv6 LL used, no. of bytes
(d) IPv6 LL used, no. of frames
0.8
0.8 n=5
0.7
Normalized Overhead
Normalized Overhead
3
(b) DynLL used, no. of frames
0.8
n=10 n=20
0.6 0.5 0.4 0.3 0.2 0.1 0
n=5
0.7
n=10 n=20
0.6 0.5 0.4 0.3 0.2 0.1 0
1.5
2 2.5 3 3.5 4 Average Degree per Node
4.5
(e) DHCPv4 used, no. of bytes
1.5
2 2.5 3 3.5 4 Average Degree per Node
4.5
(f) DHCPv4 used, no. of frames
0.8
0.8 n=5
0.7
Normalized Overhead
Normalized Overhead
2.5
Average Degree per Node
(a) DynLL used, no. of bytes
n=10 n=20
0.6 0.5 0.4 0.3 0.2 0.1 0
n=5
0.7
n=10 n=20
0.6 0.5 0.4 0.3 0.2 0.1 0
1.5
2 2.5 3 3.5 4 Average Degree per Node
4.5
(g) DHCPv6 used, no. of bytes
1.5
2 2.5 3 3.5 4 Average Degree per Node
4.5
(h) DHCPv6 used, no. of frames
0.8
0.8 n=5 n=10 n=20
0.7 0.6 0.5
Normalized Overhead
Normalized Overhead
2
0.4 0.3 0.2 0.1 0
n=5 n=10 n=20
0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
1.5
2 2.5 3 3.5 4 Average Degree per Node
4.5
(i) IPv6 SLAC used, no. of bytes
1.5
2 2.5 3 3.5 4 Average Degree per Node
4.5
(j) IPv6 SLAC used, no. of frames
Figure 6.9: ASPAN IP on guration overhead normalized to the overhead of the state of the art approa h (trial-and-error me hanism plus pure ooding), taking into a
ount the number of bytes and the number of frames ex hanged.
CHAPTER 6.
EVALUATION
199
in Chapter 2. Thereby, urves were obtained onsidering both the number of bytes (left hand side plots) and the number of frames (right hand side plots) ex hanged in ea h approa h. For ea h line in the matrix of plots of Fig. 6.9 the lega y IP auto- on guration used is dierent. The ASPAN IP on guration normalized overhead plotted in Fig.
6.9
results from the multipli ation of the normalized overhead of the PBC me hanism, provided in Appendix C, by the normalized number of pa kets transmitted by ASPAN per broad ast pa ket (see Fig.
6.8).
Thus, if the PBC
normalized overhead is low, as it happens for DynLL and IPv6 LL (see Appendix C), the resulting normalized overhead tends to be low too and the variations introdu ed by the ASPAN broad ast forwarding method are attenuated. On the other hand, as the PBC normalized overhead approa hes 1, the in uen e of the ASPAN broad ast forwarding method shows up. The normalized overhead is always higher when the number of frames ex hanged is onsidered; the ex eption is the ase when DHCPv4 is used. This is onsistent with the values provided in Appendix C for the PBC normalized overhead. Regardless the lega y IP auto- on guration used, the size of the PAN, and the average degree of the PAN nodes, the ASPAN IP auto- on guration pro edure is always signi antly more e ient than the state of the art pro edure.
The e ien y gain is always above 20% and, in pra ti e, it
may be at least around 40%, due to the sharp variation in the normalized overhead for sparse PANs. In addition, when DynLL and IPv6 LL are used for IP auto- on guration, it may be higher than 70%, even for sparse PANs (see Fig. 6.9b and Fig. 6.9d). This is parti ularly important for standalone PANs.
6.2.6 Experimental Evaluation In the previous se tions we presented the ASPAN evaluation using theoreti al and simulation analysis. In order to omplement su h analyses and demonstrate the feasibility of the proposed solution in pra ti e, we developed a proof-of- on ept prototype. In this se tion we present the ASPAN prototype implemented under Linux, the experimental setup and the performed tests, and the experimental results obtained using the ASPAN prototype.
CHAPTER 6.
EVALUATION
200
ASPAN Implementation in Linux The ASPAN proof-of- on ept prototype was implemented in Linux OS,
4
based on the built-in Learning Bridge .
Fig.
6.10 shows the modules in-
volved in the implementation and their intera tions. The ASPAN daemon or hestrates the PAN auto- on guration pro ess, namely the on guration of the a tive spanning tree omputed using
Campos's
algorithm, the sele -
tion of the lega y IP auto- on guration daemon, and the on guration of the Linux IP router running in the PAN gateway. The ASPAN daemon an run in master or slave mode. When it starts, the ASPAN daemon olle ts information about the available NICs that an be used for intra-PAN onne tivity; in our prototype, Bluetooth and IEEE 802.11b were onsidered as possible enabling wireless te hnologies. The daemon then asks the user to insert a name for the PAN to be reated, e.g., PAN name = BobsPAN. The user shall assign the same PAN name to all personal devi es it is willing to asso iate within the PAN; this is the only user intervention required. For a Bluetooth NIC, the PAN name is on gured as the Bluetooth devi e name, while for an IEEE 802.11 NIC the PAN name is used as the SSID. In the next step, the ASPAN daemon s ans for neighbor Bluetooth and/or IEEE 802.11 PAN devi es. Based on the Bluetooth devi e name or the 802.11 SSID, the ASPAN daemon learns the devi es it shall attempt to onne t to. In Bluetooth, the Bluetooth PAN pro le is used to establish a BNEP link; the ASPAN daemon simply invokes the orresponding ommands already available in Linux for that purpose. Regarding IEEE 802.11, it is only a matter of on guring the required parameters to make part of the IEEE 802.11 network of the dete ted neighbor; again, this is arried out using the Linux built-in ommands. These on gurations set the physi al PAN topology. The ASPAN daemon runs the topology dis overy, a tive topology on guration, PBC, and PGC me hanisms. If running in slave mode, the ASPAN daemon simply waits for the wise, it issues the
TR
message oming from the master; other-
TR message through all its lo al NICs used for intra-PAN
onne tivity. The ASPAN daemon sends and re eives all ASPAN signaling messages using a Linux pa ket so ket, whi h means that all ASPAN signaling messages are dire tly transported on top of Ethernet frames; this is a must, sin e IP onne tivity is not yet established at this stage. 4
http://linux-net.osdl.org/index.php/Bridge
Upon learning
CHAPTER 6.
EVALUATION
201
control
Linux IP router
control
ASPAN daemon control
Legacy IP autoconf daemon (dhclient, dhcpd, dhcp6c, dhcp6s, …)
Linux Bridge packet socket
PoA NIC (Ethernet, 802.11, …)
PAN NICs (Bluetooth, 802.11, ...)
control
Figure 6.10: Intera tion between ASPAN and its related Linux modules.
the PAN topology, the master ASPAN daemon runs
Campos's
algorithm to
ompute the a tive PAN topology. In addition, it sele ts the PAN gateway a
ording to the information piggyba ked by ea h slave in the sent to the master.
A k
messages
Afterwards, the master instru ts the slaves about the
required on gurations. Ea h slave is informed about the NICs it shall add to the Linux bridge running lo ally, a
ording to the spanning tree omputed by the master daemon. On the other hand, the slave sele ted as the PAN gateway is noti ed by means of the the
Con g
PGW Sele t
message piggyba ked in
message in luding the Linux bridge on gurations. The sele tion
of the PAN gateway and the orresponding PoA is performed based on the
PoA-metri
eld in luded in the
PGW Announ e.
In our prototype we only
onsidered IEEE 802.11 and Ethernet for Internet a
ess; so, Ethernet is always used if available, due to its high bandwidth and orresponding PoAmetri . The devi e sele ted as the PAN gateway on gures a Linux IP router to forward tra between the intra-PAN logi al link and the lo al NIC a ting as the PAN PoA (in Fig. 6.10 it is named as PoA NIC); this onsists in the a tivation of IP forwarding and, for IPv4, the on guration of NAT between the publi address orresponding to the sele ted PoA and the private IPv4 addresses used within the PAN. Subsequently, the PAN gateway sends out the
Agreement
message to inform the other PAN devi es about the lega y
dh lient, dh p6 ), after starting the lega y IP auto- on guration daemon lo ally, su h as dh pd and dh p6s. IP auto- on guration daemon they shall invoke (e.g.,
CHAPTER 6.
EVALUATION
202
Experimental Setup and Tests In order to demonstrate the feasibility of the ASPAN solution we arried out both fun tional and performan e tests using the ASPAN prototype. The s enarios onsidered to assess the ASPAN operation in a real environment are shown in Fig.
6.11.
Laptops running Linux OS were used as PAN
devi es. The PAN setup time, the average throughput, and the PAN PoA re on guration time were measured. The average throughput was measured using
Iperf 5
and
Darkstat 6
as measurement tools and taking into a
ount
TCP tra . Ten tests were onsidered for ea h measured parameter. S enario 1 was onsidered to evaluate setup time of the simplest PAN possible. Bluetooth and IEEE 802.11 were tested as the wireless te hnology
onne ting the master and the slave.
The master and the slave were pre-
on gured with the same Bluetooth name or 802.11 SSID. As a rst step, both devi es s an for neighbor PAN devi es. Upon dete ting ea h other, a BNEP or 802.11 link is established. Subsequently, the master triggers the topology dis overy pro edure. In this s enario, the a tive PAN topology is already on gured; so, there is no need to set up any Linux bridge. Regarding IP on guration, two ases were onsidered. In the rst ase, the lega y IPv4 auto- on guration pro edure des ribed in Chapter 4 was used to establish IP onne tivity. a
ount.
In the se ond ase, the PBC me hanism was taken into
DHCPv4 and DynLL were onsidered as alternatives to perform
IPv4 on gurations. In both ases, when DHCPv4 is employed, the master ran the DHCPv4 server (Linux
lient (Linux
dh lient
dh pd
daemon) and the slave the DHCPv4
daemon).
S enario 2 was used to test intra-PAN and PAN-to-Internet ows and, impli itly, the me hanisms used to on gure intra-PAN and PAN-to-Internet
onne tivity. The average throughput of intra-PAN ows was measured using
Iperf,
while the average throughput of the ows between PAN devi es
and a node in the Internet was measured using
Darkstat.
slave#1's Ethernet
NIC was used to onne t the PAN to the INESC Porto's Ethernet LAN providing Internet a
ess. Upon learning the PAN topology, the master daemon
on gures a Linux bridge between the BNEP link established with slave#1 and the IEEE 802.11 link established with slave#2. In addition, it sele ts the PAN gateway and the orresponding PoA; in this ase, slave#1 is se5 6
http://iperf.sour eforge.net http://dmr.ath. x/net/darkstat
CHAPTER 6.
EVALUATION
203
Bluetooth
Ethernet
master
Internet
slave#1 11 2. 80
master
slave#2
slave
(a) S enario 1
(b) S enario 2
80
2.1 1
Internet ASPAN Bluetooth et rn he Et
master
AP
ASPAN
Ethernet
Ethernet Bluetooth
Internet
slave#1
11 2. 80
11 2. 80
master slave#1
ASPAN
legacy slave#2
slave#2
( ) S enario 3
(d) S enario 4
Figure 6.11: S enarios used in the ASPAN experimental evaluation.
le ted as the PAN gateway and its Ethernet NIC is used as the PAN PoA. Afterwards, the master informs the slaves about the NICs they shall add to the lo al Linux bridges and informs slave#1 that it has been sele ted as the PAN gateway. As soon as slave#1 re eives the
PGW Sele t
message from
the master, it auto- on gures a Linux IPv4 router plus NAT between the Ethernet NIC onne ted to the INESC Porto's LAN and the Linux bridge virtual NIC, and runs the
dh pd
daemon regarding the on guration of IPv4
addresses and optional information within the PAN; the DHCPv4 server was
on gured to assign addresses with the 10.0.0.0/24 pre x and announ e the INESC Porto's DNS server address. When it ompletes the lo al on gurations, slave#1 instru ts the master and slave#2 to use
dh lient
daemon for
obtaining the required IP on guration parameters. After invoking
dh lient,
the master and slave#2 were able to a
ess the Internet through slave#1. The results for the average throughput of intra-PAN and PAN-to-Internet ows, whi h demonstrate the orre t ASPAN operation, are presented below. S enario 3 served as a basis for testing the ASPAN ability to seamlessly integrate lega y PAN devi es, even running a dierent OS. In Fig.
6.11 ,
the PAN devi es with the green tag are running the ASPAN daemon. For the sake of simpli ity, the lega y devi e, running Windows XP, was atta hed to the PAN using an Ethernet able; if Bluetooth or IEEE 802.11 were used
CHAPTER 6.
EVALUATION
204
instead, manual on gurations would be needed to on gure the Bluetooth or IEEE 802.11 link between the lega y devi e and the master. Upon the Ethernet able is onne ted to the Ethernet NIC, the master automati ally adds the Ethernet NIC to its lo al Linux bridge.
Thanks to the ASPAN
solution running in the master and slave#1, the lega y devi e su
essfully obtained the required IP on guration parameters using DHCP and it ould bene t from the Internet a
ess provided by slave#1. Apart from the dieren es as far as bandwidth is on erned, everything happened as if the lega y devi e was dire tly onne ted to the INESC Porto's LAN; web browsing and video streaming from YouTube were su
essfully tested. S enario 4 was taken into a
ount to evaluate the re on guration time when a PAN PoA hange o
urs and, impli itly, the ASPAN me hanisms enabling PAN PoA re on guration. The master has two 802.11 NICs, one was used for intra-PAN onne tivity and the other was used for a
essing the Internet through the INESC Porto's 802.11 WLAN. In this s enario, the Ethernet PoA that was being used breaks down. master with a
PGW Announ e
slave#1 noti es the
with the PoA- ag not set.
As a result, a
PAN PoA re on guration is needed. The master sele ts the best PoA from the PoA Table. In this ase only the IEEE 802.11 PoA remains; the master is sele ted as the new PAN gateway and its IEEE 802.11 NIC is used as the new PAN PoA. Two ases were onsidered: 1) the new PoA runs on IPv4; 2) the new PoA runs on IPv6.
In the rst ase, the master on gures a
Linux IP router plus NAT between the 802.11 NIC onne ted to the INESC Porto's WLAN and the Linux bridge virtual NIC, and a DHCPv4 server
dh pd
(
daemon) regarding the on guration of IPv4 addresses and optional
information within the PAN. Then, the master instru ts the slaves to use
dh lient.
In the se ond ase, the master on gures a Linux IPv6 router
between the 802.11 NIC onne ted to the INESC Porto's WLAN and the
dh p6s
Linux bridge virtual NIC, and a DHCPv6 server ( the master instru ts the slaves to use
dh p6 .
daemon).
Next,
The re on guration times
obtained for ea h ase are shown below.
Experimental Results In what follows, we present the experimental results obtained during the tests des ribed above.
CHAPTER 6.
EVALUATION
Setup Bluetooth IEEE 802.11
205
Lega y Approa h (s) DHCPv4 DynLL DHCPv4 DynLL
17.9 75.5 5.7 64.5
[17.3, 18.5℄ [75.1, 75.8℄ [5.3, 6.3℄ [64.3, 64.7℄
PBC (s) 17.9 17.0 5.7 5.7
[17.1, 18.7℄ [16.5, 17.6℄ [5.7, 5.8℄ [5.1, 6.3℄
Table 6.2: PAN setup time for dierent on gurations in S enario 1.
PAN Setup Time.
Table 6.2 provides the average values, and the or-
responding 95% on den e intervals, obtained for the PAN setup time in S enario 1.
The setup time was measured in the slave and took into a -
ount the time to run all the required pro edures until IP onne tivity was established. The PAN setup time is very mu h dependent on the wireless te hnology used. For Bluetooth, the high delay (on average, above 14 se onds) introdu ed by the Bluetooth s anning and link establishment pro edures represents, in general, the major ontribution to the overall PAN setup time. When IEEE 802.11 is used, due to the mu h faster s anning pro edure, the total PAN setup time be omes lower; in this ase, the major ontribution for the setup time omes from the IP auto- on guration pro edure.
Yet,
the major dieren e in the PAN setup time shows up when we ompare the times a hieved using the PBC me hanism and the lega y IP on guration approa h.
If DynLL is used for IP auto- on guration, the setup time re-
du tion provided by the PBC me hanism is around 80% when Bluetooth is used and about 90% when IEEE 802.11 is onsidered. However, it is important to realize that these values are implementation dependent; for instan e, the number of retransmissions of the
DHCP DISCOVER
message before
the devi e gives up (in our ase 2 retransmissions, see Appendix C) has a strong impa t on the results. The problem on erning the lega y IPv4 auto on guration approa h is that it assumes that DHCP is available most of the times. When using this approa h, the slave rst tries to auto- on gure an IPv4 address using DHCP by sending out multiple
DHCP DISCOVER mes-
sages until nally, after more than 60 se onds in our tests, it realizes there is not any DHCP server running and uses DynLL to on gure an IPv4 linklo al address. The PBC me hanism saves time by sele ting in advan e the proper auto- on guration me hanism to be used. Consequently, the delay introdu ed by the attempt to auto- on gure IP onne tivity through DHCP
CHAPTER 6.
EVALUATION
Intra-PAN Flow
206
Average TCP Throughput (kbit/s)
masterslave#1 slave#2slave#1 masterslave#2
365 [360, 370℄ 324 [320, 329℄ 3865 [3776, 3954℄
Table 6.3: Average TCP throughput for the three possible intra-PAN ows in S enario 2.
New PAN PoA
Re on guration Time (s)
IPv4 IPv6
3.8 [3.3, 4.4℄ 4.1 [3.9, 4.3℄
Table 6.4: PAN PoA re on guration time in S enario 4.
is eliminated. In on lusion, the PAN setup time is very mu h dependent on the wireless te hnologies used underneath and on the IP auto- on guration pro edures; the ASPAN pro edures themselves ontribute marginally to the total PAN setup time. On the other hand, the PBC me hanism used in ASPAN may signi antly redu e the PAN setup time when ompared to the lega y IP auto- on guration approa h; the redu tion may be up to 90%.
Average Throughput.
The average throughput for the three possible
intra-PAN ows in S enario 2 is presented in Table 6.3. Regarding PAN-toInternet ows, we tested two ows: slave#2Internet and masterInternet; both are limited by the Blueooth link, whi h is the bottlene k in this ase. The measured average TCP throughput was similar to the average throughput presented in Table 6.3 for the ows slave#2slave#1 and masterslave#1. The results on rm the proper operation of the Linux Bridge, the Linux IP router, and the ASPAN solution as a whole.
PAN PoA Re on guration Time.
Table 6.4 shows the average PAN PoA
re on guration time. The re on guration time was obtained as the sum of two time intervals, measured in the master and in slave#2. At the master, we measured the time between the arrival of the
PGW Announ e
from slave#1
and the end of the lo al on gurations. At slave#2, we measured the time between the arrival of the
PGW Sele t
and the end of IP on guration; the
time required to dete t the Ethernet link failure and transmit the
Announ e
and the
PGW Sele t
is negligible.
PGW
CHAPTER 6.
EVALUATION
207
The high re on guration times are due to DHCPv4 and DHCPv6. While the address auto- on guration itself is fast (hundreds of milise onds), the mandatory DAD pro edure asso iated to both proto ols in urs about 3 se onds of delay, on average.
The Optimisti DAD for IPv6 [Moo06℄ has
been proposed to over ome this problem for DHCPv6. If this solution was adopted, the PAN PoA re on guration time ould be below 1 se ond instead.
Nevertheless, the values are a
ording to what would be expe ted
and on rm the orre t operation of the ASPAN solution in pra ti e.
6.3 WiFIX Evaluation This se tion is devoted to the evaluation of WIFIX. The performan e of WiFIX was studied by means of theoreti al analysis and real experiments. We start by analyzing the WiFIX overhead and ompare it with the overhead introdu ed by the 802.11s tree-based me hanisms, PREQ and RANN. We then evaluate the SBC me hanism running between the terminals/stations (hereafter abbreviated to STAs) and the master MAP and ompare its signaling overhead with the signaling overhead in urred when the trial-and-error me hanism is used. In addition, we evaluate the re on guration time when a node failure o
urs in the Stub WMN and, nally, we present the experimental evaluation arried out using a 10-node Stub WMN running WiFIX and IEEE 802.11s, onsidering throughput, delay, and pa ket loss as the performan e metri s.
6.3.1 Path Con guration Overhead Analysis In this subse tion we hara terize the WiFIX overhead and ompare it with the overhead introdu ed by the tree-based routing solution onsidered in IEEE 802.11s. The analysis takes into a
ount the two tree-based routing me hanisms de ned in 802.11s: PREQ and RANN. For the PREQ me hanism only the registration mode is onsidered for the reasons mentioned in Chapter 4.
Analyti al Study We de ne in Table 6.5 a set of parameters. Based on these parameters we evaluate the overhead introdu ed by ea h solution when ommuni ation
CHAPTER 6.
EVALUATION
208
Notation
Des ription
HA LF T n nST A P
Average number of hops between root and MP Lifetime of forwarding table entry (se onds) Number of nodes forming the mesh network Average number of STAs behind a MAP Probability that STA is the endpoint initiating a
ommuni ation session Probability of broad asting a data frame every LF T interval due to absen e of forwarding table entry Average frame size (bytes) PREP message size (bytes) PREQ message size (bytes) RANN message size (bytes) TR message size (bytes) PREQ broad ast interval (se onds) RANN broad ast interval (se onds) TR broad ast interval (se onds)
PB SA SP REP SP REQ SRANN ST R TP REQ TRANN TT R
Table 6.5: Parameters used in the WiFIX overhead analysis.
between STAs and the root/master (and vi e-versa) takes pla e; ommuni ation between STAs is not onsidered. Below, the term link is used either to refer to the virtual link between mesh nodes or the radio link used by STAs to atta h to a Stub WMN. The overhead for the proa tive PREQ me hanism (OP REQ ) an be al ulated as:
1 ·n+ TP REQ 1 · (n − 1) · HA · TP REQ
OP REQ (byte/s) = SP REQ · SP REP The root sends one
PREQ
is re-broad ast, at least, on e resulting in
TP REQ
n
PREQ
every
7
TP REQ
se onds. The
PREQ
(6.2)
message
by ea h MP forming the mesh network,
messages transmitted within the mesh network every
se onds. Upon re eiving a
PREQ
message, ea h MP replies with a
PREP message in order to register itself and the 802.11 STAs behind any) at the root. The PREP message is retransmitted HA times on
uni ast it (if
average. 7
This is the best ase s enario. In pra ti e, ea h MP may rebroad ast the PREQ more than on e; this will happen when a mesh node re eives a PREQ message with a better metri .
CHAPTER 6.
EVALUATION
209
The overhead for the proa tive RANN me hanism (ORAN N ) an be al ulated using the following expression:
ORAN N (byte/s) =
SRAN N ·
1 TRAN N
·n+
(SP REP + SP REQ ) · The root MP sends one
RANN
every
(6.3)
1 · (n − 1) · HA TRAN N
TRAN N
sage is re-broad ast, at least, on e by ea h MP, resulting sages transmitted within the mesh network every
RANN
RANN in n RANN
se onds. The
TRAN N
mesmes-
se onds. For ea h
PREQ message towards the PREP message to the urrent
message, ea h MP replies with a uni ast
root MP. In response, the root MP sends a
TRAN N interval by the n − 1 MPs. messages ross HA MPs, on average. Therefore,
MP; this pro edure is performed every Both the
PREQ
and
they are transmitted
PREP HA
times.
The overhead for WiFIX (OW iF IX ) an be al ulated using the following expression (the proof an be found in Appendix B):
1 ·n+ (6.4) TT R 1 P · SA · · 2 · (n − 1) · (PB )nST A · (n − 1) · nST A + LF T 1 · 2 · (n − 1) · PB · (n − 1) · nST A (1 − P ) · SA · LF T 1 = ST R · ·n+ TT R 1 · (n − 1)2 · nST A · (P · (PB )nST A + 2 · SA · LF T (1 − P ) · PB )
OW iF IX (byte/s) = ST R ·
WiFIX also onsiders a root node (the master) that sends out one message every resulting in onds.
n
TT R
TR
se onds. The
TR
TR message is re-broad ast by ea h MAP,
messages transmitted within the network every
TT R
se -
WiFIX does not introdu e any further expli it signalling overhead.
However, there is additional overhead due to the use of Learning Bridges and the orresponding forwarding pro edure. When a Learning Bridge does not know the path to the destination of the urrent data frame, it will send the frame to all ports, ex ept the port the frame was re eived from. If no bridge in the mesh has a forwarding table entry for the destination of the data frame, the frame will be transmitted
n−1
times in the mesh network;
CHAPTER 6.
EVALUATION
210
n
HA
5 10 20 30
1.36 1.53 1.61 1.62
Table 6.6: Average number of hops between master MAP and MAPs.
we assume this ase in Eq. 6.4, i.e., the worst ase. Taking into a
ount that ea h MAP has two physi al interfa es, we have and other
n−1
n−1 links forming the WMN
links, one per MAP, to enable the atta hment of STAs to
the Stub WMN. Thereby, when the path to the destination of a data frame is unknown, the frame will be sent to MAPs and
nST A
2 · (n − 1) links;
n−1 nST A · (n − 1)
be ause there are
STAs per MAP, this pro edure is performed
times. Nonetheless, the broad ast of a data frame a ross the mesh network, every
LF T
interval, by an MAP, will only happen with a given probability,
whi h depends on the destination of the urrent frame. If the frame is addressed to the master MAP, the probability of broad asting the data frame is equal to the probability of having all STAs slient behind an MAP during the
LF T
interval; this is given by the probability of the interse tion of
events Terminal silent during
LF T
nST A
se onds. Sin e ea h terminal operates
independently from the others, the probability of the interse tion is equal to the produ t of the individual probabilities, i.e.,
(PB )nST A .
If a frame is des-
tined to a terminal, the probability of broad asting the data frame is simply equal to
PB .
On the other hand, if we assume bidire tional tra , whether
a ommuni ation session is initiated by a terminal or either by the master MAP or some node in the Internet has in uen e on the WiFIX overhead. We take this into a
ount in Eq. 6.4 by means of the
P
parameter.
Overhead Evaluation In order to simplify the overhead al ulations, we assume onstant values
TT R are set to 1 s, a
ording to the re ommend value stated in [Gro09a℄ for TP REQ and TRAN N . The values for HA are a fun tion of the number of nodes n, and were obtained
for some parameters in Table 6.5.
TP REQ , TRAN N
and
by means of simulations using the STS simulator, onsidering the average number of hops over 1000 random topologies (see Table 6.6).
P
is set to
0.95, a value that takes into a
ount that it is most probable for an STA
CHAPTER 6.
EVALUATION
211
to initiate a ommuni ation session than to be the endpoint of a session initiated by some node in the Internet; indeed, this is the ase in most appli ations (e.g. web browsing, streaming, le transfer), even onsidering unidire tional appli ations, su h as real-time audio/video, where there is always a bidire tional signaling phase before data ex hange. The value of
PB
was obtained experimentally by analyzing the behavior of
an 802.11 STA in two ases: (1) when the STA is onne ted to the Internet but there is no user data ex hanged; (2) when the STA is onne ted to the Internet and there is user data transferred between the STA and the Internet. The analysis for the se ond ase was performed by apturing the tra generated by ve users utilizing their 802.11 STAs to read e-mails, browse the web, and ommuni ate using instant messaging. The apture of
8
tra was performed during periods of 600 s using Ethereal . For the rst
ase we have used the same method and observed that, even though the station did not have any a tive data ow, there was still some a tivity due to the ex hange of ontrol proto ol messages. In pra ti e, this represents the worst ase for the 802.1D bridge forwarding pro edure; without user tra the forwarding table entries will expire more frequently and the overhead will be higher. The values of
PB
presented in Table 6.7 represent the average of
50 samples, 10 samples per user. The value of
PB
for a given sample was
al ulated using Eq. 6.5:
PB = where
Ni
Ni SP LF T
=
Ni · LF T SP
(6.5)
is the number of intervals in whi h an STA is silent more than
se onds and
SP
LF T
represents the sample period (in this ase 600 s).
Eq. 6.5 re e ts the fa t that a broad ast will only be sent in out of the total number of STA is silent less than
LF T
LF T
Ni
intervals
intervals omposing the sample period; if an
se onds, a forwarding table entry will still be
available and the data frame an be uni ast. The log les used to al ulate the values of
PB
presented in Table 6.7 an be found in [Cama℄. In both ases
the lo al tra ex hanged between the STA and the AP enabling Internet a
ess (e.g. for authenti ation) was not onsidered in the al ulations. In the following we provide the results obtained for the WiFIX overhead in omparison with the overhead of the two me hanisms de ned in 802.11s. The expressions presented above onsider overhead in byte/s. However, in 8
http://www.ethereal. om
CHAPTER 6.
LF T
EVALUATION
(s)
5 10 20 30
PB
212
(without user tra )
PB
(with user tra )
0.25 0.34 0.31 0.21
0.19 0.18 0.10 0.03
Table 6.7: Probability of lifetime expiration of the forwarding table entries.
802.11 systems, it is more suitable to onsider overhead expressed in frame/s, sin e the medium a
ess overhead (i.e. SIFS, DIFS, Ba ko ) ontributes the most to the time required to transmit a frame; the size of the frame is a se ond order fa tor. Thereby, the overhead results presented herein are in frame/s.
They were obtained by ignoring the sizes of the messages in the
mathemati al expressions. The parameters
n , LF T
and
nST A
were varied in
the al ulations.
Comparison of WiFIX and PREQ overhead.
The plots of Fig. 6.12a
and Fig. 6.12b show the WiFIX overhead normalized to the PREQ me hanism overhead, where the values of
PB
orrespond to the s enario without
user tra ex hange (see Table 6.7); it represents the overhead introdu ed by the solutions when the a tivity of an STA is minimal.
The plots show
the WiFIX overhead as a fun tion of the number of nodes forming the mesh network, and onsider four values for
LF T ;
the dieren e between the plots
in Fig. 6.12a and Fig. 6.12b has to do with the value of
nST A ,
the average
number of STAs behind an MAP. The major on lusion is that WiFIX introdu es signi antly less overhead than the 802.11s PREQ me hanism, regardless of the lifetime of the forward-
n = 10, nST A = 3, and LF T = 5s, 0.53. For LF T = 5s and LF T = 10s,
ing table entries; for instan e, when
the
normalized WiFIX overhead is
the
WiFIX overhead in reases linearly with the size of the mesh network, but it is still below the PREQ overhead. For higher
LF T
values the normalized
WiFIX overhead is kept almost onstant with the size of the mesh network. The WiFIX overhead is higher when small values of This was expe ted, sin e the lower the lifetime
LF T
LF T
are onsidered.
the higher the num-
ber of times the bridges will send tra using the broad ast me hanism. Furthermore, in general, the in rease in the
nST A
value represents an in-
rease in the WiFIX overhead; this is parti ularly observed for and
LF T = 10s.
LF T = 5s
If we onsider Eq. 6.4, this would be expe ted, sin e the
CHAPTER 6.
EVALUATION
213
1.2
1
5s 10s
0.8
20s 30s
Overhead (normalized)
Overhead (normalized)
1.2
0.6 0.4 0.2 0
1
5s 10s
0.8
20s 30s
0.6 0.4 0.2 0
0
5
10 15 20 25 30 Number of Mesh Access Points
35
0
(a) Without user tra , nST A = 3
10 15 20 25 30 Number of Mesh Access Points
35
(b) Without user tra , nST A = 10
1.2
1.2
1
10s 20s
0.8
30s
5s Overhead (normalized)
5s Overhead (normalized)
5
0.6 0.4 0.2 0
1
10s 20s
0.8
30s
0.6 0.4 0.2 0
0
5
10
15
20
25
30
35
0
Number of Mesh Access Points
5
10
15
20
25
30
35
Number of Mesh Access Points
( ) With user tra , nST A = 3
(d) With user tra , nST A = 10
Figure 6.12: Overhead of WiFIX normalized to the PREQ me hanism.
WiFIX overhead is proportional to
nST A .
The plots in Fig. 6.12 and Fig. 6.12d show the same information but
onsider the values for Table 6.7).
PB
orresponding to the ase with user tra (see
By omparing these plots with the plots in Fig.
6.12a and
Fig. 6.12b, we on lude that the WiFIX overhead de reases when the STAs be ome more a tive, as expe ted; greater STA a tivity means higher probability of having a valid forwarding table entry both for that STA and for the master MAP (assuming bidire tional tra ). The bottom line is that the WiFIX overhead is inversely proportional to the a tivity degree of STAs.
The more a tive the STAs are, the lower
the WiFIX overhead is, unlike the PREQ me hanism whi h has a onstant signaling rate independent of the user tra . In pra ti e, if a single radio
hannel is used to support all MAPs onne ted to the wired infrastru ture, a WMN is expe ted to be formed by only a few MAPs (let us say
n < 10), so
that minimal data throughput an be guaranteed to the STAs. In su h ase, WiFIX is signi antly more e ient than the 802.11s PREQ me hanism. The redu tion in overhead may rea h 60%.
CHAPTER 6.
EVALUATION
214
1.2
1.2
1 0.8
30s
5s Overhead (normalized)
Overhead (normalized)
5s 10s 20s
0.6 0.4 0.2
1
10s 20s
0.8
30s
0.6 0.4 0.2
0
0 0
5
10
15
20
25
30
35
0
5
Number of Mesh Access Points
(a) Without user tra , nST A = 3
15
20
25
30
35
(b) Without user tra , nST A = 10
1.2
1.2 5s
5s
10s
1
Overhead (normalized)
Overhead (normalized)
10
Number of Mesh Access Points
20s 30s
0.8 0.6 0.4 0.2
10s
1
20s 30s
0.8 0.6 0.4 0.2
0
0 0
5
10 15 20 25 30 Number of Mesh Access Points
35
( ) With user tra , nST A = 3
0
5
10 15 20 25 30 Number of Mesh Access Points
35
(d) With user tra , nST A = 10
Figure 6.13: Overhead of WiFIX normalized to the RANN me hanism.
Comparison of WiFIX and proa tive RANN overhead.
The plots
in Fig. 6.13a and Fig. 6.13b show the WiFIX overhead normalized to the RANN me hanism overhead, onsidering the values of
PB
for the ase where
the a tivity of an STA is minimal. The results show that the WiFIX overhead is also onsiderably lower than the overhead introdu ed by the RANN me hanism, regardless of the values hosen for head may rea h about 70%. Here, for low
LF T
LF T .
The redu tion in over-
values, the normalized WiFIX
overhead also in reases linearly with the size of the mesh network. Still, the in reasing rate is lower than in the plots of Fig. 6.12a and Fig. 6.12b; this has to do with the higher signaling overhead of the RANN me hanism when
ompared to the PREQ me hanism. For higher
LF T = 30s)
LF T
values (LF T
= 20s
and
the normalized WiFIX overhead is kept almost onstant as the
size of the mesh in reases. The plots in Fig. 6.13 and Fig. 6.13d show that with the in rease in the a tivity of the STAs, the normalized WiFIX overhead be omes lower; this holds for every
LF T
value.
It is interesting to note that, in general,
the normalized WiFIX overhead slightly de reases with the size of the mesh network, when the number of stations behind ea h MAP (nST A ) in reases.
CHAPTER 6.
EVALUATION
215
Normalized no. of packets
1 0.95 0.9 0.85 0.8 0.75 0.7 0
5
10 15 20 25 30 Number of Mesh Access Points
35
Figure 6.14: Number of pa kets transmitted by WiFIX per broad ast pa ket normalized to the number of pa kets transmitted when using pure ooding.
This is explained by Eq. 6.4. The values of
PB
in this ase are smaller than
in the ase without user tra ex hanged (see Table 6.7).
The lower
PB
values tend to redu e the ontribution of the se ond term in Eq. 6.4 to the total WiFIX overhead, espe ially as overhead is independent of
PB
nST A
in reases. In ontrast, the RANN
and grows faster with the size of the mesh
network. These two opposite ee ts ontribute to the observed redu tion in the normalized WiFIX overhead. We then on lude that WiFIX is more e ient than the RANN me hanism too, regardless of the
LF T
value sele ted. The overhead redu tion may
rea h more than 70%. Overall, WiFIX introdu es signi antly lower overhead than both PREQ and RANN, while providing immediate path availability; even in the ases where there is no path available the data frame is immediately sent to the destination using broad ast.
6.3.2 Broad ast Frame Forwarding Analysis The IEEE 802.11s solution uses pure ooding to ope with broad ast tra ; this is also the approa h used by most of the state of the art solutions addressing Stub WMNs, as we have seen in Chapter 4.
When using pure
ooding, ea h Stub WMN transmits on e the broad ast pa ket. This leads to
n
pa kets transmitted per broad ast pa ket.
Conversely, WiFIX uses
the a tive spanning tree reated using the ATCM me hanism for broad ast tra ooding a ross the Stub WMN, whi h leads to a total of transmitted per broad ast pa ket.
n − 1 pa kets
CHAPTER 6.
EVALUATION
216
Fig. 6.14 provides a plot with the normalized number of pa kets transmitted by WiFIX per broad ast pa ket as a fun tion of the number of MAPs
− normal(n < 10). This is
forming the Stub WMN. The WiFIX broad ast e ien y gain (1 ized no. of pa kets) is signi ant for small Stub WMNs
of great importan e, sin e real WMNs are expe ted to be formed by a few MAPs when a single wireless hannel is used, as referred to in Se tion 6.3.1. As the number of nodes forming the Stub WMN in reases, the e ien y gain provided by WiFIX be omes marginal. The bottom line is that the WiFIX approa h is always more e ient than pure ooding.
6.3.3 Path Re on guration Time Analysis We now ompare WiFIX and 802.11s with respe t to the path re on guration delay after a node failure. The urrent
open80211s
implementation,
used as a basis for our experimental evaluation (see Se tion 6.3.5), does not support the 802.11s proa tive me hanisms, so the two solutions ould not be
ompared experimentally. The analysis presented here fo us on the theoreti al lower and upper limits of the re on guration delay for ea h solution. We ignore the propagation delays, sin e they are at least two orders of magnitude lower than the refresh periods involved in the me hanisms being studied. The 802.11s PREQ and RANN me hanisms de ne that, respe tively, a PREQ and RANN message shall be sent every se ond by the root MP [Gro09a℄. Upon re eiving a new PREQ/RANN message, and after a propagation delay to wait for additional PREQ/RANN oming from other paths, ea h MP sele ts its best upstream neighbor as the parent node in the a tive spanning tree. This me hanism is also employed to establish new paths between ea h MP and the root MP after a node failure o
urs, as referred
when a proa tive path sele tion proto ol is used, MP failure and information on the new whereabouts of an MP are disseminated during triggered and periodi path update rounds . This to in the 802.11s draft standard [Gro09a℄:
means that the re on guration time is almost instantaneous, if the failure o
urs right before the refresh period timeout, and about one refresh period (1 se ond by default), if the failure o
urs immediately after the periodi PREQ/RANN message was re eived by the MPs in the WMN. The MPs affe ted by the node failure will not re eive any PREQ/RANN message in the next refresh period from their urrent upstream neighbor. Then, they will sele t a new upstream neighbor, based on further PREQ/RANN messages
CHAPTER 6.
EVALUATION
217
1
2
3
4
5
6
Figure 6.15: Example of a WiFIX node failure ae ting a node with a andidate parent node unae ted by the failure; Node 4, the node ae ted by the failure of Node 2, has a andidate parent unae ted by the node failure (Node 3).
re eived through other paths. Based on the new PREQ/RANN message and the registration made by ea h MP at the root MP, new paths are reated and the re on guration of the a tive tree topology is a
omplished. The WiFIX solution uses a more robust me hanism to sele t the paths between ea h MAP and the master MAP. In order to a
ount for possible signaling message failures, it waits tween two onse utive
TR
Dp
se onds, i.e., 3 times the interval be-
messages until it takes a de ision on the best
upstream neighbor. When the node failure only ae ts WiFIX nodes that have andidate parent nodes unae ted by the node failure, the re on guration time due to the ATCM me hanism varies between
Dp
and
2·Dp
se onds;
this s enario is exempli ed in Fig. 6.15, where the node ae ted by the node failure (Node 4) has a andidate parent unae ted by the node failure (Node 3).
In the best ase, the re on guration time is about
node failure o
urs before the rst
TR
message within
Dp se onds, a Dp period
if the
ould
be rebroad ast by the failure node. This is illustrated in Fig. 6.16a, where the node failure pre ludes the re eption of any
TR message from the urrent
parent node (Cp ) within the subsequent
period; after
Dp
ae ted WiFIX node sele ts a new parent as the new the dete tion of the node failure takes about was able to send a
TR
in Fig. 6.16b, where at
2·Dp
Cp .
Dp
se onds the
In the worst ase,
se onds, if the failure node
message before going down. This ase is illustrated
2 · Dp
the ae ted WiFIX node still assumes that the
failure node is running. The node failure is dete ted only after an additional
CHAPTER 6.
EVALUATION
218
TR from candidate parent
TR from Cp
X
X
X
Dp
(candidate parent selected as Cp)
time
2Dp
(a) Best ase TR from candidate parent
TR from Cp
X X
X
Dp
(Cp=Cp) X
X
(candidate parent selected as Cp)
X
2Dp
3Dp
time
(b) Worst ase Figure 6.16: Re on guration timeline for the WiFIX nodes that have andidate parent nodes unae ted by the node failure, where a ross means that the orresponding message is not re eived.
Dp
period; by then a new parent is sele ted. When the node failure ae ts
WiFIX nodes that do not have any andidate parent unae ted by the node failure, the maximum re on guration time (RTmax ) is dire tly proportional to the maximum number of hops (Hmax ) between the master MAP and the MAPs in the new a tive spanning tree, as de ned in Eq. 6.6.
RTmax
o
urs
when a MAP one-hop away from the master MAP fails. Eq. 6.6 assumes that the master MAP never fails. If the master MAP fails a re on guration is not possible, sin e the Stub WMN simply goes down.
RTmax = 2 · Dp + (Hmax − 2) · Dp
(6.6)
= 6 · TT R + (Hmax − 2) · 3 · TT R The maximum number of hops in a Stub WMN a tive topology should be low, as apa ity de reases with the number of hops to the master MAP [AW05℄. Consider, for instan e, a Stub WMN with
RTmax
is equal to
3 · Dp = 9 · TT R ,
Hmax = 3.
In that ase,
TT R value = 3, where
i.e., 9 se onds, if the default
is used. Fig. 6.17 shows a re on guration example, with
Hmax
there is an ae ted WiFIX node (Node 5) without any andidate parent node unae ted by the node failure. When Node 2 fails, Node 4 is able to sele t a new parent node after
2 · Dp
se onds, in the worst ase, sin e it has an
CHAPTER 6.
EVALUATION
1
2
219
3
3
3
4 5
1
1
4
4
5
5
(a) Node 2 fails Figure 6.17:
(b) Node 4 sele ts new Cp
( ) Node 5 sele ts new Cp
Example of a WiFIX re on guration when there is a node
ae ted by the node failure without any unae ted andidate parent node.
unae ted andidate parent node (Node 3). Upon sele ting the new parent node (Node 3), Node 4 starts rebroad asting the it. After
Dp
T R messages re eived from
se onds, Node 5 an sele t its new parent node (Node 4) and
the re on guration of the a tive spanning tree is omplete (Fig. 6.17 ). In WiFIX, the STAs running behind ea h MAP are not expli itly registered in the master MAP, as it happens in the proa tive 802.11s me hanisms. In order to ompletely evaluate the WiFIX re on guration speed we also need to onsider the time required until the new paths towards the STAs are found. This is related to the ina tivity intervals of an STA. Using the same experimental results onsidered for the overhead analysis presented in Se tion 6.3.1, we ould nd the Cumulative Distribution Fun tion (CDF) for the ina tivity intervals asso iated to an STA when there is user tra ex hanged. The CDF of Fig. 6.18 results from the average of 50 samples, 10 samples per user. The plot of Fig. 6.18 shows the median (4 ms) and the
95th
per entile
(0.77 s). These values show that the ina tivity interval asso iated to an STA
ontributes marginally to the re on guration time of the WiFIX solution. After the new a tive topology is established by the ATCM me hanism, the new paths either towards the STAs or the master MAP will be found fast. We then on lude that the WiFIX re on guration time is higher than the re on guration time a hieved using the proa tive 802.11s me hanisms. The reason for the fast re on guration times of the proa tive 802.11s me hanisms is the immediate hange in the paths between ea h MP and the root MP, every time the ae ted MPs fail to re eive the next PREQ/RANN from their
urrent upstream neighbor within a refresh period. While this represents a
CHAPTER 6.
EVALUATION
220
1
0.9
(0.77,0.95)
Cumulative Distribution Function
0.8
0.7
0.6
0.5 (0.004,0.5) 0.4
0.3
0.2 1e-04
Figure 6.18:
0.001
0.01
0.1 Inactivity Interval (s)
1
10
100
Cumulative distribution fun tion for the ina tivity intervals
asso iated to an STA (WiFIX).
good me hanism for dete ting node failures, in regular operation this may
ause instability in the paths between ea h MP and the root MP; a simple message loss may erroneously lead to the immediate hange of the urrent path.
On the other hand, a node failure is not envisioned to o
ur that
frequently. Usually, the a tive topology will be stable. Node failures will only o
ur due to sporadi problems or due to human intervention for maintenan e purposes. Thereby, the higher WiFIX re on guration time is not seen as a relevant disadvantage.
6.3.4 IP Con guration Overhead Analysis In this subse tion we analyze the overhead involved in the WiFIX IP
on guration pro edure. The SBC me hanism runs between the terminals and the master MAP, on top of the Stub WMN reated by the ATCM me hanism. The WiFIX IP on guration pro edure is evaluated onsidering the SBC me hanism running together with the WiFIX broad ast forwarding method. As a ben hmark we use the lega y trial-and-error me hanism and the pure ooding approa h followed by most of the state of the art solutions,
CHAPTER 6.
EVALUATION
221
0.9
0.9 bytes
bytes 0.8 Normalized Overhead
Normalized Overhead
0.8
frames
0.7 0.6 0.5 0.4
frames
0.7 0.6 0.5 0.4
0.3
0.3 5
10
15
20
25
30
35
5
10
Number of Mesh Access Points
15
20
25
30
35
Number of Mesh Access Points
(a) DHCPv4 used
(b) DHCPv6 used
0.9 bytes Normalized Overhead
0.8
frames
0.7 0.6 0.5 0.4 0.3 5
10 15 20 25 30 Number of Mesh Access Points
35
( ) IPv6 SLAC used Figure 6.19: WiFIX IP on guration overhead normalized to the overhead of the state of the art approa h (trial-and-error me hanism plus pure ooding).
su h as IEEE 802.11s. The results obtained when the broad ast forwarding method is the same for both SBC and trial-and-error me hanisms an be found in Appendix C. The plots in Fig. 6.19 show the overhead of the WiFIX IP on guration pro edure normalized to the overhead of the state of the art approa h, when the number of MAPs forming the Stub WMN is varied.
The urves were
obtained onsidering the messages ex hanged by the SBC and trial-and-error me hanisms (see Appendix C) and the number of messages transmitted per broad ast message for WiFIX and for pure ooding. the
Agreement
message was onsidered to travel a ross
In the al ulations,
n−1
hops, in order
to onsider the worst ase s enario for the SBC me hanism. The dieren e between the plots of Fig. 6.19a, Fig. 6.19b, and Fig. 6.19 has to do with the lega y me hanism used for IP auto- on guration. The normalized overhead is lower when the broad ast e ien y gain is higher. As the size of the Stub WMN in reases, it tends to the SBC me hanism normalized overhead (see Appendix C). When DHCPv4 is used for IP auto- on guration, the WiFIX IP on guration normalized overhead is
CHAPTER 6.
EVALUATION
222
almost independent of the size of the Stub WMN; in this ase, the SBC me hanism overhead plays the major role in the overall overhead. The dieren es between the two urves shown in ea h plot of Fig. 6.19 are onsistent with the normalized overhead of the SBC me hanism presented in Appendix C for ea h ase. For 802.11-based Stub WMNs, the normalized overhead onsidering the number of frames transmitted is more relevant. In that ase, from Fig. 6.19 we on lude that the WiFIX IP on guration normalized overhead varies between 0.5, when DHCPv4 is used, and 0.8, when DHCPv6 is used. For small Stub WMNs (n
< 10),
and onsidering the ases when DHCPv6
and IPv6 SLAC are used, the normalized overhead is lower and diminishes signi antly as the number of nodes forming the Stub WMN de reases. In on lusion, regardless the lega y IP auto- on guration used and the size of the Stub WMN, the WiFIX IP auto- on guration pro edure is always more e ient than the state of the art approa h.
For small Stub WMNs,
the maximum normalized overhead is around 0.7, whi h orresponds to an e ien y gain of about 30%. When DHCPv4 is used, as it urrently happens in the great majority of the ases, the e ien y gain is higher than 50%.
6.3.5 Experimental Evaluation In order to show its feasibility and good performan e, WiFIX was implemented in Linux and experimentally evaluated using 802.11s as a ben hmark. The experimental setup and the results obtained for WiFIX and 802.11s
9
are des ribed below. The existing open-sour e implementation of 802.11s
was used as a basis for our experimental evaluation. In its urrent version,
open80211s
only supports the on-demand part of HWMP. However, the dif-
feren e between the 802.11s on-demand and proa tive me hanisms exists at the ontrol plane only. The a tual paths established between ea h MP and the root MP using any of these me hanisms are the same, sin e the same path sele tion metri (Airtime Link Metri ) is taken into a
ount. Thus, the performan e results presented below are those that would be obtained if the 802.11s proa tive me hanisms were used to establish the paths between ea h MP and the root MP. 9
http://www.open80211s.org
CHAPTER 6.
EVALUATION
223
Linux Bridge
tap1
tap#
vtun module control
tap0
control
Other Interfaces
tap file descriptors
WiFIX daemon packet socket
802.11 NIC
Figure 6.20: Intera tion between WiFIX and its peer Linux modules.
WiFIX Implementation in Linux The Linux OS provides the means required to implement WiFIX: a Learning Bridge and tools to reate virtual interfa es. Using these tools, WiFIX is required to reate and delete virtual interfa es and to perform Eo11 en apsulation. The Linux bridge is exible enough to support the virtual interfa es. It expe ts them to behave like Ethernet devi es and have a 6-byte MAC address. Fig. 6.20 illustrates the modules involved in the implementation, and their intera tions. The WiFIX daemon seats between the virtual interfa es, represented by
taps, and the wireless NIC.
The tunnels to ea h neighbor are implemented using a provided by the
vtun
tap
interfa e,
module, whi h are virtual interfa es that behave like
Layer-2 Ethernet devi es to the upper layers; in the implementation, a behaves as a tunnel endpoint.
A frame sent to a
tap
tap
interfa e is in fa t
delivered to a le des riptor on the user spa e appli ation that reated the interfa e, in this ase the WiFIX daemon. The frame will already ontain an Ethernet header, with both the sour e and nal destination MAC addresses. It is up to the WiFIX daemon to further pro ess the frame and forward it to the wireless NIC. The kernel will then pro ess this frame in the same way it would pro ess a frame from a physi al Ethernet NIC. The WiFIX daemon a
esses the wireless NIC using a Linux pa ket so ket. The pa ket so ket allows the re eption of frames with a prede ned Ethertype, and it also enables the appli ation using it to spe ify the sour e MAC address, the destination MAC address and Ethertype of a frame to be
CHAPTER 6.
EVALUATION
224
re eived. These features are valuable for our goals, given that the proposed solution requires that WiFIX pro esses the Eo11 Ethertype and repla es the MAC address of the frame. The WiFIX daemon runs the ATCM me hanism in order to dete t the parent and hild nodes, and reate the a tive tree topology. node reates a
tap
interfa e per hild and a
tap
Ea h mesh
interfa e on erning the
tunnel established with its parent node. All these interfa es are then added to the bridge.
The asso iation between the neighbor address and the
tap
le des riptor is maintained in the Parent-Child Table, within the daemon. When a frame arrives to the WiFIX daemon from a
tap
le des riptor, the
appli ation fet hes the neighbor address asso iated with the
tap.
A new
header is then inserted before the original Ethernet frame, with the sour e address equal to the urrent node MAC address, the destination equal to the neighbor MAC address, and the Ethertype set to Eo11. The frame is then sent to the wireless NIC, via the pa ket so ket. The WiFIX daemon re eives all the frames en apsulated in Eo11. Only the frames originated at known neighbors are pro essed; all the others are dropped. When re eiving a frame, the daemon looks up in the Parent-Child Table for the
tap le des riptor that orresponds to the sour e address of the
neighbor in the 802.11 frame header. The frame is then de apsulated and sent to the
tap
interfa e le des riptor. The
tap
will then forward the frame
to the bridge. If the urrent node is the destination of the frame, the bridge will pass it upwards; otherwise, it will forward the frame a
ording to the standard forwarding algorithm. As a result, some frames an be forwarded to other physi al interfa es or frames passed to the
tap
tap
devi es that belong to the bridge.
The
devi es are then pro essed by the WiFIX daemon
using the method des ribed above. To ope with the extended frame length due to the Eo11 header, the Maximum Transfer Unit (MTU) of the physi al interfa e was in reased by 14 bytes, whi h an be easily handled by 802.11. The MTU of the
tap
and
bridge devi es are un hanged to guarantee that the forwarded frames do not ex eed the Ethernet MTU. The WiFIX sour e ode was ompiled for x86 and ross- ompiled to MIPS pro essors. The latter allowed deploying the solution on o-the-shelf 802.11g wireless APs running Linux OS. The Linksys WRT54GL with OpenWRT 10
http://www.openwrt.org
10
CHAPTER 6.
EVALUATION
225
WhiteRussian distribution was used.
SBC Me hanism Implementation The WiFIX implementation mentioned above purposely does not onsider the SBC me hanism. While de ned as part of WiFIX, the SBC me hanism an run in standalone mode on top of any Layer-2 network, as seen in Chapter 5. This hara teristi makes it useful to be used in s enarios other than the Stub WMN. Indeed, the SBC me hanism was spe i ed as part of
+
the Ambient Network Atta hment pro edure [Ra 07℄ designed within the se ond phase of the Ambient Networks (AN) proje t
11 in whi h the author
parti ipated. The SBC me hanism made part of the overall AN prototype [Rem07℄, and it was demonstrated at the nal audit of the proje t.
The
main goal of the SBC me hanism implementation was to be used as a proofof- on ept. The three major lega y IP auto- on guration me hanisms, i.e., DHCPv4, DHCPv6, and IPv6 SLAC, were onsidered in the prototype for a tual IP auto- on guration.
The deployment of the SBC me hanism al-
lowed proving that it does work in pra ti e and that its implementation and integration with lega y IP auto- on guration solutions is a straightforward pro ess. Given the similarities between SBC and the PBC me hanism, evaluated within the ontext of the ASPAN solution, this just further validates the fundamental pro edures used in both me hanisms.
Experimental Setup and Tests The testbed deployed to assess the operation of WiFIX in a real environment is shown in Fig. 6.21. Both performan e and fun tional tests were
arried out using the WiFIX implementation presented above. The INESC Porto's wired infrastru ture was extended with 10 WMN nodes, positioned along the third oor of the INESC Porto's building, and forming the topology presented in Fig. 6.21. In ea h WMN node, wireless NICs with atheros
hipset were used, in order to be able to run
open80211s.
For WiFIX, the
wireless NICs of ea h MAP were set up in 802.11 ad ho mode to enable the reation of an 802.11 ad ho network between the 10 WMN nodes. For
open80211s, using the tools provided by the open80211s proje t, we have reated a mesh network between the 10 WMN nodes. For running open80211s, 11
http://www.ambient-networks.org.
CHAPTER 6.
EVALUATION
226
Windows XP Laptop
802.11 BSS INESC Porto Intranet
DHCP Server
Internet
MAP3
MAP6
MAP9
root/ master
MAP2
MAP5
MAP8
Stub WMN
MAP1
MAP4
MAP7
Intranet Switch
Gateway
Figure 6.21: Setup of the testbed used in the WiFIX evaluation.
it was ne essary to ompile the latest Linux 802.11 wireless driver (ath5k); the same Linux wireless driver was used for WiFIX, for the sake of proper
omparison between WiFIX and 802.11s.
The default wireless driver set-
tings were onsidered in the tests, on erning transmission power, number of MAC retransmissions, and RTS/CTS. The rate of the wireless NICs was set to the maximum bit rate possible ( urrently 11 Mbit/s, due to the problems related to the Linux wireless driver reported in the o ial web site
12).
Channel 3 was used in the tests, in order to minimize the interferen e from INESC Porto's Wi-Fi infrastru ture. In addition, the tests were performed over the weekends, so that the in uen e of people walking around, as well as interferen e from the INESC Porto's Wi-Fi infrastru ture had minimal impa t on the results. The performan e tests were made using
mgen 13
and
Iperf 14
as measure-
ment tools, with all MAPs (1 to 9) sending tra to the root/master MAP. Both UDP and TCP tra tests were arried out, onsidering sessions of 120 s. Ten tests were onsidered for TCP and for ea h oered rate in UDP.
mgen 12
was used for generating UDP tra , while
http://wireless.kernel.org/en/users/Drivers/ath5k http://pf.itd.nrl.navy.mil/mgen/mgen.html 14 http://iperf.sour eforge.net 13
Iperf
was used for generat-
CHAPTER 6.
EVALUATION
227
ing TCP tra . The average throughput, one-way delay (OWD), and pa ket loss ratio were measured for WiFIX and 802.11s. The goal was to evaluate the WMN performan e when WiFIX and 802.11s are used as alternatives. UDP tests were made onsidering six dierent onstant bit rates (from 120 kbit/s to 720 kbit/s) for the ows between ea h MAP and the master MAP. In all tests, the size of the data pa kets was set to 1500 bytes and, for UDP, the oered rate was set equal for every node. Fun tional tests were performed using WiFIX to extend the INESC Porto's Intranet, as shown in Fig. network servi es already deployed.
6.21.
No hanges were made to the
The INESC Porto's a
ess router and
DHCP server were used as well. We onne ted a Cis o Aironet 1200 AP to the Ethernet port of one MAP. This was an unmodi ed orporation grade AP. It was used to enable the Windows XP laptop to a
ess the WiFIX network and, onsequently, the Intranet.
After onne ting to the 802.11
BSS shown in Fig. 6.21, the laptop obtained an IP address from the DHCP server, and a
essed both Intranet and Internet servi es; servi es su h as web browsing, Internet radio streaming, and VoIP worked without a glit h, in a similar way as if the node was dire tly onne ted to the infrastru ture using a standard 802.11 AP. It was even possible to use servi es like network boot from the lo al Preboot Exe ution Environment (PXE) servi e.
Experimental Results In what follows we refer to the experimental results obtained for WiFIX and 802.11s, taking into a
ount four metri s: average throughput between an MAP and the master MAP, average throughput per MAP, pa ket loss ratio, and OWD. The plot in Fig. 6.22 presents the average throughput for both solutions. WiFIX provides higher UDP throughput when ompared to 802.11s, regardless of the oered load. This is explained by the higher pa ket loss ratio of 802.11s, even for smaller rates, shown in the plot of Fig. 6.23. The higher pa ket loss is aused by the unstable paths established by 802.11s, using the ALM metri , whi h is de ned as the default path sele tion metri for 802.11s WMNs (see Chapter 4). The ALM metri onsiders two onstant and two variable parameters. The variable parameters are the rate at whi h the wireless NIC is running and the frame error probability for a test frame whose size is onsidered in the metri too.
For all performed tests, the rate was
CHAPTER 6.
EVALUATION
228
350 WiFIX 802.11s (hop count) 802.11s (ALM) 300
Average Throughput (kbit/s)
250
200
150
100
50
0 0
Figure 6.22:
100
200
300 400 500 Offered Load (kbit/s)
600
700
800
WiFIX and 802.11s average throughput versus oered load
onsidering UDP tra .
set to onstant (11 Mbit/s). As su h, only the frame error probability was variable and ontributed to the dieren e between path osts. The 802.11s path refresh me hanism allows the establishment of a new high quality path (in terms of ALM) if the urrent path be omes worse. A given MP dete ting a path with better ALM metri (usually in luding unloaded links, whi h exhibit lower frame error probability) sele ts it as its new path and starts sending its tra through that path.
However, shortly the new path will
suer a metri degradation, sin e the urrent node (and maybe other nodes) sele ted it as the new path. The previous path may now be ome a good path again and a new hange may o
ur. This leads to frequent os illations in the paths between ea h MP and the root MP (as veri ed during our tests), as well as the on entration of tra in some paths, whi h overall ontributes to in rease the pa ket loss in the WMN and redu e the average throughput. Indeed, this path os illation phenomenon was also veri ed by Garroppo
al.
et
in their experimental work presented in [GGIT08℄. In order to on rm
that the worse 802.11s performan e does ome from the use of the ALM metri , we have made experiments onsidering hop ount as the path sele tion metri . The results shown in Fig. 6.22 validate this hypothesis. When using the hop ount metri for 802.11s the average throughputs of WiFIX
CHAPTER 6.
EVALUATION
229
1 WiFIX 802.11s
Average Packet Loss Ratio
0.8
0.6
0.4
0.2
0 0
100
200
300
400 500 Offered Load (kbit/s)
600
700
800
Figure 6.23: Average pa ket loss ratio for WiFIX and 802.11s.
and 802.11s are similar, as expe ted, sin e the same a tive tree topology is employed in both solutions. WiFIX uses the number of hops between ea h MAP and the master MAP as the default metri to ompute the paths. Based on our experimental results and the results a hieved in [GGIT08℄, we on lude that the hop ount metri is a better metri than ALM in its urrent form. The plot in Fig. 6.24 shows the average throughput per MAP when the oered load is 480 kbit/s per MAP. Similar plots would be obtained for higher oered load values. This plot shows that the higher average throughput obtained for WiFIX does not ome from lower fairness; the average throughput per MAP is also higher for WiFIX independently of the node onsidered. These results also illustrate the unfair distribution of the throughput among the WMN nodes, a well-known problem in 802.11 mesh networks [AW05℄. The MAPs loser to the master have the highest throughput, sin e their own tra is enough to almost ompletely ll up their queues, ausing the pa kets from the farther nodes to be dropped very frequently. The plot in Fig.
6.25 presents the OWD for WiFIX and 802.11s.
In
general, a higher delay is obtained for WiFIX. This is due to the higher number of pa kets transported by the WMN when WiFIX is used.
For
802.11s, there is a higher pa ket loss, whi h leads to less tra in the WMN.
CHAPTER 6.
EVALUATION
230
500 WiFIX 802.11s
Average Throughput (kbit/s)
400
300
200
100
0 1
2
3
4 5 6 Mesh Access Point
7
8
9
Figure 6.24: Average UDP throughput per MAP when the oered load is 480 kbit/s.
Therefore, the network delay be omes lower than for WiFIX, as expe ted. Con erning lower oered rates (≤ 240 kbit/s), whi h de nes the ases where the network is operating below the saturation point, both solutions provide similar network delays. Table 6.8 presents the average throughput per node and the average throughput between an MAP and the master MAP for TCP tra . As for UDP, WiFIX provides higher average TCP throughput than 802.11s. Also, the MAPs losest to the master MAP are able to transmit more TCP traf , as for UDP. The reasons for the higher throughput obtained when using WiFIX are those mentioned above for the UDP results.
As for UDP, the
ows related to the MAPs 1-hop away from the master/root have higher throughput. However, in this ase, due to the TCP ongestion ontrol me hanism, this is more prominent. The TCP ows related to the MAPs 1-hop away from the master dominate the a
ess to the medium, as it happens for UDP. This for es the MAPs two and three hops away to ba k o.
As
a onsequen e, higher unfairness than for UDP is present and most of the MAPs two and three hops away from the master have very low throughput.
CHAPTER 6.
EVALUATION
231
10 WiFIX 802.11s
One-way Delay (s)
8
6
4
2
0 0
100
200
300
400 500 Offered Load (kbit/s)
600
700
800
Figure 6.25: One-way delay for WiFIX and 802.11s.
Solution WiFIX 802.11s
per MAP (kbit/s) 1 238 495
2 2449 1510
3 1909 1731
4 39 17
5 13 52
6 123 104
7 54 160
8 14 32
9 103 32
Average (kbit/s) 549 459
Table 6.8: Average TCP throughput for WiFIX and 802.11s.
6.4 Dis ussion After evaluating ASPAN and WiFIX from dierent perspe tives, it is now important to summarize and dis uss the results and their impli ations. In the following, we do it for ea h solution. At the end, we draw the overall
on lusions.
6.4.1 ASPAN ASPAN onsiders lega y Learning Bridges and IP auto- on guration me hanisms as base building blo ks. These blo ks are then omplemented by three new building blo ks regarding (1) the on guration of the a tive spanning tree, (2) the sele tion of the proper lega y IP auto- on guration me hanism, and (3) the on guration of the PAN gateway. The on guration of the a tive spanning tree is performed based on a new MRCST approximation spanning tree algorithm,
Campos's
algorithm.
CHAPTER 6.
EVALUATION
232
This algorithm ombines riteria used by the MST algorithms, the gorithm, and
Dijkstra's
Add
al-
algorithm, whi h revealed to be a good approa h
to design a new approximation MRCST algorithm.
Campos's
algorithm is
shown to be better than the urrent IEEE algorithm, in terms of routing
ost, without introdu ing further time omplexity; the redu tion in routing ost is espe ially veri ed for heterogeneous, sparse networks, pre isely the ase of multi-te hnology PANs. In addition, our algorithm outperforms MST algorithms and, in pra ti e, provides the same performan e as
Wong's
algorithm, the fastest state of the art approximation MRCST algorithm. As su h, it is indeed a better solution to de ne the a tive spanning tree within multi-te hnology PANs. After omparing ASPAN with the state of the art path on guration solutions, AODV and AODV-DR, in terms of throughput and delay, we showed that, in spite of using a single spanning tree, omputed by
Campos's
algo-
rithm, ASPAN outperforms AODV and performs similarly to AODV-DR, while introdu ing similar path on guration load and path re on guration times, and avoiding the omplexity and ine ien y of the route dis overy pro edure de ned by AODV-DR. Also, we demonstrated that ASPAN is more e ient when it omes to the path establishment delay.
The AS-
PAN path establishment delay is around one order of magnitude lower than that introdu ed by AODV/AODV-DR; this makes the ASPAN path establishment pro edure almost instantaneous.
It is important to realize that,
while the omparison was performed on erning AODV and AODV-DR, the
on lusions an be applied with respe t to other rea tive routing proto ols, su h as AODVjr, DYMO, IEEE 802.11s, and LUNAR, whi h are based on the same fundamental me hanisms. Also, note that the obtained results are
onservative, sin e in our simulations we onsidered heterogeneous PANs in luding wireless links with nominal data rates whose maximum dieren e is up to two orders of magnitude. In pra ti e, the dieren es between the wireless te hnologies oexisting in a single PAN may rea h four to ve order of magnitude. Thus, even better results may be a hieved by ASPAN. ASPAN uses the spanning tree omputed by handling both uni ast and broad ast tra .
Campos's
algorithm for
A spanning tree is known to
be the optimal approa h to handle broad ast. However, most of the state of the art solutions use pure ooding instead, due to its simpli ity.
Upon
omparing the number of pa kets transmitted per broad ast pa ket by ea h
CHAPTER 6.
EVALUATION
233
approa h, we showed that, even for sparse networks, the gains are signi ant, namely for small PANs (n
< 10).
The omparison between ASPAN and the IP auto- on guration approa h
urrently followed also showed the higher ASPAN e ien y, in terms of signaling overhead and auto- on guration delay.
This omes from (1) the
use of the PBC me hanism to sele t the proper lega y IP auto- on guration me hanism and (2) the higher e ien y asso iated to the ASPAN broad ast approa h. The signaling overhead redu tion may rea h 70% and the auto on guration delay, when using DynLL for IP address on guration, may
ontribute to redu e the PAN setup time up to around 90%, as shown by our experimental results. However, these results are very mu h in uen ed by the underlying wireless te hnologies in use. The experimental evaluation of the on guration and re on guration of a PAN gateway demonstrated that ASPAN does work properly as far as PAN-to-Internet onne tivity is on erned.
However, from the results, an
important on lusion is that the lega y IP auto- on guration ontributes the most to the PoA re on guration time.
As su h, the way forward to
improve the PoA re on guration time shall onsider optimizations to the lega y IP auto- on guration me hanisms. Currently, ASPAN is fo used on the establishment of intra-PAN and PAN-to-Internet onne tivity. It does not de ne any mobility management solution for dealing with PAN PoA hanges. Thereby, when a PoA re on guration o
urs, the ommuni ation sessions between PAN devi es and the Internet will break down.
A possible solution ould be to run standard
Mobile IP [Per02℄ [JPA04℄ in ea h PAN devi e, for example. However, the
hange of IP version that may o
ur when the PoA hanges and the use of NAT for IPv4, pre ludes the use of Mobile IP. This is left for further investigation.
6.4.2 WiFIX As a solution also derived from the SFA framework, WiFIX onsiders Learning Bridges and IP auto- on guration me hanisms as basi building blo ks.
In this ase, two new omplementary building blo ks are de ned,
regarding (1) the on guration of the a tive spanning tree and (2) the sele tion of the proper lega y IP auto- on guration me hanism for IP terminals atta hing to the Stub WMN.
CHAPTER 6.
EVALUATION
234
The evaluation results show the higher e ien y of WiFIX when ompared to the 802.11s tree-based solution, regardless of the lifetime value sele ted for the forwarding table entries (LF T ). The re ommended value in the 802.11s draft standard is 5 s [Gro09a℄. Even for that value the WiFIX overhead is signi antly below the overheads of the proa tive 802.11s me hanisms, namely for the typi al ase where STAs behind MAPs send/re eive user data. Besides being more e ient than PREQ and RANN for uni ast tra , WiFIX is also more e ient when it omes to broad ast tra , thanks to the use of the a tive spanning tree established for uni ast. The higher re on guration time required by WiFIX when a node failure o
urs is not seen as a major problem in Stub WMNs, as they are envisioned to be stati and node failures are expe ted to o
ur sporadi ally.
On the
other hand, the lower re on guration time indu ed by the 802.11s proa tive me hanisms is a hieved using a less robust me hanism that may indu e path os illations and ontribute to further exa erbate the problems arising from the use of the ALM metri . While the mesh nodes are assumed to be essentially stati , the STAs that onne t to a WiFIX mesh network may be mobile.
WiFIX does not
provide any mobility management solution addressing STAs. Rather, it relies on the impli it mobility management me hanism enabled by the frequent data ex hange between ea h STA and the IP gateway running in the wired infrastru ture; the 802.11 mobility management me hanisms already de ned (IEEE 802.11f [fWG03℄ and IEEE 802.11r [rWG08℄) may also be onsidered. The experimental analysis performed using the prototype developed shows the good performan e of WiFIX when ompared to 802.11s.
It provides
higher throughput, both for UDP and TCP tra , lower pa ket loss, and similar delay when the oered load is equal to or lower than the maximum
apa ity of the WMN. Theoreti ally, the use of the airtime link as the metri to ompute the ommuni ation paths is better than the number of hops. When using the number of hops every link is onsidered to have the same quality.
Using the ALM metri links with lower quality may be avoided.
Still, from our experimental results we on lude that the use of a simple metri appears to be preferable.
It is important to realize that WiFIX is
not tied to a single metri . It an use metri s other than hop ount deemed useful in a given s enario or environment, to reate the a tive tree topology. The performan e analysis presented herein fo used on the WiFIX target
CHAPTER 6.
EVALUATION
235
s enario the extension of the wired infrastru ture for providing pervasive Internet a
ess.
Regarding intra-WMN ommuni ations, WiFIX may be
worse than 802.11s due to the use of a single a tive tree rooted at the master MAP for this type of ommuni ation too. In its urrent version, WiFIX supports a single master MAP. However, with a few modi ations, it an be extended to support multiple master MAPs. The
TR message used to reate the a tive topology has to in lude an
identi er (e.g., the MAC address) of the master MAP, so that slaves are able to distinguish between dierent master MAPs. Upon sele ting an upstream neighbor and a master MAP, based on the set of re eived
urrent node shall only retransmit the
TR
messages, the
TR message asso iated to the sele ted
master. Nonetheless, the upstream neighbour sele tion poli y is the same: to
hoose the parent node that ensures the lowest ommuni ation ost towards the wired infrastru ture.
Instead of a single a tive tree topology, multiple
trees rooted at a dierent master MAPs are reated. When it omes to the IP on guration of the terminals atta hing to the Stub WMN, WiFIX is also more e ient that the state of the art approa h. This results from the use of the SBC me hanism to sele t the proper lega y IP auto- on guration me hanism and from the higher e ien y asso iated to the WiFIX broad ast approa h when ompared to 802.11s. The e ien y gain is espe ially signi ant for small Stub WMNs (n
< 10);
when DHCPv4
is used for IP on guration, as it urrently happens in the great majority of the ases, it may be higher than 50%.
6.4.3 Overall on lusions The evaluation results presented in this hapter do prove the feasibility of the SFA framework we propose for multi-te hnology PANs and 802.11based Stub WMNs.
They show that it is possible to de ne simple, more
e ient, and ba kwards ompatible solutions for these types of networks without ompromising performan e. This is a
omplished by reusing lega y te hnology, namely Learning Bridges and lega y IP auto- on guration me hanisms, whi h run together with new simple omplementary me hanisms that improve e ien y and keep or improve performan e with respe t to state of the art solutions.
This validates our initial hypothesis and estab-
lishes a new approa h to address the network auto- on guration problem in multi-te hnology PANs and 802.11-based Stub WMNs.
CHAPTER 6.
EVALUATION
236
While fo used on multi-te hnology PANs and 802.11-based Stub WMNs, the SFA framework instan es proposed herein an be onsidered as a basis to address other types of networks. For example, residential networks, whi h may also in lude heterogeneous wired/wireless links, su h as IEEE 802.11, Ethernet, and UWB, have hara teristi s similar to multi-te hnology PANs; so, the ASPAN solution may be dire tly applied. On the other hand, given the similarity between the UWB and IEEE 802.11 te hnologies, WiFIX may be onsidered to reate UWB-based Stub WMNs, in order to take advantage of the high UWB data rates and over ome the urrent UWB overage limitations. This broadens the SFA appli ation s enarios.
6.5 Summary The SFA framework proposed in this thesis is just an abstra t model whi h spe i es the building blo ks that a on rete solution may in lude. As su h, the two SFA instan es onsidered for addressing auto- on guration of multi-te hnology PANs and 802.11-based Stub WMNs, ASPAN and WiFIX, respe tively, represent the a tual solutions that needed to be evaluated against state of the art solutions. In this hapter we presented a wide set of evaluation results obtained onsidering theoreti al, simulation, and experimental analysis. By means of theoreti al analysis we evaluated the e ien y of ASPAN and WiFIX when it omes to IP on guration, broad ast transmission, and path re on guration time, as well as the path on guration overhead asso iated to the 802.11s tree-based solution and WiFIX. ASPAN and WiFIX revealed to be signi antly more e ient than the orresponding state of the art solutions regarding IP on guration and broad ast transmission. Con erning path re on guration, while ASPAN was shown to exhibit path re on guration times similar to AODV, WiFIX in urs higher re on guration times than IEEE 802.11s; however, the higher re on guration time required by WiFIX when a node failure o
urs is not seen as a major problem in Stub WMNs, as they are envisioned to be stati and node failures are expe ted to o
ur sporadi ally. Regarding path on guration, WiFIX proved to be more e ient than the 802.11s. Using simulation analysis we evaluated
Campos's
algorithm, in terms of
routing ost and exe ution time. Based on simulation results, we showed that
CHAPTER 6.
EVALUATION
237
it is the urrent fastest known approximation MRCST algorithm, providing results similar to
Wong's algorithm, the fastest approximation MRCST algo-
rithm known so far, namely for heterogeneous, sparse graphs. Also based on simulations we showed that ASPAN, by using
Campos's
algorithm for om-
puting the a tive PAN topology, outperforms AODV and performs similarly to AODV-DR, as far as throughput and delay are on erned, while in urring similar path on guration load and redu ing the path establishment delay by one order of magnitude. Experimental analysis was used to evaluate ASPAN and WiFIX in a real networking environment. The ASPAN prototype was mainly used as a proof-of- on ept, but some important on lusions were drawn from the experimental results obtained. The ASPAN PBC me hanism may ontribute to redu e the PAN setup time up to 90%, the PAN setup time is very mu h in uen ed by the underlying wireless te hnologies being used, and the major part of the PAN PoA re on guration time is due to the lega y IP auto on guration me hanism. The WiFIX implementation was used to ompare WiFIX against 802.11s. Experimental results showed the WiFIX good performan e when ompared to 802.11s and demonstrated the problems of using the ALM metri de ned by default in 802.11s. For both ASPAN and WiFIX, we showed the ability of the solutions to support lega y PAN devi es and lega y terminals, respe tively. The evaluation performed along this hapter proves the feasibility of the SFA framework we propose for multi-te hnology PANs and 802.11-based Stub WMNs, and validates our initial resear h hypothesis.
Chapter 7
Con lusion In this nal hapter we provide an overview of the work developed, re all the major ontributions of our work and, nally, refer topi s that may be
onsidered for future work.
7.1 Overview of the Work Developed Network auto- on guration is ru ial for enabling multi-te hnology PANs and 802.11-based Stub WMNs. It onsists in all on gurations required to enable IP onne tivity. This involves path and IP address auto- on guration. The major obje tive of this thesis was to design a new simple, e ient, and ba kwards ompatible solution, onsidering a joint path and IP address auto- on guration approa h to multi-te hnology PANs and 802.11based Stub WMNs. To a hieve this goal we proposed the SFA framework. SFA builds upon two lega y building blo ks, Learning Bridges and lega y IP auto- on guration me hanisms, whi h provide the ba kwards ompatible
omponent, and de nes simple omplementary building blo ks intended to improve network auto- on guration e ien y and performan e with respe t to the state art of solutions. From SFA we derived two solutions for multi-te hnology PANs and 802.11based Stub WMNs, alled ASPAN and WiFIX, respe tively. ASPAN onsiders a new spanning tree algorithm,
Campos's
algorithm, de nes a new
entralized spanning tree proto ol, and in ludes new IP on guration me hanisms that are able to (1) sele t the adequate lega y IP auto- on guration me hanism to be used for IP-related on gurations and (2) on gure the best PoA for a PAN. WiFIX de nes a new distributed single-message signal-
239
CHAPTER 7.
CONCLUSION
240
ing proto ol to reate the a tive Stub WMN spanning tree and onsiders an IP on guration me hanism to e iently a
omplish IP auto- on guration of the terminals atta hing to an 802.11-based Stub WMN. Our evaluation results show that ASPAN and WiFIX do represent more e ient solutions than their state of the art ounterparts, while keeping performan e, simpli ity, and ba kwards ompatibility. In addition, they validate our initial hypothesis and support the ommon approa h we have followed to
ope with path and IP address auto- on guration within multi-te hnology PANs and 802.11-based Stub WMNs, despite the dieren es between the networks. In spite of being fo used on multi-te hnology PANs and 802.11-based Stub WMNs, the SFA framework instan es proposed herein an be onsidered as a basis to address other types of networks. For example, residential networks, with hara teristi s similar to multi-te hnology PANs may bene t from the ASPAN solution.
On the other hand, WiFIX may be used, for
instan e, to enable UWB-based Stub WMNs, given the similarity between the UWB and IEEE 802.11 te hnologies and the urrent UWB overage limitations.
The SFA framework itself may be used as a basis to derive new
network auto- on guration solutions targeting these or other types of networks.
7.2 Original Contributions In the following we re all the major ontributions of this PhD thesis.
7.2.1 A Simple and Flexible Network Auto- on guration Framework for Multi-te hnology PANs and 802.11based Stub WMNs We propose an auto- on guration framework, alled SFA framework, to address path and IP address auto- on guration of multi-te hnology PANs and 802.11-based Stub WMNs. The novelty of the framework omes from the reuse of lega y te hnology, namely Learning Bridges and lega y IP auto on guration me hanisms, as a basis for a simple and ba kwards ompatible joint path and IP address auto- on guration solution addressing multite hnology PANs and 802.11-based Stub WMNs. This is in ontrast to state of the art solutions, whi h address path and IP address auto- on guration
CHAPTER 7.
CONCLUSION
241
separately, de ne new solutions from the s rat h, introdu e unne essary omplexity, and make migration from lega y systems hard or even impossible. In spite of targeting multi-te hnology PANs and 802.11-based Stub WMNs, the SFA framework is not limited to this type of networks; the modularity of the framework enables its easy adaptation to other networking s enarios. SFA has some limitations. The use of Learning Bridges limits SFA to small s ale networks.
In addition, due to the use of a single spanning tree, it is
only a good auto- on guration framework for heterogeneous networks or for networks where tra onverges to a single node.
In su h ases a single
spanning tree is good enough, as proved by the evaluation results obtained for ASPAN and WiFIX.
7.2.2 A Simple and E ient IP Auto- on guration Me hanism for Dual-sta k Nodes We propose a simple and e ient IP auto- on guration me hanism that enables the e ient oexisten e of two IP versions. The proposed me hanism sele ts the proper IP auto- on guration a
ording to the networking ontext. As su h, it enables the establishment of IP onne tivity in a more e ient and simpler way than using the state of the art trial-and-error me hanism employed by dual-sta k IP devi es; less number of signaling messages are involved and the address auto- on guration pro edure may be ompleted faster.
Nevertheless, the me hanism is only bene ial if running in every
node involved in the IP auto- on guration pro edure; otherwise, it will only
ontribute to in rease the IP auto- on guration overhead.
Also, it is only
useful if a single IP version is to be used. If both versions are intended to be on gured, there is no advantage in using the proposed me hanism; the ex eption is the ase when DynLL is used in IPv4, as shown in Chapter 6.
7.2.3 A Fast Algorithm for Computing Minimum Routing Cost Spanning Trees Con erning the on guration of the a tive spanning tree in multi-te hnology PANs, we propose a new spanning tree algorithm, named gorithm.
Campos's
al-
Campos's algorithm deals with the omputation of an approximate
MRCST. By ombining dierent approa hes followed by state of the art algorithms, su h as
Prim's, Add,
and
Dijkstra's
algorithms, it is the urrent
fastest known approximation MRCST algorithm, providing results similar
CHAPTER 7.
to
Wong's
CONCLUSION
242
algorithm the fastest approximation MRCST algorithm known
so far, namely when it omes to heterogeneous, sparse graphs. The major drawba ks of
Campos's algorithm are (1) its entralized hara teristi , whi h
may pre lude the use of the algorithm in a distributed path on guration solution, and (2) the trend to diverge from the results provided by
Wong's
algorithm when the set of dierent edge weights in the input graph in reases.
7.2.4 A Network Auto- on guration Solution for Multi-te hnology PANs The Auto- on guration and Self-management of Personal Area Networks (ASPAN) solution de nes a new solution for multi-te hnology PANs. ASPAN uses
Campos's
algorithm to ompute the a tive PAN topology, de nes
a new entralized spanning tree proto ol, onsiders the me hanism referred to in Se tion 7.2.2 for e iently on guring IP onne tivity, and de nes a me hanism for sele ting the best PoA for a PAN. ASPAN represents a new simple and ba kwards ompatible solution for multi-te hnology PANs, whi h is more e ient and exhibits the same or better performan e than state of the art solutions.
ASPAN has two major drawba ks.
Firstly, if the PAN
master runs out of battery, for example, the PAN annot be maintained anymore; a PAN master handover me hanism an be added to ASPAN in the future to over ome this short oming. Se ondly, the use of a single spanning tree makes ASPAN more vulnerable to topology hanges than state of the art solutions.
7.2.5 A Network Auto- on guration Solution for 802.11-based Stub WMNs The Wi-Fi network Infrastru ture eXtension (WiFIX) solution is proposed to address 802.11-based Stub WMNs. WiFIX uses a new distributed single-message signaling proto ol to reate the a tive Stub WMN spanning tree and onsiders the IP on guration me hanism referred to in Se tion 7.2.2 to e iently a
omplish the IP auto- on guration of the terminals atta hing to the Stub WMN. WiFIX represents a new simple and ba kwards
ompatible solution for auto- on guring 802.11-based Stub WMNs that exhibits good performan e and is more e ient than the referen e state of the art solution, IEEE 802.11s. The main drawba ks of WiFIX are (1) the exponential growth of the Learning Bridges' forwarding tables as the size of
CHAPTER 7.
CONCLUSION
243
the WMN in reases, (2) the higher re on guration time when ompared to IEEE 802.11s, and (3) the non-optimal performan e regarding intra-mesh
ommuni ation.
7.3 Future Work In the following we refer to resear h topi s that may be onsidered as part of future work within the s ope of ASPAN and WiFIX.
ASPAN Improve
Campos's
algorithm.
Along our simulations we veri ed that
the routing ost of the nal spanning tree omputed by
Campos's
algorithm
depends signi antly on the sele ted initial vertex. Thus, improvements to the sele tion of the initial vertex may be onsidered in the future as a way to a hieve better results with our algorithm. In addition, the re-de nition of the omposed parameters
wdv
and
jspv
may be taken into a
ount by
using other basi parameters either to be ombined with the urrent basi parameters or to be used in alternative.
Design sion,
Campos's
Campos's
algorithm distributed version.
algorithm is a entralized algorithm.
In its urrent ver-
The de nition of its
distributed version is a possible topi for future work to broaden the appli ation domain of our algorithm.
Improve topology maintenan e pro edure.
The urrent ASPAN topol-
ogy maintenan e pro edure runs periodi ally regardless of the mobility pattern of the PAN devi es and the number of data ows running. Improvements to the topology maintenan e pro edure may be onsidered so that the PAN master adapts the topology refresh period a
ording to the data ow a tivity and the mobility pattern of the PAN devi es; if there are no data ows running or the PAN is foreseen to be stable, the topology refresh period an in rease, and vi e-versa.
Consider inter-PAN ommuni ation.
ASPAN is fo used on network
auto- on guration of a single PAN. The extension of ASPAN to address inter-PAN ommuni ation may be onsidered in the future; this may in lude
CHAPTER 7.
CONCLUSION
244
the design of the me hanisms needed to enable PoA sharing and the on guration of the nodes enabling the ommuni ation between atta hing PANs as IP routers or Learning Bridges.
Design of a mobility management solution to ope with PoA hanges. Currently, when the PAN PoA hanges ongoing sessions are broken; this problem is aggravated by the oexisten e of two IP versions. The design of a network mobility solution that (1) opes with PoA hanges and (2) onsiders the oexisten e of two IP versions is a topi for further investigation.
Use other metri s to de ne a tive spanning tree and PoA.
Con-
erning the omputation of the a tive spanning tree and the sele tion of the PoA, other metri s su h as energy onsumption and nan ial ost may be taken into a
ount in alternative or together with the urrent metri (nominal bandwidth). ASPAN may then be upgraded with a me hanism to de ide whi h metri shall be used in ea h networking ontext to on gure the a tive spanning tree and the PoA.
WiFIX Support multi ast tra e iently.
WiFIX is fo used on uni ast and
broad ast tra ; multi ast tra is handled as broad ast.
A better solu-
tion for handling multi ast tra may be investigated, possibly reusing te hniques well known from bridged Ethernet networks, su h as IGMP snooping.
Explore other metri s to on gure the a tive spanning tree.
Re-
garding the on guration of the a tive spanning tree, other metri s may be explored. For instan e, the number of hildren of a MAP may be onsidered as a se ond order metri . When a MAP has two or more andidate parents with the same hop ount metri , the number of hildren for ea h andidate parent may be used to break the tie. This will enable the reation of a bal-
1 and fairer distribution of the tra within the
an ed a tive spanning tree Stub WMN.
Redu e signaling overhead. 1
WiFIX targets the extension of a wired
A balan ed spanning tree is de ned as a tree where no leaf is mu h farther away from the root than any other leaf; an example of a balan ed tree is the omplete binary tree.
CHAPTER 7.
CONCLUSION
245
infrastru ture for enabling Internet a
ess. So, an improvement may be to develop a me hanism that enfor es ommuni ation between ea h MAP and the master MAP only. This will for e all signaling messages sent in broad ast by ea h MAP, su h as ARP, NDP, and DHCP messages, to use only the path between ea h MAP and the master MAP and will avoid unne essary network-wide signaling.
Upgrade ATCM me hanism.
WiFIX is urrently limited to a single
master MAP, operates using a single wireless hannel, and assumes a single radio per MAP with omnidire tional antennas. ATCM may be upgraded to support multiple wireless hannels, multiple master MAPs, multiple radios, and dire tional antennas. This will ontribute to improve the performan e and the s alability of a WiFIX Stub WMN.
Improve SBC me hanism.
The SBC me hanism may be amended to
take into a
ount (1) load balan ing among the supported lega y IP auto on guration me hanisms and (2) the type of terminal atta hing.
If there
are multiple lega y IP auto- on guration me hanisms available, SBC may distribute the load evenly among them. On the other hand, depending on the type of terminal atta hing, SBC may enfor e a dierent lega y IP auto-
2
on guration; for instan e, if the atta hing terminal is a guest terminal , SBC may enfor e the use of some spe i IP version and lega y IP auto on guration me hanism.
2
A guest terminal is a terminal visiting a Stub WMN owned by a given entity, e.g., university, ompany.
Appendix A Campos's
algorithm
This appendix explains how
Campos's
algorithm is used to ompute an
MRCST by means of an illustrative example. Also, it provides further simulation results obtained with the STS simulator for
Campos's
algorithm and
the state of the art spanning tree algorithms used as a basis for omparison,
spv and wdv are independent from C3 , C4 , and C5 . On the other hand,
and it shows that, in general, the values of the values of the oe ients
C1 , C2 ,
this appendix highlights the gain and the dieren e between
Campos's
algo-
rithm and the standard IEEE algorithm used by IEEE 802.1D bridges, by
omparing the spanning trees omputed by ea h algorithm for an example input graph.
v
dv
1 2 3 4 5 6 7
2 3 3 3 3 2 2
sv 101 102 21 12 21 2 11
dv , sv , vertex v .
Table A.1: Values of the parameters spanning potential (spv ) for ea h
mv 100 100 10 10 10 1 10
247
spv
0.4 0.6 0.7 0.8 0.7 1.2 0.5 and
mv
and the orresponding
APPENDIX A.
CAMPOS'S ALGORITHM
248
1 100
1
2
4 10
1
1
1
3 5
10 6
10 1
7
Figure A.1:
Example graph and the orresponding approximate MRCST
omputed using
Campos's
algorithm (in bold).
A.1 Illustrative Example In order to illustrate the use of
Campos's algorithm in the omputation of
an approximate MRCST, let us onsider the input graph shown in Fig. A.1. We start by al ulating the parameters
dv , sv ,
and
mv ,
and the spanning
potential for ea h vertex (spv ). The values are presented in Table A.1. A
ording to the algorithm, the vertex with the highest the initial vertex
f.
L.
Here,
is sele ted as
In this ase vertex 6 is sele ted; the orresponding
appears inside a re tangle in Table A.1. Subsequently, of verti es
spv
L is modeled by a table,
f
spv
is added to the list
where ea h olumn represents a
vertex in the list. The vertex sele ted at ea h step of the algorithm to make part of
T
is shown in bold. The value of the omposed parameter that made
it happen appears inside a re tangle. The tables A.2a A.2g represent the dierent instan es of Initially
L
L.
only ontains vertex 6. The values of the parameters hara -
terizing vertex 6 are shown in Table A.2a; some values are unde ned (NIL), sin e the initial vertex does not have parent vertex. The algorithm pro eeds by removing vertex 6 from 7) are added to make part of
T,
L;
L
Then, all adja ent verti es to 6 (verti es 4 and
this is shown in Table A.2b. Vertex 4 is then sele ted to
sin e it is the vertex with the highest
for all verti es in added to
L.
L;
jspv
and
wdv
is equal
the verti es adja ent to vertex 4 (vertex 1 and 3) are
(Table A.2 ). Vertex 7 is sele ted to make part of
T,
as it is the
APPENDIX A.
CAMPOS'S ALGORITHM
v
6
v
4
wv dv sv pv pdv psv cfv
0 2 2 NIL NIL NIL 0 0 NIL
wv dv sv pv pdv psv cfv
1 3 12 6 2 2 1 1 5.4
wdv jspv
(a)
wdv jspv
7 1 2 11 6 2 2 1 1 4.3
v
7
wv dv sv pv pdv psv cfv
1 2 11 6 2 2 1 1 4.3
wdv jspv
(b)
v
1
wv dv sv pv pdv psv cfv
1 2 101 4 3 12 2 1.1 5.0
wdv jspv
249
3 10 3 21 4 3 12 11 10.1 6.2
5 10 3 21 7 2 11 11 10.1 5.2
(d) v wv dv sv pv pdv psv cfv wdv jspv
5 10 3 21 7 2 11 11 10.1 5.2 (f)
v
3
wv dv sv pv pdv psv cfv
10 3 21 4 3 12 11 10.1 6.2
wdv jspv
1 1 2 101 4 3 12 2 1.1 5.0
3 10 3 21 4 3 12 11 10.1 6.2
( ) 5 10 3 21 7 2 11 11 10.1 5.2
2 100 3 102 1 2 101 102 100.2 5.0
(e)
2
v
5
1 3 102 3 3 21 12 2.1 6.0
wv dv sv pv pdv psv cfv
1 3 21 2 3 102 13 2.2 6.0
wdv jspv
(g)
Table A.2: Tables representing the dierent instan es of
L.
APPENDIX A.
CAMPOS'S ALGORITHM
vertex with the lowest vertex added to in
L;
T
wdv ;
T,
vertex 5 is added to
L
is vertex 1, sin e it has the lowest
vertex 2 is added to
and added to
250
L
(Table A.2d). The next
wdv
among the verti es
L wd2
(Table A.2e). Next, vertex 3 is removed from
due to its highest
jspv .
Sin e the omposed parameter
gets lower value if omputed using vertex 3 as andidate parent vertex, the
andidate parent for vertex 2 is hanged at this stage (Table A.2f); regarding vertex 5 nothing hanges, as the omposed parameter
wd5
does not get lower
value if vertex 3 is onsidered as its andidate parent vertex. Subsequently, as the vertex with the lowest
T.
wdv ,
vertex 2 is removed from
Vertex 5 is now the remaining vertex in
part of
T.
At this point,
T
L.
L
and added to
It is nally sele ted to make
de nes the approximate MRCST shown in Fig.
A.1 in bold.
A.2 Simulation Results for Slightly Heterogeneous Graphs This se tion provides further simulations results obtained using the STS simulator.
The plots shown in Fig.
set of edge weights
S = {1, 2, 3}
A.2 were obtained by onsidering the
as input to the STS simulator. The set
was obtained by using the dis rete fun tion
v[n]
S
presented in Se tion 6.2.1
1 ≤ n ≤ 3.
Campos's algorithm we an on lude the following. When the number of verti es in the input graph is small (n = 10) Campos's algorithm provides the same results as Wong's algorithm, independently of the input graph density. As the size of the input graph in reases Campos's algorithm tends to perform slightly worse than Wong's algorithm but provides similar Regarding
or the same results when the input graph is dense. represents a suitable alternative to graph is slightly heterogeneous.
Wong's
Then, our algorithm
algorithm also when the input
On the other hand,
Campos's
algorithm
provides lower routing osts than urrent IEEE spanning tree algorithm, independently of the size of the input graph. The gain may rea h 21% but, in ontrast to what happens for homogeneous input graphs, it de reases with the size of the input graph (this o
urs for both
Campos's
and
Wong's
algorithms). Con erning MST algorithms the following on lusions an be drawn.
Prim's
algorithm provides a good approximate MRCST when the size of
CAMPOS'S ALGORITHM
1.2
Routing Cost (normalized)
Routing Cost (normalized)
APPENDIX A.
Campos Wong
1.1 1 0.9 0.8 0.7 0
2
4
6
8
251
Add Prim Kruskal
2.4 2 1.6 1.2 0.8
10
0
Average Degree per Vertex
Campos Wong
1.1 1 0.9 0.8 0.7 0
5 10 15 20 25 Average Degree per Vertex
2
1.2 0.8 0
Routing Cost (normalized)
Routing Cost (normalized)
0.9 0.8 0.7 10 20 30 40 Average Degree per Vertex
(e) n = 50 Figure A.2: sis when
5 10 15 20 25 Average Degree per Vertex
30
50
Add Prim Kruskal
2.4 2 1.6 1.2 0.8 0
10 20 30 40 Average Degree per Vertex
50
(f) n = 50
Routing osts for ea h spanning tree algorithm under analy-
slightly heterogeneous
onsidered.
10
(d) n = 30
1
0
8
1.6
30
Campos Wong
1.1
6
Add Prim Kruskal
2.4
( ) n = 30
1.2
4
(b) n = 10
Routing Cost (normalized)
Routing Cost (normalized)
(a) n = 10
1.2
2
Average Degree per Vertex
input graphs of 10, 30, and 50 verti es are
APPENDIX A.
CAMPOS'S ALGORITHM
the input graph is small.
For
n = 10
the routing ost is just about 5%
greater than the routing ost provided by the results for
Kruskal's
252
Campos's and Wong's
algorithms;
algorithm are similar. We then on lude that, for
small input graphs, the edge weights an almost be used as the only sele tion
riterion regarding the onstru tion of the approximate MRCST. However, as the size of the input graph in reases MST algorithms provide worse results, even worse than urrent IEEE spanning tree algorithm. This an be explained by using the example given in Fig. 5.9. For a given input graph
G
with 6 verti es, if one of the spanning trees shown in Fig. 5.9 is an MST the other also de nes an MST for
G,
sin e both have total ost equal to 7. An
MST algorithm an sele t both with equal probability, although they have dierent topologies and, as su h, have dierent routing osts; the spanning tree on the right-hand side has lower routing ost.
This fa t, on average,
ontributes to in rease the routing ost of the nal spanning tree. For small size input graphs the number of possible MSTs is small and the dieren es in topology are small too; thereby, the average routing ost does not greatly diverge from the routing ost of the best MST (from the perspe tive of the routing ost), whi h represents a good approximate MRCST, as impli itly shown by our simulation results. Yet, the number of possible MSTs in reases for bigger input graphs, as well as the number of MSTs providing higher routing ost than the best MST. On average, the routing ost of the spanning tree omputed by an MST algorithm in reases a
ordingly. Nevertheless, for the input graphs onsidered in this ase the dieren es between the routing ost for the MST algorithms and the other spanning tree algorithms are attenuated by the redu ed heterogeneity of the edge weights; for highly heterogeneous the dieren es are greater when the input graphs are dense, as we have seen in Chapter 6. As theoreti ally expe ted,
Add
algorithm does not provide good results
for heterogeneous graphs, even for slightly heterogeneous graphs. Regardless of the size of the input graph it provides routing osts that diverge from the results a hieved by the other algorithms.
This is be ause it does not
onsider the edge weights at all; only topology is onsidered whi h is in general insu ient for onstru ting a spanning tree with small routing ost as mentioned in Chapter 5. The on lusion is that, in fa t, the
Add algorithm
annot be used as an approximate MRCST when the input graph is nonhomogeneous.
APPENDIX A.
CAMPOS'S ALGORITHM
253
A.3 Dependen e of spv and wdv from the Coe ients The parameters parameters.
spv
spv
and
wdv
result from a linear ombination of basi
is the result of a linear ombination of three parameters,
where ea h parameter is ae ted by the oe ients
C1 , C2 ,
and
C3 ; wdv
is
omputed from the linear ombination of two parameters whi h are ae ted by the oe ients
C4
and
C5 .
In this se tion, we present simulation results
obtained using the STS simulator whi h prove that
spv
wdv
and
are, in
general, not in uen ed by the values of these oe ients. The urves shown in Fig. A.4, Fig. A.5, and Fig. A.6 were obtained onsidering multiple ombinations for the oe ients and for the set of weights
onsidered in STS to generate random graphs; the routing ost is normalized to the routing ost of the spanning tree omputed using the IEEE algorithm. In ea h gure, we onsider a matrix of 20 plots. The rst and se ond olumns refer to the results obtained for results for
n = 30.
C2 , and C3
n
= 10; the last two olumns provide the
In ea h plot dierent ombinations for the oe ients
are onsidered. Note that the number of ombinations is limited,
sin e the sum of the three oe ients shall be 1; so, in ea h ombination,
C2 ,
and
C3
C1 , C1 ,
take one of three values: 0.2, 0.4, or 0.6. In the matrix of plots
onsidered in ea h gure, a row provides the results for a given ombination of the oe ients
C4
and
C5 .
In ea h ombination,
C4
and
C5
take one of
four values: 0.1, 0.3, 0.7, or 0.9; again, the number of ombinations is limited be ause the sum of the two oe ients shall be 1. After analyzing the plots, the following on lusions an be drawn. Regardless of the values onsidered for
C1 , C2 ,
approximate MRCST obtained is the same.
and
C3 ,
the routing ost of the
In ea h plot the urves over-
lap; on the other hand, in ea h gure, the urves in the rst and se ond
olumns (n = 10) and in the third and fourth olumns (n = 30) are similar.
C4 and C5 , the on lusion is dierent. For highly heterogeneous input graphs (S = {1, 10, 100} and S ={1, 10, 100, 1000, 10000}), as C4 be omes lower than C5 , the routing ost of the omputed MRCST inCon erning oe ients
reases.
This is lear if, for ea h gure, we ompare the urves shown in
the rst row with the last three rows of plots. The best results are obtained when
C4
is equal or greater than
C5 .
Regarding homogeneous input graphs, the parameters
spv
and
wdv
are
APPENDIX A.
CAMPOS'S ALGORITHM
254
not in uen ed by the values of the oe ients. This an easily be demonstrated analyti ally. As we have seen in Chapter 5,
spv = C1 · dv + C2 · When the input graph is homogeneous,
spv
is given by:
dv 1 + C3 · sv mv
dv sv
=1
and
1 mv
(A.1)
=1
for every vertex.
So, the sele tion of the vertex with the highest spanning potential is based on the
dv
parameter only.
values of the oe ients
Sin e a single parameter is truly involved, the
C1 , C2 ,
and
C3
an be any.
The same reasoning an be applied to the
wdv
parameter.
wdv
is given
by:
wdv = C4 · wv + C5 · cfv
(A.2)
wv = 1 for every vertex. Therefore, the sele tion of the vertex with the lowest wdv value is simply de ned by the cfv parameter. Again, with a single parameter truly involved, the values of C4 and C5 an be any.
When the input graph is homogeneous,
A.4 Spanning Tree Computation using algorithm and the IEEE algorithm
Campos's
In this se tion, using an example, we illustrate the gain and the differen e between
Campos's
algorithm and the standard IEEE spanning tree
algorithm. For that purpose, we ompare the spanning trees omputed by ea h algorithm onsidering the example input graph of Fig. A.1. The omputation of the spanning tree using
Campos's
algorithm was explained in
Se tion A.1; the spanning tree obtained is shown in Fig. A.1. The spanning tree omputed by the IEEE algorithm onsists of a random SPST, due to the random sele tion of the root of the SPST. Consider, for instan e, that in this ase vertex 5 is sele ted as the root. An SPST rooted at vertex 5 is shown in Fig. A.3. In order to ompare the two spanning trees, we al ulate their routing
osts.
The routing ost for the spanning tree omputed using
Campos's
algorithm (CC ) and the IEEE algorithm (CI ) are shown in Eq. A.3 and Eq.
APPENDIX A.
CAMPOS'S ALGORITHM
255
1 1 2
4 10
1
1
3 5 6
10 7
1
Figure A.3: Spanning tree obtained using the standard IEEE algorithm for the example graph of Fig. A.1, when vertex 5 is sele ted as the root.
A.4, respe tively.
CC
= 12 + 11 + 1 + 13 + 2 + 3 + 1 + 11 +1 + 12 + 13 + 10 + 2 + 11 + 12 +12 + 1 + 2 + 13 + 14 + 1 = 158
CI
(A.3)
= 12 + 11 + 1 + 13 + 24 + 23 + 1 + 11 +1 + 12 + 11 + 10 + 2 + 13 + 12 +12 + 23 + 22 + 11 + 10 + 1 = 236
(A.4)
In this ase, the normalized routing ost of the spanning tree obtained using
Campos's
algorithm is 0.67 (158/236). So, there is a redu tion of 33%
when ompared to the routing ost of the spanning tree omputed using the IEEE algorithm. Here, the purpose is to show with an example the spanning trees obtained using ea h algorithm. This represents a snapshot of the simulations performed using random input graphs and omplements the simulation results provided in Chapter 6, sin e it gives the details and provides further insight on the reasons for the gains obtained when used.
Campos's
algorithm is
CAMPOS'S ALGORITHM
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 0.7 2 4 6 8 Average Degree per Vertex
(b)
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
n=10; C4 =0.3, C5 =0.7
( )
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 0.7
(i)
2 4 6 8 Average Degree per Vertex
n=10; C4 =0.3, C5 =0.7
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8
(j)
(g)
2 4 6 8 Average Degree per Vertex
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 0.7
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9
2 4 6 8 Average Degree per Vertex
0.8
10
n=10; C4 =0.7, C5 =0.3
(n)
2 4 6 8 Average Degree per Vertex
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 0.7
n=10; C4 =0.7, C5 =0.3
(o)
2 4 6 8 Average Degree per Vertex
10
n=10; C4 =0.9, C5 =0.1
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
2 4 6 8 Average Degree per Vertex
10
n=10; C4 =0.9, C5 =0.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 5 10 15 20 25 Average Degree per Vertex
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0
(h)
5 10 15 20 25 Average Degree per Vertex
C1 , C2 , C3 , C4 ,
and
C5 , obtained for n S = {1, 2, 3} .
30
n=30; C4 =0.3, C5 =0.7 1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
5 10 15 20 25 Average Degree per Vertex
30
0
(l)
n=30; C4 =C5
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =C5
1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.7, C5 =0.3
0
(p)
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.7, C5 =0.3 1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.9, C5 =0.1
0
(t)
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.9, C5 =0.1
Figure A.4: Normalized routing ost for dierent values of the oe ients (right hand side), when
30
n=30; C4 =0.1, C5 =0.9
30
n=30; C4 =0.3, C5 =0.7
0
(s)
1.1
0.7 5 10 15 20 25 Average Degree per Vertex
0.7 0
(r)
C1=0.2;C2=0.6;C3=0.2
1.5
1.4
0.7 0
1.2
0
Routing Cost (normalized)
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
10
1.5
1.4
Routing Cost (normalized)
1.5
(d)
0.7 0
C1=0.4;C2=0.2;C3=0.4
0
1.5
1.4
0.7 0
C1=C2=C3
1.3
(k) Routing Cost (normalized)
C1=C2=C3
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
1.5
1.4
0
n=10; C4 =C5
C1=0.4;C2=0.2;C3=0.2
1.3
30
n=30; C4 =0.1, C5 =0.9
10
1.4
0.7 5 10 15 20 25 Average Degree per Vertex
0
1.5
1.4
Routing Cost (normalized)
1.5
0.8
0.7 0
n=10; C4 =C5
C1=0.2;C2=0.4;C3=0.4
1 0.9
1.5
1.4
10
1.1
10
0.7 0
C1=0.2;C2=0.6;C3=0.2
0.7 2 4 6 8 Average Degree per Vertex
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
Routing Cost (normalized)
C1=C2=C3
1.3
1.2
0
1.5
1.4
C1=0.2;C2=0.2;C3=0.6
1.5
1.4
0
(f)
C1=C2=C3
1.3
10
n=10; C4 =0.1, C5 =0.9
10
1.5
1.4
0.7 2 4 6 8 Average Degree per Vertex
0.7 2 4 6 8 Average Degree per Vertex
1.5
Routing Cost (normalized)
0.8
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
Routing Cost (normalized)
C1=C2=C3
1.3
0
Routing Cost (normalized)
C1=0.6;C2=0.2;C3=0.2
1 0.9
1.5
1.4
0.7
(q)
1.1
0
1.5
(m)
C1=0.4;C2=0.2;C3=0.4
10
n=10; C4 =0.1, C5 =0.9
(e)
1.2
0.7 0
(a)
C1=0.4;C2=0.4;C3=0.2
Routing Cost (normalized)
C1=0.2;C2=0.6;C3=0.2
C1=0.4;C2=0.2;C3=0.2
1.3
Routing Cost (normalized)
1.2
1.5
1.4
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
C1=C2=C3
1.3
Routing Cost (normalized)
1.5
1.4
Routing Cost (normalized)
Routing Cost (normalized)
1.5
256
Routing Cost (normalized)
APPENDIX A.
= 10 (left hand side) and
n
= 30
CAMPOS'S ALGORITHM
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 2 4 6 8 Average Degree per Vertex
0.8
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.8 2 4 6 8 Average Degree per Vertex
n=10; C4 =0.3, C5 =0.7
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
0.8
( )
2 4 6 8 Average Degree per Vertex
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
n=10; C4 =0.3, C5 =0.7
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.8
(j)
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 0.7
2 4 6 8 Average Degree per Vertex
2
4 6 8 Average Degree per Vertex
n=10; C4 =0.7, C5 =0.3
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
0.8 2
4 6 8 Average Degree per Vertex
n=10; C4 =0.7, C5 =0.3
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 0.7 2 4 6 8 Average Degree per Vertex
10
n=10; C4 =0.9, C5 =0.1
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8
(h)
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
n=10; C4 =0.9, C5 =0.1
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 5 10 15 20 25 Average Degree per Vertex
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8
(l)
5 10 15 20 25 Average Degree per Vertex
C1 , C2 , C3 , C4 ,
and
1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
0
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.7, C5 =0.3
0
(p)
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.7, C5 =0.3 1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
0
C5 , obtained for n = S = {1, 10, 100}.
30
n=30; C4 =C5
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.9, C5 =0.1
0
(t)
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.9, C5 =0.1
Figure A.5: Normalized routing ost for dierent values of the oe ients (right hand side), when
30
n=30; C4 =0.3, C5 =0.7
0
n=30; C4 =C5
0.8
(s)
1.4
30
0.9
10
30
0.7 5 10 15 20 25 Average Degree per Vertex
0.7 2 4 6 8 Average Degree per Vertex
5 10 15 20 25 Average Degree per Vertex
n=30; C4 =0.1, C5 =0.9
0
1.5
1.4
0
(r)
C1=0.2;C2=0.2;C3=0.6
1
0.7 0
C1=C2=C3
1.3
0
(o)
0.8
1.5
1.4
0.8
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
C1=C2=C3
1.3
n=30; C4 =0.3, C5 =0.7
10
C1=0.6;C2=0.2;C3=0.2
1 0.9
30
0.7 0
1.1
0.7 5 10 15 20 25 Average Degree per Vertex
1
1.5
1.4
(d)
1.5
0.9
1.5
C1=0.2;C2=0.4;C3=0.4
(k)
1
(n)
1.1
0.9
n=10; C4 =C5
1.4
10
C1=0.2;C2=0.6;C3=0.2
0
0.7 0
1.2
10
C1=0.4;C2=0.2;C3=0.4
0
0.7 0
n=10; C4 =C5
C1=0.2;C2=0.2;C3=0.6
0.8
Routing Cost (normalized)
10
Routing Cost (normalized)
(i)
2 4 6 8 Average Degree per Vertex
C1=C2=C3
1.3
1
0.7 0
C1=0.4;C2=0.4;C3=0.2
1.2
1.5
1.4
0.9
(g)
C1=0.4;C2=0.2;C3=0.2
1.3
30
1.5
1.4
0.9
0.7
5 10 15 20 25 Average Degree per Vertex
n=30; C4 =0.1, C5 =0.9
10
1.4
0.7 0
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
C1=C2=C3
1.3
C1=0.2;C2=0.4;C3=0.4
0.8
1.5
1.4
1.1
0.7 0
(f)
C1=0.2;C2=0.6;C3=0.2
1.5
1.4
1
1.5 Routing Cost (normalized)
n=10; C4 =0.1, C5 =0.9
10
1.2
10
0.7 0
Routing Cost (normalized)
2 4 6 8 Average Degree per Vertex
0.9
0.7
C1=0.2;C2=0.2;C3=0.6
1
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
Routing Cost (normalized)
C1=C2=C3
1.3
C1=C2=C3
1.3
0.7 0
(b)
1.5
1.4
0.9
1.5
1.4
0.9
Routing Cost (normalized)
C1=0.6;C2=0.2;C3=0.2
1
1.5
(q)
1.1
10
n=10; C4 =0.1, C5 =0.9
(m)
C1=0.4;C2=0.2;C3=0.4
0.7 0
(e)
1.2
0.9
0.7
(a)
C1=0.4;C2=0.4;C3=0.2
Routing Cost (normalized)
C1=0.2;C2=0.6;C3=0.2
C1=0.4;C2=0.2;C3=0.2
1.3
Routing Cost (normalized)
1.2
1.5
1.4
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
C1=C2=C3
1.3
Routing Cost (normalized)
1.5
1.4
Routing Cost (normalized)
Routing Cost (normalized)
1.5
257
Routing Cost (normalized)
APPENDIX A.
10 (left hand side) and
n
= 30
CAMPOS'S ALGORITHM
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8 2 4 6 8 Average Degree per Vertex
0.8
(b)
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.8 2 4 6 8 Average Degree per Vertex
n=10; C4 =0.3, C5 =0.7
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.8
( )
2 4 6 8 Average Degree per Vertex
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
n=10; C4 =0.3, C5 =0.7
(g)
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.8 0.7
0
(i)
2 4 6 8 Average Degree per Vertex
10
(j)
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
0.9 0.8 0.7
2 4 6 8 Average Degree per Vertex
10
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
(n) Routing Cost (normalized)
n=10; C4 =0.7, C5 =0.3
1 0.9 0.8 0.7
2 4 6 8 Average Degree per Vertex
2
4 6 8 Average Degree per Vertex
n=10; C4 =0.7, C5 =0.3
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
n=10; C4 =0.9, C5 =0.1
C1=0.6;C2=0.2;C3=0.2
0.9 0.8
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
2
4 6 8 Average Degree per Vertex
n=10; C4 =0.9, C5 =0.1
(s)
0.8 5 10 15 20 25 Average Degree per Vertex
n=30; C4 =0.1, C5 =0.9
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0
(h)
5 10 15 20 25 Average Degree per Vertex
C1 , C2 , C3 , C4 ,
and
30
n=30; C4 =0.3, C5 =0.7
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
5 10 15 20 25 Average Degree per Vertex
30
0
(l)
n=30; C4 =C5
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =C5
1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.7, C5 =0.3
0
(p)
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.7, C5 =0.3 1.5
1.4
C1=C2=C3
1.3
C1=0.2;C2=0.2;C3=0.6
1.2
C1=0.2;C2=0.6;C3=0.2
1.1
C1=0.2;C2=0.4;C3=0.4
1 0.9 0.8
1.4
C1=0.4;C2=0.2;C3=0.2
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
C1=0.4;C2=0.2;C3=0.4
1.1
C1=0.6;C2=0.2;C3=0.2
1 0.9 0.8 0.7
5 10 15 20 25 Average Degree per Vertex
30
n=30; C4 =0.9, C5 =0.1
0
(t)
5 10 15 20 25 Average Degree per Vertex
C5 , obtained for n = 10 (left hand S = {1, 10, 100, 1000, 10000}.
30
n=30; C4 =0.9, C5 =0.1
Figure A.6: Normalized routing ost for dierent values of the oe ients (right hand side), when
30
1.5
1.4
0
10
C1=0.6;C2=0.2;C3=0.2
1 0.9
30
n=30; C4 =0.3, C5 =0.7
0
(o)
1.1
0.7 5 10 15 20 25 Average Degree per Vertex
0.7 0
(r)
1.2
1.5
1
10
C1=0.2;C2=0.2;C3=0.6
10
0.7 0
(d)
0.7 0
Routing Cost (normalized)
0
C1=0.4;C2=0.2;C3=0.4
0
1.5
1.4
1
0.7
C1=C2=C3
1.3
(k) Routing Cost (normalized)
C1=C2=C3
1.3
C1=0.4;C2=0.4;C3=0.2
1.2
1.5
1.4
0
n=10; C4 =C5
C1=0.4;C2=0.2;C3=0.2
1.3
30
n=30; C4 =0.1, C5 =0.9
10
1.5
1.4
Routing Cost (normalized)
1.5
2 4 6 8 Average Degree per Vertex
1.4
0.7 5 10 15 20 25 Average Degree per Vertex
0.7 0
n=10; C4 =C5
0.8
1.5
1.4
0.9
0.7
C1=0.2;C2=0.4;C3=0.4
1 0.9
0
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
C1=C2=C3
1.3
1.1
10
1.5
1.4
C1=0.2;C2=0.6;C3=0.2
0.7 0
(f)
1.2
1.5
1.4
0.9
1.5 Routing Cost (normalized)
n=10; C4 =0.1, C5 =0.9
10
C1=0.2;C2=0.2;C3=0.6
0
0.7 0
C1=C2=C3
1.3
10
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
Routing Cost (normalized)
C1=C2=C3
1.3
0.9
Routing Cost (normalized)
2 4 6 8 Average Degree per Vertex
1.5
1.4
1.5
1.4
0.7 0
0.7
Routing Cost (normalized)
C1=0.6;C2=0.2;C3=0.2
1
1.5
(q)
1.1
10
n=10; C4 =0.1, C5 =0.9
(m)
C1=0.4;C2=0.2;C3=0.4
0.7 0
(e)
1.2
0.9
0.7
(a)
C1=0.4;C2=0.4;C3=0.2
Routing Cost (normalized)
C1=0.2;C2=0.6;C3=0.2
C1=0.4;C2=0.2;C3=0.2
1.3
Routing Cost (normalized)
1.2
1.5
1.4
Routing Cost (normalized)
C1=0.2;C2=0.2;C3=0.6
Routing Cost (normalized)
C1=C2=C3
1.3
Routing Cost (normalized)
1.5
1.4
Routing Cost (normalized)
Routing Cost (normalized)
1.5
258
Routing Cost (normalized)
APPENDIX A.
side) and
n
= 30
Appendix B
WiFIX Proofs In this appendix we demonstrate that the expression presented in Chapter 6 for the WiFIX overhead is valid for all
n.
Furthermore, we prove that
the ATCM me hanism does guarantee a loop free a tive topology.
B.1 Overhead Expression Demonstration The expression for WiFIX overhead, as a fun tion of
n,
is demonstrated
using the mathemati al indu tion method. Our statement is that the WiFIX overhead is de ned by:
OW iF IX (byte/s) =
ST R ·n+ TT R SA · (n − 1)2 · nST A · (P · (PB )nST A + 2· LF T (1 − P ) · PB ) (B.1)
In order to simplify the expression above we de ne two onstants
K2 : K1 = K2 = 2 ·
K1
and
ST R TT R
SA · nST A · (P · (PB )nST A + (1 − P ) · PB ) LF T
The simpli ed expression be omes:
OW iF IX (n) = K1 · n + K2 · (n − 1)2
259
(B.2)
APPENDIX B.
Proof.
WIFIX PROOFS
260
First, we prove that Expression B.2 is true for
the mesh network is omposed of the master only.
n = 1.
When
n = 1,
As su h, the overhead
introdu ed by WiFIX is only due to the periodi message sent out by the Master
OW iF IX (1) =
ST R TT R
Using Expression B.2 we get:
ST R TT R
OW iF IX (1) = K1 · 1 + K2 · (1 − 1)2 = K1 =
n = 1. Now, we need to prove that n = k + 1, assuming that it is valid for n = k.
The expression then holds for expression is valid for su h, for
n=k
the As
we get:
OW iF IX (k) = K1 · k + K2 · (k − 1)2 For
n=k+1
we have:
OW iF IX (k + 1) = K1 · (k + 1) + K2 · k2 But,
OW iF IX (k + 1)
an also be de ned as a fun tion of
(B.3)
OW iF IX (k)
OW iF IX (k + 1) = OW iF IX (k + 1) + K1 + K2 · (k − 1) + K2 · k Expression B.4 represents the overhead introdu ed by
k
(B.4)
mesh nodes plus
the additional overhead introdu ed by the insertion of a new mesh node in the network. A new node means that the one more time (K1 ).
TT R
message will be retransmitted
In addition, the broad ast sent out by ea h node
when no forwarding table entry exists for a given destination also rea hes the
(k + 1)th
mesh node. On the other hand, a broad ast message sent out
by the Master when there is no forwarding table entry available rea hes one more mesh node and the orresponding STAs behind it; this is represented by the term
k+1
K2 · (k − 1).
The ontribution for the overall overhead by the
mesh node is given by
K2 · k.
Expression B.4 an be simpli ed in order to prove that it leads to the same result obtained using Expression B.3
OW iF IX (k + 1) = K1 · k + K2 · (k − 1)2 + K1 + K2 · (k − 1) + K2 · k = K1 · (k + 1) + K2 · k2 − 2 · K2 · k +K2 + K2 · k − K2 + K2 · k = K1 · (k + 1) + K2 · k2 Thus, the expression holds for all
n.
APPENDIX B.
WIFIX PROOFS
261
1 m1,2
mv+1,1 v+1
2
mv,v+1
m2,3
….
3
v
Figure B.1: Ring graph used as a basis to prove the loop free a tive topology
reated by the ATCM me hanism.
B.2 Loop Free Topology Demonstration We now prove that the ATCM me hanism used in WiFIX to reate the a tive topology always ensures a loop free topology.
Proof.
In ATCM, ea h MAP sele ts one and only one parent node at a time
in the tree rooted at the master MAP. As su h, a loop an only o
ur if a
y li parent sele tion takes pla e. We prove that this never happens using the
redu tio ad absurdum
method.
Consider the ring graph illustrated in Fig. B.1, where
(i, j), mi,j > 0, ∀i, j ∈ V .
assigned to the edge
mj,i ),
and
mi,j
mi,j
is the metri
is assumed to be symmetri (i.e.,
mi,j =
The verti es represent the MAPs and the
edges represent the possible virtual links that may be established between neighbor MAPs.
Remember that in ATCM ea h MAP sele ts the parent
with lowest metri towards the root MAP. Without loss of generality, we
onsider vertex 1 as example; exa tly the same reasoning an be applied to any other vertex in the ring. Let
M1
be the best metri vertex 1 ould
nd so far. It orresponds to the sele tion of a parent that does not belong to the ring and it is in luded by vertex 1 in the
TR
it retransmits.
order to form a loop, a y li parent sele tion must o
ur.
In
In su h ase,
the following onditions shall be satis ed. Vertex 2 sele ts vertex 1 has its parent, be ause
M1 + m1,2
is the best metri found. The same happens with
M1 + m1,2 + m2,3 is the sele ts vertex v as parent,
vertex 3, whi h sele ts vertex 2 as its parent, be ause best metri found, and with vertex sin e
v + 1,
M1 + m1,2 + m2,3 + · · · + mv,v+1
whi h
is lower than any other metri value
APPENDIX B.
WIFIX PROOFS
v + 1 as its parent the loop. However, M1 + m1,2 + m2,3 + · · · + mv,v+1 + mv+1,1 < M1 sin e mi,j > 0, ∀i, j ∈ V . known so far. Finally, vertex 1 must sele t vertex
262
to form is false,
Thus, we on lude that a y li parent sele tion never o
urs and, as su h, a loop is never formed by ATCM.
Appendix C
PBC and SBC Evaluation: Further Details This appendix provides details on the messages ex hanged in the PBC/SBC and trial-and-error me hanisms, together with the message sizes onsidered in the evaluation and the PBC/SBC overhead normalized to the overhead of the trial-and-error me hanism, when the ontribution of ea h me hanism is solely onsidered. The information is valid for both PBC and SBC, sin e they are based on the same fundamental pro edures.
C.1 Messages Ex hanged and Normalized Overhead Below, we provide a set of tables in luding the messages ex hanged by ea h me hanism for ea h spe i lega y IP auto- on guration me hanism a tually used. For ea h message its size and the orresponding number of transmissions is provided; the message sizes are a
ording to the spe i ations or a
ording to the typi al sizes found in pra ti e when standards leave values as open. The PBC/SBC normalized overhead is presented taking into a
ount the number of bytes and the number of frames ex hanged. The rst three tables are appli able to both PBC and SBC; the last two are only appli able to PBC.
263
APPENDIX C.
Me hanism
Trial-and-error
PBC/SBC
PBC AND SBC EVALUATION
Message DHCP DISCOVER DHCP OFFER DHCP REQUEST DHCP ACK ARP REQUEST Neighbor Sol. MLD report Router Sol. DHCPv6 Sol. Proposal Agreement DHCP DISCOVER DHCP OFFER DHCP REQUEST DHCP ACK ARP REQUEST
264
No. of transmissions
Message Size
1 1 1 1 3 3 2 3 3 1 1 1 1 1 1 3
321 368 365 302 28 64 126 56 176 11 10 321 368 365 302 28
Normalized Overhead bytes
frames
0.57
0.50
Table C.1: Messages ex hanged by ea h me hanism when DHCPv4 is a tually used and the orresponding PBC/SBC normalized overhead.
Me hanism
Trial-and-error
PBC/SBC
Message MLD report Neighbor Sol. Router Sol. Router Adv. DHCP Sol. DHCP Adv. DHCP Request DHCP Reply MLD report Neighbor Sol. DHCP DISCOVER ARP REQUEST Proposal Agreement MLD report Neighbor Sol. Router Sol. Router Adv. DHCP Sol. DHCP Adv. DHCP Request DHCP Reply MLD report Neighbor Sol.
No. of transmissions
Message Size
2 3 1 1 1 1 1 1 2 3 3 3 1 1 2 3 1 1 1 1 1 1 2 3
126 64 56 104 176 221 198 241 126 64 321 28 11 10 126 64 56 104 176 221 198 241 126 64
Normalized Overhead bytes
frames
0.65
0.82
Table C.2: Messages ex hanged by ea h me hanism when DHCPv6 is a tually used and the orresponding PBC/SBC normalized overhead.
APPENDIX C.
Me hanism
Trial-and-error
PBC/SBC
Table C.3:
PBC AND SBC EVALUATION
Message MLD report Neighbor Sol. Router Sol. Router Adv. MLD report Neighbor Sol. DHCP DISCOVER ARP REQUEST Proposal Agreement MLD report Neighbor Sol. Router Sol. Router Adv. MLD report Neighbor Sol.
265
No. of transmissions
Message Size
2 3 1 1 2 3 3 3 1 1 2 3 1 1 2 3
126 64 56 104 126 64 321 28 11 10 126 64 56 104 126 64
Normalized Overhead bytes
frames
0.51
0.78
Messages ex hanged by ea h me hanism when IPv6 SLAC is
a tually used and the orresponding PBC/SBC normalized overhead.
Me hanism
Trial-and-error
PBC
Message DHCP DISCOVER ARP REQUEST Neighbor Sol. MLD report Router Sol. DHCPv6 Sol. Proposal Agreement ARP REQUEST
No. of transmissions
Message Size
3 3 3 2 3 3 1 1 3
321 28 64 126 56 176 11 10 28
Normalized Overhead bytes
frames
0.05
0.29
Table C.4: Messages ex hanged by ea h me hanism when DynLL is a tually used and the orresponding PBC normalized overhead.
Me hanism
Trial-and-error
PBC/SBC
Message MLD report Neighbor Sol. Router Sol. DHCP Sol. DHCP DISCOVER ARP REQUEST Proposal Agreement MLD report Neighbor Sol.
No. of transmissions
Message Size
2 3 3 3 3 3 1 1 2 3
126 64 56 176 321 28 11 10 126 64
Normalized Overhead bytes
frames
0.21
0.41
Table C.5: Messages ex hanged by ea h me hanism when IPv6 LL is a tually used and the orresponding PBC normalized overhead.
Appendix D
Pure Flooding Expression This appendix demonstrates that the ooding expression used in Chapter 6 is valid for all
davg
and
n.
D.1 Expression Demonstration The ooding expression is demonstrated using the mathemati al indu tion method. Our statement is that the number of pa kets transmitted per broad ast pa ket is de ned by:
Np (n, davg ) = (davg − 1) · n + 1,
Proof.
First, we onsider
Expression D.1 is true for
∀n ≥ 2, davg ≥ 1
(D.1)
davg as the indu tion variable. We prove that davg = 1. When davg = 1, ea h node has a single
interfa e. Two s enarios may o
ur: 1) the network is omposed by 2 nodes only; 2) all nodes are onne ted to a shared medium. In both ases, only the transmitter sends out a broad ast pa ket, i.e.,
Np = 1.
Using Expression D.1 we get:
Np (n, 1) = (1 − 1) · n + 1 = 1 davg = 1. Now, we = k + 1, assuming that
The expression then holds for expression is valid for For
davg = k
davg
need to prove that the it is valid for
davg = k.
we get:
Np (n, k) = (k − 1) · n + 1 For
davg = k + 1
we have:
Np (n, k + 1) = (k + 1 − 1) · n + 1 = k · n + 1 267
(D.2)
APPENDIX D.
But,
PURE FLOODING EXPRESSION
Np (n, k + 1)
an also be de ned as a fun tion of
268
Np (n, k)
Np (n, k + 1) = Np (n, k) + n where
n
(D.3)
is the sum of the additional pa kets transmitted when
davg
is in-
reased by 1. Expresion D.3 an be simpli ed in order to prove that it leads to the same result got using Expression D.2.
Np (n, k + 1) = (k − 1) · n + 1 + n = n · (k − 1 + 1) + 1 = k · n + 1 Thus, the expression holds for all
n
We now onsider D.1 is true for
n = 2.
davg .
as the indu tion variable. We prove that Expression
When
n = 2,
ea h node has a single interfa e. As seen
above, in this ase only the transmitter sends out a broad ast pa ket, i.e.,
Np = 1. Using Expression D.1 we get:
Np (2, davg ) = (davg − 1) · 2 + 1 = 1 sin e
n = 2 ⇒ davg = 1.
The expression then holds for
that Expression D.1 is valid for
n = k + 1.
For
n=k
n = k,
n = 2.
Assuming
we need to prove that it is valid for
we get:
Np (k, davg ) = (davg − 1) · k + 1 For
n=k+1
we have:
Np (k + 1, davg ) = (davg − 1) · (k + 1) + 1 But, again,
Np (k + 1, davg )
an be de ned as a fun tion of
(D.4)
Np (k, davg )
Np (k + 1, davg ) = Np (k, davg ) + (davg − 1) where the term
(davg − 1)
(D.5)
is due to the new node added to the network.
Expression D.5 an now be simpli ed, so that we prove that it provides the same result obtained using Expression D.4.
Np (k + 1, davg ) = (davg − 1) · k + 1 + (davg − 1) = (davg − 1) · (k + 1) + 1 Thus, the expression also holds for all
n.
Appendix E
NS-2 Simulations: Further Results In this appendix we present further NS-2 simulation results on the number of
Route Request
E.1
ollisions when using AODV-DR for path on guration.
Route Request
Collisions
Fig. E.1 shows the number of number of NICs per node,
Route Request
AN ICs ,
ollisions when the average
and the number of pairs ommuni ating
simultaneously is varied. These plots are intended to support the throughput results presented in Chapter 6. The values plotted in Figs. E.1 E.1f were obtained for TCP ows starting at dierent instants of time. The number of ollisions in reases as
n, np,
and the density of the links
between PAN nodes in rease. The average number of hops between two given nodes is dire tly proportional to
n.
The higher average number of hops the
higher the probability of ollisions for
Route Request
messages, sin e the
messages have to travel through more hops; this explains why the number of
Route Request
ollisions in reases with
n.
On the other hand, if there are
more pairs of nodes a tive, there is a higher number of pa kets traveling in the network, whi h an potentially ollide with the
Route Request
messages.
Finally, if the density of the network is higher, there are more possible paths for the
Route Request
messages. This generates more
sages in the network, due to the
Route Request
Route Request
forwarding strategy followed
by AODV-DR. So, again the probability of ollision in reases.
269
mes-
NS-2 SIMULATIONS: FURTHER RESULTS
30
No. of RREQ Collisions
No. of RREQ Collisions
APPENDIX E.
25 20 15 10 5 0 1
1.5
2
2.5
3
30 25 20 15 10 5 0
3.5
1
Average No. of NICs per Node
20 15 10 5 0 1
15 10 5 0 1
1.5 2 2.5 3 3.5 Average No. of NICs per Node
(e) n = 10, np = 4 Figure E.1:
Number of
Route Request
3.5
20 15 10 5 0 1
1.5 2 2.5 3 3.5 Average No. of NICs per Node
(d) n = 20, np = 2
No. of RREQ Collisions
No. of RREQ Collisions
20
3
25
( ) n = 10, np = 2
25
2.5
30
1.5 2 2.5 3 3.5 Average No. of NICs per Node
30
2
(b) n = 20, np = 1
No. of RREQ Collisions
No. of RREQ Collisions
25
1.5
Average No. of NICs per Node
(a) n = 10, np = 1
30
270
30 25 20 15 10 5 0 1
1.5 2 2.5 3 3.5 Average No. of NICs per Node
(f) n = 20, np = 4
ollisions for 10-node and 20-node
PANs, when the average number of NICs per node and the number of pairs
ommuni ating simultaneously is varied.
Referen es [3GP℄
3GPP. Universal Mobile Tele ommuni ations System. http://www.3gpp.org/arti le/umts, 2010 [September 27, 2010℄.
[A+ 07℄
B. Aboba et al. Link-Lo al Multi ast Name Resolution (LLMNR). IETF RFC 4795, January 2007.
[a ℄
IEEE P802.11 Task Group a . Status of proje t IEEE 802.11a . Internet: http://www.ieee802.org/11/Reports/tga _update.htm [September 27, 2010℄.
[ad℄
IEEE P802.11 Task Group ad. Status of proje t IEEE 802.11ad. Internet: http://www.ieee802.org/11/Reports/tgad_update.htm [September 27, 2010℄.
[All℄
WiMedia Allian e. WiMedia Allian e O ial web site. http://www.wimedia.org, 2010 [September 27, 2010℄.
[All08℄
WiMedia Allian e. How it Works: UWB, WPAN and WiMedia Radio Spa e. White Paper, August 2008.
[ASBF08℄
D. Allan, P. Smith, N. Bragg, and D. Fedyk. Provider Link State Bridging. IEEE Communi ations Magazine, vol. 10, pp. 110-117, September 2008.
[AW05℄
I. Akyildiz and X. Wang. A Survey on Wireless Mesh Networks. IEEE Radio Communi ations, vol. 43, pp. S23-S30, September 2005.
[AWD04℄
M. Abolhasan, T. Wyso ki, and E. Dutkiewi z. A review of routing proto ols for mobile ad ho networks. Adho Networks, vol. 2, pp. 1-22, January 2004.
[Ba 98℄
F. Ba kes. Transparent Bridges for Inter onne tion of IEEE 802 LANs. IEEE Network, vol. 2, pp. 5-9, January 1998.
[BCF05℄
N. Bouli ault, G. Chelius, and E. Fleury. Ana4: a 2.5 Framework for Deploying Real Multi-hop Ad ho and Mesh Networks. Ad Ho & Sensor Wireless Networks: an International Journal, vol. 2, pp. 1159-1169, 2005.
[BCGP06℄
R. Bruno, M. Conti, E. Gregori, and A. Pinizzotto. A Layer-2 Ar hite ture for Inter onne ting Multi-hop Hybrid Ad Ho Networks to the Internet. Pro eedings of the Third Annual Conferen e on Wireless On demand Network Systems and Servi es (WONS 2006), January 2006.
[BCM10℄
C. Bernardos, M. Calderon, and H. Moustafa. Survey of IP address auto on guration me hanisms for MANETs. Internet draft, draft-bernardos-manetauto onf-survey-05 (work in progress), June 2010. 271
Internet:
Internet:
REFERENCES
272
[Bel58℄
R. Bellman. On a Routing Problem. Quarterly of Applied Mathemati s, vol. 16, pp. 87-90, 1958.
[C+ 07℄
I. Chakeres et al. Mobile Ad ho Network Ar hite ture. Internet draft, draft-ietf-auto onf-manetar h-07 (work in progress), November 2007.
[C+ 10℄
T. Clausen et al. Mobile Ad Ho Network (MANET) Neighborhood Dis overy Proto ol (NHDP). Internet draft, draft-ietf-manet-nhdp-12 (work in progress), Mar h 2010.
[CAG05℄
S. Cheshire, B. Aboba, and E. Guttman. Dynami Con guration of IPv4 Link-Lo al Addresses. IETF RFC 3927, May 2005.
[Cama℄
Rui Campos. Log les. http://tele om.ines porto.pt/∼r ampos/frameCaps.zip, 2010℄.
Internet: [September 27,
[Camb℄
Rui Campos. Personal web site. http://tele om.ines porto.pt/∼r ampos/software.php, 2010 [September 27, 2010℄.
Internet: September 27,
[CB02℄
I. Chakeres and L. Berndt. AODVjr, AODV simpli ed. ACM SIGMOBILE Mobile Computing and Communi ations Review, vol. 6, pp. 100-101, July 2002.
[CC07℄
R. Calvo and J. Campo. Adding Multiple Interfa e Support in NS-2. NS-2 Tutorial, January 2007.
[CDA08℄
T. Clausen, C. Dearlove, and B. Adamson. Jitter Considerations in Mobile Ad Ho Networks (MANETs). IETF RFC 5148, February 2008.
[CDJ10℄
T. Clausen, C. Dearlove, and P. Ja quet. The Optimized Link State Routing Proto ol version 2. Internet draft, draft-ietf-manet-olsrv2-11 (work in progress), April 2010.
[CDS+ 09℄
R. Campos, R. Duarte, F. Sousa, M. Ri ardo, and J. Ruela. WiFIX: A New Solution for 802.11-based Wireless Mesh Networks. Pro eedings of the 9th Conferen e on Computer Networks (CRC'09), O tober 2009.
[CDS+ 11℄
R. Campos, R. Duarte, F. Sousa, M. Ri ardo, and J. Ruela. Network Infrastru ture Extension Using 802.1D-based Wireless Mesh Networks. Wireless Communi ations and Mobile Computing, vol. 11, pp. 67-89, January 2011.
[Chr10℄
J. Chrobo zek. The Ad Ho Con guration Proto ol. Internet draft, draft hrobo zek-ah p-00 (work in progress), August 2010.
[CJ03℄
T. Clausen and P. Ja quet. Optimized Link State Routing Proto ol (OLSR). IETF RFC 3626, O tober 2003.
[CK10℄
S. Cheshire and M. Kro hmal. Multi ast DNS. Internet draft, draft- heshirednsext-multi astdns-11 (work in progress), Mar h 2010.
[CO97℄
D. Cro ker and P. Overell. Augmented BNF for Syntax Spe i ations: ABNF. IETF RFC 2234, November 1997.
[Con℄
WirelessHD Consortium. WirelessHD O ial web site. http://www.wirelesshd.org, 2010 [September 27, 2010℄.
Internet:
REFERENCES
273
[Con07℄
WirelessHD Consortium. WirelessHD Spe i ation Version 1.0 Overview, O tober 2007.
[CP10℄
I. Chakeres and C. Perkins. Dynami MANET On-demand (DYMO) Routing. Internet draft, draft-ietf-manet-dymo-21 (work in progress), July 2010.
[CR05℄
R. Campos and M. Ri ardo. Auto on guration and Self-management of Personal Area Networks: a New Framework. Pro eedings of the 15th Meeting of the Wireless World Resear h Forum, De ember 2005.
[CR06℄
R. Campos and M. Ri ardo. Dynami and Automati Conne tion of Personal Area Networks to the Global Internet. Pro eedings of the ACM International Wireless Communi ations and Mobile Computing Conferen e 2006 (IWCMC'06) Wireless LANs and Wireless PANs (Wireless Networking), July 2006.
[CR08℄
R. Campos and M. Ri ardo. A fast algorithm for omputing minimum routing ost spanning trees. Computer Networks, vol. 52, pp. 3229-3247, De ember 2008.
[CR09℄
R. Campos and M. Ri ardo. A New E ient Me hanism for Establishing IP Conne tivity between Ambient Networks. Pro eedings of the IEEE International Conferen e on Communi ations 2009 (ICC 2009), June 2009.
[CR10℄
R. Campos and M. Ri ardo. An e ient me hanism for establishing IP
onne tivity in next-generation networks. International Journal of Communi ation Systems, vol. 23, pp. 817840, June 2010.
[Cra98℄
M. Crawford. Transmission of IPv6 Pa kets over Ethernet Networks. IETF RFC 2464, De ember 1998.
[CSM09℄
L. Cai, X. Shen, and J. Mark. E ient MAC Proto ol for Ultra-Wideband Networks. IEEE Communi ations Magazine, vol. 10, pp. 179-185, June 2009.
[CVS06℄
T. Chown, S. Venaas, and C. Strauf. Dynami Host Con guration Proto ol (DHCP): IPv4 and IPv6 Dual-Sta k Issues. IETF RFC 4477, May 2006.
[D+ 03℄
R. Droms et al. Dynami Host Con guration Proto ol for IPv6 (DHCPv6). IETF RFC 3315, July 2003.
[DDH+ 10℄
A. Durand, R. Droms, B. Haberman, J. Woodyatt, and Y. Lee. Dual-sta k Lite Broadband Deployments Following IPv4 Exhaustion. Internet draft, draft-ietf-softwire-dual-sta k-lite-06 (work in progress), August 2010.
[Dij59℄
E. Dijkstra. A note on two problems in onnexion with graphs. Numeris he Mathematik, vol. 1, pp. 269-271, De ember 1959.
[DPZ04℄
R. Draves, J. Padhye, and B. Zill. Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks. Pro eedings of Mobi om'04, pp. 114-128, O tober 2004.
[Dro97℄
R. Droms. Dynami Host Con guration Proto ol. IETF RFC 2131, Mar h 1997.
[ECE07℄
K. Elmeleegy, A. Cox, and T. Eugene. Etherfuse: an ethernet wat hdog. Pro eedings of ACM SIGCOMM, pp. 253-264., August 2007.
REFERENCES
274
[ECM05℄
ECMA. High Rate Ultra Wideband PHY and MAC Standard. ECMA Standard, ECMA-368, De ember 2005.
[Eng05℄
P. Engelstad. Towards the Realization of IP-based Personal Area Networks with On-Demand Routing. PhD, University of Oslo, Oslo, 2005.
[ER59℄
P. Erdos and A. Renyi. On random graphs. Publi ationes Mathemati ae Debre en, vol. 6, pp. 290297, 1959.
[FF62℄
L. Ford and D. Fulkerson. Flows in Networks. New Jersey, US: Prin eton University Press, 1962.
[FOB06℄
F. Feuli, A. Ordine, and G. Bian hi. Multiple Path Layer-2 based Routing and Load Balan ing Approa h for Wireless Infrastru ture Mesh Networks. Pro eedings of the CoNEXT 2006, De ember 2006.
[For00℄
USB Implementers Forum. Universal Serial Bus Spe i ation. Revision 2.0, April 2000.
[For05a℄
USB Implementer Forum. Wireless Universal Serial Bus Spe i ation, Revision 1.0, May 2005.
[For05b℄
USB Implementers Forum. Universal Serial Bus Communi ations Class Sub lass Spe i ation for Ethernet Emulation Model Devi es, Revision 1.0, February 2005.
[FT87℄
M. Fredman and R. Tarjan. Fibona
i heaps and their uses in improved network optimization algorithms. Journal of the ACM (JACM), vol. 34, pp. 596-615, July 1987.
[fWG03℄
IEEE 802.11f Work Group. Ieee Trial-Use Re ommended Pra ti e for MultiVendor A
ess Point Interoperability via an Inter-A
ess Point Proto ol A ross Distribution Systems Supporting IEEE 802.11 Operation, July 2003.
[GGIT08℄
R. Garroppo, S. Giordano, D. Ia ono, and L. Tavanti. On the development of a IEEE 802.11s Mesh Point prototype. Pro eedings of Trident om 2008, Mar h 2008.
[Gon07℄
I. González. My bandwidth is wider than yours. Pro eedings of the Linux Symposium, vol. 2, pp. 127-134, June 2007.
[Groa℄
IEEE 802.11 Work Group. O ial IEEE 802.11 Work Group Proje t Timelines. Internet: http://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm [September 27, 2010℄.
[Grob℄
IEEE 802.15 Work Group. IEEE 802.15 Working Group for WPAN. Internet: http://www.ieee802.org/15, September 23, 2010 [September 27, 2010℄.
[Gro98℄
IEEE 802.2 Work Group. Part 2: Logi al Link Control, May 1998.
[Gro02℄
IEEE 802.1 Work Group. IEEE Standard for Lo al and Metropolitan Area Networks: Overview and Ar hite ture, February 2002.
[Gro03℄
IEEE 802.15 Work Group. Part 15.3: Wireless Medium A
ess Control (MAC) and Physi al Layer (PHY) Spe i ations for High Rate Wireless Personal Area Networks (WPANs), September 2003.
REFERENCES
275
[Gro04℄
IEEE 802.1D Work Group. 802.1D Media A
ess Control (MAC) Bridges, June 2004.
[Gro05a℄
IEEE 802.15 Work Group. Part 15.1: Wireless medium a
ess ontrol (MAC) and physi al layer (PHY) spe i ations for wireless personal area networks (WPANs), June 2005.
[Gro05b℄
V. Grout. Prin iples of ost minimization in wireless networks. Journal of Heuristi s, vol. 11, pp. 115-133, Mar h 2005.
[Gro06a℄
IEEE 802.1 Work Group. 802.1Q Virtual Bridged Lo al Area Networks, May 2006.
[Gro06b℄
IEEE 802.15 Work Group. Part 15.4: Wireless Medium A
ess Control (MAC) and Physi al Layer (PHY) Spe i ations for Low-Rate Wireless Personal Area Networks (WPANs), September 2006.
[Gro07℄
IEEE 802.11 Work Group. Part 11: Wireless LAN Medium A
ess Control (MAC) and Physi al Layer (PHY) spe i ations, June 2007.
[Gro09a℄
IEEE 802.11 Work Group. IEEE 802.11s/d3.0, draft amendment to standard ieee 802.11: Mesh networking, work in progress., Mar h 2009.
[Gro09b℄
IEEE 802.11 Work Group. Part 11: Wireless LAN Medium A
ess Control (MAC) and Physi al Layer (PHY) spe i ations Amendment 5: Enhan ements for Higher Throughput, O tober 2009.
[Gro09 ℄
IEEE 802.15 Work Group. Part 15.3: Wireless Medium A
ess Control (MAC) and Physi al Layer (PHY) Spe i ations for High Rate Wireless Personal Area Networks (WPANs) Amendment 2: Millimeter-wave-based Alternative Physi al Layer Extension, O tober 2009.
[Gro09d℄
IEEE 802.15 Work Group. Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs), May 2009.
[GVT+ 06℄
F. Greve, W. Vandenberghe, F. Tur k, I. Moerman, and P. Demeester. Towards Ethernet-based wireless mesh networks for fast moving users. Pro eedings of EUROMICRO-SEAA'06, September 2006.
[HHM08℄
J. Harris, J. Hirst, and M. Mossingho. Combinatori s and Graph Theory. US: Springer, 2008.
[HKS84℄
B. Hawe, A. Kirby, and B. Stewart. Transparent Inter onne tion of Lo al Networks with Bridges. Journal of Tele ommuni ations Networks, vol. 3, pp. 116-130, O tober 1984.
[HNN04℄
D. Husemann, C. Narayanaswa, and M. Nidd. Personal Mobile Hub. Pro eedings of the 8th International Symposium on Wearable Computers, pp. 85-91, November 2004.
[Hor84℄
C. Hornig. A Standard for the Transmission of IP Datagrams over Ethernet Networks. IETF RFC 894, April 1984.
[J+ 08℄
M. Ja obsson et al. PN Se ure Networking Frameworks, Solutions and Performan e. IST-027396/MAGNET/WP2.3/DUT/D2.3.2, MAGNET Deliverable D2.3.2, September 2008.
REFERENCES
276
[JHM07℄
D. Johnson, Y. Hu, and D. Maltz. The Dynami Sour e Routing Proto ol (DSR). IETF RFC 4728, February 2007.
[JMRA07℄
U. Javaid, D. Meddour, T. Rasheed, and T. Ahmed. Personal Network Routing Proto ol (PNRP) for Personal Ubiquitous Environments. Pro eedings of ICC 2007, pp. 3100-3107, June 2007.
[JMRA08℄
U. Javaid, D. Meddour, T. Rasheed, and T. Ahmed. Mobility Management ar hite ture for Personal Ubiquitous Environments. Pro eedings of IEEE PIMRC 2008, September 2008.
[JPA04℄
D. Johnson, C. Perkins, and J. Arkko. IP Mobility Support in IPv6. IETF RFC 3775, June 2004.
[JPR+ 08℄
A. Jonsson, M. Pettersson, J. Rune, T. Larsson, and A. Méhes. Method and Proto ol for Managing Devi es in a Personal Area Network. US, 2008/0062958 A1, Mar h 2008.
[JPSS04℄
E. Johansson, K. Persson, M. Skold, and U. Sterner. AODV Routing in Ad Ho Networks with Variable Data Rates. Te hni al Report, ISSN 1650-1942, De ember 2004.
[JRP+ 06℄
A. Jonsson, J. Rune, M. Pettersson, T. Larsson, and A. Méhes. A Method and a Devi e for Providing A
ess in a Short Range Communi ation Network. US, WO 2006/036093 A1, April 2006.
[JS03℄
J. Jun and M. Si hitiu. The Nominal Capa ity of Wireless Mesh Networks. IEEE Wireless Communi ations, vol. 10, pp. 8-14, June 2003.
[KPT07℄
B. Kim, E. Park, and S. Tak. A virtual link routing s heme in the wireless home network ar hite ture supporting end-to-end seamless onne tivity. Wireless Communi ations and Mobile Computing, vol. 7, pp. 1159-1169, De ember 2007.
[Kru56℄
J. Kruskal. On the shortest spanning subtree of a graph and the traveling salesman problem. Pro eedings of the Ameri an Mathemati al So iety, vol. 7, pp. 48-50, February 1956.
[MAC+ 04℄
Luis Muñoz, Ramón Agüero, Johnny Choque, José Ángel Irastorza, Luis Sán hez, Marina Petrova, and Petri Mähönen. Empowering Next-Generation Wireless Personal Communi ation Networks. IEEE Communi ations Magazine, vol. 42, pp. 64-70, May 2004.
[Mad04℄
N. Madhvani. Poli y-driven Middleware for Personal Area Networks. MS , Imperial College, London, 2004.
[Mal98℄
G. Malkin. RIP Version 2. IETF RFC 2453, November 1998.
[ML05℄
P. Mieghem and S. Langen. In uen e of the link weight stru ture on the shortest path. Phys. Rev. E71, 056113, pp. 1-13, May 2005.
[MM05℄
P. Mieghem and S. Magdalena. Phase transition in the link weight stru ture of networks. Phys. Rev. E72, 056138, pp. 2-7, November 2005.
[MMMW01℄ K. Manousakis, A. M Auley, A. Misra, and L. Wong. Con guring an Entire Network with DCDP/DRCP. Pro eedings of the 5th Adv. Tele ommun. and Info. Dist. Res. Conf., Mar h 2001.
REFERENCES
277
[Moo06℄
N. Moore. Optimisti Dupli ate Address Dete tion (DAD) for IPv6. IETF RFC 4429, April 2006.
[Moy98℄
J. Moy. OSPF Version 2. IETF RFC 2328, April 1998.
[NMA06℄
H. Nguyen, H. Morikawa, and T. Aoyama. Personal Mesh: A Design of Flexible and Seamless Internet A
ess for Personal Area Network. IEICE Trans. Commun. vol. E89B, APRIL 2006, pp. 1-11, April 2006.
[NNSS07℄
T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Dis overy for IP version 6 (IPv6). IETF RFC 4861, September 2007.
[P+ 03℄
C. Perkins et al. Ad ho On-demand Distan e Ve tor (AODV) Routing. RFC 3561, July 2003.
[P+ 10℄
R. Perlman et al. RBridges: Base Proto ol Spe i ation. Internet draft, draft-ietf-trill-rbridge-proto ol-16 (work in progress), Mar h 2010.
[PB94℄
C. Perkins and P. Bhagwat. Highly dynami Destination-Sequen ed Distan e-Ve tor routing (DSDV) for mobile omputers. ACM SIGCOMM Computer Communi ation Review, vol. 24, pp. 234-244, O tober 1994.
[Per85℄
R. Perlman. An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN. ACM SIGCOMM Computer Communi ation Review, vol. 15, pp. 44-53, September 1985.
[Per02℄
C. Perkins. IP Mobility Support for IPv4. IETF RFC 3220, January 2002.
[Plu82℄
D. Plummer. An Ethernet Address Resolution Proto ol. IETF RFC 826, November 1982.
[Pos81℄
J. Postel. Internet Control Message Proto ol. IETF RFC 792, September 1981.
[PR07℄
C. Park and T. Rappaport. Short-Range Wireless Communi ations for NextGeneration Networks: UWB, 60 GHz Millimeter-Wave WPAN, and Zigbee. IEEE Wireless Communi ations, vol. 14, pp. 70-78, September 2007.
[Pri57℄
R. Prim. Shortest onne tion networks and some generalizations. Bell System Te hni al Journal, vol. 36, pp. 1389-1401, November 1957.
[Pro℄
AWDS Proje t. Wireless Multi-Hop Routing. http://awds.berlios.de, April 21, 2010 [September 27, 2010℄.
[PV09℄
A. Paranjpe and S. Vempala. MyMANET: A Customized Mobile Ad ho Network. Pro eedings of the 3rd ACM Workshop on Networked Systems for Delivering Regions, O tober 2009.
[Ra+ 07℄
T. Rinta-aho et al. Ambient Network Atta hment. Pro . of IST Summit 2007, July 2007.
[RBK10℄
H. Rogge, E. Ba
elli, and A. Kaplan. Pa ket Sequen e Number based ETX Metri for Mobile Ad Ho Networks. Internet draft, draft-funkfeuer-manetolsrv2-etx-01 (work in progress), Mar h 2010.
[Rem07℄
R. Rembarz. D17-h.4 Ambient Control Spa e Prototype Design. CALL4-027662-AN P2/D17-H.4, V1.0, June 2007.
Internet:
FP6-
REFERENCES
278
[RL95℄
Y. Rekhter and T. Li. A Border Gateway Proto ol 4 (BGP-4). IETF RFC 2453, Mar h 1995.
[RVC01℄
E. Rosen, A. Viswanathan, and R. Callon. Multiproto ol Label Swit hing Ar hite ture. IETF RFC 3031, January 2001.
[rWG08℄
IEEE 802.11r Work Group. Part 11: Wireless LAN Medium A
ess Control (MAC) and Physi al Layer (PHY) Spe i ations Amendment 2: Fast Basi Servi e Set (BSS), July 2008.
[S+ 05℄
K. Sethom et al. Distributed Virtual Interfa es to support intra-PAN and PAN-to-infrastru ture Conne tivity. Pro eedings of IEEE GLOBECOM 2005, pp. 3554-3558, De ember 2005.
[SH99℄
P. Srisuresh and M. Holdrege. IP Network Address Translator (NAT) Terminology and Considerations. IETF RFC 2663, August 1999.
[SIGa℄
Bluetooth SIG. Bluetooth SIG o ial web http://www.bluetooth.org, 2010 [September 27, 2010℄.
[SIGb℄
Bluetooth SIG. WiMedia Allian e Transfers Spe i ation. Internet: http://www.bluetooth. om/Bluetooth/Te hnology/Te hnology_Transfer, 2009 [August 14, 2009℄.
[SIG10℄
Bluetooth SIG. Spe i ation of the Bluetooth System (version 4.0), July 2010.
[SLA℄
J. Siek, L. Lee, and A.Lumsdaine. The Boost Graph Library (BGL). Internet: http://www.boost.org/libs/graph/do /index.html, [September 27, 2010℄.
[Sof09℄
R. So a. A Survey of Advan ed Ethernet Forwarding Approa hes. IEEE Communi ation Surveys & Tutorials, vol. 11, pp. 92-115, Mar h 2009.
[TD03℄
O. Troan and R. Droms. IPv6 Pre x Options for Dynami Host Con guration Proto ol (DHCP) version 6. IETF RFC 3633, De ember 2003.
[TGRW04℄
C. Ts hudin, R. Gold, O. Rensfelt, and O. Wibling. LUNAR: A Lightweight Underlay Network Ad-Ho Routing Proto ol and Implementation. Pro eedings of NEW2AN'04, pp. 201-206, February 2004.
[TN07℄
S. Thomson and T. Narten. IPv6 Stateless Address Auto on guration. IETF RFC 4862, September 2007.
[TRY08℄
F. Templin, S. Russert, and S. Yi. MANET Auto on guration. Internet draft, draft-templin-auto onf-dh p-11 (work in progress), February 2008.
[TZL10℄
D. Thaler, L. Zhang, and G. Lebovitz. IAB Thoughts on IPv6 Network Address Translation. IETF RFC 5902, July 2010.
[UHRD04℄
V. Untz, M. Heusse, F. Rousseau, and A. Duda. On demand label swit hing for spontaneous edge networks. Pro eedings of the ACM SIGCOMM workshop on Future dire tions in network ar hite ture, pp. 35-42, August 2004.
[V+ 07a℄
W. Vandenberghe et al. Conne tion Management over an Ethernet based Wireless Mesh Network. White Paper, August 2007.
site.
Internet:
REFERENCES
279
[V+ 07b℄
J. Vardakas et al. On the End-to-End Delay Analysis of the IEEE 802.11 Distributed Coordination Fun tion. Pro eedings of ICIMP'07, pp. 16-16, July 2007.
[VC04℄
R. Vida and L. Costa. Multi ast Listener Dis overy Version 2 (MLDv2) for IPv6. IETF RFC 3810, June 2004.
[VKT04℄
S. Vasudevan, J. Kurose, and D. Towsley. Design and Analysis of a Leader Ele tion Algorithm for Mobile Ad Ho Networks. Pro eedings of ICNP'2004, O tober 2004.
[W+ 99℄
B. Wu et al. A polynomial time approximation s heme for minimum routing
ost spanning trees. SIAM Journal on Computing, vol. 29, pp. 761-778, De ember 1999.
[WC04℄
B. Wu and K. Chao. Spanning Trees and Optimization Problems. US: Chapman & Hall, 2004.
[WHC05℄
R. Whitaker, L. Hodge, and I. Chlamta . Bluetooth s atternet formation: a survey. Ad Ho Networks, vol. 3, pp. 403450, 2005.
[Won80℄
R. Wong. Worst- ase analysis of network design problem heuristi s. SIAM Journal of Algebrai Dis rete Mathemati s, vol. 1, pp. 51-63, 1980.
[WSC08℄
G. Wu, S. Singh, and T. Chiueh. Implementation of Dynami Channel Swit hing on IEEE 802.11-based Wireless Mesh Networks. Pro eedings of 4th International Wireless Internet Conferen e (WICON'08), November 2008.
[XPN04℄
S. Xu, S. Papavassiliou, and S. Narayanan. Layer-2 multi-hop IEEE 802.11 ar hite ture: design and performan e analysis. IEE Pro eedingsCommuni ations, vol. 151, pp. 460-466, 2004.
[YKI07℄
A. Yanagisawa, T. Kato, and S. Itoh. Proposal of Layer 2 Based Approa h for Constru ting Wireless Mesh Networks. Pro eedings of the IASTED European Conferen e Internet and Multimedia Systems and Appli ations, Mar h 2007.
