Satoru OKAMOTO†††, and Naoaki YAMANAKA†††, Fellows
SUMMARY Software defined networking (SDN) and OpenFlow, whichenables the abstraction of vendor/technology-specific attributes, improve thecontrol and management flexibility of optical transport networks. In this pa-per, we present an interoperability demonstration of SDN/OpenFlow-basedoptical path control for multi-domain/multi-technology optical transportnetworks. We also summarize the abstraction approaches proposed formulti-technology network integration at SDN controllers.key words: software defined networking (SDN), OpenFlow, multi-domainand multi-technology optical transport networks
1. Introduction
The latest innovations in optical networking technologiesprovide not only high-capacity connectivity but also im-proved network control and management flexibility for core,metro, and access networks. For core networks, ma-jor telecommunication vendors are already shipping opti-cal transport systems equipped with 100 Gbit/s coherenttransponders and reconfigurable color-less, direction-less,and contention-less (CDC) optical add/drop multiplexers(ROADMs), which enable the remote reconfiguration of thenetwork topology and provisioning of the optical paths [1].For metro and access networks, optical packet switching(OPS) [2] and an elastic optical network [3], [4] that enablesefficient network resource utilization are being actively dis-cussed.
With the recent large growth in traffic and demand formore efficient, flexible networks, introducing the softwaredefined networking (SDN) concept to optical transport net-works remains essential. SDN is a most promising tech-nology and has attracted considerable interest from both theresearch and industrial communities due to the cost and com-plexity of managing the network infrastructure. SDN decou-
Manuscript received September 15, 2015.Manuscript revised March 6, 2016.†The authors are with Mitsubishi Electric Corporation,
Kamakura-shi, 247-8501 Japan.††The authors are with KDDI R&D Laboratories, Fujimino-shi,
356-8502 Japan.†††The authors are with Graduate School of Science and Tech-
nology, Keio University, Yokohama-shi, 223-8522 Japan.††††The authors are with National Institute of Information and
ples the network control and forwarding functions, and en-ables the network control to become directly programmable,and the underlying infrastructure to be abstracted. Open-Flow [5], which is standardized by the Open NetworkingFoundation (ONF), is a de facto open equipment controlprotocol. In fact, OpenFlow-enabled SDN solutions havebeen commercially deployed in both data center networksand enterprise networks [6]. Intensive investigations haveaimed at moving the SDN/OpenFlow concept out from datacenter networks to optical transport networks. For exam-ple, [7] reports an OpenFlow-based unified control planearchitecture for multi-layer/multi-granularity optical switch-ing networks, and demonstrates its performance. An ex-periment conducted in an environment including adaptiveerbium-doped fiber Raman amplifiers, multi-degree Super-channel transponders, and flexible grid switching nodes hasalso been reported [8]. In addition, prototypes of transportSDN technologies (e.g. OpenFlow extension, prototypes ofcontroller northbound interfaces) are being actively demon-strated [9].
One of the most effective uses of SDN-based transportnetwork control is datacenter interconnection [10]. With thepopularization of cloud computing and datacenters, there isa growing demand for datacenter interconnection, as well asa need to dynamically establish high-volume transmissionpipes through multiple optical network domains.
However, certain difficulties inhibit practical use ofSDN-based transport network control. In multi-domain op-tical transport networks, vendor and technology-specific at-tributes such as switching capability, physical layer con-straints, accessibility of optical paths, the fault isolation pro-cess, and switching time have to be considered during pathprovisioning. These attributes should be abstracted so thatan SDN controller can uniformly manage multi-technologyoptical transport networks. In this paper, we present an inter-operability demonstration of SDN/OpenFlow-based opticalpath control for multi-technology optical transport networkscomprised of elastic lambda aggregation networks, 100Gbit/s optical packet and circuit integrated (OPCI) networks,and 100 Gbit/s wavelength division multiplex (WDM) net-works. We also summarize the abstraction approaches pro-posed to date for multi-technology network integration at anSDN controller.
GAO et al.: DEMONSTRATION OF SDN/OPENFLOW-BASED PATH CONTROL1493
In several related SDN controller/orchestrator platformssuch as ODENOS [11] and OpenDaylight [12], dedicatedmodules (e.g. packet module, OpenFlow module, VLANmodule and so forth) corresponding to each technology areplugged in to orchestrate the multi-technology network. Dif-ferently to these approaches, a unified control approach [7] isused in this paper. It reduces the complexities of preparingplug-in modules for the SDN controllers/orchestrators. Inthis approach, the SDN controller controls several networkcontrollers using a unified control protocol (e.g. OpenFlow).The network controllers of each technology domain are ex-panded to act as SDN adaptors for unified protocol termi-nation and protocol conversion between the unified protocoland the domain-specific protocols. The SDN controller doesnot need to have modules added to handle other protocolsand thus can control the entire network via a unified pro-tocol. Therefore, this approach leads to a reduction in thecomplexity of constructing an SDN controller/orchestrator.
The rest of this paper is organized as follows. In Sect. 2,we present details of the abstraction approaches. Section 3introduces the experimental setup and reports the experi-mental results, while Sect. 4 summarizes additional issuesfor future investigation. Finally, Sect. 5 establishes the di-rection of our future work and concludes this paper.
2. Network Architecture and Abstraction Approaches
2.1 SDN Controlled Multi-Technology Transport Network
a) SDN controllerFigure 1 shows the architecture of an SDN-controlled
multi-technology transport network. The network comprisesmulti-domain and multi-technology networks and data cen-ters, the whole coordinated by an SDN controller whichcontrols the southbound network controllers by using theOpenFlow protocol. With the SDN controller and the net-work controllers working in co-operation, flexible controlover the multiple networks based on data center requests canbe achieved. The network controllers abstract and partitionthe resources of the network elements including ports, linksand available bandwidths, and supply the information to theSDN controller so that the SDN controller can have knowl-edge of the network topology and the available resources.Only the abstracted network topology is presented to theSDN controller in order to improve the scalability. Each net-work domain is configured autonomously by its own networkcontroller. When a connection request is sent to the SDNcontroller from a data center, the SDN controller performsend-to-end path computation based on the abstracted topol-ogy, and informs each network domain of the results. Eachnetwork controller then computes the path and resource al-location within its own domain. After all the networks havecompleted their configuration work, end-to-end transmissionis established.b) Flowvisor
With the introduction of a Flowvisor [13] between theSDN controller and a network element such as a network
Fig. 1 Architecture of SDN-controlled multi-technology transport net-work.
controller and its associated network equipment, it is pos-sible to create multiple slices for management by separateSDN controllers. A Flowvisor can enforce isolation betweenthe slices. Slices can be defined by any combination of pa-rameters such as switch ports, source/destination addresses,etc. In this architecture, each access/metro/core network do-main is virtualized and autonomously configured by its ownnetwork controller and further sliced by the Flowvisor.
2.2 Core Network/WDM Network
The role of a core network is to provide high-capacity, long-haul connections between metro networks. Based on theconcept of “loosely coupled orchestration”, the core networkis designed to provide an abstracted point-to-point path ondemand.
Figure 2 shows a conceptual system designed arounda WDM network. Each WDM network element (NE) isequipped with 100 Gbit/s optical transceivers with digitalsignal processing (DSP) [14] technology, and an opticalcross-connect switch (OXC) with CDC [15] capability. TheNEs are connected to each another in a mesh topology, andthe transceivers and OXCs of the system are configured toform an optical path on request. Thanks to the CDC ca-pability of the OXCs and the DSP in the transceivers, anend-to-end optical path can be established on demand, with-out reconfiguring patch cords, installing dispersion compen-sation fibers, etc. As a result, the network behaves as amonolithic circuit switch. While not discussed here, an NEcan be equipped with sub-lambda switches, or with elasticoptical network [3] functions. Such equipment can providegranular circuit capacity or multi-layered functions tradedoff against increasing path management complexity.
The SDN controller is the centralized control plane fora set of multi-domain/multi-technology networks which in-corporate large scale WDM networks. The current SDNtechnology is designed to control the L2/L3 network of adata center. However, the control and optimization of aWDM network is more complex. Also, the required re-source control capacity becomes a big challenge for the SDNcontroller. Therefore, we expand the network managementsystem (NMS) of the WDM network to act as an adap-tor to support the SDN controller in controlling the multi-domain/multi-technology networks. The NMS is designedwith vendor-specific attributes such as the fault isolation pro-
1494IEICE TRANS. COMMUN., VOL.E99–B, NO.7 JULY 2016
Fig. 2 SDN/OpenFlow-based WDM network control architecture.
Fig. 3 The functional blocks of the NMS cum SDN adaptor.
cess, accessibility of wavelength paths, and switching timetaken into account during the path provisioning and restora-tion processes. All these attributes should be abstracted bythe NMS so that the SDN controller described in Fig. 1 canuniformly manage multi-domain/multi-technology networkswithout any need to deal with vendor-specific attributes.
We incorporate the SDN adaptor in a conventional NMSto take advantage of the existing system. The function blocksof the SDN adaptor and the NMS are shown in Fig. 3. TheSDN adaptor updates the abstracted WDM network for theSDN controller and receives control messages from the SDNcontroller via an open interface. Then the PCE calculates theoptimal path based on the converted control messages, andthe equipment management function sends path provisioningcommands to the ingress NE via the NE interface. Theingress NE uses distributed path control such as GMPLS-based RSVP-TE signaling to establish the optical paths [16].
There are three functions in the SDN adaptor: the northbound interface (NBI) termination function, the network ab-straction function and the protocol conversion function.a) NBI Termination function
The NBI termination function supports standardized
northbound interfaces such as Multi-Technology NetworkManagement (MTNM) [17], Multi-Technology OperationsSystems Interface (MTOSI) [18] or OpenFlow for interfacingwith a higher level management system. The SDN adaptorcan act as an OpenFlow agent (OFA) in this experiment.b) Network Abstraction function
The originality of our SDN adaptor lies in the abstrac-tion mechanism: it abstracts the entire WDM network to anL2 switch. The SDN adaptor sends the L2 switch configura-tion to the SDN controller via the NBI termination function.Therefore, the SDN controller can control the WDM networkas a layer-2 (L2) network, without considering any opticalparameters during path provisioning.
This function provides the abstraction mechanism formapping the physical resources of the WDM network to theabstracted resources. In the abstraction mechanism, inter-mediate nodes in the WDM network are omitted and onlyedge nodes are taken into consideration. The client ports ofthe edge nodes are abstracted as the ports of the L2 switch.We use a resource mapping table to manage the abstractedresources. This table shows the correspondence betweeneach port of the abstracted L2 switch and its correspondingclient port in the edge node.
The network abstraction function also holds an opti-cal path table to update the port state of the abstracted L2switch. The current optical path and state of the ports of theabstracted L2 switch are maintained in this table. If there isno optical path between two ports of an edge node, the stateof the corresponding two ports in the abstracted L2 switch is“idle”. If an optical path is set up between these two ports,the state of the two corresponding ports in the abstracted L2switch is changed to “used”. If the optical path goes down,the two corresponding ports will be deleted from this tableand from the abstracted L2 switch.c) Protocol Conversion function
All the SDN control messages are translated to vendor-specific messages in the protocol conversion block. The pro-tocol conversion function extracts the numbers of input andoutput ports. Depending on these numbers, vendor-specificparameters such as wavelength numbers and transpondernumbers are established based on the NE database of theNetwork management function and the optical path man-agement function. For example, the protocol conversionfunction extracts port numbers from the Flow_Mod messageof OpenFlow. It then finds the corresponding transponderin the NE and an available wavelength. Finally, it createsvendor-specific commands based on these parameters.
2.3 Metro Network/Optical Packet and Circuit IntegratedNetwork
We apply an OPCI network [19], [20] to a metro networkinfrastructure because this network provides both high-speeddata transfer and bandwidth-guaranteed data transfer, whichsuits it to providing diversified services to users. The networkseparates the wavelength bandwidth into OPS and opticalcircuit switching (OCS) resources, and dynamically moves
GAO et al.: DEMONSTRATION OF SDN/OPENFLOW-BASED PATH CONTROL1495
Fig. 4 Interworking between SDN and OPCI network controllers.
the boundary between those resources depending on serviceusage.
In order to effectively transfer a large number of traf-fic flows from SDN-based networks to the OPCI network,interworking between both types of network is desirable,which interworking has been demonstrated experimentally[21], [22]. Figure 4 illustrates this interworking. Trafficflows requiring a high quality of service (QoS) can be trans-ferred on OCS links, while others are transferred on high-capacity OPS links. The SDN controller specifies flexiblyhow to transport each flow’s data on the OPCI network,which includes the switching method, the preferred routefor the packets and the wavelength of the optical path. InFig. 4, Flow 1 is associated with OCS and a wavelength pathis established between Node 1 and Node 2. Flow 2 is as-sociated with OPS and a route for OPS is configured. TheSDN controller controls the OPS systems via an OFA whileit sends control request to the OCS control plane directly.The OFA serves as the SDN adapter and provides protocolconversion function for interworking between the SDN con-troller and OPS control systems. The OFA converts eachreceived OpenFlow message to OPS control message. Weexplain the interworking in more detail below.a) Interworking between SDN (OpenFlow) and OCS
The OPCI network uses distributed path control forOCS signaling and routing [19], while OpenFlow is basedon centralized control. Hence, we need an interworkingfunction to go between OpenFlow and OCS [21]. Each flowentry in an OpenFlow network is flexibly associated with apath. That is, simply by designating a destination IP address,a path is established on the preferred wavelength and route.b) OPS system in the OPCI network
Figure 5 illustrates the OPS system. The OPS controlincludes header processing, switching and buffer scheduling[20]. The optical packet transponder has a Label MappingTable (LMT) which associates label IDs with values in theheader field of the 10 Gbit/s Ethernet (10GE) frame, adds alabel ID to the 10GE frame, and converts it to a 100 Gbit/scolored optical packet. The destination IP addresses of theincoming 10GE frames are employed for the label mappingprocess. The header processor has a Switching Table (ST)that associates label IDs with output ports of the opticalpacket switch, and each incoming optical packet is trans-
Fig. 5 OPS system in an OPCI node.
Fig. 6 Interworking between SDN and OPS.
ferred to the corresponding output port. The OPS systemsin multiple OPCI nodes can be collectively controlled fromjust one SDN controller [19], [22].c) Interworking between SDN and OPS
Figure 6 illustrates interworking between SDN (Open-Flow) and OPS. The SDN control part consists of the SDNcontroller and Flowvisor as discussed in 2.1. When theSDN controller receives a Packet_In message, it calculatesthe route and assigns a label ID to the packets in the sameflow. The Flowvisor can virtualize multiple flows’ data foreach destination IP address by associating it with OPS labelIDs. The SDN controller sends requests to the OFAs to addand delete entries in the LMTs and STs via the OpenFlowprotocol as Flowtable modification (Flow_Mod) messages[22].
Since the OPS system does not yet support OpenFlow,the OFAs translate the messages into proprietary OPS com-mands and send them to Nodes 1 and 2. Each node thenconfigures its LMT and ST in accordance with these com-mands.
The Elastic Lambda Aggregation Network (EλAN) has beenpresented as an access/aggregation integrated network [23]–[26]. In EλAN, different varieties of network services thathave different protocols and QoS requirements are supportedby introducing programmable optical line terminals and op-tical network units (P-OLT, P-ONU) [4] and access paths
1496IEICE TRANS. COMMUN., VOL.E99–B, NO.7 JULY 2016
Fig. 7 EλAN architecture and unified control model.
that have flexible bandwidths.a) EλAN Architecture
Figure 7 shows the architecture of the EλAN. The vir-tual layer-2 network (VL2NW) connects the metropolitanarea network and the P-OLTs. The VL2NW transfers thedata frames of multiple network services to and from theappropriate P-OLTs. The P-OLTs and P-ONUs respectivelyconfigure logical OLTs and logical ONUs (L-OLT, L-ONU).The L-OLTs and L-ONUs provide the medium access con-trol (MAC) and physical layer (PHY) functions required foreach network service, such as frame processing, time syn-chronization, Multipoint Control Protocol (MPCP), dynamicbandwidth allocation (DBA), rate adaptation, and forwarderror correction (FEC) coding. Access paths are config-ured on the optical distribution network (ODN), which con-sists of all-optical devices such as wavelength cross connects(WXCs), optical splitters, and optical amplifiers. The EλANNMS (access NMS) performs as a SDN adapter. It providesnetwork abstraction function, EλAN control function, andEλAN configuration function. The EλAN NMS abstractsthe internal architecture of the EλAN to an L2 switch. Ac-cording to OpenFlow messages from the SDN controller,the EλAN NMS controls the VL2NW, the P-OLTs, and theODN. In detail, the EλAN NMS computes the route of theaccess path in the EλAN domain and reconfigures devicesthat compose the VL2NW and the ODN. The EλAN NMSalso manages the P-OLTs to configure the L-OLTs in appro-priate position.b) SDN based control implementation
We implemented the unified EλAN control model [26]in the interoperability demonstration. In this control model,the NMS abstracts the detailed internal architecture of theEλAN to reduce the complexity of computing end-to-endoptical paths for the integrated SDN control system. Onlythe network-network interface (NNI) of the VL2NW and theuser-network interfaces (UNI) of the P-ONUs are visible tothe integrated SDN control system.
In this implementation, OpenFlow 1.0 is used to con-trol multi-layer devices from the EλAN NMS. The VL2NWconsists of a generic layer-2 switch with OFA that translatesOpenFlow messages to device-specific commands. The P-OLTs and P-ONUs are implemented on generic Linux-basedservers. Simple MAC functions for the L-OLTs are real-
ized by C programs running on virtual machines. The ODNconsists of optical circuit switches with OFAs.
The operation of the demonstration is described below.The integrated control system sends Flow_Mod (add) mes-sages to the EλAN NMS when the system establishes anoptical path. The messages identify the interfaces (NNI andUNI) at which the optical path is to be established and a ser-vice type (e.g., virtual local area network (VLAN) ID). TheNMS that receives the messages calculates the placementof the L-OLTs and the routing and wavelength allocationof the access paths in the ODN. The NMS then directs theVL2NW and the optical devices in the ODN to establish theoptical path by sending further OpenFlow messages. TheOFAs translate the messages and configure the devices. Atthe same time, the NMS also directs a P-OLT to generatean L-OLT. As a result, the system establishes an end-to-endoptical path without considering the detailed internal archi-tecture of the EλAN and sending OpenFlow messages to allthe devices. The integrated control system sends Flow_Mod(delete_strict) messages to the EλAN NMS when the systemreleases an optical path.
3. Experiments and Results
To demonstrate SDN/OpenFlow-based end-to-end path con-trol for a multi-domain/multi-technology optical transportnetwork, we set up an experimental network test bed asshown in Fig. 8. Two SDN controllers are used to controlthe entire network via the Flowvisor. In this demonstration,SDN Controller #1 establishes the end-to-end path betweenthe GbE Testers and SDN Controller #2 establishes the end-to-end path between the 10GbE Testers. The experimentalnetwork consists of three different domains: a WDM corenetwork domain (C), OPCI metro network domains (B andD), and EλAN access network domains (A and E). The corenetwork domain (C) comprises two WDM nodes and anNMS with an SDN adaptor. Each node is equipped witha 2-degree ROADM and 100 Gbit/s optical transponders toprovide a 100 Gbit/s wavelength transmission pipe for the at-tached metro networks. The OPCI metro networks are ringscomprising two OPCI nodes with OFAs. The OPCI metronetwork domains (B) and (D) provide one 100 Gbit/s opti-cal packet transmission pipe and two 10 Gbit/s transmissionpipes for the attached datacenters emulated respectively by10GE traffic testers and client networks. The access net-works are constructed from EλANs and associated NMSs asdiscussed in 2.4. Data centers emulated by 1 Gbit/s Ether-net (GbE) traffic testers with OpenFlow protocol emulationfunctions are connected to the P-ONUs in each EλAN.
In the control plane, the SDN controllers were con-nected to the WDM NMS, all the OPCI nodes with OFAs inthe metro networks, and all the EλAN NMSs. As an NBI,several remote control protocols such as REST [27] andNETCONF [28] are also discussed. All the contributors tothis demonstration are implementing OpenFlow in their pro-totypes, and some can support REST and NETCONF. SinceOpenFlow is standardized for control of the traffic flow, we
GAO et al.: DEMONSTRATION OF SDN/OPENFLOW-BASED PATH CONTROL1497
Fig. 8 Experimental setup.
Fig. 9 OpenFlow sequence diagram and abstracted topology.
decided that OpenFlow is the most suitable approach to pathprovisioning in this demonstration.
The OpenFlow used in this experiment was specifica-tion 1.0 without technology-specific extension for underlyingnetworks. Later versions of OpenFlow are extended to sup-port optical networks. In our approach, the optical networkand other-technology networks are abstracted to the L2 net-work. No optical network parameters such as wavelengthneed to be considered when provisioning end-to-end paths.Therefore, we could use OpenFlow ver.1.0, which is notextended for the optical layer, in this demonstration.
We verified end-to-end path provisioning across thecore, metro and access networks. Figure 9(a) shows theOpenFlow signaling sequence for setting up an end-to-end path in the multi-domain network. We observed that,once the SDN Controller receives a connection request (aPacket_In message from a Tester), it calculates a route basedon an abstracted network topology. Figure 9(b) illustratesthe abstracted network topology as managed at the SDNController. EλAN access network domains (A and E) andcore network domain (C) are respectively abstracted as vir-tual L2 switches. After calculating the end-to-end route, theSDN Controller sends Flow_Mod messages to establish theoptical paths. In the access and core domains, the EλANNMSs and the WDM NMS terminate the Flow_Mod mes-sages. Instead of the SDN Controller, the EλAN NMSs andthe WDM NMS handle the path provisioning by controlling
Fig. 10 Wireshark capture of the Flow_Mod messages for setting up a100 Gbit/s wavelength path.
the equipment in each domain under their control to abstractthe technology-specific approach. Figure 10 shows the Wire-shark [29] capture of the Flow_Mod messages for setting upa 100 Gbit/s wavelength path.
Since OpenFlow is designed to set up uni-directionalflows, the SDN controller sent two Flow_Mod messages tosignal bi-directional wavelength paths. On receipt of theFlow_Mod messages, the WDM NMS initiated a vendor-specific signaling procedure. We confirmed that GMPLS-based RSVP-TE signaling messages were transmitted be-tween ROADM#1 and ROADM#2 via an internal data com-munication network on the optical supervisory channels, andthat the 100 Gbit/s wavelength path was activated success-fully.
In the metro networks, the OPCI nodes (OPCI#1,OPCI#2, OPCI#3, and OPCI#4) are controlled directly bythe SDN controller via the OFAs. OPCI#1 and OPCI#4 donot send Packet_In messages to the SDN controller. Settingup the path in the OPCI network is also triggered by theleftmost Packet_In in Fig. 9, which is sent from the tester.Based on this Packet_In message, the route of the opticalpackets in the OPCI network and the label ID are decided.Note that, in this experiment, we split one physical OPCInode virtually into four logical nodes by logically dividingmultiple input/output ports. The OFAs successfully updatedthe LMTs for adding the label-ID associated with the desti-
1498IEICE TRANS. COMMUN., VOL.E99–B, NO.7 JULY 2016
Fig. 11 Spectrum waveform for 100 Gbit/s optical packets.
nation IP address to each incoming 10GE frame. The OFAsalso updated the STs for transferring each optical packet tothe corresponding output port of the optical packet switchon the basis of the label-ID. In this way, an optical packetpath capable of up to 100 Gbit/s of bandwidth-shared datatransfers can be established by the proper configuration com-mands from the SDN controller. Due to equipment resourceconstraints, we did not prepare an experimental environmentfor wavelength path setup from the SDN controller. In otherwords, in this experiment, the SDN controller did not sendFlow_Mod messages to OPCI#3 and OPCI#4 because weestablished wavelength paths in advance. Note that we haveexperimentally demonstrated wavelength path setup from anSDN controller in another project [21].
Figure 11 shows the spectra of 10-wavelength100 Gbit/s optical packets. The left-hand and right-handfigures are respectively the spectra before and during datatransmission. As we can see in the right-hand figure, flatgain can be maintained over the target wavelength range dueto the burst-mode erbium-doped fiber amplifiers installed inthe OPCI nodes [20].
4. Additional Issues for Future Investigation
For the future deployment of multi-technology optical net-work management using the SDN/OpenFlow approach,some additional issues may have to be considered.
We will be required to deal with how to manage faults inan abstracted network because the relationship between thereal network and the abstracted network would not be unique.In addition, although CDC OXC-based DWDM is useful forSDN, it is difficult to localize a fault in a transparent opticalnetwork using CDC OXC-based DWDM because there is notermination of the optical signal.
In an OPCI metro network, we will be required to dealwith how to transfer each traffic flow’s data from the edgenetworks (e.g. SDN-based access, data center or LAN) tothe OPS or OCS links on the basis of information such asend-hosts’ QoS requirements, resource usage, the degree ofcongestion in the OPCI network and the traffic situation inthe edge networks.
In the access network, we have proposed L-OLT mi-gration to achieve more flexible utilization of the network
resources in the EλAN project [24], [30]. In the procedurefor L-OLT migration, an L-OLT is moved from one P-OLTto another P-OLT as a virtual machine. As a result, the P-ONUs continues to receive the same service via the otherP-OLT. By implementing L-OLT migration, we expect someadvantages such as energy saving, load balancing betweenP-OLTs, and improved fault tolerance. In the interoperabilitydemonstration, L-OLT migration was not implemented dueto the suspension of communication that L-OLT migrationcauses.
In the unified EλAN control model, the EλAN NMSwas able to execute L-OLT migration independently since theintegrated control system is not concerned with the detailsof the internal architecture of the EλAN. However, over-long suspension of communication will cause degradation ofthe end-to-end service quality. We will continue to discussimprovement of the L-OLT migration procedure to minimizethe period of suspension.
5. Conclusions
In this paper, we present an interoperability demonstration ofOpenFlow-based end-to-end optical path control for multi-domain/multi-technology optical transport networks. Weapply abstraction approach for handling different switchingcapabilities, and we experimentally verify OpenFlow-baseddynamic path provisioning across EλAN access networks,100 Gbit/s OPCI metro networks, and a 100 Gbit/s WDMnetwork.
We also summarize the additional issues for the fu-ture deployment of multi-technology optical network man-agement. We believe that the study presented in this pa-per will benefit the ongoing SDN/OpenFlow standardizationactivities and facilitate the commercial deployment of theSDN/OpenFlow-based unified control plane in the near fu-ture.
Acknowledgments
This work was partly supported by the STRAUSS Project,the R&D on “Digital Coherent Optical Transceiver Tech-nologies” and “High-speed Optical Transport System Tech-nologies” of the Ministry of Internal Affairs and Commu-nications (MIC) of Japan, “Research and Development of
GAO et al.: DEMONSTRATION OF SDN/OPENFLOW-BASED PATH CONTROL1499
Elastic Optical Aggregation Network,” the commissionedresearch of the National Institute of Information and Com-munications Technology (NICT), and Grant-in-Aid from theJapan Society for the Promotion of Science (JSPS) Fellows,grant number 246849.
The authors also would like to thank the Keihanna In-teroperability Project for providing facilities and giving in-sightful comments.
References
[1] Mitsubishi Electric 100 Gbps Transmission System Solutions, http://www.mitsubishielectric.com/bu/communication/wdm/index.html
[2] S. Shinada, H. Furukawa, and N. Wada, “Huge capacity opti-cal packet switching and buffering,” Opt. Express, vol.19, no.26,pp.B406–B414, Nov. 2011.
[3] M. Jinno, H. Takara, B. Kozicki, Y. Tsukishima, Y. Sone, and S.Matsuoka, “Spectrum-efficient and scalable elastic optical path net-work: architecture, benefits, and enabling technologies,” IEEE Com-mun. Mag., vol.47, no.11, pp.66–73, Nov. 2009.
[4] H. Ikeda, H. Takeshita, and S. Okamoto, “Future service adaptiveaccess/aggregation network architecture,” IEICE Trans. Commun.,vol.E95-B, no.3, pp.696–705, March 2012.
[5] The OpenFlow switch consortium, http://www.openflow.org/[6] S. Jain, M. Zhu, J. Zolla, U. Hölzle, S. Stuart, A. Vahdat, A. Kumar, S.
Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, andJ. Zhou, “B4: Experience with a globally-deployed software definedwan,” Proc. ACM SIGCOMM 2013 Conference on SIGCOMM,SIGCOMM’13, pp.3–14, 2013.
[7] L. Liu, D. Zhang, T. Tsuritani, R. Vilalta, R. Casellas, L. Hong, I.Morita, H. Guo, J. Wu, R. Martínez, and R. Muñoz, “Field trial of anOpenFlow-based unified control plane for multilayer multigranular-ity optical switching networks,” J. Lightwave Technol., vol.31, no.4,pp.506–514, Feb. 2013.
[8] P.N. Ji, T.J. Xia, J. Hu, M.-F. Huang, Y. Aono, T. Tajima, G.A.Wellbrock, and T. Wang, “Demonstration of OpenFlow-enabled traf-fic and network adaptive transport SDN,” Optical Fiber Communi-cation Conference, W2A.20, 2014.
[9] OIF/ONF white paper, “Global Transport SDN Prototype Demon-stration,” Oct. 7, 2014.
[10] Open Networking Foundation, Optical Transport Use cases, https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/optical-transport-use-cases.pdf
[11] ODENOS, https://github.com/o3project/odenos[12] OpenDayLight, http://www.opendaylight.org/[13] https://github.com/OPENNETWORKINGLAB/flowvisor/wiki[14] E. Yamazaki, S. Yamanaka, Y. Kisaka, T. Nakagawa, K. Murata,
E. Yoshida, T. Sakano, M. Tomizawa, Y. Miyamoto, S. Matsuoka,J. Matsui, A. Shibayama, J.-I. Abe, Y. Nakamura, H. Noguchi, K.Fukuchi, H. Onaka, K. Fukumitsu, K. Komaki, O. Takeuchi, Y.Sakamoto, H. Nakashima, T. Mizuochi, K. Kubo, Y. Miyata, H.Nishimoto, S. Hirano, and K. Onohara, “Fast optical channel recov-ery in field demonstration of 100-Gbit/s Ethernet over OTN usingreal-time DSP,” Opt. Express, vol.19, no.14, pp.13179–13184, July2011.
[15] S. Gringeri, B. Basch, V. Shukla, R. Egorov, and T.J. Xia, “Flex-ible architectures for optical transport nodes and networks,” IEEECommun. Mag., vol.48, no.7, pp.40–50, July 2010.
[16] L. Liu, T. Tsuritani, I. Nishioka, S. Huang, S. Yoshida, K. Kubo,and R. Hayashi, “Experimental demonstration of highly resilientwavelength-switched optical networks with a multivendor interop-erable GMPLS control plane,” J. Lightwave Technol., vol.30, no.5,pp.704–712, March 2012.
[17] “Multi-technology network management: CORBA IDL solution set(TMF814) with implementation statement templates and guidelines
(TMF814A),” ITU-T Recommendation M.3170.3, March 2007.[18] Multi-Technology Operation Support interface (MTOSI) Extensible
Markup Language (XML) Solution Set, TM Forum, TMF854, 2005.[19] H. Harai, H. Furukawa, K. Fujikawa, T. Miyazawa, and N. Wada,
“Optical packet and circuit integrated networks and software de-fined networking extension,” J. Lightwave Technol., vol.32, no.16,pp.2751–2759, Aug. 2014.
[20] H. Furukawa, S. Shinada, T. Miyazawa, H. Harai, W. Kawasaki,T. Saito, K. Matsunaga, T. Toyozumi, and N. Wada, “A multi-ringoptical packet and circuit integrated network with optical buffering,”Opt. Express, vol.20, no.27, pp.28764–28771, Dec. 2012.
[21] T. Miyazawa, H. Furukawa, N. Wada, H. Harai, H. Otsuki, andE. Kawai, “Experimental demonstrations of interworking betweenan optical packet and circuit integrated network and OpenFlow-based networks,” 2013 IEEE Globecom Workshops (GC Wkshps),pp.1210–1215, 2013.
[22] X. Cao, N. Yoshikane, T. Tsuritani, I. Morita, T. Miyazawa, andN. Wada, “Openflow-controlled optical packet switching networkwith advanced handling of network dynamics,” 2014 The EuropeanConference on Optical Communication (ECOC), pp.1–3, 2014.
[23] Y. Higuchi, Y. Shimada, T. Sato, S. Okamoto, and N. Yamanaka,“OpenFlow-based multi-layer service adaptation control method inelastic lambda aggregation network (EλAN),” 9th International Con-ference on IP+Optical Network (iPOP2013), T3-2, May 2013.
[24] T. Sato, K. Tokuhashi, H. Takeshita, S. Okamoto, and N. Yamanaka,“A study on network control method in elastic lambda aggregationnetwork (EλAN),” 2013 IEEE 14th International Conference on HighPerformance Switching and Routing (HPSR), pp.29–34, 2013.
[25] S. Kimura, “Elastic lambda aggregation network (EλAN) —Proposal for future optical access network —,” 18th OptoElectronicsand Communications Conference (OECC 2013), WP4-4, July 2013.
[26] T. Yamaguchi, T. Sato, H. Takeshita, S. Okamoto, and N. Yamanaka,“Experimental report of elastic lambda aggregation network (EλAN)control method for SDN-based carrier class network,” 2014 12thInternational Conference on Optical Internet 2014 (COIN), pp.1–2,2014.
[27] W. Zhou, L. Li, and W. Chou, “SDN northbound REST API with effi-cient caches,” 2014 IEEE International Conference on Web Services,pp.257–264, 2014.
[28] NETCONF, https://tools.ietf.org/html/rfc6241[29] Wireshark, http://www.wireshark.org/[30] T. Sato, Y. Higuchi, S. Okamoto, N. Yamanaka, and E. Oki, “Log-
Shan Gao joined Mitsubishi Electric Cor-poration, Kamakura, Japan in 2013. He hasbeen engaged in research and development ofoptical long-haul transmission systems utilizingwavelength- division multiplexing transmission,and software defined transmission networkingand network virtualization.
1500IEICE TRANS. COMMUN., VOL.E99–B, NO.7 JULY 2016
Xiaoyuan Cao joined KDDI R&D Labora-tories in 2013. He has been engaged in researchon optical communication and networking, opti-cal burst and packet switching, Software-DefinedNetworking and network virtualization.
Takehiro Sato received his B.E. and M.E.degrees from Keio University, Japan, in 2010and 2011, respectively. He is currently work-ing toward his Ph.D. degree at the GraduateSchool of Science and Technology, Keio Uni-versity, Japan. His research interests includecommunication protocols and network architec-tures for the next generation optical network. Hewas a research fellow of the Japan Society forthe Promotion of Science from 2012 to 2015.
Takaya Miyazawa received his B.E., M.E.,and Ph.D. degrees in information and computerscience from Keio University, Yokohama, Japan,in 2002, 2004, and 2006, respectively. He isnow a senior researcher at NICT, Tokyo, Japan.His research interests include optical networkarchitecture.
Sota Yoshida received his B.E. and M.E.degrees in information engineering from NiigataUniversity, Niigata, Japan in 2003 and 2005 re-spectively. In 2005, he joined Mitsubishi Elec-tric Corporation, Kamakura, Japan, where he hasbeen engaged in the research and development ofoptical networking systems.
Noboru Yoshikane joined KDD (currentlyKDDI Corporation), Japan in 1999, and since2001 has been working at KDDI R&D Labo-ratories. He has been engaged in research onthe design of submarine cable systems, highlyspectrally efficient optical communication sys-tems utilizing wavelength-division multiplexingtransmission, and designing and modeling ofphotonic networks.
Takehiro Tsuritani joined KDD (currentlyKDDI Corporation), Japan in 1997, and since1998 he has been working at KDDI R&D Lab-oratories. He has been engaged in researchon long-distance optical communication systemsusing wavelength-division multiplexing trans-mission and designing and modeling of photonicnetworks.
Hiroaki Harai received his M.E. andPh.D. in information and computer sciences fromOsaka University, Osaka, Japan, in 1995 and1998, respectively. He is now a Director at Na-tional Institute of Information and Communica-tions Technology, Tokyo, Japan. His researchinterests are Future Networks and Optical Net-works.
Satoru Okamoto received B.E., M.E. andPh.D. degrees in electronics engineering fromHokkaido University, Hokkaido, Japan, in 1986,1988 and 1994. He is currently a specially ap-pointed Professor of the University of Electro-Communications, Japan and a researcher of KeioUniversity, Japan. He is an IEEE Senior Mem-ber.
Naoaki Yamanaka graduated from KeioUniversity, Japan where he received B.E., M.E.and Ph.D. degrees in engineering in 1981, 1983and 1991, respectively. He is currently Professorof Keio University, Department of Informationand Computer Science. He is now research-ing future optical IP networks and optical MPLSrouter systems. Dr. Yamanaka is an IEEE Fellow.
