Basic operation

As outlined in figure 12.1, PAA consists of three software components. An unconfigured node runs the client to allocate an unused IP address. The client communicates with one (or more) PAA-servers running on already configured nodes. These PAA-servers communicate with the routing daemons running on their local hosts. All communication between PAA-clients and PAA-servers is done using the link-local address space 192.168.0.0/16 when using IPv4 and fe80:: when using IPv6. DAD flooding is done using the flooding mechanism offered by the routing protocol in addition to link-local traffic.

PAA packets uses the 64-bit header illustrated in figure 12.2, and all traffic is carried using UDP.

Bits: 001 2 3 4 5 1

Figure 12.2:The generic PAA packet.

Bits: 001 2 3 4 5 1

Figure 12.3:The Forward Request message.

Bits: 001 2 3 4 5 1

Figure 12.4:The Address Request message.

Bits: 001 2 3 4 5 1

Figure 12.5:The Address Response message.

Bits: 001 2 3 4 5 1

Figure 12.6:The Address Test message.

Bits: 001 2 3 4 5 1

Figure 12.7:The Address Test Confirmation message.

Proxy vs. broadcast solution

Two main approaches can be taken when requesting an IP address from nodes in a MANET. They are here referred to as the proxy solution and the broadcast solution.

If using the proxy solution, the unconfigured node elects one configured node that operates on behalf of it for the entire configuration session. In PAA this can be done, but the implementation on which this chapter is based, uses another approach. The main idea in the implementation of PAA, is that an unconfigured node is to be able be mobile while doing configuration. Because of this no proxy is used for configuration.

A node communicates with any configured nodes that are in communication range. Data is broadcasted from the unconfigured node and back from configured nodes. Because of this, this approach is called the broadcast solution. No state is kept in the configured nodes regarding configuration sessions. An unconfigured node can be mobile and use different configured nodes for different parts of the configuration process.

Both approaches have their pros and cons. The broadcast solution gives the advantage of mobility, but the proxy approach could provide a more robust DAD. If using a proxy, address conflict messages in strong DAD, can be unicasted back to the proxy node. When using the broadcast solution all such traffic is flooded throughout the MANET. Some specific scenarios where a node loses connectivity and does not receive conflicting messages could also be avoided when using the proxy solution, but new such problematic scenarios could be generated for the proxy solution as well.

An example of a configuration session

Figure 12.8 illustrates a configuration session where a new node joins the MANET. In this example, no address conflicts are detected. If using IPv4 the unconfigured host configures itself with a random link-local address, if using IPv6 the link-link-local address automatically assigned to the used interface is used. The PAA-client then broadcasts(IPv4) or multicasts(IPv6) an Address Request(figure 12.4). Since the IPv4 link-local address is generated using random numbers, conflicts can occur. Because of this, an identifier that the PAA-client generates based on the interfaces MAC address, is used for host identification. This identifier is also used when using IPv6, since all return traffic is also multicasted back to the client from the server.

The Address Request message might contain a preferred address that the unconfigured host wishes to use

Configured host

Figure 12.8:An example of a conflictless PAA IP allocation session.

if available. When using IPv4 this is a regular IP address, when using IPv6 this is the MAC address of the interface on which PAA is running. Note that an IPv6 Address Request still contains a 128 bits preferred address field to allow for possible future changes and to maintain a consistent IPv4/IPv6 packet design. A PAA-server receiving this request forwards it to the PAA-plugin. When using IPv4 the PAA-plugin checks if the preferred IP address is available, if the address is not available or if no preferred address was received, it acquires a random available address. An available address is defined as an IP address that the configured node has not heard mentioned in any OLSR control traffic for a given time. If using IPv6, the client has to submit its MAC address in the request message. The server then forwards the request to the PAA-plugin that generates an address based on the MAC. The address is made up of a prefix from some predefined net-range and the MAC address. This address is then checked against the IP cache pool. If a conflict is discovered multiple “backup” net-ranges could be used to create an address based on the MAC. The allocated address is then sent back to the requesting host in an Address response message(figure 12.5).

The requester is now to perform strong DAD. This is done by broadcasting or multicasting a Address Test message (figure 12.6) link-local. All PAA-servers receiving this message is to flood it through the MANET using MPR flooding. This is done by encapsulating the message in an OLSR message and sending it as a regular OLSR message. The PAA-server must confirm that it has received the message from the requester by replying with a Test Confirm message. If a requester does not receive such a confirmation message, the emitted Address Test is not considered flooded and another Address Test message is broadcasted or multicasted immediately.

An OLSR daemon extended with a PAA-plugin that receives an Address Test message, is to forward this link-local if the node has received a Forward Request (figure 12.3) within a given time interval. Any node in the process of configuration, broadcasts or multicasts such forward request messages regularly. This is to make sure configured nodes within transmission range of any unconfigured host will forward all received Address Test messages link-local.

If a node in the process of configuration, receives an Address Test originating from another unconfigured node and this message contains the address the local node has been offered, it is considered an address conflict. This is because some other node (the sender of the Address Test message) is in the process of configuring itself with the same address the local node was offered. The node will then restart the configuration process by sending a new Address Request.

12.4 Implementation

The Pro-Active Auto-configuration solution is implemented for use with olsrd. Parts of the protocol is currently patent pending [14] by Thales Communications AS, and therefore the source code is not publicly available as of yet.

In the following sections we will look into the PAA server, PAA client and the olsrd plugin in detail.