**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 typi‐ cally 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 hierarchi‐ cal 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**

network, which arises the need for that the datacenter network (DCN) architecture to be rede‐ signed [2]. Recently, elastic optical network (EON) with software‐defined networking (SDN) architecture has been introduced into datacenters to improve the performance of service pro‐ visioning. This can jointly consider both IT resources and network resources and enable net‐ work 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 opera‐ tors 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 hier‐ archical 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.

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 typi‐ cally 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 hierarchi‐ cal architecture, in which a father controller is deployed for cross‐domain orchestration and

each domain controller is deployed for local domain resource management.

**2. Software‐defined optical network architecture**

4 Optical Fiber and Wireless Communications

**Figure 1.** SDON architecture.

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:


The northbound interface (NBI) is designed for communications between controllers and net‐ work 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.

	- (a) Support creating, deleting, and adjusting point‐to‐point, point‐to‐multi‐point, and multi‐point‐to‐multi‐point services.
	- (b) Support getting running status of all or selected services.
	- (a) Support posting routing computation request and offering path computation func‐ tion according to demand of service strategy.
	- (b) Support posting reconfiguring path request, adjusting path connected, in order to satisfy new requirement.

#### **2.2. Protocols**

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


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 cus‐ tomers. RESTCONF is one option, which supports notification event defined in YANG model. RESTCONF clients receive notifications by means of subscribing URL of notification mes‐ sage's resource. NBI protocol can follow RESTCONF protocol defined in IETF draft‐ietf‐net‐ conf‐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.
