compound wired/wireless internetworking with ospf filecompound wired/wireless internetworking with...

HAL Id: inria-00599086https://hal.inria.fr/inria-00599086

Submitted on 8 Jun 2011

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Compound Wired/Wireless Internetworking with OSPFJuan Antonio Cordero, Matthias Philipp, Emmanuel Baccelli

To cite this version:Juan Antonio Cordero, Matthias Philipp, Emmanuel Baccelli. Compound Wired/Wireless Internet-working with OSPF. [Research Report] RR-7642, INRIA. 2011, pp.23. �inria-00599086�

https://hal.inria.fr/inria-00599086

https://hal.archives-ouvertes.fr

appor t

de r ech er ch e

ISS

N0

24

9-6

39

9IS

RN

INR

IA/R

R--

76

42

--F

R+

EN

G

INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE

Compound Wired/Wireless Internetworking with

OSPF

Juan Antonio Cordero, Matthias Philipp, Emmanuel Baccelli.

N° 7642

June 2011

Centre de recherche INRIA Saclay – Île-de-FranceParc Orsay Université

4, rue Jacques Monod, 91893 ORSAY CedexTéléphone : +33 1 72 92 59 00

Compound Wired/Wireless Internetworkingwith OSPF

Juan Antonio Cordero∗, Matthias Philipp†, Emmanuel Baccelli‡.

Theme : COM – Systemes communicantsEquipe-Projet Hipercom

Rapport de recherche n➦ 7642 — June 2011 — 20 pages

Abstract: As wireless ad hoc networks become more deployed, there is agrowing interest for compound internetworks, that is, internetworks that containboth fixed and ad hoc networks. Routing is one of the main challenges that arisein such compound internetworks. Although specialized routing protocols existfor wired and for ad-hoc networks, and several such specialized protocols couldbe used together in a compound internetwork, it has been shown that the useof a single routing solution in the whole internetwork brings several advantages.The IETF has standardized extensions of the Open Shortest Path First (OSPF)protocol for ad hoc operation.

While previous performance evaluations of these extensions have focused onthe wireless part of the internetwork and have been mostly performed by wayof simulation tools, this paper studies practical issues of the use of a singleprotocol, extended OSPF, providing paths through a compound internetwork.In first term, it examines the behavior of OSPF in a real networking testbed.This testbed consists of an internetwork composed of 6 computers that form astatic topology, i.e., computers do not move during network lifetime. In secondterm, the overall behavior of extended OSPF, both considering standard OSPFand its MANET extension, is examined. Despite the limitations of the testbed,these experiments provide both a proof-of-concept and complementary resultscompared to prior work in the domain, which was mostly based on simulations,and focused on wireless ad hoc network scenarios only.

Key-words: OSPF, MANET, MPR, Routing, Internetwork, Compound,Testbed, Experiment

∗ INRIA Saclay – Ecole Polytechnique, [email protected]† INRIA Saclay – Ecole Polytechnique, [email protected]‡ INRIA Saclay – Ecole Polytechnique, [email protected]

Compound Wired/Wireless Internetworkingwith OSPF

Resume : A mesure que les reseaux ad hoc sans fil deviennent de plus enplus deployes, il y a un interet croissant pour des internetworks (reseaux desreseaux) hybrides, c’est-a-dire, internetworks qui contiennent la fois des reseauxad hoc et des reseaux fixes. En ce domain-la, le routage devient l’un des princi-paux defis qui se posent. Bien qu’il existe des protocoles de routage specifiquespour reseaux filieres et des reseaux ad hoc, et plusieurs de ces protocoles pour-raient etre utilises ensemble dans un internetwork hybride, il a ete montre quel’utilisation d’une seule solution de routage dans un internetwork hybride aplusieurs avantages. L’IETF a standardise trois extensions du protocole OpenShortest Path First (OSPF) ayant pour but le routage dans des reseaux ad hocet a mobilite (MANETs).

Les evaluations du rendement de ces extensions developpees jusqu’a presentse sont concentrees sur la partie sans fil (ad hoc) de l’internetwork et ont eteprincipalement effectuees a travers de simulations. Ce rapport etudie des ques-tions pratiques liees a l’usage d’un seul protocol de routage, en l’occurrenceOSPF, sur un internetwork hybride. D’abord, la performance de OSPF estanalysee avec des experiences sur un banc d’essai de reseaux (testbed). Cetestbed consiste en un internetwork hybride de 6 ordinateurs qui forment unetopologie statique, c.-a.-d. ou les ordinateurs ne bougent pas durant la vie dureseau. Deuxiemement, le comportement global du protocole OSPF etendu, ala fois sa version standard et son extension pour MANETs, est examine. Malgreles limites du testbed, ces experiences fournissent a la fois une preuve de conceptet des resultats qui confirment et completent des travaux anterieurs dans le do-maine, bases sur l’analyse du protocol sur MANETs a travers des simulations.

Mots-cles : OSPF, MANET, MPR, Routage, Internetwork, Hybride, Bancd’essai, Experience

Compound Wired/Wireless Internetworking with OSPF 3

Contents

1 Introduction 41.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Paper Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 The OSPF Protocol and its MANET Extension 52.1 Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Interface Types for Wired Links . . . . . . . . . . . . . . . . . . . 62.3 MANET Interface Type . . . . . . . . . . . . . . . . . . . . . . . 6

3 Testbed Description 73.1 Interfaces Configuration and Network Topology . . . . . . . . . . 7

3.1.1 Physical Topology . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Logical Internetwork Topology . . . . . . . . . . . . . . . 8

3.2 OSPF Routing Configuration . . . . . . . . . . . . . . . . . . . . 83.2.1 OSPF Adjacencies and MPRs . . . . . . . . . . . . . . . . 83.2.2 OSPF Flooding . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Experiments and Results 94.1 Wireless Multi-hop Communication . . . . . . . . . . . . . . . . . 104.2 OSPF Control Traffic Pattern . . . . . . . . . . . . . . . . . . . . 11

4.2.1 Hello Packets . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.2 LSDB Synchronization . . . . . . . . . . . . . . . . . . . . 134.2.3 Link State Updates, Requests and Acknowledgements . . 14

5 Conclusion 15

A APPENDIX 19A.1 Testbed Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 19A.2 Testbed Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 19A.3 Setup for PDR and RTT Measures . . . . . . . . . . . . . . . . . 19A.4 Setup for Control Traffic Measures . . . . . . . . . . . . . . . . . 19A.5 OSPF Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 19

RR n➦ 7642

4 J.A. Cordero, M. Philipp, E. Baccelli

1 Introduction

Since the Internet Engineering Task Force (IETF) defined in 1997 the conceptof Mobile Ad hoc Networks (MANETs), several research efforts have focusedon enabling communication in wireless multi-hop networks in which topology isspontaneous and dynamic. As a result of such efforts, different routing protocolshave been designed for MANET operation, the most prominent to date beingthe OLSR [12] and AODV [14].

This paper studies the case of Autonomous Systems (AS) containing bothad hoc and fixed networks – such an AS is hereafter denominated compoundAS. An approach for routing in a compound AS consists in splitting the AS intoseveral routing domains, and then using a routing protocol for each domain:MANET-specific protocols in ad hoc networks, other existing protocols for fixednetworks. An alternative approach consists of using a single routing protocolfor the whole AS – ad hoc and fixed networks considered together. The formerapproach requires the presence in the AS of routers with specific hardware andsoftware capabilities, denominated gateways, in order to provide connectivitybetween different routing domains. The latter approach, explored in this paper,reduces the cost of network maintenance and operation as no such gateways areneeded, as explained in [1]. This is, however, at the expense of increasing thecomplexity of the employed routing protocol, which in this case needs to handlethe diverse characteristics of MANETs and fixed networks with the same coremechanisms.

To date [16], two major protocols are used in the Internet for IGP routing:the Open Shortest Path First protocol (OSPF, specified in RFCs 2328 [17] and5340 [9]) and the Intermediate-System-to-Intermediate-System protocol (IS-IS,RFC 1142 [18]). This paper explores the use of OSPF for routing in compoundASes, by way of evaluating its performance in a testbed consisting in a smallcompound internetwork.

1.1 Related Work

Several extensions of OSPF for MANET operation have recently been proposedand analyzed. Early studies and proposals such as [13] [20] paved the wayto IETF standardizing several OSPF protocol extensions for operation overad hoc networks [8] [5] [7]. Various studies have evaluated and compared theperformance of these extensions in mobile ad hoc scenarios [6, 11, 21], mostly viasimulations. Further improvements of these extensions have been proposed in[2, 3], still comparatively evaluated via simulations in MANET only scenarios.In contrast, this paper evaluates OSPF on a real testbed, consisting in both adhoc networks and fixed wired networks.

1.2 Paper Outline

In the experiments described thereafter, all router interfaces run OSPF – in-terfaces attached to the wired network use the OSPF point-to-point interfacespecified in [9, 17], while wireless interfaces use the MANET interface type ofthe OSPF protocol extension specified in [8]. Analysis of the behavior of ex-tended OSPF on such a testbed confirms results obtained in simulation-basedstudies. In particular, this paper concentrates on the effect of wireless links on

INRIA


data path quality, on managing their coexistence with wired links in the sameinternetwork, as well as the impact of wireless links on overall OSPF controltraffic.

Section 2 introduces the basics of OSPF and its extension for MANET op-eration, both used in the testbed. Section 3 describes the main characteristicsof the testbed, the internetwork topology and the configuration of the partic-ipating network interfaces. Section 4 presents the performed experiments andthe most significant results. Finally, section 5 concludes the paper.

2 The OSPF Protocol and its MANET Exten-sion

OSPF [9, 17] is a link-state routing protocol for IP networks. This implies thateach router maintains a local instance of the Link-State Database (LSDB), rep-resenting the full network topology – with the objective of the protocol beingthat each router should have the same information in its local instance of LSDBand, thus, the exact same view of the network topology. Paths to every possibledestination are derived from the Shortest Path Tree (SPT) that every routercomputes, by way of Dijkstra’s algorithm [19]. OSPF supports network parti-tioning in several areas, in a way such that topology information maintained bydifferent routers (the LSDB from which they maintain local instances) is thesame if they belong to the same area. Throughout this document, however, asingle area is configured in the internetwork.

Routers acquire local topology information and advertise their own pres-ence by periodically exchanging Hello messages with all their 1-hop neighbors(i.e. neighbor sensing). With such signaling, each router becomes aware ofits immediate network topology, i.e. its 2-hop neighborhood. This also allowsverification of bidirectional connectivity with 1-hop neighbors (then called bidi-rectional neighbors). The set of symmetric 1-hop neighbors of a router x aredenoted by N(x), whereas the set of symmetric 2-hop neighbor are denoted byN2(x).

Each router also explicitly synchronizes its local instance of LSDB with asubset of its bidirectional neighbors. Links between a router and its synchro-nized neighbors are called adjacencies, and are required to form a network-wideconnected backbone, connecting all routers in the network, in order to ensurepaths can be computed correctly.

Finally, routers also acquire remote topology information by way of receivingLink State Advertisements (LSA). Each such LSA lists mainly the current adja-cencies of the router which generated the LSA. LSAs are disseminated throughthe entire network in reliable fashion (explicit acknowledgements and retrans-missions) via the backbone formed by adjacencies; this operation is called LSAFlooding. Thus, any router which has formed adjacencies must advertise thisperiodically by way of originating an LSA and performing LSA flooding.

Remote topology information is then used for the construction of the Short-est Path Tree: each router computes the shortest paths over the network graphdescribed in the set of received LSAs it, by way of Dijkstra’s algorithm.

According to this structure, OSPF distinguishes several types of links: asubset of bidirectional links become adjacent, among which a new subset is

RR n➦ 7642


selected to be part of the SPT. While data traffic is routed on the SPT, controltraffic is sent over adjacent links.

2.1 Packet Types

Routers in OSPF use five types of messages and packets to exchange topologyinformation over the networks, some of them have been already mentioned inthis section: Hello packets are used for neighbor sensing, Database Description(DBDesc) packets are exchanged for LSDB synchronization and Link State Ad-vertisements (LSAs) are used for topology reliable flooding and update. Afterthe exchange of DBDesc packets, a router in process of LSDB synchronizationmay request to its synchronizing neighbor the retransmission of particular LSAs– these requests are sent by way of Link State Request (LSReq) packets. Sev-eral LSAs may be sent in a single Link State Update packet (LSU). Several LSAacknowledgements may also be grouped in a single Link State Acknowledgment(LSAck) packet.

2.2 Interface Types for Wired Links

Rules for flooding and adjacency handling vary for the different interface typessupported by OSPF. In broadcast and non-broadcast multiple access (NBMA)interfaces, the flooding procedure is mainly managed by Designated Routers(DRs). A Designated Router is elected from among routers whose interfacesare connected to the same link. Such a DR forms adjacencies with all therouters connected to the same link, and it becomes responsible for floodingof LSAs, originated by routers on that link. In point-to-point and point-to-multipoint interfaces, all links are synchronized and all interfaces participate inLSA flooding.

2.3 MANET Interface Type

The MANET interface type is defined in the extension of OSPF for operationover MANETs. Three different extensions have been standardized by the IETF[5, 7, 8], each of which specifies mechanisms to optimize topology description,flooding and LSDB synchronization in wireless ad hoc environments.

The experiments carried out used RFC 5449 [8]. Wireless interfaces followingthis specification select a set of Multi-Point Relays (MPRs) among its bidirec-tional neighbors [12, 15]. The set of MPRs selected by the wireless interface ofa router must ensure that every packet received from the router reach all 2-hopneighbors of the selecting interface in 2 hops (MPR coverage criterion). A linkbetween a router and one of its MPRs is denominated MPR link.

LSA flooding is then performed through MPRs, meaning that an LSA trans-mitted (originated or forwarded) by an interface is retransmitted by the MPRsof such interface. Links between interfaces and their MPRs are synchronizedand thus become adjacent. Moreover, each interface describes in its LSAs theset of MPRs and MPR selectors. As the set of adjacencies based on MPR se-lection may not provide a connected subgraph, links from one additional routerin the network (denominated synch router) are also declared adjacent to ensureadjacency set connection [4]. The Shortest Path Tree is then constructed overthe set of adjacencies.

INRIA


3 Testbed Description

This section describes the characteristics of the employed networking testbed.Section 3.1 presents the distribution of computers in the testbed and the networktopology that they form. Section 3.2 details the implications of such topologyin OSPF routing.

3.1 Interfaces Configuration and Network Topology

The testbed is composed of 6 fixed computers (routers/hosts) attached to twointerconnected networks: a wired network and a wireless network. Table 1indicates the network interfaces of each computer. For more details about com-puters’ hardware, see Appendix A.1.

Computer Abbr. Wired ifs. Wireless ifs.

server S eth0, eth1 –

hybrid1 h1 eth0 wlan0

hybrid2 h2 eth0 wlan0

wless1 w1 – wlan0

wless2 w2 – wlan0

wless3 w3 – wlan0

Table 1: Network interfaces of testbed computers.

3.1.1 Physical Topology

The internetwork connecting these computers was deployed in the ComputerScience Lab (Laboratoire d’Informatique, LIX) of Ecole Polytechnique, in Paris(France). Three scenarios –I, II and III– were configured over the resultinginternetwork. These scenarios permit to test the communication between com-puters wless3 and server, for different situations. The physical distribution ofcomputers at LIX is displayed in Figure 1.

Sh1

h2 w2

w1

w3

w3

(II, III)

(I)

10 m

Figure 1: Computers position over the plan of LIX.

Positions of computers do not change, except for the case of wless3, whichhas a different position for scenario I and for scenarios II and III, as shown inFigure 1.

RR n➦ 7642


3.1.2 Logical Internetwork Topology

Each scenario corresponds to a specific internetwork topology. Figure 2 indicatesthe internetwork topology graphs for scenarios I, II and III. In the wired network,computers communicate through the IEEE 802.3 (Ethernet) standard protocol,server is connected with hybrid1 by way of interface eth0 and with hybrid2

by way of interface eth1, as shown in Figure 2. In the wireless network, inter-faces communicate through the IEEE 802.11b WLAN standard protocol, andall wireless routers (hybrid1, hybrid2, wless1, wless2 and wless3) use theirwireless interface wlan0. The topology that results from wireless reachabilityamong computers hybrid1, hybrid2, wless1, wless2 and wless3 is modifiedby means of MAC filtering in order to disable links h1 ←→ h2, w1,3 ←→ w2,w1,3 ←→ h2 and w2 ←→ h1, as well as h1 ←→ w1 for scenario III.

S

h1 h2

w2

w3

eth0

eth0 eth1

eth0

wlan0 wlan0

wlan0

wlan0

S

h1 h2

w2

w3

w1

eth0

eth0 eth1

eth0

wlan0 wlan0

wlan0 wlan0

wlan0

I IIS

h1 h2

w2

w3

w1

eth0

eth0 eth1

eth0

wlan0

wlan0 wlan0

wlan0

III

Figure 2: Considered topologies for scenarios I, II and III.

3.2 OSPF Routing Configuration

All interfaces use the extended OSPFv3 routing protocol, wired and wirelessinterfaces using different interface types. Wired interfaces are configured aspoint-to-point interfaces, as they are specified in RFCs 2328 [17] and 5340 [9].Wireless interfaces are configured as MANET interfaces, as specified in theMPR-OSPF MANET extension for OSPF (RFC 5449 [8]).

3.2.1 OSPF Adjacencies and MPRs

According to the specification of OSPF and MPR-OSPF extension, all links inany of the considered topologies for scenarios I, II and III are adjacent. Withinthe wired network, every point-to-point link is an adjacency. In the wireless

INRIA


network, wireless links are adjacent if they are MPR links. The list of MPRs ofevery wireless interface, for each scenario, is displayed in Table 2.

Interface I II III

hybrid1:wlan0 w1 w1 –

hybrid2:wlan0 w2 w2 w2

wless1:wlan0 – w2 w2

wless2:wlan0 w3 w1 w1

wless3:wlan0 w2 w1 w1

Table 2: MPRs selected by each wireless interface, for each scenario.

It can be observed that all links are MPR links, and therefore all are adja-cent. In this topology, the presence of a synch router (see section 2.3) is thusredundant.

3.2.2 OSPF Flooding

Flooding in the wired network is performed through adjacent links – that means,S ←→ h1 and S ←→ h2. In the wireless network, flooding is performed:

❼ through the MPR links (from a wireless router towards its MPR), and

❼ through all links connecting an interface to a hybrid router (hybrid1 andhybrid2).

4 Experiments and Results

For each scenario (I, II and III), communication between wless3 and server

is tested by way of two experiments. Displayed results show the averaged mea-sures over tens of samples (see Appendices A.3 and A.4 for further details onconfiguration of the experiments):

❼ Transmission of ICMPv61 requests (pings) from wless3 to server. Themeasure of time between the transmission of an ICMP request and itsreply corresponds to the Round Trip Time (RTT) of the ping through theevaluated path.

❼ Transmission of a constant bit rate data UDP flow from wless3 to server.Comparison between packets sent and packets received permits to test thequality of the traversed paths and the wireless links that compose themin each scenario. Characteristics of these UDP flows are summarized inTable 3.

Nominal sender bit rate 100 pkts/s

Packet payload 1024 bytes

CBR traffic rate 300 kbps

Flow duration 5 min/flow

Table 3: Characteristics of transmitted UDP flows.

1Internet Control Messaging Protocol for IPv6, RFC 4443 [10].

RR n➦ 7642


The three considered scenarios are complemented by another scenario inwhich information is transmitted and measured through the wired link h1 ←→

S. Results on this scenario are added for completeness and reference. Sec-tion 4.1 presents the results obtained in both experiments, for each scenario, interms of quality of wireless links. Section 4.2 examines the amount and struc-ture of control traffic used in OSPF for enabling routing of packets within theinternetwork.

4.1 Wireless Multi-hop Communication

Figures 3.a and 3.b display the results of the performed experiments, in partic-ular the delay for ICMP requests (pings) and the packet delivery ratio of CBRUDP data flows.

0 1 2 3Number of wireless hops

0.0

0.2

0.4

0.6

0.8

1.0

PDR

(a) Packet Delivery Ratio (PDR)

0 1 2 3Number of wireless hops

0

10

20

30

40

50

ms

(b) Round Trip Time (RTT)

Figure 3: (a) Packet delivery ratio (PDR) of UDP flows, and (b) Round TripTime (RTT) of ICMP requests, both depending on the number of wireless hops.

Both Figures 3.a and 3.b indicate the degradation of the quality of commu-nication between routers wless3 and server as the number of wireless linksbetween them increases. As expected, the wired link h1 ←→ S has an almost-ideal behavior: 100% PDR and no significant delay. The negative impact ofwireless links in the path from source to destination is close-to-linear with thenumber of traversed wireless links, as shown in Figure 3.a: more than 30% oftransmitted packets are lost in the first wireless link, and such percentage in-creases about a 15% per additional wireless link included in the path. Figure 3.bshows that such degradation is also evident in terms of round trip time (RTT).

INRIA


Replies to ICMP requests are immediately delivered through a wired link, butthe average and the variation of delays grow with the number of wireless linksinvolved – is in the order of tens of miliseconds for 2 and 3 wireless links.

While the impact on communication due to the use of wireless links dependson the specific topology and the network technology that is used, two conclusionscan be drawn from these experimental results. As each additional wireless hopin the route of data packets in the network implies a significant degradation ofthe quality of communication, routing in wireless networks should preserve theprinciple of shortest (wireless) paths, meaning that the number of wireless linkstraversed by data packets should be minimized. This confirms the conclusionsof simulation-based studies such as [21] which highlights the importance of notsacrificing path optimality for less control traffic.

Moreover, in the context of compound internetworks with both wired andwireless links, it is obvious that ’optimal’ does not necessarily mean ’the leastnumber of hops’, as implicitly used in previous work such as [6, 11, 2, 3]. Indeed,in compound internetworks, it is better for a path to use wired links than wirelesslinks, whenever possible, even if it means more hops in the end. This observationconfirms that metrics used should indeed be able to track link quality, and thatOSPF sepcifications such as [8] [5] [7] should be completed with a standard wayto do that in MANETs.

4.2 OSPF Control Traffic Pattern

0 50 100 150 200 250 300Seconds

0

100

200

300

400

500

600

700

800

900

Byte

s

LS-RequestLS-UpdateLS-AckHelloDatabase Description

(a) Bytes

0 50 100 150 200 250 300Seconds

0

2

4

6

8

10

Coun

t


(b) # Packets

Figure 4: Control traffic overhead at server:eth1.

RR n➦ 7642


Figures 4, 5, 6 and 7 display the evolution of OSPF control traffic transmit-ted by wireless interfaces wless3:wlan0 and hybrid1:wlan0, on one side, andwired interfaces hybrid1:eth0 and server:eth0, on the other. The five packetformats used in OSPF (Hello, LSUpdate, LSRequest, LSAck and DBDesc, seesection 2.1) can be distinguished in these figures. Measures were taken with thetopology of scenario I, each point corresponding to the number of packets orbytes sent within an interval of 5 seconds. The traffic load of the internetworkwas composed of a CBR UDP data traffic flow from wless3 towards server (seeTable 3 for details), and OSPF control traffic. The figures show the structureof such control traffic, both in terms of number of packets and number of bytes,during the first 335 seconds of network operation, i.e., after routers’ startup. Allinterfaces are configured with the same OSPF parameters, in order to facilitatethe comparison between control traffic patterns of each of them. See AppendixA.4 for further details.

4.2.1 Hello Packets

0 50 100 150 200 250 300Seconds

0

100

200

300

400

500

600

700

800

900

Byte

s


(a) Bytes

0 50 100 150 200 250 300Seconds

0

2

4

6

8

10

Coun

t


(b) # Packets

Figure 5: Control traffic overhead at wless3:wlan0.

The amount of Hello packets sent by each interface is kept constant along themonitored time. As HelloInterval = 2sec, interfaces transmit 2.5 Hello packetsper interval of 5 seconds. The length of Hello packets is significantly longer inwireless interfaces (Figures 7.a and 5.a) than in wired interfaces (Figures 4.aand 6.a). For the same number of neighbors, Hellos from hybrid1:eth0 have40 bytes while those from hybrid1:wlan0 have 75.34 bytes. This is due to the

INRIA


fact that Hello packet format in RFC 5449 [8] includes additional informationabout link costs, adjacencies and MPR selection, which is added to the formatspecified in OSPF [17] and OSPFv3 [9].

4.2.2 LSDB Synchronization

0 50 100 150 200 250 300Seconds

0

100

200

300

400

500

600

700

800

900

Byte

s


(a) Bytes

0 50 100 150 200 250 300Seconds

0

2

4

6

8

10

Coun

t


(b) # Packets

Figure 6: Control traffic overhead at hybrid1:eth1.

The existence of ongoing LSDB synchronization processes during the moni-tored time interval can be noticed in the OSPF control traffic structure by wayof the presence of Database Description (DBDesc) packets. The fact that suchpackets are only present, for wired interfaces, in the first part of the monitoredinterval (from t = 0sec to t = 10sec, as shown in Figures 4 and 6) indicates thatlinks become synchronized only when the routers are switched on. In contrast,DBDesc are transmitted in the whole monitored interval for wireless interfaces.This is consistent with the fact that wired links are mostly stable and there-fore there is no need to repeat synchronization process after the first LSDBexchange. Wireless links, in contrast, are more prone to packet losses and linkfailures, and need thus to be synchronized several times during the networklifetime, even in the absence of router mobility. The same phenomenon can beobserved with LSRequest packets, which can only be sent during the last phaseof the LSDB synchronization process, when the synchronizing neighbors havecompleted the exchange of DBDesc packets. These observations are also consis-tent with simulation-based studies such as [21] which have studied the impactof link quality on OSPF control traffic.

RR n➦ 7642


4.2.3 Link State Updates, Requests and Acknowledgements

0 50 100 150 200 250 300Seconds

0

100

200

300

400

500

600

700

800

900

Byte

s


(a) Bytes

0 50 100 150 200 250 300Seconds

0

2

4

6

8

10

Coun

t


(b) # Packets

Figure 7: Control traffic overhead at hybrid1:wlan0.

LSUpdate packets contain one or more Link State Advertisements (LSAs).Such LSAs can be either originated by the sending interface, either originated byanother interface and flooded (forwarded) by the sending interface. Transmis-sion of LSUpdate packets follows a common pattern in all the interfaces in theinternetwork. Thus pattern consists of periodic peaks followed by time intervals(valleys) in which the number and size of LSUpdate transmissions is lower androughly constant.

The time interval between two consecutive peaks corresponds to the value ofparameter LSRefresh, set to 60sec for all interfaces. This is the time intervalat which an interface floods its topology description (periodically) if there areno topology changes in the meanwhile.

Despite the common pattern in the LSUpdate traffic, several differences canbe observed between wired and wireless interfaces. This section concentrateson three particular aspects: peak width, height of valleys between consecutivepeaks and transient state (after routers are switched on).

❼ Transient state. Immediately after switching on, wireless interfacestransmit a high number of packets – mostly, LSUpdate packets sent in re-sponse to LSRequest packets received during the first LSDB synchroniza-tion processes in all wireless links (Figures 7.a and 5.a, between t = 0secand t = 50sec). This amount of transmissions involves traffic rates above

INRIA


220Bps (1.1kB per interval of 5sec), then decreases and stabilizes in aslightly lower level (maximum peak of 130Bps). The opposite behav-ior is found in wired interfaces (Figures 4.a and 6.a), in which the ini-tial transient period of low LSUpdate traffic rate (about 26Bps = 130B

5sec

for hybrid1:eth0) is followed by a steady period in which the minimumLSUpdate rate is slightly higher (about 30Bps = 150B

5secfor hybrid1:eth0).

These different behaviors can be explained by the different roles that flood-ing has over wired and wireless links. Due to their stability, packets sentover wired links are mostly forwarded packets – that is, they come fromother interfaces than those involved in the links. In the first instants inwhich there is no flooding over the network because adjacencies have notbeen formed in the network and flooding links have not yet been identi-fied, the overall traffic traversing such wired links is temporarily low. Theopposite is observed in wireless links.

❼ Peak width. Peaks are narrower in wired interfaces (∼ 10sec for server:eth1,∼ 15sec for hybrid1:eth0) than in wireless interfaces (∼ 25sec for hybrid1:wlan0,∼ 30sec for wless3:wlan0). For interfaces attached to wireless links,there is a high probability that a topology change causes a new topologyupdate before the LSRefresh interval – therefore, intervals between con-secutive transmission of interfaces’ topology descriptions are shorter thanLSRefresh and the width of the peak increases. In stable wired links,in contrast, intervals between consecutive transmissions are closer to theLSRefresh parameter and, therefore, LSUpdate transmission events areless spread in time.

❼ Height of valleys. Besides the peaks caused by transmission of its owntopology description, either periodic or as a reaction to a topology change,two other events may lead an interface to transmit Link State Advertise-ments (LSAs): (i) forwarding of LSAs originated by other interfaces in theinternetwork, and (ii) retransmission of LSAs not acknowledged by theirintended destinations. Both additional events explain the presence of val-leys with significant traffic rate, i.e., a non-zero minimum level of LSUp-date transmissions in the monitored interfaces. In wired (reliable) linkssuch as server:eth1 and hybrid1:eth0, such transmissions are causedby flooding, and involve about 25Bps (127B per interval of 5sec). Wirelessinterfaces such as wless3:wlan0 have a minimum LSUpdate transmissionrate of about 16Bps (80B per interval of 5sec) caused by LSA retransmis-sions and flooding.

5 Conclusion

Results from the experiments carried out on the testbed confirm the effect ofthe presence of wireless links in an OSPF network, confirming prior simulation-based studies concerning control traffic composition. Analysis of OSPF controltraffic over the wireless network reveals that even with a very small numberof neighbors per wireless interface and static routers, link synchronization pro-cesses may involve a continuous and substantial amount of traffic. Reduction ofthe number of synchronized links is, therefore, essential when using OSPF overad hoc networks.

RR n➦ 7642


Degradation of data communication due to wireless links implies that subop-timal data paths should be avoided in routing on ad hoc networks, as the qualityof resulting communication decreases substantially with each additional wire-less hop. For internetworks combining wired and wireless networks, wired linksshould be preferred to wireless links when possible. A standard way to tracklink quality in compound internetworks is thus necessary in order to completecurrent OSPF specifications for operation on MANETs. The presented resultsalso point out the importance of leveraging every possible wired connection inthe compound AS, which advocates for the use of a single routing protocol inthe AS. By using a single protocol, indeed, wired links would be natively in-cluded in path computation, without requiring the use of mandatory gatewaysbetween different routing domains, which may lead to suboptimal paths (andadditional hardware, software and maintenance costs for these gateways).

INRIA


References

[1] Cordero, J. A.; Baccelli, E.; Clausen, T.; Jacquet, P. (2011).Wired/Wireless Compound Networking. In: Wang, X. (Ed.) (2011). Mo-bile Ad-Hoc Networks: Applications, InTech Publishers, ISBN 978-953-307-416-0.

[2] Cordero, J. A.; Clausen, T.; Baccelli, E. (2011). MPR+SP – Towards aUnified MPR-based MANET Extension for OSPF. Proceedings of the 44thHawaii International Conference on System Sciences (HICSS), Hawaii, HI(United States), January 2011.

[3] Baccelli, E.; Cordero, J. A.; Jacquet, P. (2010). Optimization of Criti-cal Data Synchronization via Link Overlay RNG in Mobile Ad Hoc Net-works. Proceedings of the 7th IEEE International Conference on MobileAd-hoc and Sensor Networks (MASS), San Francisco, CA (United States),November 2010.

[4] Cordero, J. A. (2010). MPR-based Pruning Techniques for Shortest PathTree Computation. Proceedings of the 18th IEEE International Conferenceon Software Telecommunications and Computer Networks (SoftCOM),Split (Croatia).

[5] Roy, A.; Chandra, M. (2010). RFC 5820, Extensions to OSPF to SupportMobile Ad Hoc Networking, IETF, March 2010.

[6] Baccelli, E.; Cordero, J. A.; Jacquet, P. (2009). Multi-Point RelayingTechniques with OSPF on Ad Hoc Networks. Proceedings of the 4th IEEEInternational Conference on Sensor Networks and Communications (IC-SNC), Porto (Portugal).

[7] Ogier, R.; Spagnolo, P. (2009). RFC 5614, Mobile Ad Hoc Network(MANET) Extension of OSPF Using Connected Dominating Set (CDS)Flooding, IETF, August 2009.

[8] Baccelli, E.; Jacquet, P.; Nguyen, D.; Clausen, T. (2009). RFC 5449,OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks, IETF,February 2009.

[9] Coltun, R.; Ferguson, D.; Moy, J. (2008). RFC 5340, OSPF for IPv6,IETF, July 2008.

[10] Conta, A.; Deering, S.; Gupta, M. (2006). RFC 4443, Internet ControlMessage Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)Specification, IETF, March 2006. (Updated by RFC 4884)

[11] Henderson, T.; Spagnolo, P.; Pei, G. (2005). Evaluation of OSPF MANETExtensions, Technical Report D950-10897-1, The Boeing Company, July2005.

[12] Clausen, T.; Jacquet, P. (2003). RFC 3626, Optimized Link State RoutingProtocol (OLSR), IETF, October 2003.

RR n➦ 7642


[13] Henderson, T. et al. (2003). A Wireless Interface Type for OSPF, Pro-ceedings of the IEEE Military Communications Conference (MILCOM),pp. 137-145, IEEE ComSoc, Boston, MA (United States), October 2003.

[14] Perkins, C.; Belding-Royer, E.; Das, S. (2003). RFC 3561, Ad hoc On-Demand Distance Vector (AODV) Routing, IETF, July 2003.

[15] Jacquet, P.; Laouiti, A.; Minet, P.; Viennot, L. (2002). Performance ofMultipoint Relaying in Ad Hoc Mobile Routing Protocols, in E. Gregoriet al.: Networking 2002, LNCS, Vol. 2345.

[16] Halabi, S.; McPherson, D. (2000). Internet Routing Architectures, 2ndEdition, Cisco Press, ISBN 1-57870-233-X.

[17] Moy, J. (1998). RFC 2328, OSPF Version 2, IETF, April 1998. (Updatedby RFC 5709)

[18] Oran, D. (1990). RFC 1142, OSI IS-IS Intra-domain Routing Protocol,IETF, February 1990.

[19] Dijkstra, E. W. (1959). A Note on Two Problems in Connection withGraphs, In: Numersiche Mathematik, No. 1, pp. 269-271.

[20] F. Baker, M. Chandra, R. White, J. Macker, T. Henderson, E. Bac-celli Problem Statement for OSPF Extensions for Mobile Ad Hoc Routing,IETF Internet Draft, Spet. 2003.

[21] E. Baccelli, J. A. Cordero, P. Jacquet, OSPF over Multi-Hop Ad HcWireless Communications, International Journal of Computer Networks& Communications (IJCNC) Vol.2, No.5, September 2010.

INRIA


A APPENDIX

A.1 Testbed Hardware

Networking interface drivers were the following:

❼ Wired interfaces: Digital Equipment Corporation DECchip 21140.

❼ Wireless interfaces: Broadcom BCM4306 WLAN.

A.2 Testbed Software

Software used in all computers was as follows:

❼ Operating System: Ubuntu v.10.04 with kernel 2.6.32.

❼ Routing Protocol Implementation: ospf6d daemon of Quagga/Zebra rout-ing suite v.0.99.15.

– Wired interfaces: Point-to-point.

– Wireless interfaces: MANET, as specified in RFC 5449 [8].

A.3 Setup for PDR and RTT Measures

❼ Routers were switched on between t = 0sec and t = 2sec.

❼ PDR results averaged over 84 iterations.

❼ ospf6d daemon NOT restarted in each iteration.

❼ UDP flows, started 60sec after ospf6d daemon switch-on:

Nominal sender bit rate 100 pkts/s

Packet payload 1024 bytes

CBR real traffic rate sim 300 kbps

Flow duration 5 min/flow

Table 4: Characteristics of transmitted UDP flows.

❼ RTT results averages over 60 iterations (ICMPv6 requests).

❼ ICMPv6 request did not overlap with UDP flows.

A.4 Setup for Control Traffic Measures

❼ Routers were switched on between t = 0sec and t = 2sec.

❼ Results averaged over 84 iterations.

❼ ospf6d daemon restarted in each iteration.

❼ UDP flows: see Table 4.

A.5 OSPF Parameters

RR n➦ 7642


Table 5: General Simulation Parameters.Name Value

OSPF General ConfigurationHelloInterval 2 secDeadInterval 10 secRxmtInterval 5 secAckInterval 2 sec

Jitter 100 msecMinLSInterval 5 secMinLSArrival 1 sec

LSRefreshInterval 60 sec

INRIA

Centre de recherche INRIA Saclay – Île-de-FranceParc Orsay Université - ZAC des Vignes

4, rue Jacques Monod - 91893 Orsay Cedex (France)

Centre de recherche INRIA Bordeaux – Sud Ouest : Domaine Universitaire - 351, cours de la Libération - 33405 Talence CedexCentre de recherche INRIA Grenoble – Rhône-Alpes : 655, avenue de l’Europe - 38334 Montbonnot Saint-Ismier

Centre de recherche INRIA Lille – Nord Europe : Parc Scientifique de la Haute Borne - 40, avenue Halley - 59650 Villeneuve d’AscqCentre de recherche INRIA Nancy – Grand Est : LORIA, Technopôle de Nancy-Brabois - Campus scientifique

615, rue du Jardin Botanique - BP 101 - 54602 Villers-lès-Nancy CedexCentre de recherche INRIA Paris – Rocquencourt : Domaine de Voluceau - Rocquencourt - BP 105 - 78153 Le Chesnay CedexCentre de recherche INRIA Rennes – Bretagne Atlantique : IRISA, Campus universitaire de Beaulieu - 35042 Rennes Cedex

Centre de recherche INRIA Sophia Antipolis – Méditerranée : 2004, route des Lucioles - BP 93 - 06902 Sophia Antipolis Cedex

ÉditeurINRIA - Domaine de Voluceau - Rocquencourt, BP 105 - 78153 Le Chesnay Cedex (France)

❤tt♣✿✴✴✇✇✇✳✐♥r✐❛✳❢r

ISSN 0249-6399

compound wired/wireless internetworking with ospf filecompound wired/wireless internetworking with...

Documents