Received 30 October 2016; accepted 26 February 2016; published 2 March 2016

ABSTRACT

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.

Keywords:

Space Information Network, SDON, Cloud Control Plane, Communication Model

1. 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 has many advantages such as the ultra-high bit-rate, the ultra-great capacity, the ultra-small size, long transmission distance, and low power consumption. If the space laser communication internetwork is implemented, and simultaneously interconnecting with the existing microwave network, the service function and quality of the network will be sharply enhanced. Therefore, the investigation on the architecture, the management-control mechanism, as well as the communication model of space optical communication network is becoming the hotspot in network fields.

So far, the exploring on the space optical network is still in the initial stage and fewer research results are reported. In addition, communication models for the space optical network have not been seen. In 2014, Beijing University of Posts and Telecommunications (BUPT) proposed the architecture of the mobile free space optical networks (MFSON) based on OpenFlowprotocol [1], which combined software defined network (SDN) with MFSON, and divided the data plane nodes into direct connected nodes and indirect connected nodes. However, this architecture is only suitable for small-scale network. By the year 2015, Tsinghua University combines network virtualization technology with SDN and DTN, established a large scale DTN evaluation testbed, called TUNIE [2]. Although this testbed can be utilized to verify the network protocol and the routing algorithm, the space optical network is not taken into consideration in this investigation.

In this paper, in consideration of the characteristics of the space information network such as the long delay and easy interrupting, a multi-layer and multi-domain SDSON architecture based on cloud platform is proposed, which introduces the cloud services with powerful computing, storage and management ability [3], as well as the design philosophy of the advanced SDN technology [4] exploring and applying in the ground network into the architecture of the space information optical network. In addition, reliable service and unreliable service communication models suited for the space information network are put forward, which integrates the architecture characteristics and protocol standards of Disruption/Delay Tolerant Network (DTN) [5]. Finally, the feasibility and availability of the architecture, and two communication models are experimentally validated by our experimental network.

2. 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.

3. 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.

3.1. 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.

3.2. 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.

4. 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 OpenFlow- controllers 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.

Acknowledgements

With the help of the SDON that has more flexible structure and function, and the cloud service that owns powerful computing, management and storage ability, the multi-layer and multi-domain architecture of the SDSON based on the cloud platform is proposed in this paper. The new architecture can perform hybrid centralized and distributed management-control, which is applicable to complicated nodes, multiple services, dynamic topology and highly heterogeneous space information network. Referring to the architecture and protocol standards of the DTN, the reliable service and unreliable service communication models are designed, which are suitable for the features of long delay and easy breaking in the space information network. Eventually, the space optical network architecture and communication models are experimentally demonstrated.

This work was supported in part by the National Natural Science Foundation of China (NSFC) under Grants 61231011 and 61071123, and The First HAEPC Science and Technology Project in 2015 (5217Q014006U).

Cite this paper

Fangyuan Xing,Hongxi Yin,Bin Wu,Jianxin Liu,Ming Li,Jingchao Wang, (2016) Design and Experimental Demonstration of Software Defined Space Optical Network (SDSON) Architecture Based on Cloud Platform. Journal of Computer and Communications,04,7-13. doi: 10.4236/jcc.2016.43002

References

NOTES

^*Corresponding author.