WO2019050424A1 - Method of minimizing multicast traffic and providing fault tolerance in sdn networks - Google Patents

Method of minimizing multicast traffic and providing fault tolerance in sdn networks Download PDF

Info

Publication number
WO2019050424A1
WO2019050424A1 PCT/RU2017/000453 RU2017000453W WO2019050424A1 WO 2019050424 A1 WO2019050424 A1 WO 2019050424A1 RU 2017000453 W RU2017000453 W RU 2017000453W WO 2019050424 A1 WO2019050424 A1 WO 2019050424A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
tree
group
rules
traffic
Prior art date
Application number
PCT/RU2017/000453
Other languages
French (fr)
Russian (ru)
Inventor
Иван Сергеевич ПЕТРОВ
Александр Владиславович ШАЛИМОВ
Руслан Леонидович СМЕЛЯНСКИЙ
Original Assignee
Некоммерческое Партнерство "Центр Прикладных Исследований Компьютерных Сетей"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Некоммерческое Партнерство "Центр Прикладных Исследований Компьютерных Сетей" filed Critical Некоммерческое Партнерство "Центр Прикладных Исследований Компьютерных Сетей"
Priority to PCT/RU2017/000453 priority Critical patent/WO2019050424A1/en
Publication of WO2019050424A1 publication Critical patent/WO2019050424A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast

Definitions

  • the technical solution relates to the field of computer networks, namely to the field of resource flow management in networks, intended for group routing and minimization of group traffic in software-defined networks.
  • IP multicast is the most common multicast implementation for traditional networks today.
  • the current IP multicast standard is PIM-SM (Farinacci D. et al. Protocol independent multicast-sparse mode (PIM-SM): Protocol specification. - 1998.), which uses the shortest-path tree to connect boundary nodes in the multicast group, where a border node is some kind of dedicated router connected to the network with at least one multicast group client.
  • PIM-SM Fibreviations D. et al. Protocol independent multicast-sparse mode
  • IP multicast There are many problems in the practical implementation of IP multicast.
  • One of the important problems is that routing protocols for IP multicast, such as Protocol Independent Multicast - Sparse Mode (PIM-SM), are not designed to build optimal traffic routing trees.
  • PIM-SM Protocol Independent Multicast - Sparse Mode
  • the shortest path trees obtained during the operation of this protocol may use a large number of physical lines and occupy a significant portion of the network’s overall capacity, thus, not being optimal in terms of network load.
  • the STP protocol is a protocol for creating a spanning tree on an Ethernet network that dynamically disables redundant (by the criteria of this protocol) lines.
  • IGMP snooping is a mechanism that prevents excessive multicast traffic on the link layer.
  • a switch that supports IGMP snooping analyzes the IGMP packets that pass through it, identifying clients connected to multicast groups. This allows switches send multicast traffic only through the ports to which its consumers are connected, thereby significantly reducing the load on the network.
  • the ports that can pass IGMP messages belong to the STP ports of the switch, so multicast traffic can only pass through lines belonging to the Ethernet spans.
  • rebuilding the spanning tree will result in customers not receiving multicast traffic for a considerable time.
  • Avalanche Routing Algorithm A routing algorithm for multicast traffic, called the Avalanche Routing Algorithm (AvRA), was also developed, which minimizes the size of the multicast tree for each group separately.
  • AvRA is a polynomial randomized algorithm that builds a routing tree of multicast traffic, trying to connect each new member of a multicast group with the nearest point of a multicast tree.
  • the AvRA algorithm does not provide an optimal solution for networks with an arbitrary topology. However, for frequently used topologies in practice, such as Tree and FatTree, the algorithm finds the optimal solution with a probability close to one, the algorithm does so with a high probability for most real network topologies. For example, for Tree and FatTree, the probability is 1. If the AvRA algorithm is not able to find the optimal solution, then a solution is found that is equivalent to the equivalent solution that PIM-SM would find.
  • VAERHA Branch Aware Edge Reduction Algorithm
  • the technical result from the use of this technical solution is to minimize the amount of multicast traffic by various criteria and ensure the sustainability of multicast traffic to transmission line failures and SDN switches.
  • This technical result is achieved due to the implementation in the L2 environment, using the SDN technology, the propagation tree of multicast traffic, the possibility of optimally rebuilding the multicast tree and restoring the transmission of multicast traffic after transmission line failures or SDN switches, as well as the possibility of choosing various criteria by which The tree of multicast traffic propagation, namely the criteria Hop, Port speed and Load.
  • a method for minimizing multicast traffic and ensuring its fault tolerance in PKS networks characterized in that: they define multicast groups and active traffic sources; set rules on all openstream network switches; receive igmp messages from the client on the port of the switching device; send this message to the controller for further analysis; based on the message received on the controller, determine the port on which the client resides, which has requested the multicast group; choose the source of multicast traffic from the list of sources; carry out the construction of the path from the source to the multicast client according to various criteria; determine the switching devices for which it is necessary to establish routing rules; set the switching rules defined in the previous step switching devices; determined by the controller network status changes; carry out the rebuilding of a multicast tree according to different criteria, taking into account the network topology updated at the previous step; determine the presence of clients not receiving multicast traffic; update openflow rules on switching devices so that all clients receive multicast traffic.
  • Figure 1 - Algorithm 1 Construction of a multicast tree
  • Figure 2 - Algorithm 2 Construction of a tree of shortest paths
  • Fig.Z - Algorithm 3 Construction of maxmin tree
  • a system means a computer system, a computer (electronic computer), a CNC (numerical control), a PLC (programmable logic controller), computerized control systems, and any other devices capable of performing a predetermined, well-defined sequence of operations (actions, instructions).
  • a command processing device is an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).
  • the command processing device reads and executes machine instructions (programs) from one or more data storage devices.
  • a storage device can act, but not limited to, hard drives (HDD), flash memory, ROM (read-only memory), solid-state drives (SSD), optical drives (CD, DVD, Blue-Ray drives).
  • a program is a sequence of instructions intended for execution by a computer control device or command processing device.
  • V the set of vertices corresponding to the switches
  • E the set of edges represented by pairs (, and) if the switches v and and are connected by a physical line.
  • n the number of vertices
  • m the number of edges of the graph G.
  • the set M M () ⁇ V is defined, called the set of group members.
  • Member of group d is called the switch to which recipients of multicast traffic are connected to group D. Participants can both connect to a group and disconnect from it.
  • the vertex s is allocated - a group member, called a group server, the server is the starting point for the multicast traffic of this group.
  • the function c (, u) is defined: E— * Z 0 representing the channel capacity between v and and such that 0 ⁇ c (v, u).
  • the function lv, u) is also defined: ⁇ - » 0 representing the channel load between v and and at time t. Routing task
  • the problem of routing multicast traffic on a network can be formulated as follows: for any multicast group Q find the subgraph T (e) of the graph G such that G is a tree and T contains vertices from M.
  • the tree T (e) is called multicast tree for group d.
  • a multicast tree T is said to be optimal by the criterion Nor, if for any vertex from v E M the path from v to s in the tree T is the shortest path between v and s in the graph G.
  • the solution to the problem will be the shortest path tree.
  • the paths between the group members are chosen so that the minimum bandwidth of the ribs is maximum.
  • a multicast tree T is called optimal by the Load criterion if the tree T is a tree of minimal cost and contains all vertices v G M.
  • the cost of the graph edges is set equal to 1, that is, the cost is an indicator of some edge.
  • the constructed tree is a tree with the minimum number of edges.
  • the described task is the Steiner problem on graphs. Vertices t G V ⁇ M can be used if necessary. Vertices t are called Steiner points. It is proved that this problem is NP-hard.
  • the solution to the problem of ensuring fault tolerance is a set of operations for rebuilding a multicast tree T when the state of the network changes, such that the tree T 'obtained after rebuilding is optimal from the point of view of the criteria set forth above.
  • This technical solution minimizes the amount of multicast traffic according to various criteria and the sustainability of multicast traffic to transmission line failures and SDN switches by implementing in an L2 environment using SDN technology, a tree of multicast traffic propagation, the possibility of optimally rebuilding a multicast tree and restoring multicast traffic after failures of transmission lines or SDN switches, as well as the possibility of choosing various criteria by which the propagation tree of multicast traffic is built, namely the criteria Hop, Port speed and Load ..
  • a method for minimizing multicast traffic and ensuring its fault tolerance in PKS networks, characterized in that: they define multicast groups and active traffic sources; set rules on all openstream network switches; receive igmp messages from the client on the port of the switching device; send this message to the controller for further analysis; based on the message received on the controller, determine the port on which the client resides, which has requested the multicast group; choose the source of multicast traffic from the list of sources; carry out the construction of the path from the source to the multicast client according to various criteria; determine the switching devices for which it is necessary to establish routing rules; set the switching rules defined in the previous step switching devices; determined by the controller to change the state of the network; carry out the rebuilding of a multicast tree according to different criteria, taking into account the network topology updated at the previous step; determine the presence of clients not receiving multicast traffic; update openflow rules on switching devices in such a way so that all customers receive multicast traffic.
  • the algorithm for constructing a spanning tree is a Breadth First Search (BFS) graph traversal.
  • BFS Breadth First Search
  • the tree constructed according to algorithm 2 multicast is optimal by the criterion Nor.
  • the complexity of algorithm 2 is 0 (n + m).
  • the branch from the BFS tree containing the vertex v is added to the multicast tree.
  • the branch containing the vertex V is trimmed in a multicast tree. Pruning a branch takes place to a certain vertex that has more than one descendant.
  • the maxmin tree construction algorithm is a modified Dijkstra's algorithm for finding the shortest paths from a certain vertex of the graph to all others.
  • the tree constructed by algorithm 3 multicast is optimal by criterion
  • the edge weight is that line capacity that will be occupied if the multicast traffic of the group for which the tree is being built passes through this line. Since for each particular multicast group on each line used by the group, the bandwidth is the same, the edge weights in the graph of the G network used in the Steiner tree construction algorithm are the same. Also, edge weights denote line loading by each multicast group separately, therefore network bandwidth occupied by other groups is not taken into account in the algorithm.
  • Algorithm 4 describes CMS heuristics.
  • leaf (T ⁇ ) means the set of leaf vertices of the tree T.
  • edge e corresponding to this line is removed, and it is necessary to reconnect clients using some siding, that is, a path that does not contain a remote edge.
  • the number A min ⁇ I ⁇ E ⁇ G (V, E ⁇ 7) is not connected ⁇ is called the number of edge connectivity of the graph.
  • edge connectivity is the minimum number of edges of the graph that must be removed in order for the graph to cease to be connected.
  • the change of the multicast tree needs to be made only on V, therefore, the change of the multicast routes will not affect users from T ⁇ v.
  • a new edge is an edge that was previously removed from the graph. G.
  • the change of the paths in the new tree will occur only for those clients who were affected by some previous edge deletions.
  • the paths to clients that were not affected by these deletions will not be changed, and they will not experience packet delays / losses associated with the installation of OpenFlow rules on the network.
  • the second is that a new edge is really new.
  • Edge data may appear on the network if the physical configuration of the network changes, for example, when new equipment is installed. In this case, rebuilding a multicast tree is a reasonable measure, because it can lead to an optimal distribution of multicast traffic on the network.
  • the Steiner tree will be rebuilt only if the cost of the multicast tree exceeds the cost of the tree constructed using the CMS heuristics by some threshold ⁇ .
  • the proposed approach was implemented as a network application for the RunOS SDN controller.
  • the application stores information about each multicast group represented on the network. For each group, a set of pairs (switch, port) is specified, which determines the locations of the servers providing this multicast group on the network.
  • a server can mean both a physical server connected to this port and a router receiving multicast groups using L3 protocols, such as PIM, DVMRP, etc.
  • L3 protocols such as PIM, DVMRP, etc.
  • a message from the IGMP Join group is sent to the server of this group so that the server initiates sending multicast traffic. If the last client disconnects from this multicast group, an IGMP Leave group message is sent to the group server so that the server stops sending traffic.
  • Join and Leave group messages are sent from the switch port connected to this source by sending messages to the OpenFlow switch - Packet-Out.
  • the application receives information about the network topology from the topology application. Further, for each group, depending on the optimality criterion for the multicast tree of this group, a spanning tree is built, which will subsequently be searched for paths connecting the multicast server with the multicast client. These spanning trees are built on the basis of the algorithms described in the previous chapter.
  • a rule is set for each SDN switch that redirects all IGMP requests to the controller. These messages are sent to the controller using OpenFlow messages - Packet-In.
  • the application on the controller processes the request data.
  • the controller searches for the path from the multicast server to the client that sent the group join request.
  • the application receives the Packet-In message from the fields about which switch port the request has received.
  • the application After finding the route from the server to the client, the application installs the corresponding rules on the switches included in this path. Also, if this is the first client to request this group, then the IGMP join group sends a request to the port on which the server of this multicast group is located. If the client is not the first to connect to this group, then the path to the client begins to be established not from the switch connected to the multicast server, but from the nearest point located in the multicast tree (the closest point is considered in the spanning tree built for this multicast group).
  • the Flow rule is set, in the match field of which the port and ip-dst are set.
  • the in-port is the port through which this switch connects to the switch that precedes the path from the server to the client.
  • the ip address of the multicast group is set in the ip-dst field.
  • this rule processes only packets coming from a multicast server and belonging to the corresponding group.
  • the action field is set to the number of the group OpenFlow rule corresponding to this multicast group.
  • Group rules are as follows:
  • the group is an AH group, that is, the packages are duplicated on each bucket.
  • the bucket'oB set is determined by the current structure of the multicast tree, that is, if in the spanning tree of this group the vertex identified by the switch has several child vertices, then for each vertex a bucket is created that sends traffic to the port connecting this switch to the switch that corresponds to it child node Thus, the traffic spreads over a multicast tree. Further, this pair of rules (Flow, Group) will be called multicast rules.
  • a method of combining the same type of group rules into one single rule is proposed to reduce the total number of rules set on the switches.
  • the rule aggregation procedure consists of combining OpenFIow group rules with the identical set of bucket'oB into one rule, as well as changing the dst_group field to a new group in the corresponding Flow rules.
  • the first step is to create merged rules from a set of multicast rules created for each multicast group.
  • the application stores a list of un-interconnected multicast rules and a list of actual rules installed on the switches.
  • each aggregated rule which shows the number of multicast rules associated with it.
  • a rule is deleted from the switchboard only when all such multicast rules associated with it are deleted, that is, the counter becomes zero.
  • the second step is to update the state of the switches.
  • State update occurs after events that change the configuration of multicast rules on the network, such as connecting / disconnecting clients, breaking / restoring lines, dropping / connecting switches. These events affect all groups, so the state of switches changes only after the procedure of combining all the rules associated with all multicast groups.
  • the aggregator compares lists of existing rules and lists of updated rules. If there are rules that participate in only one list, they are either deleted from the switch (if they are not in the updated list), or are set (if they are not on the switch, but they are in the updated list). Also change the corresponding flow rules.
  • IGMP message - IGMP join group - execution of points 6-15 Selecting the source of multicast traffic from the list of specified sources.) Automatic construction of the path from the source to the multicast client using various criteria (Hop, Port Speed, Load) using tree-building algorithms described in .1 of this paragraph.
  • the criterion for constructing trees can be, as previously set by the administrator, or selected by the default algorithm.
  • the IGMP join group controller sends a Packet-Out message to the multicast traffic source using the OpenFlow. ) Transmission of multicast traffic from the port connected to the source to the ports connected to clients via the network installed on the multicast network.
  • the source does not have this group, then go to (6) and select another server. If there are no more servers, notify the network administrator about the absence of a given multicast group on the network.) Periodically polling multicast clients with IGMP query messages and periodically sending IGMP request to the multicast traffic source.
  • the IGMP leave group controller sends a packet-out message to the source of multicast traffic using the OpenFlow.
  • the source does not have this group, then go to (6) and select another server. If there are no more servers, notify the network administrator about the absence of a given multicast group on the network.
  • the list of sources is set by the network administrator in the form of pairs (switch, port) to which sources of multicast traffic are connected.
  • Load criterion is selected as a criterion, then when the first client is connected, this client connects to the source of multicast traffic by the shortest path constructed using the Dijkstra algorithm. Subsequent clients connect the shortest path with the top of the already constructed tree nearest to this client.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to the field of computer networks. A method of minimizing multicast traffic and providing fault tolerance in SDN networks is characterized in that it involves: identifying multicast groups and active sources of traffic; establishing openflow rules on all the switching devices in a network; receiving igmp messages from a client on a port of a switching device; sending said message to a controller for further analysis; identifying, on the basis of the message received on the controller, the port on which the client requesting a multicast group is located; selecting a source of multicast traffic from a list of sources; building a path from the source to the multicast client according to various criteria; identifying the switching devices on which routing rules must be established; establishing switching rules on the switching devices identified in the previous step; identifying a change in the state of the network by means of the controller; rebuilding a multicast tree according to various criteria, taking into account the network topology updated in the previous step; identifying the presence of clients not receiving multicast traffic; updating the openflow rules on the switching devices so that all clients receive multicast traffic.

Description

СПОСОБ МИНИМИЗАЦИИ МНОГОАДРЕСНОГО ТРАФИКА И ОБЕСПЕЧЕНИЯ ЕГО ОТКАЗОУСТОЙЧИВОСТИ В ПКС СЕТЯХ METHOD OF MINIMIZATION OF MULTI-ADDRESS TRAFFIC AND ENSURING ITS FAILURE RESISTANCE IN PKS NETWORKS
ОБЛАСТЬ ТЕХНИКИ TECHNICAL FIELD
Техническое решение относится к области компьютерных сетей, а именно к области управления потоками ресурсов в сетях, предназначено для групповой маршрутизации и минимизации группового трафика в программно-конфигурируемых сетях.  The technical solution relates to the field of computer networks, namely to the field of resource flow management in networks, intended for group routing and minimization of group traffic in software-defined networks.
УРОВЕНЬ ТЕХНИКИ BACKGROUND
Из уровня техники известны следующие решения:  The prior art known solutions:
Решения для традиционных сетей.  Solutions for traditional networks.
IP multicast - наиболее распространенная на сегодняшний день реализация multicast для традиционных сетей. Текущим стандартом IP multicast является PIM-SM (Farinacci D. et al. Protocol independent multicast-sparse mode (PIM-SM): Protocol specification. - 1998.), который использует дерево кратчайших путей для соединения граничных узлов в multicast группе, где под граничным узлом понимается некоторый выделенный маршрутизатор, подключенный к сети хотя бы с одним клиентом multicast группы.  IP multicast is the most common multicast implementation for traditional networks today. The current IP multicast standard is PIM-SM (Farinacci D. et al. Protocol independent multicast-sparse mode (PIM-SM): Protocol specification. - 1998.), which uses the shortest-path tree to connect boundary nodes in the multicast group, where a border node is some kind of dedicated router connected to the network with at least one multicast group client.
Существует множество проблем в практической реализации IP multicast. Одной из важных проблем является то, что протоколы маршрутизации для IP multicast, такие как Protocol Independent Multicast - Sparse Mode (PIM-SM), не предназначены для построения оптимальных деревьев маршрутизации трафика. Деревья кратчайших путей, получаемые в ходе работы данного протокола, могут использовать большое количество физических линий и занимать значительную часть пропускной способности сети в целом, таким образом, не являясь оптимальными с точки зрения загрузки сети. There are many problems in the practical implementation of IP multicast. One of the important problems is that routing protocols for IP multicast, such as Protocol Independent Multicast - Sparse Mode (PIM-SM), are not designed to build optimal traffic routing trees. The shortest path trees obtained during the operation of this protocol may use a large number of physical lines and occupy a significant portion of the network’s overall capacity, thus, not being optimal in terms of network load.
Построение деревьев маршрутизации, на которых достигается минимум по количеству используемых физических линий, представляет собой задачу построения дерева Штейнера (М. Imase and В. М. Waxman, "Dynamic Steiner tree problem," SIAM lournal on Discrete Mathematics, vol. 4, no. 3, pp. 369-3S4, 1991.). Для произвольных графов, которые соответствуют топологиям традиционных сетей, известно, что задача построения дерева Штейнера является ΝΡ-полной (Winter P. Steiner problem in networks: a survey //Networks. - 1987. - T. 17. - 2. - С. 129-167), то есть алгоритм нахождения оптимального решения задачи Штейнера скорее всего не является полиномиальным, и таким образом представляет сложность для реализации его в виде распределенного протокола в традиционной сети. Поэтому алгоритмы на основе деревьев Штейнера почти не применяются в существующих multicast протоколах.  The construction of routing trees on which the minimum number of used physical lines is reached is the task of building a Steiner tree (M. Imase and V. M. Waxman, "Dynamic Steiner tree problem," SIAM lournal on Discrete Mathematics, vol. 4, no. 3, pp. 369-3S4, 1991.). For arbitrary graphs that correspond to the topologies of traditional networks, it is known that the task of building a Steiner tree is ΝΡ-complete (Winter P. Steiner problem in networks: a survey // Networks. - 1987. - T. 17. - 2. - C. 129-167), that is, the algorithm for finding the optimal solution of the Steiner problem is most likely not polynomial, and thus it is difficult to implement it in the form of a distributed protocol in a traditional network. Therefore, algorithms based on Steiner trees are almost never used in existing multicast protocols.
Важной проблемой для известных multicast протоколов является потеря пакетов во время процедуры перестроения multicast дерева. Эта процедура запускается при обнаружении отказа сетевых линий или узлов. Потеря пакетов происходит из-за того, что в IP multicast процедура перестроения дерева занимает слишком много времени (Wang X. et al. IP multicast fault recovery in PIM over OSPF //Network Protocols, 2000. Proceedings. 2000 International Conference on. - IEEE, 2000. - C. 116-125.).  An important problem for well-known multicast protocols is packet loss during the rebuilding procedure for a multicast tree. This procedure starts when a failure of network lines or nodes is detected. Packet loss occurs due to the fact that the IP multicast tree rebuilding procedure takes too much time (Wang X. et al. IP multicast fault recovery in PIM over OSPF // Network Protocols, 2000. Proceedings. 2000 International Conference on. - IEEE , 2000. - C. 116-125.).
Multicast маршрутизация на канальном уровне опирается на протокол STP и IGMP snooping - механизм отслеживания IGMP трафика. Протокол STP представляет собой протокол построения остовного дерева в сети Ethernet, динамически отключающего избыточные (по критериям этого протокола) линии.  Multicast routing at the data link layer relies on the STP protocol and IGMP snooping, the IGMP traffic tracking mechanism. The STP protocol is a protocol for creating a spanning tree on an Ethernet network that dynamically disables redundant (by the criteria of this protocol) lines.
IGMP snooping является механизмом, который предотвращает излишнее широковещание multicast трафика на канальном уровне. Коммутатор, поддерживающий IGMP snooping, анализирует проходящие через него IGMP пакеты, выявляя клиентов, подключенных к multicast группам. Это позволяет коммутаторам отправлять multicast трафик только через порты, к которым подключены его потребители, тем самым существенно снижая нагрузку на сеть. IGMP snooping is a mechanism that prevents excessive multicast traffic on the link layer. A switch that supports IGMP snooping analyzes the IGMP packets that pass through it, identifying clients connected to multicast groups. This allows switches send multicast traffic only through the ports to which its consumers are connected, thereby significantly reducing the load on the network.
Порты, по которым могут проходить IGMP сообщения, принадлежат STP портам коммутатора, поэтому multicast трафик может проходить только по линиям, принадлежащим остовому дереву Ethernet сети. Таким образом, невозможно производить настройку multicast дерева в зависимости от различных критериев, таких как нагрузка на линии, длина пути от источника до потребителя и т.д. Более того, в случае отключения какой-либо линии, перестроение остовного дерева приведет к тому, что клиенты не будут получать multicast трафик, в течение значительного времени.  The ports that can pass IGMP messages belong to the STP ports of the switch, so multicast traffic can only pass through lines belonging to the Ethernet spans. Thus, it is not possible to adjust the multicast tree depending on various criteria, such as the load on the line, the path length from the source to the consumer, etc. Moreover, in case of disconnection of any line, rebuilding the spanning tree will result in customers not receiving multicast traffic for a considerable time.
Решения для программно-конфигурируемых сетей.  Solutions for software-defined networks.
В статье Bondan L., Miiller L. R, Kist M. Multiflow: Multicast clean- slate with anticipated route calculation on OpenFlow programmable networks //Journal of Applied Computing Research. - 2013. - T. 2. - JNb. 2. - C. 68-74. предлагается использовать приложение на SDN контроллере NOX, которое производит обработку IGMP запросов от клиентов и установку multicast маршрутов в сети. Для вычисления наилучшего маршрута используется алгоритм Дейкстры для нахождения кратчайшего пути (М. R. Garey, D. S. Johnson, Computers and Intractability: A Guide to the Theory of NP- completeness, W.H. Freeman and Company, 1979.). В качестве весов ребер используется расстояние между узлами в сети (количество пор'ов).  In the article, Bondan L., Miiller L. R, Kist M. Multiflow: Multicast cleanest with anticipated calculation programs on OpenFlow programmable networks // Journal of Applied Computing Research. - 2013. - T. 2. - JNb. 2. - C. 68-74. It is proposed to use the application on the NOX SDN controller, which processes IGMP requests from clients and installs multicast routes on the network. To calculate the best route, Dijkstra's algorithm is used to find the shortest path (M. R. Garey, D.S. Johnson, Computers and Intractability: A Guide to the Theory of NP-completeness, W.H. Freeman and Company, 1979.). The weights of the edges are the distance between the nodes in the network (the number of pores).
В статье Iyer A., Kumar P., Mann V. Avalanche: Data center multicast using software defined networking //2014 Sixth International Conference on Communication Systems and Networks (COMSNETS). - IEEE, 2014. - C. 1- 8. представлена система для SDN сети, реализующая маршрутизацию multicast трафика в центрах обработки данных (ЦОД). Также был разработан алгоритм маршрутизации multicast трафика, называемый Avalanche Routing Algorithm (AvRA), который минимизирует размер multicast дерева для каждой группы в отдельности . AvRA это полиномиальный рандомизированный алгоритм, который строит дерево маршрутизации multicast трафика, пытаясь соединить каждого нового члена multicast группы с ближайшей к нему точкой multicast дерева. Алгоритм AvRA не дает оптимального решения для сетей с произвольной топологией. Однако, для часто используемых на практике топологий, таких как Tree и FatTree, алгоритм находит оптимальное решение с вероятностью близкой к единице, алгоритм делает это с высокой вероятностью для большинства реальных сетевых топологий . Например, для Tree и FatTree, вероятность равна 1. В случае если алгоритм AvRA не способен найти оптимальное решение, то находится решение, которое эквивалентно эквивалентное решению, которое нашел бы PIM-SM. The article by Iyer A., Kumar P., Mann V. Avalanche: Data center multicast using software defined networking // 2014 Sixth International Conference on Communication Systems and Networks (COMSNETS). - IEEE, 2014. - p. 1-8. Presents a system for an SDN network that implements the routing of multicast traffic in data processing centers (DPC). A routing algorithm for multicast traffic, called the Avalanche Routing Algorithm (AvRA), was also developed, which minimizes the size of the multicast tree for each group separately. AvRA is a polynomial randomized algorithm that builds a routing tree of multicast traffic, trying to connect each new member of a multicast group with the nearest point of a multicast tree. The AvRA algorithm does not provide an optimal solution for networks with an arbitrary topology. However, for frequently used topologies in practice, such as Tree and FatTree, the algorithm finds the optimal solution with a probability close to one, the algorithm does so with a high probability for most real network topologies. For example, for Tree and FatTree, the probability is 1. If the AvRA algorithm is not able to find the optimal solution, then a solution is found that is equivalent to the equivalent solution that PIM-SM would find.
В статье Huang L. Н. et al. Scalable Steiner tree for multicast communications in software-defined networking //arXiv preprint arXiv:1404.3454. - 2014. предлагается использовать в качестве multicast дерева - дерево под названием Branch-aware Steiner Tree (В ST). Отличие В ST дерева от дерева Штейнера состоит в том, что при построении минимизируется не только количество используемых линковлиний, но и количество узлов ветвления.  The article by Huang L. N. et al. Scalable Steiner tree for multicast communications in software-defined networking // arXiv preprint arXiv: 1404.3454. - 2014. it is proposed to use as a multicast tree - a tree called Branch-aware Steiner Tree (B ST). The difference in a ST tree from a Steiner tree is that when building, not only the number of link lines used is minimized, but also the number of branch nodes.
Авторами статьи доказано, что нахождение Branch-aware Steiner Tree это ΝΡ-трудная задача. Более того, в то время как для дерева Штейнера существуют аппроксимационные алгоритмы, которые строят решение стоимости не более чем 1.55 * ОРТ (ОРТ - стоимость дерева Штейнера), для Branch-aware Steiner Tree не существует аппроксимационного алгоритма, дающего решение, отличающееся от оптимального на множитель к1_Е, для любого ε > 0 (к - число участников multicast группы. Другими словами, решение данной задачи сложно аппроксимировать. The authors of the article proved that finding Branch-aware Steiner Tree is a ΝΡ-difficult task. Moreover, while for the Steiner tree there are approximation algorithms that build a solution of no more than 1.55 * ORT (ORT is the cost of the Steiner tree), for the Branch-aware Steiner Tree there is no approximation algorithm that gives a solution that differs from the optimal one by factor to 1_E , for any ε> 0 (k is the number of participants in the multicast group. In other words, the solution to this problem is difficult to approximate.
Авторы статьи предлагают k-аппроксимационный алгоритм для решения поставленной задачи. Данный алгоритм называется Branch Aware Edge Reduction Algorithm (ВАЕРхА).,Также авторы отмечают, что данный алгоритм который может быть использован для нахождения multicast дерева в SDN сети. The authors of the article propose a k-approximation algorithm for solving the problem. This algorithm is called Branch Aware Edge Reduction Algorithm (VAERHA). Also, the authors note that this algorithm which can be used to find a multicast tree in the SDN network.
СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ ESSENCE OF TECHNICAL SOLUTION
Данное техническое решение направлено на устранение недостатков, присущих существующим аналогам.  This technical solution is aimed at eliminating the disadvantages inherent in existing analogues.
Технический результат от использования данного технического решения заключается в минимизации количества multicast трафика по различным критериям и обеспечении устойчивости multicast трафика к отказам линий передач и SDN коммутаторов.  The technical result from the use of this technical solution is to minimize the amount of multicast traffic by various criteria and ensure the sustainability of multicast traffic to transmission line failures and SDN switches.
Данный технический результат достигается за счет реализации в L2 среде, при помощи использования технологии SDN, дерева распространения multicast трафика, возможности оптимального перестроения multicast дерева и восстановления передачи multicast трафика после отказов линий передач или SDN коммутаторов, а также возможности выбора различных критериев, по которым строится дерево распространения multicast трафика, а именно критерии Hop, Port speed и Load.  This technical result is achieved due to the implementation in the L2 environment, using the SDN technology, the propagation tree of multicast traffic, the possibility of optimally rebuilding the multicast tree and restoring the transmission of multicast traffic after transmission line failures or SDN switches, as well as the possibility of choosing various criteria by which The tree of multicast traffic propagation, namely the criteria Hop, Port speed and Load.
В одном из предпочтительных вариантов реализации предложен способ минимизации многоадресного трафика и обеспечения его отказоустойчивости в ПКС сетях, характеризующийся тем что: определяют multicast группы и активные источники трафика; устанавливают на всех коммутирующих устройствах в сети openflow правила; получают igmp сообщения от клиента на порту коммутирующего устройства; оправляют данное сообщение на контроллер для дальнейшего анализа; на основе полученного на контроллере сообщения, определяют порт, на котором находится клиент, запросивший multicast группу; выбирают источник multicast трафика из списка источников; осуществляют построение пути от источника до multicast клиента по различным критериям; определяют коммутирующие устройства, на которые необходимо установить правила маршрутизации; устанавливают на определенные на предыдущем шаге коммутирующие устройства правила коммутации; определяют контроллером изменения состояния сети; осуществляют перестроение multicast дерева по различным критериям с учетом обновленной на предыдущем шаге топологии сети; определяют наличие клиентов, не получающих multicast трафика; обновляют openflow правила на коммутирующих устройствах таким образом, чтобы все клиенты получали multicast трафик. In one of the preferred implementation options, a method is proposed for minimizing multicast traffic and ensuring its fault tolerance in PKS networks, characterized in that: they define multicast groups and active traffic sources; set rules on all openstream network switches; receive igmp messages from the client on the port of the switching device; send this message to the controller for further analysis; based on the message received on the controller, determine the port on which the client resides, which has requested the multicast group; choose the source of multicast traffic from the list of sources; carry out the construction of the path from the source to the multicast client according to various criteria; determine the switching devices for which it is necessary to establish routing rules; set the switching rules defined in the previous step switching devices; determined by the controller network status changes; carry out the rebuilding of a multicast tree according to different criteria, taking into account the network topology updated at the previous step; determine the presence of clients not receiving multicast traffic; update openflow rules on switching devices so that all clients receive multicast traffic.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ BRIEF DESCRIPTION OF THE DRAWINGS
Фиг.1 - Алгоритм 1 : Построение multicast дерева;  Figure 1 - Algorithm 1: Construction of a multicast tree;
Фиг.2 - Алгоритм 2: Построение дерева кратчайших путей;  Figure 2 - Algorithm 2: Construction of a tree of shortest paths;
Фиг.З - Алгоритм 3 : Построение maxmin дерева;  Fig.Z - Algorithm 3: Construction of maxmin tree;
Фи г.4 Алгоритм 4: кмв эвристика. Fi g4 Algorithm 4: kmv heuristics.
ПОДРОБНОЕ ОПИСАНИЕ ТЕХНИЧЕСКОГО РЕШЕНИЯ DETAILED DESCRIPTION OF THE TECHNICAL SOLUTION
В данном устройстве под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, чётко определённую последовательность операций (действий, инструкций).  In this device, a system means a computer system, a computer (electronic computer), a CNC (numerical control), a PLC (programmable logic controller), computerized control systems, and any other devices capable of performing a predetermined, well-defined sequence of operations (actions, instructions).
Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы).  A command processing device is an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).
Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические накопители информации (CD, DVD, Blue-Ray диски).  The command processing device reads and executes machine instructions (programs) from one or more data storage devices. In the role of a storage device can act, but not limited to, hard drives (HDD), flash memory, ROM (read-only memory), solid-state drives (SSD), optical drives (CD, DVD, Blue-Ray drives).
Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.  A program is a sequence of instructions intended for execution by a computer control device or command processing device.
Для понимания разработанного решения приведем общую постановку задач маршрутизации, оптимизации и отказоустойчивости.  To understand the developed solution, we present a general formulation of the routing, optimization, and fault tolerance problems.
Представим сеть в виде графа G(V; F), где V - множество вершин, соответствующих коммутаторам, а Е - множество ребер, представленных парами ( , и), если коммутаторы v и и соединены физической линией. Обозначим через п - количество вершин, а через т - количество ребер графа G.  We represent the network in the form of a graph G (V; F), where V is the set of vertices corresponding to the switches, and E is the set of edges represented by pairs (, and) if the switches v and and are connected by a physical line. Denote by n the number of vertices, and m the number of edges of the graph G.
Для каждой multicast группы д определено множество М = M( ) <Ξ V, называемое множеством участников группы. Участником группы д называется коммутатор, к которому подключены получатели multicast трафика группы д. Участники могут, как подключаться к некоторой группе, так и отключаться от нее. Среди множества М выделена вершина s - участник группы, называемый сервером группы, сервер является исходной точкой для multicast трафика данной группы. For each multicast group g, the set M = M () <Ξ V is defined, called the set of group members. Member of group d is called the switch to which recipients of multicast traffic are connected to group D. Participants can both connect to a group and disconnect from it. Among the set M, the vertex s is allocated - a group member, called a group server, the server is the starting point for the multicast traffic of this group.
Для всех ребер (у, ) Е Е определена функция c( , u): E—* Z0 представляющая собой пропускную способность канала между v и и такую, что 0 < c(v, u). Также определена функция l v, u): Е -» 0 представляющая собой загрузку канала между v и и в момент времени t. Задача маршрутизации For all edges (y,) Е Е, the function c (, u) is defined: E— * Z 0 representing the channel capacity between v and and such that 0 <c (v, u). The function lv, u) is also defined: Е - » 0 representing the channel load between v and and at time t. Routing task
В терминах введенных обозначений, задача маршрутизации multicast трафика в сети может быть сформулирована следующим образом: для любой multicast группы Q найти подграф Т{д) графа G, такой, что Г является деревом и Т содержит вершины из М. Дерево Т(д) называется multicast деревом для группы д.  In terms of the introduced notation, the problem of routing multicast traffic on a network can be formulated as follows: for any multicast group Q find the subgraph T (e) of the graph G such that G is a tree and T contains vertices from M. The tree T (e) is called multicast tree for group d.
Задача оптимизации Optimization task
Рассматриваются три различных критерия оптимальности multicast дерева Т  Three different optimal criteria for multicast tree T are considered.
1) Нор  1) Nor
2) Port speed  2) Port speed
3) Load  3) Load
Определение. Длиной пути Р: ν = Ρο,Ρι,—, Рк = w назовем количество дуг в пути Р. Definition The length of the path P: ν = Ρο, Ρι, -, Pk = w is the number of arcs in the path of R.
Определение. Кратчайшим путем между вершинами v и в графе G(V, Е) называется путь P.- v = p0,plt ..., pk = и такой, что
Figure imgf000010_0001
Definition The shortest path between the vertices v and in the graph G (V, E) is the path P.- v = p 0 , p lt ..., p k = and such that
Figure imgf000010_0001
Определение. Multicast дерево Т назовем оптимальным по критерию Нор, если для любой вершины из v Е М путь из v в s в дереве Т является кратчайшим путем между v и s в графе G. Definition A multicast tree T is said to be optimal by the criterion Nor, if for any vertex from v E M the path from v to s in the tree T is the shortest path between v and s in the graph G.
То есть решением задачи будет являться дерево кратчайших путей.  That is, the solution to the problem will be the shortest path tree.
Определение. Maxmin путем по критерию с между вершинами v и в графе G, где c: E ^ Z0, называется путь Pz v = р0,р1, ..., рк = и такой, что функция т Р)—
Figure imgf000011_0001
t \i = 1, к} максимальна. Definition Maxmin path by criterion с between vertices v and in the graph G, where c: E ^ Z 0 , is called the path Pz v = p 0 , p 1 , ..., p k = and such that the function m P) -
Figure imgf000011_0001
t \ i = 1, k} is maximal.
Определение. Multicast дерево Г назовем оптимальным по критерию Port speed, если для любой вершины из V М путь из V в s в дереве Т является maxmin путем по критерию с между V и s в графе бгде с = c Vj Ti) - пропускная способность канала 7Ш.  Definition A multicast tree Γ is called Port speed optimal by the criterion if for any vertex of V M the path from V to s in the tree T is maxmin path by criterion C between V and s in the column where c = c Vj Ti) is the bandwidth of the channel 7Ш.
То есть пути между участниками группы выбираются так, чтобы минимальное значение пропускной способности ребер было максимальным.  That is, the paths between the group members are chosen so that the minimum bandwidth of the ribs is maximum.
Определение. Стоимостью дерева Т называется величина νν(Γ) = (v,i eT w(.v, u), где w(v, u - стоимость ребра между v и и. Definition The value of the tree T is the quantity νν (Γ) = ( v , i eT w ( . V, u), where w (v, u is the cost of the edge between v and and.
Определение. Multicast дерево Т называется является оптимальным по критерию Load, если дерево Т является деревом минимальной стоимости и содержит все вершины v G М.  Definition A multicast tree T is called optimal by the Load criterion if the tree T is a tree of minimal cost and contains all vertices v G M.
В данной задаче стоимость ребер графа выставляется равной 1 , то есть стоимость является индикатором некоторого ребра. Таким образом, построенное дерево является деревом, минимальным по количеству ребер.  In this task, the cost of the graph edges is set equal to 1, that is, the cost is an indicator of some edge. Thus, the constructed tree is a tree with the minimum number of edges.
Описанная задача является задачей Штейнера на графах. Вершины t G V\M могут быть использованы, если это необходимо. Вершины t называются точками Штейнера. Доказано, что данная задача является NP- трудной.  The described task is the Steiner problem on graphs. Vertices t G V \ M can be used if necessary. Vertices t are called Steiner points. It is proved that this problem is NP-hard.
Задача обеспечения отказоустойчивости Fault tolerance task
Решением задачи обеспечения отказоустойчивости является набор операций перестроения multicast дерева Т при изменении состояния сети, такого, что полученное после перестроения дерево Т' является оптимальным с точки зрения критериев, поставленных выше.  The solution to the problem of ensuring fault tolerance is a set of operations for rebuilding a multicast tree T when the state of the network changes, such that the tree T 'obtained after rebuilding is optimal from the point of view of the criteria set forth above.
Под изменением состояния сети подразумевается: 1) Подключение/отключение клиента от некоторой multicast группы.By changing the state of the network is meant: 1) Connect / disconnect a client from some multicast group.
2) Отключение/восстановление линии между двумя коммутаторами.2) Disable / restore the line between the two switches.
3) Отключение/восстановление некоторого коммутатора. 3) Turn off / restore some switch.
Данное техническое решение обеспечивает минимизацию количества multicast трафика по различным критериям и устойчивость multicast трафика к отказам линий передач и SDN коммутаторов за счет реализации в L2 среде, при помощи использования технологии SDN, дерева распространения multicast трафика, возможности оптимального перестроения multicast дерева и восстановления передачи multicast трафика после отказов линий передач или SDN коммутаторов, а также возможности выбора различных критериев, по которым строится дерево распространения multicast трафика, а именно критерии Hop, Port speed и Load..  This technical solution minimizes the amount of multicast traffic according to various criteria and the sustainability of multicast traffic to transmission line failures and SDN switches by implementing in an L2 environment using SDN technology, a tree of multicast traffic propagation, the possibility of optimally rebuilding a multicast tree and restoring multicast traffic after failures of transmission lines or SDN switches, as well as the possibility of choosing various criteria by which the propagation tree of multicast traffic is built, namely the criteria Hop, Port speed and Load ..
Согласно предлагаемому техническому решению, предложен способ минимизации многоадресного трафика и обеспечения его отказоустойчивости в ПКС сетях, характеризующийся тем что: определяют multicast группы и активные источники трафика; устанавливают на всех коммутирующих устройствах в сети openflow правила; получают igmp сообщения от клиента на порту коммутирующего устройства; оправляют данное сообщение на контроллер для дальнейшего анализа; на основе полученного на контроллере сообщения, определяют порт, на котором находится клиент, запросивший multicast группу; выбирают источник multicast трафика из списка источников; осуществляют построение пути от источника до multicast клиента по различным критериям; определяют коммутирующие устройства, на которые необходимо установить правила маршрутизации; устанавливают на определенные на предыдущем шаге коммутирующие устройства правила коммутации; определяют контроллером изменения состояния сети; осуществляют перестроение multicast дерева по различным критериям с учетом обновленной на предыдущем шаге топологии сети; определяют наличие клиентов, не получающих multicast трафика; обновляют openflow правила на коммутирующих устройствах таким образом, чтобы все клиенты получали multicast трафик. According to the proposed technical solution, a method has been proposed for minimizing multicast traffic and ensuring its fault tolerance in PKS networks, characterized in that: they define multicast groups and active traffic sources; set rules on all openstream network switches; receive igmp messages from the client on the port of the switching device; send this message to the controller for further analysis; based on the message received on the controller, determine the port on which the client resides, which has requested the multicast group; choose the source of multicast traffic from the list of sources; carry out the construction of the path from the source to the multicast client according to various criteria; determine the switching devices for which it is necessary to establish routing rules; set the switching rules defined in the previous step switching devices; determined by the controller to change the state of the network; carry out the rebuilding of a multicast tree according to different criteria, taking into account the network topology updated at the previous step; determine the presence of clients not receiving multicast traffic; update openflow rules on switching devices in such a way so that all customers receive multicast traffic.
1. Алгоритмы решения 1. Algorithm solutions
1.1 Критерий Нор 1.1 Criterion Nor
Для построения оптимального multicast дерева по критерию Нор необходимо построить дерево кратчайших путей из s в каждую вершину из группы М = М{д). Для построения такого дерева сначала строится остовное дерево кратчайших путей графа G (алг.2 - Фиг.2), а затем выбирается минимальное по критерию Нор поддерево, содержащее точки из М (алг.1 - Фиг.1).  To construct an optimal multicast tree by the Nor criterion, it is necessary to construct a shortest path tree from s to each vertex of the group M = M (d). To build such a tree, first, a spanning tree of the shortest paths of the graph G (alg.2 - Fig.2) is built, and then the minimum subtree according to the criterion Nor, containing points from M (alg.1 - Fig.1), is selected.
Алгоритм построения остовного дерева представляет собой обход графа в ширину (Breadth First Search - BFS) . На этапе поиска BFS дерево будет сохраняться список висячих вершин, чтобы затем, для получения результирующего multicast дерева, начать удаление поддеревьев, не содержащих вершины из М.  The algorithm for constructing a spanning tree is a Breadth First Search (BFS) graph traversal. At the BFS search stage, the list of hanging vertices will be saved in order to then, to get the resulting multicast tree, to start deleting subtrees that do not contain vertices from M.
В описании алгоритмов 1,2 и 3 используются следующие обозначения: In the description of algorithms 1,2 and 3, the following notation is used:
• num - массив номеров вершин • num - array of vertex numbers
• father - массив родительских вершин в дереве  • father - an array of parental vertices in the tree
• list - массив списков смежных вершин  • list - an array of lists of adjacent vertices
• child - массив счетчиков дочерних вершин  • child - an array of child vertex counters
· d - массив значений глубины вершины в дереве  · D - an array of vertex depth values in the tree
• Q - очередь вершин  • Q - vertex queue
• Р - очередь висячих вершин  • P - queue of pendant vertices
Построенное по алгоритму 2 multicast дерево оптимально по критерию Нор. Сложность алгоритма 2 составляет 0(п + т).  The tree constructed according to algorithm 2 multicast is optimal by the criterion Nor. The complexity of algorithm 2 is 0 (n + m).
При добавлении multicast клиента v к некоторой группе д, происходит добавление ветви из BFS дерева, содержащей вершину v, в multicast дерево. При отключении клиента происходит обрезка ветви, содержащей вершину V, в multicast дереве. Обрезка ветви происходит до некоторой вершины , имеющей более одного потомка. 1.2 Критерий Port Speed When adding a client's multicast v to some group g, the branch from the BFS tree containing the vertex v is added to the multicast tree. When a client is disconnected, the branch containing the vertex V is trimmed in a multicast tree. Pruning a branch takes place to a certain vertex that has more than one descendant. 1.2 Port Speed Criteria
Для построения Port speed оптимального multicast дерева необходимо построить maxmin дерево Т с корнем в вершине s: Vi7 М— М{д) v 6 Т. Также как и в предыдущем пункте, сначала строится остовное дерево, удовлетворяющее требуемому критерию (алг.З - Фиг.З), а затем выбирается минимальное поддерево, содержащее точки из М (алг. 1).  To build a Port speed of an optimal multicast tree, it is necessary to build a maxmin tree T with a root at the vertex s: Vi7 M — M {d) v 6 T. Just as in the previous paragraph, a spanning tree is first built that satisfies the required criterion (alg. 3 .3), and then selects the minimum subtree containing points from M (alg. 1).
Алгоритм построения maxmin дерева является модифицированным алгоритмом Дейкстры нахождения кратчайших путей от некоторой вершины графа до всех остальных .  The maxmin tree construction algorithm is a modified Dijkstra's algorithm for finding the shortest paths from a certain vertex of the graph to all others.
Построенное по алгоритму 3 multicast дерево оптимально по критерию The tree constructed by algorithm 3 multicast is optimal by criterion
Port Speed. Сложность алгоритма 3 составляет 0(π2). Port Speed. The complexity of algorithm 3 is 0 (π 2 ).
1.3 Критерий Load 1.3 Load Criterion
Для построения Load оптимального multicast дерева необходимо построить дерево Штейнера, соединяющее все вершины из = M jj). Здесь под весом ребра понимается та пропускной способности линии, которая будет занята, если через эту линию будет проходить multicast трафик группы, для которой строится дерево. Так как для каждой конкретной multicast группы на каждой линии, используемой группой, пропускная способность одинакова, то и веса ребер в графе сети G, используемые в алгоритме построения дерева Штейнера, одинаковы. Также веса ребер обозначают загрузку линии каждой multicast группой в отдельности, поэтому пропускная способность сети, занимаемая другими группами, в алгоритме не учитывается.  To construct a load optimal multicast tree, it is necessary to construct a Steiner tree connecting all vertices of = M jj). Here, the edge weight is that line capacity that will be occupied if the multicast traffic of the group for which the tree is being built passes through this line. Since for each particular multicast group on each line used by the group, the bandwidth is the same, the edge weights in the graph of the G network used in the Steiner tree construction algorithm are the same. Also, edge weights denote line loading by each multicast group separately, therefore network bandwidth occupied by other groups is not taken into account in the algorithm.
В отличие от предыдущих пунктов, где изначально строилось остовное дерево, а потом из него выбирались пути до клиентов, для критерия Load необходимо строить дерево Штейнера для каждого возможного значения множества М в отдельности, то есть при подключении/отключении клиентов, оптимальное дерево в принципе может полностью отличаться от предыдущего. Задача, где клиенты подключаются и отключаются, называется dynamic Steiner tree problem. Unlike the previous paragraphs, where a spanning tree was originally built, and then paths to customers were selected from it, for the Load criterion, it is necessary to build a Steiner tree for each possible value of the set M separately, that is, when connecting / disconnecting clients, the optimal tree can completely different from the previous one. The task where clients connect and disconnect is called dynamic Steiner tree problem.
Для данной задачи доказано, что не существует аппроксимационного алгоритма с аппроксимационным коэффициентом менее чем ogfc, где к = \М(д)\. Поэтому для решения dynamic Steiner tree problem в реальной сети мы предлагаем воспользоваться эвристическими алгоритмами.  For this problem, it was proved that there is no approximation algorithm with an approximation coefficient less than ogfc, where k = \ M (d) \. Therefore, to solve the dynamic Steiner tree problem in a real network, we suggest using heuristic algorithms.
Рассмотрим использование жадного алгоритма построения дерева Штейнера. Алгоритм работает следующим образом: при подключении очередного клиента, данный клиент соединяется с ближайшей точкой уже построенного дерева Штейнера. Для нахождения кратчайшего пути может быть использован алгоритм Дейкстры, который имеет сложность 0(п2). Изначально, когда в multicast группе еще нет клиентов, дерево считается состоящим из одного узла s Е М - являющегося сервером данной группы. Consider using a greedy Steiner tree construction algorithm. The algorithm works as follows: when connecting another client, this client connects to the nearest point of the already constructed Steiner tree. To find the shortest path, Dijkstra's algorithm can be used, which has complexity 0 (n 2 ). Initially, when there are no clients in the multicast group, the tree is considered to consist of one node s Е М - which is the server of this group.
Проблемой данного подхода состоит в том, что в нем не предусмотрен механизм перестроения дерева в случае отключения клиентов от multicast группы. Можно привести примеры топологий сетей и такие последовательности подключений/отключений клиентов в них, которые могут привести к построению неоптимального дерева. Но, в то же время, перестроение дерева при каждом изменении множества М{д) приведет к тому, что остающиеся в группе клиенты могут испытывать задержки и потери трафика, связанные с перестроением multicast маршрутов. Таким образом, необходим алгоритм перестроения дерева, а также критерий, по которому можно будет определить, что перестроение дерева необходимо.  The problem with this approach is that it does not provide a mechanism for rebuilding the tree in case of disconnecting clients from the multicast group. We can give examples of network topologies and such client connection / disconnection sequences in them that can lead to the construction of a non-optimal tree. But, at the same time, rebuilding the tree with each change of the set M (e) will result in the remaining clients in the group experiencing delays and traffic losses associated with rebuilding multicast routes. Thus, a rebuilding tree algorithm is needed, as well as a criterion by which it will be possible to determine that rebuilding a tree is necessary.
Для выявления неоптимальности дерева Штейнера необходимо сравнить стоимость дерева с оптимальным решением, и, если разница превышает некоторый порог Δ, то необходимо перестроить дерево. Так как нахождение оптимального дерева ΝΡ-полная задача, сравнение дерева будем производить с деревом, построенным по КМВ эвристике, описанная в алгоритме 4 (Фиг.4).  To identify the non-optimality of the Steiner tree, it is necessary to compare the cost of the tree with the optimal solution, and if the difference exceeds a certain threshold Δ, then the tree must be rebuilt. Since finding the optimal tree is полная-complete, we will compare the tree with the tree constructed using the KMV heuristic described in algorithm 4 (Figure 4).
Важным свойством данной эвристики является то, что для нее доказано, что решение, полученное с помощью данной эвристики, не превышает по An important property of this heuristic is that it has been proven that the solution obtained using this heuristic does not exceed
2  2
стоимости оптимальное решение с множителем 2— -, где к = \М д \, [4]. the cost is the optimal solution with the factor 2 - -, where k = \ M d \, [4].
В алгоритме 4 описана КМВ эвристика.  Algorithm 4 describes CMS heuristics.
Стоит отметить, что в строке 4 полученный подграф может не являться деревом, так как пути графа G соответствующие ребрам Е Ύ' могут пересекаться, следовательно, в графе G' могут появиться циклы.  It should be noted that in line 4 the resulting subgraph may not be a tree, since the paths of the graph G corresponding to the edges E Ύ 'may intersect, therefore, cycles may appear in the graph G'.
В строке 8 под leaf(T^) подразумевается множество листовых вершин дерева Т.  In line 8, leaf (T ^) means the set of leaf vertices of the tree T.
Таким образом, в строках (6-11) производится удаление таких ветвей дерева Т, на которых нет вершин из М.  Thus, in lines (6-11), the removal of such branches of the tree T, on which there are no vertices from M.
Для нахождения путей наименьшей стоимости между всеми вершинами из М, можно воспользоваться алгоритмом Флойда-Уоршелла, который имеет сложность 0(п3). Для нахождения минимальных остовных деревьев можно использовать алгоритм Краскала со сложностью 0(m log п), таким образом, результирующая сложность построения дерева по КМВ эвристике равна 0(п3). To find the least cost paths between all vertices of M, one can use the Floyd-Worshell algorithm, which has complexity 0 (n 3 ). To find the minimum spanning trees, Kruskal's algorithm with complexity 0 (m log n) can be used, thus, the resulting complexity of building a tree using the CMS heuristic is 0 (n 3 ).
2. Восстановление multicast дерева 2. Restore multicast tree
Опишем алгоритмы перестроения текущего multicast дерева при следующих событиях:  Let us describe the algorithms for rebuilding the current multicast tree for the following events:
1) Отключение/восстановление линии между двумя коммутаторами 1) Disable / restore line between two switches
2) Отключение/восстановление некоторого коммутатора. 2) Turn off / restore some switch.
Так как отключение/подключение некоторого коммутатора может быть смоделировано последовательным отключением/подключением смежных с данным коммутатором линий, далее будет рассматриваться только первый случай.  Since the disconnection / connection of a switch can be modeled by successive disconnection / connection of lines adjacent to this switch, only the first case will be considered.
При отключении некоторой линии в сети, удаляется ребро е, соответствующее данной линии, и необходимо переподключить клиентов, используя некоторый запасной путь, то есть путь, не содержащий удаленного ребра. Определение. When a certain line is disconnected on the network, edge e corresponding to this line is removed, and it is necessary to reconnect clients using some siding, that is, a path that does not contain a remote edge. Definition
Число А = min{ I ^ Е \ G(V, Е \7) не является связным } называется числом реберной связности графа.  The number A = min {I ^ E \ G (V, E \ 7) is not connected} is called the number of edge connectivity of the graph.
То есть реберная связность, это минимальное количество ребер графа, которые нужно удалить, для того, чтобы граф перестал быть связным.  That is, the edge connectivity is the minimum number of edges of the graph that must be removed in order for the graph to cease to be connected.
По теореме Менгера между произвольными вершинами графа существует λ непересекающихся по ребрам путей. Таким образом, максимальное количество отказов линий, при которых возможно переподключить клиентов, равняется А— 1.  By Menger's theorem, between arbitrary vertices of the graph, there are λ non-intersecting paths along edges. Thus, the maximum number of line failures at which it is possible to reconnect clients is equal to A to 1.
При отключении некоторой линии, связность multicast дерева может быть нарушена, в результате чего оно распадется на компоненты связности, одна из которых будет содержать вершину s. Таким образом, члены группы, оказавшиеся в компоненте связности, не содержащей вершину s, не будут получать multicast трафик. Следовательно, необходимо производить переподключение членов группы, с которыми была потеряна связь отключенных. Причем переподключение необходимо производить так, чтобы другие члены группы, не затронутые отказом линии, не испытывали задержки или потери трафика, связанные с перестроением multicast дерева.  When a certain line is disconnected, the connectivity of the multicast tree can be broken, as a result of which it will break up into connectivity components, one of which will contain the vertex s. Thus, group members that are in a connected component that does not contain vertex s will not receive multicast traffic. Therefore, it is necessary to reconnect the members of the group with whom the disconnected connection has been lost. Moreover, it is necessary to reconnect so that other members of the group who are not affected by the failure of the line do not experience delays or traffic losses associated with rebuilding the multicast tree.
При удалении некоторого ребра е = vw, при использовании критериев Нор и Port speed будет построено новое дерево Т' в графе G ' = G\e, оптимальное для указанных критериев. Дерево 7*'\ί? совпадает с Τ\ν, где ν множество вершин из поддерева с корнем ν в дереве Т графа G, так как удаление некоторого ребра е £ Ε(Γ\ν) не повлияет на кратчайший или maxmin путь от S до некоторой вершины х 6
Figure imgf000017_0001
When removing some edge e = vw, when using the criteria Nor and Port speed, a new tree T 'will be built in the column G' = G \ e, optimal for the specified criteria. Tree 7 * '\ ί? coincides with Τ \ ν, where ν is the set of vertices from the subtree with root ν in tree T of graph G, since deleting some edge e £ Ε (Γ \ ν) does not affect the shortest or maxmin path from S to some vertex x 6
Figure imgf000017_0001
Таким образом, изменение multicast дерева необходимо производить только на V, следовательно, изменение multicast маршрутов не затронет пользователей из T\v.  Thus, the change of the multicast tree needs to be made only on V, therefore, the change of the multicast routes will not affect users from T \ v.
При появлении нового ребра е— vw необходимо рассмотреть 2 случая. When a new e-vw edge appears, it is necessary to consider 2 cases.
Первый - новое ребро есть ребро, которое ранее было удалено из графа G. В этом случае, изменение путей в новом дереве произойдет только для тех клиентов, которых затрагивали некоторые предыдущие удаления ребер. Таким образом, пути до клиентов, которых эти удаления не затрагивали, не будут изменены, и они не испытают задержек/потерь пакетов, связанных с установкой OpenFlow правил в сеть. First, a new edge is an edge that was previously removed from the graph. G. In this case, the change of the paths in the new tree will occur only for those clients who were affected by some previous edge deletions. Thus, the paths to clients that were not affected by these deletions will not be changed, and they will not experience packet delays / losses associated with the installation of OpenFlow rules on the network.
Второй - появившееся ребро действительно новое.  The second is that a new edge is really new.
В этом случае нет гарантий, что появление ребра не изменит пути до всех клиентов. Данные ребра могут появиться в сети в случае изменения физической конфигурации сети, например с установкой нового оборудования. В этом случае, перестроение multicast дерева является оправданной мерой, потому что оно может привести к оптимальному распределению multicast трафика в сети. In this case, there is no guarantee that the appearance of the edge will not change the path to all customers. Edge data may appear on the network if the physical configuration of the network changes, for example, when new equipment is installed. In this case, rebuilding a multicast tree is a reasonable measure, because it can lead to an optimal distribution of multicast traffic on the network.
Для критерия Load, клиенты, отключенные от группы, будут поочередно подключаться жадным алгоритмом построения дерева Штейнера к поддереву графа G содержащему вершину s. Поддеревья, которые не содержат вершину s, будут удалены, как и соответствующие им OpenFlow правила в сети.  For the Load criterion, clients disconnected from the group will be alternately connected by the greedy Steiner tree construction algorithm to the subtree of the graph G containing the vertex s. Subtrees that do not contain vertex s will be deleted, as well as the corresponding OpenFlow rules on the network.
В случае появления в сети новых линков, дерево Штейнера будет перестроено, только если стоимость multicast дерева превысит стоимость дерева, построенного по КМВ эвристике, на некоторый порог Δ. 3. Реализация  If new links appear in the network, the Steiner tree will be rebuilt only if the cost of the multicast tree exceeds the cost of the tree constructed using the CMS heuristics by some threshold Δ. 3. Implementation
Предлагаемый подход был реализован как сетевое приложение для SDN контроллера RunOS.  The proposed approach was implemented as a network application for the RunOS SDN controller.
Приложение хранит информацию о каждой multicast группе, представленной в сети. Для каждой группы указывается набор пар (коммутатор, порт) определяющий местонахождения серверов, предоставляющих данную multicast группу в сети. В данном случае под сервером может подразумеваться как физический сервер, подключенный к данному порту, так и маршрутизатор, получающий multicast группы по L3 протоколам, таким как PIM, DVMRP и т.д. Для подключения к multicast группе или отключения от нее, пользователи сети отправляют IGMP запросы - Join group и Leave group. Поэтому приложение устанавливает на граничные SDN коммутаторы Flow правила, которые перенаправляют любые IGMP пакеты на контроллер. The application stores information about each multicast group represented on the network. For each group, a set of pairs (switch, port) is specified, which determines the locations of the servers providing this multicast group on the network. In this case, a server can mean both a physical server connected to this port and a router receiving multicast groups using L3 protocols, such as PIM, DVMRP, etc. To connect to or disconnect from a multicast group, network users send IGMP requests - Join group and Leave group. Therefore, the application installs rules on the SDN edge Flow switches that redirect any IGMP packets to the controller.
При подключении к некоторой multicast группе первого клиента, на сервер данной группы отправляется сообщение IGMP Join group для того, чтобы сервер инициировал отправку multicast трафика. При отключении от данной multicast группы последнего клиента, на сервер группы отправляется сообщение IGMP Leave group, для того, чтобы сервер прекратил отправку трафика.  When connecting to a multicast group of the first client, a message from the IGMP Join group is sent to the server of this group so that the server initiates sending multicast traffic. If the last client disconnects from this multicast group, an IGMP Leave group message is sent to the group server so that the server stops sending traffic.
Join и Leave group сообщения отправляются с порта коммутатора, подключенного к данному источнику при помощи отправки на коммутатор OpenFlow сообщения - Packet-Out.  Join and Leave group messages are sent from the switch port connected to this source by sending messages to the OpenFlow switch - Packet-Out.
3.1 Multicast маршрутизация 3.1 Multicast routing
При старте контроллера, приложение получает информацию о сетевой топологии от приложения topology. Далее, для каждой группы, в зависимости от критерия оптимальности для multicast дерева данной группы, строится остовное дерево, в котором впоследствии будет производиться поиск путей, соединяющих multicast сервер с multicast клиентом. Данные остовные деревья строятся на основе алгоритмов, описанных в предыдущей главе.  When the controller starts, the application receives information about the network topology from the topology application. Further, for each group, depending on the optimality criterion for the multicast tree of this group, a spanning tree is built, which will subsequently be searched for paths connecting the multicast server with the multicast client. These spanning trees are built on the basis of the algorithms described in the previous chapter.
При старте контроллера, на каждый SDN коммутатор устанавливается правило, которое перенаправляет все IGMP запросы на контроллер. Данные сообщения отправляются на контроллер при помощи OpenFlow сообщений - Packet-In. Приложение на контроллере производит обработку данных запросов. При получении сообщения IGMP join group, контроллер производит поиск пути от multicast сервера до клиента, приславшего запрос на подключение группы. Информацию о том, на какой порт коммутатора поступил запрос, приложение получает из полей сообщения Packet-In.  When the controller starts, a rule is set for each SDN switch that redirects all IGMP requests to the controller. These messages are sent to the controller using OpenFlow messages - Packet-In. The application on the controller processes the request data. Upon receipt of the IGMP join group message, the controller searches for the path from the multicast server to the client that sent the group join request. The application receives the Packet-In message from the fields about which switch port the request has received.
После нахождения маршрута от сервера до клиента, приложение производит установку соответствующих правил на коммутаторы, входящие в данный путь. Также, если это первый клиент, запросивший данную группу, то отправляется IGMP join group запрос на порт, на котором находится сервер данной multicast группы. Если клиент не является первым подключившимся к данной группе, то путь до клиента начинает устанавливаться не от коммутатора, подключенного к multicast серверу, а от ближайшей точки, находящейся в multicast дереве (ближайшая точка считается в остовном дереве, построенном для данной multicast группы). After finding the route from the server to the client, the application installs the corresponding rules on the switches included in this path. Also, if this is the first client to request this group, then the IGMP join group sends a request to the port on which the server of this multicast group is located. If the client is not the first to connect to this group, then the path to the client begins to be established not from the switch connected to the multicast server, but from the nearest point located in the multicast tree (the closest point is considered in the spanning tree built for this multicast group).
На каждый коммутатор устанавливаются правила следующего вида:  At each switch set the following rules:
Устанавливается Flow правило, в поле match которого установлены in- port и ip-dst. In-port является портом, через который, данный коммутатор соединен с коммутатором, предшествующим в пути от сервера к клиенту. В поле ip-dst установлен ip адрес multicast группы.  The Flow rule is set, in the match field of which the port and ip-dst are set. The in-port is the port through which this switch connects to the switch that precedes the path from the server to the client. The ip address of the multicast group is set in the ip-dst field.
Таким образом, данное правило обрабатывает только пакеты, приходящие от multicast сервера и принадлежащие соответствующей группе.  Thus, this rule processes only packets coming from a multicast server and belonging to the corresponding group.
В поле action установлен номер соответствующего данной multicast группе группового OpenFlow правила. Групповые правила выглядят следующим образом:  The action field is set to the number of the group OpenFlow rule corresponding to this multicast group. Group rules are as follows:
Группа является АН группой, то есть пакеты дублируются на каждый bucket. Набор bucket'oB определяется текущей структурой multicast дерева, то есть, если в остовном дереве данной группы вершина, отождествленная коммутатору, имеет несколько дочерних вершин, то для каждой вершины создается bucket, который отправляет трафик на порт, соединяющий данный коммутатор с коммутатором, соответствующим его дочернему узлу. Таким образом, трафик распространяется по multicast дереву. Далее, данную пару правил (Flow, Group) будем называть multicast правилами.  The group is an AH group, that is, the packages are duplicated on each bucket. The bucket'oB set is determined by the current structure of the multicast tree, that is, if in the spanning tree of this group the vertex identified by the switch has several child vertices, then for each vertex a bucket is created that sends traffic to the port connecting this switch to the switch that corresponds to it child node Thus, the traffic spreads over a multicast tree. Further, this pair of rules (Flow, Group) will be called multicast rules.
3.2 Агрегация multicast правил 3.2 Aggregation of multicast rules
Так как в сети может быть большое количество multicast групп, большое количество групповых OpenFlow правил может негативно влиять на производительность SDN коммутаторов, поэтому необходим механизм уменьшения количества установленных групповых правил, с сохранением логики маршрутизации multicast трафика для всех текущих групп. Since there can be a large number of multicast groups on the network, a large number of group OpenFlow rules can negatively affect performance of SDN switches, so a mechanism is needed to reduce the number of established group rules, while preserving the logic of multicast traffic routing for all current groups.
Предлагается метод объединения однотипных групповых правил в одно единственное правило для уменьшения общего количества правил, устанавливаемых на коммутаторы.  A method of combining the same type of group rules into one single rule is proposed to reduce the total number of rules set on the switches.
Каждое правило, которое устанавливается на коммутаторы приложением multicast, проходит процедуру агрегации. Процедура агрегации правил представляет собой объединение групповых OpenFIow правил с идентичным набором bucket'oB в одно правило, а также изменение поля dst_group на новую группу в соответствующих Flow правилах.  Each rule that is set on switches by a multicast application goes through an aggregation procedure. The rule aggregation procedure consists of combining OpenFIow group rules with the identical set of bucket'oB into one rule, as well as changing the dst_group field to a new group in the corresponding Flow rules.
Агрегация multicast правил происходит в два этапа.  Aggregation of multicast rules occurs in two stages.
Первым этапом является создание объединенных правил, из набора multicast правил, созданных для каждой multicast группы. Для каждого коммутатора приложение хранит список необъединенных multicast правил и список реальных правил, установленных на коммутаторы.  The first step is to create merged rules from a set of multicast rules created for each multicast group. For each switch, the application stores a list of un-interconnected multicast rules and a list of actual rules installed on the switches.
При появлении запроса за создание нового multicast правила на коммутаторе, происходит проверка, установлено ли на коммутаторе данное multicast правило (проверка происходит по идентификаторам группового правила):  When a request appears for creating a new multicast rule on the switch, it checks whether the switch has this multicast rule set (the check is performed using the group rule identifiers):
• Если правило не установлено, начинается процедура объединения нового правила с существующими, то есть происходит поиск существующего группового правила с идентичным набором bucket'oB. • If a rule is not set, the procedure of merging a new rule with an existing one begins, that is, an existing group rule is searched with an identical set of bucket'oB.
• Если такое правило найдено, то Flow multicast правило переписывается таким образом, чтобы оно указывало на существующее групповое правило. • If such a rule is found, then the flow multicast rule is rewritten so that it points to the existing group rule.
• Если такая группа не найдена, то multicast правило будет установлено на коммутатор без изменений.  • If such a group is not found, then the multicast rule will be set to the switch unchanged.
Также с каждым агрегированным правилом связан счетчик, показывающий количество multicast правил, которые с ним ассоциированы. Правило удаляется с коммутатора только тогда, когда удаляются все такие multicast правила, ассоциированные с ним, то есть счетчик станет равен нулю. There is also a counter for each aggregated rule, which shows the number of multicast rules associated with it. A rule is deleted from the switchboard only when all such multicast rules associated with it are deleted, that is, the counter becomes zero.
Вторым этапом является обновление состояния коммутаторов.  The second step is to update the state of the switches.
Обновление состояний происходит после событий, изменяющих конфигурацию multicast правил в сети, таких как, подключение/отключение клиентов, обрывы/восстановления линий, падения/подключения коммутаторов. Данные события влияют на все группы, поэтому состояния коммутаторов изменяются только после процедуры объединения всех правил, связанных со всеми multicast группами.  State update occurs after events that change the configuration of multicast rules on the network, such as connecting / disconnecting clients, breaking / restoring lines, dropping / connecting switches. These events affect all groups, so the state of switches changes only after the procedure of combining all the rules associated with all multicast groups.
Во время объединения правил, агрегатор сравнивает списки существующих правил и списки обновленных правил. Если существуют правила, которые участвуют только в одном списке, то они либо удаляются с коммутатора (если их нет в обновленном списке), либо устанавливаются (если их нет на коммутаторе, но они есть в обновленном списке). Также изменяются соответствующие им flow правила.  While merging rules, the aggregator compares lists of existing rules and lists of updated rules. If there are rules that participate in only one list, they are either deleted from the switch (if they are not in the updated list), or are set (if they are not on the switch, but they are in the updated list). Also change the corresponding flow rules.
Для минимизации количества OpenFlow сообщений (если существуют группы, которые нужно удалить, и также существуют группы, которые нужно добавить), вместо пары сообщений — удалить/добавить, отправляется единственное OpenFlow сообщение, которое изменяет набор bucket'oB в удаляемом правиле на набор из нового правила.  To minimize the number of OpenFlow messages (if there are groups that need to be deleted, and there are also groups that need to be added), instead of a pair of messages — delete / add, the only OpenFlow message is sent that changes the set of bucket'oB in the rule being deleted to a set of new regulations.
4. Подробное описание алгоритма 4. Detailed description of the algorithm
4.1 Алгоритм обеспечения multicast маршрутизации 1) Автоматическое определение multicast групп и активных источников трафика, либо задание данных групп администратором сети. ) Установка на всех коммутаторах в сети OpenFlow правил, которые перехватывают IGMP сообщения с портов, подключенных к хостам в сети, и отправляют на контроллер.4.1 Algorithm for ensuring multicast routing 1) Automatic detection of multicast groups and active traffic sources, or the network administrator setting these groups. ) Installation on all switches on the OpenFlow network of rules that intercept IGMP messages from ports connected to hosts on the network and send to the controller.
) Получение IGMP сообщения от клиента на некотором порту коммутатора.) Receiving an IGMP message from a client on some switch port.
) Отправка данного сообщения на контроллер для дальнейшего анализа.) На основе полученного на контроллере сообщения, определения порта, на котором находится клиент, запросивший multicast группу. Далее в зависимости от типа полученного на контроллере IGMP сообщения выбирается следующий порядок действий, проводимый контроллером: ) Sending this message to the controller for further analysis.) Based on the message received on the controller, the definition of the port on which the client resides, which has requested the multicast group. Further, depending on the type of message received on the IGMP controller, the following procedure is taken by the controller:
Если IGMP сообщение - IGMP join group - выполнение пунктов 6-15:) Выбор источника multicast трафика из списка заданных источников.) Автоматическое построение пути от источника до multicast клиента по различным критериям {Hop, Port Speed, Load) алгоритмами построения деревьев описанным в п.1 данного параграфа. Критерий построения деревьев может быть, как заранее задан администратором, так и выбран алгоритмом по умолчанию. If IGMP message - IGMP join group - execution of points 6-15 :) Selecting the source of multicast traffic from the list of specified sources.) Automatic construction of the path from the source to the multicast client using various criteria (Hop, Port Speed, Load) using tree-building algorithms described in .1 of this paragraph. The criterion for constructing trees can be, as previously set by the administrator, or selected by the default algorithm.
) Определение коммутаторов, на которые необходимо установить правила маршрутизации.) Determination of switches for which you need to set routing rules.
) Проведение процедуры агрегации групповых OpenFlow правил (минимизации количества групповых правил), описанной в п.3.2 данного параграфа.) Carrying out the procedure of aggregation of group OpenFlow rules (minimizing the number of group rules) described in paragraph 3.2 of this paragraph.
0) Установка соответствующего набора OpenFlow правил описанного в п.3.1 данного параграфа.0) Install the appropriate set of OpenFlow rules described in Section 3.1 of this paragraph.
1) Если подключившийся клиент - первый клиент данной группы, то отправка контроллером IGMP join group источнику multicast трафика при помощи OpenFlow сообщения Packet-Out. ) Передача multicast трафика от порта, подключенного к источнику до портов, подключенных к клиентам через установленное в сети multicast дерево.1) If the connecting client is the first client of this group, then the IGMP join group controller sends a Packet-Out message to the multicast traffic source using the OpenFlow. ) Transmission of multicast traffic from the port connected to the source to the ports connected to clients via the network installed on the multicast network.
) Получение multicast трафика на входных портах, соединенных с выбранным источником, либо определение, что данный источник не обладает запрошенной multicast группой. Проверка происходит при помощи считывания счетчиков на правиле обработки multicast трафика на коммутаторе, соединенном с сервером. Если значения счетчиков не изменяются в течение некоторого интервала времени, заданного администратором, то детектируется отсутствие группы на сервере. ) Receiving multicast traffic on the input ports connected to the selected source, or determining that this source does not have the requested multicast group. Verification occurs by reading the counters on the multicast traffic processing rule on the switch connected to the server. If the values of the counters do not change during a certain time interval set by the administrator, then the absence of a group on the server is detected.
Если источник данной группой не обладает, то переход к (6) и выбор другого сервера. Если серверов больше нет, то уведомление администратора сети об отсутствии заданной multicast группы в сети.) Периодический опрос multicast клиентов сообщениями IGMP query и периодическая отправка IGMP request источнику multicast трафика. If the source does not have this group, then go to (6) and select another server. If there are no more servers, notify the network administrator about the absence of a given multicast group on the network.) Periodically polling multicast clients with IGMP query messages and periodically sending IGMP request to the multicast traffic source.
) Если какой-либо клиент не отвечает на сообщения IGMP query в течение некоторого заданного администратором промежутка времени - удаление данного клиента из multicast группы и перестроение дерева (переход к ( 16)). ) If a client does not respond to IGMP query messages for a certain period specified by the administrator, delete this client from the multicast group and rebuild the tree (go to (16)).
Если IGMP сообщение - IGMP leave group - выполнение пунктов 16- 23: If an IGMP message is an IGMP leave group - the execution of points 16-23:
) Автоматическое перестроение multicast дерева по различным критериям {Hop, Port Speed, Load) алгоритмами построения деревьев описанным в п.1 данного параграфа. Критерий построения деревьев может быть, как заранее задан администратором, так и выбран алгоритмом по умолчанию.) Automatic rebuilding of a multicast tree according to various criteria {Hop, Port Speed, Load) tree-building algorithms described in item 1 of this paragraph. The criterion for constructing trees can be, as previously set by the administrator, or selected by the default algorithm.
) Определение коммутаторов, на которые необходимо установить правила маршрутизации. 18) Проведение процедуры агрегации групповых OpenFlow правил (минимизации количества групповых правил), описанной в п.3.2 данного параграфа. ) Determination of switches for which you need to set routing rules. 18) Carrying out the procedure of aggregation of group OpenFlow rules (minimization of the number of group rules), described in paragraph 3.2 of this paragraph.
19) Обновление соответствующего набора OpenFlow правил описанного в п.3.1 данного параграфа, связанного с перестроением multicast дерева.  19) Update the corresponding set of OpenFlow rules described in Section 3.1 of this paragraph related to the rebuilding of a multicast tree.
20) Если отключившийся клиент - последний клиент данной группы, то отправка контроллером IGMP leave group источнику multicast трафика при помощи OpenFlow сообщения Packet-Out.  20) If the disconnected client is the last client of this group, then the IGMP leave group controller sends a packet-out message to the source of multicast traffic using the OpenFlow.
21) Передача multicast трафика от порта, подключенного к источнику до портов, подключенных к клиентам через перестроенное multicast дерево. 21) Transmission of multicast traffic from a port connected to a source to ports connected to clients via a rebuilt multicast tree.
22) Получение multicast трафика на входных портах, соединенных с выбранным источником, либо определение, что данный источник не обладает запрошенной multicast группой. Проверка происходит при помощи считывания счетчиков на правиле обработки multicast трафика на коммутаторе, соединенном с сервером. Если значения счетчиков не изменяются в течение некоторого интервала времени, заданного администратором, то детектируется отсутствие группы на сервере.  22) Receive multicast traffic on the input ports connected to the selected source, or determine that this source does not have the requested multicast group. Verification occurs by reading the counters on the multicast traffic processing rule on the switch connected to the server. If the values of the counters do not change during a certain time interval set by the administrator, then the absence of a group on the server is detected.
Если источник данной группой не обладает, то переход к (6) и выбор другого сервера. Если серверов больше нет, то уведомление администратора сети об отсутствии заданной multicast группы в сети. If the source does not have this group, then go to (6) and select another server. If there are no more servers, notify the network administrator about the absence of a given multicast group on the network.
23) Периодический опрос оставшихся multicast клиентов сообщениями IGMP query и периодическая отправка IGMP request источнику multicast трафика. 23) Periodic polling of the remaining multicast clients with IGMP query messages and periodically sending IGMP requests to the multicast traffic source.
24) Если какой-либо клиент не отвечает на сообщения IGMP query в течении некоторого, заданного администратором, промежутка времени - удаление данного клиента из multicast группы и перестроение дерева (переход к ( 16)). Комментарий к пункту (3) описанного алгоритма: 24) If any client does not respond to IGMP query messages for a certain period specified by the administrator, remove this client from the multicast group and rebuild the tree (go to (16)). Comment to paragraph (3) of the described algorithm:
Список источников задается администратором сети в виде пар (коммутатор, порт), к которым подключены источники multicast трафика.  The list of sources is set by the network administrator in the form of pairs (switch, port) to which sources of multicast traffic are connected.
Комментарий к пунктам (5) и (16) описанного алгоритма:  Commentary to paragraphs (5) and (16) of the described algorithm:
Если в качестве критерия построения multicast выбраны критерии Нор или Port Speed, то способ подключения новых клиентов не зависит от того, сколько клиентов уже подключено к данной группе.  If Noor or Port Speed criteria are selected as the criterion for building multicast, then the method of connecting new clients does not depend on how many clients are already connected to this group.
Если в качестве критерия выбран критерий Load, то при подключении первого клиента, данный клиент соединяется с источником multicast трафика кратчайшим путем, построенным по алгоритму Дейкстры. Последующие клиенты подключаются кратчайшим путем с ближайшей к данному клиенту вершиной уже построенного дерева.  If the Load criterion is selected as a criterion, then when the first client is connected, this client connects to the source of multicast traffic by the shortest path constructed using the Dijkstra algorithm. Subsequent clients connect the shortest path with the top of the already constructed tree nearest to this client.
Так как данный алгоритм может привести к неоптимальному результату, при каждом подключении/отключении клиента от данной multicast группы, происходит сравнение построенного multicast дерева для данной группы с деревом, построенным по алгоритму 4 параграфа 5. Если разница в количестве используемых сетевых линий между данными деревьями выше некоторого порога Δ, то multicast дерево заменяется деревом, построенным по алгоритму 4, и происходит изменение соответствующих OpenFlow правил на коммутаторах в сети.  Since this algorithm can lead to a non-optimal result, each time a client connects / disconnects from a given multicast group, a constructed multicast tree for this group is compared with a tree constructed using algorithm 4 of section 5. If the difference in the number of network lines used between these trees is higher a certain Δ threshold, the multicast tree is replaced by a tree constructed by algorithm 4, and the corresponding OpenFlow rules are changed on the switches in the network.
4 J Алгоритм обеспечения отказоустойчивости multicast трафика 4 J Multicast traffic resiliency algorithm
1) Определение контроллером изменения состояния сети: подключение/отключение некоторого коммутатора, подключение/отключение некоторой сетевой линии между коммутаторами.  1) Definition by the controller of a network state change: connection / disconnection of a certain switch, connection / disconnection of a certain network line between switches.
2) Автоматическое перестроение multicast дерева по различным критериям {Hop, Port Speed, Load) алгоритмами построения деревьев описанным в п.1 данного параграфа, с учетом обновленной топологии сети. 3) Определение наличия клиентов, не получающих multicast трафика.2) Automatic rebuilding of a multicast tree according to various criteria {Hop, Port Speed, Load) by tree-building algorithms described in item 1 of this paragraph, taking into account the updated network topology. 3) Determining the presence of clients not receiving multicast traffic.
4) Обновление OpenFlow правил на коммутаторах в соответствии с пунктом 2 данного параграфа для того, чтобы все клиенты получали multicast трафик. 4) Update OpenFlow rules on the switches in accordance with paragraph 2 of this paragraph so that all clients receive multicast traffic.
5) Переход к (14) предыдущего алгоритма.  5) Go to (14) of the previous algorithm.
Специалисту в данной области, очевидно, что конкретные варианты осуществления способа и системы минимизации многоадресного трафика и обеспечения его отказоустойчивости в ПКС сетях описаны здесь в целях иллюстрации, допустимы различные модификации, не выходящие за рамки и сущности объема изобретения.  It is obvious to a person skilled in the art that specific embodiments of the method and system for minimizing multicast traffic and ensuring its fault tolerance in PKS networks are described here for purposes of illustration, various modifications are possible that are not beyond the scope and essence of the invention.

Claims

ФОРМУЛА FORMULA
1. Способ минимизации многоадресного трафика и обеспечения его отказоустойчивости в ПКС сетях, характеризующийся тем что:  1. The way to minimize multicast traffic and ensure its fault tolerance in PKS networks, characterized by the fact that:
• определяют multicast группы и активные источники трафика;  • define multicast groups and active traffic sources;
• устанавливают на всех коммутирующих устройствах в сети openflow правила;  • set rules on all openstream network switches;
• получают igmp сообщения от клиента на порту коммутирующего устройства;  • receive igmp messages from the client on the port of the switching device;
• оправляют данное сообщение на контроллер для дальнейшего анализа; • send this message to the controller for further analysis;
• на основе полученного на контроллере сообщения, определяют порт, на котором находится клиент, запросивший multicast группу; • based on the message received on the controller, determine the port on which the client resides, which has requested the multicast group;
• выбирают источник multicast трафика из списка источников;  • select the source of multicast traffic from the list of sources;
• осуществляют построение пути от источника до multicast клиента по различным критериям;  • carry out the construction of the path from the source to the multicast client according to various criteria;
• определяют коммутирующие устройства, на которые необходимо установить правила маршрутизации;  • determine the switching devices for which it is necessary to establish routing rules;
• устанавливают на определенные на предыдущем шаге коммутирующие устройства правила коммутации;  • set the switching rules defined in the previous step switching devices;
• определяют контроллером изменения состояния сети;  • determined by the controller to change the state of the network;
• осуществляют перестроение multicast дерева по различным критериям с учетом обновленной на предыдущем шаге топологии сети;  • carry out the rebuilding of a multicast tree according to different criteria, taking into account the network topology updated at the previous step;
• определяют наличие клиентов, не получающих multicast трафика;  • determine the presence of clients not receiving multicast traffic;
• обновляют openflow правила на коммутирующих устройствах таким образом, чтобы все клиенты получали multicast трафик.  • update openflow rules on switching devices so that all clients receive multicast traffic.
2. Машиночитаемый носитель данных, содержащий исполняемые одним или более процессором машиночитаемые инструкции, которые при их исполнении реализуют выполнение способа минимизации многоадресного трафика и обеспечение его отказоустойчивости в ПКС сетях по п.1.  2. A computer-readable storage medium containing computer-readable instructions executed by one or more processors that, when executed, implement the method for minimizing multicast traffic and ensuring its fault tolerance in PKS networks according to claim 1.
PCT/RU2017/000453 2017-09-11 2017-09-11 Method of minimizing multicast traffic and providing fault tolerance in sdn networks WO2019050424A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/RU2017/000453 WO2019050424A1 (en) 2017-09-11 2017-09-11 Method of minimizing multicast traffic and providing fault tolerance in sdn networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2017/000453 WO2019050424A1 (en) 2017-09-11 2017-09-11 Method of minimizing multicast traffic and providing fault tolerance in sdn networks

Publications (1)

Publication Number Publication Date
WO2019050424A1 true WO2019050424A1 (en) 2019-03-14

Family

ID=65634467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2017/000453 WO2019050424A1 (en) 2017-09-11 2017-09-11 Method of minimizing multicast traffic and providing fault tolerance in sdn networks

Country Status (1)

Country Link
WO (1) WO2019050424A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070195797A1 (en) * 2006-02-23 2007-08-23 Patel Alpesh S Network device that determines application-level network latency by monitoring option values in a transport layer message
US7519006B1 (en) * 2003-11-26 2009-04-14 Cisco Technology, Inc. Method and apparatus for measuring one-way delay at arbitrary points in network
US7937492B1 (en) * 2008-09-30 2011-05-03 Juniper Networks, Inc. LSP ping and traceroute for bypass tunnels
US20140105209A1 (en) * 1999-01-11 2014-04-17 Yahoo! Inc. Performing Multicast Communication In Computer Networks By Using Overlay Routing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140105209A1 (en) * 1999-01-11 2014-04-17 Yahoo! Inc. Performing Multicast Communication In Computer Networks By Using Overlay Routing
US9252963B2 (en) * 1999-01-11 2016-02-02 Google Inc. Performing multicast communication in computer networks by using overlay routing
US7519006B1 (en) * 2003-11-26 2009-04-14 Cisco Technology, Inc. Method and apparatus for measuring one-way delay at arbitrary points in network
US20070195797A1 (en) * 2006-02-23 2007-08-23 Patel Alpesh S Network device that determines application-level network latency by monitoring option values in a transport layer message
US7937492B1 (en) * 2008-09-30 2011-05-03 Juniper Networks, Inc. LSP ping and traceroute for bypass tunnels

Similar Documents

Publication Publication Date Title
US10673741B2 (en) Control device discovery in networks having separate control and forwarding devices
US9929938B2 (en) Hierarchal label distribution and route installation in a loop-free routing topology using routing arcs at multiple hierarchal levels for ring topologies
KR102006038B1 (en) Resiliency-aware hybrid design of controller-switch connectivity in a split-architecture system
EP2883334B1 (en) Techniques for flooding optimization for link state protocols in a network topology
US9397747B2 (en) Method and apparatus for connectivity control in a data center network
Pfeiffenberger et al. Reliable and flexible communications for power systems: Fault-tolerant multicast with SDN/OpenFlow
EP2614615B1 (en) Automated traffic engineering for 802.1aq based upon the use of link utilization as feedback into the tie-breaking mechanism
US9246794B2 (en) Label distribution and route installation in a loop-free routing topology using routing arcs
US9722861B2 (en) Fault-resilient broadcast, multicast, and unicast services
Petale et al. Link failure recovery mechanism in software defined networks
CN109889350A (en) A kind of method and device for toggle path in SDN network failure
US20140140210A1 (en) Network system and load balancing method
TW201212589A (en) Automated traffic engineering for fat tree networks
KR20150051107A (en) Method for fast flow path setup and failure recovery
JP6204168B2 (en) Transfer device, server, and route change method
Cousin et al. Tree reconfiguration without lightpath interruption in WDM optical networks
RU2676239C1 (en) Method for minimizing multi-address traffic and ensuring its failure resistance in sdn
WO2019050424A1 (en) Method of minimizing multicast traffic and providing fault tolerance in sdn networks
CN114697002B (en) Distributed quantum cryptography network group key distribution method and system
Petrov et al. Minimization of multicast traffic and ensuring its fault tolerance in software-defined networks
Tkachova et al. A network load balancing algorithm for overlay-based SDN solutions
Messmer et al. Real-time fault-tolerant routing in high-availability multicast-aware video networks
Tam Robustness in data center networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17924000

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17924000

Country of ref document: EP

Kind code of ref document: A1