In the productive scenarios of virtualized network function (vnf), active network elements are always accompanied by the software upgrade, due to the off-the-shelf ones cannot provide satisfactory functionalities, some high-level reasons e.g. business upgrading. Thus original network elements have to be re-formulated and adapt to their future work. First, we should say thanks to the evolution brought by vnf. Its appearance actually gives us a new chance to replace traditional hardware-based upgrades with software style, increasing the cost-efficiency as well the technology iterative speed.

Second, the Click-driven platform has been one of the most popular vnf platforms that allow flexible composition of packet-processing functionalities. It has been used in a number of application prototypes such as a router for the future Internet architecture, redundant traffic elimination systems, a scalable middlebox platform, and a cluster-based high performance software router, just to name a few.

The key strength of Click is its inherent extensibility for functional components: a new feature can be easily implemented by module integration. While Click’s flexible design has satisfied many demands for rapid prototyping, its internal architecture has not caught up with the potential software upgrade. Traditional Click-driven upgrades for network elements have some significant drawbacks as following:

D1: Integrating new modules with upgraded network elements is a time-consuming processing. During this processing, however, the packet-processing functionalities are out-of-work. This will bring several insufficiencies including the inability to elastically scale out network functions on demand and to quickly recover from downtime.

D2: With no mechanism to reconstruct lost states for network elements, stateful functionalities are unable to correctly handle packets after upgrade, leading to service disruption. This may involve with states such as connection information in a stateful firewall, substring matches in an intrusion detection system, address mappings in a network address translator, or server mappings in a stateful load balancer.

D3: Development of new modules requires intimate knowledge of complex library implementation, let alone correctly deal with states. It is frustrating that the visibility of current upgrade is pretty poor and the learning curve is rather steep.

In order to address these problems and satisfy practical requirements about stateful network element upgrades, we present CLICK-UP, which is, the effort towards software upgrades of Click-driven stateful network elements.

For one thing, we notice the root of D1 is that software integration of upgrades didn’t stick religiously to the service context.A series of functionality-neutral modules are redundantly shipped with essential modules. Thus, we argue that explicitly integrating essential modules in a service context aware manner can cut down upgrade overheads. (solution of D1). For another, current Click modularity still poses severe challenges in maintaining network states during software upgrades. Instead of expecting the operators who originate network elements to manage any problem, we argue that a state synchronization scheme which enforcedly integrated into modules is essential. (solution of D2). At last, as the exoskeleton of Click modularity, we argue that a lightweight runtime library of software upgrades is also necessary to be embraced for clarifying service semantics, simplifying tedious orchestration and unifying interfaces. (solution of D3).

Besides the agile, stateful and tractable features on software upgrades, CLICK-UP also stands out because of its strong compatibility. The seamless instead of invasive integration style can be easily compatible with current Click-driven techniques, such as ClickOS, CliMB and FastClick.