Abstract

Aiming at the limitations of existing solutions for network bottleneck caused by the gap between the network transmission capacity and the processing capability of the current Internet architecture, this paper presents a novel cloud routing protocol named LD-CR based on limited deflection mechanism. A router running this protocol logically separates data forwarding and processing, which could share cloud processing resources with other nodes by using extra bandwidth. This method could effectively alleviate single-node congestion by leverage of the capability of electronic processing and optical transmission capacity at the same node. Analysis and simulation results show the simple LD-CR protocol could improve network performance in packet loss rate and network throughput obviously compared with OSPF protocol. Meanwhile, this method could also avoid performance rapid deterioration under the condition of heavy traffic load by using traditional deflection routing technology.

1. Introduction

The rapid rise of cloud computing and mobile Internet has led to explosive growth in network traffic recently [1]. Though dense wavelength-division multiplexing (DWDM) technology that appeared in 1990s provides enormous bandwidth at the transmission layer [2, 3], Moore’s Law has dictated a relatively slower increase in the electronic processing speed, which means that data transmitted optically has to be slowed down at each node. In the past few years, a transmission capacity of beyond 100 Tb/s over dozens of kilometers on an optical fiber has been experimentally demonstrated [4, 5], which is hundreds of times as large as per-port processing power of electronics [6]. The mismatch between transmission capacity growth and processing power growth limits the increasing of network bandwidth. Accordingly, how to balance electronic processing power with optical transmission rate at a conventional router has triggered a lot of research activities [7, 8]. Stacked device is a realistic and simple method for enhancing the processing power of single node. However, it is well known that the current practice architecture suffers from the problems of low scalability [9, 10] and high cost as well as single point of failure in a large-scale network. All-optical packet switching is a natural perfect solution for this bottleneck problem, but fast switching in the optical domain is still a sophisticated and expensive task [11]. Optical burst switching (OBS) combines good aspects of both circuit and packet switching and seems to be a promising technique for next-generation networks architecture [12], which also has a weakness for resource competition due to the limited buffering capability.

Trying to solve the limitations of existing technologies for network processing bottleneck, this paper proposes a novel cloud routing protocol based on the limited deflection mechanism (LD-CR). This method partitions data forwarding and processing logically, and, by utilizing deflection routing technology, it could forward those data beyond the single node processing capability transparently by extra transmission channel to more powerful or temporary free routing nodes. Compared with traditional deflection routing technology applied in OBS [13, 14], we limited the number of deflection nodes which could alleviate traffic congestion caused by deflection flows efficiently. Based on this resource sharing mechanism, it could also narrow the gap between the capability of electronic processing for single node and the optical transmission capacity and eliminate the network bottleneck, which effectively improves the overall performance of the network.

As a starting point, in Section 2, the implementation mechanism of the cloud routing protocol is elaborated. A simplified theoretical analysis to the performance comparison to traditional routing protocol is provided in Section 3. In Section 4, the simulation model for the cloud routing node is developed, and burst traffic source is introduced to the simulation which is most close to the real network. Based on these, the simulation results are presented for the overall performance comparison among the cloud routing technology and traditional routing technology as well as traditional deflection routing under different traffic load. In the last section, Section 5, a summary is made for this paper, and also the future and follow-up work for the cloud routing is prospected.

2. The Principle and Implementation for the Cloud Routing Protocol

2.1. The Optical Switching Structure of Cloud Routing Protocol Node

Typically, there is no partition between data processing and forwarding in traditional network routing or switching technologies. Data processing and forwarding usually overlap in the port physically and logically. In another word, one node would do the processing for all the traffic flow from a certain physical ingress belong to itself and then forward it to the relevant egress according to the carried address, like the OSPF routing protocol popularized in IP network [15].

Therefore, due to the overlap of the processing and forwarding port, the network throughput is limited by the maximum processing capability of any intermediate node. Hence, the basic principle of the cloud routing protocol is to enhance the network capacity by partitioning the overlap port. It could adopt dual-port access according to time-division or space-division for the partition mechanism, which divides the data into forwarding flow or processing flow. For forwarding flow, there is no need for any routing processing, just transmitting it from the corresponding forwarding port according to the given port-mapping method. Like the implementation in photo-electronic hybrid network, an extra wavelength channel could be added for the data beyond the capability of electronic processing, while, in the optical cross matrix (OXC) of the core node network, it could be implemented by assigning some certain wavelength channels for the data transparent forwarding, which reduces the complexity for electronic processing.

2.2. The LD-CR Algorithm

In Figure 1, a typical structure of electrical-control, all-optical-switch node is depicted. As an assumption in this traditional routing node, the switching capability is ; then, extra wavelength channels can be in introduced to support the cloud routing protocol, which can transmit more data flow. These data are transmitted by exchanging to corresponding egress port in the extra channels, following predefined static switching scheme, the dynamic configuration via electronic control routing switch module is not necessary. Obviously, in order to support the cloud routing protocol in OXC, only static port-mapping forwarding configuration module is needed compared with traditional routing/switching node, which has the fully forward compatibility.

Deflection routing technology is one of the common resolution policies for network congestion in optical network which is lack of buffering technology like OBS network [16]. When congestion occurs, data packets can be forwarded to alternative egress port without any processing. This traditional policy could effectively improve the network performance in the network on condition that network connectivity is good and traffic load is light. However, as the traffic load increases, the data packets generated by the deflection routing would begin to cruise repeatedly, which consumes a lot of network resource and gives rise to live-lock causing network efficiency decrease. The cloud routing protocol proposed in this paper is partially based on the traditional deflection technology, and use limited deflection constraint mechanism to eliminate the live-lock problem.

A typical network domain supporting LD-CR consists of front-end nodes and tail-end nodes along the cloud path, as Figure 2 shows. A group of front-end nodes and a tail-end node make up a cloud path such as node , node , node , and node , where node is a tail-end node and the others are front-end nodes. Every front-end node includes 4 node groups; logically, they are processing ingress port , processing egress port , forwarding ingress port , and forwarding egress port , respectively. Tail-end node is similar but with no forwarding egress port group. Cloud path is directional and tail-end port is mandatory. In Figure 2, assuming constructs to a cloud path , is the tail-end node of , then for node , any traffic from node to forwarding ingress port, if not be processed, would directly come out of the forwarding the egress port which connected with node . Similarly, when congestion occurs in node , this part of traffic flow coming from the processing ingress port would exchange to the forwarding egress port connective to node for transmission. All the forwarding traffic load which arrives at node would be simply discarded if exceeding the processing capability of this node.

Thus, for each node, the quantity of cloud paths needed to maintain equals the ingress port number of this node, and the forwarding egress port for the traffic flow from certain forwarding ingress port is determined by looking up the local cloud path set . Simultaneously, the cloud routing protocol could also further avoid the live-lock problem caused by the traditional deflection routing protocol by monitoring the processing queue and setting the threshold th to control the forwarding traffic data rate of the node.

The cloud path set could be configured statically or updated periodically according to the statistics information, which is flexible and also low processing overhead for the forwarding traffic. Furthermore, if we generate or change the cloud path according to the traffic long period statistic information, the forwarding accuracy could be enhanced; that is, the network performance would be improved. Limited by this paper’s length, the dynamic generation, maintenance, and update of the cloud path are not discussed here. Assuming for each routing node in Figure 2, there is a set of effect cloud paths mapping to the ingress port; when congestion happens or there is traffic entering forwarding channel, the traffic can be mapped to the corresponding egress port according to the ingress port and cloud path; at the same time, we set the processing maximum threshold to be and the traffic ingress port , and the egress port , the detailed algorithm is described in Algorithm 1 for the cloud routing protocol, in which OSPF_Output_Port_Get() means the processing egress port of the next hop according to OSPF algorithm.

LD-CR Algorithm: Initializing Cloud Path Set  
input:
output:
if    then
  if    then
  
  return
  end if
  if    then
    for  each   do
      if    then
      return
      end if
    end for
  end if
end if
if    then
  if    then
  
  return
  end if
  if    then
    for each   do
      if    then
      return
    end for
  else
  drop packet
  end if
end if

3. The Performance Analysis of LD-CR

Given is a cloud routing network and is the node set, is the link set. are the source and destination nodes of the end-to-end traffic flow, is the packet loss rate, and is the packet arrival rate generated by the th source for the node. And assuming that the arrival time obeys Poisson distribution, packet length is exponential distribution.

The research has shown that it is quite complicated for the mathematical expression of the packet loss rate or average end-to-end delay, even if for the single node in the real network traffic. Therefore, the expressions based on these parameters are more complex or even hardly explicitly described for the whole network with complex topologies. Thus, we only present the simplified theoretical analysis here. In Figures 3 and 2, adjacent nodes , in are considered in the traffic model.

Given , are the buffer length for , , respectively, and , are their each service rate, the service model for the 2-node could be considered as queue, and where the traffic load intensities for each are When OSPF routing protocol is utilized in the network, the packet loss rates for are So, the end-to-end packet loss rate is The delay for the single node is Therefore, the average queue length can be obtained by Similarly, also can be obtained, so the average total delay for the system is estimated by Obviously, there is no packet loss in node when LD-CR protocol is adopted, and the traffic can be directly forwarded to node . The packet loss rate for LD-CR can be estimated by (7) under light to medium traffic condition. Consider So, the delay for end-to-end is From (3) and (7), it’s obvious that the packet loss rate can be dramatically improved if cloud routing protocol is adopted compared with that of OSPF hop-by-hop protocol under ideal simplified situation. Especially, the performance enhancement is quite outstanding for LD-CR when there is bottleneck existing in the intermediate nodes, that is to say, when is bigger and traffic load is normal. Also from comparison of (6) with (8), the delay for LD-CR is still slightly better than OSPF under normal traffic load.

4. The Performance Simulation Analysis of LD-CR Cloud Routing Protocol

4.1. Simulation Environment

In this paper, the random topology structure as shown in Figure 4 is utilized for the simulation analysis. The purpose is to estimate the relative performance of LD-CR protocol and traditional routing protocol. Let the group of nodes be edge router for traffic generation and the group of nodes the core router. Edge routers are used for network traffic generation by adopting large number of ON/OFF sources superimposed to mimic the real network traffic, which obey Pareto distribution. The traffic from each edge node would be transmitted to other edge nodes following equal probability. The link speed is 1 Gbps between nodes, and there is an extra 1 Gbps forwarding channel for the node model which supports LD-CR protocol. Given the packet length is 1.5 KB, the processing time is for single packet in core nodes, and the node maximum buffer queue length is 20.

4.2. Simulation Results and Analysis

In Figure 4, a set of available cloud paths with random length is statically configured for each core node. Then, we run the simulations utilizing OSPF protocol, LD-CR protocol, and traditional deflection routing (DR) protocol for the performance analysis. Here, the strategy for DR is forwarding the packets randomly to certain forwarding port until it finds the available node () and enters the buffer queue for processing when congestion occurs in the shortest path routing. The same parameters are set for maximum hops and delay both in DR and LD-CR.

The results have shown the packet loss rate, delay, and network throughput comparison of the 3 kinds protocols, respectively, in Figure 5. The core nodes are configured with different processing capability under heavy traffic load. In the first group of data (LD-CR1, OSPF1, DR1), the processing time is set to for all the core nodes; that is to say, there is no bottleneck for the single node in the system. And, in the second group (LD-CR2, OSPF2, DR2), the processing time increases to for 3 key nodes , , and , mimicking the case that bottleneck exists in the single node.

In Figures 5(b) and 5(c), it is shown that the performance has obvious improvement in packet loss rate relative to the average end-to-end delay compared LD-CR with OSPF, which corroborates our theoretical analysis in Section 3. The performance of traditional DR protocol is the worst under heavy load, caused by its greedy strategy. Whenever congestion happens, the deflection traffic would cruise repeatedly in the network, grabbing the processing resource which leads to live-lock causing the performance to dramatically drop. It is quite interesting that when there is bottleneck in single nodes, the performance of DR is better on contrast. The reason for this phenomenon is that although the 3 core nodes are the network bottleneck, the traffic of DR is much free to find the alternative path which may get better performance. That is also the same result as the edge effect in topology research [17]. While in OSPF or LD-CR protocol the packets have no such capability, the performance drops as the processing capability decreases.

In addition, it is quite effective on solving the bottleneck of single node when using LD-CR protocol under normal traffic load. When traffic load is within , the network throughput can even reach twice better relative to OSPF or DR with the bottleneck existing.

In Figure 6, the packet loss rate and delay of the 3 protocols under light traffic load are shown. Let the transmission rate decrease to 1/3 for all the edge nodes and for all the core nodes; the processing capability promotes twice. We can see that DR and LD-CR have better performance compared with OSPF under light traffic, but as the traffic load increases, the packet loss rate rapidly worsens when traffic load reaches 0.8 for traditional DR due to live-lock, while the performance gap is widening between LD-CR and OSPF. We can also see that the end-to-end delay of LD-CR is not a bit worse than that of OSPF even under light traffic load from Figure 6(b).

5. Conclusion and Future Work

The internet data dramatic increase has exceeded the development speed of network data processing. Aiming to the gap between network transmission capacity and processing capability, a novel cloud routing protocol based on limited deflection mechanism is proposed in this paper, and the node architecture and algorithm are also presented to support the protocol implementation. As expected, the implementation is simple for the LD-CR protocol. It is only needed to add a static port-mapping processing module in current routing nodes to utilize the idle transmission capacity for network processing capability improvement, which is limited by the network bottleneck caused by the processing capability insufficient in single nodes. Both theoretical analysis and simulation results show that the performance on packet loss rate, network throughput, and so forth is obviously improved when using LD-CR protocol compared with OSPF. Simultaneously, LD-CR protocol also overcomes the traditional DR protocols drawback when traffic load increases the performance rapidly worsens.

For the future work, the performance would be evaluated in bigger network for LD-CR. At the same time, the study of the cloud paths dynamic generation would be done, and its impact on network safety is also under consideration.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgments

This work was supported by the National Natural Science Funds of China (Grant no. 61174152), the Key Program of the National Natural Science Funds of China (Grant no. 61331008), and the Key Science-Technology Project of the National of China (2010ZX03004-002).