SDN-BASED WAN OPTIMIZATION: PCE IMPLEMENTATION IN MULTI-DOMAIN MPLS NETWORKS SUPPORTED BY BGP-LS

Transcription

1 Image Processing & Communications, vol. 22, no. 1, pp DOI: /ipc SDN-BASED WAN OPTIMIZATION: PCE IMPLEMENTATION IN MULTI-DOMAIN MPLS NETWORKS SUPPORTED BY BGP-LS GRZEGORZ RZYM 1 KRZYSZTOF WAJDA 1 PIOTR CHOŁDA 1 1 AGH University of Science and Technology, Department of Telecommunications, Al. Mickiewicza 30, Kraków, Poland {rzym,wajda,cholda}@kt.agh.edu.pl Abstract. In order to provide efficient and flexible resource management and path set-up in high-speed MPLS/GMPLS networks, the PCE (Path Computation Element) architecture was proposed by IETF. Implementation of a central module for the path set-up enables network operators to run path establishment operations for applications with explicitly defined objective functions and QoS requirements. The paper reports on recent research and experimental investigations with PCE-based path computation performed according to the 3- layered traffic engineering (TE) system consisting of: (1) a PCE module equipped with the IBM Cplex LP solver used in the highest layer 3, and (2) a SDN controller in the intermediate layer 2 responsible for transferring path setup requests towards virtual routers in the lowest layer 1. The presented results show usefulness of the PCE-supporting architecture with an SDN controller and applicability of bandwidth-oriented optimization based on real-time focused constraints (path delay limits). We emphasise that even a simple optimization approach shows the power provided by the SDN, i.e., flexibility of flows. This property is in practice not feasible in classical IP or MPLS networks, that is the usage of flow-based routing provided by network programmability really opens opportunities in network tuning Key words. Border Gateway Protocol Link State (BGP-LS), Label Switching Path (LSP), Multi-Protocol Label Switching (MPLS), multi-domain traffic optimization, Path Computation Element (PCE), Software Defined Networks (SDN), Wide-Area Networks (WAN) 1 Introduction Contemporary broadband networks offer enormous transmission and forwarding/switching resources. Control over such the resources is performed mainly by the MPLS (Multi Protocol Label Switching) suite of protocols, with flexibility brought by successful emerging of the new SDN (Software Defined Networks) paradigm.

2 36 G. Rzym, K. Wajda, P. Chołda To compute paths in MPLS efficiently and with high flexibility, the IETF (Internet Engineering Task Force) has proposed an optimization framework and architecture known as PCE (Path Computation Element) [2]. The PCE concept is based on a dedicated module which introduces efficiency, flexibility and high-level visibility as well as the centralized control of MPLS domains and allows for highly dynamic resource management in the network. The PCE module is a solver of the optimization problem and acts as a network optimization manager realizing flow assignment task translated into the MPLS path set-up process. The PCE proposal was primarily designed for an intradomain traffic engineering (TE) but was also extended towards multi-domain and multi-carrier cases. Moreover, in recent years we have observed intensified works of PCE Working Group of IETF towards new enhancements of PCE resulting in a number of new drafts, also enabling integration of PCE with the SDN concept. It is worth noticing that these works have experiences a significant enthusiasm of network equipment vendors and were implemented by them (e.g. Cisco, Juniper) from the very early sketches. In this paper we focus on an optimization problem formulated in the form valid for real-time applications, such as VoIP and on-line gaming. This problem is defined as a multi-commodity flow allocation problem. The proposed constraints of the optimization task reflect limits for transmission delay of established paths. The paper is organized as follows. Section 2 briefly introduces the PCE architecture as the solution for a centralized path set-up optimization supporting IP flows. Section 3 extends the single-domain case with Label- Switched Path (LSP) configuration aspects for a multidomain network. Section 4 describes implementation aspects of the joint usage of SDN and BGP Link-State (BGP-LS), then in Section 5 the optimization model with directly imposed delay constraints for QoS is discussed. The implementation details, inclusing the test network topology, used tools and performance results are documented in Section 6. In summary, Section 7 presents concise conclusions and enumerates further investigation steps. 2 PCE From the perspective of network operator deployment of MPLS Traffic Engineering technique is one of the marketavailable solution implementing services with guaranteed transmission parameters. In MPLS, the path selection process is crucial to achieve the required qualitative parameters or minimize the cost associated with the usage of available resources. The selection process comprises not only finding of the route for the LSP but also reservation of transmission parameters. The effective LSP (Label Switched Path) choice can be influenced by the delay between the end of the optimization process and resource reservation in the network or the limited knowledge about network topology, traffic engineering and current utilization of resources. Therefore, in order to run efficiently and smoothly the path selection process, IETF proposed introduction of Path Computation Element (PCE) as a dedicated network element (module) responsible for the path computation [2]. 2.1 PCE architecture PCE architecture reflects centralized and flexible approach to flow assignement and routing and is composed of PCE server (PCE), PCE client (PCC) and dedicated communication protocol (PCEP). PCC is an application client located usually in access router which initiates path computation process. Path Computation Server runs optimization process using information gathered from the network and available from TED (Traffic Engineering Database). PCEP is responsible for communication between PCE server and clients or among servers located in

3 Image Processing & Communications, vol. 22, no. 1, pp different domains [11]. PCE can be used in two modes: stateful and stateless. In the former one, PCE module keeps full synchronization with the network and thus knows topology, link capacities, established LSPs and reserved resources (bandwidths) [8, 13]. The latter does not know active LSPs and each path set-up request is served independently. Stateless mode seems to be not proper solution for PCE since network managers expect full insight and results of efficient optimization process from PCE but it appeared that keeping full synchronization (in stateful mode) is rather difficult and raises scalability issues in real cases, faced by operators. Nevertheless, we have implemented stateful version of PCE as the solution employing optimally all available resources. 2.2 PCEP Path Computation Element Protocol (PCEP) is a communication protocol used to exchange information between PCC and PCE, and also between two PCEs [11]. In order to ensure reliability PCEP uses TCP as a transport protocol. At the time of writing this article a number of enhancements to PCEP had the status of IETF drafts. Document [13] defines new type of messages exchanged among MPLS network nodes implementing PCEP with the stateful extensions. For instance, stateful-enabled PCE sends Path Computation LSP Initiate messages with the Explicit Route Object. Moreover, new objects introducing tunnel assignment to a particular PCE were added in order to protect against path modification by another PCE servers (LSP delegation). Enhancement proposed in [8] defines new PCEP messages: (1) Path Computation State Report sent by the PCC to PCE to report the status of one or more LSPs. It can contain actual path parameters such as: addresses of consecutive nodes through the path, path bandwidth, its administrative or operating state, and, (2) Path Computation Update Request sent by the PCE to PCC to modify the parameters of a path or remove the assignment of a path to the PCE. 3 PCE deployment scenarios In this section we analyze and compare various available approaches of implementation of the PCE-based solutions for the single and multi-domain networks. Each of them is briefly described, then advantages and limitations are discussed. 3.1 Single-domain PCE Network operated by a single operator that usually owns this network infrastructure is a single-domain network. In such a network routing protocols, such as e.g. OSPF-TE, are able to exchange information about traffic engineering databases without any restrictions. Decisions on how and how much of the data are distributed in the network is only taken by the administrator. To ensure that customer s requirements are satisfied, as well as the network operation cost is minimized, the administrator may want to create its own route selection algorithm. Such a possibility gives him MPLS in combination with PCE. In a single-domain scenario a network operator is not constrained by any external policies. It has the ability to implement different schemes, one or multiple PCE servers, according to the very specific needs. Furthermore, during the optimization process additional parameters may be also taken into account (e.g. used technology, signal quality, alarms from the network, etc.) without any restrictions. 3.2 Multi-domain PCE One of the reasons for the introduction of PCE is a limited knowledge about foreign/neighboring network topology, its routing and TE databases. Moreover, in multidomain networks pure BGP does not pass information

4 38 G. Rzym, K. Wajda, P. Chołda about links states, etc. In order to ensure a proper level of QoS PCE concept can be implemented. In this section we present various approaches resulting in LSP (Label Switched Path) optimization in multi-domain networks Central PCE In case of central PCE serving many domains (Figure 1) one PCE server should posses knowledge to compute a LSP spanning multiple ASes (Autonomous Systems). Such information can be provided by administrators and be a result of operators collaboration (e.g. federation) or can constitute a commercial service. Additionally, there exist an extension to BGP that provides a possibility to share link state and traffic engineering databases among different ASes, i.e. BGP Link State (BGP-LS) [6]. PCE Figure 2. A LSP is computed independently within each domain by its internal PCE server in accordance with its internal routing policies and TE database. In each AS, PCE server determines LSP that ends in the neighboring AS (ASBR Autonomous System Border Router), forcing the beginning of the MPLS tunnel in the next AS. Then, the process is continued from the perspective of the next domain. Lack of coordination between PCE servers can lead to the creation of sub-optimal paths (from the global perspective). Moreover, this is often the main cause of the lack of reachability of the destination node. PCE1 PCE2 PCE3 R5 R1 R3 R7 R9 R1 R3 R5 R7 R9 R2 R4 R6 R8 Domain 1 Domain 2 Domain 3 R2 R4 R6 R8 PCEP OSPF-TE RSVP-TE Domain 1 Domain 2 Domain 3 BGP-LS PCEP OSPF-TE RSVP-TE Fig. 2: PCE per domain. Lack of cooperation among PCE servers. Fig. 1: Central PCE. Due to the internal polices of the operator such information (LSA and TE DBs) may be filtered and modified, protecting interests of a service provider. Despite the fact that both IGP and EGP protocols may carry the same information, such a solution is more scalable than in multidomain network without EGP and allows for the use of all possibilities offered by BGP PCE per domain without the cooperation The approach of implementation of PCE server per domain without cooperation among them is shown in the Standard Backward Path Computation PCEP enables the possibility of collaboration among different PCE servers located in neighboring domains. In such an approach LSP may by established in accordance with the Standard Backward Path Computation [14] concept. Standard Backward Path Computation assumes existence of PCEP session among servers. Furthermore, knowledge about the AS path (sequence of domains from source to the destination node) is know in advance. The LSP set-up process is presented in the Figure 3. PCE1, after receiving the request of the path set-up from R1 to

5 Image Processing & Communications, vol. 22, no. 1, pp R9, sends the PCReq message to PCE2. Then, this message is propagated to the next PCE server until it reaches the PCE server located in the same domain as the R9 router (in our example PCE3). In a next step, PCE3 replies PCE2 with the PCRep message containing ERO (Explicit Route Object) with a fragment of the path that passes through this domain, i.e., R8-R9. PCE2 computes the path within its own domain. Then, PCE2 sends the PCRep containing calculated fragment and fragment received from PCE3, i.e., R6-R8-R9. Next, PCE1 performs a path selection within domain 1. Then, PCE1 correspond to the R1 (source router) with the list of next-hops along the entire path, i.e., R1-R2-R4-R6-R8-R9. It allows the R1 router to send RSVP-PATH message signalling LSP in the network. From the global point of view, the chosen path may by also sub-optimal. However, presented process of cooperation among PCE servers eliminates the problem of reservation of resource by RSVP-TE belonging to the path which does not reach the destination node. path is also computed recursively from the end, i.e., starting from destination domain. However, in replay to a PCReq message, PCE server passes a (virtual shortest path tree) computed in accordance with internal routing policies and TED. Such messages with potentially shortest paths, as well as their metrics, are send in the Metric objects of the PCRep message. In analyzed example (Figure 4) PCE3 provides to PCE2 information about available paths to R9, i.e., R7-R9 and R8-R9, both together with calculated metrics. ERO objects may contain very exact paths, router by router (explicit path) or only loose hops. The process is repeated until originating domain is reached. Then, the optimal path is computed. The Backward Recursive Path Computation standard allows to determine globally optimal path without announcing information about internal structure of domains. Passed information may be aggregated (loose hops and metrics) but still sufficient for set-up a globally optimal path to the destination node. PCE1 PCE2 PCE3 PCE1 R1 R3 PCE2 R5 PCE3 R7 R1 R3 R5 R7 R9 R2 R4 R6 R8 R9 R2 R4 R6 R8 Domain 1 Domain 2 Domain 3 Domain 1 Domain 2 Domain 3 PCEP OSPF-TE RSVP-TE Fig. 3: PCE per domain. Standard Backward Path Computation. PCEP OSPF-TE RSVP-TE Fig. 4: PCE per domain. Backward Recursive Path Computation Hierarchical PCE Standard Backward Recursive Path Computation Backward Recursive Path Computation works very similarly to the Standard Backward Path Computation. The The hierarchical approach is presented in the [7]. In the example illustrated in the Figure 5 cpce (child-pce) of each domain communicates with ppce (parent-pce) using PCEP. Each cpce has only knowledge about TED be-

6 40 G. Rzym, K. Wajda, P. Chołda longing to its domain. The ppce stores list of domains and information about available inter-domain connections in order to be able to determine sequence of domains (AS path) that LSP will pass. In considered topology cpce1 receives request for calculation of a path connecting R1 and R9. Since R9 does not belong to the domain 1, cpce1 passes such a request to ppce. Firstly, ppce determines AS path. Then, ppce sends parallel requests to cpce1, cpce2 and cpce3 with demand of path computation within each domain. At the same time, ppce sends a request to cpce2 to calculate connections between AS1-AS2 and AS2-AS3. Each cpce replays to ppce with computed paths together with corresponding metrics. ppce, based on received information, computes optimal path between R1 and R9 and sends it to cpce1. Then, signalling process with usage of RSVP-TE may be triggered. ppce 4 PCE concept using SDN & BGP- LS Open Networking Foundation defines SDN (Software- Defined Networking) as a modern network architecture that separates the data plane from the control plane, which is fully programmable [16]. In traditional networks configuration of devices is limited by implemented and available functionalities and is a low-level process. The SDN concept enables operators to create high-level applications that can control and monitor the behavior of the entire network. Centralized configuration and control makes it possible to easily specify variety of tasks within a single application. Such an approach allows administrators to create complex policies and procedures for network management. It also simplifies network configuration and troubleshooting. In SDN paradigm control plane is centralized. It does not mean that the controller is physically located in the center of a network. Moreover, it does not meant that only single instance of SDN controller can be implemented. Notwithstanding, in order to improve the network performance, reliability, and scalability different communicating controller instances should be run on several cooperating and synchronized servers. cpce1 cpce2 cpce3 4.1 SDN architecture R5 R1 R3 R7 R9 R2 R4 R6 R8 Domain 1 Domain 2 Domain 3 PCEP OSPF-TE RSVP-TE Fig. 5: Hierarchical PCE. SDN network consists of three layers: application plane, control plane and data plane (Figure 6) [15]. Each of them has a specific task. Application plane contains a program communicating the network operator via northband interface with a controller belonging to the control plane. The controller is used to control the network. It applies policies and actions implemented in the application layer. Its tasks include monitoring and passing the state of the network to the application plane. Controller has two interfaces: north serving, as previously mentioned, communication chan-

7 Image Processing & Communications, vol. 22, no. 1, pp nel with application plane, and south connecting control plane with data plane, passing control information to the network devices and collecting information from them about network status. Data plane consists of network devices providing forwarding (switching) functionalities and performs network traffic control. Application plane Control plane Data plane SDN controller Switches & Rrouters Application Fig. 6: SDN architecture. Northband API Network services Southband API 4.2 BGP-LS BGP (Border Gateway Protocol) does not introduce the possibility to provide information about link s states and applied traffic engineering among different autonomous systems. Implementation of PCE as a mechanism for path calculation between nodes potentially located in different administrative domains requires possession of a knowledge about network topology of foreign domain. So far, PCE could not calculate globally optimal path passing a network belonging to another autonomous system. The intensive standardization work aimed at defining of a new protocol allowing for distribution of information about links state and traffic engineering databases. From the very early drafts of [6] network equipment vendors (such as Cisco and Juniper) implemented new proposal of extension to BGP called BGP Link-State proposed by IETF. In BGP-LS a router maintains one or more databases storing link state information from an given area. Those information applies: local/remote IP address, local/remote interface ID, link metrics, TE metrics, link throughput, available link throughput (possible to reserve), resource reservation for each CoS (Class of Service), preemption, Shared Risk Link Groups. The BGP process can retrieve shared information from databases and pass it to the recipient directly or indirectly, through another BGP router (see Figure 7) [6]. Information about link state and traffic engineering are carried in the TLV ((Type/Length/Value) fields. There are two available formats: NLRI Network Layer Reachability Information describing links, nodes, and prefixes obtained from an inter-domain routing protocol, BGP-LS attribute carrying information about properties of links, nodes, and attributes such as link or prefix metric, router ID. Receiver BGP router Receiver BGP router BGP router BGP router IGP IGP IGP Fig. 7: Process of gathering information about network topology by BGP-LS. 4.3 PCE deployment into SDN paradigm PCE and SDN seems have very similar, layered architecture. But when comparing SDN concept with PCE, the former is conceptually broader and can thus incorporate

8 42 G. Rzym, K. Wajda, P. Chołda the latter (PCE). One of possible solution (among others, e.g. OpenFlow, SNMP) for southband interface of SDN is PCEP. In the highest layer of SDN architecture optimization application (e.g. implementing objective functions presented in [12]) acting as PCE server should be deployed. Controller is only used as an intermediate layer translating high-level output to low-level instructions for network nodes. The possibility of deployment of PCE architecture into SDN paradigm was introduced in the OpenDaylight (ODL) controller in BGPCEP project [18]. ODL implements two interfaces allowing for communication between controller and network devices: first one BGP- LS [6] used to pass information about TED (Traffic Engineering Database) and LSDB (Link State Database), and the second one PCEP used to create, modify and delete LSPs. Moreover, from the perspective of RFC4655 [2] Open- Daylight does not fulfill criteria of PCE architecture. It provides only APIs allowing for communication between controller and: high-level application (used for network optimization), and network nodes (routers, switches). 5 Model There are six optimization models formulated in accordance with RFC All of them can by applied by PCE [12]. There are three objective functions that apply to a single path computation, and three others are used for computation of multiple paths at the same time (when multiple synchronous demands occurs). We propose an extension for a multi-commodity flow allocation problem [3], [10] with the additional delay constraint. Below, we present a description of indices, constants, decision variables, the objective function and constants used for the model formulation. The used flow allocation model is known as link (arc) path formulation. Indices: e = 1, 2,..., E d = 1, 2,..., D p = 1, 2,..., P d k = 1, 2,..., K Constants: links demands candidate paths capable to fulfill demand d segments used to approximate the link delay function with linear segments δ edp = 1 if link e belongs to path p realizing demand d; 0, otherwise h d volume of demand d C e upper bound of capacity of link e Ecost e unit cost of link e ˆD d maximum acceptable delay for demand d M a sufficiently big number, e.g., M = 10 9 a ek, b ek coefficients of the linear pieces of the piecewise linear approximation of the delay at link e Variables: y e u dp z e m edp Objective: non-negative continuous capacity assigned to edge e binary variable; = 1 if demand d is realized by path p; 0, otherwise auxiliary non-negative continuous variable used as approximation of the delay experience at link e auxiliary non-negative continuous variable, used for the delay constraint formulation, it attains values according to the identity: m edp = u dp z e min F = e Ecost e y e (1)

9 Image Processing & Communications, vol. 22, no. 1, pp Subject to: u dp = 1 d = 1, 2,..., D (2) p δ edp h d u dp y e e = 1, 2,..., E (3) d p y e C e e = 1, 2,..., E (4) δ edp m edp ˆD d d = 1, 2,..., D (5) e p z e a ek y e + b ek m edp M u dp m edp z e m edp z e M(1 u dp ) e = 1, 2,..., E k = 1, 2,..., K (6) e = 1, 2,..., E d = 1, 2,..., D p = 1, 2,..., P (7) e = 1, 2,..., E d = 1, 2,..., D p = 1, 2,..., P (8) e = 1, 2,..., E d = 1, 2,..., D p = 1, 2,..., P (9) The presented model aims at total cost minimization (1) when the capacity unit (marginal) link cost Ecost is considered. Formula (2) assures that only one path p is satisfying demand d (only non-bifurcated flows are allocated). Equation (3) is to provide that all demands will be met and served with a candidate path, resulting in the link loads requiring capacity assignment y e. Constraints defined in formula (4) assure that the upper bound of link capacity C e will not be exceeded. Inequalities defined in formula (5) ensure that the summarized link delay experienced by a single d will not exceed the given limit ˆD d. Formula (6) is a piecewise linear approximation of a link delay function considered later in this section. Constraints (7)-(8) are to represent in the linear form that the auxiliary m edp attains value equal to u dp z e, thus representing the value of the delay experienced by demand d on its candidate path p with respect to link e. From the optimization viewpoint M should be no less than the largest possible value of m edp, i.e., due to the definition of the variables, no less than the largest acceptable link delay. In practice this value is related to the router construction (e.g., the longest possible time to wait for being served in an interface buffer). As we would like not to discuss this technical issue, we just assign M = In the presented formulation we use a piecewise linearization of a link delay being a convex function of a link load (i.e., the total assigned capacity y e ). We assume that link e can be modeled as M/M/1 queue and the average transmission delay for such a link can be expressed as in equation (10). In fact we could use any theoretical model, that represents the delay as an increasing convex function of the link load. The M/M/1 model is the simplest theoretical model, commonly known and accepted. That is why we use it. From the optimization viewpoint we could even use a characteristics obtained due to measures, but the mentioned model is most accepted. Instead of using the non-linear link delay formulation of this kind, the piecewise linear approximation presented in (11) may be used as proposed by [5] and [4]. Such the equation is an approximation, but it gives preliminary insight into the static behavior of the network. The approximation can be made more precise and the presicion level has very little impact on the solution process (it does not involve noncontinuous decision variables). d e (y e ) = 1 c e y e, 0 u e < c e (10) The presented model does not take into account the constant link transmission delay related to distance between network nodes. For such a purpose an extension of formula (5) as presented in formula (12) should be included,

10 44 G. Rzym, K. Wajda, P. Chołda where ˆL e is a constant link transmission delay (e.g. for a fiber link, this is equal to its length times 2/3 of the speed of light in vacuum). d(y e ) = y e for 0 y e < 1 c e 3 3y e 2 3 c 1 e for 3 y e < 2 c e 3 10y e 16 3 c 2 e for 3 y e < 9 c e 10 70y e c 9 e for 10 y e < 1 c e 500y e c e for 1 y e < 11 c e y e c e 3 for y e c e < (11) switches. All network nodes were run as a Cisco IOS XRv virtual routers [17]. The SDN controller (OpenDaylight) implementing PCE concept was deployed on the Ubuntu virtual machine. The following modules were installed: odl-bgpls-bgpcep-all to run BGP Link- State, odl-pcep-bgpcep-all to support PCEP and odl-dlux-all as the REST interface handler. IBM Cplex v was used as a solver of problems written in OPL language. Optimization computations were made on server equipped with: Intel(R) Xeon(R) 2.70GHz CPU, 32GB of RAM memory and running on Linux CentOS version el Network topology δ edp (m edp + u dp ˆL e ) ˆD d (12) e p 6 Implementation In this section, we present a set of tools used for testbed implementation running a multi-domain network topology with PCE and SDN orchestration. First, we show the network topology used for our tests, then its configuration and instrumentation as well as performance results. 6.1 Used tools Running a multi-domain network implementing PCE module requires integration of multiple different networking, virtualizing and programming tools. For the purpose of demonstration of the presented concept we used a virtualized environment. KVM (Kernel-based Virtual Machine) served as a hypervisor. This platform is based on the Linux kernel and allows to create virtual machines that can run any operating system together with virtualized resources. For each virtual machine up to 32 PCI devices can be pinned allowing, for instance, for creation of virtual network interfaces that can be connected into virtual All tests were carried on the network topology presented in the Fig. 8. The network consist of a three domains understood as separate autonomous systems: AS100, AS200 and AS1. AS100 and AS200 implement only one router, XR1 and XR8 respectively. Those routers act as a access routers for data centers located behind them. AS1 is a transit network. It provides connectivity between DCs located in AS100 and AS200. Both, AS100 and AS200 are multihomed, i.e., each of them has two inter-domain links connecting them with AS1. All domains use MPLS as a technique providing connectivity between DCs. Created LSPs span all three domains. Inter-domain routing was provided with OSPFv2, intra-domain with BGP. Additionally, BGP-LS was used to redistribute link state and traffic engineering databases. SDN & PCE AS100 XR1 e 1 e 3 e 6 XR2 e 4 AS1 XR4 e e 6 3 e 7 e 5 e 8 8 e 9 XR6 e 11 e 10 e 9 e 13 e 10 XR3 XR5 XR7 e 12 Fig. 8: Network topology AS200 XR8 e 12

11 Image Processing & Communications, vol. 22, no. 1, pp Tab. 1: Unit link cost. Link number Unit link cost Test scenarios Performance tests were conducted with network topology presented in the Fig. 8. The network was modelled in the form of graph, where routers are vertices and links are edges. We assumed that inter-domain links (i.e., e 1, e 2, e 12, e 13 ) operate in Gigabit Ethernet technology. Links within the AS1 domain are Fast Ethernet. The maxflow/min-cut of presented graph is equal to 300 [Mbps], and it is the maximum bandwidth that can be obtained between DCs [1]. It should be also taken into account that model presented in Section 5 does not provide possibility for flow bifurcation and the maximum rate for a single demand can not exceed 100 [Mbps]. In the proposed model we used unit link cost. The unit cost of a link price is diverse and is selected in such a way that bandwidth cost on the inter-domain links is higher than on intra-domain links within AS1. In addition, the unit cost of backup inter-domain link is higher than the primary one. The pricing is presented in the Table Results Conducted performance tests show computation time and memory usage of optimization algorithm implemented in PCE server using IBM Cplex solver. Tests were repeated 100 times for each set of randomly generated demands with flow sizes (i.e., bandwidth requests) and maximum delay limits. Then, 95% confidence intervals were computed. We present only results of successfully finished cases, since randomization of demands allows for infeasibility of the problem in specific conditions. Obtained results (Fig. 9) show that the optimization time increases nearly linearly with the increasing number of simultaneous demands. Moreover, the size of confidence intervals also increases with the number of input Optimization time [ms] Number of simultaneous demands Fig. 9: Computation time demands. Depicted results show that the time required for the optimization process can introduce significant delay. As a consequence such an additional delay can have an impact for the end-user perceived QoE. Very similar results (in the shape of plotted curve) were obtained for RAM usage (Fig. 10). As can be observed, optimization process had not consumed significant amount of available memory. RAM usage [MB] Number of simultaneous demands Fig. 10: Memory usage

12 46 G. Rzym, K. Wajda, P. Chołda 7 Conclusions In this paper we presented the analysis of deployment and implementation of an SDN architecture employing PCE module in the multi-domain MPLS network, additionally supported by use of information gathered by BGP-LS protocol. We discussed various possibilities to implementation of PCE in a multi-domain network. Additionally, the proposed optimization problem, used for multi-commodity flow allocation with additional constraints, is expressing real-time requirements of transmission delay limits. The delay constraints are individually imposed for each traffic demand separately. Moreover, for each flow the volume bandwidth demand should be met. The presented numerical results show the impact of the number of simultaneous demands for the computation time and the memory usage. Due to the proposed model assuming unit bandwidth link costs, we observed that the optimization time can introduce significant delay in the whole process of path set-up together with increasing number of simultaneous demands. The memory usage increases predictably with an increasing number of demands and is not a significant component when considering resources used for optimization process. As a future work we plan to investigate possible introduction of heuristics in order to reduce the optimization time of path set-up as well as multi-criteria optimization approach taking into account juxtaposing goals such as link open cost and delays. Moreover, we plan to illustrate the effectiveness of the PCE concept in a multi-domain network with additional operation scenarios. Acknowledgements This work was performed under Contract No References [1] Cui L., Kumara S., Albert R. (2010). Complex Networks: An Engineering View. In IEEE Circuits and Systems Magazine, 10(3): [2] Farrel A., Vasseur J.P., Ash J. (2006). A Path Computation Element (PCE)-Based Architecture. RFC4655. [3] Fonoberova M., Lozovanu D.D. (2005). Algorithms for Finding Optimal Flows in Dynamic Networks. In Computer Science Journal of Moldova, Institute of Mathematics and Computer Science. [4] Fortz B., Thorup M. (2000). Internet Traffic Engineering by Optimizing OSPF Weights. In Proceedings IEEE INFOCOM, Tel Aviv. pp , vol. 2. [5] Fortz B., Thorup M. (2002, May). Optimizing OSPF/IS-IS Weights in a Changing World. In IEEE Journal on Selected Areas in Communications. 20(4): [6] Gredler H., Medved J., Previdi S., Farrel A., Ray S. (2016). North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP. RFC7752. [7] King D., Farrel A. (2012). The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. RFC6805. [8] Medved J., Varga R., Minei I., Crabbe E. (2016, December). PCEP Extensions for Stateful PCE. IETF draft. [9] Paolucci F., Cugini F., Giorgetti A., Sambo N., Castoldi P. (2013). A Survey on the Path Computation Element (PCE) Architecture. In IEEE Communications Surveys and Tutorials, 5(1):2 13.

13 Image Processing & Communications, vol. 22, no. 1, pp [10] Pioro M., Medhi D. (2004). Routing, Flow, and Capacity Design in Communication and Computer Networks. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. [11] Le Roux J.L., Vasseur J.P., Lee Y. (2009). Path Computation Element (PCE) Communication Protocol (PCEP). RFC5440. [12] Le Roux J.L., Vasseur J.P. (2009). Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP). RFC5541. [13] Varga R., Minei I., Sivabalan S., Varga R. (2017, January). PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model. IETF draft. [14] Vasseur J.P., Zhang R., Bitar N., Le Roux J.L. (2009). A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths. RFC5441. [15] Xia W., Wen Y., Foh C.H., Niyato D., Xie H. (2015). Survey on Software-Defined Networking. In IEEE Communications Surveys and Tutorials, 17(1). [16] Open Networking Foundation: Software-Defined Networking: The New Norm for Networks. ONF White Paper, [17] xrv/install_config/b_xrvr_432_chapter_01.html (2017, February). [18] PCEP:Lithium_Operations_Guide#Creating_LSP (2017, February).