An example of a configuration session

Figure: The generic PAA packet.
\includegraphics[width=2.8in]{gfx/paa-header.eps}
Figure: The Forward Request message.
\includegraphics[width=2.8in]{gfx/paa-fwd-req.eps}
Figure: The Address Request message.
\includegraphics[width=2.8in]{gfx/paa-req.eps}
Figure: The Address Response message.
\includegraphics[width=2.8in]{gfx/paa-offer.eps}
Figure: The Address Test message.
\includegraphics[width=2.8in]{gfx/paa-test.eps}
Figure: The Address Test Confirmation message.
\includegraphics[width=2.8in]{gfx/paa-test-resp.eps}

Figure 12.8 illustrates a configuration session where a new node joins the MANET. In this example, no address conflicts are detected.

Figure: An example of a conflictless PAA IP allocation session.
\includegraphics[width=5.5in]{gfx/paa-example1.eps}
If using IPv4 the unconfigured host configures itself with a random link-local address, if using IPv6 the 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 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.

Andreas 2004-07-29