Software‐Defined Optical Networking (SDON): Principles and Applications

Abstract

Featured by the advantages of high capacity, long transmission distance, and low energy consumption, optical network has been deployed widely as the most important infrastructure for backbone transport network. With the development of Internet, datacenter has become the popular infrastructure for cloud computing, which needs to be connected with high bitrate transport network to support heterogeneous applications. In this case, optical network also becomes a promising option for intra and inter‐datacenter networking. In the networking field, software‐defined networking (SDN) has gained a lot of attention from both academic and industry, and it aims to provide a flexible and programmable control plane. SDN is applicable to optical network, and the optical network integrated with SDN, namely software‐defined optical network (SDON), are expected as the future transport solutions, which can provide both high bitrate connectivity and flexible network applications. The principles and applications of SDON are introduced in this chapter.

1. Introduction

The continuous growth in the number of large‐scale datacenters (DC) poses new challenges to the capacity and elasticity of current optical network. Datacenter applications, such as scheduled high‐speed data replication, require the substrate network to provide ultra‐high bandwidth dynamically [1]. This is quite different from the service model of traditional optical network, which arises the need for that the datacenter network (DCN) architecture to be redesigned [2]. Recently, elastic optical network (EON) with software‐defined networking (SDN) architecture has been introduced into datacenters to improve the performance of service provisioning. This can jointly consider both IT resources and network resources and enable network to be programmed like general hardware [3–5]. The optical network integrated with SDN, namely software‐defined optical network (SDON), can provide high bandwidth with IT resources for multiple tenants [6]. It separates the control plane from the data plane and turns the control manner into a centralized and flexible one. In addition, it enables datacenter operators to control and program network functions such as bandwidth provisioning with Quality of service (QoS) guarantees. Resources of datacenter are provisioned by virtualizing resources of distributed datacenters and operator’s optical network in a coordinating manner [7]. A hierarchical control mechanism is proposed to control multi‐domain optical network [8], which can support connections between datacenters in multi‐domain scenario. On the basis of above studies, the objective of this chapter is to find what applications can be deployed on SDON.

2. Software‐defined optical network architecture

A case of SDON integrated with datacenters is schematically depicted in Figure 1 [9]. There are datacenters (DC) geographically distributed in different locations. Datacenter network typically consists of multi‐domain and multi‐technology network, such as Ethernet access network and optical transport network. For each network domain, an SDN controller is deployed with extended protocols. The Control Virtual Network Interface and the corresponding OpenFlow (OF) agents (there are some other potential protocols, such as Path Computation Element Communication Protocol (PCEP) and Simple Network Management Protocol (SNMP)) are implemented for optical devices and equipment. The control plane is designed as a hierarchical architecture, in which a father controller is deployed for cross‐domain orchestration and each domain controller is deployed for local domain resource management.

Figure 1.

SDON architecture.

2.1. Southbound and northbound interfaces

The southbound interface (SBI) is mainly used to synchronize control information between controllers and network devices and datacenters. The control information contains topology graph, label resources, statistics data, alarm events, and kinds of flow tables.

In December 2013, a series of suggestions about SDON southbound interface were given from the white paper of Open Networking Foundation (ONF), namely control data plane interface (CDPI), which has defined the programming protocols between SDN controllers and optical transport network devices [10].

Here are some basic functions that controller southbound interface should satisfy:

1. Controller can get local topology and resource occupation status via southbound interface.

2. Controller can configure local network connection and control functions related to service, including connection creating, deleting, and adjusting via southbound interface. The configuration parameters include the information about QoS, Operation-Administration-Maintenance (OAM), and so on.

3. Controller can get local network’s alarming information via southbound interface asynchronously.

The northbound interface (NBI) is designed for communications between controllers and network customers. Via the NBI, controllers can virtualize the heterogeneous features of physical devices and provide abstracted network information for customers to deploy their applications.

According to a research about OpenDayLight project, which is demonstrated on Open Networking Conference 2014 in California, the development of SDN northbound interface functions is pushed forward swiftly. It matches the purpose of SDN research, which means that services can be accepted flexibly and clients can take control of devices and resources in network by using the software programmable technique. Consequently, it is obvious that there will be a good perspective of developing SDN northbound interfaces.

Northbound interface should support basic functions as follows.

1. NBI should support upper layer controller to get all or parts of the network topology, including top layer subnet, as well as all nodes, links, ports it contains.

2. NBI should support service management, which is mainly about:

   1. Support creating, deleting, and adjusting point‐to‐point, point‐to‐multi‐point, and multi‐point‐to‐multi‐point services.

   2. Support getting running status of all or selected services.

3. NBI should support point‐to‐point connection control function.

4. According to flow distribution between nodes on client side, NBI should support creating, deleting, and adjusting virtual network services.

5. NBI can optionally support path computation function when the controller is controlled by other upper layer orchestrators.

   1. Support posting routing computation request and offering path computation function according to demand of service strategy.

   2. Support posting reconfiguring path request, adjusting path connected, in order to satisfy new requirement.

6. NBI should support post controller resource data updating request. When network resource data is updating directly, instead of based on network notifications, new request will be needed through northbound interface to update data. And resource should be released after connections are deleted.

7. Northbound should support triggering the function of resynchronizing controller resource data.

2.2. Protocols

There are several protocols that can be used to implement SBI:

1. OpenFlow protocol: OpenFlow protocol for network devices should correspond to the requirement of ONF TS‐024 (OpenFlow Switch Specification 1.4.1) and ONF TS‐022 (Optical Transport Protocol Extensions Ver1.0) or higher version. OpenFlow protocol supports resource reporting and network device configuring.

2. OF‐Config protocol: As a supplementary of OpenFlow protocol, it is used for configuring OpenFlow network devices.

3. Traditional management protocols: Qx, SNMP, TL1 protocols, and so on.

4. ASON/GMPLS control panel protocol: Signaling protocol should correspond to GB‐T 21645.4‐2010(ASON) and Request For Comments (RFC) 3471; routing protocol should correspond to GB/T 216545.8‐2012 and RFC4203. Automatic discovering protocol should correspond to GB/T 21645.7‐2010 and RFC4204.

5. Path computation element protocol (PCEP): Corresponding to the requirement of Internet Engineering Task Force (IETF) RFC 5440 (PCE communication protocol) and other derived RFC documents.

SDON NBI can be implemented by SDN‐specific protocols (RESTCONF, PCEP, etc.) or other popular protocols used in current software engineering (Restful, Protobuf, etc.).

In some cases, notification function is mandatory for NBI to push update information to customers. RESTCONF is one option, which supports notification event defined in YANG model. RESTCONF clients receive notifications by means of subscribing URL of notification message’s resource. NBI protocol can follow RESTCONF protocol defined in IETF draft‐ietf‐netconf‐restconf‐07 to realize functions above.

It is JSON or XML format that content encoding of northbound interface communication should use, which corresponds to RFC7159 and RFC3032, respectively.

3. Key technologies in SDON

SDON is stretching optical network intelligence. It represents the fact that the control panel of optical network changes from switching intelligence to a comprehensive automatic one, where services diversity and management automation are also considered. In order to adapt to this revolution, SDON needs to make breakthroughs on key technologies like services assignment strategies, heterogeneous networks, and programmable optical transmit devices.

3.1. Sliceable transponder

Sliceable transponder is a kind of photonic, which can be divided into several sub‐transponders, and each sub‐transponder can be used to construct an independent lightpath without “O‐E‐O” switching on transit nodes. From the perspective of optical layer, multiple optical flows can be multiplexed into one optical transponder. And the de‐multiplexing procedure for each optical flow will be operated in the receiver at destination node of that flow. Figure 2 shows a sliceable flexible optical transponder.

Figure 2.

Sliceable optical transponder schematic diagram.

A physical transponder can generate different ligthpaths with different spectrum segments. Multi‐flow optical transponder has been proposed and proved by experiment [11]. In addition, multi‐spectrum sliceable and bandwidth‐extendable coherence optical transponder based on any waveform optical generator, which can also generate multiple optical paths, has been proposed and proved [12].

The most significant difference between sliceable transponder and unsliceable transponder is that there are multiple send‐receive interfaces in sliceable transponder, which means multiple clients’ signals can be handled by one transponder. Consequently, there should be a programmable switch matrix between interface card and sliceable transponder, in order to routing signals between them. In this case, the number of interface cards M and transponder slices are the key factor, which decide the network capability and networking cost.

3.2. Wavelength‐selective switching (WSS)

The advent of all‐optical switches based on wavelength‐selective switching (WSS) has a significant impact on the development of extensibility and flexibility on optical networking. It makes the structure of all‐optical switches change unexpectedly. This kind of WSS lets each wavelength in an input Wavelength-Division Multiplexing (WDM) signal transmit to anyone of the output ports, while the N×1 WSS has the contrary function.

Each WSS chooses an output previously configured wavelength from each input optical fiber. The number of WSS will grow according to the expansion of its dimensions. As to interfaces on client side, several WSS can be deployed as multiplexing/de‐multiplexing role, instead of deploying one WSS for each add/drop fiber.

Figure 3 shows an example flexible switching node, which can realize high‐spectral efficient multi‐grid grade switching.

Figure 3.

Software‐defined flexible switching node.

3.3. Bandwidth‐variable optical cross‐connect

Bandwidth‐variable optical cross‐connect (BV‐OXC) is an important kind of switching node in flexible spectrum optical network. A multi‐dimension BV‐OXC is composed of some splitters and some bandwidth‐variable wavelength‐selective switches (BV‐WSS) as shown in Figure 4.

Figure 4.

Bandwidth‐variable optical switching node schematic diagram.

Bandwidth‐variable optical cross‐connect (BV‐OXC) changes the switching granularity from wavelength to sub‐carrier level. The basic unit bandwidth of sub‐carrier is 12.5 GHz, while the interval is 6.25 GHz, both of which are much less than 50 GHz—the International Telegraph Union Telecommunication Standardization Sector (ITU-T) standard wavelength.

In addition, each wavelength in OXC is isolated from the others. Even though there is a blocking interval between two adjacent wavelengths, this feature makes it impossible for a bandwidth that is more than a wavelength to pass inviolately. However, BV‐OXC eliminates the slot between sub‐carriers and makes it possible for multiple sub‐carriers to bind together and become a broadband. BV‐OXC makes it possible to switch a signal as a super‐channel.

Thus, BV‐OXC has not only better switching granularity but also makes switching capability rise dramatically. Subsequently, this technique can be used in elastic optical network (EON), for the reason that the core idea of EON is to provide necessary spectrum resource with better granularity for users’ different connection requirements.

3.4. Routing and spectrum assignment

In elastic optical network, high‐spectral efficiency and expansibility have been already realized. Meanwhile, the flexibility introduces new challenges in network research. For instance, taking route and spectrum assignment into account, it is not suitable for traditional routing and wavelength assignment (RWA) algorithm being used in flexible spectrum network any longer. One of the reasons is that there lies a new feature—constraint condition of spectrum continuity in flexible spectrum network, which means that network needs to assign a slot of continuing and available spectrum resource for each lightpath. In addition, the flexibility of grid makes the network model more complicated, resulting in higher difficulties of optimization.

In elastic optical network, spectrum is further divided into a series of sub‐carriers that has lower data rate and finer granularity than those in WDM network [13]. Compared with RWA problem in traditional network schedule, the primary problem in elastic network is to allocate contiguous spectrum resources to provision high bandwidth demand connections. This problem is called Routing and Spectrum Allocation (RSA) [14].

According to required bitrates and modulation format, lightpath is constructed from source node to destination node in frequency domain by means of allocating continuous sub‐carriers on all links. In order to demodulate easily on receivers, one or more sub‐carriers are needed as gap between adjacent spectrum paths. There are three kinds of constraints that we should obey when operating RSA computation:

1. Spectrum consistency constraint, namely each link in the path needs to allocate the same spectrum resource.

2. Spectrum continuity constraint, only to make sure that each sub‐carrier in the path must connect with the others.

3. Spectrum conflict constraint, allocated spectrum in different paths on the same fiber cannot be overlapped [15–17].

When connections are deleted, the allocated spectrum resource will be released and can be provided for other coming services. However, due to the fact that network being usually used to serve multiple applications, lightpaths may be constructed and deleted randomly, which leads to the appearance of spectrum fragments inevitably. When contiguous spectrum is divided into fragmentary segments, new coming requests might be blocked for lacking wider contiguous spectrum segment, though there are still lots of unused spectrum slots. This means that the spectrum is not used efficiently. Some heuristic algorithms have been proposed for RSA problems [18–20] and defragmentation problems [21–23].

3.5. Virtual optical network mapping

Virtual optical network (VON) is a new kind of transport service, which aims to allocate spectrum resource to customers at topology level. Compared with RSA, VON mapping is more complex because it needs not only spectrum allocation but also mapping virtual topology to physical substrates. Figure 5 shows a use case of virtual network mapping. The left is abstracted topology and the right is the physical topology. If node mapping method is adopted, node 1 on the abstracted topology is mapped on node 2 on physical topology. Similarly, nodes 2 and 3 are mapped on nodes 4 and 1 on physical topology. If link mapping method is adopted, link 1–2 on abstracted topology is mapped on link 2‐3‐4 on physical topology, and link 1–3 is mapped on link 2–1 on physical topology. The procedure of virtual network mapping can be divided into two phases:

Figure 5.

An example of virtual optical network mapping.

1. Node mapping: Map virtual nodes to different real physical nodes and satisfy virtual nodes’ resources demand.

2. Link mapping: Map virtual links between virtual nodes to real physical links.

From the perspective of VON mapping, all of the mapping algorithms can be summarized as:

1. Use a kind of greedy algorithm when mapping nodes, for example, begin from the physical node which owes the most physical resources [24, 25].

2. If the network does not support distribution technique when mapping links, Shortest Path First algorithm should be considered [24]. Else, if it supports, multi‐path algorithm should be considered [25, 26].

3. When mapping nodes and links at the same time, this method can find a fairly good solution. However, the algorithm complexity is high and expansibility is not good.

As for mapping algorithm, concepts like sliceable ability of link, optical transponder, and switching nodes are proposed to describe resource abstraction method in flexible spectrum network. And based on that above, LS‐based virtual optical network mapping strategy and NS‐based virtual optical network mapping strategy are proposed [27]. Result from experiment shows that LS‐based virtual optical network mapping and NS‐based virtual optical network mapping, compared to baseline virtual optical network mapping, get lower blocking probability and higher profit.

3.6. Cross stratum optimization algorithm

In datacenter network, network‐based services are provisioned by both IT and network resource. In order to achieve the optimization of IT and network resource, cross stratum optimization (CSO) is proposed [28], which can enable a joint optimization of IT and network resource and take optical as a service (OaaS).

The SDN‐based control architecture with CSO between optical network and application stratum resource in inter‐datacenter network is proposed to partially meet the QoS requirement.

Unified control architecture is proposed as depicted in Figure 6(a), which especially emphasizes on the cooperation between application controller (AC) and service controller (SC) based on OpenFlow to realize the CSO of application and network resource. According to the requirement, AC customizes appropriate virtual resource through related SC with extended OpenFlow protocol. In addition, dynamic global load balancing strategy is implemented based on both application and network resource, while SC can trigger service‐aware Path Computation Element algorithm based on the result of dynamic global load balancing strategy. SC interacts with each other for the security and virtual network information. OpenFlow‐enabled routers and optical transport nodes are realized by extending match domain in extended OpenFlow protocol. The responsibilities and interactions among entities are provided as shown in Figure 6(b) and (c).

Figure 6.

Architecture and procedure of OaaS: (a) architecture, (b) CSO procedures, (c) module diagram.

4. Novel applications

SDON is a promising solution for next‐generation high‐speed optical transport network, which embraces a wide application perspective. Here are some sample applications, which can make optical network being used in a more flexible manner. The sample applications include bandwidth on demand [29], Virtual Optical Network (VON) services [30], and some emerging applications [31, 32].

4.1. Bandwidth on demand

Based on the centralized control plane of SDON, providers are able to predict resource occupation status in time dimension, and accordingly arrange and accommodate users’ requests to avoid spectrum conflicts and fragmentations. One application, which is called time‐aware bandwidth on demand, has already been implemented and demonstrated to do such things. Bandwidth on demand can improve the utilization of spectrum resource in SDON. The overall feasibility and efficiency of this time‐aware Bandwidth on demand architecture is experimentally verified on a testbed with real OpenFlow‐enabled tunable optical modules in terms of blocking probability and resource occupation rate, as shown in Figure 7. First, the users’ requests are sent to the controller, and then the controller will schedule these requests to make the spectrum resource utilization optimized, finally the controller will send messages to optical nodes to set up lightpaths. As one of the basic types of services in intelligent optical network, bandwidth on demand can prove the integrity and availability of networking by offering bandwidth resource directly. Also, bandwidth on demand can be a basic measurement index of network automation.

Figure 7.

Time‐aware bandwidth on demand: (a) without SS, three slots occupied; (b) with SS, two slots occupied, one slot resource is saved.

4.2. Virtual optical network

Virtual optical network (VON), which aims to provide multiple dedicated virtual network over shared network infrastructure, has gained a lot of attention by network providers. By VON, service providers can request a dedicated network for each application on a per‐need basis and have full control ability over that network. Network virtualization technologies can partition/composite of network infrastructure (i.e., the physical optical nodes and links) into independent virtual resource, adopting the same functionality as the physical resource. Also, the composition of these virtual resource (i.e., virtual optical nodes and links) allows deploying multiple VON. A VON must be composed of not only a virtual transport plane but also a virtual control plane, with the purpose of providing the required independent, and full control functionalities. In datacenter optical network, since the computing resources are highly distributed, it is impossible to build a dedicated optical network for a special service. So joint considering computing and networking resource is very important if they are under the control of same provider. Network virtualization can eradicate the ossification of the network, stimulate innovation of new network architectures and applications, and enable network operators to operate different VON that share a common physical infrastructure. Figure 8 shows the schematic of SDN‐based VON provisioning.

Figure 8.

VON provisioning.

There are many challenges in VON provisioning, such as VON design and VON resource management. VON design refers to the procedures to find a subset of the underlying physical network topology connecting the computing resources with virtual nodes hosted on the physical nodes and virtual links spanning over the physical links. The VON design problem is related to the traffic demand model and the entire physical network topology information. VON resource management includes two schemes, that is, dedicated scheme and shared scheme. The dedicated VON assumes that the link resources are exclusively assigned to a VON user, so each VON topology runs independently, and its reserved link resources cannot be occupied by other VON. The dedicated VON is relatively easier to achieve, but it has a drawback that it increasingly decreases the efficiency of resource utilization. Note that the sharing VON scheme can be fully or partially shared, and partially shared VON manner is more profitable. On each physical link belonging to a VON, a minimum guaranteed capacity must be assigned to it, while residual capacity is shared by all the VON on that link. The challenge in employing the partially shared VON approach is that the service provider should treat the dedicated and shared resources with different policies, which inevitably increases implementation complexity and difficulty.

5. Conclusions

In this chapter, we summarize the basic principles and key technologies of SDON. First, the architecture of SDON is described with southbound and northbound interfaces and protocols. Then, several key technologies of SDON are introduced, including sliceable transponder, WSS, BV‐OXC, routing and spectrum assignment, virtual optical network mapping, and CSO algorithms. Finally, two novel applications are prospected, such as bandwidth on demand and VON. More studies need to be conducted to promote the evolution of SDON in the future.