Pro-Active Autoconfig Implementation Overview version 0.2. Andreas Tønnesen

Transcription

1 Pro-Active Autoconfig Implementation Overview version 0.2 Andreas Tønnesen 12th February 2004

2 ABSTRACT This document describes the basic functioning of the Thales Pro-Active Autoconfig implementation. It also covers how to compile, configure and run the PAA implementation using the UniK OLSR routing protocol with PAA extensions. 1

3 Pro-Active Autoconfig About Pro-Active Autoconfig is an IPv4 address allocation protocol with duplicate address detection(dad) for use in mobile ad-hoc networks(manets). PAA takes advantage of the fact that nodes that are already members of a MANET domain, running a pro-active routing protocol, already has a full understanding of the topology and therefore are well suited to allocate a IP address that is probably currently not used by any nodes in the network. PAA also does complete DAD to ensure that no other node is configured, or in the process of configuring itself, with a address. This is done by flooding the network using the underlying routing protocol. PAA should provide a node with the ability to automatic configure itself with a uniqe address and join a MANET. PAA could again be started from a MANET sensing daemon. Basic operation PAA consists of three software components. They are outlined in Fig.1. A unconfigured node runs the PAA-client to allocate a free address. In this contex free means a addres not used by any other node in the MANET. The unconfigured node comunicates with one (or more) configured nodes. A configured node runst the PAA-server that communicates with the routing daemon using interprocess communication(ipc). In the next three sections functioning of the three components are described. 2

4 Figure 1: Basick outline of the PAA design. 3

5 PAA client Files File src/paa_protocol.h src/paa_client.c src/interface.c src/net.c Description packet descriptions and constants client functions interface configuration functions network functions Terms LL - a link local address in the ( /16) address space ID - a unique identificator based on a nodes interface MAC address requester - a node requesting a IP address SEQNO - sequence number that is incremented with 1 for each sent msg. Responsibilities configure an interface with a random LL address querying neighbors for an address offer using LL broadcast perform DAD on the offered address Configure the node with the free address(or exit if no unique addresses could be found) start the routing protocol go to server operation-mode 4

6 Figure 2: Schematic view of a configuration session with respect to the PAA-client. Comunication types All control-traffic uses the user datagram protocol(udp). Interface configuration When starting PAA one must specify on what interface it should run. For now PAA can only be used on one interface. The client will first generate a random LL address. It will then configure an alias interface with this address. If PAA is set to run on eth0 the alias interface would be eth0:0. This interface will be used by both the PAA-client and later the PAAserver. 5

7 Forwarding request A requester will periodically broadcast a forwarding request(fwd_req) message LL. This is to let already configured neighbors know that they should forward all received PAA control messages LL. Address request An address request(addr_req) message is broadcasted LL next. A node signs this request with its ID. Any neighbor that is already a configured member of the MANET routing domain and out of quarantine time will answer with an offered address(if any could be allocated). If no replys are received the PAA-client can optionally configure its interface with a random /16 address and start the routing daemon - thus starting its own MANET. Address test Even though address request response(addr_res) are unicasted back to the requester - the ID field has to be set. This is to avoid problems if two nodes should configure themselves with the same LL address while both are in range of the replier. Upon receiving the first ADDR_RES(with the correct ID) the requester will generate a address test(addr_test) message and broadcast it LL to all neighbors. Any other ADDR_RES received for the same request(carrying the same SEQNO) is silently discarded. Any configured node that hears the ADDR_TEST message sends a ADDR_TEST_RES response message so that the PAA-client can be sure that the test-message is flooded. If no ADDR_TEST_RES is heard a new ADDR_TEST is sent until at least one ADDR_TEST_RES arrives. The PAA-client then waits for a given interval PAA_REQ_TIMEOUT to receive conflicting ADDR_TEST messages sent by other nodes. If this interval times out without any conflicting ADDR_TEST messages received, another ADDR_TEST 6

8 message is broadcasted. If another time interval of PAA_REQ_TIMEOUT passes without the node receiving any conflicting ADDR_TEST messages the address is considered valid and DAD is considered complete. If conflicting messages are received another ADDR_REQ message will be generated as described in 3.3. Configuring interface When a unique IP is allocated the PAA-client will configure the interface specified with the address. FORW_REQ messages will now no longer be sent. Starting the routing protocol When the interface is configured the chosen routing protocol is started. In this implementation the UniK OLSR implementation is used( The PAAclient must take care to ensure that the routing daemon will run on the chosen interface. PAA is also responsible for terminating the routing-protocol process when it is terminated itself. Leaving client mode When the routing-daemon is started the PAA-client will put itself in server mode. 7

9 PAA server Files File src/paa_protocol.h src/paa_server.c src/ipc.c src/net.c Description packet descriptions and constants server functions for communicating with PAA-clients IPC functions for communication with the routing protocol network functions Terms FWD_TIMER - a timer indicating if a PAA-server should forward messages on the LL interface LL - a link local address in the ( /16) address space ID - a unique identificator based on a nodes interface MAC address requester - a node requesting a IP address offerer - a node offering a IP address SEQNO - a sequence number that is incremented with 1 for each sent message. Responsibilities connect to the local routing-daemon listening for FWD_REQ messages and maintain a forward timer listening for ADDR_REQ messages query the routing protocol for free addresses 8

10 Figure 3: Schematic view of a configuration session with respect to the PAA-server. send ADDR_RES messages to PAA-clients that has issued ADDR_REQ messages forward ADDR_TEST messages received from PAA-clients to the routing protocol forward ADDR_TEST messages received from the routing protocol to PAAclients Communication types All control-traffic between PAA-clients and servers uses the user datagram protocol(udp). IPC between PAA-servers and the OLSR daemon uses TCP over the loopback device. Connecting to the local routing-daemon The first thing PAA does when going from client- to server-mode is to connect to the routing-daemon via a TCP socket to the loopbackdevice( ). All IPC between the PAA-server and the routing-daemon will go via this socket. 9

11 Forward request messages A PAA-server should only forward messages LL if there exists any unconfigured 1 hop neighbors. To detect this the PAA-server listens for FWD_REQ messages sent periodically by unconfigured nodes. Upon receiving a FWD_REQ the FWD_TIMER of this node is set to current time + FWD_HOLD_TIME. Address response messages Upon receiving a ADDRESS_TEST from a PAA-client the PAA-server queries the routing protocol(over IPC) for a free address. If the ADDR_TEST contained a preferred address this is passed to the OLSR daemon in the query message. If no free IP addresses can be allocated, the PAA-server will silently discard the ADDR_TEST and take no further action. If a IP offer is received from the routing protocol a ADDR_RES message is generated containing the offered IP and the ID and SEQNO from the received ADDR_TEST. Address test messages from PAA-clients Upon receiving an ADDR_TEST message on the LL interface, the PAA-server forwards this message to the routing protocol if and only if the FORWARDED flag is not set in the message. This is to prevent forwarding of messages forwarded from other PAA-servers. The PAA-server then sends a ADDR_TEST_RES LL back to the PAA-client. Address test messages from the routing protocol Upon receiving an ADDR_TEST message from the routing protocol the PAAserver broadcasts this message LL if and only if the FORWARD_TIMER > current time. If the message is to be forwarded the FORWARDED flag is set. This is to en- 10

12 sure that other PAA-servers within radio-range does not process this message as a ADDR_TEST from a PAA-client. 11

13 Routing daemon with PAA extentions Files File olsrd/src/paa_protocol.h olsrd/src/paa_olsr.h olsrd/src/olsr_protocol.h olsrd/src/paa.c olsrd/src/process_package.c olsrd/src/input.c olsrd/src/olsr.c olsrd/src/build_msg.c Description packet descriptions and constants OLSR encapsulated PAA packets the OLSR protocol definitions IP address caching package processing package reception PAA message forwarding Message generation Responsibilities(with respect to PAA) Make sure it does not serve any IP address before it has ran for a certain amount of time(quarantine) Caching all heard-of IP addresses for a given period Listen for ADDR_REQ messages and try to locate a free IP address Flood the network with ADDR_TEST messages Deliver ADDR_TEST messages to the PAA-server Communication types IPC between PAA-servers and the OLSR daemon uses TCP over the loopback device. 12

14 Figure 4: Schematic view of a configuration session with respect to the routing-daemon. IP cache The pro-active routing protocol will eventually have heard of all IP addresses currently used in the MANET if the PAA protocol is used by all nodes. But rather than checking for free IP addresses by looking up all internal tables of the routing table, a IP cache pool is maintained. This way IPs can also be cached for a longer periods than they would stay in the routing daemons internal tables. Upon receiving any kind of known routing control traffic, the routing daemon adds all the IP addresses listed in the message to the IP cache with a timeout of CACHE_HOLD_TIME. This period is set to 30 seconds in the implementation. To locate a free address the routing daemon selects a random address in the netrange that the MANET uses or uses a possible preferred address provided by the PAA-server, and checks this against the IP cache. If the address exists a random address is created within the MANETs net-range and checked against the IP cache again - this is done for a maximum of GEN_TRIES times. If an generated address is not found in the cache it is considered free and will be sent to the PAA-server that will offer it to the PAA-client that again will perform DAD on the address. 13

15 Figure 5: Schematic view of a configuration with no conflicts. Address request message Upon receiving a ADDR_REQ message from the PAA-server the routing daemon tries to generate a free IP address as described in section If a free address is located a ADDR_RES is sent to the PAA-server and the address is added to the IP cache. If no address was found no action is taken. Address test messages from PAA-server Upon receiving an ADDR_TEST from the PAA-server the routing daemon encapsulates the ADDR_TEST message in a routing protocol message. This message is then flooded troughout the MANET by the flooding mechanism provided by the routing protocol. Address test messages carried by routing protocol Upon receiving a encapsulated ADDR_TEST message carried by the routing protocol the routing daemon will, in addition to forwarding the encapsulated message according to the forwarding algorithm used by the routing protocol, decapsulate the packet and forward it to the PAA-server. 14

16 Installing the UniK OLSR daemon You must use a version of olsrd with PAA-extensions. As of now the public avalible versions found at does not have these extensions. Compile and install the routing-protocol #tar xvfj uolsrd-0.x.x.tar.bz2 #cd unik-olsrd-0.x.x #make #make install Edit the configfile /etc/olsrd.conf in your favorite editor: remove all interface entries to let PAA set the interface olsrd should run on set other parameters. Remeber the PAA does not set any parameters other than the interface at startup. 15

17 Compiling and installing PAA Throughout all descriptions of compiling, installing and running it is assumed that you run the given commands in a shell such as bash. Requirements The PAA implementation is written i C for the GNU/Linux operating system on the i386 architecture. But it should compile for architectures such as ARM as well. To compile PAA the following is required A system running Linux kernel 2.2 or above The GNU C compiler suite(gcc). If one wishes to use another compiler one has to edit the Makefile. GNU-make GNU libc pthread dynamic libraries Compiling To compile PAA go to the root directory of the paa source tree and run: #tar xvfj paa-0.x.x.tar.bz2 #cd paa-0.x.x #make This should compile and link PAA. The executable ends up as./bin/paa 16

18 Installing NOTE: This step is not required. To install paa in /usr/local/sbin go to the root directory of the paa source tree and run: #make install Notice that this requires root privileges. 17

19 Configuring and running IMPORTANT: You must be root(have UID=0) to run paa. Configuring You should edit the path to the routing protocol daemon executable to fit your needs prior to compiling. This can be changed in the start_routing_protocol function in src/ipc.c Running The following options can be passed to the paa binary: Specifies the interface to use. Example: -i eth0 Specifies that the PAA-client should start its own net if no contact is made. To run the binary you should go to the root directory of the paa source and run: #./bin/paa <options> if you did not install paa as described in section 5.3. If you installed it, PAA can be ran from anywhere typing: #paa <options> 18

20 The paa_protocol headerfile The headerfile defines all PAA spesific datatypes and values in the implementation. It is listed here as a reference:! "! # %$'& ()$ # *' +$'& (, -. /- # $ # , # # # # : # <;3 = <; > : - # A! 1 6! BC(D& ( ( ( ( ( ( ( # 7 E*!F 1 (D& ( ( ( ( ( ( ( # (D 5( ( ( ( ( ( ( - HG I - 19

21 # 790 *6 1! 5 # 12 E*H;1F 8 # 12 E*13 5 # <9E*' $( # 13 *'13, # 790! 0 E*H; *6 1! *6, - - #!! A 0 3 (D -!. - #!! 1 7E*> (D( ( ( ( -!. D - #!! 37)*> <; >C: C # 0 17 F! 1 7E*>C(D( ( ( (& ( - 6)*< )? $, $: & $, - 4, "7 ; /G? - 4,? - I D / A! 1 6! B - 4, - G? - 20

22 4,? - I D "7 )*!F 1-4, - #G? - 4,? - I D "7 )*!F 1-4, - #G? - 4,? 4, G? - 4,? - I D "7 )*!F ,? 4, 21

23 - = G? - G? & & ) $: 4, ) ) < ) < ) < ) < ) < ) < 22