Address Assignment

Summary

Introduction:

Because there are a number of inter-dependencies between interfaces and because different Device configurations can require different TCP/IP address and route assignment, it was deemed essential that the logic for controlling IP address and Route assignment be consolidated into a single module. WARM serves the purpose of properly adding and removing TCP/IP addresses and Routes to Weave related IP interfaces as those interfaces transition from active<->inactive.

WARM is intended to be configured at compile time via WarmProjectConfig.h and WarmConfig.h. WarmProjectConfig.h must accurately reflect the supported features of the device upon which WARM will execute.

WARM is a portable module that limits its dependency on how a TCP/IP stack and Thread Interface are configured. For this purpose WARM relies on a Set of Platform API's which must be implemented by the Platform Integrator. Furthermore, the Platform Integrator is responsible for making the various nl::Warm API calls from appropriate execution points within the Platform code base.

Theory of Operation:

The Platform code base will call nl::Warm API's to announce a change of State for related features such as the WiFi interface and Thread interface. A call to any of these nl::Warm API's may result in a call by WARM to Platform::RequestInvokeActions(). Platform::RequestInvokeActions() must be implemented to perform the necessary operations that will call Warm::InvokeActions(). This process at first glance may appear un-necessarily indirect. Why wouldn't WARM call InvokeActions directly? The answer to that question, is to allow for any task in a multi-tasking system to call the nl::Warm State Change API's, and to provide a mechanism so that only a specific task will call the Platform:: API's. After taking the Platform requirements into consideration, the Platform Integrator may choose to implement Platform::RequestInvokeActions() so that it posts an event to the appropriate task that will react by calling Warm::InvokeActions(). If, for a given platform, it is decided that no such multi-tasking concerns exist, Platform::RequestInvokeActions() can be implemented to call Warm::InvokeActions() directly.

When Warm::InvokeActions() is called the WARM logic will examine the current System State and make any necessary Platform:: API calls in order to bring the address and routing State in line with the System and Configuration State. These calls are made in a pre-defined order and if any of these API's return kPlatformResultInProgress, execution of the ordered list will suspend and exit. Furthermore, when one of these API's returns kPlatformResultInProgress, it is interpreted that the operation will complete asynchronously and that the WARM logic should wait for that operation to complete. Upon operation completion, the Platform code should call Warm::ReportActionComplete(), passing in a result of kPlatformResultSuccess or kPlatformResultFailure. Upon receiving this call the WARM logic will again call Platform::RequestInvokeActions() in order to restart execution of the ordered action list.

In this way WARM does not require its own task but can instead rely on another task to call into Warm as appropriate. Additionally, any task may call one or more of the System State change API's, thus simplifying integration.