Design and performance evaluation of an OpenFlow-based control plane for software-defined elastic optical networks with direct-detection optical OFDM (DDO-OFDM) transmission

: Optical Orthogonal Frequency Division Multiplexing (O-OFDM), which transmits high speed optical signals using multiple spectrally overlapped lower-speed subcarriers, is a promising candidate for supporting future elastic optical networks. In contrast to previous works which focus on Coherent Optical OFDM (CO-OFDM), in this paper, we consider the direct-detection optical OFDM (DDO-OFDM) as the transport technique, which leads to simpler hardware and software realizations, potentially offering a low-cost solution for elastic optical networks, especially in metro networks, and short or medium distance core networks. Based on this network scenario, we design and deploy a software-defined networking (SDN) control plane enabled by extending OpenFlow, detailing the network architecture, the routing and spectrum assignment algorithm, OpenFlow protocol extensions and the experimental validation. To the best of our knowledge, it is the first time that an OpenFlow-based control plane is reported and its performance is quantitatively measured in an elastic optical network with DDO-OFDM transmission.


Introduction
An elastic optical network, which is able to dynamically and adaptively allocate the necessary optical spectrum according to the traffic demand, the selected modulation format and path conditions (e.g., physical length or optical impairments), has been proposed to efficiently utilize network spectrum resources [1].In an elastic optical network, the optical spectrum is partitioned into basic fixed-size spectrum slots or slices (e.g., 6.25 GHz or 12.5 GHz) and spectrum ranges are adaptively allocated to bandwidth-variable optical connections.Thus, an elastic optical network can provide diverse services directly at the optical layer in a spectrumefficient way [2].For intelligent end-to-end connection provisioning and dynamic route computation (known as routing and spectrum assignment (RSA) [3]), a control plane is a key enabling technique.
To date, two different control plane solutions have been proposed and experimentally demonstrated for an elastic optical network [4].The first one is based on the distributed Generalized Multi-Protocol Label Switching (GMPLS) architecture and its associated protocols [5][6][7].The second solution is based on Software-Defined Networking (SDN), in particular, the OpenFlow [8] architecture, which uses a centralized controller (e.g.NOX [9]) to perform both RSA computation and path provisioning.Compared with GMPLS, the OpenFlow provides flexibility for the operators to control a network given its open interfaces and the open nature of its source code, in contrast to the fact that GMPLS is usually deployed in closed systems [10][11][12].
The first extended OpenFlow-based control plane for an elastic optical network has been presented in [13], focusing on the protocol extensions and overall feasibility validation.Further studies regarding software-defined elastic optical networks have investigated the control of flexible transmitters [14], integration with Path Computation Elements (PCE) [15], interoperability with optical performance monitors [16], inter-datacenter connections [17], and field trial demonstration [18].Despite massive progress, it should be noted that all the previous works only considered single-carrier transmission schemes [13,14,[16][17][18], or coherent optical orthogonal frequency division multiplexing (CO-OFDM) transmission [15].It is well known that the optical OFDM system can be mainly categorized as coherent and incoherent (direct-detected) systems [19].Compared with the direct-detection optical OFDM (DDO-OFDM) systems, CO-OFDM improves performance in spectral efficiency, receiver sensitivity, and robustness against polarization dispersion, but it requires higher complexity in transceiver design [19,20].The superior performance of CO-OFDM enables it an excellent candidate for long-haul transmission [19,20].On the other hand, the advantage of DDO-OFDM is its relatively low cost and simple implementation in both hardware and software realizations [19,20].Although recent experiments demonstrated that DDO-OFDM can support super-channel (>100 Gb/s) transmission for several hundreds of kilometers [21 ,22], it is generally agreed that DDO-OFDM is much more suitable for metro networks where cost is primary concern [19,20].In light of this, in this paper, we consider an elastic optical network with DDO-OFDM transmission as the network scenario, and then we design and deploy an OpenFlow-based control plane on top of it, assessing its overall feasibility and quantitatively evaluating its performance.To the best of our knowledge, the performance of OpenFlowcontrolled elastic optical networks by using DDO-OFDM transmission has not been investigated yet.
The rest of this paper is organized as follows: Section 2 presents the network architecture.Section 3 introduces the OpenFlow protocol extensions and Section 4 details the two-phase RSA algorithm.Section 5 presents the experimental setup, results and discussions.We conclude in Section 6 by summarizing our contributions.

Network architecture
Figure 1 illustrates a network architecture for an OpenFlow-controlled elastic optical network with DDO-OFDM transmission.The optical layer is provisioned with Bandwidth-Variable Wavelength Cross-Connects (BV-WXCs), which are implemented by using Bandwidth-Variable Wavelength Selective Switches (BV-WSS) [1].DDO-OFDM transmitters (Tx) and receivers (Rx), which are supported by advanced digital signal processing, are connected to ingress and egress BV-WXCs respectively, as shown in Fig. 2(a) and Fig. 2(b) respectively.At the Tx, the random binary bits are firstly mapped to the pre-defined Quadrature Amplitude Modulation (QAM) symbols (e.g. 4, 16, or 64QAM), and, along with an radio frequency (RF) pilot tone [23], converted to time domain using a 128-point Inverse Fast Fourier Transform (IFFT).A cyclic prefix with a length of ~(1/16 x symbol duration) is added at the head of each OFDM symbol to prevent the inter-symbol interference (ISI).After that, 4x oversampling is performed to model the output analog signals to increase the reliability of the results.The generated signal is used to drive a linear IQ modulator fed by a zero-linewidth laser.The output of the modulator is sent to the network.At the Rx, a square-law photodiode is used to down-convert the received signals to the electrical baseband.After down-sampling (by ADC), signal processing such as cyclic prefix removal, FFT, channel estimation and equalization, QAM de-mapping are performed to recover the transmitted signals.The Bit Error Rate (BER) is obtained directly by comparing the transmitted and recovered bits (directcounting method).All the network elements (NEs) are controlled by OpenFlow agents, and are referred to as OpenFlow-enabled Tx, Rx, and BV-WXC (OF-Tx, OF-Rx, and OF-BV-WXC for short) respectively.A centralized NOX controller is introduced to control all the NEs through the extended OpenFlow protocol as detailed below.

OpenFlow protocol extensions
Figure 1 depicts the procedure for dynamic elastic path provisioning by using an OpenFlowbased control plane.According to the OpenFlow methodology, the path provisioning is triggered by a Packet In message as shown in the step 1 in Fig. 1.Here, we assume that the Packet In message is sent from an operator via a network management system (NMS), and we extend the Packet In message to carry the bit rate information of the incoming client (e.g.IP) traffic.This requires the operator/NMS can detect or monitor the bit rate of the incoming flow, and the approach for this detection is beyond the scope of this paper.According to the source/destination and bit rate of the flow, the NOX performs a two-phase RSA algorithm (as detailed in Section 4), allocating suitable frequency slots and modulation format, and then controls corresponding OF-Tx, OF-Rx and OF-BV-WXCs to create a path with appropriate optical spectrum range through extended OpenFlow Flow Mod messages, as shown in the step 2-5 in Fig. 1.The extended Flow Mod message carries the RSA results from the NOX, including input/output ports, central frequency, slot width, and modulation format, etc. for each OpenFlow agent to control the underlying hardware.Although, macroscopically, the architectural aspects of a control plane for DDO-OFDM and CO-OFDM may be the same, and specific components such as topology management are common, from the control plane point of view, the major difference of the DDO-OFDM from CO-OFDM is the controller aspects in terms of route selection and algorithm design.In other words, algorithms are designed with the constraints associated to DDO-OFDM, and all protocol extensions that are related to the dynamic programming of transceivers need to take into account the potential modulation formats.As a tradeoff of its simple transceivers and low cost, the long haul transmission performance of DDO-OFDM is worse than that of CO-OFDM.In general, the DDO-OFDM signals can only transmit shorter distance and fewer nodes compared with CO-OFDM.Therefore, the control plane is required to take this transmission limitation into consideration for the route selection, and this design will impact the overall network performance (e.g.blocking probability), as detailed next.Finally, it should be noted that the transceiver model of CO-OFDM and DDO-OFDM may also be different and the way of programming it (e.g. the hardware abstraction layer) could also be extended for advanced functionalities, and this part will be addressed in our future works.

Two-phase RSA computation
Considering potential scalability issues in the centralized OpenFlow architecture, as well as the fact that fully dynamic RSA computation is complex and is likely to be CPU-intensive, in this work, we implement a two-phase RSA algorithm in the NOX. Figure 3 shows the diagram of this algorithm.In the first phase for off-line network planning, the K-shortest paths for each source-destination pair are calculated, which are then classified according to their distance (in km) and hop count.After that, pre-computed tables comprise the bit error rate (BER) values and optical spectrum width (in GHz) information for given net data rates, modulation formats, path distances and hop counts are generated, which are the results of the simulation of DDO-OFDM transmission which emulates the possible paths while varying their length and the number of hops, net bit rates, and modulation formats.In the second phase for dynamic path selection and resource assignment when a Packet In message is received, the NOX performs a lookup for pre-computed static planning tables and then obtains the feasible combinations of the data rate, the modulation format, required optical spectrum and the number of sub-carrier according to the traffic engineering database.If different combinations are possible, the criterion is to minimize the resulting optical spectrum.

Experimental setup, results and discussion
To evaluate the overall feasibility and efficiency of the proposed solutions, we set up a real OpenFlow control plane testbed as shown in Fig. 4, which models the Japanese core network topology.We have implemented and evaluated the proposed algorithm and protocol extensions using this testbed.It is composed of 14  is the transmission distance, and c is the light speed in vacuum.The fiber input power is 0dbm.We use K = 3 for the K-shortest paths algorithm, restricted to a maximum number of 5 hops.For longer paths which are not considered during the off-line planning phase, the most robust modulation format is assigned.For each link, the maximum span length is limited to 80 km.Each span contains an erbium doped fiber amplifier (EDFA) compensating exactly the loss of each span with a fixed noise figure of 6 dB.The noise is loaded with a power spectral density of ( ) 0( 1) where h is the Plank constant, v0 is the optical frequency, G is the gain of EDFA of each span (a function of span), and NF is the EDFA noise figure.Each ROADM is modeled as a 4th-order Gaussian-shaped filter with a −3dB-bandwidth of ~1.5 times of the signal bandwidth.The frequency response of this optical filter is given by 2 0 ( ) exp( 0.5 (( where 0 f is the filter's center frequency, m is the filter order, and BW is the designed bandwidth.The target BER is at ~3.8E-3 which is the threshold of the hard-decision forward error correction code (HD-FEC) [23].Different QAM formats, such as 4-, 16-and 64, and diverse data rates including 10, 40, and 100 Gb/s are discussed.Note that in this work, we only considered 4QAM, 16QAM and 64QAM.But the demonstrated control plane can be extended to operate with any other modulation formats.In this case, the controller should be extended to take other modulation formats into account for routing and spectrum assignment.The offline network planning is needed to include the newly introduced modulation formats during the characterization of physical paths, and dynamic path selection needs to take into account the properties of other modulation formats.The Flow Mod message, in particular, the "modulation format" field should be extended to carry additional information to represent the newly introduced modulation formats.Finally, the OpenFlow agent should be extended to interpret the Flow Mod message, and control the underlying Tx/Rx with the assigned modulation formats.This also affects the characterization of paths in terms of suitable candidates for dynamic path selection.Figures 5, 6, and 7 show the off-line network planning results.BER at the Rx side for different distances and hop count corresponding to different modulation formats (4QAM, 16QAM, 64QAM) at 10Gb/s, 40Gb/s, and 100Gb/s DDO-OFDM transmissions are measured, as shown in Figs.5-7 respectively.We use Matlab to simulate the system with a linear device/transmission assumption.Our own Matlab code is designed to simulate the DDO-OFDM signal transmission, as the details mentioned above.Table 1 shows the signal bandwidth and required spectrum slots for DDO-OFDM with different modulation formats.As expected, the 64QAM constellation gives the best performance in terms of spectral efficiency, whereas the 4QAM constellation is more robust to physical impairments.It can be observed that all the 4QAM cases are below the target BER threshold, whereas when using 16 QAM at 100Gb/s, 64 QAM at 40Gb/s, and 64 QAM at 100Gb/s, the attainable distance is limited.These results are stored in the pre-computed static planning table in the NOX.In this work, we adopt a realistic network scenario which models the Japan core network topology with 14 nodes.According to our results, the static network planning table contains 576 entries of BER values for given data rates, modulation formats, path distances and hops.The factors which will impact on the size of the static planning table include the number of modulation formats, the number of flow bits rates, the network size (i.e.number of nodes), and the K value of the K-shortest path algorithm.In this work, we considered 3 different modulation formats (4, 16 and 64QAM), 3 different bit rates (10, 40, and 100Gbps), a medium network with 14 nodes, and K = 3.If more modulation formats, more flow bit rates, a larger K value, and a larger scale network are considered, the size of the static network planning table will be increased accordingly.But it should be noted the fact that the DDO-OFDM transmission is usually applied to a small or medium network, therefore the static planning table will not be very big, and it should not be a bottleneck of the whole system in terms of network scalability especially when the modern database technique (e.g.memory resident database) is deployed.When an extended Packet In message is received, the NOX performs a lookup for the precomputed static planning table and then performs dynamic path selection and resource assignment for the incoming requests.The Wireshark, which is a packet analyzing software that monitors network traffic and displays operating system-based time-stamped packets, is used to capture the control plane messages and measure the path setup and release latencies.The Wireshark capture of an extended Packet In message in Fig. 8 shows that the flow bit rate information is encapsulated in this message.After the two-phase RSA is successfully carried out, the NOX controls the Tx, Rx and WXCs through the extended Flow Mod messages, as the Wireshark capture shown in Fig. 9.It can be seen that the input/output ports, central frequency, number of spectral slots, modulation format and number of sub-carriers are included in the extended Flow Mod message for the OpenFlow agents to control the underlying hardware.We also measure the overall path setup and release latencies for connections with different hops, as depicted in Fig. 10 repeating the experiments for more than 100 times.It can be seen that, by using the proposed solution, the OpenFlow-based control plane can set up and release lightpaths within ~36ms and ~17ms respectively.Note that this amount does not take into account hardware configuration delay.In addition, the OpenFlow protocol may evolve and is being standardized for transport networks, so it may be required that the OpenFlow agent sends an acknowledgment message after the cross-connection is established, increasing the overall setup delay.Moreover, in this work, the cross-connects are programmed in a serial manner, which causes the setup delay to grow slightly linear.The OpenFlow controller could parallelize the commands for a reduced setup delay at the expenses of a more complex implementation [15].The hardware configuration latency is mainly based on vendor's product.In general, it is very dependent on the actual hardware vendor and the required procedures to ensure a correct transmission (e.g.power equalization).A very basic setup can indeed add several tens of milliseconds and the overall setup latency depends on whether the connection is set up in parallel or serialized (one hop at a time).In the former, the time will be determined by the slower hop and, in the later, the time will be the sum of all crossconnections.Production-level setup delays may require a total overall setup time of the order of seconds taking into account quality of transmission constraints.The blocking probability measurement by using the proposed solution is depicted in Fig. 11.Compared with our previous works on elastic optical networks with CO-OFDM transmission [15], we observed that the blocking probability in elastic optical networks with DDO-OFDM is relatively higher.It is because, as a tradeoff of its simple transceivers and low cost, the long haul transmission performance of DDO-OFDM is worse than that of CO-OFDM, which results in less feasible paths to route an incoming flow.These performance evaluation results validated the overall feasibility and efficiency of the OpenFlow-controlled elastic optical networks with DDO-OFDM transmission.In our future works, we will consider non-linear optical effects among multiple DDO-OFDM channels, and investigate how to include these non-linearity optical effects in an OpenFlow control plane.We believe that non-linearity optical effects will make the transmission performance of DDO-OFDM much worse, so how to use OpenFlow to optimize the routing and spectrum assignment for the incoming flow will be a key issue.Moreover, new OpenFlow messages and protocol extensions will be considered.For example, a new OpenFlow message can be introduced which can update and notify the cross-channel effects, and we will investigate how the algorithms can take into account the existence of connections for new request allocation.

Conclusion
In this paper, for the first time, we deploy and demonstrate an OpenFlow-based control plane, and quantitatively measure its performance for a software-defined elastic optical network using DDO-OFDM transmission.The overall feasibility of the proposed solutions, including the network and functional architectures, the two-phase RSA computation, as well as the OpenFlow protocol extensions, are experimentally validated and quantitatively evaluated in terms of path provisioning latencies and blocking probability on an OpenFlow testbed.The result of this study indicates practical deployment of SDN and elastic optical networks with simple DDO-OFDM transmission may be possible in the near future.

Fig. 1 .
Fig. 1.Network architecture and path provisioning procedures for OpenFlow-controlled elastic optical networks with DDO-OFDM transmission.

2 (
OpenFlow agents without associated optical hardware, which enable maximum flexibility in topology configuration.The OpenFlow agents are implemented in Linux-based PCs with Fedora 11 Operating System, Intel Core i5-3470 3.2 GHz CPU and 2 GB of memory.A dedicated OpenFlow controller (NOX) is deployed in a Linux PC with Ubuntu 10.04 Operating System, Intel Core i5-3470 3.2 GHz CPU and 8 GB of memory.A dedicated Ethernet network is deployed to allow connectivity from the OpenFlow agents located at each node and the OpenFlow controller.Note that although the optical hardware is emulated, a complete control plane implementation (i.e.control protocol stack) is used, and not simulation.The message propagation latencies from the NOX to each OpenFlow agents are assumed, which are indicated in Fig. 4 (i.e., the time value close to each node).The OpenFlow agent is developed based on OpenFlow protocol v1.0, and the controller is developed based on the NOX-Classic version.Connection arrivals follow a Poisson process, with requests randomly select between distinct node pairs, and the connection holding time follows the exponential distribution.The DWDM links are characterized by 128 individual slots of 6.25 GHz each.For the off-line planning for static paths characterization, linear standard single mode fiber (SSMF) links have been assumed, featuring an attenuation of 0.2 dB/km and a chromatic dispersion coefficient of D = 16 ps/nm•km.The chromatic dispersion distorts the signal with a frequency response of 2 the baseband frequency, λ is the optical wavelength, L

Fig. 5 .
Fig. 5. BER performance at the Rx for different distances and hop count corresponding to different modulation formats (4QAM, 16QAM, 64QAM) at 10Gb/s.

Fig. 6 .
Fig. 6.BER performance at the Rx for different distances and hop count corresponding to different modulation formats (4QAM, 16QAM, 64QAM) at 40Gb/s.

Fig. 7 .
Fig. 7. BER performance at the Rx for different distances and hop count corresponding to different modulation formats (4QAM, 16QAM, 64QAM) at 100Gb/s.