E2

A Framework for NFV Applications

By moving network appliance functionality from proprietary
hardware to software, Network Function Virtualization promises
to bring the advantages of cloud computing to network packet
processing. However, the evolution of cloud computing
(particularly for data analytics) has greatly benefited from
application-independent methods for scaling and placement that
achieve high efficiency while relieving programmers of these
burdens. NFV has no such general management solutions. To this
end, we present E2 -- a scalable and application-agnostic
scheduling framework for packet processing.

Architecture

E2 is made up of three main system components: the E2 Manager
which orchestrates overall operation of the cluster, a Server
Agent that manages operation within each server, and the E2
Dataplane (E2D) that acts as a software traffic processing layer
beneath the NFs at each server. The E2 Manager interfaces with
the hardware switch(es) through standard switch APIs and with
the Server Agents.

Pipelets

E2 provides a declarative interface through which the global SDN
controller tells each E2 cluster how traffic should be
processed. It does so by specifying a set of policy statements
that we call pipelets. Each pipelet defines a traffic class and
a corresponding directed acyclic graph (DAG) that captures how
this traffic class should be processed by NFs.

Dynamic Scaling

E2 provides hooks for NFs to report on their instantaneous load,
and the E2D detects overloads based on queues and processing
delays. When the E2D detects overload, it splits the overloaded
NF instance to lighten the load. This involves placing the new
instances, setting up new interconnection state, and considering
the affinity requirements of flows, so it is not to be done
lightly. Pictured above is the traffic load at an overloaded NF
instance and its corresponding new instance with migration
avoidance enabled (original NF splits at 2s).

Migration Avoidance

E2 employs a novel migration avoidance strategy in which the
hardware and software switches act in concert to maintain flow
affinity. This scheme does not require state migration and is
designed to minimize the number of flow table entries used on
the hardware switch to pass traffic to NF instances