Dynamic LightPath Allocation in WDM Networks Using an SDN Controller

Core wavelength division multiplexed (WDM) networks are widely used to provide fixed physical connectivity and bandwidth to the logically connected upper electronic layer devices using optical signals. However, growing demands for bandwidth-intensive applications and cloud-based services push optical networks carriers’ to provide scalable and flexible services dynamically. Software defined networking (SDN) has the potential to program electronic layers by dynamically controlling and managing network resources using SDN controller applications. SDN’s on-demand characteristics combined with the optical circuit-switching can enable optical network service providers to customize their service provisioning dynamically to the user’s requirements. They enable fast provision of new services, and minimize under-utilization of resources. In this paper, a model is proposed to bring the dynamic allocation of resources which is a layer 2+ functionality, to the WDM layer using SDN. A middle-ware application based on SDN and OpenFlow for dynamic switching and provisioning of optical service is presented. The application abstracts the optical layer’s connectivity, also accounting for the switching constraints. Details of the model’s implementation are discussed considering classically used equipment and its performance in terms of CPU and memory utilization, topology emulation time, and latency is evaluated. Finally, the application is tested with a Cisco layer one switch. Performance results show that the latency doubles when increasing the number of fibers of an optical cross connect from 5 to 7 and keeping wavelengths equal to 8, with Clos fabric topology.

previous works [4]- [8]. However, nothing could be standardized yet because of the complex nature of the physical layer issues, starting from accounting for the physical impairments to the vendor-specific configuration mechanisms for optical paths. A significant advantage of extending SDN to photonic networks is the combined dynamic service provisioning and optimization by the SDN controller because of its global knowledge of several network layers. A recent work [9] provides an SDN-controlled platform to simulate end-to-end integrated data plane of packet and optical network. The physical behaviour of a WDM network is simulated using analytical models and an optical data plane is emulated as data packets with additional information about wavelength. The platform can be used to configure network elements in a customised manner, however; switching constraints are not considered in this model. Advantages of using the SDN controller in optical networks are explained in Section III. In the literature, there have been some efforts that deal with establishing the wavelength paths through the WDM layer using SDN, e.g., [10]- [12]. However, all of these have assumed fully interconnected switch fabrics, and the switching constraints are over-sighted. If the switch's internal fabric is busy and there is no available path through the fabric, then user's service provision request cannot be completed dynamically. Furthermore, none of the works have exploited the core potential of the OF protocol, i.e., dynamic resource allocation in response of a request, by generating the path request initiation from the WDM device itself. Either an IP router in the upper electronic layer is used or an agent-base approach is applied for request initiation purpose, further details of which are discussed in Section IV. Agent-based approach requires both the controller and the OF protocol, to be extended. Our work is an effort to design a middle-ware mechanism that can be used with any SDN controller and OF protocol versions without extensions, while taking into account the switch's internal limitations and also dynamically full-fills the service request and allocation of the resources.
In our work, we propose a model in which a single SDN controller can have a global view of all the possible paths within the switch, together with the end-to-end links between the devices. We use the popular "Mininet" emulator, further explained in Section V. The SDN controller will thus have a knowledge of all the available paths and can dynamically provision a connection when a request arrives. Our work is based on emulating the network connectivity, in the SDN controller as a network of layer two OpenFlow switches using Mininet. The controller thus does not have any knowledge of the underlying optical switches nor the wavelengths. Therefore no extensions of the SDN controller as well as OpenFlow protocol are required. A middle-ware application is developed to do all the translations between the controller and the optical network. Details of the model's implementation and tests are provided in Sections VI and VII respectively. Section IX describes the performance results while Section X provides discussion about the graphs. The paper summarizes with conclusions in Section XI.

II. BACKGROUND
SDN's potential in the packet domain has already been proven, initially by the researchers and now by the fact that some major companies are providing services and products based on SDN architecture and technology 1 . For optical networks, SDN has been suggested to be advantageous over existing control plane solutions in many aspects, see e.g., [13]- [15]. There have been efforts to extend SDN to optical networks; however, for multilayer convergence and control, layer one (electronic switching) as well as layer zero, i.e., wavelength switching layer should also be included in the SDN umbrella. Extending SDN to WDM layer has several challenges; though, from the physical characteristics of the communication signals to how the resources are allocated in vendors' proprietary equipment.

A. PACKET AND CIRCUIT SWITCHED NETWORKS
There is an essential and fundamental difference between circuit-switched and packet-switched networks, i.e., a packet-switched network do not pre-allocate resources before the first data flows. Instead, it allocates resources on-demand as datagrams arrive. On the other hand, circuit-switched systems pre-allocate resources before the first data flows. Those resources can then only be used for that instance of data flow. Optical transport networks are circuit-switched networks, which use light signals for faster delivery of packets from the source to the destination ports of layer two or layer 3 devices as shown in Figure 1. LightPaths are pre-computed and established by the management system and provisioning a new optical connection involves operator intervention. These mechanisms allocate the entire wavelength to a single connection, and the connections remain 'on' even when they are not utilized fully.

B. PATH ESTABLISHMENT IN OPTICAL WDM NETWORKS
Todays' commercial long-haul or core optical transport networks are implemented in a mesh topology with path planning and management done through a centralized network management system (NMS). NMS employs multiple element management systems (EMSs) to manage the whole network [1]. Usually, a single vendor's network elements are managed by a separate EMS. The EMS can have a view of only its attached network devices and does not have the overall network view. Therefore, for the management of whole network, all EMSs, are supposed to connect and report to the NMS. The NMS then manages all types of network elements, see Figure 1. Additionally, a simple device management system is needed to enable the craftspeople and other technical staff to configure and manage individual network equipment.
Two main components of a WDM network are reconfigurable optical add/drop multiplexers (ROADMs), and optical cross-connects (OXCs). ROADM is a wavelength switching device which is required when some of the wave- lengths need to be dropped or added locally in the network while others need to pass through to their destinations. OXCs are designed to perform almost same tasks as ROADMs but they have larger number of ports and wavelengths involved and are deployed in core optical networks. The OXC's core is its switch fabric. The switch fabric is a combination of switching cells which are arranged in the form of a either a crossbar matrix or multistage interconnections (MIN). The fabric usually exists in one of the popular form of MIN topologies, e.g., Clos, Benes, Banyan, or Tree. When a new connection is to be made, the local switch controller has to find an available connecting path in the switch fabric and issue respective electronic control signals to set up switching cells. Algorithms performing such tasks are reffered as control algorithms [1], [16]. The circuit-switched connection between WDM networks' client terminals is called LightPath and the process of finding the path and assigning a wavelength is designated as Routing and Wavelength Assignment (RWA) problem [17], [18]. Connection management tasks, e.g., setting/releasing and monitoring LightPath connections in a network is done by NMS and EMS.
For a new service provision, the user needs to request to the "Sales and Planning" department of the IP network. The Sales department puts up a request to the management department, which collaborates with the management of transport network and works out the feasibility of service provision, see Figure 1. As a result, it may take several months for a service provider to supply a new service in response to a user's new connection request. The span of these connections is generally for years. With the evolution of optical networks, connection demands are becoming more dynamic and networks are turning more extensive and complex. Carriers prefer to provide connections to their customers quickly and not hold them for a long time. The current mechanism of LightPath management has proven to be very complex and slow. It involves human labor, time, and is error-prone [8]. To a certain extent, dynamic connection provisioning is achieved by the wavelength switching and routing at optical switches; however, more research, technology and new methods, are required in this domain.

C. SDN AND MININET
SDN paradigm separates the control plane from the forwarding plane of a traditional network and brings the intelligence in a logically centralized controller that keeps the global network information and does strategic changes in routing and switching devices dynamically, based on different requirements, e.g., quality of service (QoS) or traffic engineering. The OpenFlow protocol, first introduced by N. McKeown et al. implements SDN and is a communication standard between the controller and the forwarding devices. For testing SDN solutions, an emulator called "Mininet" is mostly used which is a rapid prototyping environment that offers lightweight virtualization and flexibility. For further understanding, the working, benefits, limitations, and features of SDN, OpenFlow and Mininet, the reader is referred to [19]- [21].

III. ADVANTAGES
Employing SDN controller for dynamic control of optical networks brings many advantages with it, some of which are discussed below.

A. MULTILAYER CONVERGENCE
SDN has already shown its benefits in layers 2-4. A considerable benefit of encompassing optical networks with SDN will be the combined dynamic provision of services as well as optimization of multiple network layers. A central SDN controller based on its global view of all the layers can play a role in optimal resource allocation. If a service needs ondemand connectivity, the SDN controller can calculate an optimum path through multiple layers and can dynamically establish the connection, see e.g., [22].

B. DYNAMIC CUSTOMIZED PROVISION OF SERVICES
Provisioning of dynamic on-demand bandwidth pipes between end-to-end systems can benefit economically and improve network performance by dynamically giving preference to the customer's preferred service(s), based on instantaneous network status, e.g., see a use-case by [6].

C. TRAFFIC ENGINEERING
In SDN, the controller has a bird's-eye view of the network's resources and can improve its performance by providing effective traffic engineering solutions. The SDN controller can choose paths in order to balance the load on various links and devices in the network where multiple alternate paths are available, see examples in [23], [24].

D. OPTIMUM PATH CALCULATION
Centralized path computation has always been known to be more effective when compared to the traditional distributed VOLUME 4, 2016 path computation. Combining this advantage of SDN with others, e.g. taking into account the physical layer impairments, can improve end-to-end optimum path calculation, see e.g., [25]. Layer one transport networks also face another major issue of RWA. RWA can be handled better by incorporating contemporary RWA algorithms within path computation engine of SDN controller, see e.g., [26].

E. CONTROL OF ELASTIC OPTICAL NETWORKS(EONS)
To meet the highly dynamic traffic demands of the future, an elastic optical network has been regarded as a promising paradigm, which can offer a flexible data rate/channel allocation and high resource efficiency. The main purpose of EONs is to replace the fixed spectrum spacing with a flexible grid where an optical channel can span a smaller grid size for low data rates, whereas multiple slots to accommodate higher bit rates, e.g., 400 Gbps, thus supporting various data rates dynamically in a spectrum-efficient manner [27]. Technology advances associated with EON nodes have been identified as flexible grid add/drop and switching (essentially Bandwidth Variable Transponders and flexible OXCs), as well as spectrum conversion. To harness such a flexible network, a programmable control plane technique is required to program network functions dynamically according to the applications. However, this isn't easy to implement, as the control and data planes are currently integrated within the network nodes. Newly emerging software-defined optical networking (SDON) paradigm has a separated programmable control and data plane (DP) in which network functions and protocols are manageable according to the user's demand and applications [28]. The first feasibility and validation check of an OpenFlow-based control plane for an EONs has been presented in [29]. Further studies regarding software-defined elastic optical networks are reported in [28], [30].

F. PROTECTION AND RESTORATION
A well-established key feature of fixed-grid optical core networks is their protection and agile restoration when link failures occur. The critical factor that needs to be considered while planning protection schemes is a trade-off between redundant capacity and restoration time [31]. Most popular protection schemes are based on dedicated path protection; however, research studies are exploring the ways to improve the performance of these techniques for fixed-grid and EONs. Network-coding-based protection [32] is one of such proposed techniques; see for example [31]. With the paradigm shift to SDON, the protection and restoration tasks are performed by a centralized controller, which can perform optimum computations based on the global map of the network. The reader can find references to various studies with a focus on SDN-based protection and recovery in [33].

G. OPPORTUNITY FOR NEW BUSINESS MODELS
SDN's programmability and flexibility have opened up opportunities for the network carriers' to try new business models. Network operators can investigate, test, and implement new models using the controller to optimize optical network's cost and performance, e.g., better bandwidth provision or energy effectiveness, see examples in [34], [35].

IV. RELEVANT WORK
SDONs are being investigated and studied at the industrial as well as academic level. However, these investigations have varied scales and aim for different objectives. Good survey of previous research efforts has been reviewed in [7], [8], [36]- [38]. Here we will discuss the works, explicitly done at the WDM layer.
In [12], the authors propose to use IP router to invoke the request to the SDN controller for path establishment. The work proposes OpenFlow-enabled optical switches which can understand commands from the extended-NOX controller. The optical switch interfaces are mapped using virtual Ethernet interfaces 'veths' of an OF switch; however, internal switching constraints are invisible to the controller. Also, the optical switch is incapable of generating the request itself, and thus the full potential of the dynamicity of the OpenFlow protocol is not exploited.
References [11], [15] have used an agent-based approach and developed an extended controller with an application to compute LightPaths. It is not clear how the optical devices' constraints are considered by the resource model and their way of abstracting the devices' hardware, require them to use an extended OpenFlow protocol and an extended controller. Reference [10] uses the same agent-based concept and utilises a Path Computation Engine (PCE) and a Wavelength Assignment (WA) algorithm in the controller for computing LightPaths. The authors use a port emulation entity that maintains and receives updates about port status, used to calculate the LightPath, but no data is given for the switch fabric's limitations. They have also used an extended OF protocol.
Reference [39] uses a proxy application to control a WDM network device with the SDN controller. The authors have considered an end-to-end connection between devices as an optical link and used Simple Network Management Protocol (SNMP) to get the features of the switch; hence, the internal fabric connectivity is hidden from the controller. The work is conducted for integrating ROADMS, which are much simpler than OXCs, which are the main operating devices in the optical core networks.
The Open Networking Foundation Transport Working Group (ONFTWG) is a team, working towards extending SDN and OpenFlow protocol for transport networks. Some initial efforts are being made by ONFTWG as well as other emerging organizations for standardization. In [40], [41], authors have presented an ONOS control method using a disaggregated transport network.

V. PROPOSED DESIGN
The idea of parameterizing the WDM layer, as a layer two system that allocates wavelength paths in an on-demand fashion, is presented in this paper. The proposed framework demonstrates a way to abstract layer one network connectivity so that it can be used in a layer two paradigm. The abstraction also includes the internal connectivity of the switch fabrics of OXCs and ROADMs and hence incorporating switching constraints as discussed in [8]. Switching constraints are imposed by the topology of the switch fabric, which is often chosen to reduce the cost and may result in congestion and hence non availability of the path through the fabric. This leads to declining a service provision.
Our model uses a central SDN controller and the emulated connectivity of layer one to control the end-to-end network connections. Incorporating the connectivity of switch fabrics helps the SDN controller to make "Network Graph". OXCs use different control algorithms to find paths through their switch fabrics. Algorithm for one fabric, may not work for others. Abstracting the connectivity eliminates the need for different equipment-specific algorithms, and one algorithm can be used to find end-to-end path in different classes of equipment.
In WDM optical networks, another limitation is "Wavelength Continuity Constraint" (WCC), which is catered in a component of our model called Resource Management System (RMS). The RMS component serves as a portal or application that maintains and manages virtual abstraction of paths of an optical network, so that customers are served dynamically as per their needs. With dynamic path establishment using SDN controller, the requirement for the alwayson connections can be eliminated thus avoiding wastage of resources, when not being used. Our way of abstraction does not need to use any extended controller nor any extensions to the OF protocol. Figure 2 represents the overview of the proposed design. RMS is used to parameterize the layer one optical network to the SDN controller, as a network of layer two OF switches. The WDM link is emulated as a combination of Ethernet-linked interfaces, each representing an individual wavelength. The controller is used to find a path from source to destination through this network. The RMS uses the path information in the emulated network and sends commands to Layer one devices to set up the physical path through the optical network. The proposed model assumes the invocation of path-requests from the optical switch itself. The model also assumes that the optical device can extract destination address from the incoming signals. The RMS can also include a "scheduler" component to save future requests. Details of the components of the proposed model are as below.

A. RESOURCE MANAGEMENT SYSTEM (RMS)
The RMS is responsible for performing multiple tasks and acts as a middle-ware between the SDN controller and optical network. It has many components and performs actions like collecting information from the optical switches, abstracting layer one connectivity, translating path found by the SDN controller, and wavelength availability check. It also main-

B. SDN CONTROLLER
This is any conventional SDN controller with path computation ability. It can be loaded with customized applications for advanced control of this system, such as a few mentioned in the Section III.
The proposed design achieves the goal of dynamic path establishment in few steps. The first step involves "Network Graph" creation. This step can be challenging as there is no network connectivity initially (within switches), and resources will be allocated once the traffic flow starts. However, if all the possible paths are abstracted, see, e.g., [42], the SDN controller is able to make a network graph. Thus the SDN controller can have a global view of the layer one network, emulated as a layer two network. The second step follows when a request signal arrives at an optical switch. The relevant information of this request is sent to the RMS by the switch, which triggers the path calculation process in the RMS using the SDN controller. The controller computes the path for the emulated network, and flows are installed in the OF switches. In the next step, this path is translated back by the RMS to a form that is understandable by the optical devices, and finally, it sends commands to physically set up the path through them. This model appears to be an agent-based approach, however the way we implemented it (see sectionVI), is instead a middle-ware approach. Flow chart and timing diagram for this process are discussed and VOLUME 4, 2016 represented in [43].

VI. IMPLEMENTATION
Our RMS is in the form of a GUI application to implement the proposed design. We used the RYU controller and ran the application namely, "simpleswitch1.3" along with the "Spanning Tree Protocol" application to avoid any loops in the topology. Python and Bash scripting have been used to implement the components of the RMS. The components of this application are shown in Figure 3 and are explained as below.

A. INFORMATION COLLECTION COMPONENT
The information collection component serves the purpose of the topology discovery. Layer one switches are required to have knowledge about their neighbors either through a protocol like Link Layer Discovery Protocol (LLDP) or installing static files. Every switch has an interconnection of switching cells to make input-output port connections through it, called switch fabric, common examples of which are Clos, Benes, and Banyan [1]. Information collection components can be made to use any protocol to extract switch fabric information from the switch, for example, SNMP. However currently, switch fabrics are not managed in this way, so we have implemented it as a manual process to provide information such as, type of the switch fabric, number of fibers, number of allowed wavelengths per fiber, and a neighbors table.

B. EMULATE NETWORK TOPOLOGY
In order to abstract the layer one network topology, we have used a popular emulator, called "Mininet". The emulated network represents all layer one possible connections in the form of a layer two devices' (OF switches) network to the SDN controller. For every possible wavelength route, a packet based Ethernet link between two OF switches is formed in an emulated topology and each port of the optical switch is represented by an individual OF switch. The component emulates Layer one connectivity using an "Emulation table" which has information for mapping of the optical paths of WDM layer in Mininet. For this work, we have chosen the "Clos" and "Crossbar" fabric topologies for demonstration, however any other topology can be emulated. The Mininet topology is emulated as a wavelength selective architecture, further details of which are explained in [42]. Once the "Emulate topology" button is pressed, the topology is constructed in Mininet and OF switches will start registering themselves with the SDN controller.

C. STATE TABLE INITIALIZATION
The state table maintains the status of all the current, past and future connections and wavelengths assigned to them. The path found by the 'Translator' component is checked for its availability against the state table. The state table can be initialized at any stage of the simulation.

D. SPOOFING
Once the Mininet topology is created, the SDN controller will have a global view of the network. The controller can now find a path between any source and destination port (OF switches). When the light signal arrives at any of the optical switches, the switch will send the request for path and also the destination address to the RMS. The RMS will initiate the process of spoofing a frame arrival at the OF switch, corresponding to the same optical port that received the signal. After this, a standard OF protocol procedure involving "PacketIn" and "PacketOut" messages will start.
To implement spoofing, we have used the "Ping" command. When the "Ping" process is invoked, the OF switch looks for a flow entry in its table. If no path is found, a 'Packet In' message is sent to the controller. The SDN controller finds a path between source and destination ports and installs flow entries in the OF switches. A successful ping means that there is a possible route between the source and destination ports of the optical switch (es).

E. ACCESS FLOW ENTRIES
This component accesses flow entries of the OF switches after the 'Ping' process completes. It then verifies if the path is a valid path between the required source and destination ports. For this purpose it uses the topology information of the network.

F. TRANSLATOR
Translator uses the "Emulation table" and translates the layer two network path into a layer one path. It then checks if this path is idle (using state table) and also availability of a single wavelength along this path to satisfy the WCC. If both conditions are satisfied, it can then trigger the "Path setup" component.

G. PATH SETUP
This component is responsible for sending commands to the optical switches that are understandable by them and establishing a LightPath. These commands tell the switch to make connections between specific switch cells and the ports' interfaces, thus establishing circuit switched LightPath.
Since the whole process initiates when the requests from the optical switches arrive, this is used to dynamically find the path with no need for pre-allocation of resources as in conventional WDM networks. Another worth considering aspect of the WDM networks, while moving from static to dynamic path allocation, is to take care of the protection strategy. With our framework, it is easy to add a "link failure" component in the RMS, which will store alternate paths computed by the SDN controller. Upon receiving a link failure alarm from the switch, this component can communicate the alternate route to the optical switch and restore the traffic. We left the implementation of such a feature for our future work. Here, the RMS GUI application has been designed to have buttons for performing the respective tasks. However this is only done for demonstration purposes. The RMS only needs to receive a request from the switch and the rest of the path establishing process is automatic. If the light signal stops striking a port for a certain threshold time, the optical switch needs to inform the RMS and the path setup component will send commands to reset the switching cells of the optical switch to terminate the connection and will also update the state table.

VII. TESTING
In order to prove the concept of the dynamic path establishment process using our model, we have tested our developed RMS with a layer one switch by Cisco namely Nexus 3550-F Fusion (formerly called ExaLINK Fusion) 2 , see Figure 4. The ExaLINK Fusion has layer one switch characteristics and consists of a crossbar switch fabric that can be dynamically set up to provide a connection between any of its ports. The switch offers SNMP and JSON remote procedure call services that we have used in our testing. Figure 5 represents the testing scenario. ExaLink Fusion is assumed to have one fiber having 16 wavelengths comprising of A1-A16 (input), and B1-B16 (output) crossbar fabric for this experiment.
Steps followed for the testing are described below.
1) The RMS is provided with the information required for emulating a crossbar fabric topology, manually. Once the button "Emulate topology" is pressed, a cross bar topology is created in Mininet, see Figure 6. 2) When the signal arrives at one of the input ports of the ExaLink Fusion, it sends SNMP "trap" notification to the SNMP engine running in our Linux Machine which is integrated with the RMS, see Figure 7. 3) After analyzing this trap notification, the RMS uses spoofing mechanism (destination address is chosen random) to find path through the switch, see Figure 8. 4) When an available path is found and translated for the switch, the system uses remote procedure call (RPC) JSON interface to configure ExaLink Fusion to establish path between ports, e.g., path established between ports A1 and A3, as shown in Figure 9. Figure 3 represents the case where RMS GUI is given parameters of a "Clos" type of topology, and the number of switches/OXC in the network is one. At the same time, the number of fibers and wavelengths/fiber in that switch are also provided. Pressing the "Emulate topology" button of the RMS GUI runs a python script that takes these input parameters and uses an embedded topology creation algorithm to emulate the WDM network connectivity in Mininet. Figures  10 and 11 show the cases for two fibers, two wavelengths (2F, 2W) and three fibers, two wavelengths (3F, 2W) for Clos type of OXC's switch fabric, respectively. To see the case for (3F, 3W) and understand how this topology maps the actual VOLUME 4, 2016  optical switch fabric, the reader is referred to [42]. To find out the effect of the number of wavelengths and fibers on Mininet topology creation, we analyzed the "Generate Mininet topology" algorithm [42]. For example, we noticed that to map the wavelength-selective architecture of Clos fabric in Mininet; we need twice the number of hosts for a single increase in the number of (F ) or (W ), hence the equation (3). We noticed that three entities of a Mininet topology, i.e., OpenFlow switches (S), hosts (H), and links (L)) depend on two factors namely fibers (F ) and wavelengths/fiber (W ), see equations (1), (2), and (3). Figure  12 represents the trend for these entities with the increase in the number of wavelengths (F is kept constant) for a Clos type of optical switch fabric. It is observed that the effect of varying F is not as prominent as with W , as apparent from the equations as well, thus here, we are only showing the trend with the number of wavelengths while keeping the number of F constant (e.g., five).

VIII. TOPOLOGY CREATION
It can be seen from the graph that the increase in the number of links is huge with the increasing number of wavelengths.
For example, increasing wavelengths from 4 to 6, increases the number of links from 200 to 410, this is because every possible path for a wavelength in an optical network is represented as an individual Ethernet link in the Mininet emulation. Similar equations can be found for emulating other types of fabrics, and their effect can be observed. Here, it is important to consider the effects of W and F because they help understand the performance parameters' trends. A higher number of F and W means bigger and complex Mininet topologies.

IX. PERFORMANCE RESULTS AND ANALYSIS
The emulated Mininet topology gets more complex with the complexity of the OXC's fabric topology and with the increase in the number of the wavelengths and fibers. We observed that more the fabric structure is complex, more the computational resources are required by our designed system. We therefore did an experimental analysis of some main computational resource factors, e.g., memory, CPU usage, and time required for creating the Mininet topology. For this analysis we chose "Clos" switch fabric topology as  an example.
Our system specifications are Intel Core i7-7600 CPU 2.80GHz 2.90GHz with 16GB installed memory. Figure 13 shows that the percentage of the idle CPU (mean values) decreases very quickly as soon as the topology starts getting created. As long as the topology is being created the CPU is utilized almost 100% and then comes back to become almost free. Smaller the number of F and W , quicker is the restored CPU usage, this is clearly because of less number of OpenFlow switches, links and hosts and thus less required processing. Same trend is followed when the topology is destroyed (not shown in the graph). Figure 14 shows the graph for maximum Resident Set Size (RSS) memory allocated for creating Mininet Clos topologies with various number of fibers and wavelengths. Increasing the number of fibers and wavelengths increase the number of switches, links, and hosts and thus more memory is  utilized. The graphs become steeper with higher values of W , since the number of links and switches increase as the square power of W , (see (1), (2), and (3)). Increasing the number of wavelengths in a sequence of one, increases the memory utilization by nearly more than 1.5MB for topologies with 3, 5, and 7 fibres, as seen in the graph. The memory utilization increases by 10.8% with increase in the number of fibers from 3 to 5, while the increase is 9.7% with increase in the number of fibers from 5 to 7, with the number of wavelengths equal to 8. However, this gain slightly increases with the number of wavelengths because of more memory required. Figure 15 shows the increase in the time required for creating a topology in Mininet, with the increase in the number of fibers and wavelengths. It can be seen that the graph becomes steeper with higher values of F and W , this is compliant with our equations, (1-3) and Figure 12, where the number VOLUME 4, 2016 of switches and links increase as a square power of W . We observed that there is no specific approximate time for the creation of topology and the creation time is highly dependent on the state of the machine on which experiments are being conducted. For every fresh startup of the machine, less time is taken for the topology creation than if the machine is already running other processes or when cache memory is full. For our experiments, the topology creation time increases by 96% when increasing fibers from 3 to 5, and by 43% when increasing fibers from 5 to 7, while the number of the wavelengths is 8.

D. LATENCY
The overall path setup delay depends on the delay in the links between OXCs, performance of the controller, time for translation of flows and configuration of optical switches. To measure the time required for the whole path setup process is difficult as it involves different systems; however, the most contributing and varying factor in the path setup delay is the path finding through the Mininet topology. Thus if we have an estimate of how much time is taken by the path finding process in the Mininet topology, then we can have a estimation of the overall path setup delay. In our model, RMS uses a spoofing mechanism to invoke path finding process which uses the 'Ping' command to find the path between the source and the destination hosts. Thus we measure the time taken by a successful 'Initial Ping' (Iping) [44], [45], by performing the Ping test between end hosts of the given network topologies for calculating round trip time (RTT) between hosts.  Figure 16 shows the Iping delays (mean values) between the end hosts for topologies with 5, 7, and 9 fibers. It is obvious from the graph that the latency has an increasing trend for bigger topologies; however, the increase is not smooth because of the high dependence on the state of the machine. For exact number of switches, links, and hosts in a topology, see equations (1)(2)(3). Standard error for bigger topologies is between 100-300 milliseconds approximately. Increase in the ping delay doubles when increasing the number of fibers from 5 to 7, and 7 to 9, for the number of wavelengths being equal to 8.

X. DISCUSSION
The graphs shown here are only for a single switch having Clos topology switch fabric. For any other topology, reanalysis will be required. Moreover, there may exist different types of switches within the optical network, so overall network connectivity will be the combination of all the switch fabrics and hence will be the combined required resources. Our results show compliance with the outcomes and discussions in some other performance analysis works, e.g., [44], [46], [47]. Figure 15 shows some large error bars especially for higher values of wavelengths, this is mainly because the speed of experiments depend on the background processes running at the same time. This is an unavoidable situation in our case as the processor has to continue its back-end processes for its normal operation. Thus in cases, where automation of the process depends on the time of topology creation (as in our case), no certain time can be assumed and there is need of an alert system to tell that the topology creation is done, and the system is ready for the next "path finding" step.
Dynamically establishing paths using SDN, seems to take time; however, considering core transport networks, the incoming requests do not arrive very often, and also once the path is established, it remains for longer times, e.g., months or years [48]. Although, there will be an initial loss of data until the path is found and established, but this is worth of the flexibility of the dynamic resources allocation, and offers a range of other benefits of SDN, as discussed previously in Section III.

XI. CONCLUSION
A model for path establishment in WDM network is presented in this paper which provides a flexible and configurable SDN solution for dynamic circuit-switching in WDM devices in core optical networks. It gives an advantage over other path establishment approaches presented in the literature in terms of considering switching constraints. None of the designs considered the congestion inside a switch and hence the non-availability of the path. This design is an effort towards a dynamic on-demand SDN based path establishment in WDM network without enhancing controller or OF protocol. However, the model considers the optical switch to be able to extract the destination addresses from the incoming requests. The model has been tested with Cisco layer one switch, and its performance is evaluated in terms of CPU and memory utilization, topology creation time, and latency. It is found that with more complicated switch fabric's topology, more computational resources are required and also path establishment time increases. Gain in the memory utilization, topology creation time, and latency is 9.7%, 43%, and 100% respectively, when increasing the number of fibers from 5 to 7 and the number of wavelengths is set to 8.