With the rapid development of the Internet and the wide application of real-time services such as live video broadcasting and network teaching, multiple receivers need to receive the same streaming media data from one or more source nodes at the same time. The information capacity of network transmission increases greatly, occupying a large amount of network bandwidth. For these application requirements, the traditional on-demand technology not only consumes a lot of source node resources and network bandwidth, but also limits the expansion of the number of users. In comparison, multicast is a good transmission scheme. Because routers in traditional networks need to be configured in advance before they can dynamically support multicast subscribers’ joining and leaving operations and multicast tree generation operations, and routers in traditional networks do not dynamically select transmission paths according to users’ large demand for bandwidth, it is easy to cause link congestion, cannot provide users with better quality of service, and is difficult to deploy on a large scale in traditional networks.
The software-defined network (SDN) framework with OpenFlow technology as the core has the function of centralized control, can sense the change of network topology by itself, has natural advantages in fine-grained path selection, access control and load balancing, and provides a good solution for the realization of IPv6 multicast function. In order to solve the IPv6 multicast problem in SDN network, three functional modules are proposed in SDN controller: group member management, bandwidth topology maintenance and multicast tree construction. It is no longer necessary to deploy distributed multicast routing protocols.
II. Introduction to SDN
SDN is from Stanford University’s Clean Slate project team. They have a grand goal, that is, to rebuild the Internet and change the existing rigid network architecture model, in order to build a scalable modern network architecture with high performance. In 2009, SDN concept was shortlisted in the top ten leading technologies of Technology Review. In April 2012, ONF released the SDN White Paper, proposing an idea similar to an operating system: all network devices in the network are treated as managed resources, and the controller is equivalent to an operating system to manage these resources. This controller abstracts the network equipment, maintains the network equipment, and provides the network equipment information to the upper application. The upper application configures and manages these network devices through a unified programmable interface to realize relevant network application functions, and does not need to care about changes in the underlying network topology. The SDN three-layer model (physical device layer, control layer and application layer) is proposed and widely recognized by the industry.
In the practice of SDN network, scientific research organizations such as OFELIA, Internet2, FIRE and GENI have deployed SDN network in real environment. Huawei, Ruijie, Cisco, Pica8 and other manufacturers have actively invested human and material resources in research and development of SDN controllers or SDN switches supporting OpenFlow protocol. In the aspect of enterprise deployment of SDN network, Google deployed SDN network based on OpenFlow technology in data center on a large scale, which greatly improved the utilization rate of network resources and reduced the complexity of network operation and maintenance.
The network architecture diagram of SDN is as follows: the application layer is mainly a variety of upper-level application programs that complete the user’s intention and manage the network resources in a unified way. The core function of the control layer is to realize the functions of network internal switching path calculation, boundary service route calculation, flow table control and distribution, etc. The forwarding layer mainly consists of links between switches to form a basic forwarding network. The forwarding table items needed in the forwarding process are flow tables issued by the controller. The switch forwards according to the flow tables and does not have logic judgment function.
(SDN Network Architecture Diagram)
Iii. ONOS controller
SDN controller plays a decisive role in the performance of the whole SDN network architecture. At present, there are more than 20 kinds of controllers developed by different languages and institutions, especially the open source community, which provides many controllers, such as NOx, Ryu, Flood Light, Open Daylight, Onos, etc. Among them, ONOS controller is the first commercial controller for operators. It supports a variety of southbound interface protocols, abstracts and shields protocol differences, is famous for its high reliability and high availability, and is more suitable for operator scenarios. ONOS design is highly hierarchical, modular and abstract. The kernel of ONOS is composed of many subsystems designed according to the same architecture. The core layer follows the object-oriented design principle of “programming for interfaces, not for specific implementations” in its design, abstracting the service functions provided by subsystems into interfaces and presenting them to the top-level applications and the bottom-level protocol plug-ins. The structure of the subsystem is shown in the following figure.
(ONOS Controller Subsystem Structure)
- App Component: applications aggregate messages through AdminService and other service interfaces and are used and operated by Manager Component.
- Manager Component: The abstraction of the network is protocol independent and provides a unified northbound interface to the network. It mainly includ es Manager and Store. Store is responsible for data storage, query, update and east-west synchronization. All data-related operations from Manager will be completed through Store. Manager also throws events in Store a nd implements ListenerService interface. Other applications can monitor events through ListenerService interface.
- Provider Component：Provider is protocol-related and mainly provides abstract data types for the core layer. Provider injects network information into t he core layer through the ProviderService interface provided by the core layer. Provider also exposes the provider interface to the core layer and rece ives command messages from the core layer. Each Provider needs to be registered in the ProviderRegistry to be recognized by the ProviderService.
IV. Architecture Implementation
IPv6 multicast function is developed and implemented in the adaptation layer, core layer and application layer of ONOS controller. Comprises the maintenance of the switch port state by an adaptation layer; The core layer maintains subscriber information and subscriber directly connected switch information; Maintenance of multicast path selection by application layer. The architecture implementation diagram is shown in the following figure.
(Implementation Architecture Diagram)
Bandwidth topology adapter component implements the maintenance of switches and their port states. OpenFlowDeviceProvider class is an abstract class of switching devices already existing in ONOS controller, but it does not provide a way to obtain real-time port bandwidth. In order to obtain real-time port available bandwidth information, the PortStatsCollector class is designed in the OpenFlowDeviceProvider class.
The group member management component needs to maintain multicast subscribers and subscriber side switch information, and notify the multicast routing module to select a path for the multicast subscribers. The implementation of the group member management component depends on the equipment management subsystem, the data packet management subsystem and the host management subsystem. The component consists of two parts: multicast subscriber information maintenance and subscriber switch maintenance.
Multicast routing component. When a multicast subscriber joins a multicast group, the multicast routing component selects a transmission path for the multicast subscriber according to the current network topology and link bandwidth information, and considers whether the multicast subscriber joins a new multicast group or an existing multicast group. There are different routing algorithms for the two situations. If a new multicast group is added, multicast traffic is transmitted from the multicast sender to the receiver; If you join an existing multicast group, the multicast traffic is copied and forwarded from multiple ports of the switch that forwards the multicast traffic.
V. experimental results
The data plane uses Mininet simulator to simulate 6 switches. Mininet uses xterm command to open 3 hosts in Mininet simulator, which is a network platform simulator capable of creating virtual hosts, switches, controllers and links. Mininet hosts run standard Linux network software. Mininet virtual hosts, switches, links and controllers are created by software, making them look like a complete network. In Mininet simulator, three hosts are opened by xterm command. IPv6 addresses configured for multicast sender are fc00::1/64, and IPv6 addresses configured for two subscribers are fc00::2/64 and fc00::3/4. The three hosts respectively run their own programs to receive multicast traffic and output the source and time of receiving multicast traffic. The experimental results are shown in the following figure. Two subscribers can receive the same data at the same time.
Author: Li Dan