SDN

Currently, we have been working with SDN OpenDaylight instances that control different autonomous systems. We have managed to synchronize them by replicating each network's data to the other controller. In this way, both instances are able to provide backup functionalities between them which is an important characteristic in order to improve the network response time in cases of emergency in 5G Networks. 

We deploy two types of controllers which use the DDS to exchange network information as shown in the figure.

The Global Controllers (GCs) communicate with each other to keep a consistent network state and establish inter-domain flow routes. In the same way, the Area Controllers (ACs) update their GCs when a change in their topology occurs. Similarly, the GCs inform their ACs when there is a change in the global topology that can affect the communication among the nodes under the control of different ACs. Furthermore, the use of the DDS allows a stronger performance during the recovery stages because the GCs share their network information with each other. Thus, if any problem arises with a GC operation, its functions are assumed by another GC.

The testbed architecture is composed of two GCs, each of which manages two ACs. The GCs are physically distributed in Granada (University of Granada, UGR) and Barcelona (Universitat Polit├Ęcnica de Catalunya, UPC). Similarly, their ACs are placed in these locations, and they can only communicate with their GCs. Thus, we have two SDN domains. The blue dashed line represents the DDS connections over RedIRIS as shown in the following picture.

The GCs were configured to support communication over Wide Area Network (WAN). In this way, the GCs can exchange network information and discover other GCs through DDS. The ACs were also configured to support communication over WAN in case their GCs are geographically distant in another SDN domain. However, the first principle was to use private LAN to communicate with controllers in the same SDN domain.

Making DDS Really Real-Time with OpenFlow

An increasing amount of distributed real-time systems and other critical infrastructure now rely on Data Distribution Service (DDS) middleware for timely dissementation of data between system nodes. While DDS has been designed specifically for use in distributed real-time systems and exposes a number of QoS properties to programmers, DDS fails to lift time fully into the programming abstraction. The reason for this is simple: DDS cannot directly control the underlying network to ensure that messages always arrive to their destination on time.

Publication Year: 
2016
1 post / 0 new
Offline
Last seen: 1 year 6 months ago
Joined: 09/29/2019
Posts: 8
Is there any ways to get other DDS participants's QOS setting?

I'm trying use DDS with SDN on my research,

and I want let SDN controller(ryu) know each domain participants's QOS.

If this is possible, I need some example, thanks of all.

Sincerely, Karen

MIDAS Overview and Demonstration - Using SDN and OpenFlow to automatically enforce DDS QoS

The MIDdleware Assurance Substrate (MIDAS) uses software defined networking (SDN) and OpenFlow to automatically enforce timing and other non-functional properties for DDS-based publish/subscribe systems.

The video demonstrates how MIDAS can be used to maintain the network Qos necessary to close a real-time control loop even in the presence of network interference and a Denial of Service (DoS) attack.

Author:
Subscribe to RSS - SDN