Software Defined Optical Networks (SDON): proposed architecture and comparative analysis

Abstract

Background

Interface SDN network with Optical network to enhance the capability of current optical network capability to achieve high data rate support to fulfilled 5G and Internet of things (IoT) backbone capacity requirement.

Methods

We use the proposed SDON design architecture based on Software defined networking and do the performance analysis so that proposed work can provide the backbone for current 5G and IoT network to support high data rate support.

Results and conclusion

A comparative analysis of results obtained in two different designs one consisting of the DWDM system and the other consists of programmable optical switches (ROADM) merged in the packet switched domain of SDN. This paper proves how SDN leads to significant improvement in the performance of the existing optical or any other Ethernet network. The flexibility of the SDON network is send the packets to the particular destination address is transmitted while the other value is either dropped or sent to the SDN controller for rerouting through a new path where flow entry is fed to the switch later.

Background

Network service providers face a common problem regarding management of current networks that are made up of routers, switches and many middle boxes with complex protocols [1, 2]. Since the current networking, trends comprise of some demanding nodes like data centric nodes. These nodes require high speed and such demands are met when we merge the benefits of circuit switched networks with those of the packet switched networks. Since the existing networks demand high speed and in addition to it they also require error free delivery of packets. Optical networks provide high speed or we might say circuit switched networks because nothing can overpower the speed of light, while as error free delivery of packets is ensured by the packet switching. But merely switching to packet switching won’t make much difference, we also want our networks to be flexible, programmable, and adaptable because traffic patterns from these data centric nodes in the different networks are dynamic and hence we want our networks to adapt to such traffic demands. Thus, the current computing trends demand an evolution in the existing network and the network providers don’t want to change the network as a whole. We want the nodes to reroute the packet through a path that is idle when its conventional path would be congested, in order to have such benefits in our network we need our packet switched nodes to be controlled by an SDN controller. SDN is a paradigm that separates the control plane from the forwarding plane [3, 4] the SDN controller carries out leaving behind the job of forwarding only for the switches and the control part.

Thus if we combine the error free recovery of packets of packet switching with high speed of optical network or circuit switching and finally the programmability and flexibility of networks of SDN we can lead to a revolution in the field of networking as shown in Fig. 1 and this could be a huge step towards making our networks flexible, cost efficient and innovative. Since SDN has a global view of the network as a whole thus it can lead to better optimization of resources [5, 6]. In fact, since in SDN the control is centralized which has a better control compared to the distributed control in other existing networks. Thus, combining SDN with the optical networks would revolutionize the networking world by making them flexible and adaptable to the demanding nodes of current scenario. It also gives a provision to the users itself to be independent of network operators as they themselves can be innovative in designing their own network as they won’t have to change the infrastructure but only reprogram the network.

Fig. 1

General Software Defined Optical Networking architecture

Contributions

In the field of Software Defined Optical Networking (SDON), a testbed has been simulated in OptiSystem along with MATLAB co-simulation with OpenFlow switches represented by MATLAB components. The main aim was to design a system to incorporate both SDN and Optical networks so that both high speed and capacity ensured by Optical networks is accompanied by error free delivery of packets taken care by SDN (packet switched part) that makes the system programmable and hence adaptable to current computing trends. Therefore, a simulated design of SDON is shown in this paper accompanied by the comparative analysis of results obtained from SDON with that a simple optical network, in this case DWDM system. The results obtained clearly show how SDN improves the flexibility of system and hence lowers BER to as low as zero because we get the exact replica of input packets at the receiver side.

In this paper, the following section II contains the brief description of basics of SDN. It also presents different flow charts that show the operation of OpenFlow switches. In section, III a network design is proposed that has employed all the above-mentioned three domains and this model is implemented in the OptiSystem tool. The algorithms accompany the general architecture mentioned and flow chart the whole network employs during its operation. Section IV mentions various designs of optical networks and SDON in the simulation tool optisystem. The following section V mentions the respective results. In this section a comparative analysis is carried out between a simple optical network that comprises of the DWDM system and the network that has SDN controlling the packet switching part and optical part of the network. A comparison of BER and Quality factor is shown in this section and it is seen how SDN decreases the BER and how speed is increased by including SDN in optical networks. A detailed study of effect of SDN on the optical part of the network is analyzed based on input from the OpenFlow switch. Since in OptiSystem we can only design the optical part, the packet switched part is designed in the MATLAB and then co-simulated with the OptiSystem tool.

Methods

Software-defined networking (SDN) has gained a lot of attention in recent years, because it addresses the lack of programmability in existing networking architectures and enables easier and faster network innovation [7,8,9]. The conventional communication systems comprises of switches, routers, and middle boxes. These networks have the capability to forward the packets and in addition to it they have the controlling ability embedded in them. Software Defined Networks (SDN) are different from these conventional networks in a way that SDN is the paradigm for separating the forwarding plane of networking from the control plane. This advancement in the field of networking has helped to make our networks flexible, adaptable to current computing trends. SDN has the centralized control plane that has a broader view or we can say a global view over the whole networks and it is well aware of the busy and free nodes or paths in the network. Having this global view of the existing network and having the ability to update the routing tables of the switches the controller of Software Define Network can make the packets to take the path that might be idle since a long time. Hence, it can lead to better optimization of resources.

We have a three-layer software defined architecture shown in Fig. 2 in which the three respective layers are application layer, control layer, and infrastructure layer. In addition to these three layers, it also consists of two types of interfaces [7,8,9,10] i.e. southbound interface and northbound interface. The southbound interface is between the infrastructure layer and the control layer whereas the northbound interface exists between the application layer and the control layer. The underlying protocol responsible for communication between the control layer or control plane and the infrastructure layer or data plane is known as OpenFlow.

Fig. 2

Three layer SDN architecture

Software Defined Networking being based on the protocol known as OpenFlow. In fact, the switches used in the SDN are also different from the conventional switches and are termed as OpenFlow switches. We may discuss the underlying protocol and its respective switches in the following subsections.

OpenFlow protocol

OpenFlow protocol is just an option among various programmable protocols for controlling purpose in SDN [11,12,13,14], but it has proved to be the dominant one. As OpenFlow is currently in its evolving stage and many versions of its specification exist like OF 1, OF 1.1, OF 1.2, and OF 1.3; with newer releases proving to be more powerful as compared to previous versions, as their features set support IPv6, Multiprotocol Label Switching (MPLS), rerouting, metering, policing and more scalable control. The OpenFlow protocol architecture consists of three basic concepts. (1) The network is made up of OpenFlow switches that compose the forwarding plane or the data plane; (2) the control plane consists of one or more OpenFlow controllers such as NOX, POX etc.; and (3) a secure control channel, which connects the OpenFlow switches with the controller or control plane.

OpenFlow switches

An OpenFlow switch is a basic forwarding device that forwards the packets according to its flow table [15,16,17,18,19]. This table in the switch holds a set of flow table entries, each of which consists of match fields, counters and instructions.

The incoming packets search for the entry in the flow table against which the header of the packet is matched and if the flow entry exists, the switch forwards the packet according to the action given in the flow entry as is shown in the flow table below in Fig. 3.

Fig. 3

Matching of packet header

If the flow entry of the incoming packet is not present that is if the packet header is not matched with the matching field then it searches for the table miss entry. It is explained well in the below shown Fig. 4, that if the table miss entry is present then either the packet is forwarded to next flow table or it is passed to controller or in fact it drops the packet if all other flow tables are checked for.

Fig. 4

Table Miss flow table

After checking for the table miss flow entry the three decisions take on the basis of action part (instructions) of the flow entry leads to further forwarding of packets. Now, if the packet is forwarded controller it has to set up a new path and hence the flow table needs to be updated. Thus when the flow table is updated that is when a new flow entry is introduced in the table the counter is set which calculates the time for which the flow entry exists in the table and after those seconds the flow entry is automatically discarded.

SDN and optical networks

Optical networks are composed of any switch with optical interfaces in order to perform circuit switching. It is strictly confined to the optical layer: e.g. wavelength division multiplexing (WDM) equipment, further confining to DWDM for high speed operations, reconfigurable optical add drop multiplexer (ROADM) acting as optical switches and the supporting optical link between them.

Optical networks as such are circuit switched networks and enable faster delivery of packets to destination port. Thus in order to meet the current trends and applications we need to make our networks fast as well a flexible and adaptable to changing demands of users. This demand would be fulfilled if we will merge the benefits of SDN and optical networks by making the existing optical networks programmable and thus flexible enough to meet changing needs of users. Many ways have been proposed, employing which we can design an efficient optical network, which can be controlled by an SDN controller to make it flexible and programmable. Some efficient optical networks that can be implemented to include SDN are: (1) Generic packet/TDM/fibre switching, (2) CDC ROADM based network, (3) Sub-wavelength switched network (broadcast network with tunable receiver), (4) Sub- wavelength switched network (tunable transmitter based optical burst switch).

Proposed architecture of SDON

The architecture of an SDON [7, 8, 20,21,22,23] is depicted by Fig. 5. It consists of two clients A and B between which the communication is to be held. These clients are connected to the openflow switches, which in turn are controlled by the SDN controller, and by itself it just performs the forwarding part of communication only.

Fig. 5

Proposed general architecture of SDON

The optical part of the architecture as can be seen in the figure consists of ROADM switches but we can also use COADM switches, in case we have lesser number of wavelengths to dropped or added. The communication between the openflow switches and the ROADM switches is through an electrical to optical converter. Since both the optical as well packet switches are controlled by the SDN controller, for packet switches we don’t require an interface but for optical switches we do require an interface to translate the electrical messages from the SDN controller to the optical signals to control the optical switches (ROADM). It’s been called as the openflow optical agent which can also be programmed in Matlab as we will program SDN controller in Matlab and then interface with rest of the optical part. The interaction between the controller and the agent or openflow switch is based on the openflow protocol. We can simulate this architecture of SDON in different tools. But the tool I have worked on to implement it is OptiSystem and different Matlab interfaced components like openflow optical agent and SDN controller managing the control part of the communication network.

Algorithms and flowcharts

Algorithms based on which the incoming packets are forwarded in the above mentioned general architecture of the Software Defined Optical Network (SDON) are mentioned below in a step wise manner starting with matching the header field of the packet and finally moving towards the dropping of packets that is decided by the OpenFlow switch based on the fed instructions.

A complete flowchart of the passage and steps that a packet follows while traversing from the client A to client B. The flowchart in Fig. 6 gives a complete scenario of how the packet moves through different stages in the packet switched path followed by the circuit switched path and again ending on the packet switched path on the destination side. It gives a clear picture as we can see that first the packet that arrives from the source client enters the OpenFlow switch and in there the header field of the incoming packet is matched against the match field of the flow table entry. If the match field of flow entry matches the header field of the packet then the packet is forwarded in accordance to the action mention in the flow entry itself. If the match is not performed then the search is carried on in finding the table miss entry. If the table miss entry is found then either of the three conditions is followed [4] i.e., (1) packet dropped (2) packet sent to controller (2) Action performed in accordance to the instructions mentioned. Along with this matching and table miss entry search we also need keep the track of counters of how long the flow entry should persist in the flow table. This is performed in a similar way as was done in the basic SDN itself. In addition to it, after the packets have been matched or not we need to take care of forming a new flow entry if the packet is sent to controller. The new path is set after the controller has a global view of the network which is ensured by the SDN controller as it is centrally located. The new path is based on the knowledge that the controller has of the network as a whole. The controller keeps track of resources that are idle and the routes that are not in use yet and hence makes a new path and hence a new flow entry that is later updated in the flow table and hence implemented for messages that have the same matching field.

Fig. 6

A stepwise flowchart of packets following in the general architecture of SDON

Simulation models

DWDM layout

A simple DWDM network is designed to ensure high capacity and high speed due to optical signals involved. The layout of a simple 4-channel or 16-channel DWDM network consists of the following components shown in the figure below. The only difference of DWDM network from the basic WDM network is to ensure dense wavelengths and decrease the frequency spacing. As shown in Fig. 7 the layout of DWDM network consists of a WDM transmitter followed by WDM multiplexer which feeds the signal to a loop control and the it is forwarded to Single Mode Fiber (SMF) which is amplified by an EDFA and then the dispersion needs to be compensated and hence it is passed through Dispersion Compensation Fiber (DCF). The signal after passing through a second EDFA is fed again to the loop control to complete the loop count for which the design is set. Thus after completing the respective loops of loop control, signal is demultiplexed and received by an optical receiver.

Fig. 7

DWDM layout in OptiSystem

ROADM layout

The above-mentioned general architecture of SDON has been simulated in the latest version of a very advanced tool called OptiSystem. As is shown in the Fig. 7 below, in or der to design a simple ROADM switch [7,8,9,10, 18,19,20,21,22,23] the most important consideration is to design banyan architecture switch which consists of optical switches in the crisscross manner as depicted in the figure itself.

This part of the ROADM is necessary and important as this ensures the wavelength selective switching (WSS) which is the underlying principle of ROADM. The source transmits an array of signals which are passed through the WDM multiplexer which on moving further is passed through the amplifier specifically SOA. After passing the signals through a common amplifier the signals are split and individually passed through a Bessel filter followed by an optical delay in each path. Then these waves are fed to this banyan architecture switch which performs the wavelength selective switching. And finally at the output we select one of the waves transmitted and hence it acts as a ROADM switch. On simulating this layout it was seen that how we get a different wavelength at the output when we change the respective bits in the control part of the optical switches.

The expression that allows the selection of the output wavelength from among four input wavelengths in this case, according to the physical parameters and structure of the device, is:

$$ \lambda \sim \frac{x}{f}\frac{1}{\left(\frac{n}{ND}+\frac{2}{\left(\raisebox{1ex}{$M$}\!\left/ \!\raisebox{-1ex}{$2$}\right.\right)d}\right)} $$

where x is the distance from the optical axis to the output fibre, f is the focal distance of the lens, d is the spatial period of the fixed diffraction grating and M has into account the number of phases.

Once the Spatial Light Modulator has been chosen, the focal distance of the lens, f, to illuminate with the collimated light the complete active surface ND × ND of the SLM, is related with the number of pixels N and its size D by the expression:

$$ f=\pi {\phi}_{core}\frac{ND}{4{\lambda}_o} $$

where ϕ_core is the input fibre core diameter and λ_ο the central wavelength in the operation region. The 3 dB passband filter bandwidth of the holographic device, BW, is:

$$ BW\ge {\phi}_{core}\frac{\left(\raisebox{1ex}{$M$}\!\left/ \!\raisebox{-1ex}{$2$}\right.\right)d}{f}{\left(1-\frac{{\lambda_o}^2}{{\left[\left(\raisebox{1ex}{$M$}\!\left/ \!\raisebox{-1ex}{$2$}\right.\right)d\right]}^2}\right)}^{\raisebox{1ex}{$3$}\!\left/ \!\raisebox{-1ex}{$2$}\right.} $$

if the condition 8D ≫ D is reached, where d is the fixed grating spatial period.

In case of a Bessel filter, the BW (filter -3 dB bandwidth) and out-band attenuation are reached by the increment of the filter order or the variation of the polynomial coefficients. For a Gauss filter these values are obtained, directly, by the change of the standard deviation = BW:

$$ H{f}_{Gauss}=\frac{1}{\sqrt{2\pi } BW}{e}^{\frac{{\left(\lambda -{\lambda}_o\right)}^2}{2{BW}^2}} $$

with λ_ο-2BW< λ < λ_ο +2BW, and

$$ H{f}_{Bessel}=\frac{1}{{\left(\lambda -{\lambda}_o\right)}^2+3\left(\lambda -{\lambda}_o\right)+3} $$

SDON layout

In order to implement the above-discussed proposed general architecture of SDON we have used ROADM switches to consist as the optical switches, which can further be programmed by the SDN controller in order to get hold of the flexibility of the network as whole. Since the packet SDN controller can control switched part easily by importing the new route into the switch but when this SDN is merged with the optical domain we need only those optical switches that can be programmed and hence this purpose is served by ROADM very well. As can be seen in the layout shown in Fig. 8 below that for designing the packet switched part of SDON we needed to design the OpenFlow switch in MATLAB which consists of generating the packets and then followed by the flow table against which the packets are matched and hence further traversed.

Fig. 8

ROADM layout in OptiSystem

The SDN controller in the layout above consists of the MATLAB component, which generates different sequences of bits that acts as the control part for ideal optical switches in the banyan architecture switch of ROADM. These bit sequences if kept in a separate subsystem would constitute a controller of ROADM as a whole. If this SDN controller gets an input packet from the OpenFlow switch then the controller, which would be a MATLAB component in OptiSystem, would take a global view of the network and would look for the possible routes this incoming packet could take and hence would form a new path for this particular packet and this path would be updated in a new flow entry which would be later updated in the existing flow table present in the OpenFlow switch. Hence, when any other packet with a similar header field arrives the input of OpenFlow switch would be routed according to this new flow entry fed from the controller.

Simulation parameters

The following table gives precise value of parameters used in the above-mentioned layouts of OptiSystem Table 1. Table 2 gives the distinct values used in MATLAB components as well as those of optical components.

Table 1 Optical Part

Table 2 SDN Part

Stages of simulating SDON (Fig. 9)

The stages that lead to the development of a full-fledged SDO network are briefly discussed in this section. Firstly, a system was developed that could generate a bit sequence in a MATLAB component which was used to generate an NRZ sequence which was later modulated by a DM laser and proceeds in a normal manner as any other optical signal would propagate till the receiver end. In the next stage, this system was enhanced by generating the header and payload of a full packet of data that is used in any Ethernet network. From the MATLAB component, the generated packet frame is fed to NRZ generator, which is modulated and sent over an optical fiber or switched through the ROADM switches to add flexibility. In the last and final stage a complete SDON was developed in which a flow table was introduced on the basis of which the switch could make the decision on whether the respective packet should be forwarded or sent to the controller or should be dropped. In addition to the introduction of flow table, ROADM was also added in the design, which was controlled by the SDN controller in which the separate controlling user defined sequences were kept. Therefore, in this design the decision of forwarding the packet was done based on OpenFlow switch’s flow table entries. Then this packet traversing the ROADM switches is headed towards the receiver end where again the MATLAB component is used to convert this optical signal which was received as the electrical signal, into the bit sequence which would constitute the frame of packet sent at the transmitter end.

Fig. 9

Software Defined Optical Network layout in OptiSystem

Results and analysis

Simple DWDM network

The received signal of the DWDM network when analyzed under the BER analyzer shows better results when compared to other optical networks. Because the higher capacity and speed is ensured by the DWDM networks in comparison to other networks. In fact, the bit error rate and quality factor are also much better.

Different wavelengths at the ROADM output (Figs. 10 and 11)

When the above-mentioned layout of ROADM shown in Fig. 7 is simulated in OptiSystem we get four different wavelengths at the output when we change the bit sequence fed from a user defined sequence which acts as the controller for an ideal optical switch. Table 3 shows the combination of different bit sequences that result in different wavelength at the output of the ROADM. The bit sequences or in this case the user defined sequences controlling the ideal switches can be replaced by a MATLAB component which would give the respective sequence of bits to the switches to transmits a particular wavelength and drop the other. As we can see in the table below that, we just need to give a particular sequence of bits to the banyan architecture switch and not the y-select switch that selects any of the wavelengths.

Fig. 10

Different wavelengths at the output of ROADM

Table 3 Control bit sequence for banyan architecture switch

Fig. 11

Power level difference for two different DA addresses

Comparative analysis of received signal between DWDM and SDON

A comparison of received signal in two cases, i.e. (1) DWDM network and (2) SDON network, is carried out and the results are seen to vary drastically. When the simple optical network in this case DWDM network is compared to a network in which SDN is included, we see that BER is lowered to as low as zero as we get the exact replica of the packets sent from the transmitter end. However, in practical optical networks we see that dispersion and other attenuating factors play a vital role and may lead to intersymbol interference and hence would lead to lower but still some amount of BER, which is seen in the Fig. 12 below.

Fig. 12

Comparison of BER and Q-Factor between optical network (DWDM) and Software Defined Optical Network (SDON)

The Q-factor as seen in the figure below in case of DWDM is 5.8 but for SDON we can see that the increase of Q-factor to 1.5exp (047) is quite huge and this is ensured by the merging of packet switching in the optical infrastructure. While as decrease in BER of 2.9exp (− 009) in case of DWDM to 0(zero) in case of SDON is also quite significant and hence leads to the requirement of SDON in place of current optical networks as it would serve various needs of the users.

For this reason an experiment was carried out as to see how the network reacts if a packet is sent whose header or in this case the Destination Address (DA) does not match any of the match field of any flow entry. We can see in Fig. 13, a clear distinction as to when the destination address is BBBBBBBBBB, from the condition when the destination address is changed to BBBBBBBB00. Since in that case this packet should be sent to controller and a net path should be set. But since the controller is not yet programmed to set a net path in this test-bed therefore we can see that this packet won’t be transmitted further.

Fig. 13

Different packet frames for different DA. (a) Input packet frame (b) Output packet frame for DA = BBBBBBBBBBBB (c) Output packet frame for DA = BBBBBBBBBB00

Conclusion

After carrying on the simulations of an optical network specifically a DWDM network and in comparison to it the SDON network proved design that is more efficient and led to making the networks flexible and programmable. The BER and Q-factor obtained from the SDON were far better than obtained in case of just an optical network. The flexibility of the SDON network was proved when the network was able to transmit a particular packet of data, which contained a specific destination address that would match the match field of flow entry. While as, the packet with some other destination address, which does not match the match field of flow, entry either is dropped or lead towards the SDN controller, which in turn has a global view of the network and hence is able to reprogram the network according to the demands. Thus, this paper gives a clear distinction between the SDON and an optical network consisting of DWDM networks, and proves as to how SDN leads to adaptability of network to current computing trends.

Appendix

Co-Simulation of MATLAB and OptiSystem

In OptiSystem, all the available components sometimes prove to be insufficient for the requirements of the new design that could meet the current computing trends. Thus, we want to design such components in some other tool and then co-simulate with our base tool like OptiSystem. Now the best possible tool available to us in which we can design any type of component and ensure anything required in our design is MATLAB. Thus, we do have a MATLAB component present in OptiSystem version 13 or 14.In order to co-simulate a MATLAB file with the rest of the OptiSystem design we need to follow below mentioned steps:

❖ STEP 1: In the Default, section of OptiSystem library there is a subsection named External Software Library wherein we can find the MATLAB Component.

❖ STEP 2: Import the respective MATLAB component at a place where you need to have the component as per your requirements.

❖ STEP 3: Write the MATLAB code separately in the MATLAB tool and store it at some specific location in your PC.

❖ STEP 4: Double click on the MATLAB component of OptiSystem and there you will find a section named Path wherein you need to provide the complete path of the .m file, which you have already stored at some specific location in PC.

❖ STEP 5: after providing the path of .m file another section named Run Command is seen, where the name of the respective .m file is written followed by .m.

❖ STEP 6: The last and final step is to check the Load section in the properties block of MATLAB component, which would load the .m file and then you run your design and automatically the MATLAB component would be co-simulated with your OptiSystem design.