Experimental validation and performance evaluation of OpenFlow-based wavelength path control in transparent optical networks

doi:10.1364/OE.19.026578

« Show journal navigation

Experimental validation and performance evaluation of OpenFlow-based wavelength path control in transparent optical networks

Lei Liu, Takehiro Tsuritani, Itsuro Morita, Hongxiang Guo, and Jian Wu »View Author Affiliations

Optics Express, Vol. 19, Issue 27, pp. 26578-26593 (2011)
http://dx.doi.org/10.1364/OE.19.026578

View Full Text Article

Acrobat PDF (2894 KB)

Journal Search
Article Lookup

Article Tools

Citations

Alert me when this article is cited
Export Citation/Save

Article Navigation

▸ Article Outline
– Abstract
1. Introduction
2. OpenFlow-based wavelength path control in transparent optical networks
3. Experimental setup, results and discussions
4. Conclusions
– References and links

Article Tools
Full Text
Article Info
References
Cited By
Figures
Metrics
Download PDF

Viewing Equations in the
HTML Article

Optimal Viewing Recommendations

Full Text
Article Info
References (9)
Cited By
Figures (15)
Metrics

Abstract

OpenFlow, as an open-source protocol for network virtualization, is also widely regarded as a promising control plane technique for heterogeneous networks. But the utilization of the OpenFlow protocol to control a wavelength switched optical network has not been investigated. In this paper, for the first time, we experimentally present a proof-of-concept demonstration of OpenFlow-based wavelength path control for lightpath provisioning in transparent optical networks. We propose two different approaches (sequential and delayed approaches) for lightpath setup and two different approaches (active and passive approaches) for lightpath release by using the OpenFlow protocol. The overall feasibility of these approaches is experimentally validated and the network performances are quantitatively evaluated. More importantly, all the proposed methodologies are demonstrated and evaluated on a real transparent optical network testbed with both OpenFlow-based control plane and data plane, which allows their feasibility and effectiveness to be verified, and valuable insights of the proposed solutions to be obtained for deploying into real OpenFlow controlled optical networks.

1. Introduction

Transparent optical networks are typically composed of nodes such as reconfigurable optical add-drop multiplexers (ROADM), wavelength cross-connects (WXC) and photonic cross-connects (PXC). In the current commercial metro and core networks, these optical nodes are controlled and managed through the element management system (EMS) and/or the network management system (NMS) in a manual and semi-static style for lightpath provisioning, as shown in Fig. 1 . Although this approach is very reliable, the network carriers require a control plane technique for dynamic and intelligent control of wavelength paths in transparent optical networks, in order to save operational expense, reduce the processing latency, and handle the rapid increase of dynamic network traffic.

Fig. 1 NMS/EMS-based lightpath provisioning in current optical networks.

A well-known choice is generalized multi-protocol label switching (GMPLS) [1

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

], which is a stable protocol suite to automatically provision end-to-end connections in a fully distributed manner. However, the GMPLS-based control plane has not been widely deployed, and more importantly, most network carriers seem to lack the confidence to promote the commercial deployment of GMPLS in the optical backbone. The reasons for this situation are complicated [2

A. Farrel, “A unified control plane: dream or pipedream,” presented at the 6th International Conference on IP + Optical Network (IPOP 2010), Tokyo, Japan, 10–11 Jun., 2010. http://www.pilab.jp/ipop2010/info/onlineproceedings.html.

]. One of the most important reasons is that the carriers are risk averse and prefer a centralized control approach rather than distributed approach because the centralized control architecture is simpler, more manageable and reliable. Moreover, a centralized control scheme is easier to migrate and update from the current NMS/EMS architecture that has been established, with huge investments already made.

Recently, a new open-source protocol referred to as OpenFlow has been proposed [3

“The OpenFlow switch consortium,” http://www.openflow.org/.

] and received extensive attention worldwide [4

S. Das, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and L. Ong, “Packet and circuit network convergence with OpenFlow,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG1. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG1.

–7

S. Das, A. R. Sharafat, G. Parulkar, and N. McKeown, “MPLS with a simple OPEN control plane,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper OWP2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2011-OWP2.

]. Although the original motivation of OpenFlow is to develop virtualized and programmable networks, it has also been widely regarded as a promising candidate for a control plane technique in heterogeneous networks because of its special features [4

–7

]. In order to dynamically control an optical network with a centralized control plane, we experimentally demonstrate OpenFlow-based wavelength path control in transparent optical networks, and to the best of our knowledge, this is the first study to investigate the OpenFlow-based control of an optical network. A previous study with a similar background can be found in [5

V. Gudla, S. Das, A. Shastri, G. Parulkar, N. McKeown, L. Kazovsky, and S. Yamashita, “Experimental demonstration of OpenFlow control of packet and circuit switches,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG2.

], in which the OpenFlow is utilized to control a single 1x9 wavelength selective switch (WSS). In this paper, we propose two different approaches (sequential and delayed approaches) for lightpath setup and two different approaches (active and passive approaches) for lightpath release in the optical network by using the OpenFlow protocol. The overall feasibility of these approaches was experimentally validated and the network performances were quantitatively evaluated. More importantly, all the proposed methodologies were demonstrated and evaluated on a real transparent optical network testbed with both an OpenFlow-based control plane and a data plane, which is beneficial for verifying their feasibility and effectiveness, and obtaining valuable insights for proposed solutions when deploying into real OpenFlow controlled optical networks.

The rest of this paper is organized as follows. Section 2 proposes solutions for OpenFlow-based wavelength path control in transparent optical networks. Section 3 presents the experimental demonstration and performance evaluations of the proposed solutions. Section 4 concludes this paper by summarizing our contributions and discussing directions for our future works.

2. OpenFlow-based wavelength path control in transparent optical networks

In this section, the OpenFlow protocol is introduced firstly. After that, the OpenFlow-based optical node is presented. Finally, the signaling procedures for dynamic lightpath setup and release in OpenFlow-based optical networks are proposed and investigated in detail.

2.1 Brief introduction to OpenFlow

We briefly outline the main features of OpenFlow. A more detailed and exhaustive description is available in [3

“The OpenFlow switch consortium,” http://www.openflow.org/.

]. An OpenFlow-based network comprises at least one OpenFlow controller (e.g. NOX [8

“NOX: an OpenFlow controller,” http://noxrepo.org/wp/.

]), several OpenFlow switches, a secure channel that interconnects the NOX with the OpenFlow switch, and the OpenFlow protocol for signaling between the NOX and the switches. In an OpenFlow controlled network, packet forwarding is executed in the OpenFlow switch according to a flow table, and the NOX is responsible for the routing decision. When the OpenFlow switch receives a packet that does not match any entry in the flow table, it sends the packet to the NOX. The NOX may drop the packet or may add a new flow entry in the flow table, to force the OpenFlow switch to forward packets belonging to the same flow on a given path. Each entry in the flow table of an OpenFlow switch contains a packet header that defines the flow, the action defines how to process the packets, and flow statistics, as shown in Fig. 2 .

Fig. 2 Architecture of an OpenFlow-enabled network [3

“The OpenFlow switch consortium,” http://www.openflow.org/.

2.2 OpenFlow-based optical nodes

We adopt the PXC as an example to illustrate how to use OpenFlow protocol to control an optical node. Figure 3(a) shows the structure of a PXC. In order to control this node through the OpenFlow protocol, we introduce virtual Ethernet interfaces (veths) to an OpenFlow switch. These veths are virtualized from the physical interfaces of the PXC and each veth exactly corresponds to a physical interface of the PXC, as shown in Fig. 3(a). By using this approach, the OpenFlow switch obtains a virtualized view of the physical structure of the PXC, which is greatly beneficial for the NOX to control the cross-connections within the PXC by using the OpenFlow protocol.

Fig. 3 OpenFlow-based optical nodes. (a) Virtualization of the physical interfaces of a PXC to virtual Ethernet interfaces (veths) of an OpenFlow switch. (b) Architecture of an OF-PXC.

The combination of an OpenFlow switch and the corresponding PXC is referred to as an OpenFlow-enabled PXC (OF-PXC), which is controlled by a NOX controller through the OpenFlow protocol, as shown in Fig. 3(b). Once the first IP packet of a new flow is received by the NOX, the NOX obtains the source and destination IP addresses of this flow and then performs routing and wavelength assignment (RWA) based on its knowledge of the whole network. After that, according to the results, the NOX inserts a new flow entry in the flow table of the OpenFlow switch. In turn, based on the flow entry, the OpenFlow switch automatically sends standard transaction language 1 (TL1) commands to cross-connect the corresponding ports of PXC through the transmission control protocol (TCP) interface to establish the lightpath, thanks to the same virtualized view of the PXC structure in the OpenFlow switch. For example, as shown in Fig. 3(b), if the RWA result calculated by the NOX is a path from the west side to the east side through the PXC and the assigned wavelength is W3, the NOX firstly inserts a flow entry in the OpenFlow switch with the input port veth3 and the output port veth7. After that, based on this flow entry, the OpenFlow switch sends a TL1 command to the PXC to cross-connect the physical ports between 3 and 7.

2.3 Signaling procedures for lightpath control in an OpenFlow-based optical network

In order to dynamically control a wavelength path, we propose two approaches for lightpath setup, referred to as the sequential approach and the delayed approach respectively. Moreover, we also propose two approaches for lightpath release, which are referred to as the active approach and the passive approach respectively.

Lightpath setup

The sequential approach for lightpath setup. The sequential approach refers to the solution by which the OpenFlow protocol controls the ingress IP router and optical nodes in sequential order. The signaling procedure is depicted in Fig. 4 and summarized as follows:

Fig. 4 Signaling procedures of lightpath setup by using the sequential approach.

Step 1: IP traffic (an IP flow) arrives at the ingress OpenFlow-enabled IP router/switch (OF-R1).
Step 2: If the IP flow does not match any flow entries in the flow table of OF-R1, OF-R1 forwards the first packet of this flow to the NOX.
Step 3: The NOX calculates the route (e.g. the path computation result is OF-R1→OF-PXC1→OF-PXC2), assigns the wavelength in the optical network, and then adds a new flow entry in OF-R1, OF-PXC1 and OF-PXC2 respectively.
Step 4: OpenFlow switches of OF-PXC1 and OF-PXC2 send TL1 commands to set up cross-connects of the PXCs.
Step 5: The lightpath is successfully established and the flow arrives at the OF-R2 through the lightpath.
Step 6: If the flow does not match any flow entries in the flow table of OF-R2, OF-R2 forwards the first packet of this flow to the NOX.
Step 7: NOX inserts a new flow entry in the flow table of OF-R2.
Step 8: The IP flow is forwarded to the destination.

The sequential approach is the most straightforward solution for lightpath provisioning. However, considering the configuration latency of the PXC for cross-connection and the signaling latency within each OF-PXC (i.e. between each OpenFlow switch and the corresponding PXC), there is no guarantee that the lightpath in the optical domain is completely provisioned before the flow arrives at the ingress OF-PXC (e.g. OF-PXC1 in Fig. 4). Assume that the signaling propagation latency between NOX and the ingress OF-R is t₁, the time latency for flow entry insertion in the ingress OF-R is t₂, the latency for the IP data flow transmission from the ingress OF-R to the ingress OF-PXC (e.g. OF-R1 to OF-PXC1 in Fig. 4) is t₃, and the optical connection setup latency is T_opt, which comprises the signaling propagation latency among the NOX, the OpenFlow switches and the PXCs, the internal processing latency in the OpenFlow switches, and the latency for cross-connection in the PXCs. In this case, packet losses will occur when T_opt is longer than the sum of t₁, t₂ and t₃. In other words, the packet loss possibility of the sequential approach is equal to the possibility of the case that T_opt>t₁ + t₂ + t₃. When packet loss occurs, if we further assume that the total amount of data for the IP flow is TD and the transmission rate is V, the amount of lost packets can be calculated as V(T_opt-t₁-t₂-t₃) and in turn, the packet loss probability can be measured as V(T_opt-t₁-t₂-t₃)/TD. Clearly, when packet losses occur, the service performance will degrade even if some higher layer mechanisms (e.g. TCP) are utilized to retransmit the lost packets. In light of this, we propose the delayed approach for lightpath provisioning to address this issue.

The delayed approach for lightpath setup. The signaling procedure of lightpath setup by using the delayed approach within an OpenFlow-based optical network is shown in Fig. 5 . Different from the sequential approach, by using the delayed approach, the NOX firstly controls the OF-PXCs to establish a lightpath in the optical domain. After that, the NOX waits for a deliberate time delay and then inserts a new flow entry in the ingress IP router. With this approach, the control of the ingress IP router is “delayed.” Therefore, this approach is referred to as the delayed approach. The operations of this approach in an OpenFlow-enabled optical network are summarized as follows:

Fig. 5 Signaling procedures of lightpath setup by using the delayed approach.

Step 1: IP traffic (an IP flow) arrives at the ingress OpenFlow-enabled IP router/switch (OF-R1).
Step 2: If the IP flow does not match any flow entries in the flow table of OF-R1, OF-R1 forwards the first packet of this flow to the NOX.
Step 3: The NOX calculates the route (e.g. the path computation result is OF-R1→OF-PXC1→OF-PXC2), assigns the wavelength in the optical network, and then adds a new flow entry in OF-PXC1 and OF-PXC2 respectively.
Step 4: OpenFlow switches of OF-PXC1 and OF-PXC2 send TL1 commands to set up cross-connections of the PXCs.
Step 5: The NOX waits for an appropriate time delay for the successful lightpath provisioning in the optical domain and then inserts a new flow entry in the ingress IP router (OF-R1).
Step 6: The flow arrives at the OF-R2 through the lightpath.
Step 7: If the flow does not match any flow entries in the flow table of OF-R2, OF-R2 forwards the first packet of this flow to the NOX.
Step 8: NOX inserts a new flow entry in the flow table of OF-R2.
Step 9: The IP flow is forwarded to the destination.

The advantage of the delayed approach is that this approach can guarantee a successful end-to-end IP flow transmission as the optical connection is well established before the IP flow arrives at the ingress optical node, at the expense of longer signaling latency due to the waiting time in the NOX controller.

Lightpath release

The active approach for lightpath release. The active approach is a special solution for lightpath release. It is only applicable when the amount of data for the arriving traffic is known in advance. In this case, the connection holding time in the optical domain can be predicted. Therefore, the NOX controller can insert a “hard timeout” field in the corresponding flow entry in the flow table. This field can be utilized to indicate the connection holding time. After the “hard timeout” expires, the OpenFlow switch automatically deletes the corresponding flow entry and in turn, releases the cross-connection of the PXC. Since this approach releases a lightpath directly from each OpenFlow switch without any external requests or indications, it is referred to as the “active” approach.

The passive approach for lightpath release. The passive approach releases a lightpath by the NOX controller after a lightpath release indication is received. The signaling procedure of the passive approach for lightpath release is shown in Fig. 6 . By using this approach, after a flow is successfully transmitted, the source client sends a packet to notify the completeness of the service. This packet is also a standard IP package but with a specified source and/or destination TCP/UDP ports. These ports are pre-determined, according to the service agreement between the users and the service providers. Clearly, due to the special TCP/UDP ports, this packet is treated as the first packet of a new flow by the ingress OF-R, and in turn, the ingress OF-R sends this packet to the NOX controller through the OpenFlow protocol. After the NOX controller receives this packet, it analyzes the source and/or destination TCP/UDP ports of this packet. If these ports are the same as the specified TCP/UDP ports based on the service agreement, the NOX controller can realize that this packet is not the first packet of a new flow, but a notification of the completeness of an existing flow. Therefore, according to the source and destination IP addresses of this packet, the NOX controller can determine the corresponding flow entry and then delete this existing entry. The detailed operations of the passive approach for lightpath release are summarized as follows:

Fig. 6 Signaling procedures of lightpath release by using the passive approach.

Step 1: The client-1 sends an IP packet with specified source (and/or destination) TCP (or UDP) ports after the completeness of flow transmission.
Step 2: The IP packet does not match any flow entries in the flow table of OF-R1 due to the specified source (and/or destination) TCP (or UDP) port. Then OF-R1 forwards this packet to the NOX, as a first packet of a new flow.
Step 3: NOX receives this packet and through the analysis of the source (and/or destination) TCP (or UDP) port, the NOX controller determines that this packet is not a first packet of a new flow, but an indication of service completeness of an existing flow. Then according to the source and destination IP addresses of this IP packet, the NOX deletes the corresponding flow entries in OF-R1, OF-PXC1 and OF-PXC2.
Step 4: OpenFlow switches of OF-PXC1 and OF-PXC2 send TL1 commands to delete the corresponding cross-connections in the PXCs.

Clearly, different from the NMS/EMS-based solution presented in Fig. 1, the approaches and procedures proposed in the sub-section are fully dynamic. In an optical network with an OpenFlow-based control plane, the NMS system is also expected to be introduced. In this case, it can be utilized to send a request to NOX to establish or delete a connection from the network operator.

3. Experimental setup, results and discussions

In order to verify the aforementioned methodologies and evaluate the solutions we proposed in this paper, we constructed a transparent optical network testbed with four OF-PXCs in a mesh topology, as shown in Fig. 7 . Each optical link was configured with four wavelengths (1552.50 nm, 1553.33 nm, 1554.13 nm and 1554.94 nm), and an optical spectrum analyzer was installed in the link OF-PXC1—OF-PXC2. Four OpenFlow-enabled software switches/routers (OF-Rs) were assumed to be connected to the four OF-PXCs respectively. In addition, a PC was attached to each OF-R as a client, through an Ethernet cable. But due to the lack of suitable transponders, four distributed feed-back laser diode (DFB-LD) modules as quasi-transponders were connected to OF-PXC1, which worked at the aforementioned wavelengths as light sources, as shown in Fig. 7.

Fig. 7 Experimental setup.

If an IP flow from the client is received by the OF-R, the OF-R sends the first packet of this IP flow to the NOX controller to insert a flow entry and establish a lightpath according to the sequential approach or delayed approach. Alternatively, in order to evaluate the lightpath setup and release, only the first packet of the forthcoming IP flows needs to be sent to the OF-R because only the first packet of a flow is required by the NOX for path computation, flow entry modification and lightpath setup. The rest of the packets of this flow will transmit through the established lightpath, without any communication with the NOX controller. In this sense, the first IP packet of a new flow can be regarded as a lightpath setup request in a dynamic provisioning scenario. Furthermore, the operator can also send this lightpath setup request (i.e. a standard IP packet with the source and destination client addresses) to the NOX controller in a static provisioning scenario. But note that a proxy of the OpenFlow switch must be inserted between the operator and the NOX in order to encapsulate this IP packet with the OpenFlow protocol.

In our current implementation, the centralized NOX obtained a copy of the network topology and wavelength availabilities for each optical link. Moreover, in the optical domain, all the feasible routes between a pair of OF-Rs were pre-computed through the conventional k-shortest-path algorithm in the NOX. For a new IP flow (or a lightpath setup request), the NOX always selected the route with least hops among all the feasible routes, unless the wavelength continuity constraint (WCC) could not be satisfied on this route. After the route was determined, the first fit mechanism was adopted to assign a wavelength for this route.

In the experiment, firstly we assumed all the wavelengths in links OF-PXC1—OF-PXC3 and OF-PXC1—OF-PXC4 were occupied and we updated the information of wavelength availabilities in the NOX. Then four IP flows (or lightpath setup requests) were sent from client-1 respectively, as summarized in Table 1 . The flows (1) and (2) were routed on the shortest path on wavelengths W1 and W2 respectively. For the flow (3), since the WCC could not be satisfied on the shortest path, NOX selected the second shortest path to route this request and assigned wavelength W3 for this lightpath. Similarly, the flow (4) was routed on the third shortest path by using the wavelength W4. Figures 8(a) -8(d) shows the optical spectrum on link OF-PXC1—OF-PXC2 when the four lightpaths were established one by one.

Table 1 Summary of flows and lightpaths

No.	Source	Destination	Calculated Lightpath	Wavelength
1	Client-1	Client-3	OF-PXC1→OF-PXC2	W1(1552.52 nm)
2	Client-1	Client-3	OF-PXC1→OF-PXC2	W2(1553.33 nm)
3	Client-1	Client-4	OF-PXC1→OF-PXC2→OF-PXC3	W3(1554.13 nm)
4	Client-1	Client-2	OF-PXC1→OF-PXC2→OF-PXC3→OF-PXC4	W4(1554.94 nm)

Fig. 8 Optical spectrum observed on link OF-PXC1—OF-PXC2.

Figure 9 shows printed information from the NOX controller during the lightpath setup for flow (1) by using the sequential approach. After a new packet is received by the NOX, the NOX performs the RWA algorithm, and then installs a new flow entry in OF-R1, OF-PXC1 and OF-PXC2 respectively, in sequential order. In Fig. 9, the “dpID” is short for data path identifier, which is the OpenFlow terminology to represent an OpenFlow switch. In our experimental setup, the “dpID 1,” “dpID 2” and “dpID 3” refer to OF-R1, OF-PXC1 and OF-PXC2 respectively. By using Wireshark, packet analyzing software that monitors network traffic and displays operating system-based time-stamped packets, we obtained the protocol capture files as shown in Fig. 10 . From Fig. 10, we can clearly observe the OpenFlow-based signaling procedures when the sequential approach is adopted for lightpath setup. The signaling latency among NOX and each OpenFlow switch is very short, around 1.67 ms in total as shown in Fig. 10.

Fig. 9 Printed information from the NOX during lightpath setup with the sequential approach.

Fig. 10 Wireshark capture of the OpenFlow protocol during lightpath setup with the sequential approach.

On the other hand, Fig. 11 and Fig. 12 show the printed information from the NOX controller and the Wireshark capture respectively, during the lightpath setup for flow (1) by using the delayed approach. As shown in both figures, once a new packet is received by the NOX controller, it firstly inserts a new flow entry in OF-PXC1 and OF-PXC2 respectively to set up a lightpath in the optical domain. After that the NOX waits for 300 ms, and then inserts a flow entry in the OF-R1 to start the flow transmission. Note that the waiting time depends on the signaling latency between the OpenFlow switch and the optical node, as well as the configuration latency of the optical node. It may vary with different hardware (e.g. optical nodes) or different lightpaths (e.g. different hops). If this waiting time is set too short, it cannot guarantee successful flow transmission through the lightpath. On the contrary, if this time is too long, it will introduce long end-to-end signaling latency. In an actual operational scenario, a precise waiting time can be obtained by performance monitoring in the transponder at the receiver side.

Fig. 11 Printed information from the NOX during lightpath setup with the delayed approach.

Fig. 12 Wireshark capture of the OpenFlow protocol during lightpath setup with the delayed approach.

Figure 13 shows the flow entries in the flow table of OF-PXC1 for these four lightpaths when the active approach is utilized for lightpath release. In this experiment, we assume that the connection holding times for flow (1)-(4) are 1000 seconds, 500 seconds, 5000 seconds and 2000 seconds respectively. In this case, a “hard timeout” field is required to insert for the corresponding flow entry, as aforementioned. Take the flow entry for flow (1) as an example. The “hard_timeout=1000” and “duration_sec=64s” indicate the total connection holding time is 1000 seconds and this connection has already been established for 64 seconds. The “in_port=1, actions=output:5” shows that the input port and output port of the OpenFlow switch in OF-PXC1 are veth1 and veth5 respectively, corresponding to the cross-connection from port 1 to port 5 in the optical node. After the “hard timeout” expires, the OpenFlow switch automatically deletes the corresponding flow entry and releases the cross-connection in the PXC. Since the optical connection for flow (2) is with the shortest holding time in this experiment, it is released firstly, and then the optical connection for flow (1) is released, as shown in Figs. 8(e)-8(f).

Fig. 13 Flow table of OF-PXC1 after four lightpaths are successfully established.

The experimental results of lightpath release for flow (1) with the passive approach are shown in Fig. 14 and Fig. 15 , which are the printed information from the NOX controller and the Wireshark capture respectively. Similarly, an IP packet for lightpath is sent from client-1 after the completeness of flow traffic transmission. But different from a new IP flow (or a lightpath setup request), this IP packet is with specified source and destination TCP ports. Therefore, the NOX controller realizes that that it is an indication for lightpath release. The results in Fig. 14 and Fig. 15 show that this approach is feasible and efficient for releasing a lightpath.

Fig. 14 Printed information from the NOX during lightpath release with the passive approach.

Fig. 15 Wireshark capture of the OpenFlow protocol during lightpath release with the passive approach.

Moreover, we quantitatively measured the path setup and release latency in our demonstrated scenario by using the proposed solutions. It should be noted that the path setup latency evaluated in this paper not only includes the lightpath provisioning latency in the optical domain, but also comprises the control of the ingress OF-R. In this regard, the contributors to the overall path setup latency include: the packet (request) propagation latency from the client to the NOX, the packet processing latency in the NOX and OpenFlow switches, the signaling latency among the NOX, the OpenFlow switches and the PXCs, and the internal cross-connection time of the PXCs. Similarly, the path release latency includes the deletion of the corresponding flow entries in the ingress OF-R as well as the lightpath release latency in the optical domain. In the case of the active approach, the path release latency comprises the processing latency in OpenFlow switches, the signaling latency between the OpenFlow switches and the PXC, and the operational latency within the PXC for deleting the cross-connection. In the case of the passive approach, the packet (request) propagation latency from the client to the NOX, the packet processing latency in the NOX, as well as the OpenFlow signaling latency among the NOX and each OpenFlow switch must be added.

The results are summarized in Table 2 . For the internal cross-connection time of the PXC, we simply used the reference value of 10 ms. The results in Table 2 show that the time for provisioning paths for flows (1)-(4) is around 243 ms~254 ms by using the sequential approach. If the delayed approach is adopted for lightpath provisioning, this time increases to 314 ms~316 ms, which is longer than that of the sequential approach. This is because the NOX controller has to wait for a period of time (in this experiment, 300 ms) in order to cover the lightpath setup latency in the optical domain. For the sequential approach, the path setup times for flows (3) and (4) are slightly longer than those for flows (1) and (2), mainly due to the longer processing latency in the NOX (e.g. RWA) and the signaling latency. Compared to our previous implementation in [9

L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “OpenFlow-based wavelength path control in transparent optical networks: a proof-of-concept demonstration,” in 37th European Conference and Exhibition on Optical Communications (ECOC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper Tu.5.K.2. http://www.opticsinfobase.org/abstract.cfm?URI=ECOC-2011-Tu.5.K.2.

], the software processing is optimized by deleting some authentication operations in order to reduce the path setup latency. Note that, although the sequential approach outperforms the delayed approach in terms of the path setup latency, it may result in packet losses if the optical connection is not completely established before the flow arrives, as aforementioned.

Table 2 Summary of path setup and release latency

Flow No.	Sequential approach for lightpath setup	Delayed approach for lightpath setup	Active approach for lightpath release	Passive approach for lightpath release
1	~243 ms	~314 ms	~123 ms	~126 ms
2	~243 ms	~314 ms	~123 ms	~126 ms
3	~249 ms	~315 ms	~124 ms	~127 ms
4	~254 ms	~316 ms	~124 ms	~128 ms

In addition, since the lightpath release requests are directly sent from each OpenFlow switch after the timeout, the path release times for the four lightpaths are almost the same, around 123 ms, when the active approach is deployed. On the other hand, if the passive approach is adopted, the lightpath release latency is around 126 ms~128 ms for flows (1)-(4), which is slightly longer than that of the active approach. The reason for this is that, compared to the active approach, the packet (request) propagation latency from the client to the NOX, the packet processing latency in the NOX, as well as the OpenFlow signaling latency among the NOX and each OpenFlow switch are added for overall path release latency.

When the network becomes more complex, the path setup latency by using both the sequential and delayed approaches will increase accordingly, due to the longer processing time in the NOX controller for RWA computation, and the longer latency of the OpenFlow-based signaling for the insertion of flow entries in all the related OF-PXCs. Moreover, the path setup latency of the delayed approach is still expected to be longer than that of the sequential approach due to the NOX waiting time. For an optical connection with more hops, a relatively longer waiting time must be introduced in the NOX to cover the provisioning time of the lightpath. On the other hand, the active approach will not be significantly affected in terms of path release latency even if there are many nodes involved in a lightpath. This is because by using the active approach, the cross-connections of the PXCs are directly and simultaneously released from each OpenFlow switch after the timeout. Therefore, each OpenFlow switch is fully independent from the NOX controller and other OpenFlow switches during the lightpath release, which implies that the overall path release latency will not be remarkably affected with the increasing numbers of OF-PXCs along a lightpath. However, the path release latency of the passive approach will increase when the network becomes more complex, and thus, it will be longer than that of the active approach. This is because in this case, the centralized NOX controller has to inform more OpenFlow switches to release the cross-connections through the OpenFlow protocol, which will increase the overall signaling latency.

Finally, based on the proposed solutions and the obtained results, we compared the conventional NMS/EMS-based and the OpenFlow-based path control schemes, as summarized in Table 3 . Compared to the conventional NMS/EMS-based solution, the OpenFlow-based scheme is able to dynamically setup and release an end-to-end path for IP flow transmission within the optical domain, with many advantages such as the reduction of operational cost and path provisioning latency. These advantages, as well as the centralized feature of the OpenFlow protocol, are attractive and would be greatly beneficial for the carriers, if it were deployed as an intelligent control plane for optical networks.

Table 3 Comparison of the conventional NMS/EMS-based and the OpenFlow-based schemes

Items	NMS/EMS-based Solution	OpenFlow-based Solutions
	● Mature technique with the deployment in real operational scenarios		● In the early stage with many issues to be investigated
Features	● Manual and semi-static styles for path setup and release		● Dynamic setup and release of end-to-end paths
	● High operational cost		● Low operational cost
	● Separated control of IP and optical domains		● Unified control of IP and optical domains
Path Setup Latency	Long (Several hours to several days)	Short (Hundreds of milliseconds)
Path Release Latency	Long (Several hours to several days)	Short (Hundreds of milliseconds)

4. Conclusions

In this paper, for the first time, we experimentally present a proof-of-concept demonstration of OpenFlow-based wavelength path control in transparent optical networks. In order to control an optical node by using the OpenFlow protocol, we propose a solution for the virtualization of an optical node through an OpenFlow switch. Based on this virtualization, we propose two different approaches for lightpath setup and two different approaches for lightpath release, in an OpenFlow-enabled optical network. Using the proposed solutions, we verified the overall feasibility of OpenFlow-controlled optical networks, including dynamic lightpath setup and release, routing and wavelength assignment, as well as the dynamic cross-connection of optical nodes. We also quantitatively evaluated the network performances such as the latency of lightpath setup and release in a transparent network testbed with four PXC nodes in a mesh topology.

Our future works are two-fold. One is the enhancement of the OpenFlow protocol to support add/drop devices (e.g. transponders, regenerators, etc.) and to support the dynamic lightpath restoration in transparent wavelength switched optical networks. The other is the investigation of a unified OpenFlow-based control plane for the heterogeneous multi-layer optical switching networks.

Compared to GMPLS, OpenFlow is still in the very early stage. Many issues have to be investigated for the OpenFlow-based control plane, such as the protection and restoration, standardization, multi-vendor interoperability, etc. However, due to the previously mentioned advantages of OpenFlow (e.g., simple, centralized, unified control for IP/optical multi-layer networks, etc.), OpenFlow is still a promising intelligent control plane technique for dynamic optical networks in the future, and we hope the work presented in this paper contributes to accelerating this procedure.

References and links

1.	E. Mannie, ed., “Generalized multi-protocol label switching (GMPLS) architecture,” IETF RFC 3945 (2004), http://tools.ietf.org/html/rfc3945.
2.	A. Farrel, “A unified control plane: dream or pipedream,” presented at the 6th International Conference on IP + Optical Network (IPOP 2010), Tokyo, Japan, 10–11 Jun., 2010. http://www.pilab.jp/ipop2010/info/onlineproceedings.html.
3.	“The OpenFlow switch consortium,” http://www.openflow.org/.
4.	S. Das, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and L. Ong, “Packet and circuit network convergence with OpenFlow,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG1. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG1.
5.	V. Gudla, S. Das, A. Shastri, G. Parulkar, N. McKeown, L. Kazovsky, and S. Yamashita, “Experimental demonstration of OpenFlow control of packet and circuit switches,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG2.
6.	S. Das, Y. Yiakoumis, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and P. D. Desai, “Application-aware aggregation and traffic engineering in a converged packet-circuit network,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper NThD3. http://www.opticsinfobase.org/abstract.cfm?URI=NFOEC-2011-NThD3.
7.	S. Das, A. R. Sharafat, G. Parulkar, and N. McKeown, “MPLS with a simple OPEN control plane,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper OWP2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2011-OWP2.
8.	“NOX: an OpenFlow controller,” http://noxrepo.org/wp/.
9.	L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “OpenFlow-based wavelength path control in transparent optical networks: a proof-of-concept demonstration,” in 37th European Conference and Exhibition on Optical Communications (ECOC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper Tu.5.K.2. http://www.opticsinfobase.org/abstract.cfm?URI=ECOC-2011-Tu.5.K.2.

OCIS Codes
(060.4250) Fiber optics and optical communications : Networks
(060.4510) Fiber optics and optical communications : Optical communications

ToC Category:
Backbone and Core Networks

History
Original Manuscript: October 3, 2011
Revised Manuscript: November 11, 2011
Manuscript Accepted: November 14, 2011
Published: December 14, 2011

Virtual Issues
European Conference on Optical Communication 2011 (2011) Optics Express

Citation
Lei Liu, Takehiro Tsuritani, Itsuro Morita, Hongxiang Guo, and Jian Wu, "Experimental validation and performance evaluation of OpenFlow-based wavelength path control in transparent optical networks," Opt. Express 19, 26578-26593 (2011)
http://www.opticsinfobase.org/oe/abstract.cfm?URI=oe-19-27-26578

Sort: Journal | Reset

References

E. Mannie, ed., “Generalized multi-protocol label switching (GMPLS) architecture,” IETF RFC 3945 (2004), http://tools.ietf.org/html/rfc3945 .
A. Farrel, “A unified control plane: dream or pipedream,” presented at the 6th International Conference on IP + Optical Network (IPOP 2010), Tokyo, Japan, 10–11 Jun., 2010. http://www.pilab.jp/ipop2010/info/onlineproceedings.html .
“The OpenFlow switch consortium,” http://www.openflow.org/ .
S. Das, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and L. Ong, “Packet and circuit network convergence with OpenFlow,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG1. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG1 .
V. Gudla, S. Das, A. Shastri, G. Parulkar, N. McKeown, L. Kazovsky, and S. Yamashita, “Experimental demonstration of OpenFlow control of packet and circuit switches,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG2 .
S. Das, Y. Yiakoumis, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and P. D. Desai, “Application-aware aggregation and traffic engineering in a converged packet-circuit network,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper NThD3. http://www.opticsinfobase.org/abstract.cfm?URI=NFOEC-2011-NThD3 .
S. Das, A. R. Sharafat, G. Parulkar, and N. McKeown, “MPLS with a simple OPEN control plane,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper OWP2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2011-OWP2 .
“NOX: an OpenFlow controller,” http://noxrepo.org/wp/ .
L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “OpenFlow-based wavelength path control in transparent optical networks: a proof-of-concept demonstration,” in 37th European Conference and Exhibition on Optical Communications (ECOC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper Tu.5.K.2. http://www.opticsinfobase.org/abstract.cfm?URI=ECOC-2011-Tu.5.K.2 .

Other

E. Mannie, ed., “Generalized multi-protocol label switching (GMPLS) architecture,” IETF RFC 3945 (2004), http://tools.ietf.org/html/rfc3945 .
A. Farrel, “A unified control plane: dream or pipedream,” presented at the 6th International Conference on IP + Optical Network (IPOP 2010), Tokyo, Japan, 10–11 Jun., 2010. http://www.pilab.jp/ipop2010/info/onlineproceedings.html .
“The OpenFlow switch consortium,” http://www.openflow.org/ .
S. Das, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and L. Ong, “Packet and circuit network convergence with OpenFlow,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG1. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG1 .
V. Gudla, S. Das, A. Shastri, G. Parulkar, N. McKeown, L. Kazovsky, and S. Yamashita, “Experimental demonstration of OpenFlow control of packet and circuit switches,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2010), Technical Digest (CD) (Optical Society of America, 2010), paper OTuG2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2010-OTuG2 .
S. Das, Y. Yiakoumis, G. Parulkar, N. McKeown, P. Singh, D. Getachew, and P. D. Desai, “Application-aware aggregation and traffic engineering in a converged packet-circuit network,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper NThD3. http://www.opticsinfobase.org/abstract.cfm?URI=NFOEC-2011-NThD3 .
S. Das, A. R. Sharafat, G. Parulkar, and N. McKeown, “MPLS with a simple OPEN control plane,” in Optical Fiber Communication Conference and Exposition and National Fiber Optic Engineers Conference (OFC/NFOEC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper OWP2. http://www.opticsinfobase.org/abstract.cfm?URI=OFC-2011-OWP2 .
“NOX: an OpenFlow controller,” http://noxrepo.org/wp/ .
L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “OpenFlow-based wavelength path control in transparent optical networks: a proof-of-concept demonstration,” in 37th European Conference and Exhibition on Optical Communications (ECOC 2011), Technical Digest (CD) (Optical Society of America, 2011), paper Tu.5.K.2. http://www.opticsinfobase.org/abstract.cfm?URI=ECOC-2011-Tu.5.K.2 .

Cited By

Alert me when this paper is cited

OSA is able to provide readers links to articles that cite this paper by participating in CrossRef's Cited-By Linking service. CrossRef includes content from more than 3000 publishers and societies. In addition to listing OSA journal articles that cite this paper, citing articles from other participating publishers will also be listed.

Click here to see a list of articles that cite this paper

Figures


Fig. 1	Fig. 2	Fig. 3


Fig. 4	Fig. 5	Fig. 6


Fig. 7	Fig. 8	Fig. 9


Fig. 10	Fig. 11	Fig. 12


Fig. 13	Fig. 14	Fig. 15