RU2775146C1 - Method for automated provision of a virtual channel by a communication operator between data processing centers - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to the field of computer technology. The expected result is achieved due to the method for forming a virtual channel between data processing centers (DPC) using a software-configurable network controller (SCN), in which the SCN controller: receives a request to create a record of the tenant of virtual channels and a sign of compliance with the tenant’s virtual channel maintenance mode, generates a data set of virtual channel tenants, receives a request to form a virtual channel, builds a virtual channel route, adds records about the virtual channel to the traffic organization data set, adds records about the ownership of the virtual channel to the tenant to the data set of virtual channel tenants, executes a series of requests to switches to configure switches along the built virtual channel route with the formation of a virtual channel in one direction, and in response to the virtual channel termination condition executes a series of requests to switches along the built virtual channel route to remove traffic processing and routing rules of the virtual channel.

EFFECT: increase in the stability of the created virtual communication channels.

22 cl, 7 dwg, 2 tbl

Description

FIELD OF TECHNOLOGY

This technical solution relates to computer technology and, in particular, to data center control systems, as well as to the field of network technologies, software-defined networks, data transit through the channels of a telecom operator and the implementation of the functions of QoS models, and more specifically, to methods for automated provision of virtual channel by the communication operator between the data center.

BACKGROUND OF THE INVENTION

Requirements for Data Processing Centers (DPC) for the provision of IaaS (from the English Infrastructure as a Service - infrastructure as a service), PaaS (from the English Platform as a Service - platform as a service), SaaS (from the English software as a service - software as a service) are constantly growing, as these services allow enterprises to optimize the total cost of ownership (TCO, from the English total cost of ownership) and save time deploying computing infrastructure.

In the general case, the data center management system ( 101 , FIG. 1 ) includes interacting software modules: components that provide data storage and processing, for example, cloud infrastructure services, such as Nova hypervisor management, Keystone authentication service, Swift distributed storage, interface to databases Trove data or the Neutron network infrastructure management component, which provides communication between all components implemented in the OpenStack management system.

The physical memory where digital data is actually stored can be distributed among several servers and have, for example, a network attached storage (NAS, Network Attached Storage) service interface or another. Data processing can also be distributed across multiple servers. Distributed data processing in this organization may resemble a fully meshed network scheme, in which each node interacts with each, as shown in FIG. 1 depicting a variant of the communication scheme of the computer information processing system implemented in the data center.

FIG. Figure 1 shows a variant of a logical meshed network, a data transfer scheme between infrastructure cloud services (in particular, data processing and storage) 131 , 141 , 151 , 161 , used in the data center 101 and clients 111 , 121 - tenants of computing resources.

To securely transfer data and tenant traffic between data center components, network data transmission tunneling is used.

The construction of tunnels between software components within the data center system is performed automatically. The construction of tunnels for interaction between software components of different data centers can be performed in an automated mode with the execution of API calls to data center control systems ( 202 , 212 , FIG. 2 ). For example, in FIG. Figure 2 shows a diagram of connections between data centers over a leased line previously leased by a telecom operator, which has a guaranteed bandwidth, designed for maximum traffic intensity. Thus, to transfer data between software components (modules) of different data centers, an API call is made to data center control systems, after processing which a tunnel or tunnels are created between the network modules of remote data centers, allowing data to be transferred. The choice of the exact implementation at this level depends on the data center control system and the applied tunneling protocols.

When pooling resources, subject to data exchange between remote data centers, at the output of the network component (in particular, the data center control system module, for example, the Neutron module from the OpenStack control system), encapsulated data (at least over ISO/OSI models for L2 or L3 tunneling), organized L2 or L3 tunneling ( 222 , FIG. 2 ). The choice (which is made automatically, with the algorithm chosen depending on the implementation of the control system) of the exact implementation at this level depends on the control system of the data center and the tunneling protocols used.

To build tunnels between software components of remote data centers, it is also possible to use a solution without a leased line previously leased: using shared channels of a telecom operator, but this method of building tunnels between software components of remote data centers does not guarantee a stable bandwidth and acceptable response time. Therefore, to organize communication between data centers, the telecom operator leases a dedicated line with guaranteed bandwidth. As a rule, to combine data centers, the telecom operator allocates an L2, L3 channel or a physical channel with a bandwidth designed for maximum traffic intensity.

But for building tunnels between software components of remote data centers, a solution with a pre-leased line of a telecom operator that guarantees sufficient bandwidth has low efficiency for both the telecom operator and the owner of the data center: the creation of such a channel can take several days, the lease time is determined by months , the channel should be designed for maximum load, but the maximum traffic intensity does not always happen and lasts for a short time, so the owner of the data center often pays for an unused channel, and the operator's equipment remains unloaded.

A solution with a pre-leased line of a telecom operator in the general case also does not guarantee the timely transit of individual data streams that are sensitive to traffic time delays, since within a leased channel with a guaranteed total bandwidth, the transit of individual streams is performed according to the non-guaranteed QoS delivery model (from the English quality of service - “quality of service”).

ESSENCE OF THE TECHNICAL SOLUTION

The technical result achieved by the proposed technical solution consists in increasing the efficiency of creating virtual channels, increasing the efficiency of using network equipment, and increasing the stability of the created virtual channels.

According to one of the implementation options, a method is proposed for automatically forming a virtual channel between data processing centers (DPCs) using a software-defined network (SDN) controller, in which:

- switches controlled by the SDN controller perform packet exchange of connection discovery protocols;

- the SDN controller periodically polls the switches, specified using the interprocess communication mechanism, about the interfaces existing on the switches, the bandwidth of the lines and about the devices connected to their interfaces with the formation of the first data set;

- based on the first data set, the SDN controller generates a traffic management data set containing data on the topology and resources of the switch network;

- the SDN controller, using the inter-process communication mechanism, receives a request to create a tenant record of virtual channels and a sign of compliance with the maintenance mode of the tenant's virtual channels, where the sign of the maintenance mode sets the priority when building virtual channels routes;

- the SDN controller generates a data set of tenants of virtual channels, containing: identifiers of tenants of virtual channels, identifiers of virtual channels and a sign of compliance with the tenant's channel service mode;

- the SDN controller, using the interprocess communication mechanism, receives a request to form a virtual channel, containing at least: data on the entry points of the virtual channel traffic, a sign of traffic entering the virtual channel, information about the beginning and end of the virtual channel, data about the ownership of the virtual channel to the tenant and data on the required QoS parameters;

- the SDN controller constructs the route of the virtual channel, taking into account: the sign of compliance with the service mode of the tenant channels, the bandwidth resource of the switch domain, information about the beginning and end of virtual channels and the QoS parameters requested for virtual channels;

- the SDN controller adds records about the virtual channel to the traffic organization data set: the route of the virtual channel, the sign of the traffic entering the virtual channel, information about the beginning and end of the virtual channel and the bandwidth occupied by the virtual channel;

- the SDN controller adds to the dataset of tenants of virtual channels records about the ownership of the virtual channel by the tenant;

- the SDN controller performs a series of requests to the switches to configure the switches along the constructed virtual channel route with the formation of at least one virtual channel in at least one direction, where the setting includes rules for processing and routing traffic, taking into account the network bandwidth resource and QoS parameters;

- in response to the virtual channel termination condition, the SDN controller executes a series of requests to the switches along the constructed virtual channel route to remove the rules for processing and routing virtual channel traffic.

In one of the private implementation options, the information for the formation of the first data set is specified statically.

In one of the private implementation options, the request for the formation of a virtual channel, as information about the beginning and end of the virtual channel, contains the lifetime of the virtual channel.

In one of the private implementation options, the request to form a virtual channel, as information about the beginning and end of the virtual channel, contains the maximum value of the amount of data transmitted over the virtual channel.

In one of the private implementation options, the termination of the existence of a virtual channel is performed on a request transmitted using the inter-process communication mechanism containing the identifier of the virtual channel.

In one of the private implementation options, when detecting by periodically polling switches about devices connected to their interfaces or by notification received by the SDN controller from the switch, a change in the connection topology is detected: communication line failure, switch failure, detection of new connections, moreover: in case of failure the communication line or switch along the route of the formed virtual channel, the SDN controller automatically rebuilds the virtual channel through other available switches.

In one of the private implementation options, a sign of traffic entering the virtual channel is the packet data header fields of the second level of the OSI / ISO network interaction model, on the basis of which routing is supported by the switch; or a sign of traffic are the fields of the header of the third level of the OSI / ISO network interaction model, on the basis of which the switch supports routing; or a sign of traffic are the fields of the header of the fourth level of the OSI / ISO network interaction model, based on which the switch supports routing.

In one of the private implementations, throughput along the route of the virtual circuit is provided through the use of routing algorithms.

In one of the private implementation options, when setting the lifetime of virtual channels in a network of switches between remote data centers, a request to the switch to create rules for processing and routing virtual channel traffic is generated at the time when the virtual channel begins to exist, and at the time when the virtual channel ends, the SDN controller deletes from the configuration of the switches, information about the virtual channels existing between the data centers, and the traffic between the data centers ceases to be transmitted when a series of requests are sent to the switches to change the configuration of the switches, and the record of the route and the bandwidth allocated for the virtual channel is removed from the traffic organization data set.

In one of the particular implementation options, upon receipt of a request to create a virtual channel, the SDN controller searches for the optimal load distribution (load balancing) according to the applied routing algorithm using the lifetime of virtual channels and the sign of the tenant channel service mode that determines the route construction order.

In one of the private implementation options, when building or rebuilding the routes of all virtual channels is limited by the bandwidth of the switch interfaces, the routing of virtual channels is performed taking into account the sign of the tenant channel service mode.

In one of the private implementation options, when constructing virtual circuit routes, the feature of the virtual circuit priority service mode is used to displace tenants from the topology graph of virtual circuits.

In one particular implementation, the traffic engineering dataset is stored in the format of a traffic engineering database hosted locally or remotely.

In one particular implementation, a set of virtual circuit tenant data is stored in the format of a virtual circuit tenant database hosted locally or remotely.

In one of the private implementation options, the functions of the SDN controller are duplicated by an additional SDN controller according to the principle of the main and backup SDN controller.

In one of the private implementation options, the creation of a virtual channel is initiated using the 'event subscription' mechanism, in which the switches inform the SDN controller about the arrival of data with a given attribute, upon receipt of which the switch notifies the SDN controller, and the SDN controller, based on the specified parameters, creates for this traffic is a virtual circuit.

In one of the private implementation options, a series of requests from the SDN controller to the switches is a series of NETCONF requests.

In one of the private implementation options, a series of requests from the SDN controller to the switches is a series of RESTCONF requests.

In one of the private implementation options, yang openConfig models, yang models created by the switch manufacturer, or yang models created by third parties are used to form requests to switches by the SDN controller.

In one particular implementation, the series of requests from the SDN controller to the switches is a series of ofConfig requests.

In one of the private implementation options, a series of requests from the SDN controller to controlled switches is a series of openFlow requests.

In one of the particular implementation options, the virtual channel termination condition is a request received by the SDN controller using the interprocess communication mechanism, or the virtual channel expiration event or the exhaustion of a given amount of data transmitted over the virtual channel.

BRIEF DESCRIPTION OF GRAPHICS

FIG. 1 illustrates a variant of a logical meshed network, data transfer schemes between infrastructure cloud services used in a data center and tenants of computing resources;

FIG. 2 illustrates the scheme of communications between data centers over a leased line previously leased by the telecom operator, which has a guaranteed bandwidth, designed for maximum traffic intensity;

FIG. 3 illustrates an example of automated virtual circuit provisioning with QoS features, according to one embodiment;

FIG. 4 illustrates a functional diagram of the SPC controller, according to one of the embodiments of the present technical solution;

FIG. 5 illustrates a variant of the TED database schema according to one embodiment of the present technical solution;

FIG. 6 illustrates an example of an interface overcapacity case;

FIG. 7 illustrates an exemplary embodiment of the present technical solution.

DESCRIPTION OF EMBODIMENTS

Features of the present technical solution will become apparent by referring to examples of embodiments. However, the present technical solution is not limited to the exemplary embodiments disclosed below. The description of the embodiments is nothing more than specific details, defined to assist a person skilled in the art in a thorough understanding of the technical solution. The discussed embodiments are given for the purpose of describing an idea defining a plurality of embodiments. This technical solution is defined only in the scope of the attached formula. The terms "module", "component", "element" and similar used to refer to technical means used in the present description of the present technical solution can be both hardware and an application executable by program code and / or firmware, firmware.

In the following description, the terms "switch" and "router" are used interchangeably and refer to a device that processes the packet data headers of the second, third, and/or fourth layer of the OSI/ISO networking model.

FIG. 3 shows an example of automated provision of a virtual channel with QoS functions, according to one of the embodiments, in particular, a variant of the scheme for automated provision of a virtual channel by a telecom operator between data centers using elements of differentiated and integrated QoS service models is shown.

The proposed technical solution allows you to create a virtual channel for a fixed short period of time and, instead of renting a channel with a larger bandwidth for a long time, limit yourself to renting a virtual channel with sufficient bandwidth for the current needs of the client and do it when the client needs it.

One of the objectives of this technical solution is to automate the provision of a virtual channel between the data center by the telecom operator.

FIG. 3 shows two groups of clients, the software components in the control system of the data center A 202 and the software components in the control system of the data center B 212 . In the initial state, the software components of the two data center control systems (client and server) cannot transfer data to each other; several API calls are made to organize the exchange (in particular, several API calls to the data center control systems 202 , 212 and to the PKS controller 313 ).

Let the first API call ( 373 ), which provides the construction of tunnels for interaction between software components of different data centers, be made to the control systems of data center A 202 and data center B 212 , now the data coming from the clients is sent to the tunnel / tunnels 222 and can go to the switch R1 343 and switch R2 353 , as a result of a call that provides the construction of tunnels for interaction between software components of different data centers.

The second API call ( 363 ), in particular, an API call that notifies the SPC controller about the need to form a virtual channel, is performed to the SPC controller 313 , the SPC controller 313 configures virtual channels on the controlled switches: R1 343 and R2 353 , and the API call contains, at a minimum, data for said setting, including data on entry points of virtual channel traffic, a sign of traffic entering the virtual channel, information about the beginning and end of the virtual channel, information about the tenant ownership of the virtual channel, and data about the required QoS parameters. Virtual circuits allow you to add the functionality of managing lifetime, bandwidth - to provide the functions of QoS service models in different combinations of components, as well as to perform fault-tolerant routing and load balancing. Switch R1 343 routes the tunnel to the network of controlled switches. Through the conditional network, in this case directly, the data is sent from the switch R1 343 to the switch R2 353 . However, it should be understood that the number of nodes and the topology of the network of switches ( 343 , 353 ) controlled by the SDN controller 313 can be arbitrary and is limited, in some embodiments, only by the number of simultaneously open file descriptors at the operating system architecture level of the SDN controller 313 . Routing of virtual circuits can be performed using additional tunneling, such as QinQ, in which case the R2 353 switch extracts the data (in the case of additional tunneling of data transmitted over a virtual circuit, such as QinQ) transmitted over the tunnel and transmits to the network component of the data center control system B 212 . The network software component (in particular, the network service) of the data center control system B 212 extracts the data transmitted by the data center control system software component from the tunnel and passes the destination address to the data center control system software component B. The same happens in the opposite direction, the data coming from the data center control software is processed. data center control system component B data center control system software component A.

Since data is transmitted between data centers over carrier lines, there may be a need for additional functionality that allows you to quickly create channels, control speed, prioritize individual data streams, etc., as shown in FIG. 3 . These functions can be included in the functionality of the overlay network 303 , since their implementation does not depend on the data transfer protocols used, the logical and physical organization of communication lines, and is performed through centralized control, as described below.

The software- defined network controller (SDN) 313 allows you to automatically create virtual channels 323 on controlled switches - rules for processing and routing traffic, add the functionality of managing the lifetime and bandwidth of virtual channels 323 , provide other functions of the models QoS services in different combinations of components, as well as perform fault-tolerant routing and load balancing, as shown in FIG. 3 .

Said virtual channels 323 include (in a particular case, they are) traffic processing and routing rules installed on the switches along the traffic transit route, created by centralized configuration (in particular, management) of the switches by the SDN controller 313 .

The functionality of the overlay network 303 includes (in a particular case is) traffic processing and routing rules installed on the switches along the traffic transit route, created by centralized configuration (in particular, management) of the switches by the SDN controller 313 .

FIG. 4 shows a functional diagram of the PKS controller, according to one of the embodiments of the present technical solution.

As shown in the functional diagram, FIG. 4 , the controller PKS 313 consists of logic that provides routing of virtual channels (control application 404 ) and software libraries, in particular, libraries for interaction with the switch 434 , interaction with the switch 343 , 353 , providing centralized control, configuration of switches on the data path between the data center . The number and type of libraries for interaction with the switch 434 determines the number of protocols supported by the SDN controller 313 used for the interaction of the SDN controller with the switches 343 , 353 . The order and content of the configuration requests/responses (in particular, RPC calls) 333 also depends on the protocol used for the interaction of the PCC controller 313 with the switch 343 , 353 .

The control application of the PKS 404 controller, in the described embodiment, using the NETCONF protocol (network configuration protocol, network device control protocol), performs initial initialization at startup, the switches are polled at the specified addresses. In various embodiments, the addresses of the switches may be stored in the configuration of the controller SDN 313 or set dynamically using inter-process communication mechanisms. RPC calls 333, 444 are made to determine the interfaces on the switches, the bandwidth of the lines, and information about neighboring switches available via connection discovery protocols. Using the received data, the controller PKS 313 builds a graph corresponding to the topology of connections and the bandwidth of the lines between the switches.

PKS controller control application404 maintains TED database records414 (Traffic Engineering Data (TED) databases) obtained during the interrogation of switches and received as a result of processing requests for the formation of virtual channels. Information exchange between the control application 404 and the TED database 414 may consist of data on the topology and resources of the domain of controlled switches, information on the route of virtual channels. The TED database information 414 may be used by the control application of the SDN controller 404 in some embodiments to calculate the route of the virtual circuit or in the event of a disaster recovery (where the fact of a crash requiring disaster recovery may be, for example, the content in the TED database). The TED database can be located on the same software and hardware platform as the PKS controller or hosted outside, remotely. The domain topology graph of controlled switches in the TED database may, in some embodiments, be stored as table entries "switch_tbl" (535) and "interfaces_tbl" (545).

The control application of the SDN controller keeps records of the database of tenants of virtual channels 424 . The communication between the control application 404 and the virtual circuit tenant database may, in some embodiments, consist of virtual circuit tenant identifiers, virtual circuit identifiers, and a tenant privileged service flag. The tenant database information 424 may be used by the control application of the SDN controller 404 in some embodiments to build or reroute virtual circuits, or in case of disaster recovery. The Privileged Service Mode flag defines the routing priority of virtual circuits 323 , which in some embodiments, for example, may be a flag that allows the control application 404 to preempt virtual circuits of other tenants from the topology graph when routing virtual circuits.

The REST API call ( 363 ), in some embodiments, may include, for example, a request to create or delete a virtual circuit ( 323 ).

Centralized management of switches on the data path between remote data centers is performed using the NETCONF protocol (RFC4741 https://tools.ietf.org/html/rfc4741, RFC6241 https://tools.ietf.org/html/rfc6241). The PCC controller 313 may generate a NETCONF request using the YANG data modeling language (RFC6020 https://tools.ietf.org/html/rfc6020https://tools.ietf.org/html/rfc7950, RFC7950). In some embodiments, communication between the SDN controller 313 and controlled switches can be performed using the RESTCONF protocol (RFC8040 https://tools.ietf.org/html/rfc8040, RFC8527 https://tools.ietf.org/html/rfc8527). In some embodiments, communication between the SDN controller 313 and controlled switches may be performed using the openConfig protocol. In some embodiments, the communication between the SPC controller 313 and controlled switches may be performed using the ofConfig protocol /rfc5440, RFC7896 https://tools.ietf.org/html/rfc7896, RFC8253 https://tools.ietf.org/html/rfc8253, RFC8356 https://tools.ietf.org/html/rfc8356, RFC8408 https ://tools.ietf.org/html/rfc8408, RFC8664 https://tools.ietf.org/html/rfc8664, RFC7420 https://tools.ietf.org/html/rfc7420). In some embodiments, communication between the SDN controller 313 and controlled switches can also be performed using the OpenFlow protocol (OpenFlow® Switch Specification 1.3.0 https://opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1 .3.0.pdf).

Centralized management functions provide:

- interrogation of switches during the initial initialization of the PKS 313 controller;

- automatic creation and removal of virtual channels 323 between data centers (in particular, between data center control systems);

- tracking the state and topology of the links of the domain of controlled switches.

So, using centralized control, the switches are polled during the initial initialization of the PKS controller 313 ; automatic creation and deletion of virtual channels 323 between the data center and tracking the state and topology of the links of the domain of controlled switches.

The functions of the control application 404 provide:

- building and rebuilding the route of virtual channels 323 in the network of controlled switches between remote data centers;

- planning, start and end times of the existence of virtual channels 323 in the network of controlled switches between remote data centers;

- building and rebuilding the route, taking into account the sign of the privileged mode of servicing the virtual channel ( 323 );

- load balancing with automatic rerouting of virtual channels 323 in the network of controlled switches;

- fault tolerance during data transmission over virtual channels 323 in case of failure of one or more physical data transmission lines due to automatic rerouting of the virtual channel ( 323 ).

Thus, the control application 404 builds and re-routes virtual channels 323 in the network of controlled switches between remote data centers; planning, start and end times of the existence of virtual channels 323 in the network of controlled switches between remote data centers; building and rebuilding the route, taking into account the sign of the privileged service mode of the virtual channel ( 323 ); load balancing with automatic rerouting of virtual channels 323 in the network of controlled switches; ensuring fault tolerance during data transmission over virtual circuits 323 in case of failure of one or more physical data transmission lines or switches due to automatic rerouting of the virtual circuit ( 323 ).

Features provided by the switches:

- in some embodiments, the implementation of the functions of the integrated service model QoS (guaranteed throughput);

- in some embodiments, the implementation of the function of a differentiated QoS service model (service based on the division of traffic by class);

- in some embodiments, the simultaneous use of the functions of the differentiated and integrated QoS service models in different combinations of components.

Thus, the management of switch settings provides the ability to implement the functions of an integrated QoS service model (guaranteed bandwidth) for data flows transmitted over virtual channels; functions of a differentiated QoS service model (service based on the division of traffic into classes); simultaneous application of the functions of differentiated and integrated QoS service models in different combinations of components.

Automatic creation of virtual circuits 323 ( centralized control functions) is provided by the execution of the REST API request ( 363 ) to the SPC controller 313 . In some embodiments, the API request ( 363 ) to create a virtual circuit ( 323 ) must include the identifiers of the switches and interfaces of the beginning and end of the route, the start and end times of the existence of the virtual circuit ( 323 ), the attribute of the ownership of the virtual circuit ( 323 ) to the tenant, and the traffic attribute falling into the virtual channel ( 323 ).

In some embodiments, as a sign of traffic entering the virtual channel ( 323 ), fields of the network frame header (L2) can be used, based on which the switch supports routing, for example, MAC destination, MAC source, IEEE 802.1Q tag and / or Ethertype . In some embodiments, as a sign of traffic entering the virtual circuit ( 323 ), the fields of the network packet header (L3) can be used, based on which the switch supports routing, for example, based on the version, type of service, time to live, protocol fields , source ip address, destination ip address, ip options IPv4 packet header fields. In some embodiments, as a sign of traffic entering the virtual circuit ( 323 ), the fields of the transport layer (L4) header can be used, based on which the switch supports routing, for example, source port, destination port, ACK, PSH, RST, SYN, FIN of TCP protocol, source port, destination port of UDP protocol. Also, in some embodiments, as a sign of traffic entering the virtual channel ( 323 ), other packet fields of other protocols or their combinations can be used, based on which the switch supports routing.

Execution of requests to the PKS 313 controller to create a virtual channel ( 323 ) for data transmission in the variant using the NETCONF protocol causes the execution of a series of NETCONF requests ( 333 ) from the PKS 313 controller to the controlled switches. Depending on the sign of the traffic entering the virtual channel ( 323 ) and the selected QoS model, the type and sequence of requests to be executed may differ. For example, in some embodiments, to provide a guaranteed bandwidth of the virtual channel ( 323 ), on each switch of the constructed route, a request can be made (which is sufficient for this) to configure a filter that separates the selected traffic and a request to configure a shaper (from English traffic shaping) A that limits the bandwidth for the selected traffic. The guarantee of the required bandwidth of the virtual channel is provided by the control application 404 based on the records of the TED 414 database using both standard (Dijkstra, Bellman-Ford algorithms, etc.) and new (Maximally Redundant Trees) routing algorithms in different implementations, as well as with the help of algorithms that can be developed later, depending on the PKS used in the controller. After the requests are made, the switches on the data path between the data centers are configured to transfer traffic between the data centers (as shown in FIG. 3 ), an entry about the route of the virtual channel is added to the TED database (in the column corresponding to the topology of connections between the switches and the bandwidth of the lines) and the bandwidth it occupies. In some embodiments, the TED database schema may be as shown in FIG. 5 .

FIG. 5 shows a variant of the TED database schema according to one embodiment of the present technical solution. In this embodiment, the TED database consists of tables: a table containing a list of virtual circuit tenants "holder_tbl"505; a table containing a list of virtual channels "channel_tbl"515; a table containing a list of signs of traffic entering the virtual channel "properties_tbl"525; a table containing a list of switches "switch_tbl"535; a table containing a list of switch interfaces "interfaces_tbl"545; a table containing a list of virtual circuit routes "hop_tbl" 555 . The tables in the TED database schema are linked by key fields (by unique record identifiers).

In FIG. 5 of the TED database implementation, the VC route leg entry may be as shown in Table 1.

Table 1. Example of a TED virtual circuit route section record.

hop_ident 7 channel_ident 2 hop_number 0 switch_dpid 00:1f:d0:00:ba:9b switch_prev_dpid null switch_next_dpid 00:1f:d0:00:ba:9c switch_interface_in ge-0/0/3.1 switch_interface_out ge-0/0/0.1 switch_state TRUE

In this example, the VC route leg entry reports that: the unique identifier of this entry is "7"; the identifier of the virtual channel to which the entry refers is equal to "2"; serial number of the route section "0"; switch ID "00:1f:d0:00:ba:9b"; identifier of the previous switch "null"; ID of the next switch "00:1f:d0:00:ba:9c"; virtual channel data comes from the "ge-0/0/3.1" interface; virtual channel data is routed to the "ge-0/0/0.1" interface; the value of the switch_state field set to "TRUE" indicates that the switch has been configured to route virtual circuit data.

Table 2. An example of a selection about the route of the created virtual circuit from the TED database.

hop_ident 7 eight 9 ten channel_ident 2 2 2 2 hop_number 0 one 2 3 switch_dpid 00:1f:d0:00:ba:9b 00:1f:d0:00:ba:9c 00:1f:d0:00:ba:9d 00:1f:d0:00:ba:9e switch_prev_dpid null 00:1f:d0:00:ba:9b 00:1f:d0:00:ba:9c 00:1f:d0:00:ba:9d switch_next_dpid 00:1f:d0:00:ba:9c 00:1f:d0:00:ba:9d 00:1f:d0:00:ba:9e null switch_interface_in ge-0/0/3.1 ge-0/0/0.1 ge-0/0/0.1 ge-0/0/2.1 switch_interface_out ge-0/0/0.1 ge-0/0/2.1 ge-0/0/2.1 ge-0/0/3.1 switch_state TRUE TRUE TRUE TRUE

Upon expiration of the lifetime of the virtual channel or upon request (363) PKS controller313 deletes information stored on switches about virtual channels routed between data centers. What information about virtual channels routed between data centers is removed from the switch configuration depends on the sign of traffic entering the virtual channel and the selected QoS model. By sending NETCONF requests to the switches, the configuration of the switches is changed and, thus, tunnel traffic between the data centers is no longer transmitted, the record of the route and band of the virtual link in the TED database is deleted. The type and sequence of requests may differ depending on the type of traffic entering the virtual channel and the selected QoS model. If a tenant entry is deleted, all virtual circuits associated with the tenant ID are deleted.

Tracking the state and topology of links of the domain of controlled switches, which provides centralized management functions, in different embodiments, can be performed both using periodic polling of switches about neighboring network devices, and (for example, in an embodiment using the NETCONF protocol) using the “subscription to events" (NETCONF Event Notifications, RFC5277, YANG Module for NETCONF Monitoring, RFC 6022; NETCONF Base Notifications, RFC 6470). The switch can receive (in particular, request) information about connections between network devices, for example, using one of the link layer protocols, such as LLDP (Link Layer Discovery Protocol, IEEE 802.1ab), depending on those supported by the switches.

The construction and re-routing of virtual channels, which provides the functions of the control application 404 , in various embodiments, can be performed using both standard (Dijkstra, Bellman-Ford algorithms, etc.) and new (Maximally Redundant Trees) routing algorithms, as well as algorithms that can be developed later, depending on the PKS 313 used in the controller.

The time points of the beginning and end of the existence of virtual channels with a given period monitors the scheduler of the controller PKS 313 . In various embodiments, the scheduler functions may be provided, for example, by API calls of the control application 404 to the operating system of the PCC controller 313 or otherwise. Upon the arrival or end of existence, an RPC call is made to create or delete virtual channels. Start and end time tracking is provided by the functions of the control application 404 .

The construction and rebuilding of the route, taking into account the sign of the privileged mode of servicing tenant channels, is performed by the control application404 PKS controller313,provides control application functions404. In some cases, when a request is received to create a virtual channel, the control application404 may perform rerouting of all virtual circuits, for example, in accordance with the optimizing routing algorithm described below. The privileged service mode flag may determine the order in which routes are constructed. Privileged mode of service flag is contained in the TED database414table "holder_tbl" (505), the "holder_privilege" field. If building or rerouting virtual circuits605,614 limited by the bandwidth of the communication line (switch interfaces)607, then the routing virtual channels611,610 will be executed taking into account the attribute of the privileged service mode, and, for example, an API call to create a virtual channel (363)for virtual channel 2 (610, 614) may be rejected or virtual circuit 2 routing (610, 614)can be rescheduled for another time, as shown inFIG. 6.

FIG. 6 shows an example of the case of exceeding the bandwidth of the interface: the control application of the SDN controller processes requests to create virtual channel_1 605 , 611 with a bandwidth of 300 Mb/s and virtual channel_2 614 , 610 with a bandwidth of 750 Mb/s. According to the topology shown in FIG. 6 route virtual circuit_1 605 , 611 passes through switch 1 603 , link 604 , switch 2 606 , link 607 and switch 3 609 , route virtual circuit_2 614 , 610 passes through switch 4 612 , link 613 , switch 2 606 , line communication 607 and switch 3 609 . Bandwidth of communication lines and interfaces of switches is 1000 Mb/s. Thus, the total throughput of the requested virtual channels 611 , 610 on the route section switch 2 606 - switch 3 609 exceeds the throughput of the communication line 607 .

Virtual channels, the throughput of which, together with the throughput of the constructed routes, exceeds the bandwidth of the switch interfaces (if it is not possible to place all virtual channels in the domain of controlled switches), can be rescheduled for a later time or at the first opportunity (with a change in topology) the route of these virtual channels will be rebuilt.

Load balancing with automatic rerouting of virtual channels in the network of controlled switches, which provides the functions of the control application 404 , is carried out in accordance with the built graph of the topology and bandwidth of communication lines between the switches, the route table of existing virtual channels (Table 2), occupying part of the total network bandwidth controlled switches and a residual graph, which is composed of a graph of the topology and bandwidth of communication lines and a route table of existing virtual channels by optimizing routes when new requests for creating virtual channels arrive, in particular, by using an optimizing routing algorithm. In some embodiments, the optimizing routing algorithm is based on the idea of finding complementary paths with a given bandwidth from the flow scaling method. So, the search for complementary paths with a given throughput is carried out from the flow scaling method. If for a new request to create a virtual circuit it is not possible to build a route in the residual graph of the network of controlled switches, then the route is searched using potential edges. A potential edge is an edge involved in the route of the laid virtual circuit and having the capacity of this virtual circuit. On a virtual link path between the same pair of neighboring vertices in the link topology graph, a residual and a potential edge can be used simultaneously to satisfy the throughput requirement. If a potential edge is involved in the route for a new request, then the corresponding virtual circuits are (necessarily) re-routed. Along with this, in a particular case, one can consider rebuilding the route of a virtual channel as a new request, so the same algorithm can be used for the problem of rebuilding the route, but with fixed routes for the already considered virtual channels. Since rerouting may affect the consideration of a large number of virtual circuits, the algorithm has a configurable parameter "k" - the maximum number of virtual circuits whose routes can be rerouted. With this algorithm, network bandwidth utilization can be increased, in particular, since dynamic rebuilding of routes, in a particular case, can help in a situation where there is no route in the residual network graph.

Fault tolerance for data transmission over virtual circuits in the event of failure of physical data transmission lines or switches, which provides the functions of the control application 404 , is carried out in accordance with the built topology graph and the route table of existing virtual circuits (a table containing a list of virtual circuit routes "hop_tbl" 555 ) in depending on changes in the state of communication lines or switches. In the event of a failure of communication lines or switches, virtual links whose route uses the sections of the network where the failure occurred are removed from the configuration of switches and the route table of existing virtual links. These virtual circuits may be treated as a new request and, in some embodiments, the optimization routing algorithm described above or another may be applied to them.

In the event of a failure of the SDN controller 313 , the virtual channel routing table and the state of the network topology of the controlled switches are stored in the TED database 414 of the SDN controller. The switches of the controlled network continue to operate in the state before the failure of the PKS 313 controller. Upon restoration of the PKS 313 controller, the primary initialization of the network topology of the controlled switches is performed. Virtual circuit routes stored in the TED 414 database of the PKS 313 controller are being loaded.

In an embodiment of the integrated QoS service model, for traffic that has a sign that corresponds to entering a virtual circuit, a bandwidth limit is set as part of the provision of such a function by switches. For each physical interface in the network of controlled switches, the sum of the throughputs of virtual circuits passing through this interface is limited by the bandwidth of the physical interface. If no route is found for a virtual circuit that exceeds the physical bandwidth of the switch interface, the creation of the virtual circuit fails. When virtual circuits are rebuilt, routes can be rescheduled at a later time, or at the first opportunity (for example, with a change in the topology of the network of controlled switches), the route of these virtual circuits will be rebuilt.

An example of NETCONF requests sent by the SDN controller to controlled switches is shown below. The first request creates a bandwidth limit on the virtual circuit. The second request creates a filter that determines the traffic that enters the virtual channel, binds the created bandwidth limit to it, and sets the interface for routing virtual channel traffic. The third request applies the changes to the actual switch configuration.

As a result of processing requests by controlled switches along the data transit route, a virtual channel is created for the GRE tunnel (L3) with the identifier GREKEY 579, which performs packet data transmission with a bandwidth limit of 20 Mbps.

In an implementation of a differentiated QoS model, traffic having a characteristic that matches that entering the channel is set to class of service values in accordance with the priority value of the IEEE 802.1p header fields, as part of the provision of such a function by switches.

In the embodiment of the simultaneous use of differentiated and integrated QoS service models for traffic that has a sign that corresponds to entering the channel, both the value of the classes of service is set in accordance with the value of the priority of the IEEE 802.1p header fields and the bandwidth limit, within the framework of providing such a function by switches. For each physical interface in the network of controlled switches, the sum of the throughputs of virtual links passing through this interface is limited by the bandwidth of the physical interface. If no route is found for a virtual circuit that exceeds the physical bandwidth of the switch interface, the creation of the virtual circuit fails. When rebuilding virtual circuits, routes can be rescheduled for a later time, or at the first opportunity (with a change in the topology of the network of controlled switches), the route of these virtual circuits will be rebuilt.

An example of NETCONF requests to delete a virtual channel sent by the SDN controller to controlled switches is given below. The first request removes the bandwidth limit of the virtual circuit. The second request removes the filter that determines the traffic that enters the virtual circuit. The third request applies the changes to the actual switch configuration.

FIG. 7 shows an exemplary embodiment of the present technical solution.

In step 705 , the switches controlled by the SDN controller perform an exchange of connection discovery protocol packets.

In step 710 , the SDN controller periodically polls the switches, specified using the interprocess communication mechanism, about the interfaces existing on the switches, the bandwidth of the lines, and about the devices connected to their interfaces with the formation of the first data set.

In a particular case, the information for the formation of the first data set is specified statically.

In step 715 , based on the first set of data, the SDN controller generates a traffic management data set containing data about the topology and resources of the switch network.

In a particular case, a traffic engineering data set is stored in the format of a traffic engineering database hosted locally or remotely.

In step 720 , the SDN controller, using the interprocess communication mechanism, receives a request to create a virtual circuit tenant entry and a tenant virtual circuit service mode flag, where the service mode flag specifies a priority when building virtual circuit routes.

In step 725 , the SDN controller generates a virtual circuit tenant dataset containing: virtual circuit tenant identifiers, virtual circuit identifiers, and tenant channel service mode matching flag.

In a particular case, a set of virtual circuit tenant data is stored in the format of a virtual circuit tenant database hosted locally or remotely.

In step 730 , the SDN controller, using the inter-process communication mechanism, receives a request to form a virtual channel, containing at least: data on the entry points of the virtual channel traffic, a sign of traffic entering the virtual channel, information about the beginning and end of the virtual channel, data about ownership virtual channel to the tenant and data on the required QoS parameters.

In a particular case, the request for the formation of a virtual channel, as information about the beginning and end of the virtual channel, contains the lifetime of the virtual channel.

In a particular case, when a request is received to create a virtual channel, the SDN controller searches for the optimal load distribution (load balancing) according to the applied routing algorithm using the time interval of the existence of virtual channels and the sign of the tenant channel service mode that determines the order of building routes.

In a particular case, when specifying the lifetime of virtual channels in a network of switches between remote data centers, a request to the switch to create rules for processing and routing virtual channel traffic is generated at the time the virtual channel begins to exist, and at the end of the virtual channel, the SDN controller removes it from the switch configuration information about the virtual channels existing between the data centers, and traffic between the data centers ceases to be transmitted when a series of requests are sent to the switches to change the configuration of the switches, and the record about the route and the bandwidth allocated for the virtual channel is removed from the traffic organization data set.

In a particular case, the request for the formation of a virtual channel, as information about the beginning and end of the virtual channel, contains the maximum value of the amount of data transmitted over the virtual channel.

In a particular case, a sign of traffic entering the virtual channel is the packet data header fields of the second level of the OSI / ISO network interaction model, on the basis of which the switch supports routing; or a sign of traffic are the fields of the header of the third level of the OSI / ISO network interaction model, on the basis of which the switch supports routing; or a sign of traffic are the fields of the header of the fourth level of the OSI / ISO network interaction model, based on which the switch supports routing.

In step 735 , the SDN controller constructs the virtual circuit route considering: tenant circuit service mode matching flag, switch domain bandwidth resource, virtual circuit start and end information, and QoS parameters requested for the virtual circuits.

In step 740 , the SDN controller adds records about the virtual circuit to the traffic organization data set: the route of the virtual circuit, the sign of traffic entering the virtual circuit, information about the beginning and end of the virtual circuit, and the bandwidth occupied by the virtual circuit.

In step 745 , the SDN controller adds to the virtual circuit tenants dataset records about the ownership of the virtual circuit by the tenant.

In step 750 , the SDN controller performs a series of requests to the switches to configure the switches along the constructed virtual circuit route with the formation of at least one virtual circuit in at least one direction, where the configuration includes rules for processing and routing traffic, taking into account the network bandwidth resource and parameters QoS.

In a particular case, the creation of a virtual channel is initiated using the 'event subscription' mechanism, in which the switches inform the SDN controller about the arrival of data with a given attribute, upon receipt of which the switch notifies the SDN controller, and the SDN controller, based on the specified parameters, creates a virtual channel for this traffic. channel.

In a particular case, a series of requests from the SDN controller to the switches is a series of NETCONF requests.

In a particular case, a series of requests from the SDN controller to the switches is a series of RESTCONF requests.

In a particular case, to form requests to switches by the SDN controller, openConfig yang models, yang models created by the switch manufacturer, or yang models created by third parties are used.

In a particular case, a series of requests from the SDN controller to the switches is a series of ofConfig requests.

In a particular case, a series of requests from the SDN controller to controlled switches is a series of openFlow requests.

In step 755 , in response to the virtual circuit termination condition, the SDN controller executes a series of requests to the switches along the constructed virtual circuit route to remove the rules for processing and routing virtual circuit traffic.

In a particular case, the termination of the existence of a virtual channel is performed upon a request transmitted using the interprocess communication mechanism containing the identifier of the virtual channel.

In a particular case, when detecting by means of periodic polling of switches about devices connected to their interfaces or by notification received by the SDN controller from the switch, a change in the connection topology is detected: communication line failure, switch failure, detection of new connections, moreover: in the event of a communication line failure or switch along the route of the formed virtual link, the SDN controller automatically rebuilds the virtual link through other available switches.

In a particular case, throughput along the route of the virtual circuit is provided through the use of routing algorithms.

In a particular case, when the construction or rebuilding of routes of all virtual channels is limited by the bandwidth of the switch interfaces, the routing of virtual channels is performed taking into account the sign of the tenant's channels service mode.

In a particular case, when constructing virtual circuit routes, the feature of the virtual circuit priority service mode is used to displace tenants from the topology graph of virtual circuits.

In a particular case, the functions of the SPC controller are duplicated by an additional SPC controller according to the principle of the main and backup SPC controller.

In a particular case, the virtual channel termination condition is a request received by the SDN controller using the interprocess communication mechanism, or an event of expiration of the virtual channel lifetime or exhaustion of the specified amount of data transmitted over the virtual channel.

The description of this technical solution is a description of examples illustrating the proposed technical solution, other modifications are possible. It should be taken into account that this description is not intended to define the scope or boundaries of the proposed technical solution. The present description contains simplified embodiments of the present technical solution. Various embodiments of this technical solution can be much more complicated.

In conclusion, it should be noted that the information given in the description are examples that do not limit the scope of the present technical solution defined by the formula. It becomes clear to the person skilled in the art that there may be other embodiments of the present technical solution, consistent with the essence and scope of the present technical solution.

Claims (33)

1. A method for forming a virtual channel between data processing centers (DPC) using a software-defined network (SDN) controller, in which: - switches controlled by the SDN controller perform packet exchange of connection discovery protocols; - the SDN controller periodically polls the switches, specified using the interprocess communication mechanism, about the interfaces existing on the switches, the bandwidth of the lines and about the devices connected to their interfaces with the formation of the first data set; - based on the first data set, the SDN controller generates a traffic organization data set containing data on the topology and resources of the switch network; - the SDN controller, using the inter-process communication mechanism, receives a request to create a tenant record of virtual channels and a sign of compliance with the maintenance mode of the tenant's virtual channels, where the sign of the maintenance mode sets the priority when building virtual channels routes; - the SDN controller generates a data set of tenants of virtual channels, containing: identifiers of tenants of virtual channels, identifiers of virtual channels and a sign of compliance with the tenant's channel service mode; - the SDN controller, using the interprocess communication mechanism, receives a request to form a virtual channel, containing at least: data on the entry points of the virtual channel traffic, a sign of traffic entering the virtual channel, information about the beginning and end of the virtual channel, data about the ownership of the virtual channel to the tenant and data on the required QoS parameters; - the SDN controller constructs the route of the virtual channel, taking into account: the sign of compliance with the service mode of the tenant channels, the bandwidth resource of the switch domain, information about the beginning and end of virtual channels and the QoS parameters requested for virtual channels; - the SDN controller adds records about the virtual channel to the traffic organization data set: the route of the virtual channel, the sign of the traffic entering the virtual channel, information about the beginning and end of the virtual channel and the bandwidth occupied by the virtual channel; - the SDN controller adds to the dataset of tenants of virtual channels records about the ownership of the virtual channel by the tenant; - the SDN controller performs a series of requests to the switches to configure the switches along the constructed virtual channel route with the formation of at least one virtual channel in at least one direction, where the setting includes rules for processing and routing traffic, taking into account the network bandwidth resource and QoS parameters; - in response to the virtual channel termination condition, the SDN controller executes a series of requests to the switches along the constructed virtual channel route to remove the rules for processing and routing virtual channel traffic. 2. The method according to claim 1, wherein the information for generating the first data set is statically specified. 3. The method according to claim 1, wherein the request to form a virtual channel, as information about the start and end of the virtual channel, contains the lifetime of the virtual channel. 4. The method according to claim 1, in which the request to form a virtual channel, as information about the beginning and end of the virtual channel, contains the maximum value of the amount of data transmitted over the virtual channel. 5. The method of claim 1, wherein terminating the existence of the virtual channel is performed upon a request transmitted by the interprocess communication mechanism containing the identifier of the virtual channel. 6. The method according to claim 1, in which upon detection by periodically polling the switches about the devices connected to their interfaces or by notification received by the SDN controller from the switch, a change in the connection topology is detected: communication line failure, switch failure, detection of new connections, and : in case of failure of the communication line or switch along the route of the formed virtual channel, the SDN controller automatically rebuilds the virtual channel through other available switches. 7. The method according to claim 1, in which the sign of the traffic entering the virtual channel are the packet data header fields of the second level of the OSI/ISO network interaction model, based on which the switch supports routing; or a sign of traffic are the fields of the header of the third level of the OSI / ISO network interaction model, on the basis of which the switch supports routing; or a sign of traffic are the fields of the header of the fourth level of the OSI / ISO network interaction model, based on which the switch supports routing. 8. The method of claim 1, wherein throughput along the virtual circuit path is provided through the use of routing algorithms. 9. The method according to claim 1, in which when specifying the lifetime of virtual channels in a network of switches between remote data centers, a request to the switch to create rules for processing and routing traffic of a virtual channel is formed at the time when the virtual channel begins to exist, and at the time when the existence of the virtual channel ends. channel, the SDN controller removes from the configuration of the switches information about the virtual channels existing between the DPCs, and the traffic between the DPCs ceases to be transmitted when a series of requests are sent to the switches to change the configuration of the switches, and the record of the route and the bandwidth allocated for the virtual channel is removed from the traffic organization data set. 10. The method according to claim 1, in which, upon receipt of a request to create a virtual channel, the SDN controller searches for the optimal load distribution (load balancing) according to the applied routing algorithm using the time interval for the existence of virtual channels and the sign of the tenant channel service mode that determines the order of building routes . 11. The method according to claim 1, in which, when the construction or rebuilding of routes of all virtual channels is limited by the bandwidth of the switch interfaces, the routing of virtual channels is performed taking into account the sign of the service mode of tenant channels. 12. The method according to claim 1, in which, when constructing the routes of virtual circuits, the feature of the priority service mode of virtual circuits is used to displace tenants from the topology graph of virtual circuits. 13. The method of claim 1, wherein the traffic management data set is stored in a traffic management database format hosted locally or remotely. 14. The method of claim 1, wherein the virtual circuit tenant data set is stored in a virtual circuit tenant database format hosted locally or remotely. 15. The method according to claim 1, in which the functions of the SDN controller are duplicated by an additional SDN controller according to the principle of the main and backup SDN controller. 16. The method according to claim 1, in which the creation of a virtual channel is initiated using the 'event subscription' mechanism, in which the switches inform the SDN controller about the arrival of data having a given attribute, upon receipt of which the switch notifies the SDN controller, and the SDN controller based on the specified parameters creates a virtual channel for this traffic. 17. The method of claim 1, wherein the series of requests from the SDN controller to the switches is a series of NETCONF requests. 18. The method of claim 1, wherein the series of requests from the SDN controller to the switches is a series of RESTCONF requests. 19. The method of claim 1, wherein the SDN controller uses openConfig yang models, yang models created by the switch manufacturer, or yang models created by third parties to generate requests to the switches. 20. The method of claim 1, wherein the series of requests from the SDN controller to the switches is a series of ofConfig requests. 21. The method of claim 1, wherein the series of requests from the SDN controller to the controlled switches is a series of openFlow requests. 22. The method of claim 1, wherein the virtual channel termination condition is a request received by the SDN controller using an interprocess communication mechanism, or a virtual channel timeout event or exhaustion of a predetermined amount of data transmitted over the virtual channel.

Images