Flexibility of Networks: a new measure for network design space analysis?
FFlexibility of Networks: a new measure fornetwork design space analysis?
Wolfgang Kellerer, Arsany Basta, Andreas Blenk
Chair of Communication NetworksDepartment of Electrical and Computer EngineeringTechnical University of Munich {wolfgang.kellerer,arsany.basta,andreas.blenk}@tum.de
ABSTRACT
Flexibility is often claimed as a competitive advantage whenproposing new network designs. However, most proposalsprovide only qualitative arguments for their improved sup-port of flexibility. Quantitative arguments vary a lot amongdifferent proposals. A general understanding for flexibilityis not yet clearly defined, leaving it to the reader to drawthe right conclusions based on background information. Theterm flexibility is commonly defined as the ability to adaptto changes. For networks, flexibility would refer to the abil-ity to adapt the available network resources, such as flowsor topology, to changes of design requirements, e.g., shorterlatency budgets or different traffic distributions. Recent con-cepts such as Software Defined Networking, Network Virtu-alization and Network Function Virtualization have emergedclaiming to provide more flexibility in networks. Neverthe-less, a deeper understanding of what flexibility means andhow it could be quantified to compare different network de-signs remains open. In this paper, we ask whether flexibil-ity can be a new measure for network design space analysis.As it is quite challenging to formulate a flexibility measurethat covers all network aspects, we propose an initial set offlexibility aspects to start grounding guidelines. Our initialselection is backed up by an analysis of Software DefinedNetworking, Network Virtualization and Network FunctionVirtualization for their support of the selected flexibility as-pects. Our research methodology is based on a systematicapproach that leads to network design guidelines with re-spect to flexibility.
1. INTRODUCTION
Flexibility has become a key design objective for networksand respective proposed control and data plane mechanismtoday. For example, more than one third of the publicationspresented at ACM SIGCOMM in 2014 mention flexibility intheir description.In fact, heterogeneous requirements from different appli-cation domains demand for networks to be designed for flex-ibility. These requirements include the ability to add newflows or even virtual networks on demand without influenc-ing existing flows/networks, the ability to temporarily extend a network topology to serve events, and the ability to recon-figure the network in real-time for resilience, e.g., for indus-trial applications, to give some examples.Let us take a popular sports event as another example [1].For a short period of time thousands of users demand net-work resources to send videos or to obtain additional infor-mation about the game. To meet those demands, networkresources have to be allocated in the best possible way toscale with the increased number of users. Topology mightbe adapted to allow multicasting of extra information. How-ever, this is only needed for some hours. A network that cansatisfy these requirements is commonly said to be flexible.Flexibility can be defined in different domains and fromdifferent viewpoints. For networks, which is the focus of thispaper, flexibility refers to the ability of a network to adapt itsresources such as flows or topology to changes of require-ments. This adaptation to changes may include the adapta-tion of the network configuration, the network topology orthe network functions and their placement.Note that in this paper we focus on network aspects offlexibility. In general, in a communication system, flexibilitymay also refer to aspects of software implementation, oper-ating systems, protocol stack design, application design, etc.,which are out of scope for our discussion here.In the recent years, a number of technologies have emergedclaiming to provide flexibility in networks. One widely ac-cepted approach is the concept of Software Defined Net-working (SDN) [2] separating the data plane from a logi-cally centralized control plane with a standardized interfaceallowing programmability and hence flexibility in networks.SDN-based network control can be complemented by theconcept of Network Virtualization (NV) [3] where networkresources can be operated on logical, hence virtual level on aphysical network substrate. The concept of virtualization hasalso been extended to network functions. Network FunctionVirtualization (NFV) [4] allows to provide network functionssuch as gateways and middleboxes in software and to runthem on commodity hardware, e.g., in data centers.Although new technologies evolved that increase the abil-ity of a network to be adapted, a clear definition of whatflexibility means for networks is missing. Moreover, thereis no common agreement on a quality indicator quantifying a r X i v : . [ c s . N I] D ec onstantCost Flexibilitylogarithmic linear exponential Figure 1: Trade-off between flexibility and cost a network’s flexibilty. Such quality indicator could be de-fined similar to what has been defined for Quality of Service(QoS). QoS has been introduced to provide a common un-derstanding about network support for service level perfor-mance aspects , in particular, data rate, delay and jitter.For flexibility, we raise the question whether it will be anew measure for network design space analysis. Moreover,we advocate to come up with a network flexibility measure,e.g., "Quality of Flexibility" (QoF), describing a commonset of flexibility aspects . Similar to QoS, where the impor-tance of aspects such as data rate and delay varies amongdifferent service requirements, flexibility depends on the re-quirements as well. For some network scenario the place-ment of functions may be important, for another its scalein topology size. Hence, we are not aiming at quantifyingflexibility of networks as a singular comparative metric, butrather through a set of flexibility aspects. To be able to quan-titatively compare different network designs with respect totheir flexibility, a common definition of main flexibility as-pects is indispensable.The cost incurred to provide flexibility is important to con-sider when we compare different network designs with re-spect to network flexibility. Cost involved in providing flex-ibility may include, e.g., additional network load for signal-ing, additional data path latency, and the number of recon-figurations needed to change a network state.Whereas ongoing research is focusing to come up withnew network designs and protocols to realize the SDN con-cept or NFV for various use cases, a fundamental analy-sis of the cost-benefit trade-off for flexibility in networksis missing. Figure 1 illustrates how such trade-off analysiscould look like. A common understanding might be that costrises with increased flexibility, e.g., signaling overhead in-creases with the number of supported configuration parame-ters. However, we lack quantitative trade-off evaluation re-sults for different network design choices. Would costs riselinearly, logarithmic or exponential with increased flexibil-ity? Or would the costs rather remain constant? For a quan-titative analysis and, in particular, for the comparison of de-sign choices, we need a define the aspects that comprise anetwork flexibility measure.The main contributions of this paper are (a) to show thatflexibility is used for network evaluation in various ways, but a common definition of a flexibility measure is missing, (b)to propose an initial set of flexibility aspects for a commonnetwork flexibility measure, (c) to advocate that in networkresearch a deeper analysis of the fundamental design spaceof networks for flexibility with respect to cost is needed, and(d) to layout guidelines on the methodology and approachthat we intend to follow to tackle this fundamental problem.In the remainder of this paper, we analyze state of the artapproaches for their support of flexibility in Section 2. InSection 3, we propose a selection of flexibility aspects as abasis for a common network flexibility measure. In Section4, we discuss how our proposal applies to emerging tech-nologies such as SDN, NV and NFV based on examples. InSection 5, we introduce a methodology framework that aimsat defining a measure for network flexibility.
2. FLEXIBILITY IN LITERATURE
In this section, we analyze the state of the art that arguesabout flexibility. We extract the definition of flexibility ap-plied in each targeted use case and, if possible, show howflexibility is expressed via quantitative measures.
Anderson et al. [5] discuss the flexibility gain of networkvirtualization. They argue that virtualization is needed in or-der to provide flexible experimentation with traffic from thecurrent Internet. Furthermore, they introduce two views ofa future architecture, the purist view and the pluralist view.As the architecture remains in place a long time, the puristsaim for architectural flexibility. This means that the archi-tecture should only provide mechanisms to be changed overlarge time scales. In contrast, the pluralists want to providethe ability to add or augment overlay networks when needed.They argue that flexible adding or removing overlays, i.e.,changing virtual topologies, provides the needed flexibility.Greenberg et al. [6] propose VL2, a scalable and flexibledata center network. They argue that data centers should pro-vide an adaptive and flexible resource allocation in order toachieve a high resource efficiency. Although the authors donot define flexibility as the dominant system attribute, theymention agility as the key property. In the data center con-text, the key to achieve high utilization ”is the property ofagility - the capacity to assign any server to any service.”The authors of [7] investigate the flexibility of insertingnew technologies in existing infrastructures. They define”Flexibility” as ”the ability for” an ”approach to adapt tochanges in topology over time (...) as well as failures”. Theyquantify the flexibility for different technologies. For in-stance, flexibility (fault tolerance) vs. achieved throughput.While one approach is more flexible (failure resilient), itadds overhead, thus, decreases throughput.
Jin et al [8] tackle the challenges of the cellular core net-work. They say that the current mobile core network is ”in-exible” for three reasons: they ”forward all traffic throughthe P-GWs”, ”P-GWs are not modular”, carriers cannot ”mixand match capabilities from different vendors (e.g., use afirewall from one vendor, and a transcoder from another)”.They propose the scalable architecture SoftCell that can makefine-grained policies for the mobile core network devices.SoftCell uses so called flexible, high-level service policies.Operators can use these policies to redirect traffic throughmiddleboxes, which are operated according to the demandsof subscribers. The high level policies are realized via switchesthat are deployed close to the base stations. The core switchesenable forwarding to the needed middleboxes, i.e., networkfunctions.
Arumaithurai et al. [9] propose Function-Centric ServiceChaining (FCSC). FCSC is based on Information CentricNetworking in order to make the management of networksthat use virtualization for dynamic function placement moreflexible. They see flexibility as the ability to adapt faster tofailures and to change middleboxes more quickly. More indetail, ”an efficient service chaining network should support(...) changes in a flexible way - (...) middleboxes should beable to determine the functions of a flow themselves and thechanges should take effect immediately.”
In order to make current switches more flexible in terms ofQoS, Sivaraman et al. [10] propose to add an FPGA-basedextension to switches. This extension provides more ca-pabilities to control the fast-path and queuing behavior ofswitches. In particular, ”the data plane should be flexibleenough to handle diverse and unanticipated application re-quirements.” It is also argued that such ”flexibility couldbe realized easily in software router running on a general-purpose microprocessor.”, i.e., software routers, but that theselack providing the same performance as hardware implemen-tations, or software solutions extended with hardware.Similar to the previous concept, Hwang et al. [11] say thatsoftware solutions running on commodity servers, whose hard-ware is extensively exploited via software extensions, e.g.DPDK, provides ”far greater flexibility” than existing purpose-built hardware. They propose NetVM, which ”enable(s) in-network services”, e.g., firewalls or proxies, ”to be flexiblecreated, chained and load balanced.” For instance, they pro-pose a shared switching memory inside hypervisors to avoidmemory migration during the migration of virtual machines.
Han et al. [12] are focusing on solutions for the congestionproblem of networks. They see router-assisted congestioncontrol algorithms as not flexible enough as the end-point isdependent on the feedback from the network. On the otherhand, they see pure end-point based solutions as not as effi-cient as router-assisted solutions. Accordingly, they presenta framework called FCP. FCP relies on both, i.e., it provides flexible end-point realization that can incorporate congestionfeedback from the network. Thus, it provides the ”flexibilityto ensure that new behaviors can be implemented to accom-modate potential changes in communication patterns.”
Chowdhurry et al. [13] propose Sinbad that lets applica-tions make decisions about where to steer their file traffic.Thus, Sinbad avoids congested network links by avoidingnetwork traffic hotspots. It increase the flexibility of clusterfile systems by adapting the replica destinations.Vissicchio et al. [14, 15] introduce Fibbing, an architec-ture that ”readily supports flexible load balancing, traffic en-gineering, and backup routes”. Fibbing provides a way tohave a control plane that runs physically distributed but isstill centrally controlled. For this, they introduce fake nodesand links in order to indirectly impact the path calculation ofthe distributed control plane. In this, the advantages of bothworlds should be combined. The authors also mention that”while more flexible (e.g., enabling stateful control logic)than Fibbing, SDN requires updating the switch-level rulesone-by-one” thus ”forgoes the scalability and reliability ben-efits of distributed routing.”In summary, we can observe that flexibility is a key re-quirement for network design in the related work. However,several different perspectives of flexibility are taken and acommon understanding of network flexibility as measure ismissing so far. Nevertheless, we can observe common as-pects of network flexibility among the different publications.In the following, we are going to extract those to come upwith a set of flexibility aspects as part of a common mea-sure.
3. TOWARDS A FLEXIBILITY MEASURE
Network flexibility can be expressed with respect to manydifferent network parameters, e.g., set of possible configura-tions or number of locations for function placement. There isno unified measure that can express how flexible a networkis, i.e., to quantify flexibility for comparing network designchoices. There is also a lack of quantitative analysis for theincurred cost, i.e., overhead, resulting from increasing net-work flexibility in a network.Defining a measure for network flexibility is not a trivialproblem as a lot of the involved network parameters are de-pending on each other. The main reason for this dependencyis the huge variety of the parameters. For example, the flex-ibility of migrating a virtual network depends on the migra-tion mechanism, the size of the network, the topology of thenetwork, the hypervisor used, the physical technology, thefunction to be migrated, etc. For a flexibility measure, thechallenge is to quantify the resulting values of each parame-ter according to their dependencies.Network flexibility as a measure is mostly used with a spe-cific objective in mind, e.g. "network A can be re-configuredaster than network B", focusing on a selected, narroweddown set of parameters, which we could already observe inSection 2. Hence, in order to come up with a common mea-sure, the challenge is to find reasonably independent flexibil-ity aspects combining some of the parameters to support anintuitive understanding of flexibility.In the following, we provide an initial set of such flexi-bility aspects. For each, we list the parameters defining theaspect as well as the cost involved for achieving the respec-tive flexibility.A network can be assessed in terms of its flexibility tochange its configuration . The configuration can either bea single parameter or a state change, i.e., "re-configuration"or rather an addition to the possible set of configurations thatthe network supports. Network configuration flexibility canbe assessed in terms of the number or set of possible config-urations, where a larger set of possible configurations addsto flexibility. Another assessment of configuration flexibilityis time, in which a configuration is either changed, added orenforced. Network configuration flexibility can be expressedfor flow configuration, function configuration and parameterconfiguration.Another aspect of network flexibility is the ability to changethe deployment location of network functions within a givennetwork, i.e., network function placement . Network func-tion placement allows to meet different latency requirementsand also the combination of functions, i.e., chaining.A third area for network flexibility is the aspect of scale .This includes the ability of a network to scale its resources,e.g., to add link capacity, or to scale the allocated resourcesto network flows, e.g., allocate more capacity to a flow. Italso refers to the ability to scale and apply adaptations tothe network topology, e.g., scale the network size throughadding nodes and links or change the network connectivityfrom a tree to a mesh topology.Note that the proposed aspects can be considered as le-nient examples for an initial set of network design choicesin the context of flexibility. These flexibility aspects can beextended through new networking concepts, technologies orfuture design requirements.
Flow configuration describes the course of flows inside anetwork through configuring forwarding policy for a flow oneach network hop. Flow configuration can be considered asan elementary attribute for configuration flexibility. Havingthe ability to change the configuration of the flow policies of-fers traffic steering, which in turn can bring more flexibilityto networks. Such flexibility can be related to the magnitudeand granularity of flow configurations, more possible con-figurations would reflect to higher flexibility. As an exam-ple, a network element that can support only forwarding ofpackets is less flexible than an element that can provide bothforwarding and duplicating packets on multiple ports for in-stance. Flexibility of flow configuration can be also coupled with the time required to change such configuration. Net-work elements can vary from not being able to change theflow configuration on run-time, i.e., static, to elements thatcan support run-time flow configuration.It is very important to note that there is a cost to supporthigher flexibility in terms of flow configuration. From anoperational aspect, changing the configuration of networknodes requires additional control, which might impose la-tency and data overhead. From a performance perspective,changing the flow configuration "steering" might lead to ser-vice interruption or even to network instability. parameters: e.g., set of flow configurations, support forrun-time configuration cost: e.g., control latency, control overhead, network sta-bility, flow interruption
Function configuration denotes the ability of configuringthe functionality of network elements such as firewalls, NATs,proxies, load balancers, etc. Nowadays, programmable switchesare being introduced which allow the operator to change andtweak their network function. Hence, a programmable resp.configurable network element can be another driver to in-crease network flexibility. Flexibility of function configu-ration can be assessed in terms of the set of possible func-tions supported by the programmable network element. Therun-time support to change the function configuration canbe considered as another main enabler for higher flexibility.The cost of flexible function configuration can be observed interms of latency or control overhead. It may also require ad-ditional resources or capabilities on the programmable net-work elements compared to conventional network elements.Function configuration might also impact the performance ofthe data plane. For instance, if the function configuration fea-ture is only supported by software implementations that runon the general-purpose computing of a network element, arelative decline in performance could be observed comparedto other functions that are implemented and integrated in thehardware. parameters: e.g., set of function configurations, supportfor run-time configuration cost: e.g., function configuration latency, resource over-head, control overhead, data plane performance, data pro-cessing latency
In addition to flow configuration, which describes the dataflow in a network, and function configuration, that denotesthe functionality in a network, there is a third type of config-uration which is parameter configuration. Parameter config-uration concerns changing the values and policies to be usedby each network function. This means that flow path and thenetwork functionality remain the same, however the parame-ters configured on those functions can vary. For example, fora priority queuing scheduler, parameter configuration wouldbe setting the priority values for the receptive queues, or itould be the maximum rate for a port shaper. More possibleparameter configurations and the ability of changing the net-work parameters on run-time would imply more flexibility.Similar to flow and function configuration, there is a cost in-duced by parameter configuration coming from control anddata plane performance. parameters: e.g., set of parameter configurations, supportfor run-time configuration cost: e.g., parameter configuration latency, resources over-head, control overhead, data performance
The placement of a function within a network defines thepossible locations for network functions. The function place-ment has a direct impact on the network performance, e.g.,the SDN controller placement with respect to switches andits impact on control latency. Dynamic placement adds anadditional dimension to flexibility in case changing the func-tion placement is supported through, e.g., migration tech-niques for virtual functions.The placement flexibility is directly influenced by the setof possible locations to place a function. More potential lo-cations have the degree of freedom to place network func-tions such that diverse or even more strict requirements canbe satisfied. The connectivity given between the set of loca-tion can also play a role in the overall flexibility. A dynamicfunction placement that can change on run-time offers moreflexibility than a static placement. parameters: e.g., set of potential locations, connectivitybetween locations, static or dynamic placement cost: e.g., control and data latency, control and data through-put, state consistency, synchronization overhead (dependingon migration mechanism), interruption during migration (de-pending on migration time)
The allocation of resources denotes the flexibility of a net-work to change the assignment of network resources to flowsor functions. It is decided based on the possible resources,e.g., network element CPU or link capacity, that can be al-located to individual flows or functions. For example, for anetwork element that has two functions which share equallyits resources, e.g., CPU or memory, resource allocation flex-ibility would mean that we can assign 80% of the resourcesto one of the functions. Higher resource allocation flexibilitywould be achieved with more possible types of resources thatcan be assigned. Flexibility is also related to the granularityof such resource assignment. Adding more resource alloca-tion flexibility in network elements means more complexityand management overhead. It could also mean that part ofthe resources can be utilized by the manager that enforcesthe resource assignment. parameters: e.g., granularity of assignment, set of possi-ble resources to be assigned cost: e.g., network element management overhead, net-work element complexity, resources overhead
The adaption of network topology describes the flexibilityof a network to change its topology structure through addingor removing nodes or links. Topology adaptation flexibilitycan be reflected by the network technology. As an example,adding a node to an optical topology can require more effort(in terms of tuning and setup) compared to adding a nodein an IP topology. The network technology can also referto physical compared to logical topologies. A logical topol-ogy in this sense has more flexibility to adapt its mapping onthe network infrastructure, while a physical network is re-stricted by its set of physical nodes and links. Additionally,discovery protocols also play a role to support the flexibil-ity in adapting a network topology. A topology that runsan automated discovery protocol, which provide on run-timetopology adaptation, is more flexible than a topology thathas to be manually configured. Flexibility of topology adap-tation comes with a cost in terms of additional protocols andmanagement overhead. The topology adaptation protocolsmight also have a cost in terms of network resources, i.e.,additional resources needed to run these protocols. parameters: e.g., technology, discovery protocols, run-time adaptation cost: e.g., topology adaption latency, resource overhead,signaling and management overhead, protocol complexity,data throughput and latency
4. HOW FLEXIBILE ARE RECENTNETWORKING CONCEPTS?
Emerging technology concepts to provide flexibility in net-works include SDN, NV and NFV. In order to illustrate how aquantitative analysis of the flexibility vs. cost trade-off couldlook like, we describe and discuss selected use cases in thefollowing. We have applied our selected flexibility aspects(Section 3) to examples from the state of the art of each ofthe three concepts. Table 1 illustrates which flexibility as-pects are supported by each of them.
SDN was developed to target programmable flows and tocentralize network control, which contributes to flexibilityin terms of flow configuration. This flexibility needs to beassessed in terms of the number of possible configurations.OpenFlow (OF) [2], which is the most commonly used pro-tocol to implement SDN, has an upper boundary in its flex-ibility due to the limited set of configurations specified inthe specification of each OF protocol version. In additionto flexibility of flow configuration, SDN’s network controlcan also indirectly support the flexibility of network func-tions placement [16], flow configuration [17] and topologyadaptation [18].An example for the trade-off between SDN’s flow con-figuration flexibility and its cost can be observed in [19]. able 1: Concepts vs. Flexibility Aspects. ( (cid:88) ): main target, (-): out of scope, (+): provides support
Concept Flow Config Function Config Parameter Config Function Placement Resource Allocation TopologyAdaptationSDN (cid:88) – – + + +NV – – + (cid:88) (cid:88) (cid:88)
NFV – (cid:88) + (cid:88) (cid:88) –This work illustrates the cost of state synchronization be-tween distributed SDN controllers with the application ofload balancing. The evaluation looks at two controllers thatexchange link utilization information towards two servers.The target is to apply load balancing among the two serversby consistent flow configuration based on the exchanged state.It is shown that more frequent state synchronization, whichtranslates into signaling and processing overhead, is neededto achieve the targeted load balancing. As we can observe, aconcrete flexibility vs. cost trade-off provided by SDN doesnot come for granted, but might induce cost on network op-eration. NV abstracts network resources from physical infrastruc-ture with the scope of adding flexibility to network resources.With existing networking hardware, virtualization can con-tribute to flexibility in terms of flow and topology adaptation,flexibility of function placement through migration of virtualnodes as well as flexibility of parameter configuration for theabstract virtual resources.Addressing migration for instance to evaluate the flexibil-ity of virtual networks, [20] shows a study for live migra-tion solution of virtual switches. A live migration provides ahigh flexibility in adapting the virtual network topology. Theevaluation shows that the introduced solution can success-fully achieve migration without packet loss, i.e., transparentto the service. However, an extra software layer is added thatcomes at a control overhead of 7%. This means that gainsin terms of topology flexibility offered by NV might havedrawbacks on performance, i.e., cost.
NFV leverages virtualization to functionality, where func-tions get developed as software and are executed on com-modity hardware. Having programmable hardware can of-fer flexibility to define and program function configuration.NFV can also provide flexibility in terms of flow scale bybeing independent from networking hardware, e.g., scale upresources assigned to a network function or scale out a func-tion on multiple hardware entities. Software functions, wichare independent from hardware, also contribute to the func-tion placement flexibility.An example to show the trade-off between the flexibilityand cost of NFV can be seen in [21]. This work investi-gates the opportunity to virtualize network middleboxes andto convert them into software functions that run in a cloud. Middleboxes contribute to a large fraction of network do-mains, e.g., enterprise, thus software inter-changeable mid-dleboxes can promise a huge increase in flexibility. The eval-uation shows that flexibility of software middleboxes can in-duce a cost in terms of increased latency depending on thecloud provider and solution taken. It is also shown that thecost of traffic overhead with software middleboxes can be upto an additional 52% in the worst case.Overall, we can observe that our proposed network flexi-bility aspects well apply for latest technology concepts. Firstquantitative cost analysis is provided, however, as a com-mon measure is missing, a general quantitative analysis andcomparison of different design choices remains challenging.Moreover, most current work is highlighting improvementswith respect to flexibility. An analysis of network flexibilitylimits is missing as well. Such should be part of a com-prehensive analyis of the network design space to be able toshow why a design choice is flexible and to what extent. Oneshould always be careful when reading evaluation statementsjust claiming improved flexibility as such.
5. FRAMEWORK TOWARDS QUANTI-FYING FLEXIBILITY
In this section, we outline our methodology and approachtowards a measure for network flexibility. We define a sys-tematic approach that would lead to guidelines on how todesign a network with respect to flexibility. The frameworkconsists of three main building blocks, namely objective def-inition, solution analysis and guideline formulation, as shownin Figure 2.
As we define the flexibility of a network in terms of itsability to adapt, the input of a flexibility framework shoulduse input that shows changing behavior in time and space.This assumption is based on the fact that, e.g., network usersare changing their locations over time. Such diurnal patternsare regularly observed in current traffic measurements takenfrom different types of networks. In order to support spa-tial traffic patterns, i.e., network traffic occurs with varyingintensity for different locations, also spatial behaviors needto be considered when analyzing flexibility. Beside vary-ing traffic patterns, the underlying network topology maystrongly impact the performance of network architectures.Thus, different types of topologies serve as input for flexibil-ity analysis. bj1 single objective multi objective topology traffic obj2obj3 obj1&2obj1 obj2obj1&2&3
Solutions Analysis trade-offspareto frontiersQoF measure
Network Design GuidelinesModelling and OptimizationInput
Model updatesPatternsAnalysis feedbackTraining sets
Figure 2: Methodology framework towards network flex-ibility measure. Based on an initial solution analysis,observed patterns and new training sets are fed backfor modeling and optimization. The models are updatedbased on insights from consecutive solution analysis
This first step is considered as the core of the whole frame-work. The selected flexibility aspects, mentioned above inSection 3, are modeled as network design optimization prob-lems. The optimization problems target specific technologyaspects and concept details, e.g., model the control and dataplane split in SDN networks or model the logical mappingof virtual networks on the physical substrates. The objectivedefinition then incorporates the different network require-ments that can be inferred from today’s networks, e.g., min-imize data plane delay, minimize the management overheadby considering re-configurations, or maximize the supportfor drastic traffic changes or fluctuations. The resulting net-work design based on the defined objectives would be influ-enced by the input, which can be narrowed down on an ab-stract level to two main contributors, namely, different net-work topologies and differing traffic distributions. Our ap-proach aims at altering the optimization’s topology and traf-fic input. This might result in different network design solu-tions, which might show trade-offs or Pareto frontiers.
The next step is the analysis of the solutions. This bringsus closer to defining guidelines for a flexibility measure. In the first step, the optimization problems are solved with vary-ing input of network topology and traffic distributions result-ing in a whole set of solutions. The analysis of these solu-tions derives patterns from the solutions and moves a stepforward towards the flexibility measure.One example would be to deduce which network designcould support more variations of the topology and traffic in-put, hence, infer higher flexibility. We could consider thenumber of supported variations as a flexibility measure. Be-sides, initial solution analysis might reveal so called problem-solution patterns. A pattern might be that one architecturefits to topologies showing a specific characteristic, such ashigh betweenness centrality, while another architecture mightfit best to sparsely connected network topologies. Further-more, the solution analysis could also reveal that for a set oftraffic patterns and topologies, a flexibility parameter doesnot need to be considered at all. For instance flexibility inconfiguration might not be needed as all available technolo-gies might not support the time dimension of the topology ortraffic input.
The last step in our framework is to incorporate all infor-mation about the optimization objective, used input, and re-sults of the solution analysis to be able to formulate guide-lines for a flexible network design. This step requires linkingand combining the different aspects involved in the challengeto define a quantitative flexibility measure.The outcome of the solution analysis could then be used asfeedback for model updates and also to thin out and substan-tiate the input data for the modeling and optimization step.Thinning out and substantiating the input data should lead toexperiments in which conditions are investigated which ac-tually affects the variation of the optimization results. Thiscycle could be repeated several times within the proposedframework till it converges to a set of clear and solid guide-lines.This modeling/optimization/analysis cycle needs a clearstopping condition. As an example, a simple stopping con-dition might be that the whole process stops if the completeproblem and solution space was exhaustively analyzed, i.e.,all possible combinations of parameters and input data wereinvestigated. However, such an analysis might be infeasi-ble due to the size of the problem and solution space. Thus,sophisticated mechanisms for identifying when an analysistruly converges, i.e., does not produce false positive conclu-sions, need to be established.
6. CONCLUSION
Flexibility is commonly used as a differentiating featurein recent proposals for network designs. However, quantita-tive arguments are often missing in order to express clearlywhich flexibility aspects are addressed to which extent andwhat costs are incurred to state that one network design ismore flexible than another design. Therefore, we advocatehat in network research a deeper analysis of the fundamen-tal design space of networks for flexibility with respect tocost is needed. Moreover, we ask the question whether net-work flexibility is constituting a new measure for networkdesign space analysis. We claim that with emerging network-ing concepts such as SDN, NFV and NV, network flexibilitywill most likely become a new measure in network researchand development in the future. In our initial proposal suchflexibility measure is not a single parameter but includes sev-eral flexibility aspects including the ability to adopt dynamicchanges in network configuration, the ability to place net-work functions and the ability to scale the network topol-ogy in size. Our selection of flexibility aspects is backedup by an analysis of SDN, NV and NFV based on concreteuse cases. The latter show that an initial evaluation of net-work flexibility with respect to costs is already taking placethat could benefit from our proposed measure. Accordingly,we proposed an initial framework for investigating flexibilityaspects in a well-defined manner. The framework consistsof multiple steps that should be repeated iteratively, finallyleading to clear and solid design guidelines for network ar-chitectures, which support flexibility in the paper’s context.Benefits include to reveal limits of flexibility and to be ableto compare among different approaches.
ACKNOWLEDGMENT
This work is part of a project that has received funding fromthe European Research Council (ERC) under the EuropeanUnion’s Horizon 2020 research and innovation program (grantagreement No 647158 - FlexNets). This work reflects onlythe authors’ view and the funding agency is not responsiblefor any use that may be made of the information it contains.
7. REFERENCES [1] Jeffrey Erman and K.K. Ramakrishnan. Understandingthe super-sized traffic of the super bowl.
InternetMeasurement Conference , pages 353–360, 2013.[2] Nick McKeown, Tom Anderson, Hari Balakrishnan,Guru Parulkar, Larry Peterson, Jennifer Rexford, ScottShenker, and Jonathan Turner. OpenFlow: EnablingInnovation in Campus Networks.
ACM SIGCOMMComputer Communication Review , 38(2):69, March2008.[3] N. M. Mosharaf Kabir Chowdhury and RaoufBoutaba. A survey of network virtualization.
Computer Networks
Computer , 38(4):34–41, April 2005. [6] Albert Greenberg, James R. Hamilton, Navendu Jain,Srikanth Kandula, Changhoon Kim, Parantap Lahiri,David a. Maltz, Parveen Patel, and Sudipta Sengupta.Vl2.
ACM SIGCOMM Computer CommunicationReview , 39(4):51, 2009.[7] Matthew K. Mukerjee, Dongsu Han, SrinivasanSeshan, and Peter Steenkiste. Understanding tradeoffsin incremental deployment of new networkarchitectures. In
CoNEXT , pages 271–282, 2013.[8] Xin Jin, Li Erran Li, Laurent Vanbever, and JenniferRexford. SoftCell: Scalable and Flexible Cellular CoreNetwork Architecture. In
CoNEXT , pages 163–174,2013.[9] Mayutan Arumaithurai, Jiachen Chen, Edo Monticelli,Xiaoming Fu, and Kadangode K Ramakrishnan.Exploiting ICN for flexible management ofsoftware-defined networks. In
INC , pages 107–116,2014.[10] Anirudh Sivaraman, Keith Winstein, SuvinaySubramanian, and Hari Balakrishnan. No silver bullet.In
ACM HotNets Workshop , pages 1–7, 2013.[11] Jinho Hwang, K K Ramakrishnan, and Timothy Wood.NetVM: High Performance and Flexible NetworkingUsing Virtualization on Commodity Platforms. In
USENIX NSDI , pages 445–458, 2014.[12] Dongsu Han, Robert Grandl, Aditya Akella, andSrinivasan Seshan. FCP: A Flexible TransportFramework for Accommodating Diversity. In
ACMSIGCOMM , page 135, 2013.[13] Mosharaf Chowdhury, Srikanth Kandula, and IonStoica. Leveraging endpoint flexibility indata-intensive clusters.
ACM SIGCOMM ComputerCommunication Review , page 231, 2013.[14] Stefano Vissicchio, Laurent Vanbever, and JenniferRexford. Sweet Little Lies: Fake Topologies forFlexible Routing. In
ACM HotNets Workshop , pages1–7, 2014.[15] Stefano Vissicchio, Olivier Tilmans, LaurentVanbever, and Jennifer Rexford. Central Control OverDistributed Routing. In
ACM SIGCOMM , 2015.[16] Jiaqiang Liu, Yong Li, and Depeng Jin. Sdn-based livevm migration across datacenters. In
ACM SIGCOMM ,pages 583–584, 2014.[17] Sushant Jain, Alok Kumar, Subhasree Mandal, JoonOng, Leon Poutievski, Arjun Singh, SubbaiahVenkata, Jim Wanderer, Junlan Zhou, Min Zhu, et al.B4: Experience with a globally-deployed softwaredefined wan. In
ACM SIGCOMM ComputerCommunication Review , volume 43, pages 3–14, 2013.[18] Pankaj Berde, Matteo Gerola, Jonathan Hart, YutaHiguchi, Masayoshi Kobayashi, Toshio Koide, BobLantz, Brian O’Connor, Pavlin Radoslavov, WilliamSnow, et al. Onos: towards an open, distributed sdn os.In
ACM SIGCOMM HotSDN Workshop , pages 1–6,014.[19] Dan Levin, Andreas Wundsam, Brandon Heller, NikhilHandigol, and Anja Feldmann. Logically centralized?:state distribution trade-offs in software definednetworks. In
ACM SIGCOMM HotSDN Workshop ,pages 1–6, 2012.[20] Eric Keller, Soudeh Ghorbani, Matt Caesar, andJennifer Rexford. Live migration of an entire network(and its hosts). In
ACM HotNets Workshop , pages109–114, 2012.[21] Justine Sherry, Shaddi Hasan, Colin Scott, ArvindKrishnamurthy, Sylvia Ratnasamy, and Vyas Sekar.Making middleboxes someone else’s problem:network processing as a cloud service.