Specifying and Placing Chains of Virtual Network Functions
SSpecifying and Placing Chains ofVirtual Network Functions
Sevil Mehraghdam
University of Paderborn33098 Paderborn, GermanyEmail: [email protected]
Matthias Keller
University of Paderborn33098 Paderborn, GermanyEmail: [email protected]
Holger Karl
University of Paderborn33098 Paderborn, GermanyEmail: [email protected]
Abstract —Network appliances perform different functions onnetwork flows and constitute an important part of an operator’snetwork. Normally, a set of chained network functions processnetwork flows. Following the trend of virtualization of networks,virtualization of the network functions has also become a topicof interest. We define a model for formalizing the chaining ofnetwork functions using a context-free language. We processdeployment requests and construct virtual network functiongraphs that can be mapped to the network. We describe themapping as a Mixed Integer Quadratically Constrained Program(MIQCP) for finding the placement of the network functions andchaining them together considering the limited network resourcesand requirements of the functions. We have performed a Paretoset analysis to investigate the possible trade-offs between differentoptimization objectives.
I. I
NTRODUCTION
An operator’s network consists of a large number of interme-diate Network Functions (NFs). Network Address Translators(NATs), load balancers, firewalls, and Intrusion DetectionSystems (IDSs) are examples of such functions. Traditionally,these functions are implemented on physical middle-boxes,which are network appliances that perform functions other thanstandard path discovery or routing decisions for forwardingpackets (RFC 3234 [1]). Middle-boxes are based on special-purpose hardware platforms that are expensive and difficultto maintain and upgrade. Following the trend of virtualizationin large-scale networks, network function that were deployedas middle-boxes are also being replaced by
Virtual
NetworkFunctions (VNFs).Typically, network flows go through several network func-tions. That means a set of NFs is specified and the flows traversethese NFs in a specific order so that the required functions areapplied to the flows. This notion is known as network functionchaining or network service chaining [2], [3].NFs can modify the traversing network flows in differentways. For example, a Deep Packet Inspector (DPI) can split theincoming flows over different branches according to the type ofthe inspected packets, each branch having a fraction of the datarate of the incoming flow. Firewalls can drop certain packets,resulting in flows with a lower data rate than incoming flows.A video optimizer can change the encoding of the video, whichcan result in a higher data rate. There can also be a dependencyamong a set of NFs that should be applied to the traffic in anetwork [4], which requires special attention to the order oftraversing the functions in chaining scenarios. For instance, if This work is partially supported by the International Graduate School“Dynamic Intelligent Systems”. the packets have to go through a WAN optimizer and an IDS,packet inspection by the IDS should typically be carried outbefore the WAN optimizer encrypts the contents. In case thefunctions in a chaining scenario do not have such a dependency,there can be multiple possibilities for chaining them together.Depending on how each function in the chain modifies thedata rate of the flows, different chaining options can havedifferent impact on the traffic in network links, on applicationperformance, or on latency. We address two challenges in thisarea.The first challenge is to formalize a request for chainingseveral NFs together, while considering the possible dependen-cies among them. Upon receiving such a request, the networkoperator has the freedom to chain the functions in the bestpossible way to fit the requirements of the tenant applications.After the logical chaining of functions is specified, the functionsneed to be placed in the operator’s network. In addition to thedependencies within the chains of functions, NFs can also beshared and reused among different applications in the network.The second challenge is hence to find the best placement for thefunctions, considering the requirements of individual requestsas well as the overall requirements of all network applicationsand the combination of requests. We will elaborate on theseconsiderations in the following sections. For example, Figure 1illustrates two different ways of chaining a set of functionstogether, one resulting in a lower average data rate requirementbut higher processing requirements than the other.Traditionally, modifying the way functions are chainedtogether and changing the placement of functions in the networkrequire complex modifications to the network, such as modi-fying the network topology or changing how physical boxesare connected to each other. Network Function Virtualization(NFV) offers more flexibility in network function chaining bysimplifying chaining and placement of NFs and by makingthese changes more practical and achievable in real scenarios.Considering this, we focus on formalizing the chaining requestsand placing the chained functions in the best locations accordingto optimization goals in an operator’s network that supportsNFV. Our solutions are not bound to a specific implementationoption and can be applied to virtualized and non-virtualizedNF chaining scenarios.First, we give an overview of the related work in Section II.In Section III, we define our model for specifying the requestsfor chaining VNFs (given by network administrators or tenants)in a way that different chaining options can be analyzed and theone that fits the optimization goals and network requirementscan be chosen. Based on the chaining possibilities given in therequests, the operator can decide the placement of the functions. a r X i v : . [ c s . N I] J un he preprocessing step required before the functions can beplaced in the network and a heuristic for reducing the runtime ofthe final decision process are described in Section IV. We definea Mixed Integer Quadratically Constrained Program (MIQCP)in Section V for placing the chained VNFs considering thefollowing three objectives: 1) Maximizing remaining data rate;2) minimizing number of used network nodes; 3) minimizingtotal latency over all paths. Finally, we describe the resultsof evaluating our placement and a multi-objective Paretodiscussion in Section VI and conclude the paper in Section VII.II. R ELATED W ORK
A number of standardization activities in the NFV area arecarried out by ETSI and IETF, resulting in a white paper [5]and several drafts like problem statements in NFV [6], [3], usecases [7] and frameworks for network function chaining [8]. Themodel for chaining VNF presented in this paper is compatiblewith the models and architectures proposed in these drafts.Our placement solution for chained NFs can be consideredas an extension to the following two NP-hard problems:Location-Routing Problems (LRP) and Virtual Network Em-bedding (VNE). Location-routing problems [9], [10] aim atplacement of components while reducing the costs in nodes,edges or paths. In these problems, each path has one start pointand one end point. We need to create several paths betweendifferent pairs of NFs and connect these paths to represent thechaining. In this case, the routing problem turns into a multi-commodity flow problem, with inter-commodity dependencies.Virtual network embedding (VNE) problems [11] are similarto our problem in the chaining aspect. Chained NFs can beseen as graphs to be embedded into a substrate network. Theseproblems treat the nodes of the virtual graphs (NFs in our case)independently. In our problem, however, flows from differenttenants can share and reuse NFs for better NF utilization.Similar to the approach of Fuerst et al. [12], we place severalNFs on a single node to reduce inter-location traffic.Joseph and Stoica [13] present a model for describing thebehavior and functionality of a limited number of NFs but it isnot a complete model for VNFs since it does not contain anyinformation about requirements like computational resourcesand their influence on the network traffic. Gember et al. [14]introduce a network-aware orchestration layer for NFs. Ourmodel for chaining VNFs is similar in some aspects, but theirmodel is defined in a data center network, while we focus onan operator’s network with multiple data center sites. Moreover,they do not capture any resource requirements of the functionsapart from processed traffic.NFV is still a concept under investigation and standard-ization of the problem definition and use cases are not yetfinalized. Therefore, we found only a very limited amount ofongoing work related to our research focus. We define ourmodels in a flexible way that can be extended and reinterpretedeasily when more technical details about the chaining scenariosand implementation requirements are available.III. N
ETWORK F UNCTION C HAINING S PECIFICATION
We model the substrate network, where VNF chains aredefined and placed, as a connected directed graph, G =( V, E ) . Some of network nodes are switch nodes , with typical routingand switching capabilities, along with (small) computationalcapacity that can be used for running VNFs, e.g., inside anFPGA in the switch. The remaining nodes are distributed siteswith (much larger) computational capacity. We consider eachof these sites as a large computational unit, called a data centernode , without looking into their internal topology. We definetwo types of computational capacities for the nodes: c d ( v ) and c s ( v ) ( ∀ v ∈ V ) . For today’s switch nodes, c d is zero and forcurrent data center nodes, c s is zero. We define both typesof capacities for all nodes to keep our model open to futureextensions. For example, in future, switches might be equippedwith general-purpose processing capabilities, leading to c d > for switch nodes. The network links are directed edges in thegraph, with data rate d ( v, v (cid:48) ) and latency l ( v, v (cid:48) ) for everyedge ( v, v (cid:48) ) ∈ E .The following information about offered network functionsis available and maintained by the network operator: • Set F of available network functions. • Computational resource requirements p ( f ) ( ∀ f ∈ F ) ofan instance of the VNF f per each request, whether it isplaced on a switch node, p s ( f ) , or on a data center node, p d ( f ) . Some functions can be placed either on a switchor on a data center node, e.g., a load balancer ( p d > and p s > ), and some can be placed only on a data centernode, e.g., a Virtual Machine (VM) implementing a videooptimizer ( p d > and p s =0 ). • Maximum number of instances of the VNF that can bedeployed, n inst ( f ) , e.g., determined by the number oflicenses that the operator owns for the VNF. • Number of chaining requests an instance of a VNF canhandle, n req ( f ) . For example, an anti-virus function canbe configured once and used for every chain that needsthis function, (i.e., number of requests it can handle is onlylimited by hardware specifications), but a firewall mightneed specific configurations for each chaining request andone instance of this function cannot be shared betweentwo chains (i.e., n req =1 ).A network operator receives deployment requests for dif-ferent partially ordered sets of VNFs. In these requests, anetwork administrator or the tenant specifies which of theoffered functions should be applied in which order to givenflows between fixed start and end points. A deployment requestcontains the following information: • Set U of individual requests for instances of availablenetwork functions. • Chaining request , denoted as c , for specifying the desiredorder of functions. • For each branch leaving a requested function, the percent-age of incoming data rate it produces given as an orderedset r ( u ) ( ∀ u ∈ U ) for each function. For example, for aDPI that is expected to send 20% of the incoming packetstowards a video optimizer and 80% towards a firewall thisset is given as { . , . } . • Set A of fixed start and end points for the flows, e.g., anapplication VM deployed in a data center node or a routerthat connects the operator’s network to external networks. • Set A pairs ⊆ A × A of pairs of start and end points belongingto different flows. Location of start and end points of flows in the network,loc ( a ) ∈ V ( ∀ a ∈ A ) . • Initial data rate entering the chained functions, d in . • Maximum tolerable latency between the start and endpoints of flows, l req ( a, a (cid:48) ) ( ∀ ( a, a (cid:48) ) ∈ A pairs ) .We define a context-free language for formalizing thechaining requests. Using this language, complex requests canbe composed that contain the order of functions to be appliedto network flows. Every chaining request is formalized usingdifferent types of modules . The elements of this language arethe following modules: • An individual function or a start/end point for the chain • A set of functions that should be applied to network flowsin an optional order ( optional order module) • A function that splits the incoming flows into multiplebranches that consist of different modules ( split module) • A function that splits the incoming flows into multiplebranches that all consist of the same module ( parallel module)Several (possibly nested) modules can be placed sequentiallyin the chaining request to reflect a simple and fixed order amongdesired functions. G =( V , T , P , S ) is the grammar for this language. V isthe set of non-terminals consisting of the following vari-ables: (cid:104) modules (cid:105) , (cid:104) mod (cid:105) , (cid:104) order (cid:105) , (cid:104) optorder (cid:105) , (cid:104) split (cid:105) , (cid:104) parallel (cid:105) , (cid:104) term (cid:105) , (cid:104) moremod (cid:105) , (cid:104) moreterm (cid:105) , (cid:104) num (cid:105) . T = U ∪ A ∪ D ∪{ , , . . . , n }∪{ (cid:15) } is the set of symbols ofthis language where (cid:15) is the empty string. A subset of naturalnumbers from to n is required for displaying the number ofbranches that leave a VNF. n can be defined as a number largerthan the maximum number of outgoing branches in all requests.This upper bound is necessary because the set of symbols hasto be a finite set. D is the set of delimiters consisting of thefollowing symbols: . , ; { } ( ) [ ]. S = (cid:104) start (cid:105) is the start symbolof the grammar and P is the set of production rules: (cid:104) start (cid:105) ::= (cid:104) modules (cid:105) (1) (cid:104) modules (cid:105) ::= (cid:104) order (cid:105) (cid:104) modules (cid:105) | (cid:104) mod (cid:105) (2) (cid:104) order (cid:105) ::= (cid:104) mod (cid:105) · (3) (cid:104) mod (cid:105) ::= (cid:104) optorder (cid:105) | (cid:104) split (cid:105) | (cid:104) parallel (cid:105) | (cid:104) term (cid:105) (4) (cid:104) optorder (cid:105) ::= ( (cid:104) term (cid:105) (cid:104) moreterm (cid:105) ) (5) (cid:104) split (cid:105) ::= (cid:104) term (cid:105) [ (cid:104) modules (cid:105) (cid:104) moremod (cid:105) ] (6) (cid:104) parallel (cid:105) ::= (cid:104) term (cid:105) { (cid:104) term (cid:105) (cid:104) moreterm (cid:105) ; (cid:104) modules (cid:105) ; (cid:104) num (cid:105) } (7) (cid:104) moreterm (cid:105) ::= , (cid:104) term (cid:105) (cid:104) moreterm (cid:105) | (cid:15) (8) (cid:104) moremod (cid:105) ::= , (cid:104) modules (cid:105) (cid:104) moremod (cid:105) | (cid:15) (9) (cid:104) term (cid:105) ::= u | u | . . . | u | U | | a | a | . . . | a | A | (10) (cid:104) num (cid:105) ::= 1 | | | . . . | n (11) Rule 4 expresses the 4 different types of modules. Werefer to the requests for using an instance of a VNF and thestart/end points of chains as terms in this grammar. Rule 3is used for defining a fixed and simple order among modules.Optional order modules are produced by Rule 5. Such a moduleconsists of a set of functions that should be applied to the flowsand the order of traversing these functions can be chosen bythe operator. A request for a split module can be expressedby Rule 6, where the splitting function is a term and themodules on different branches can be any of the defined typesof modules. Finally, a request for a parallel module can beproduced using Rule 7. Parallel modules have 4 parts: 1) The function that splits the flows into different branches; 2) a set offunctions, including the splitting function, that can be placedin an arbitrary order before the flows reach the modules ondifferent branches (optional); 3) the module that should bereplicated for the given number of times on multiple branches;4) number of outgoing branches from the splitting function(number of times the module mentioned in part 3 should bereplicated).A VNF chaining request formalized this way is a repre-sentation for a connected directed graph that we refer to as a
VNF graph . The required functions and also the start and endpoints of the flows are nodes of the VNF graph ( U ∪ A ). Thestart/end points are mapped to fixed locations in the substratenetwork and the location for the VNFs has be to determined.Each one of the directed links in the set of edges in this graph( U pairs ) represents the order of traversing the functions. Everylink in the VNF graph has to be mapped to a path (consistingof at least of edge) in the substrate network graph. We define atwo-step process for deploying the chained functions based onthe deployment requests: processing the requests and buildingVNF graphs, and finding the optimal placement for the VNFgraphs based on optimization goals in the operator’s network.We describe this process in the following sections.IV. P ROCESSING D EPLOYMENT R EQUESTS
The network operator receives deployment requests forplacing chained VNFs in the network, where chaining requestsare formalized using the language described in Section III. Theoperator needs to find the best placement for several chainedfunctions based on multiple deployment requests. The first stepis to build VNF graphs for every deployment request.For each deployment request, the chaining request ( c ) isfirst parsed using the grammar of the language (Section III).The parser matches and stores different modules of the request.Modules consisting of a single function or start/end point offlows are stored as a node of the VNF graph. For the moduleswhere a number of functions can be ordered arbitrarily ( optionalorder and split modules) every possible permutation of the setof functions is computed and stored separately as a candidatefor being a part of the final VNF graph. Moreover, for everymatch of a parallel module, the module on the branches isreplicated for the requested number of times and stored as apart of the graph. Using the specified orders and depending onthe modules that build the chaining request, at the end of theparsing process different modules are stored as parts of the VNFgraph with explicit orders among all functions. Parts of thegraphs are then connected using directed links that represent thesequence of modules in the request. Considering the differentpermutations for different modules, at least one VNF graphis built out of each chaining request. Using the rest of theinformation in the deployment request and the informationavailable about the network functions, computational resourcerequirements are assigned to the nodes of the VNF graphs. Thelinks of the graphs are also annotated by data rate and latencyrequirements.Each of the graphs that can be created from a requestcan have different characteristics in terms of average datarate required for its links and number of VNF instances. Forexample, the Load Balancer (LB) in Figure 1 splits the incoming f LB f f f (a) LB f f f f f f f f f (b)Fig. 1. Two of the chaining options for a set of functions flows into three different branches to balance traffic over threeinstances of f . The ratio of outgoing to incoming data rate inall VNFs except the LB is 1. Placing this load balancer earlierin the directed graph, as in Figure 1b, reduces the data rateof the links on each branch after it. But it also means thatup to three instances of all subsequent VNFs will be requiredon the paths towards f . Each of these instances has a lowerprocessing requirement than the instances in Figure 1a thatshould handle higher data rates.For every module that requests n ∈ N ≥ VNFs with optionalorder among them (i.e., optional order or parallel module), n ! permutations are computed and stored. For a chain that containsmultiple optional order or parallel modules, the number ofdifferent ways for combining these modules is the productof the number of permutations for different modules. Forexample, if a chaining request contains one optional ordermodule with 3 different VNFs and one parallel module inwhich 4 VNFs can be placed with an arbitrary order, a totalof · combinations of these modules is possible. Thatmeans, for finding the best combination, the placement step inthe deployment process has to be done 144 times so that theresults can be compared and the option that fits the networkrequirements can be chosen. Our deployment process createsthe VNF graphs for each deployment request separately, andthen all possible combinations of VNF graphs from differentrequests would have to be computed and sent to the placementstep. As the number of combinations increases very quickly inthe number of deployment requests and the number of functionsin each request, trying every possible combination becomesimpractical.We propose a heuristic for choosing one of the possiblecombinations, respecting the optimization goals in an operator’snetwork. In this method, instead of computing all possiblepermutations of the sets of functions with arbitrary orders,we sort the functions in ascending order according to theirratio of outgoing to incoming data rate. The function thatreduces the data rate of the flows the most is placed beforeall other functions in the module. Therefore, each deploymentrequest results in one single VNF graph and the final inputto the placement step is a disconnected graph consistingof the VNF graphs from different requests. We define theplacement optimization problem in Section V for finding thebest placement in the substrate network for the combinedVNF graphs. We optimize the placement for a new set ofdeployment requests by mapping all new requests together intoa network that may or may not contain a previous deploymentof chained functions. This can be extended to adapt the existingdeployments to the new state of the network.For each deployment request, our heuristic chooses a VNFgraph that has the minimum overall data rate requirementamong all possible VNF graphs for that request. This method TABLE I. R
EQUIRED INPUT FOR PLACEMENT
Domain Parameter Description ∀ v ∈ V c d ( v ) Data center computational resources in vc s ( v ) Switch computational resources in v ∀ ( v, v (cid:48) ) ∈ E d ( v, v (cid:48) ) Data rate capacity on ( v, v (cid:48) ) l ( v, v (cid:48) ) Latency of ( v, v (cid:48) ) ∀ f ∈ F n inst ( f ) Number of allowed instances for fn req ( f ) Number of requests f can handle p d ( f ) Data center resource demand of fp s ( f ) Switch resource demand of f ∀ u ∈ U t ( u ) Requested function ∀ ( u, u (cid:48) ) ∈ U pairs d req ( u, u (cid:48) ) Data rate demand of ( u, u (cid:48) ) ∀ a ∈ A loc ( a ) Network node where a is placed ∀ ( a, a (cid:48) ) ∈ A pairs paths ( a, a (cid:48) ) All possible paths between a and a (cid:48) l req ( a, a (cid:48) ) Maximum latency between a and a (cid:48) TABLE II. D
ECISION VARIABLES
Domain Variable Description ∀ u ∈ U, ∀ v ∈ V m u,v u mapped to v ms u,v u mapped to a switch function on v md u,v u mapped to a data center function on v ∀ f ∈ F, ∀ v ∈ V i f,v
An instance of f mapped to v ∀ ( v, v (cid:48) ) ∈ E, ∀ x, y ∈ V, ∀ ( u, u (cid:48) ) ∈ U pairs e v,v (cid:48) ,x,y,u,u (cid:48) ( v, v (cid:48) ) belongs to path between x and y ,where u and u (cid:48) are mapped to ∀ v ∈ V used v At least one request mapped to v ∀ ( v, v (cid:48) ) ∈ E remdr v,v (cid:48) Remaining data rate on ( v, v (cid:48) ) ∀ ( u, u (cid:48) ) ∈ U pairs lat u,u (cid:48) Latency of the path between u and u (cid:48) might discard some graphs that are optimal in terms of totalnumber of required VNF instances or the total latency. However,the gain in execution time can compensate for this deviationfrom optimality. We have performed a Pareto analysis ofthe placement optimization problem to show the trade-offsbetween different optimization objectives, which we present inSection VI.V. P LACEMENT OF C HAINED N ETWORK F UNCTIONS
There can be several metrics that the operator might needto optimize. We formulate the placement optimization problemas an MIQCP with respect to data rate, number of usednetwork nodes, and latency. Input to the placement step is thecapacity of network nodes and links, requirements of differentnetwork functions, and the combined VNF graph from therequest processing step. Table I shows an overview of the inputparameters to the placement optimization problem.Decision variables are described in Table II. “remdr”and “lat” are continuous variables and all other ones arebinary indicator variables. We show the constraints of theoptimization problem in Section V-A and the objective functionsin Section V-B.
A. Constraints
In this section, we describe the constraints of the placementoptimization problem in 3 parts: 1) Placing functions innetwork nodes and mapping requests for using instances ofnetwork functions to these nodes; 2) creating paths betweenfunctions; 3) collecting metric values. Placement and pathcreation constraints have a clear separation that facilitatesextending the model in either part without causing problems inthe other part. Besides, necessary ties between these parts arealso carefully defined, for example, using the decision variable e , to build a consistent and uniform model for placing functionsand chaining them together optimally. ) Network Function Placement Constraints: ∀ u ∈ U : (cid:88) v ∈ V m u,v =1 (12) ∀ a ∈ A : m a, loc ( a ) =1 (13) ∀ f ∈ F, ∀ v ∈ V : (cid:88) u ∈ Ut ( u )= f m u,v ≤M· i f,v (14) i f,v ≤ (cid:88) u ∈ U,t ( u )= f m u,v (15) ∀ u ∈ U, ∀ v ∈ V : ms u,v + md u,v =1 (16) ∀ u ∈ U, ∀ v ∈ V, p s ( t ( u ))=0 , p d ( t ( u )) (cid:54) =0 : ms u,v =0 (17)md u,v =1 (18) ∀ v ∈ V : (cid:88) u ∈ U m u,v · md u,v · p d ( t ( u )) ≤ c d ( v ) (19) (cid:88) u ∈ U m u,v · ms u,v · p s ( t ( u )) ≤ c s ( v ) (20) ∀ f ∈ F : (cid:88) v ∈ V i f,v ≤ n inst ( f ) (21) ∀ v ∈ V, ∀ f ∈ F : (cid:88) u ∈ U,t ( u )= f m u,v ≤ n req ( f ) (22) Every request for using a VNF should be mapped to exactlyone node (Constr. 12). Start/end points of the flows are fixedin the network, so ∀ a ∈ A , m a, loc ( a ) is not a decision variable.However, values of m are also used in path creation constraintsand there are paths to be created between the start/end pointsand the rest of the chained functions. Therefore, for these points m is defined similar to the functions (Constr. 13). Constraints14 and 15 are complementary to each other and avoid startingan instance of a function on network nodes without mappingany requests to them. They also make sure that a request ismapped to a node only if an instance of the required functionis placed on that node. M∈ N is a number larger than the sumon the left side of the inequality in Constr. 14 (a so-called“big M” constraint). Constr. 16 ensures that a request is mappedto a node either as a switch function or a data center functionbut not both. For every u that is a request for a VNF thatcan only be placed on a data center, ms u,v is set to zero andmd u,v is set to one. This constraint is necessary for correctnessof Constr. 19 and 20 when the function has a non-zero valuefor both types of computational resource requirements (i.e.,can be placed either on a switch node or on a data centernode). Computational resource requirements of all requestsmapped to a node should be less than or equal to availableresources in that node. In data center nodes only the datacenter resource requirements of the functions mapped to themare considered and in switch nodes only the switch resourcerequirements (Constr. 19 and 20). Variables m , md, and msare binary decision variables and the product of two binaryvariables can easily be linearized. Therefore, Constr. 19–20 canbe considered as quadratic constraints instead of cubic. Forevery function f , up to n inst ( f ) instances can be placed inthe network (Constr. 21). Finally, Constr. 22 ensures that everyinstance of f handles no more than n req ( f ) requests.
2) Path Creation Constraints: ∀ ( v, v (cid:48) ) ∈ E, ∀ x, y ∈ V, ∀ ( u, u (cid:48) ) ∈ U pairs : e v,v (cid:48) ,x,y,u,u (cid:48) ≤ m u,x · m u (cid:48) ,y (23) ∀ ( u, u (cid:48) ) ∈ U pairs : (cid:88) ( x,v ) ∈ E,y ∈ V e x,v,x,y,u,u (cid:48) · m u,x · m u (cid:48) ,y =1 (24) (cid:88) ( x,v ) ∈ E,y ∈ V e x,v,x,y,u,u (cid:48) · (1 − m u,x · m u (cid:48) ,y )=0 (25) (cid:88) ( v,y ) ∈ E,x ∈ V e v,y,x,y,u,u (cid:48) · m u,x · m u (cid:48) ,y =1 (26) (cid:88) ( v,y ) ∈ E,x ∈ V e v,y,x,y,u,u (cid:48) · (1 − m u,x · m u (cid:48) ,y )=0 (27) ∀ ( u, u (cid:48) ) ∈ U pairs , ∀ w, x, y ∈ V : (cid:88) v ∈ V,v (cid:54) = y, ( v,w ) ∈ E e v,w,x,y,u,u (cid:48) = (cid:88) v (cid:48) ∈ V,w (cid:54) = x, ( w,v (cid:48) ) ∈ E e w,v (cid:48) ,x,y,u,u (cid:48) (28) ∀ ( u, u (cid:48) ) ∈ U pairs , ∀ v, x, y ∈ V, x (cid:54) = y : e v,v,x,y,u,u (cid:48) =0 (29) ∀ ( u, u (cid:48) ) ∈ U pairs , ∀ x, y ∈ V, ∀ ( v, v (cid:48) ) , ( v (cid:48) , v ) ∈ E, v (cid:54) = v (cid:48) : e v,v (cid:48) ,x,y,u,u (cid:48) + e v (cid:48) ,v,x,y,u,u (cid:48) ≤ (30) ∀ ( v, v (cid:48) ) ∈ E : (cid:88) ( u,u (cid:48) ) ∈ U pairs , ∀ x,y ∈ V e v,v (cid:48) ,x,y,u,u (cid:48) · d req ( u, u (cid:48) ) ≤ d ( v, v (cid:48) ) (31) ∀ ( a, a (cid:48) ) ∈ A pairs : (cid:88) ( v,v (cid:48) ) ∈ E,x,y ∈ V, ( u,u (cid:48) ) ∈ paths ( a,a (cid:48) ) e v,v (cid:48) ,x,y,u,u (cid:48) · l ( v, v (cid:48) ) ≤ l req ( a, a (cid:48) ) (32) An edge in the network graph belongs to a path between nodes v and v (cid:48) if there are requests mapped to these nodes and apath needs to be created between them (Constr. 23). Constr. 24ensures the path in network graph created for edge ( u, u (cid:48) ) in the VNF graph starts at exactly one edge going out ofnode x in the network where request u is mapped to. WithoutConstr. 25 any random edge might be marked as the first edgeof this path. Analogously, Constr. 26–27 ensure the correctnessand uniqueness of the creation of the last edge in the path.In Constr. 24–27, the product of the binary variables can belinearized to avoid having cubic constraints in the problem.Constr. 28 ensures that for every node w in the network graph,if one of its incoming edges belongs to a path between thenodes where requests u and u (cid:48) are mapped to, then one ofits outgoing edges also belongs to this path. Excluded fromthis rule are the cases where the incoming edge to a node isthe last edge in the path and where the outgoing edge from anode is the first edge in the path. Constraints 29–30 preventthe creation of infinite loops and unnecessary extensions ofthe created paths. For every edge in the network, the sum ofthe required data rates of all paths going through that edgeshould be less than or equal to the data rate capacity of thisedge (Constr. 31). Moreover, the sum of latencies of all edgesthat belong to a path between the start and end points of aflow should not exceed the maximum tolerable latency givenfor that flow (Constr. 32).
3) Metrics Calculation Constraints: ∀ v ∈ V : (cid:88) f ∈ F i f,v ≤M (cid:48) · used v (33) ∀ v ∈ V : used v ≤ (cid:88) f ∈ F i f,v (34) ∀ ( v, v (cid:48) ) ∈ E : remdr v,v (cid:48) = d ( v, v (cid:48) ) − (cid:88) ( u,u (cid:48) ) ∈ U pairs , ∀ x,y ∈ V e v,v (cid:48) ,x,y,u,u (cid:48) · d req ( u, u (cid:48) ) (35) ( u, u (cid:48) ) ∈ U pairs : lat u,u (cid:48) = (cid:88) x,y ∈ V, ( v,v (cid:48) ) ∈ E e v,v (cid:48) ,x,y,u,u (cid:48) · l ( v, v (cid:48) ) (36) Using Constr. 33 and 34 we mark a network node as used if there is an instance of at least one function mapped to it. M (cid:48) ∈ N is a number larger than the sum on the left side of theinequality in Constr. 33. For each edge ( v, v (cid:48) ) in the network,the remaining data rate after the placement of chained functionsis calculated by subtracting the sum of required data rates ofall paths that go through this edge from the initial data rate ofit (Constr. 35). For every edge ( u, u (cid:48) ) in the VNF graph, thelatency of the paths created between the nodes where requests u and u (cid:48) are mapped to is equal to the sum of latencies of allnetwork edges that belong to this path (Constr. 36). B. Objectives
Different objectives can be targeted for placement optimiza-tion, and each of them can result in a different mapping of theVNF graphs into the network graph. We define three objectivefunctions and describe the behavior of the placement processusing each objective.
1) Maximizing the remaining data rate on network links: maximize (cid:88) ( v,v (cid:48) ) ∈ E,v (cid:54) = v (cid:48) remdr v,v (cid:48) (37) As highly utilized links can result in congestion in the network,solutions that leave more capacity on the links are desirable.This objective aims at leaving more data rate on the links.By maximizing the sum of remaining data rate over all edgesexcept self-loops, it forces the placement algorithm to use self-loops (i.e., links between two functions that are placed on onenetwork node) more than other links.
2) Minimizing the number of used nodes in the network: minimize (cid:88) v ∈ V used v (38) This objective can result in an energy-efficient solution byallowing more unused nodes to be switched off. However, itmight concentrate the placement of functions on a small subsetof nodes causing congestion in the network.
3) Minimizing the latency of the created paths: minimize (cid:88) ( a,a (cid:48) ) ∈ l req (cid:16) (cid:88) P ∈ paths ( a,a (cid:48) ) (cid:16) (cid:88) ( u,u (cid:48) ) ∈ P lat u,u (cid:48) (cid:17)(cid:17) (39) In complex chaining scenarios with branches in the structure,there are multiple simple paths between the start and end points.As each path consists of different sets of edges, they can havedifferent latencies. This objective function minimizes the meanlatency of all paths created for all deployment requests.These objective functions cause the placement to focus ona specific goal. For example, using the third objective, we getsolutions with minimum latency but the remaining data rateof the links or the number of used nodes in the network arenot predictable. There can be conflicts in the solutions that areconsidered as optimal using each of these objectives. Resultsof our Pareto analysis (Section VI) show that the three metricscan have trade-offs but are not necessarily conflicting. VI. E
VALUATION
We have performed two types of evaluation of our model andplacement optimization process: 1) Observing the behavior ofthe placement process and our heuristic for reducing the runtimeof the process when there are several ordering possibilitiesin deployment requests; 2) Pareto analysis for showing thepossible trade-offs between our metrics of interest. Currently,there is no commonly accepted evaluation model for eitherthe actual chained network functions or the user requests fortenant applications with chains of virtual or physical networkfunctions in their structure. Therefore, we have designed smallevaluation scenarios with manually created deployment requestson a substrate network with 12 nodes and 42 directed edges(including self-loops), based on the abilene network fromSNDlib [15]. We have built these requests to test the capabilitiesof the request processing and placement steps while beingcompatible with known use cases of chaining VNFs [7], [16].We have used the Gurobi Optimizer to solve the MIQCP onmachines with Intel Xeon X5650 CPUs running at 2.67 GHz.
A. Evaluation of Optional Orders in Chaining Requests
For this part, we have used a set of chaining requests whichallow an arbitrary order among a set of functions. Our placementresults show that for small requests that have small requirementscompared to the available resources in the network sorting thefunctions according to their ratios of outgoing to incoming datarate gives the best (or one of the best) solutions for the requests.When placing several requests the combination of requests havehigher requirements and there can be dependencies betweendifferent requests (e.g., shared VNFs). In that case, combiningthe sorted chains may result in a sub-optimal solution. Theruntime, however, should also be considered. For example, inour evaluation settings, placing a combination of 3 requestswith optional orders (resulting in 6, 6, and 4 VNF graphs,respectively) by sorting them takes an average of 13 minutesusing different objective functions to give a close to optimalsolution. But computing all combinations ( · · ) to findthe optimal one needs 31 hours. For this example, placement ofthe sorted chains was one of the optimal placements regardingremaining data rate and the latency but it used more networknodes compared to some other solutions. Our heuristic offersthe opportunity to place the chained functions in an acceptabletime by allowing a slight deviation from the optimal solution.Considering the fact that even a simple set with 3 requests canresult in 144 combinations, we use this heuristic for the secondpart of our evaluations and choose the sorted chain for each ofthe requests in our request sets. B. Pareto Set Analysis
For the Pareto analysis, we have performed the placementfor different sets of deployment requests using the objectivesdefined in Section V-B. Our request sets resemble three differentVNF chaining scenarios (broadband, mobile core, and datacenter networks) from the IETF draft on service functionchaining use cases [7]. We have defined two different setsof requests with different complexities for each scenario. Firstwe did a range estimation run for the request sets by performingthe placement using each of the objectives and recording thehighest and lowest values for the metrics. After identifyingthe interesting ranges, we performed the Pareto optimization. o t a l r e m a i n i ng d a t a r a t e [ G b / s ] S u m o f l a t e n c i e s [ s ] U s e d n o d e s (a) Results for a sample request set with optimal solution T o t a l r e m a i n i n g d a t a r a t e [ G b / s ] S u m o f l a t e n c i e s [ s ] U s e d n o d e s (b) Results for a sample request set including a Pareto setFig. 2. Sample results from the multi-objective Pareto analysis Some of our results show trade-offs between optimizing theremaining data rate, number of used nodes, and latency; thereare also results that show it is possible to find a placement thatoptimizes all three metrics. Figure 2 shows the results for twoof our request sets. For better visibility, we use different colorsfor different number of used nodes in this figure. As illustratedin Figure 2a, the objectives are not always conflicting. If thereare enough free resources in the network, it might be possibleto find a solution that is optimal in terms of all three metrics(the solution marked by a star).Results of the Pareto optimization for another one of ourrequest sets is shown in Figure 2b. Allowing the placementto use more nodes gives results with lower latency and higherremaining data rate. But after a certain point increasing thenumber of used nodes does not improve the results anymore.The figure also shows a trade-off between latency and remainingdata rate. Using a fixed number of nodes, the latency of thesolution increases to get a higher value for the remaining datarate, which also means that improving the latency can resultin a lower remaining data rate.Network operators can have different objectives whichrequire different placement solutions. Results of our Paretoanalysis can help the operators prioritize their optimizationgoals and choose the right objective functions.VII. C
ONCLUSION
In this paper, we have presented a formal model forspecifying VNF chaining requests, including a context-freelanguage for denoting complex composition of VNF. Usingthis model, we have formulated an optimization problem forplacing the chained VNF in an operator’s network with multiplesites, based on requirements of the tenants and the operator.Our evaluations have shown that placement of chained VNFis not a trivial problem and that placement decisions have to be taken differently according to the desired placementobjective (i.e. remaining data rate, latency, number of usednetwork nodes). Our results warrant further investigation toallow fast and efficient placement of VNFs and to facilitate thedeployment of NFV in different types of networks.R
EFERENCES[1] B. Carpenter and S. Brim, “Middleboxes: Taxonomy and Issues. RFC3234,” 2002.[2] F. Schneider, T. Egawa, S. Schaller, S.-i. Hayano, M. Sch¨oller, andF. Zdarsky, “Standardizations of SDN and Its Practical Implementation.”[3] P. Quinn and T. Nadeau, “Service Function Chaining Problem Statement,”Active Internet-Draft, IETF Secretariat, Internet-Draft draft-ietf-sfc-problem-statement-05, Apr. 2014.[4] V. Sekar, S. Ratnasamy, M. K. Reiter, N. Egi, and G. Shi, “The middleboxmanifesto: enabling innovation in middlebox deployment,”
Proceedingsof the 10th ACM Workshop on Hot Topics in Networks , p. 21, 2011.[5] R. Guerzoni, “Network Functions Virtualisation: An Introduction,Benefits, Enablers, Challenges and Call for Action, Introductory whitepaper,”
SDN and OpenFlow World Congress , 2012.[6] W. Xu, Y. Jiang, and C. Zhou, “Problem Statement of Network FunctionsVirtualization Model,” Internet-Draft, IETF Secretariat, Internet-Draftdraft-xjz-nfv-model-problem-statement-00, Sep. 2013.[7] W. Liu, H. Li, O. Huang, M. Boucadair, N. Leymann, Z. Cao, Q. Sun,and C. Pham, “Service Function Chaining (SFC) Use Cases,” ActiveInternet-Draft, IETF Secretariat, Internet-Draft draft-liu-sfc-use-cases-05,Apr. 2014.[8] M. Boucadair, C. Jacquenet, R. Parker, D. Lopez, J. Guichard, andC. Pignataro, “Service Function Chaining: Framework and Architecture,”Active Internet-Draft, IETF Secretariat, Internet-Draft draft-boucadair-sfc-framework-02, Feb. 2014.[9] G. Nagy and S. Salhi, “Location-routing: Issues, models and methods,”
European Journal of Operational Research , vol. 177, no. 2, pp. 649–672,Mar. 2007.[10] C. Prodhon and C. Prins, “A Survey of Recent Research on Location-Routing Problems,”
European Journal of Operational Research , Jan.2014.[11] A. Fischer, J. F. Botero, M. T. Beck, H. de Meer, and X. Hesselbach,“Virtual Network Embedding: A Survey,”
IEEE Communications Surveys& Tutorials , vol. 15, no. 4, pp. 1888–1906, 2013.[12] C. Fuerst, S. Schmid, and A. Feldmann, “Benefits and Limitations of Pre-Clustering,” in
IEEE 2nd International Conference on Cloud Networking(CloudNet 2013) , San Francisco, CA, 2013, pp. 91–98.[13] D. Joseph and I. Stoica, “Modeling middleboxes,”
Network, IEEE , vol. 22,no. 5, pp. 20–25, 2008.[14] A. Gember, A. Krishnamurthy, S. S. John, R. Grandl, X. Gao, A. Anand,T. Benson, A. Akella, and V. Sekar, “Stratos: A network-aware orchestra-tion layer for middleboxes in the cloud,” arXiv preprint arXiv:1305.0209 ,2013.[15] S. Orlowski, M. Pi´oro, A. Tomaszewski, and R. Wess¨aly, “SNDlib1.0–Survivable Network Design Library,” in