SDN controller for Network-aware Adaptive ...

SDN controller for Network-aware Adaptive Orchestration in Dynamic Service Chaining A.A. Mohammed∗, M. Gharbaoui∗, B. Martini† , F. Paganelli†, P. Castoldi∗ ∗ Scuola

Superiore Sant’Anna, Pisa, Italy † CNIT, Italy

Abstract—This paper presents an SDN orchestrator that offers adaptive path provisioning in dynamic service chaining to recover from congestion events throughout service chain paths. Moreover, the SDN orchestrator exposes a Northbound interface based on REST principles and on the Intent-Based Network Modeling Language data model that allows applications to describe their requirements for the network (including dynamic service chaining) without being concerned with low-level implementation details. Experiments in an emulated network environment have been carried out to show the feasibility of the approach and to evaluate the effectiveness of the orchestration process in terms of network resource usage and adaptation overhead. Index Terms—SDN, NFV, orchestration, dynamic service chaining, Openflow.

I. I NTRODUCTION Emerging technologies such as Software-Defined Networking (SDN) and Network Function Virtualization (NFV) promise to address cost reduction and flexibility in network operation while enabling innovative network service delivery models. Indeed, the deployment of middlebox functions as Virtual Network Functions allows network services (e.g., firewall, NAT, DPI) to be provisioned as virtual appliance and to be handled as independent service components that can be flexibly composed to provide dynamically established sequences of data processing capabilities, i.e., dynamic network service chains. On the other hand, an SDN controller can expose a Northbound Interface (NB-I) enabling applications to directly coordinate service deployments (e.g., hybrid clouds, content delivery networks) with the establishment of data delivery paths while addressing different application service requirements [1], [2]. The availability of virtualized network, computing and storage capabilities is expected to foster a composite networkcloud service provisioning ecosystem. A main benefit brought by this converging trend is the opportunity of adopting flexibility and scalability mechanisms typical of cloud computing in the networking domain [3]. As a result, new architectural models and techniques can be conceived for the combined chaining and orchestration of both network and application services. However, in order to effectively put in place and govern such scenarios, effective management and orchestration mechanisms are needed [4]. In particular, operational solutions are required to enable effective synergies between SDN network controllers with possible client applications, such as VNF orchestrators (e.g., according to the ETSI MANO c 2016 IEEE 978-1-4673-9486-4/16/$31.00

specifications [5]), orchestrators at the IT infrastructure level (e.g. cloud management platforms), as well as application service delivery platforms. In fact, a straightforward interaction would be desirable among such applications and network controllers in order to adapt service chains to ever-changing user requirements or to promptly recover from service outages or degradation events. In this work, we present an SDN controller with service orchestration capabilities (i.e., SDN orchestrator) that allows for effective interaction with applications for the purpose of establishing adaptive chains of network services. More specifically, the proposed SDN orchestrator supports the following capabilities: •

•

orchestration of network resources to allow adaptation actions to be triggered as data delivery degradations (e.g., congestions) are detected throughout network paths connecting the whole or part of service chains. In fact, degradation events are likely to occur as result of concurrent usage of network node capabilities among multiple services and the proposed orchestration allows for reactively adapting loads across network nodes while addressing required data delivery performance. exposition of a north-bound interface (NB-I) based on REST principles [5] and the intent-based NEtwork MOdeling (NEMO) Language specifications [6] to allow applications to request the set-up and tear-down of data delivery services throughout chains of virtual functions using application-oriented intent-based semantics, that is through prescriptive directives rather then dealing with technology-specific low-level implementation details.

The functionalities of the proposed SDN controller are in line with the current trends and initiatives in dynamic service chaining carried out by some standardization bodies. The Internet Engineering Task Force (IETF) is promoting the adoption of an intent-based interface to enable applications to easily describe their requirements for network connectivity to the network management systems [7]. Indeed, standardization efforts are ongoing for the NEMO Language, for which one of the main use cases is service chaining [8]. Moreover, the IETF is defining a set of control functionalities and interfaces required for establishing and recovering service function chains [9]. However, the current operational status (i.e., bandwidth utilization) of network nodes are not actually addressed while optimizing paths and balancing the loads as

this work actually does. Recently, few research works have been published that adopt SDN approaches for the on-demand provisioning of network service chains [10], [11]. However, both proposals do not address a comprehensive design of an SDN orchestrator which includes the specification of the NB-I according to current standards as well as orchestration (i.e., adaptation) functions to make middlebox service chains resilient against possible data delivery degradations. In [12] authors propose a set of traffic steering policies to implement different service chains through virtual network functions. They also use a monitoring system to allow an adaptive service chaining against network congestion. The main difference with our approach is that we maintain the service chain and we perform an orchestration at the infrastructure level (i.e., redirection of the traffic through unloaded switches), while in [12] the orchestration is performed at the service level (i.e., given the network conditions, change the service chain according to the enforcement or not of QoS). II. SDN N ETWORK O RCHESTRATION D ESIGN This section describes the SDN orchestrator functionalities that allows for the adaptive provisioning of delivery paths throughout network service chains while exposing a NB-I for the benefit of possible consumers of the offered capabilities (e.g., VNF orchestrators, orchestrators of virtual IT infrastructures and application delivery platforms) hereafter generically referred to as Applications. The proposed SDN orchestrator includes a number of service-related functions (i.e., Service Plane) that combine Floodlight network control functions [13] to provide a further layer of abstracted control of network capabilities at service (i.e, end-to-end) level. Basically, the SDN orchestrator maps data delivery service requests at NB-I into low-level directives (i.e., Openflow commands) thereby accordingly enforcing forwarding rules to the involved nodes. Besides abstraction and mapping functionalities, the Service Plane includes orchestration (i.e., adaptation) capabilities to maintain data delivery performance despite service degradation events (e.g., congestions) that are likely to occur in the network as result of concurrent usage of switch/link capabilities among different service chains. To this purpose OpenFlow traffic statistics on per-port/per-flow basis are collected to monitor the performance of service data delivery throughout the chains and, in case, activate appropriate adaptation actions to recover proper data delivery performance. In Fig. 1 the building blocks of the Service Plane are shown. The abstraction and mapping functions supporting the NB-I are assured by the following components: • a Request Manager which handles the requests received through the NB-I from Applications thereby supporting the exposition of the NB-I to setup either a basic delivery path between two specified endpoints or a composite delivery path between two specified source and destination endpoints while ensuring that a specified sequence of middlebox functions are traversed. It also coordinates the message exchange between the Applications and the Service Element responsible for the mapping functions;

ƉƉůŝĐĂƚŝŽŶ ƉƉůŝĐĂƚŝŽŶ ƉƉůŝĐĂƚŝŽŶ ^ĞƌǀŝĐĞWůĂŶĞ ĚĂƉƚĂƚŝŽŶ DŽĚƵůĞ

ZĞƋƵĞƐƚ DĂŶĂŐĞƌ

EĞƚǁŽƌŬ WĂƚŚ

^ĞƌǀŝĐĞĂƚĂ ĞůŝǀĞƌLJŶƚŝƚLJ ^ĞƌǀŝĐĞ DĂƉƉĞƌ

DŝĚĚůĞďŽdž 

^ĞƌǀŝĐĞ ůĞŵĞŶƚ

WĂƚŚ ŶĨŽƌĐĞŵĞŶƚ

^ĞƌǀŝĐĞ ŚĂŝŶ ^ƚĂƚŝƐƚŝĐƐ ŽůůĞĐƚŽƌ

E^ĞƌǀĞƌ

ĂƐŝĐEĞƚǁŽƌŬŽŶƚƌŽů&ƵŶĐƚŝŽŶƐ ŶĚͲWŽŝŶƚ

 ^ĞƌǀŝĐĞ &ƵŶĐƚŝŽŶy









^ĞƌǀŝĐĞ &ƵŶĐƚŝŽŶz

ŶĚͲWŽŝŶƚ

Fig. 1: SDN orchestrator: Functional design and Building blocks.

a Service Element which is responsible for coordinating provisioning actions of different path segments between a middlebox (or a source endpoint) and terminating at the next middlebox (or the final destination endpoint) overall establishing a service chain. The coordination of provisioning actions is delegated to different Finite State Machines in the Service Data Delivery Entity according to the required service. Each provisioning action leverages the Path Enforcement Entity that makes decisions to address the delivery path segment setup that is then actually enforced by the BNServer. Finally, the Service Mapper provides the sequence of intermediate service function instances based on the data stored in the Service Chain, Middlebox, Network Path databases; • a Basic Network Server (BNServer) which launches the Floodlight components, handles the low-level directives (i.e., Openflow messages [14]) to install the forwarding rules throughout the network nodes using the decision made by Service Element, and collects traffic statistics at switches. The databases include the following set of data to support Service Plane functions: • Service Chain database: contains service composition specifications, i.e., set and order of needed middlebox capabilities, used to drive the selection of the proper set instances [15]. The selection can be done by considering context-based information (i.e., user location) [16], or can be the result of algorithms optimizing a given utility function (e.g. delay) [17]]. • Middlebox database: contains a list of the available middlebox instances with related descriptive information (e.g., type, network location in terms of IP prefix, Data Path ID and port of the switch they are connected to) as well as operational status data (e.g., usage of CPU and memory, traffic load at interfaces, processing delay). This set of data are supposed to be provided by a relative management system, i.e., VNF managers [18]. • Network Path database: contains descriptive information about the data delivery (segment) paths (e.g., IP addresses •

of end-points, identifier and port number of intermediate network nodes) established throughout the network realizing (part of) running service chain instances. Moreover, it contains the operational status data of paths and switches collected by the Statistic Collector. The adaptation function is mainly supported by the following components: •

•

Statistic Collector that obtains the operational status data of paths (i.e., delay, throughput), after processing the set of collected OpenFlow statistics retrieved leveraging the BNServer, e.g., delay on per-chain basis, switch throughput computed from per-port byte counters; Adaptation Module is in charge of triggering the Service Element for the adaptation of (part of) service paths throughout different set of switches (i.e., redirection) as soon as a degradation event (e.g., congestions of one or more switches) is detected using operational data stored in the Network Path database.

(lines 20-22) excluding the overloaded switch from the set of switches considered for the new path setups. If the number of transmitted bytes for a given switch is lower than the threshold and the switch was overloaded in the previous periods, it is deleted from the overloadedSwitches list and considered again as available for new path setups (lines 15-17). The switch is not immediately deleted from the overloadedSwitches list otherwise it could be considered for forwarding traffic for incoming data delivery service requests. The threshold value is to be fixed based on design guidelines, e.g., level of reactiveness with respect to the occurrence of degradations. { ”objects”: { ”node”: [{ ”node-id”: chain id, ”node-name”: ”chain”, ”node-type”: ”chain-group”, ”sub-nodes”: [{ ”node-id”: fw1 id, ”order”: ”1” } { ”node-id”: lb1 id, ”order”: 2” }] }] ”flow”: [{ ”flow-name”: ”f1”, ”match-item”: [ {”match-item-name”: ”src-ip”, ”match-item-value”:{ ”string-value”: ”10.0.3.1”} }, {”match-item-name”: ”dst-ip”, ”match-item-value”:{ ”string-value”:”10.0.11.1”} }] }] } ”operations”:{ ”operation”: [{ ”operation-name”: ”o1”, ”target-object”: ”f1”, ”action”: [{ ”action-name”:”go-through”, ”parameter-values”: {{”string-value”: [ ”value”: chain id }]} ] } ]}

Algorithm 1: Path redirection algorithm 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Receive statistics of all switches from Network Path DB Get the list of active paths from database and assign it to activePaths for s ∈ SWITCHES WITH MIDDLEBOX do if bytesInPeriod ≥ THRESHOLD then Add s to overloadedSwitches ; for path ∈ activePaths do Get source and destination IPs and assign them to srcIP and dstIP; if remaining service time > 0 and srcIP and dstIP found in flowEntries then Send path deletion request to Service Data Delivery Entity; Add path to deletedPaths; end end end else if s ∈ overloadedSwitches then Remove s from overloadedSwitches; end end end for deletedPath ∈ deletedPaths do Send path setup request to Service Data Delivery Entity; end

The Path Redirection Algorithm describes the steps that are performed by the SDN orchestrator to recover from service degradations due to congestions of one or more switches. The Adaptation Module periodically receives from the Network Path database the operational data of all the switches (line 1) and the list of currently active paths (line 2). Then, for each switch that is connected to a (set of) middlebox, it performs the following operations (line 3-19). If the number of transmitted bytes is higher than a given threshold, the switch is considered as overloaded (line 5) and the orchestrator tries to redirect the active data delivery paths to other switches (lines 6-12). To do so, all the flow entries on the overloaded switch are deleted (lines 8-11). The controller then establishes a new path for each unique source and destination IP pairs

}

Fig. 2: Example of a request message for setting up a composite path expressed through the entities of the NEMO language in JSON syntax.

A. NB-I specification The NB-I of the SDN orchestrator is based on REpresentational State Transfer (REST) [19] principles. REST is a resource-oriented architectural style for networked systems, which is considered a best practice for building distributed hypermedia systems and web service interfaces. Indeed, REST is also widely adopted in the software-defined networking area. For instance, several existing SDN controllers already offer REST-based APIs (e.g. ONOS, OpenDaylight, Floodlight) [20]. For the sake of conciseness, we briefly describe here two of the REST key principles: (i) URIs as resource identifiers,

ϮϱϬ

ϭϱϬ

ϭϱϬ

ϭϬϬ

ϱϬ

ǁŝƚŚƌĞĚŝƌĞĐƚŝŽŶ

ǁŝƚŚŽƵƚƌĞĚŝƌĞĐƚŝŽŶ

ϭϬϬϬϬ

EƵŵďĞƌŽĨďLJƚĞƐ΀D΁

ǁŝƚŚŽƵƚƌĞĚŝƌĞĐƚŝŽŶ

EƵŵďĞƌŽĨďLJƚĞƐŝŶƚŝŵĞ΀D΁

EƵŵďĞƌŽĨďLJƚĞƐŝŶƚŝŵĞ΀D΃

ǁŝƚŚƌĞĚŝƌĞĐƚŝŽŶ ϮϬϬ

ϭϬϬ

ϱϬ

ϴϬϬϬ ϲϬϬϬ ϰϬϬϬ ϮϬϬϬ

Ϭ

ϮϬ

ϰϬ

ϲϬ

ϴϬ

ϭϬϬ

^ƚĂƚŝƐƚŝĐƐĐŽůůĞĐƚŝŽŶƉĞƌŝŽĚƐ

ϭϮϬ

ϭϰϬ

ǁŝƚŚƌĞĚŝƌĞĐƚŝŽŶ

ǁŝƚŚŽƵƚƌĞĚŝƌĞĐƚŝŽŶ

ϰ

ϲ

Ϭ

Ϭ

Ϭ

Ϭ

ϱϬ

ϭϬϬ

Ϯ

ϭϱϬ

ϴ

/ŽĨƚŚĞƐǁŝƚĐŚĞƐĐŽŶŶĞĐƚĞĚƚŽŵŝĚĚůĞďŽdž ƉůĂƚĨŽƌŵ

^ƚĂƚŝƐƚŝĐƐĐŽůůĞĐƚŝŽŶƉĞƌŝŽĚƐ

Fig. 3: Number of transmitted bytes in time - Fig. 4: Number of transmitted bytes in time - Fig. 5: Total number of bytes for switches Switch 4 Switch 6 connected to middlebox platform

which means that resources are exposed through URIs; (ii) uniform interface, which means that the interaction with the resource is fully expressed with four primitives, i.e., create, read, update, and delete. These operations can be mapped onto HTTP methods: GET reads the resource state, PUT updates the resource state, DELETE deletes a resource, and POST extends a resource by creating a child resource. We defined the HTTP operations and URIs for requesting the setup of a delivery path between two specified endpoints and the implementation of specific traffic policies, e.g. the definition of a service chain and the enforcement of a delivery path (i.e., traffic flow) to pass through a specified service chain. The latter case is handled through a resource called compositePath, which is specified in terms of endpoints and virtual functions to be traversed. Table. I. lists a subset of the operations exposed by the SDN orchestrator. The combination of HTTP method, URI and message body represents what the application asks the network to do. In this regard, we adopted the data model defined by the IB-NEMO IETF working group [6] and further specified in an open source implementation project [8] to model the content of the message body. The NEtwork MOdeling language (NEMO) aims to be an intuitive Domain Specific Language (DSL) which allows network users or applications to directly describe their requirements for the network without taking care of the low-level implementation details. This is in accordance to the principle that applications ask the network controllers ”what to do” and not ”how to do it”. NEMO offers a high level abstraction on network resources and network behaviors. The entities defined by NEMO are: (i) nodes (network elements, such as hosts, routers, subnets, network functions, chain of network functions), (ii) connections (virtual links between nodes) and (iii) flows (specific traffic in the network). Operations allow network users or applications to request for specific dynamic adaption on network services (e.g., rerouting a flow through a chain of network functions). Fig. 2 shows a message for a composite path setup requesting that all traffic originating at a node with IP address 10.0.3.1 and terminating to a destination node with IP address 10.0.11.1 should pass through a network function chain made by a firewall and a node balancer. This request is expressed through the entities defined in NEMO and represented in JSON syntax.

TABLE I: REST API offered by the orchestrator Resource URI . . . /path

HTTP Method POST

. . . /path/{path id}

DELETE

. . . /compositePath

POST

. . . /compositePath/ {path id}

DELETE

Description Creates a delivery path between the endpoints supplied in the request message. Returns a path identifier (path id) Deletes the delivery path identified by path id Creates a delivery path between the endpoints supplied in the request message. Returns a path identifier (path id) Deletes the composite delivery path identified by path id

III. P ERFORMANCE E VALUATION The SDN orchestrator has been tested for 11-switches network topology using Mininet network emulator. The switches have been collocated at as many nodes as the Abilene topology [21]. We evaluated the number of bytes in the OF switches for two cases: with flow redirection that is activated in case any switch is overloaded (current number of bytes exceeds a threshold fixed to 100MB) and without flow redirection. We considered four switches (switches with id 2, 4, 6 and 8) that are connected to emulated middlebox platforms. The test was repeated 3 times for 100 requests with an average inter-arrival time of 25 seconds and an average flow duration of 50 seconds [22]. We evaluate the effect of the two cases on the network performance and the overhead on the orchestrator. In Fig. 3 and Fig. 4 we plot the total number of received bytes in a given period of time (the statistics are collected every 20 seconds for this test) for two different switches, i.e., switch 4 and 6 respectively. The aim of these plots is to demonstrate the importance of having the redirection feature in terms of load balancing among the switches connected to the middlebox platforms in line with IETF directives [9]. Results show that without redirection feature, switch 4 is overloaded while switch 6 is under loaded. On the contrary, with redirection feature, when a switch is overloaded the current active flows in that switch are deleted along with all the other switches in the path and a new path is re-established

TABLE II: Overhead parameters

With redirection feature Without redirection feature

Number of exchanged messages 7348

Redirection time

Average RTT

0.3s

34.09ms

3507

0

6.2ms

excluding the overloaded switch. These redirection actions prevents degradations due to the overload and well balances the flows among the available switches. Fig. 5 plots the effect of adaptivity throughout the network by showing the total number of received bytes in the switches connected to a middlebox platform (i.e., switches with ID equal to 2, 4, 6 and 8) for the cases with and without redirection feature. Results show that the redirection actions have beneficial effects on the overall load of switches since the number of bytes is more fairly-distributed among all the available switches which confirms the load balancing characteristic of the redirection feature. Moreover, it is worth highlighting that while addressing data delivery performance, our approach preserves the quality of the perceived services since no packets are lost during the tear-down of the data delivery paths that are rapidly re-established through unloaded switches. However, these enhanced performance is obtained at the cost of increased number of exchanged messages, the presence of redirection time and a relatively high network latency that are reported in Table. II. As expected, the redirection feature increases the number of messages exchanged between the BNServer and the Service Element since every time a redirection is performed, a new path is calculated and new flow entries are set-up which necessitates further communication messages (e.g., path delivery set-up, path teardown, etc.). Moreover, these operations require a certain time evaluated to 0.3 seconds in these tests which is acceptable with respect to the overall flow duration. The Round Trip Time (RTT) measured using the Ping tool indicates a higher latency when the redirection feature is applied. In fact, the redirection increases the switching delay (i.e., the time a packet spends within a switch) which mainly depends on the communication overhead between the switch and the controller and the queuing of the packets. IV. C ONCLUSION This paper presented an SDN orchestrator for the adaptive provisioning of delivery paths throughout service chain of middlebox functions while exposing a NB-I for the benefit of VNF orchestrators, orchestrators of virtual IT infrastructures and application delivery platforms. Those functionalities are in line with current trends in standardization. The NB-I specifications has been described based on REST principles and the intent-based NEMO Language specifications. Indeed, the adoption of intent-based network abstractions is expected to effectively decouple SDN controllers and upper applications, while fostering the straightforward interaction between them for the purpose of easing the deployment of new services.

Adaptive functions are provided that activate recovery actions as data delivery degradations are detected (due to node or link congestions) throughout network paths connecting the whole or part of service chains. Those adaptive functions were assessed through a set of experiments on an emulated environment. Obtained results demonstrated their effectiveness in terms of load-balanced network resources usage and limited overhead. ACKNOWLEDGMENT This work was funded in part by the Scuola Superiore Sant’Anna on the NET-DRIVE project. R EFERENCES [1] B. Han, V. Gopalakrishnan, L. Ji, and S. Lee, “Network function virtualization: Challenges and opportunities for innovations,” Communications Magazine, IEEE, vol. 53, no. 2, pp. 90–97, Feb 2015. [2] B. Nunes, M. Mendonca, X.-N. Nguyen, K. Obraczka, and T. Turletti, “A survey of software-defined networking: Past, present, and future of programmable networks,” Communications Surveys Tutorials, IEEE, vol. 16, no. 3, pp. 1617–1634, Third 2014. [3] Q. Duan, Y. Yan, and A. Vasilakos, “A survey on service-oriented network virtualization toward convergence of networking and cloud computing,” Network and Service Management, IEEE Transactions on, vol. 9, no. 4, pp. 373–392, December 2012. [4] C. Chappel, “Unlocking network value: Service innovation in the era of SDN,” HeavyReading, White paper, June 2013. [5] ETSI, “Etsi gs nfv-man 001, network functions virtualisation; management and orchestration (nfv),” Tech. Rep. [6] Y. Xia, S. Jiang, T. Zhou, and S. Hares, “Nemo (network modeling) language,” Working Draft, IETF Secretariat, Internet-Draft draft-xiasdnrg-nemo-language-03, October 2015. [7] S. Hares, “NEMO (NEtwork MOdeling) language,” Working Draft, IETF Secretariat, Internet-Draft draft-hares-ibnemo-overview-01, October 2015. [Online]. Available: https://tools.ietf.org/html/draft-haresibnemo-overview-01 [8] “NEMO project,” https://wiki.opendaylight.org/view/NEMO:Main. [9] H. L. et al., “Service function chaining (SFC) control plane components & requirements,” Working Draft, IETF Secretariat, Internet-Draft draftietf-sfc-control-plane-02, November 2015. [10] Z. Quazi and et al, “Practical and incremental convergence between sdn and middleboxes,” in Open Network Summit, Santa Clara, CA, 2013. [11] Y. Zhang and et al, “Steering: A software-defined networking for inline service chaining,” in IEEE ICNP, 2013. [12] F. Callegati, W. Cerroni, C. Contoli, and G. Santandrea, “SDN Controller Design for Dynamic Chaining of Virtual Network Functions,” Fourth European Workshop on Software Defined Networks, 2015. [13] “Floodlight openflow controller,” http://www.projectfloodlight.org/floodlight/. [14] “Openflow specifications,” http://www.openflow.org. [15] F. Paganelli, M. Ulema, and B. Martini, “Context-aware service composition and delivery in ngsons over sdn,” Communications Magazine, IEEE, vol. 52, no. 8, pp. 97–105, Aug 2014. [16] B. Martini, F. Paganelli, A. Mohammed, M. Gharbaoui, A. Sgambelluri, and P. Castoldi, “Sdn controller for context-aware data delivery in dynamic service chaining,” in Network Softwarization (NetSoft), 2015 1st IEEE Conference on, April 2015, pp. 1–5. [17] B. Martini, F. Paganelli, P. Cappanera, S. Turchi, and P. Castoldi, “Latency-aware composition of virtual functions in 5g,” in Network Softwarization (NetSoft), 2015 1st IEEE Conference on, April 2015. [18] ETSI, “Network functions virtualisation (NFV) management and orchestration,” http://www.etsi.org/deliver/etsi gs/NFVMAN/001 099/001/01.01.01 60/gs nfv-man001v010101p.pdf. [19] R. Fielding, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, Univ. Calif., USA, 2000. [20] D. Kreutz et al., “Software-defined networking: A comprehensive survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, Jan 2015. [21] “Abilene network,” https://en.wikipedia.org/wiki/Abilene Network. [22] S. Chowdhury, M. Bari, R. Ahmed, and R. Boutaba, “Payless: A low cost network monitoring framework for software defined networks,” in IEEE Network Operations and Management Symposium (NOMS), 2014.