Architecture Overview: As shown in the following figure, the framework of CLICK-UP is divided into the top-down three layers. The three layers collectively constitute the software upgrade of Click-driven stateful network elements.

In contrast with native processing, operators directly interact with the DAG orchestrator and formulate their required atom-based pipeline in a view of runtime library, getting ride of previous inefficient manual manners. During the alternative processing, all the dependency of essential modules are fully explored according to the determined service context in DAG pipeline. This can help in cutting down unnecessary overheads of module integration, and speed up the recovery from downtime as far as possible.

The reconstruction scheme for lost states is implemented by periodic synchronization between modules and persistent storage, which respectively locates at kernel space and user space. With recovery bootstrap integrated inside all the modules, the states can thus be recaptured after upgrade.

Workflow: The procedures for CLICK-UP to handle a software upgrade of Click-driven stateful network elements are shown as arrow direction in the above figure:

• (1) the dashboard exposes DAG orchestrator to operators, allowing operators to define their upgrade needs as a DAG. The DAG is based on well-known semantics and consists of a series of pipeline processing related atom functionalities as well their required service states.
• (2) the DAG should be parsed to a set of Click modules (called elements), and its new state collection is integrated into corresponding modules. All the modules have a state synchronization mechanism and a state reconstruction bootstrap.
• (3) the modules are complied, built into kernel space, and the persistent storage in user space is initialized with new version number, meanwhile sending back former version related states.
• (4) the new configuration is created and upgraded network element is reboot from downtime with former service states fulfilled by a recovery bootstrap.

Atom-based Orchestration: As shown in the above figure, the DAG orchestration of CLICK-UP is based on a series of core functionalities called atom functionalities, e.g. packet parsing, payload modification, and the like, each of which with well-known semantics. Operators can thus represent their upgrade needs as a DAG with stateful or stateless atoms linked. Via exploring all the dependency of essential modules, runtime library will parse the atom-based graph to a module-based graph that has identical service contexts and pipeline functionalities. This realizes an unified interface for operators, at the same time provides the compatibility between CLICK-UP and other Click-driven techniques that based on module-style graph. Moreover, since the orchestration sticks religiously to the service context, thus a series of functionality-neutral modules won’t shipped with essential modules any more, significantly reducing the integration time.

Runtime Library: As shown in the above figure, the runtime library of CLICK-UP consists of a set of interfaces exposed to the orchestration. They specify available atom functionalities as well the mapping between atoms and module category. These interfaces also provide a state management toolset to deal with the state synchronization and the reconstruction bootstrap. Through top-down integration, all the modules of upgraded network elements can thus recover from downtime in an agile manner and take back their service states correctly. Developers can also enlarge current library stack in scalability by implementing new interfaces for new atoms or states, in order to handle the cases that atom-based graph doesn’t fit comfortably within upgrade needs’ range.