Adres autoconfiguratie in ad hoc netwerken. Koen Segers

Transcription

1 Universiteit Antwerpen Faculteit Wetenschappen Departement Wiskunde-Informatica Adres autoconfiguratie in ad hoc netwerken Koen Segers Eindwerk ingediend met het oog op het behalen van de graad van licentiaat in de Wetenschappen Promotor: Prof. Dr. Chris Blondia Begeleider: Michael Voorhaen, Nicolas Letor

2 Abstract Deze thesis beschrijft een onderzoek naar de verschillende mogelijkheden voor adres autoconfiguratie in ad hoc netwerken. Gebruik makend van de Click Modular Router software is er gewerkt aan een implementatie van een autoconfiguratie protocol. Deze implemententatie, genaamd PDHCP, is in NSClick gesimuleerd en geëvalueerd. PDHCP is een variant van DHCP, hetgeen zo goed als dé standaard voor adres allocatie in wirednetworks is. Om adres allocatie via DHCP te laten gebeuren, moet er een DHCP-server aanwezig zijn. Aangezien er in ad hoc netwerken geen centrale server aanwezig is, is DHCP niet bruikbaar. Het PDHCP algoritme volgt het zogenaamde Distributed-DHCP (DDHCP) idee, waar de taak van de DHCP-server verdeeld wordt over alle nodes. Overeenkomend met het uniformiteitsidee van nodes in ad hoc netwerken, is in PDHCP elke node zowel client-dhcp als server-dhcp. Het resultaat van deze thesis kan zeker gebruikt worden in reële ad hoc netwerken en vereist niet veel aanpassingen aan de oorspronkelijke DHCP packetten, wat de overgang naar PDHCP vergemakkelijkt. 2

3 Dankwoord Hoewel deze thesis een indivueel werk is, zijn er toch een aantal personen die ik zou willen bedanken. Om te beginnen dank ik professor Chris Blondia om deze thesis te mogen maken. De kennismaking met het ad hoc onderzoeksgebied en de NSClick community was een zeer rijke verruiming van de theoretische kennis die hij in de vorige jaren aangeleerd heeft. Mijn thesisbegeleiders, Michael Voorhaen en Nicolas Letor, zou ik uitermate willen bedanken. Ze stonden altijd voor me klaar met raad of oplossingen voor veel voorkomende problemen. Het enthousiasme dat ze uitstraalden gaf me altijd een extra boost om meer onderzoek te verrichten. Bart Braem zou ik ook willen bedanken voor de Click handleidingen die hij samen met Michael gemaakt heeft. Ook het ter beschikking stellen van zijn code en thesisverhandeling over AODV, hebben me zeer geholpen in de afwerking van deze thesis. Dat een thesis een process is van vallen en opstaan, hebben mijn ouders, mijn zus, maar zeker ook mijn vriendin ervaren. Bij deze zou ik hen willen bedanken voor hun steun en toeverlaat. Ik wil ook van de gelegenheid gebruik maken om een welgemeende bedankt te zeggen tegen al mijn vrienden. Zonder hen zou ik aan de afgelopen jaren nooit zoveel plezier beleefd hebben. 3

4 Inhoudsopgave 1 Introductie Thesisbeschrijving Ad hoc netwerk Adres autoconfiguratie Overzicht I Research 15 A Related work 16 A.1 Stateless address autoconfiguration protocols A.1.1 Routing independent protocols A.1.2 Routing dependent protocols A.2 Stateful address autoconfiguration protocols A.2.1 Centralized allocation table A.2.2 Distributed maintenance of the allocation table A.2.3 Distributed maintenance of multiple disjoint tables A.2.4 Distributed allocation function B Evaluating address autoconfiguration protocols 21 B.1 Evaluating through scenarios B.1.1 Scenario B.1.2 Scenario B.2 Evaluating stateless protocols B.2.1 Strong DAD B.2.2 WDAD and HDAD B.2.3 PDAD B.3 Evaluating stateful protocols B.3.1 DHCP

5 B.3.2 ManetConf B.3.3 DRCP B.3.4 Prophet B.3.5 Prime DHCP B.4 Evaluation Overview C PDHCP 26 C.1 Prime Numbering Address Allocation C.2 Retrieving an address C.3 Release C.4 Leases C.5 Becoming PDHCP server C.6 Relaying C.7 Root is special C.8 Partitioning and Merging D Routing 34 D.1 Classification of routing protocols D.1.1 Proactive or table-driven routing protocols D.1.2 Reactive or on-demand routing protocols D.1.3 Hybrid routing D.2 OLSR D.2.1 Optimizing the link state algorithm D.2.2 Core Functioning E PDHCP optimizations 38 E.1 Unique offers E.2 Proactive routing E.2.1 Release all leases E.2.2 Prune Root E.3 DHCP II Simulation 41 F NSClick 42 F.1 Click Modular Router F.1.1 Introduction F.1.2 Implementation language

6 F.1.3 Click router configuration F.1.4 Handlers F.2 NS F.2.1 Simulation F.2.2 NS2 internals F.2.3 NS2 Traces F.3 NSClick F.3.1 Time problem F.3.2 Device problem F.3.3 Parameterizing problem F.3.4 Addressing problem F.3.5 Stack problem G Installing PDHCP 50 G.1 PDHCP with OLSR G.1.1 OLSR interface nodes G.1.2 Modifications to the OLSR implementation G.1.3 Click configuration G.2 Changing the routing protocol H PDHCP evaluation 53 H.1 Simulation H.2 Non-merging ad hoc networks H.2.1 Random Waypoint Model H.3 Merging ad hoc networks H.3.1 Setup H.3.2 Merging operation III Conclusion 65 6

7 Lijst van figuren 1-1 Infrastructureless netwerk Infrastructurebased netwerk Versturen van een bericht van C naar A via flooding Versturen van een bericht van C naar A via routering Duplicate addressen als netwerken samenvoegen A-1 Flow chart of Strong DAD A-2 Routing state chart in Weak DAD A-3 Stateful address autoconfiguration protocol with a centralized allocation table A-4 Stateful address autoconfiguration protocol with distributed maintenance of the allocation table A-5 Network situation before DAAP A-6 Network situation after DAAP B-1 Network situation before scenario B-2 Network situation in scenario B-3 Duplicate addresses when networks merge C-1 A PNAA address allocation tree C-2 States a node gets in retrieving an address C-3 Sequence diagram of packets sent in retrieving an address C-4 Sequence diagram of packets sent in becoming a PDHCP server C-5 Situation where relaying is needed if the address range is C-6 Relaying with node C as a proxy between D and A D-1 Sending a broadcast message from node C using OLSR E-1 Default PDHCP offer problem F-1 Click graph to count the number of incoming packets

8 F-2 Description of possible configurations a Click Tee element can have F-3 The control flow of a software router F-4 Push and pull violations in a Click element. The correct usage is attached below F-5 A basic network of 2 nodes F-6 Agents and applications communicate through an API F-7 NSClick stack problem G-1 PDHCP in a click configuration with OLSR H-1 Address latency of 20 nodes with 500ms selecting state delay in total view H-2 Address latency of 20 nodes with 500ms selecting state delay in zoomed view H-3 Address latency of 20 nodes with 100ms selecting state delay in total view H-4 Address latency of 20 nodes with 100ms selecting state delay in zoomed view H-5 Network overhead for RWP model with different number of on-line nodes H-6 Network overhead growth for RWP model with different number of on-line nodes.. 59 H-7 Percentage of 1-hop broadcast packets for RWP model with different number of on-line nodes H-8 Stable network overhead for RWP model with different number of on-line nodes H-9 Stable network overhead growth for RWP model with different number of on-line nodes 62 H-10 Percentage of 1-hop broadcast packets for RWP model with different number of on-line nodes in stable network H-11 Situation before merging H-12 Situation when merging occurs

9 Lijst van tabellen B.1 Address autoconfiguration protocol evaluation D.1 MPR set of figure D H.1 IP assignment in 500ms and 100ms selecting state delay H.2 Offering address for node 15 in case 500m and 100ms selecting state delay H.3 Merging ad hoc networks simulation results

10 Hoofdstuk 1 Introductie 1.1 Thesisbeschrijving De titel van een document is zeer belangrijk. Een thesis is daar geen uitzondering op. Een titel kan een lezer aantrekken, maar zeker ook afstoten. De titel van deze thesis is vrij technisch en zal daarom als eerste besproken worden. In de titel staan twee belangrijke concepten die de lezer goed moet begrijpen om een idee te krijgen van het onderzoek dat verricht is Ad hoc netwerk Een ad hoc netwerk is een draadloos netwerk zonder vaste infrastructuurpunten waarbij het netwerk zorgt voor de configuratie van alle nodes 1 die zich in het netwerk bevinden. Er is dus geen centraal punt waar administratie van het netwerk kan (of moet) plaatsvinden. Om met elkaar te kunnen communiceren, maken de nodes een rechtstreekse verbinding met elkaar. Nodes die te ver afgelegen zijn, en er dus geen directe communicatie mogelijk is, worden via een multi-hopping techniek toch bereikt. Dit soort van draadloos netwerk is zonder twijfel anders dan de draadloze netwerken die we dagelijks gebruiken. GSM is het meest frappante voorbeeld van een netwerk waar er wél centrale punten nodig zijn. GSM maakt gebruik van zendmasten om de gebruikers met elkaar te verbinden. Elk gesprek wordt door de zendmast naar de bestemming gezonden. De zendmast heeft dus duidelijk een belangrijke functie in het goed functioneren van het GSM-netwerk. De hierboven beschreven types van netwerken worden respectievelijk infrastructureless(figuur 1-1) en infrastructurebased (figuur 1-2) netwerken genoemd. 1 Een node is een apparaat dat deel uitmaakt van een computer netwerk. Nodes kunnen computers, personal digital assistants(pdas), mobiele telefoons, of een ander netwerk toestel zijn. 10

11 Figuur 1-1: Infrastructureless netwerk Figuur 1-2: Infrastructurebased netwerk In sommige situaties is het niet wenselijk om een infrastructurebased netwerk als communicatiemiddel te gebruiken. Als de zendmast niet meer naar behoren werkt, is communicatie niet meer mogelijk. Hierdoor is er een sterke vraag naar infrastructureless netwerken voor oa. militaire diensten of spoed diensten. Andere aandachtspunten, eigen aan een ad hoc netwerk, zijn hun snelheid en eenvoud waarmee ze operationeel gemaakt worden. Multi-hopping Multi-hopping is een techniek waarbij nodes die te ver van elkaar afgelegen zijn om een directe communicatie te houden, toch met elkaar te laten communiceren. Tussenliggende nodes sturen de berichten door, zodanig dat de bestemming kan bereikt worden. Multi-hopping kan men zeer gemakkelijk implementeren door een bericht dat moet verstuurd worden simpelweg naar alle naburige 2 nodes te sturen. Indien de ontvangende node niet de bestemming is, wordt dit bericht naar hun naburige nodes doorgestuurd. Deze manier van rondsturen wordt flooding genoemd. Broadcasting werkt op dezelfde manier, alleen zijn hier alle nodes uit het netwerk bestemming van het bericht. Figuur 1-3 toont aan dat het versturen van een bericht van C naar A gebruik makend van flooding, veel netwerk overhead met zich meebrengt. Nodes D, E, F en G zouden het bericht eigenlijk niet moeten doorsturen. Node B zorgt er reeds voor dat het bericht bij node A aankomt. Willen we ad hoc netwerken van duizenden nodes kunnen ondersteunen, moet multi-hopping hierop verbeteren. Unicast door middel van routering zal soelaas brengen. Routering Routeringstabellen worden gebruikt om het meest optimale pad naar de bestemming van een bericht te bepalen. Enkel de nodes die op dit pad liggen moeten het bericht verder sturen tot de bestemming bereikt is. Figuur 1-4 visualizeert deze situatie. Het cruciale deel zit hem in het opmaken en onderhouden van de routeringstabellen in een netwerk waar de topologie zeer snel kan veranderen en waar verlies van pakketten regelmatig voorkomt. Net daarom is routering een belangrijk onderzoeksdomein in ad hoc netwerken. 2 Een node is een buur als ze in het bereik van de oorpsronkelijke node ligt. 11

12 A 2 B D 2 E C 2 F 1 2 G Figuur 1-3: Versturen van een bericht van C naar A via flooding A 2 E B D C F 1 G Figuur 1-4: Versturen van een bericht van C naar A via routering Adres autoconfiguratie In de vorige sectie is er, bijna vanzelfsprekend, gebruik gemaakt van het woord bestemming. Net zoals bij het versturen van een gewone brief, moet het adres van de bestemming gekend zijn alvorens men een bericht kan versturen. De vereiste opdat het bericht correct afgeleverd kan worden, is de garantie van de uniciteit van de bestemming. Adres Een logische keuze zou zijn om het hardware adres van de gebruikte netwerkkaart te kiezen als uniek adres. Het idee bestond nl. om aan elk netwerkkaart een uniek adres toe te kennen. Er waren jammer genoeg enkele problemen aan deze methode: de uniciteitsregel werd reeds snel verbroken [1] en het is daarenboven ook onmogelijk om een hierarchie (land/stad/straat/nummer) in de netwerkkaart te plaatsen door de mobiliteit van de netwerkkaart. In computer netwerken wordt er daarom veel gebruik gemaakt van een IP-adres. Een IP-adres is een uniek nummer dat netwerktoestellen gebruiken om zichzelf in een IP-netwerk te identificeren en zo te kunnen communiceren met elkaar. IP-adressen zijn daarenboven hiërarchisch, wat resulteert in meer schaalbare routerings tabellen omdat er geen routes per host nodig zijn. 12

13 U zal merken dat er in deze thesis regelmatig verwezen wordt naar een adres met slechts 1 nummer. Men noemt dit het host adres. Deze nummering kan bekeken worden als het huisnummer dat een node krijgt in een bepaald land/stad/straat. Adres Allocatie Uiteindelijk moet men voorkomen dat er twee (of meer) nodes in een netwerk hetzelfde adres hebben. Hiervoor moet adres allocatie instaan. Address allocatie kan zowel statisch als dynamisch gebeuren. Bij statische allocatie wordt er manueel een uniek IP-adres voor elke node toegekend. Dit is duidelijk niet schaalbaar. Bij dynamische allocatie wordt een uniek adres aangeboden door het netwerk. Deze methode geniet duidelijk mijn voorkeur. Autoconfiguratie In ad hoc netwerken is er nog een stap meer nodig dan enkel de dynamische adres allocatie. Ad hoc netwerken kunnen samenvoegen (mergen) als een node van het ene netwerk binnen het bereik komt van een node van een ander ad hoc netwerk. Het is zeer plausibel dat beide netwerken eenzelfde adres toegekend hebben aan een van hun nodes. Van zodra de ad hoc netwerken mergen, en er dus 1 groot netwerk gevormd wordt, is er mogelijk sprake van een duplicaat adres. Figuur 1-5 toont aan dat duplicate adressen (node 1 en 2) kunnen voorkomen als netwerken mergen. Autoconfiguratie zorgt, naast de dynamische allocatie, voor het opmerken en afhandelen van duplicate adressen. 1 A B 2 Figuur 1-5: Duplicate addressen als netwerken samenvoegen 1.2 Overzicht Het zal u mogelijk al opgevallen zijn dat er in deze thesis veel, voornamelijk Engels, vakjargon gebruikt wordt. Om foute vertalingen en onduidelijkheid te voorkomen, heb ik dan ook verkozen om de volgende hoofstukken in het Engels te schrijven. Ik ga starten met een beschrijving van een aantal autoconfiguratie protocols in hoofdstuk A. Met behulp van enkele scenario s, zullen deze protocols geëvalueerd worden in hoofdstuk B. Vervolgens zal ik het geimplementeerde protocol PDHCP tot 13

14 in de puntjes uitleggen in hoofdstuk C. Hoofdstuk D zal aangewend worden om wat meer uitleg te geven over ad hoc routerings protocollen, met een meer specifieke uitleg over de werking van OLSR. Hierop volgend zal ik een reeks van mogelijke optimalisaties voor het PDHCP protocol geven in hoofdstuk E. De laatste hoofdstukken zullen over simulatie van PDHCP-OLSR gaan. In hoofdstuk F zal het gebruikte simulatie programma besproken worden waarna er in G getoond zal worden hoe PDHCP geïnstalleerd is, en hoe men het met een ander routerings protocol kan laten samenwerken. De simulatie uitkomsten van PDHCP-OLSR zullen worden besproken in H. Uiteindelijk zal ik eindigen met een conclusie op pagina

15 Part I Research 15

16 Appendix A Related work In this chapter, I give an overview of currently existing address autoconfiguration protocols for traditional IP networks. All these protocols can be classified in stateless and stateful approaches. In the following chapter, I will evaluate all described protocols to come to my preferred, and thereby implemented, protocol PDHCP. A.1 Stateless address autoconfiguration protocols Stateless address autoconfiguration protocols are protocols where nodes don t keep a list of free or used addresses of the network at a any moment. This approach can only be decentralized, which is what ad hoc is all about. If the stateless protocol uses or changes routing information we speak of a routing dependent stateless address autoconfiguration protocol. If there is no need for the stateless protocol to change or use routing information, we speak of a routing independent stateless address autoconfiguration protocol. All xdad (Duplicate Address Detection) protocols are stateless protocols. A.1.1 Routing independent protocols Querying other nodes as to whether a chosen address is available is called Strong DAD 1 [13]. A veto mechanism is used in Strong DAD because one node can prevent allocating the address by sending a reply to the requesting node. If no reply is received within a certain period of time, a free address is assumed. Figure A-1 shows this in a flow chart. 1 Strong DAD is also known as Query-based (QDAD) or Active DAD (ADAD). In establishing uniformity of this paper, Strong DAD will be used throughout this document. 16

17 Start StrongDAD Choose Address Request Address YES NO Reply? NO Repeated X times? YES IP bound Stop StrongDAD Figure A-1: Flow chart of Strong DAD A.1.2 Routing dependent protocols Weak DAD (WDAD) and Passive DAD (PDAD) both rely heavily on the chosen routing protocol. WDAD, proposed by Vaidya [15], is based on the rule that each message will reach destination even if some duplicate addresses exist. This is accomplished by adding a key to each address, so that when two addresses have the same address, routing can be established by their key. The detection of a duplicate address will order one of the nodes to change its address. Figure A-2 shows this in a flow chart. MANET Process msg NO Routing msg? YES NO Address/Key conflict? YES Send notification Figure A-2: Routing state chart in Weak DAD Drawbacks to this idea are: 17

18 all routing protocol related control packets need to be modified to carry the key information routing tables require an extra column for the key/address combination not an optimal address allocation mechanism what if key/address pair is equal? In the WDAD scheme, the packet can still be misrouted in the interval between the occurrence of a duplicate IP address in the network and its actual detection. Enhanced WDAD eliminates this shortcoming by using sequence numbers and some bookkeeping. The third drawback can be ameliorated by making a combination of WDAD and Strong DAD, called Hybrid DAD (HDAD)[7]. PDAD is an enhancement of Weak-DAD where no modification to the routing algorithm is needed. PDAD is based on heuristics of a routing protocol to detect a duplicate address in the existing ad hoc network. Evidently, PDAD is highly dependent on the selected routing protocol and therefore not always preferred. Extensive research in PDAD has been done by Kilian Weniger. A concise overview is defined in PACMAN[16]. NOA-OLSR[9] is a PDAD for OLSR[3]. A.2 Stateful address autoconfiguration protocols Stateful protocols, on the contrary do keep some information to build a list of free or used addresses currently available in the MANET. It can be classified into four categories: 1. Centralized allocation table 2. Distributed maintenance of the allocation table 3. Distributed maintenance of multiple disjoint tables 4. Distributed allocation function A.2.1 Centralized allocation table This type of autoconfiguration protocol is implemented in almost any wired IP-network with dynamic addressing. In traditional wired IP-networks, the Dynamic Host Configuration Protocol (DHCP)[4] is the de facto standard for address allocation algorithms. A DHCP server acts as a centralized address pool of available addresses. If a node wants to retrieve an address from the pool to participate in the network, a request is sent. If all goes well, the server replies with an acknowledgment (ACK) 18

19 message which contains the address that was assigned to the requesting node. Due to the absence of such a centralized stateful server in ad hoc networks, this kind of dynamic address autoconfiguration is unfeasible. Figure A-3 gives an impression as to how this looks like. Allocation Table Figure A-3: Stateful address autoconfiguration protocol with a centralized allocation table By distributing the DHCP protocol by using one of the other stateful categories, one creates a protocol that falls under the DDHCP (Distributed DHCP) group name. A.2.2 Distributed maintenance of the allocation table The problem with the centralized allocation table becomes noticeable when one or more nodes lose connection with the server node. Therefore it would be more suitable to let all nodes have the same allocation table, and to distribute the maintenance of it. ManetConf[11] is one of those protocols. ManetConf works with a initiator (or leader) election model. If a node wants to retrieve an address from the network, it first requests a neighbor 2 to become its initiator. The initiator looks for a free address in its own table and sends a broadcast message to all other nodes in the MANET to mark the address as allocation in progress. If the initiator receives an affirmation from all nodes of the MANET it assigns the address to the new node and it broadcasts the allocation completed message. The new node will receive the address table in order to offer addresses to new nodes himself. Figure A-4 visualizes the situation. A.2.3 Distributed maintenance of multiple disjoint tables In trying to avoid all the broadcast messages that were needed for the distributed maintenance of the allocation table, one can split the address pool of the initiator in half and offer one half to the requesting node. The requesting node is now responsible for the allocation of the addresses it has received. This protocol is called the Dynamic Address Allocation Protocol (DAAP)[10]. Figure A-5 2 The neighbors of a node A are all nodes that lies in the range of A. 19

20 Allocation Table Allocation Table Allocation Table Allocation Table Figure A-4: Stateful address autoconfiguration protocol with distributed maintenance of the allocation table and A-6 explain this. DAAP is just the allocation part of a autoconfiguration protocol named DRCP (Dynamic Registration and Configuration Protocol)[10]. Allocation Table * ? Allocation Table * * Allocation Table Figure A-5: Network situation before DAAP Figure A-6: Network situation after DAAP A.2.4 Distributed allocation function All stateful approaches described above depend on having an address table and having one or many nodes maintain it. This approach is different: every node can generate new addresses according to a special function. The function must be in such a way that it produces addresses that are unique in the network, i.e. no other node can generate the same address. Prophet[20] introduced this idea. Prophet did not find a function strong enough to guarantee a unique outcome every time the function was called, but their function was able to predict when a duplicate was going to be generated. The function Prophet proposes, is very complex. Prime DHCP[6], on the other hand, defined a very easy function. Prime DHCP makes use of the very basic mathematical definition that every positive number can be written as a product of prime numbers in a unique way. This allocation mechanism is called Prime Numbering Address Allocation (PNAA) and is elucidated in section C.1. 20

21 Appendix B Evaluating address autoconfiguration protocols In comparing different solutions to the problem of address autoconfiguration in mobile ad hoc networks, a list of scenarios must be defined. Besides checking several solutions to these scenarios, this also illustrates the difficulty of the problem. The following scenarios were introduced in Prophet[20]. B.1 Evaluating through scenarios B.1.1 Scenario 1 The first scenario is the most basic scenario where a node enters a MANET and gets a unique address within a limited time. Though it is legal to return an error message as all available addresses are already exploited, it is obligatory to free unused addresses. 1 A 2 1 A 2? Figure B-1: Network situation before scenario 1 Figure B-2: Network situation in scenario 1 Figure B-1 gives a possible network situation before the new node has entered the MANET. Figure B-2 shows the moment the node gets connected to the MANET and requests an address to the network. 21

22 B.1.2 Scenario 2 In the second scenario the original MANET becomes partitioned and reemerged. Figure B-3 shows that address duplication can occur when networks merge, i.e. node 1 and 2 exist in both networks. 1 A B 2 Figure B-3: Duplicate addresses when networks merge B.2 Evaluating stateless protocols I refer to section A.1 for the description of the different stateless address autoconfiguration protocols I m going to evaluate. B.2.1 Strong DAD This algorithm does not support partitioning or merging of MANETs, so it does not fulfill the second scenario. Even the first scenario is not totally successful: due to the ignorance of the size of the network, computing the maximum time needed to receive a reply is not achievable. B.2.2 WDAD and HDAD In the evaluation of Weak-DAD, I assume Enhanced Weak-DAD is implemented. Evaluating scenario 1 is a bit difficult: the address allocation mechanism of WDAD will very likely generate a duplicate address, but packets do get to the correct destination if duplicates exist, as long as no duplicate address/key pair exists in the network. This last requirement made me evaluate this protocol negatively. Even though HDAD would perform much better in the allocation phase as fewer duplicate addresses arise by using Strong DAD, the same problem still comes forward when networks merge. So scenario 2 is likely to fail anyway. Therefore I rejected this idea. 22

23 B.2.3 PDAD PDAD succeeds both scenarios and was therefore a candidate for being implemented. Being routing protocol dependent was a negative point though. B.3 Evaluating stateful protocols A description of the different stateful address autoconfiguration protocols I am going to evaluate, can be found in section A.2. B.3.1 DHCP The proposed scenarios assumed an ad hoc network. As DHCP is unfeasible in this kind of network, there is no need to check our scenarios. I do give DDHCP an option. B.3.2 ManetConf In ManetConf[11], the initiator acts as a proxy for the requester until an address is assigned and packets can be routed to the requester. This has the advantage that new nodes can participate in a MANET almost directly, nevertheless a major problem arises as an initiator can not deduce to which node it must forward packages, as being a proxy, if more then one node has chosen it as its initiator. This means that my first scenario doesn t totally succeeds. ManetConf handles partitioning and merging of MANETs, so scenario 2 succeeds. Extending the ManetConf algorithm by using an extra ID can overcome the drawback of ManetConf. Several propositions can be made: for example adding a unique user-id (UID) to every requesting node[14] or stating that only leaders of a small neighborhood must be unique and act as a proxy to its members. Members of a neighborhood must then only be unique within this neighborhood[17]. By extending the ManetConf algorithm, both scenarios will succeed if ManetConf s problem can be solved in such a way that merging and partitioning can still be applied. All ManetConf extensions were therefore candidates for being implemented. B.3.3 DRCP According to Bernados[2], DRCP was aimed for quasi-dynamic networks. So it is not a general MANET IP address autoconfiguration solution. There is also no partitioning or merging capability. This results in failing scenario 2. 23

24 DAAP can be used in other autoconfiguration protocols. Therefore it really was worth mentioning it. B.3.4 Prophet Just as with WDAD, we can get duplicates with Prophet. But the great advantage to WDAD is that we can know when the duplicate is going to come forward. Prophet can use this information when it is needed. Prophet also supports partitioning and merging by using hello messages. The exact working of the hello messages can be found in C.8. Therefore Prophet succeeds both scenario 1 and 2 and was one of the nominees for being implemented. B.3.5 Prime DHCP Accidentally I found a paper that described an easy function that can guarantee not to generate a duplicate address every time the function is called. Prime DHCP clearly supports scenario 1. Partitioning and merging is also supported but I didn t totally like the idea introduced. In Prime DHCP there is a special node, called the root node. This root node requests the state of all nodes connected to the network. By checking all replies one by one, the root node can find duplicates when networks have merged. Thereby scenario 2 is also successful. So Prime DHCP also became a member of the list of qualified protocols. B.4 Evaluation Overview Table B.1 shows how the protocols were evaluated. The winners are PDAD, ManetConf Extensions, Prophet and Prime DHCP. But all have, although small, drawbacks. It must be possible to make a combination of these protocols to come up with a better protocol. Protocol Scenario 1 Scenario 2 Strong DAD - - WDAD - - HDAD +- - PDAD + + DHCP 0 0 ManetConf Extensions + + DRCP + - Prophet + + Prime DHCP + + Table B.1: Address autoconfiguration protocol evaluation Now that I have a choice, I add another constraint: it must be routing protocol independent. This 24

25 constraint makes the protocol more robust when the routing protocol suddenly changes. This can occur in MANETs with an adaptable routing protocol. As a consequence, PDAD is deleted from the list of qualified protocols. In a MANET, almost all nodes have limited battery power. Sending a message consumes a lot of power, so sending less messages to all nodes in the network saves a lot of power. A stateful address allocation protocol with distributed maintenance of the allocation table, like ManetConf, is per definition a protocol with much overhead. Also ManetConf Extensions is deleted from the elite protocol list. We end with Prophet and Prime DHCP. I prefer the PNAA algorithm of Prime DHCP for their genius and easy to implement distributed allocation function, and the hello messaging of Prophet for their solution to the merging difficulty. PDHCP is born! 25

26 Appendix C PDHCP As there is no RFC 1 to refer to, a detailed description of the PDHCP protocol is given in this chapter. PDHCP is a combination of Prime-DHCP[6] and Prophet[20]. Both are relatively young DDHCP protocols without an RFC. PDHCP tries to use the advantages of both protocols. C.1 Prime Numbering Address Allocation The Prime Numbering Address Allocation (PNAA) is proposed in Prime-DHCP and eliminates the necessity of Duplicate Address Detection (DAD). PNAA is originated from a canonical factorization theorem of positive integers, that is, every positive can be written as a product of prime numbers in a unique way. PNAA states that the first node that creates a network is the root node and has address 1. Section C.7 clarifies the need of the root node. The PNAA algorithm is based on following two rules: 1. The root node can allocate prime numbers in an ascending order. 2. Non-root nodes can allocate addresses equal to its own address multiplied by the unused prime number, starting from the largest prime factor of its own address. Figure C-1 gives an impression of how this is done. 1 In internetworking and computer engineering, Request For Comments (RFC) documents are a series of memoranda encompassing new research, innovations and methodologies applicable to internet technologies 26

27 Figure C-1: A PNAA address allocation tree If we, for example, take node with address 6. This is not the root node, so rule number 2 is applied. 6 has 2 prime factors, 2 and 3. 3 is the highest prime factor, so 6 can generate 18. The prime number followed by 3 is 5. So the next number generated by 6 is 30. By applying this PNAA algorithm, no two nodes can generate the same address and thus DAD is not necessary anymore. C.2 Retrieving an address This section explains how the ad hoc network assigns an address to a node. The node is in a certain state according to the packets it has received. Figure C-2 shows the states a node can traverse in retrieving an address, figure C-3 shows when the packets are sent. All packets are sent on the broadcast channel with TTL When a new node is switched on, it starts the PDHCP protocol by getting into the init state. In this state the node sends a discover message. PDHCP server nodes lying the range of the new node offer an address according to the PNAA algorithm that was described in section C.1. In figure C-3, node A is the new node and nodes B and C are server nodes. If no offer or hello 3 message is received, the node becomes root, takes address 1 and gets into the bound state. If an offer is received, the node gets in the selecting state. 2 A packet with TTL 1 is discarded by the receiving node. 3 Hello messages are primarily used for partition and merging (see section C.8), but they also indicate that an ad hoc network is present, but no free address can be offered at the moment. 27

28 init discover offer selecting nack no offer request requesting ack bound Figure C-2: States a node gets in retrieving an address 2. If a node is in the selecting state, it waits a certain time to retrieve as many offers as possible, without waiting to long. The smallest address is chosen to be sent in a request message. All neighboring nodes receive the request message, but only the offering node will respond. The node makes a transition to the requesting state. 3. If a node is in the requesting state, it waits a limited time for a nack or ack message from the node that offered the chosen address. If an ack is received, the node assigns the requested address as its own address and gets into the bound state. The node that generated the ack message, becomes the parent node. If a nack is received, the node goes back to the init state and restarts the address retrieving mechanism. If no ack or nack is received in a limited time, the node goes back to the init state and restarts the address retrieving mechanism. C.3 Release When a node is shutting down, it is supposed to sent a release message to the root node and if possible also to the parent node. Obviously a node isn t always capable of sending these messages. A battery breakdown, suddenly losing connecting, etc. can occur. Section C.4 explains how this problem can be overcome by using leases. 28

29 39! #) #) 6 :;!;! :;!;! 7 (8/-/% 7 (8/-/% %&' ()% *+',-,.' ( /-/% 0 1&' ( "!#$ C.4 Leases Figure C-3: Sequence diagram of packets sent in retrieving an address As nodes come and go, unused addresses need to be recycled. This recycling is based on leases and release messages. Release messages aren t obligatory, but it speeds the process of recycling unused addresses. Every node, except the root node, has a lease with his parent. Renewing the lease prevents the parent from allocating the address to another node. If the lease expires, the node is free to offer. Renewing a lease is done by resending the request message to the parent node. If an ack returns, both nodes know they are online. If one of the nodes is found offline, a release message is sent to the root. This will update his root table. All leases are sent on unicast. This minimizes the overhead for the entire network, but also prepares all nodes to have an entry in their routing cache in case relaying (see section C.6) is needed. This is very important if the network uses a reactive routing protocol. C.5 Becoming PDHCP server A node can become a PDHCP server if following two conditions are fulfilled: the node has retrieved a bound address (see section C.2) a lease active reply from the root node is received or the node is the root node When a lease query message is received by the root node, a lease active reply is sent. This reply contains a list of bound addresses that a previous node with this address has already offered before 29

30 &'( ;B &'( &'( C? & (( ( &'( *) G & )HA, ( 7 G & )HA, ( 7 ' < ' < I &1JFEF I &1JFEF / 0 1 ( 9D E 1 (FEF L & / 0 1 K &,- 8AMAN ( 0 '( $?OA# P &4 / 0 AQ F R ( ER $ "!# / 0 ST ( /S0U 6 3 &4 $, : ; <)>=@? A7. & / &,- "!$# % + &,- Figure C-4: Sequence diagram of packets sent in becoming a PDHCP server going out of the network. Figure C-4 explains how the node is initialized to generate unused addresses to new nodes. To inform all nodes in the lease active list that the lease with their parent node needs to be renewed again, an ack is sent by the root node. If no lease active was replied by the root node, the node must become root node. Section C.7 explains why this is obligatory. C.6 Relaying In ad hoc networks with a very limited address range, some PDHCP server nodes might not be able to offer a free address anymore. If all neighboring nodes would be in this situation, no new node can get connected to the network until a node that can offer a free address becomes a neighbor. Relaying copes with this problem. 30

31 Relaying means that a node becomes a proxy between a new node and the proxy-node his parent. Figure C-5 is such a situation. Here node 3 becomes the proxy node between node X and node 1. How this relaying is done is visualized in figure C-6. 2 X Figure C-5: Situation where relaying is needed if the address range is 0-7 All packets that have a relaying tag are sent using unicast. Doing this still prevents broadcasting the packets to all nodes like most allocation protocols do. There is a drawback though: the parent node of the proxy can lie on the other end of the network. This probably imposes unnecessary overhead as all nodes lying between the proxy-node and his parent are also potential offering nodes. The overhead added by reactive routing protocols is relatively small, as each node needs to update his lease with his parent (see section C.4). If a parent still is unable to offer a free address, the discover is re-relayed to his parent, etc. If a parent node can offer an address, all communication goes directly to the proxy. So re-relaying nodes don t become proxies themselves. In the situation of figure C-5, node X wants to retrieve an address from the network. The network has a very limited address range of 8 addresses. Node 3 receives the discover message, but can not offer an address himself (3*3=9). Node 3 therefore relays the discover message to node 1. Node 1 offers address 7. If all goes well, node X will be bound to address 7. C.7 Root is special The root node has a special service to fulfill. As said in section C.2, the root node is the node that creates an ad hoc network. The root node still differs from the central server concept as used in DHCP as the root node can move freely, even when this means that he leaves the network. The 31

32 ! +, -')%. / #1 *(* 0 #1 *(*! 0, "')%.? *(*! "# $&%"'(') "# *(* 8,! "# 23 "')%. = -A # >, -')%. /% 4 95 :! ;<%= Figure C-6: Relaying with node C as a proxy between D and A network must be smart enough to assign a new root node. This clearly differs from the idea of a central server. A list of special services the root node must provide: 1. The root node has lease with all nodes on the network. If a lease expires on a node, the node becomes root. As exhibited in section C.1, nodes with a large address can only generate larger addresses. In preventing the relaying mechanism, the node with the largest address should become root. 2. The root node renews its leases with all other nodes by broadcasting an inform request to all nodes. The inform reply message sent by a non-root node, only contains its parent address. This information is necessary to let the root node answer a lease query. 3. New nodes query their situation to the root node if they want to become a PDHCP server node. See section C.5 for more information. 4. The network ID (NID) is chosen by the root node. If a node replaces an old root node, i.e. the root lease expires, a new NID is generated. This substitution is broadcasted into the network when the lease of the new root node is renewed. See section C.8 for the meaning of the NID. 5. The root node must be able to detect ambiguities, and handle them as optimal as possible. C.8 Partitioning and Merging On page 22, figure B-3 shows that address duplication can occur when networks merge, i.e. node 1 and 2 exist in both networks. 32

33 The PNAA algorithm is not capable of handling this problem. Prophet, the second protocol where PDHCP is based on, proposes to use hello messages in order to handle the network merging detection. Hello messages are messages sent on the broadcast channel with TTL 2. Many routing protocols use this to discover the neighbors of a node. It would be possible to piggyback PDHCP data in the hello messages sent by the routing protocol, but the default PDHCP protocol uses their own hello messages to remain routing independent. The PDHCP data attached to an hello message consists of: NID, chosen by the root node of the network Network size: number of nodes connected to this network. Obtained from the inform reply messages when renewing the root lease. Root broadcast sequence number. Increases when the root node renews his lease with all other nodes. This prevents nodes that did not receive the broadcast message from becoming root node. Merging is detected if a node receives a hello message with a different NID. If so, the node with the smallest network size must resolve the possible duplication. If sizes are equal, the smallest NID is chosen. Partitioning is detected when no hello message is received anymore, or when the root lease expires. In both cases a new root node is selected. The new root node must choose a new NID and send this substitution to all nodes connected to its new network. Clearly, partitioning does not impose many protocol overhead. 33

34 Appendix D Routing To minimize the communication overhead, the PDHCP protocol uses unicast extensively. This implies that PDHCP depends on an ad hoc routing protocol, but the decision as to which routing protocol is arbitrary. In this chapter I give a general overview of possible routing protocols and a more comprehensive description of the Optimized Link State Routing (OLSR)[3] protocol as OLSR is the prefered routing protocol of the PATS research group. Above that, an implementation of OLSR in the Click modular router software[8] exists. D.1 Classification of routing protocols All ad hoc routing protocols can be classified into three major categories based on the routing information update mechanism: proactive routing, reactive routing and hybrid routing. D.1.1 Proactive or table-driven routing protocols In proactive or table-driven routing protocols, every node maintains the network topology information in the form of routing tables by periodically exchanging routing information. Using these routing tables, a path-finding algorithm can derive the path to a destination whenever a node requires it. Proactive routing protocols are superior in networks with lots of communication. If few messages are sent, the overhead of maintaining all the routing tables is to high. D.1.2 Reactive or on-demand routing protocols In reactive or on-demand routing protocols, a path to a destination is only requested whenever it is required. The necessary path is obtained by using a connection establishment process. 34

35 Reactive routing protocols are therefore superior in networks with little communication since there is no need to maintain the entire network topology information. D.1.3 Hybrid routing Protocols belonging to this category combine the best features of the above two categories. Here, each node maintains the network topology information up to r-hops. In Zone Routing Protocol(ZRP)[5], nodes within a r-hop neighborhood are said to be within the routing zone of the given node. Routing between nodes in this zone is done proactively. For nodes located beyond this zone, reactive routing is used. D.2 OLSR Optimized Link State Routing (OLSR)[3] is a proactive routing protocol for mobile ad hoc networks (MANET). As the name reveals, the protocol is based on the classical link state algorithm and customized for the requirements of MANET. D.2.1 Optimizing the link state algorithm A technique called multipoint relaying takes care of most of the optimization against classical link state algorithms as it reduces the overhead of sending a broadcast message, minimizes the number of control messages flooded in the network and has the possibility to distribute only partial link state information to the network. All three optimizations are explained below. MPRs for reducing the broadcast overhead MultiPoint Relays (MPR) are selected nodes which forward broadcast messages during the flooding process which occurs when a broadcast message is sent. Allowing only a few nodes to forward broadcast messages, evidently decreases the network overhead. It is important to choose the MPR nodes in such a way that the broadcast message is still received by all nodes connected to the network. Therefore the MPR set of a node must be a subset of the 1-hop neighboring nodes such that all strict 2-hop neighbors 1 are covered. Figure D-1 shows a situation where node C sends a broadcast message to all nodes of the network. Table D.1 reveals the MPR set of the network that was displayed in figure D-1. Notice the difference between figure D-1 and figure 1-3 of page 12. According to table D.1, nodes B and D are selected as MPRs by node C. If also node G was part of the MPR set of node C, a satisfactory MPR set is found, but not the optimal set. When starting OLSR all neighboring nodes are therefore selected as MPRs until optimization is possible. 1 A strict 2-hop neighbor is a 2-hop neighbor which is not the node itself or a 1-hop neighbor of the node. 35