Design and Experimental Demonstration of Software Defined Space Optical Network ( SDSON ) Architecture Based on Cloud Platform

Space information network is used for real time acquiring, transmitting and processing the space information on the space platform, which provides significant communication services for communication, navigation positioning and science exploration. In this paper, the architecture of Software Defined Space Optical Network (SDSON) based on cloud platform is designed by means of Software Defined Optical Network (SDON) and cloud services. The new architecture combining centralized and distributed management-control mechanism is a multi-layer and multi-domain architecture with powerful computing and storage ability. Moreover, reliable service and unreliable service communication models employed in the space information network are proposed considering the characteristic of Disruption/Delay Tolerant Network (DTN). Finally, the functional verification and demonstration are performed on our optical experimental network platform.


Introduction
The space information network interconnecting among Geostationary Orbit (GEO), Medium Earth Orbit (MEO) and Low Earth Orbit (LEO), as well as airships, space shuttles, space stations, deep space and near-space probes, will become an inevitable trend in information transmitting, switching and processing with the ultra-great capacity and the ultra-high speed rate. Space information network will be applied widely to Satellite-to-Satellite communication, Satellite-to-Ground communication, navigation positioning, deep space exploration, remote sensing and telemetry, high-resolution image acquisition and etc. The space optical communication using laser

Architecture of SDSON Based on Cloud Platform
The architecture of SDSON based on cloud platform is shown in Figure 1, which consists of the control plane and the data plane. The control plane comprising the orchestrator and many different OpenFlow-controllers, runs on the OpenStack [6] cloud platform, which can provide powerful computing, storage and management ability. On the data plane, considering that the GEO communicates with the ground directly while the MEO/ LEO indirectly communicates with the ground through the GEO, the nodes are divided into direct connected nodes and indirect connected nodes. The data plane nodes are controlled and managed by different domains according to the characteristics, such as region and location. The data plane is composed of OpenFlow-enabled optical nodes, as shown in the inset of Figure 1, which includes Open vSwitchsoftware [7], translation layer software, FPGA and OXC/ROADM. From the vertical perspective, the centralized management-control architecture can achieve the scheduling of the network resources such as transmission bandwidth and routing in the more macroscopic views. When the centralized management-control mechanism is utilized, the network can not only enhance the resource utilization, but also decrease the workload and cost of the operation, administration and maintenance (OAM). From the horizontal perspective, the distributed management-control structure can overcome disadvantages such as task excess, low efficiency, management system complication and database enormity, which are caused by the centralized management-control mechanism. The new architecture is a multi-layer and multi-domain structure combining centralized and distributed management-control merits. It decreases the scale of the global database, the query time and the information transmission of the control signaling. Furthermore, it also achieves global optimized scheduling and improves the resource utilization. This architecture is particularly well-suited for the large scale, heterogeneous network interconnection and geographically distributed space information network.
The function block diagram of the SDSON based on cloud platform is shown in Figure 2. The orchestrator, as the centralized controller of different domains, can response to the requests from the application layer or clients in time. Moreover, it can receive the intra-topology information from OpenFlow-controllers, and then analyze and store the global topology information. When the network fails to transmit certain messages, the orchestrator can analyze the service transmission information to find out the failed messages and resend the commands to OpenFlow-controllers. Moreover, the orchestrator is supposed to provide a unified interface and inter-domain routing algorithm. The OpenFlow-controllers collect the node link information from the data plane nodes and store the inter-domain topology information, which is sent to the orchestrator. According to the commands from the orchestrator, the OpenFlow-controller passes the flow entries to the data plane nodes. Generally, the OpenFlow-controller is responsible for the centralized control of the intra-domain nodes and the unified management of the intra-domain network resource. The data plane nodes are utilized to configure the optical switch matrixes states on the basis of the flow entries, analyze and store the transmitted and received messages, and discover the link information and implement the packet forwarding and etc. The orchestrator communicates with OpenFlow-controllers through Rest API based on HTTP protocol, while the OpenFlow-controllers communicate with the data plane nodes through secure channels based on the OpenFlow protocol.

Communication Models of SDSON Based on Cloud Platform
In order to adapt to the long delay, variable topology and various services, reliable service and unreliable service communication models are proposed through modifying the traditional SDON and the communication models of multi-layer and multi-domain network here, regarding the architecture and protocols of the DTN. The combination of the DTN with SDSON based on cloud platform makes the structure more flexible and the management-control mechanism simpler. Furthermore, the problems of long delay and easy interruption are solved in this model. When utilizing the communication models of reliable service and unreliable service, the communication processes between nodes and controllers, responding to the requests from the application layer, are illustrated as follows.

Unreliable Service Communication Model
When utilizing the unreliable service communication method, the network doesn't guarantee the accessibility of the messages and the information loss rate is high. In the space information network, the link breaking caused by atmospheric turbulence is the main reason for the high rate of the information loss. In order to decrease the loss rate, the delay flow entry method is proposed in this communication model. The communication process is shown in Figure 3. The procedures are as follows.
Step 1: The client sends service requests to the orchestrator.
Step 2: According to the service requests and global topology, the orchestrator identifies the domains passed by messages. Afterwards, the orchestrator makes routing decisions, assigns the wavelength and sends the commands to the OpenFlow-controller (OF-C1) belonged to the first domain (domain A), starts the timer at the same time.
Step 3: OF-C1 inserts flow entries into the OpenFlow-enabled optical nodes in its sub-domain.
Step 4: When the light paths in the intra-domain and the edge of the domain A are established, the messages passed by domain A begin to be transmitted.
Step 5: When the timestamp of the orchestrator timer is reached, the orchestrator makes routing decision again based on the new global topology and sends the commands to the OF-C2belonged to the second domain (domain B).
Step 6: OF-C2 inserts flow entries into the Open-Flow-enabled optical nodes in its sub-domain. The light paths in the intra-domain and the edge of the domain B are established. The messages passed by domain B begin to be transmitted until the services reach the destination.
Aiming at the unreliable service communication model, we utilize the large transmission delay to put forward the delay flow entry method. This method can lessen the information loss caused by broken links in the transmission. The delay time of the delay flow entry method is less than or equal to the transmission delay between nodes. Therefore, the total transmission delay is not increased. The unreliable service communication model is simple and convenient. It reduces the rate of the information loss and does not add the transmission delay.

Reliable Service Communication Model
Compared to the unreliable service communication model, the reliable service communication is more complex. In order to guarantee accessibility of the messages, the retransmission mechanism is necessary. The selective retransmission mechanism is employed in this reliable service communication to improve the transmission efficiency and decrease the rate of information loss. The communication process is shown in Figure 4. The procedures are as follows.
Step 1: The client sends service requests to the orchestrator.
Step 2: According to the service requests and global topology, the orchestrator identifies the domains passed by messages. Afterwards, the orchestrator makes routing decisions, assigns the wavelength and synchronously sends the commands to each OpenFlow-controller (OF-C1 and OF-C2) related to sub-domains (domain A and domain B).  Step 3: OF-C1 and OF-C2insert flow entries into the OpenFlow-enabled optical nodes in each sub-domain.
Step 4: When the light paths in the intra-domain and the edge of each domain are established, the messages begin to be transmitted. Meanwhile, the OpenFlow-controllers record the transmitted messages and received messages, which are forwarded to the controllers.
Step 5: The orchestrator resends the commands to each OpenFlow-controller (OF-C1 and OF-C2) and informs the information of the failed messages.
Step 6: OF-C1 and OF-C2 insert flow entries into the OpenFlow-enabled optical nodes in each sub-domain again.
Step 7: The light paths in the intra-domain and the edge of each domain are established. The failed messages begin to be retransmitted until the services reach the destination.
In the reliable service communication model, the selective retransmission mechanism is adopted, in which only the failed messages instead of the whole messages are retransmitted. Though the reliable service communication model is more complex than the unreliable one, the information loss rate is lower and the resource utilization rate is higher in the reliable service. The two communication models can be chosen in accordance with the network circumstance.

Experimental Demonstration and Function Verification
The function verification of the reliable service and unreliable service communication models is performed on the experimental platform. The orchestrator and two different OpenFlow-controllers such as Floodlight and OpenDaylight run on the OpenStack. The two OpenFlow-controllers connect with OpenFlow-enabled optical nodes and control two different domains respectively. The translation layer software in the OpenFlow-enabled optical nodes translates the flow entries stored in the Open vSwitch software to the commands which can be recognized by the optical devices. Afterwards, the commands are delivered to the FPGA, which controls the optical devices.
If the client chooses the unreliable service communication, the experimental results are shown in Figure 5. In the experiment, the orchestrator and OF-C1 are chosen as the observation points. The signaling process on the orchestrator is shown in Figure 5(a). The client acquires the information or sends the requests to the orchestrator through the GET or POST method in HTTP protocol. Once receiving the requests, the orchestrator delivers the routing commands to the OpenFlow-controllers. The time of the commands transmitted to two OpenFlowcontrollers is about 2000 ms. Figure 5(b) illustrates the signaling process on the OF-C1. After obtaining the routing commands from the orchestrator, the OpenFlow-controllers forward the flow entries named flow-mod to the OpenFlow-enabled optical nodes.
If the client chooses the reliable service communication, the experimental results are shown in Figure 6. The orchestrator is chosen as the observation point. The differences from the unreliable service communication are that the orchestrator concurrently sends the routing commands to two OpenFlow controllers. Moreover, after acquiring failed messages, the orchestrator concurrently retransmits the routing commands to two OpenFlow controllers.
The feasibility and availability of the two communication models are experimentally validated from the experimental results above. The client in the application layer can select the two communication methods in line with the contents and attributes of the service. The communication methods are identified by the flag of the request information. Furthermore, the two communication methods can be employed in the time-sharing way. The unreliable service communication is applied when the link environment is fine. For instance, the atmospheric environment of the satellite-to-ground links is peaceful and the satellite attitude is stable. While, the reliable service communication is operated under the terrible link environment or the unstable satellite attitude. The two communication models have their respective advantages, which are appropriate for long transmission delay, variable topology and various services in the space information.