Expand this Topic clickable element to expand a topic
Skip to content
Optica Publishing Group

Experimental demonstration of OpenFlow-based control plane for elastic lightpath provisioning in Flexi-Grid optical networks

Open Access Open Access

Abstract

Due to the prominent performance on networking virtualization and programmability, OpenFlow is widely regarded as a promising control plane technology in packet-switched IP networks as well as wavelength-switched optical networks. For the purpose of applying software programmable feature to future optical networks, we propose an OpenFlow-based control plane in Flexi-Grid optical networks. Experimental results demonstrate its feasibility of dynamic lightpath establishment and adjustment via extended OpenFlow protocol. Wireshark captures of the signaling procedure are printed out. Additionally, the overall latency including signaling and hardware for lightpath setup and adjustment is also reported.

©2013 Optical Society of America

1. Introduction

In order to effectively support diversity applications with a variety of QoS, the future optical network is evolving into a cost-effective architecture that can dynamically and flexibly adapt to upper services. The widely used of technologies such as Dense Wavelength Division Multiplexing (DWDM) and Reconfigurable Optical Add-Drop Multiplexers (ROADMs) have allowed service providers to increase the scale, flexibility, and reliability of optical networks. However, it is assumed that the current optical networks are still ossified or “semi-flexible”, having limitations to support new networking innovation technologies such as virtualization. Network virtualization, which is well known as a promising approach in the future network, have not yet been fully realized in optical network due to the rigid and fixed network architecture.

Recently, the Flexi-Grid optical networks based on Orthogonal Frequency Division Multiplexing (OFDM) technology have been given extensive attention [1], which enables optical networks from “rigid” to “flexible”. To the benefit of OFDM modulation, high performance of spectrum efficiency is achieved, as well as the multi-access technology in physical layer by carrying the different user data over different subcarriers [2]. Additionally, adaptive modulation coding and elastic spectrum allocation are also introduced to enable the network architecture to be more flexible [3]. The above features enable segmentation and partitioning of the network infrastructure at layer 1, which is key enabler for network virtualization. Besides focusing on the improvement of network architecture, some device developers expect to promote the programmability in terms of transmission system and equipment in OFDM-based Flexi-Grid optical network by using software-controlled Field Programmable Gate Arrays (FPGA) [4]. From the service provider point of view, it is more suitable for realizing network virtualization in Flexi-Grid optical networks than in Fixed-Grid WDM optical network. The networking resource elements such as spectrum size, modulation format and central frequency of tunable laser and filter can be “programmed” and “customized” to satisfy the diversity of users’ demand. That means a real “sliced” spectral resource can be provided through a given elastic lightpath according to each specific purpose.

This elastic optical network requires an intelligent physical layer control to meet the Spectrum-on-Demand (SoD) service, which poses a higher claim on the current control plane. Although GMPLS-based control plane [5] is a widely approved technology, it has some deficiencies due to the distributed nature, complex protocols and diffidence of service providers. Recently, Software Defined Network (SDN) and OpenFlow have become popular in optical networks [6, 7], which allow operators to control the packet and circuit switched networks by using a unified control plane. To the purpose of SDN/OpenFlow [8], the application can converse with and manipulate the networking resources from requesting the available resource in a specific way (e.g. OpenFlow protocol). It totally opens the variety of networking resources that enable services to use them intelligently and effectively. In additional, one controller with multi-switches architecture achieves good performance on lightpath provisioning latency compared with GMPLS-based control plane [9], but also brings higher requirement of processing ability for controller while networking topology and connection requests going large. The original motivation of SDN/OpenFlow which aims to develop a virtualized and programmable networking control meets the virtualization requirements of Flexi-Grid optical networks. Therefore, the combination of both technologies can achieve high performance on network, which has been becoming a hot topic in last two years [912]. In this paper, we present and experimentally demonstrate an OpenFlow-based control plane in Flexi-Grid optical networks. Dynamic lightpath establishment and adjustment are implemented in our control plane testbed. The Wireshark captures of signaling procedure are printed out. Additionally, the overall latency including signaling and hardware for lightpath setup and adjustment are also reported.

The rest of this paper is organized as follows. Section 2 proposes the enabling technologies of the OpenFlow-based Flexi-Grid optical networks. Section 3 presents OpenFlow-based elastic lightpath provisioning for time-varying traffic. Section 4 shows the experimental performance of our testbed. Section 5 concludes the whole paper by summarizing our contribution and discussing our future work on this area.

2. Enabling technologies of OpenFlow-based Flexi-Grid optical networks

The use of OpenFlow in packet-switched network has been widely studied in protocol as well as device. In this section, we focus on some new features of OpenFlow enabling technologies which are exploited in the Flexi-Grid optical networks. Firstly, the difference of OpenFlow between packet-switched networks and circuit-switched networks is briefly pointed out. After that, OpenFlow-based bandwidth variable optical switch and main protocol extensions for Flexi-Grid optical networks are presented in detail.

2.1 OpenFlow in circuit-switched optical networks

OpenFlow has originally been designed for packet-switched networks. In OpenFlow- based packet-switched networks, the first incoming packet will be encapsulated and sent to the controller. Controller returns a flow entry which is added into the flow table via Flow_mod message. The following packets (same flow) are forwarded directly by looking up the flow table of switch. Each switch which the packet passed will repeat the above processing one by one until the packet ends at the destination node. Compared with the packet-switched networks, there is a little difference in circuit-switched optical networks. Controller firstly calculates the path and reserves the resource along the path, and then sends flow entries to the corresponding switches simultaneously. Flow entry is just as a software command to trigger the action of switch. Once the lightpath is setup, it offers guaranteed performance to the transmitted data, since there is no packet processing and all data follow the same path.

2.2 OpenFlow-based bandwidth variable optical switch

To control the optical nodes with OpenFlow protocol, we illustrate a functional diagram of OpenFlow-based Bandwidth-Variable Optical Switch (OF-BVOS) as shown in Fig. 1(a) . In the switch, the OpenFlow switch software is embedded to keep the communication between controller and switch via OpenFlow Interface (OFI). The switch software receives the command (flow entry) from OpenFlow controller with the “Flow_mod” message and save it into the flow table. The OF-BVOS maintains flow table as software and translates the content to a programmable logic language which could be understood by hardware controller. This interworking is operated through Programmable Logical Interface (PLI). The function of hardware controller in Fig. 1(a) is used to realize the controlling of Bandwidth Variable Wavelength Cross-Connect (BV-WXC). The edge BV-WXC node which is equipped with Bandwidth Variable Wavelength Selected Switching [1] (BV-WSS) is shown in Fig. 1(a). The optical signal can be modulated to sub-carriers with any modulation format according to the requirement of traffic, and then launched by a tunable laser (T-LD) to the port of BV-WSS. This process can be manipulated by hardware controller through the Hardware Control Interface (HCI). In Fig. 1(a), OpenFlow switch software and hardware controller are implemented in a Linux PC, and BV-WXC is partly equipped with Finisar WaveShaper4000S which realize the flexible spectrum switching. The experimental details will be discussed in the Section 4.

 figure: Fig. 1

Fig. 1 Extended OpenFlow for Flexi-Grid optical networks. (a) OpenFlow-based bandwidth variable optical switch. (b) Flow entry extension. (c) Flow entries for different nodes.

Download Full Size | PDF

2.3 Extension of OpenFlow protocol for Flexi-Grid optical networks

Extension of flow entry: In the packet-switched network, OpenFlow abstracts the data plane as a flow entry which can be defined as “Rule”, “Action” and “Statistics” [13]. It presents the packet’s characteristic (IP address or TCP/UDP port) and the action of router or switch. The flow entry is also a key technology in the OpenFlow-based Flexi-Grid optical networks to control the optical flow. Figure 1(b) illustrates the extension option of flow entry for Flexi-Grid optical networks. As shown in Fig. 1(b), the “Rules” are extended as the In/Out Port, Central Frequency, Spectrum Size and Modulation Format which are the main characteristics in Flexi-Grid optical networks. The “Action” of optical node mainly includes four parts: Switch, Add and Drop to setup a lightpath, Delete to release a lightpath. Different combinations of “Rules” and “Action” are used to realize the control of optical transport node. Flow entries for different nodes of the path are given in Fig. 1(c). As shown in Fig. 1(c), in source node, a QPSK modulated optical flow with central frequency 192.750THz and spectrum size 50GHz is added in port 3 and out from port 4. The “Statistics” function is responsible for recording the optical flow property when the connection is setup. An option of flow property is to record the traffic rate information which aims to satisfy the dynamic Spectrum-on-Demand (SoD) service.

Description of the main extended OpenFlow protocol: To satisfy the requirement of Flexi-Grid optical networks, we make some extensions to the current OpenFlow protocol [13], which is shown as follows:

  • A. “Packet_in” message: is extended with two functions. One is to carry the lightpath request information which includes 32 bits “Source/Destination addr” and 16 bits “Traffic rate” and 32 bits “Path ID”. Additionally, it is also extended for returning a message to controller when OF-BVOSs complete the action. 32 bits “Path ID” and 8 bits “Reason” are extended to present the ID of a lightpath and the result of the action to this lightpath (success or failure) respectively. The controller will judge which function the “Packet_in” message presents and give the corresponding respond to OF-BVOS.
  • B. “Flow_mod” message: is extended for sending the lighpath setup/release commands to OF-BVOSs. The corresponding extensions involve of “OFP_Match” structure and “Command” field. For example, 32 bits “Central frequency”, 16 bits “Frequency slot” and 16 bits “Modulation format” are to present some features of lightpath in Flexi-Grid optical networks, which are implemented in structure “OFP_Match”. “Add”, “Switch” and “Drop” are actions which are implemented by extending “Command” field. The “Match” and “Command” information are collected by OF-BVOSs to control the lightpath setup and release.
  • C. “Stats_request/reply” message: is extended for informing controller about the status of optical flow. Structure “OFPST_Current_traffic” is newly added in which 32 bits “Path ID” presents the ID of a lightpath and 32 bits “Current traffic” presents the current traffic rate of this lightpath.

3. Dynamic lightpath setup and adjustment by using OpenFlow protocol

In this section, we present the signaling procedure for dynamic lightpath setup and adjustment for time-varying traffic in Flexi-Grid optical networks.

Time-varying traffic is dominant in today’s optical transport network, which the bandwidth between node pairs is varying over time. In WDM optical networks, a fixed channel (wavelength) is often provided for time-varying traffic, which leads to different bandwidth utilization in different time duration. Considering the benefit of Flexi-Grid optical networks, the spectrum size of optical channel can be flexibly provided according to the requirement of traffic. In this section, we realize the dynamic lightpath setup and adjustment by using extended OpenFlow protocol. Flow entry is updated by controller to trigger the action of switch. As described in previous section, the “Statistics” in flow entry can record the characteristic of traffic rate. When the traffic rate changed, OF-BVOS will send the spectrum adjustment information (Stats_reply message) to controller to generate a new flow entry. Then the controller will update the flow entry to the related OF-BVOSs to complete the spectrum adjustment.

Figure 2 illustrates a signaling procedure of elastic lightpath provisioning in OpenFlow-based Flexi-Grid optical networks. As shown in Fig. 2, traffic entering the Flexi-Grid optical networks is presented of time-varying feature. To effectively use the spectral resource, we can adjust the size of lightpath according to the requirement of traffic. The detailed descriptions of the procedure are summarized as follows:

 figure: Fig. 2

Fig. 2 Procedure of elastic lightpath provisioning.

Download Full Size | PDF

  • Step 1: OF-BVOS1 sends the connection request to the controller to establish a lightpath.
  • Step 2: Controller performs RSA algorithm and returns a flow entry to the related OF-BVOSs to trigger the switch action (via “Flow_mod” message). The lightpath is established.
  • Step 3: Controller queries to OF-BVOS1 about the traffic rate (via “Stats_request” message).
  • Step 4: When the traffic rate changed, OF-BVOS1 returns a message to controller to report the current traffic rate (via “Stats_reply” message).
  • Step 5: Controller sends a new flow entry to OF-BVOSs to adjust the spectrum size of lightpath (via “Flow_mod” message).

4. Experimental setup, results and discussions

We build a testbed with the topology as shown in Fig. 2. Two nodes (OF-BVOS1 and OF-BVOS2) are equipped with Finisar WaveShaper4000S which has the ability to emulate the Flexi-Grid switching capacity. The Waveshaper4000S has 4-port switching functionality, making it possible to switch or combine multiple signals at different wavelength. The other nodes, both OF-BVOSs and controller are the embedded Linux PC platform, which are running in IBM server. We develop a hardware control program according to the API function of WaveShaper4000S to control the WaveShaper4000S as well as record the hardware adjustment latency. The process of hardware control program is shown in Fig. 3 . Three different API functions are called to write filter profile into Waveshaper4000S. As shown in Fig. 3, the hardware control program can communicate with switch software and Waveshaper4000S through PLI and HCI respectively. In the experiment, time-varying traffic from OF-BVOS1 to OF-BVOS4 is established with spectrum size of 100GHz and then adjusted to 75GHz, 50GHz and 25GHz in three different time periods. The corresponding required numbers of frequency slots in WaveShaper4000S are 8, 6, 4 and 2 respectively (one frequency slot is 12.5GHz). The controller received connection request and performs RSA with shortest path routing algorithm.

 figure: Fig. 3

Fig. 3 The process of hardware control program.

Download Full Size | PDF

Figure 4 presents the whole signaling procedure for elastic lightpath setup and adjustment by using OpenFlow protocol. As shown in Fig. 4, 10.2.1.254 denotes the IP address of controller, and 10.2.1.1, 10.2.1.2, 10.2.1.5 and 10.2.1.6 denote the IP address of OF-BVOS1, OF-BVOS2, OF-BVOS3 and OF-BVOS4 respectively. After receiving connection request from source OF-BVOS, controller performs RSA and then sends “Flow_mod” messages to the corresponding OF-BVOSs simultaneously (Process #1 in Fig. 4). Then OF-BVOSs will return a success indicator and a lightpath ID via “Packet_in” message (Process #2). Message “Stats_request” (Process #3) is responsible for realizing lightpath adjustment by regularly querying OF-BVOS about the current traffic rate. Controller receives the responds from OF-BVOS via “Stats_reply” (Process #4) and then updates flow entries to corresponding OF-BVOSs via “Flow_mod” message (Process #5).

 figure: Fig. 4

Fig. 4 Wireshark capture of the signaling during the elastic lightpath setup and adjustment.

Download Full Size | PDF

Figures 5-9 illustrate the extended OpenFlow messages which correspond to Process #1 to #5 in Fig. 4, respectively. Figure 5 shows the extended “Flow_Mod” message which is sent to OF-BVOS2 (10.2.1.2) to setup a lightpath. It can be found some extensions we made for Flexi-Grid optical networks including 32 bits “Central frequency”, 16 bits “Frequency slot” and 16 bits “Modulation format” which are marked with red dotted line. In Fig. 5, “00 00 00 00”, “00 08” and “00 01” present a QPSK modulated lightpath with central frequency 193.0372 THz and spectrum size 100 GHz (8 frequency slots).

 figure: Fig. 5

Fig. 5 Wireshark capture of extended “Flow_mod” message for lightpath setup.

Download Full Size | PDF

Figure 6 illustrates the extension of “Packet_in” message. “Packet_in” message is the responds to controller when OF-BVOSs complete the action. 32 bits “Path ID” and 8 bits “Reason” are marked with red dotted line in which the “00 00 00 01” and “02” present lightpath ID (#1) is successfully established.

 figure: Fig. 6

Fig. 6 Wireshark capture of extended “Packet_in” message for lightpath setup.

Download Full Size | PDF

Figure 7 and Fig. 8 illustrate the Wireshark capture of the extended “Stats_request/reply” messages. 32 bits “Path ID” and 32 bits “Current traffic” are marked with red dotted line in which “00 00 00 01” and “00 00 00 06” denotes the lightpath ID (#1) and spectrum size (6 frequency slots) in its current stage. This session is initiated by controller and ended after receiving “Stats_reply” message from source OF-BVOS.

 figure: Fig. 7

Fig. 7 Wireshark capture of extended “Stats_request” message for lightpath adjustment.

Download Full Size | PDF

 figure: Fig. 8

Fig. 8 Wireshark capture of extended “Stats_reply” message for lightpath adjustment.

Download Full Size | PDF

After receiving “Stats_reply” message, controller will update the OF-BVOSs’ flow entry to expand or squeeze the filter (Waveshaper 4000S) pass band according to current traffic rate. Figure 9 illustrates the “Flow_mod” message which is sent to OF-BVOS1 (10.2.1.1). Looking into the “Frequency slot” field, it is obviously to find that the amount of frequency slots have changed to 6 compared with initial lightpath size (8 frequency slots in Fig. 5).

 figure: Fig. 9

Fig. 9 Wireshark capture of extended “Flow_mod” message for lightpath adjustment.

Download Full Size | PDF

The spectrum sizes of time-varying traffic in different time periods, which can be reflected on the filter profile of WaveShaper4000S, are shown in Figs. 10(a) -10(d). The filter profile can be changed by updating the flow entry of OF-BVOSs. Figure 10(e) shows the flow entry of OF-BVOS2 after lightpath is successfully established and adjusted. The flow entry is translated to the language which can be understood by WaveShaper4000S.

 figure: Fig. 10

Fig. 10 Filter profiles and flow entry after lightpath is established and adjusted.

Download Full Size | PDF

We also measure the lightpath setup and adjustment latency in our testbed. The latency includes the processing latency in controller and OF-BVOS, signaling latency between controller and OF-BVOS, and the WaveShaper4000S response latency. The WaveShaper4000S response latency includes the API writing latency (API writes filter profile to WaveShaper4000S) and hardware latency. The WaveShaper4000S response latency can be measured in API software when API Call ends, which is shown in the left side of Fig. 3. Table 1 shows the setup and adjustment latency of lightpath in Figs. 10(a)-10(d). The mainly contribution of latency is the WaveShaper4000S response latency which is ranged from 420ms to 460ms in our testbed. It can be seen that, the setup latency (~521ms) is a little higher than adjustment latency, because the WaveShaper4000S will probably response a little slower when a large spectral region (100 GHz) needs to be updated (established). Note that, the value of latencies is not static. It depends on different conditions in network, such as the number of requests, the size of networking topology, the running time of RSA algorithm, and also the processing ability of controller and OF-BVOS.

Tables Icon

Table 1. The overall latency of lightpath setup and adjustment

5. Conclusions

In order to meet the requirements of flexibility and programmability of network resource for future optical networks, we present an OpenFlow-based control plane in Flexi-Grid optical networks and experimentally demonstrate the dynamic lightpath establishment and adjustment. The overall signaling procedure and main extended OpenFlow messages are printed out in this paper. Additionally, we verify the feasibility of dynamic adjustment of spectrum size by controlling of Finisar WaveShaper4000S via extended OpenFlow protocol. The adjustment latency including the signaling latency and hardware latency is also evaluated.

Our future works contain two aspects. One is to extend the control plane testbed to a large scale topology. Therefore, the scalability issues are going to be considered including the distributed multi-controller architecture and the communication between them. The other is to develop network virtualization strategy in Flexi-Grid optical network and experiment it in the OpenFlow-based control plane in our testbed.

Acknowledgments

This work was supported in part by 863 program (2012AA011301), 973 program (2010CB328204), NSFC project (61271189, 61201154, 60932004), RFDP Project (20090005110013), 111 Project (B07005) and the Fundamental Research Funds for the Central Universities (2011RC0406).

References and links

1. M. Jinno, H. Takara, B. Kozicki, Y. Tsukishima, T. Yoshimatsu, T. Kobayashi, Y. Miyamoto, K. Yonenaga, A. Takada, O. Ishida, and S. Matsuoka, “Demonstration of novel spectrum-efficient elastic optical path network with per-channel variable capacity of 40 Gb/s to over 400 Gb/s,” in Proceedings of European Conference on Optical Communication (ECOC 2008), paper Th.3.F.6.

2. W. Wei, J. Hu, D. Qian, P. N. Ji, T. Wang, X. Liu, and C. Qiao, “PONIARD: a programmable optical networking infrastructure for advanced research and development of future Internet,” J. Lightwave Technol. 27(3), 233–242 (2009). [CrossRef]  

3. H. Takara, B. Kozicki, Y. Sone, T. Tanaka, A. Watanabe, A. Hirano, K. Yonenaga, and M. Jinno, “Distance-adaptive super-wavelength routing in elastic optical path network (SLICE) with optical OFDM,” in Proceedings of European Conference on Optical Communication (ECOC 2010), paper We.8.D.2.

4. M. S. Moreolo, J. M. Fabrega, L. Nadal, and J. Vilchez, “Software-defined optical OFDM transmission systems: Enabling elasticity in the data plane,” in Proceedings of International Conference on Transparent Optical Networks (ICTON 2012), pp.1–4.

5. E. Mannie, ed., “Generalized multi-protocol label switching (GMPLS) architecture,” IETF RFC 3945 (2004), http://tools.ietf.org/html/rfc3945.

6. L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “Experimental validation and performance evaluation of OpenFlow-based wavelength path control in transparent optical networks,” Opt. Express 19(27), 26578–26593 (2011). [CrossRef]   [PubMed]  

7. S. Azodolmolky, R. Nejabati, E. Escalona, R. Jayakumar, N. Efstathiou, and D. Simeonidou, “Integrated OpenFlow-GMPLS control plane: an overlay model for software defined packet over optical networks,” Opt. Express 19(26), B421–B428 (2011). [CrossRef]   [PubMed]  

8. T. Nadeau, “Software Driven Networks Problem Statement,” draft-nadeau-sdn-problem-statement-01(2011), https://datatracker.ietf.org/doc/draft-nadeau-sdn-problem-statement/

9. L. Liu, R. Muñoz, R. Casellas, T. Tsuritani, R. Martínez, and I. Morita, “OpenSlice: an OpenFlow-based control plane for spectrum sliced elastic optical path networks,” in Proceedings of European Conference on Optical Communication (ECOC 2012), paper Mo.2.D.3.

10. F. Paolucci, F. Cugini, N. Hussain, F. Fresi, and L. Potì, “OpenFlow-based flexible optical networks with enhanced monitoring functionalities,” in Proceedings of European Conference on Optical Communication (ECOC 2012), paper Tu.1.D.5.

11. M. Channegowda, R. Nejabati, M. Rashidifard, S. Peng, N. Amaya, G. Zervas, D. Simeonidou, R. Vilalta, R. Casellas, R. Martínez, R. Muñoz, L. Liu, T. Tsuritani, I. Morita, A. Autenrieth, J.-P. Elbers, P. Kostecki, and P. Kaczmarek, “First demonstration of an OpenFlow based software-defined optical network employing packet, fixed and flexible DWDM grid technologies on an international multi-Domain testbed,” in Proceedings of European Conference on Optical Communication (ECOC 2012), Postdeadline paper Th.3.D.2.

12. J. Zhang, J. Zhang, Y. Zhao, H. Yang, X. Yu, L. Wang, and X. Fu, “Experimental setup for OpenFlow-based elastic lightpath provisioning in Flexi-Grid optical networks,” in Proceedings of European Conference on Optical Communication (ECOC 2012), paper P5.01.

13. http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf.

Cited By

Optica participates in Crossref's Cited-By Linking service. Citing articles from Optica Publishing Group journals and other participating publishers are listed here.

Alert me when this article is cited.


Figures (10)

Fig. 1
Fig. 1 Extended OpenFlow for Flexi-Grid optical networks. (a) OpenFlow-based bandwidth variable optical switch. (b) Flow entry extension. (c) Flow entries for different nodes.
Fig. 2
Fig. 2 Procedure of elastic lightpath provisioning.
Fig. 3
Fig. 3 The process of hardware control program.
Fig. 4
Fig. 4 Wireshark capture of the signaling during the elastic lightpath setup and adjustment.
Fig. 5
Fig. 5 Wireshark capture of extended “Flow_mod” message for lightpath setup.
Fig. 6
Fig. 6 Wireshark capture of extended “Packet_in” message for lightpath setup.
Fig. 7
Fig. 7 Wireshark capture of extended “Stats_request” message for lightpath adjustment.
Fig. 8
Fig. 8 Wireshark capture of extended “Stats_reply” message for lightpath adjustment.
Fig. 9
Fig. 9 Wireshark capture of extended “Flow_mod” message for lightpath adjustment.
Fig. 10
Fig. 10 Filter profiles and flow entry after lightpath is established and adjusted.

Tables (1)

Tables Icon

Table 1 The overall latency of lightpath setup and adjustment

Select as filters


Select Topics Cancel
© Copyright 2024 | Optica Publishing Group. All rights reserved, including rights for text and data mining and training of artificial technologies or similar technologies.