Example summary of SDN + NFV + Cloud Technology

Reading 1# - SDN/NFV/Cloud Aris CahyadiRisdianto –20132095
SOC – Service Oriented Computing – Spring 2015 Page 1
SDX: A Software Defined Internet Exchange
Internet routing is unreliable, inflexible, and difficult to manage. Internet routing’s problems
result from three characteristics of the Border Gateway Protocol (BGP) which are routing only on
destinationIPprefix, influence onlyoverdirectneighbors,and indirectexpression of policy. The current
routingsystemneedtobe improvedbecause of two reasons.First,Software Defined Networking (SDN)
showsgreatpromise forsimplifyingnetwork managementand enabling new networked services, even
though currently only applies to intra-domain settings such as individual data-center, enterprise, or
backbone networks. Second, the recent resurgence of interest in layer-two Internet exchange points
(IXPs) whichconsistsof asingle switch where each participating network exchanges BGP routes (often
witha BGP route server) anddirectstrafficto otherparticipants overthe layer-two fabric. The aim is to
change wide-areatrafficdeliverybydesigning,prototyping, anddeployingasoftware defined exchange
(SDX) which addressing the following four challenges such as Compelling applications, Programming
abstractions, Scalable operation, and Realistic deployment.
There are four applications that the SDX enables:
 Application-specific peering, SDX could instead install custom rules for groups of flows
corresponding to specific parts of flow space.
 Inbound traffic engineering, SDX install forwarding rules in SDN-enabled switches at an exchange
point, an AS can directly control inbound traffic according to source IP addresses or port numbers.
 Wide-areaserverloadbalancing,SDXcouldannounce anycastprefixes and rewrite the destination
IP address to match the chosen hosting location based on any fields in the packet header
 Redirection through middle boxes, SDN-enabled exchange point can redirect targeted subsets of
traffic through one or more middle boxes.
Virtual SDXswitchabstractionallows eachAScan run SDN applicationsthatspecify flexible policies
for dropping,modifying,and forwardingthe traffic,andthenthe SDXmustthencombine the policies of
multiple ASes into a single coherent policy for the physical switch(es). Inbound policies apply to the
trafficenteringavirtual switch on a virtual port from another SDX participant; outbound policies apply
to the traffic entering a virtual switch on a physical port from the participant’s own border router. The
SDX route server allows each participant to forward traffic to all feasible routes for a prefix (even if it
learnsonlyone) because ithasunique characteristic such as overriding default BGP routes, forwarding
onlyalongBGP-advertisedpaths, groupingtraffic based on BGP attributes, originating BGP routes from
the SDX, and Integrating SDX with existing infrastructure.
SDX runtime system efficiently compiles the policies of all participants into low-level forwarding
rules by minimizing the number of rules in the switches (data-plane efficiency) and minimizing the
computation time under realistic workloads (control-plane efficiency). The policies written by SDX
participantsare abstract policiesthat needtobe joined with the BGP routes, combined, and translated
to equivalentforwardingrules for the physical switch(es). To minimize the number of rules in the SDX
switch,the SDX(1) groupsprefixeswiththe same forwardingbehaviorintoan equivalence class and (2)
implicitly tags the packets sent by each participant’s border router using a virtual MAC address.
Reducing Control-Plane Computation by optimizing initial compilation where SDX can achieve policy
compilation with only three sequential compositions (no parallel compositions) and also tuning the
optimization to handle changes that result from BGP (increment) updates, because BGP updates are
significantly more frequent than changes to the participants’ SDX policies.

The SDX controller implementation has two main pipelines: a policy compiler, which is based on
Pyretic; and a route server, which is based on ExaBGP. It is deployed by creating the environments for
the purposes of demonstrating two applications: application-specific peering and wide-area load
balance.
Performance Evaluation showsthatnumberof prefix groupsissignificantly smallerthanthe number
of prefixes,andthatthe ratioof prefix groupstoprefixesdecreasesasthe numberof prefixesincreases,
indicatinggoodscalingproperties. Also,the numberof forwarding rules increases roughly linearly with
the number of prefix groups. Another important evaluation is faster initial compilation time by
memoizingthe results of partial policycompilationswhichsupportingcachingfor300 participantsat the
SDX and1,000 prefix groups couldrequire acache of about4.5 GB andincremental compilationtimefor
re-computing the tables takes less than 100 milliseconds most of the time.

OpenNF: Enabling Innovation in Network Function Control
Network functions (NFs) or middle boxes, are systems that examine and modify packets and
flowsinsophisticatedways:e.g., intrusiondetectionsystems(IDSs),loadbalancers,cachingproxies, etc.
In parallel,software-definednetworking (SDN) is being used to steer flows through appropriate NFs to
enforce policies and jointly manage network and NF load Together. NFV and SDN can enable an
important class of management applications that need to dynamically redistribute packet processing
across multiple instances of an NF such as NF load balancing and elastic NF scaling. In the context of
such applications, “NFV + SDN” can help achieve three important goals: (1) satisfy tight service level
agreements (SLAs) on NF performance or availability; (2) accurately monitor and manipulate network
traffic; and (3) minimize NF operating costs.
OpenNF is a control plane architecture that provides efficient, coordinated control of both
internal NF state and network forwarding state to allow quick, safe, and fine-grained reallocation of
flowsacrossNF instances. There are three majorchallenges in designing OpenNF which are addressing
race conditions, bounding overhead, and accommodating a variety of NFs with minimal changes.
OpenNFallowscontrol applicationsto closely manage the behavior and performance of NFs to
satisfy high level objectives. Based on NF output or external input, control applications will (1)
determine the precise setsof flowsthatspecificNFinstancesshould process,(2) direct the controller to
provide the neededstate ateach instance,includingbothflow-specific state and state shared between
flows,and(3) ask the controllertoprovide certainguarantees onstate and state operations. Two novel
schemes to overcome underlying race conditions during re-allocating in progress flows: (1) an event
abstraction that the controller uses to closely observe updates to state or to prevent intended known
updates, and (2) a two phase forwarding state update scheme.
OpenNF’ssouthboundAPIdefines a standard NF interface for a controller to request events or
the export or import of internal NF states. The design of OpenNF’s southbound API must identify
commonalities in how internal state is allocated and accessed across various NFs which required
examination for several types of NFs from a variety of vendors, including: NATs, IDSs, load balancers,
caching proxies, WAN optimizers, and traffic monitors. And then leverage the taxonomy to design a
simple APIforNFsto export and import pieces of state; it requires minimal NF modifications. By using
well-defined notion of a flow (e.g., TCP or UDP connection) and our definition of state scope, allow a
controllertospecifyexactlywhichstate to export or import. OpenNF uses two mechanisms to prevent
and observe updates: (1) havingNFsgeneratepacket-receivedeventsforcertainpackets—the controller
tells the NF which subset of packets should trigger events—and (2) controlling how NFs should act on
the packets that generate events—process, buffer, or drop them.
OpenNF’snorthboundAPIallowscontrol applicationstoflexibly move,copy,orshare subsets of
state between NF instances, and to request important guarantees, including loss-freedom, order
preservation, andvariousformsof consistency.This OpenNF’s move operation transfers both the state
and input(i.e., datatraffic) foraset of flows from one NF instance to another instance. OpenNF’s copy
and share operationsaddressapplications’ needforthe same state to be readable and/orupdateable at
multiple NF instances and, potentially, for updates made at one instance to be reflected elsewhere.
OpenNF’scopyoperationis implemented using the get and put calls from the southbound API. Strong
and strictconsistencyare more difficulttoachieve because state reads and updates must occur at each
NF instance in the same global order. For strict consistency this global order must match the order in

whichpacketsare receivedby switch.Forstrongconsistencythe global order may differ from the order
in which packets were received by switch, but updates for packets received by a specific NF instance
must occur in the global order in the order the instance received the packets. Both cases require
synchronizing reads/updates across all NF instances that are using a given piece of state.
Using OpenNF, there are two control applications written for several of the scenarios which
relatively simple to implement: (1) high performance network monitoring – monitor CPU load for
unbalanced load, (2) Fast failure Recovery – hot standby IDS for consistently copy state, and (3)
Selectively invoking advanced remote processing – monitor outdated browser agent. The
implementationof OpenNFprototype consistsof acontroller that implements our northbound API and
several modifiedNFs—Bro,PRADS, Squid, and iptables – that implement our southbound API. The NFs
use a shared library for communicating with the controller.
The evaluationof northbound are operations efficiency guarantees requested on state or state
operations andexamine the benefitsthisflexibility enables by using the copy operation with the Squid
caching proxy. Southbound API evaluations are the time required to export and import state at NFs
directly impacts how quickly a move or copy operation completes and how much additional packet
latency is incurred when share is used. And then evaluate the efficiency of OpenNF’s southbound
operations for several of the NFs we modified.

Ananta: Cloud Scale Load Balancing
A multi-tenantloadbalancerservice is a fundamental building block of such multitenant cloud
environments. As a cloud provider, we have seen that cloud services put huge pressure on the load
balancer’s control plane and data plane. In our experience, the data plane and control plane demands
drove our hardware loadbalancersolutionintoanuntenablecornerof the design space, with high cost,
withSLA violationsandwithload balancing device failures accounting for 37% of all live site incidents.
Anantais a scalable software loadbalancerandNATthatis optimizedformultitenant clouds.Itachieves
scale,reliabilityand anyservice anywhere viaanovel division of the data plane functionality into three
separate tiers. The topmosttierroutersprovide loaddistributionatthe networklayer(layer-3) basedon
the Equal CostMulti Path (ECMP) routing protocol. The second tier, a scalable set of dedicated servers
for loadbalancing, calledmultiplexers (Mux),maintainconnection flow state in memory and do layer-4
loaddistributiontoapplicationservers.A thirdtierpresentinthe virtual switchoneveryserverprovides
stateful NAT functionality.
The main contributions are identifying the requirements for a cloud-scale solution for layer-4
load balancing, providing design, implementation and evaluation to meet scale, performance and
reliability requirements, and then providing measurements and insights from running in a large
operational Cloud.
One of the design principles is Scale-out In-network Processing or horizontal scaling model is
one where more bandwidth canbe handledbysimply adding more devices of similar capacity. Routers
scale out because they do not maintain any per-flow state that needs synchronization across routers
and therefore one can add or remove additional routers easily. Moreover, the design leverages the
distributed scalable platformandoffloadssignificantdataplane andcontrol plane functionality down to
the hypervisor in end systems.
The Architecture is a loosely coupled distributed system comprising three main components
which are Ananta Manager (AM), Multiplexer (Mux) and Host Agent (HA). The Ananta Manager (AM)
implementsthe control plane byexposing an API to configure VIPs for load balancing and SNAT. Based
on the VIPConfiguration,itconfigures the Host Agents and Mux Pools and monitors for any changes in
DIP health. The Multiplexer(Mux) handlesall incomingtraffic whoresponsible forreceivingtrafficforall
the configuredVIPsfromthe router and forwarding it to appropriate DIPs. Each instance of Ananta has
one or more setsof Muxescalled Mux Pool.HostAgentis presentonthe hostpartitionof every physical
machine that is served by Ananta. The Host Agent is the key to achieving DSR and SNAT across layer-2
domains. Anantaisa multi-tenantloadbalancerandhence tenantisolation is an essential requirement
which can be interpreted as total CPU, memory and bandwidth resources based on their weights for
each tenant. The weights are directly proportional to the number of VMs allocated to the tenant.
In order to achieve a high degree of concurrency, AM implemented using a lock-free
architecture similar to SEDA and it maintains high availability using Paxos. Mux has two main
components — a kernel-mode driver and a user-mode BGP speaker. The kernel-mode driver is
implementedusingthe windows Filtering Platform (WFP) [30] driver model. The Host Agent also has a
driver component that runs as an extension of the Windows Hyper-V hypervisor’s virtual switch.
Micro-benchmarks evaluation measure the effectiveness of Fastpath and its impact on host
CPU, and also we conduct testing to show the ability to isolate inbound packet and outbound SNAT

abuse. Real World Data evaluation shows that Ananta serves 99% of the SNAT requests locally by
leveragingportreuse andSNATpre-allocation.The average availability overa24-hr periodacross all test
tenants was 99.95%, with a minimum of 99.92% for one tenant and greater than 99.99%. For Scale at
control plane, Ananta ensures that VIP configuration tasks required median time around 75 ms, while
the maximumtime around 200 seconds. Fordata plane scale,the total uploadthroughput achievedby a
single flowMux is800Mbps throughputand the packetprocessing is 220Kpps using a single x64, 2.4GHz
core.

Example summary of SDN + NFV + Cloud Technology

More Related Content

What's hot (19)

Similar to Example summary of SDN + NFV + Cloud Technology (20)

Recently uploaded (20)

Example summary of SDN + NFV + Cloud Technology