WO2018223617A1

WO2018223617A1 - Cross-domain path computation method for multi-domain controller

Info

Publication number: WO2018223617A1
Application number: PCT/CN2017/111552
Authority: WO
Inventors: 刘锦秋
Original assignee: 烽火通信科技股份有限公司
Priority date: 2017-06-06
Filing date: 2017-11-17
Publication date: 2018-12-13
Also published as: CN107332768B; CN107332768A

Abstract

The present invention discloses a cross-domain path computation method for a multi-domain controller, comprising: single-domain controllers constructing intra-domain topology structures according to nodes and inter-node links in individual domains, and reporting domain identification information of all of the nodes in the individual domains; a multi-domain controller constructing an inter-domain topology structure according to domains and inter-domain links controlled by the multi-domain controller; the multi-domain controller computing, based on the inter-domain topology structure, a domain sequence of all domains passed through from a domain in which a source node is located to a domain in which a destination node is located; the multi-domain controller initiating an intra-domain path computation request to single-domain controllers of the domains in the domain sequence, and the single-domain controller computing intra-domain paths according to the intra-domain topology structures and reporting intra-domain path computation results; and the multi-domain controller obtaining a plurality of cross-domain paths by combination according to the intra-domain path computation results of the domains and the inter-domain links, and selecting an optimal path as a multi-domain path. The present invention resolves the problem of cross-domain path computation in complex large-scale multi-domain networks and can greatly accelerate the application of SDNs and generate economic benefit.

Description

Cross-domain path calculation method for multi-domain controller

Technical field

The invention relates to path calculation of a multi-domain controller in a software defined network (SDN), in particular to a cross-domain path calculation method of a multi-domain controller.

Background technique

The rapid development of information technology and the ever-changing needs of users not only bring new demands and challenges to communication networks, but also put forward higher requirements on the equipment capabilities and management complexity of communication networks. The communication network needs to further simplify operation and maintenance. Develop network potential and provide fast and flexible business support capabilities.

SDN has the technical features of control and forwarding separation and programmable application programming interface (API), which can better support the cooperation mechanism between application layer and network layer, and support virtualized management and centralized control of network resources. The control layer function of SDN is provided by the controller. For complex networks, SDN needs to divide the network into domains to form a multi-domain network. Each domain network is controlled by a separate controller. For the entire network, multiple domain controllers are used. Management, multi-domain controllers and single-domain controllers work together through interfaces.

In the SDN architecture, the service is initiated by the APP to the controller through the northbound interface. After the controller completes the path calculation of the service, the label is allocated, and then the flow table is sent to each switch in the path through the protocol such as openflow. The result of path calculation plays a decisive role in the success and quality of the service; therefore, in multi-domain networks, how multi-domain controllers perform optimal cross-domain path calculation is a key technical problem of SDN.

Summary of the invention

The technical problem to be solved by the present invention is how to perform optimal cross-domain path calculation in a multi-domain network in a multi-domain network.

In order to solve the above technical problem, the technical solution adopted by the present invention is to provide a cross-domain path calculation method for a multi-domain controller, including the following steps:

Step S10: Each single-domain controller constructs a corresponding intra-domain topology according to a node between the corresponding domain and a link between the nodes, and reports domain identification information of all nodes in the domain to the multi-domain controller; the multi-domain controller controls according to the control Inter-domain topology is constructed for all domains and inter-domain links;

Step S20: According to the cross-domain service establishment request, the multi-domain controller calculates, according to the inter-domain topology structure, a domain sequence of all domains passing through the domain where the source node is located to the domain where the sink node is located;

Step S30: The multi-domain controller initiates an intra-domain path calculation request to the single-domain controller of each domain in the domain sequence; the single-domain controller of each domain calculates the intra-domain path according to the intra-domain path calculation request and the intra-domain topology structure, and calculates the intra-domain path. The result is sent to the multi-domain controller;

Step S40: The multi-domain controller combines the intra-domain path calculation result and the inter-domain link of each domain involved in the domain sequence, and combines to obtain a plurality of complete end-to-end cross-domain paths from the source node to the sink node;

Step S50: The multi-domain controller selects an optimal path from the multiple end-to-end inter-domain paths as the multi-domain path according to the route optimization policy.

In the above method, step S10 includes the following steps:

Step S11: Each single domain controller controlled by the same multi-domain controller discovers nodes and links in the corresponding domain through the LLDP protocol;

Step S12: Each single domain controller separately constructs a corresponding intradomain topology according to a link relationship between nodes and nodes in the domain;

Step S13: The multi-domain controller discovers the link between the domain controlled by the domain and the domain by statically configuring the inter-domain link or the LLDP automatic discovery mode.

Step S14: The multi-domain controller constructs an inter-domain topology according to the link relationship between the domain and the domain controlled by the multi-domain controller;

Step S15: Each single-domain controller reports the domain identifier information of all nodes in the domain to the multi-domain controller through the northbound interface, and the multi-domain controller records the domain identifier information of all the nodes.

In the above method, one or more domain sequences are included from the source domain to the sink domain;

Each of the domain sequences is composed of a source node, a boundary node and a sink node of a domain from the source node to the sink node, except for the source domain and the sink domain where the source node and the sink node are located, and the domain of the other domain sequence is the intermediate domain. The boundary node of the intermediate domain includes a source boundary node and a sink boundary node.

In the above method, step S20 includes the following steps:

Step S21: The multi-domain controller receives the cross-domain service establishment request sent by the APP through the northbound interface.

Step S22: The multi-domain controller parses the service establishment request, and extracts the source node and the sink node;

Step S23: The multi-domain controller searches for the domain identifier information of the extracted source node and the sink node, and determines whether the domain of the source node and the sink node are the same. If not, perform step S24; otherwise, enter the intra-domain path calculation;

Step S24, triggering cross-domain path calculation;

Step S25: The multi-domain controller calculates all possible domain sequences from the source domain to the sink domain based on the inter-domain topology.

In the above method, the multi-domain controller initiating the intra-domain path calculation request to the single domain controller of each domain in the domain sequence includes:

The multi-domain controller calculates a request from the source node initiated by the single domain controller of the source domain in the domain sequence to the intra-domain path of the border node of the source domain in the domain sequence;

The multi-domain controller initiates an intra-domain path computation request from the source boundary node to the sink boundary node in the domain in the domain sequence to the single domain controller of the intermediate domain in the domain sequence;

The multi-domain controller initiates an intra-domain path computation request from the boundary node of the sink domain in the domain sequence to the sink node to the single domain controller of the sink domain.

In the above method, the route optimization policy is that the minimum number of hops is optimal.

The invention cooperates with the multi-domain controller and the single domain controller to complete the calculation of the optimal cross-domain path, and the multi-domain controller is responsible for calculating the domain sequence, and the single-domain controller is responsible for calculating the path in the corresponding domain, and then the multi-domain controller will The path calculation result of each single domain controller and the inter-domain link are assembled into multiple end-to-end cross-domain paths, and finally an optimal cross-domain path is selected, which solves the problem that SDN is applied to complex large-scale multi-domain networks. The cross-domain path calculation problem can greatly accelerate the application of SDN and generate greater economic benefits.

DRAWINGS

Figure 1 shows a typical SDN application scenario in a multi-domain network.

2 is a flowchart of a method for calculating a cross-domain path of a multi-domain controller according to the present invention;

3 is a topological view corresponding to an intra-domain topology constructed by the first single domain controller in FIG. 1;

4 is a topological view corresponding to an intra-domain topology constructed by the second single domain controller in FIG. 1;

5 is a topological view corresponding to an intra-domain topology constructed by the third single-domain controller in FIG. 1;

6 is a topological view corresponding to an inter-domain topology constructed by the multi-domain controller of FIG. 1;

Figure 7 is a specific flowchart of step S10 in the present invention;

FIG. 8 is a specific flowchart of step S20 in the present invention.

detailed description

The present invention will be described in detail below with reference to the drawings and specific embodiments.

Figure 1 shows a typical SDN application scenario in a multi-domain network. The multi-domain network consists of three domains. The first domain 1 includes a source node S, a border node BN11, and a border node BN12. The controller 10 controls; the second domain 2 includes four boundary nodes, namely BN21, BN22, BN23, and BN24, controlled by the second single domain controller 20; the third domain 3 includes the boundary node BN31, the boundary node BN32, and the sink node. D, controlled by the third single domain controller 30; the first single domain controller 10, the second single domain controller 20, and the third single domain controller 30 communicate with the multi-domain controller 40 through the northbound interface; the multi-domain controller 40 and APP communicate through the northbound interface to complete service establishment and the like, for example, the APP initiates a service establishment request from the source node S of the first domain 1 to the sink node D of the third domain 3 to the multi-domain controller 40, and the multi-domain controller It is responsible for completing the cross-domain path calculation from the source node S to the sink node D.

The invention cooperates with the multi-domain controller and the single domain controller to complete the calculation of the optimal cross-domain path, and the multi-domain controller is responsible for calculating the domain sequence, and the single-domain controller is responsible for calculating the path in the corresponding domain, and then the multi-domain controller will The path calculation result of each single domain controller and the inter-domain link are assembled into multiple end-to-end cross-domain paths, and finally an optimal cross-domain path is selected. As shown in FIG. 2, the method for calculating a cross-domain path of a multi-domain controller provided by the present invention includes the following steps:

Step S10: Each single-domain controller constructs a corresponding intra-domain topology according to a link between the node and the node in the corresponding domain, and reports the domain identifier information of all nodes in the corresponding domain to the multi-domain controller record; the multi-domain controller The inter-domain topology is constructed according to all the domains it controls (equivalent to the topology node) and the inter-domain links, and the links between the nodes and nodes in each domain are not considered here.

As shown in FIG. 7, in the present invention, step S10 includes the following steps:

Step S12: Each single-domain controller separately constructs a corresponding intra-domain topology according to the relationship between the nodes in the domain and the link relationship between the nodes. After the completion of the construction, a node between the intra-domain nodes and the inter-node is formed in each single-domain controller. The topology view of the intra-domain topology formed by the first single-domain controller 10, the second single-domain controller 20, and the third single-domain controller 30 is shown in FIG. 3. Figure 4 and Figure 5;

Step S14: The multi-domain controller constructs an inter-domain topology structure according to the link relationship between the domain and the domain controlled by the multi-domain controller. After the completion, the multi-domain controller forms an inter-domain topology view composed of the domain and the inter-domain link. FIG. 1 is an example, and the topology view corresponding to the inter-domain topology constructed by the multi-domain controller is shown in FIG. 6;

Step S20: According to the cross-domain service establishment request sent by the APP, the multi-domain controller calculates a domain sequence of the domain (source domain) where all the source nodes are located to the domain (solf domain) where the sink node is located, based on the inter-domain topology structure; The sink domain may include multiple domain sequences, that is, multiple paths exist from the source domain to the sink domain, and each of the domain sequences consists of a source node, a boundary node and a sink node of the domain from the source node to the sink node, except the source. The source domain and the sink domain where the node and the sink node are located, and the domain of the other domain sequence is the intermediate domain. The boundary node of the intermediate domain includes the source boundary node and the sink boundary node, and the topology view corresponding to the inter-domain topology structure in FIG. 6 is taken as an example. Assuming that each inter-domain link satisfies the routing constraint, the multi-domain controller calculates four domain sequences, which are:

S-BN11-BN21-BN23-BN31-D;

S-BN11-BN21-BN24-BN32-D;

S-BN12-BN22-BN23-BN31-D;

S-BN12-BN22-BN24-BN32-D.

As shown in FIG. 8, in the present invention, step S20 includes the following steps:

Step S21: The multi-domain controller receives the cross-domain service establishment request sent by the APP through the northbound interface, and establishes the cross-domain service from the source node S of the first domain 1 to the sink node D of the third domain 3 by using FIG. 1 as an example. ;

Step S23: The multi-domain controller searches for the domain identifier information of the extracted source node and the sink node, and determines whether the source node and the domain of the sink node are the same. If they are different, the cross-domain service request is performed, and step S24 is performed; otherwise, the process is performed. Intra-domain path calculation;

Step S24, triggering cross-domain path calculation;

Step S30: The multi-domain controller initiates an intra-domain path calculation request to the single-domain controller of each domain in the domain sequence by using the northbound interface; the single-domain controller of each domain receives the intra-domain path computation request and calculates the intra-domain path according to the intra-domain topology structure. And sending the path calculation result in the domain to the multi-domain controller;

In the present invention, the domain sequence passes through the source domain, the intermediate domain, and the sink domain; the multi-domain controller initiates the intra-domain path computation request to the single domain controller of each domain in the domain sequence through the northbound interface, including:

(1) The multi-domain controller calculates a request from the source node to the single-domain controller of the source domain in the domain sequence to the intra-domain path of the boundary node of the source domain in the domain sequence; according to the domain as shown in FIG. The domain sequence calculated by the inter-domain topology is taken as an example, and the intra-domain path calculation request initiated by the multi-domain controller 40 to the first single-domain controller 10 is: the source node S to the boundary node BN11 and the source node S to the boundary node BN12; First single domain controller 10 The intra-domain path calculation results are two intra-domain paths, namely S-BN11 and S-BN12.

(2) The multi-domain controller initiates the source boundary node to the sink boundary node in the domain in the domain sequence through the northbound interface to the single domain controller of the intermediate domain in the domain sequence (removing the collective name of the source domain and other domains of the sink domain) The intra-domain path calculation request is based on the domain sequence calculated according to the inter-domain topology shown in FIG. 6, and the intra-domain path calculation request initiated by the multi-domain controller 40 to the second single-domain controller 20 is: source boundary node. BN21 to the sink boundary node BN23, the source boundary node BN21 to the sink boundary node BN24, and the source boundary node BN22 to the sink boundary node BN23 and the source boundary node BN22 to the sink boundary node BN24; it is assumed that the link BN22-BN24 does not satisfy the routing constraint. The intra-domain path calculation result of the second single domain controller 20 is four intra-domain paths, which are BN21-BN23, BN21-BN23-BN24, BN22-BN21-BN23, and BN22-BN21-BN23-BN24, respectively.

(3) The multi-domain controller initiates an intra-domain path calculation request of the border node of the sink domain in the domain sequence to the sink node through the northbound interface to the single domain controller of the sink domain. The intra-domain path calculation request initiated by the multi-domain controller 40 to the third single-domain controller 30 is: the boundary node BN31 to the sink node D, the boundary node BN32- to the sink node D; at this time, the intra-domain path of the third single-domain controller 30 The calculation results are two intra-domain paths, namely BN31-D and BN32-D.

Step S40: The multi-domain controller combines the intra-domain path calculation result and the inter-domain link of the single domain controller response of each domain involved in the domain sequence, and combines to obtain multiple complete end-to-end cross-domain paths from the source node to the sink node. Taking the intra-domain path calculation result and the inter-domain link returned by the first single-domain controller 10, the second single-domain controller 20, and the third single-domain controller 30 in FIG. 6 as an example, the multi-domain controller assembles four pieces. Cross-domain paths are:

S-BN11-BN21-BN23-BN31-D;

S-BN11-BN21-BN23-BN24-BN32-D;

S-BN12-BN22-BN21-BN23-BN31-D;

S-BN12-BN22-BN21-BN23-BN24-BN32-D.

Step S50: The multi-domain controller selects an optimal path from the multiple end-to-end inter-domain paths as the multi-domain path according to the route optimization policy. In the present invention, the route optimal policy has the minimum hop count as the optimal. Then, the optimal path selected by the multi-domain controller at this time is S-BN11-BN21-BN23-BN31-D.

It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and modifications of the invention

Claims

A cross-domain path calculation method for a multi-domain controller, comprising the steps of:

Step S10: Each single-domain controller constructs a corresponding intra-domain topology according to a node between the corresponding domain and a link between the nodes, and reports domain identification information of all nodes in the domain to the multi-domain controller; the multi-domain controller controls according to the control Inter-domain topology is constructed for all domains and inter-domain links;

Step S20: According to the cross-domain service establishment request, the multi-domain controller calculates, according to the inter-domain topology structure, a domain sequence of all domains passing through the domain where the source node is located to the domain where the sink node is located;

Step S30: The multi-domain controller initiates an intra-domain path calculation request to the single-domain controller of each domain in the domain sequence; the single-domain controller of each domain calculates the intra-domain path according to the intra-domain path calculation request and the intra-domain topology structure, and calculates the intra-domain path. The result is sent to the multi-domain controller;

Step S40: The multi-domain controller combines the intra-domain path calculation result and the inter-domain link of each domain involved in the domain sequence, and combines to obtain a plurality of complete end-to-end cross-domain paths from the source node to the sink node;

Step S50: The multi-domain controller selects an optimal path from the multiple end-to-end inter-domain paths as the multi-domain path according to the route optimization policy.
The method of claim 1 wherein step S10 comprises the steps of:

Step S11: Each single domain controller controlled by the same multi-domain controller discovers nodes and links in the corresponding domain through the LLDP protocol;

Step S12: Each single domain controller separately constructs a corresponding intradomain topology according to a link relationship between nodes and nodes in the domain;

Step S13: The multi-domain controller discovers the link between the domain controlled by the domain and the domain by statically configuring the inter-domain link or the LLDP automatic discovery mode.

Step S14: The multi-domain controller constructs an inter-domain topology according to the link relationship between the domain and the domain controlled by the multi-domain controller;

Step S15: Each single-domain controller reports the domain identifier information of all nodes in the domain to the multi-domain controller through the northbound interface, and the multi-domain controller records the domain identifier information of all the nodes.
The method of claim 1 wherein the source domain to the sink domain comprise one or more domain sequences;

Each of the domain sequences is composed of a source node, a boundary node and a sink node of a domain from the source node to the sink node, except for the source domain and the sink domain where the source node and the sink node are located, and the domain of the other domain sequence is the intermediate domain. The boundary node of the intermediate domain includes a source boundary node and a sink boundary node.
The method of claim 3 wherein step S20 comprises the steps of:

Step S21: The multi-domain controller receives the cross-domain service establishment request sent by the APP through the northbound interface.

Step S22: The multi-domain controller parses the service establishment request, and extracts the source node and the sink node;

Step S23: The multi-domain controller searches for the domain identifier information of the extracted source node and the sink node, and determines whether the domain of the source node and the sink node are the same. If not, perform step S24; otherwise, enter the intra-domain path calculation;

Step S24, triggering cross-domain path calculation;

Step S25: The multi-domain controller calculates all possible domain sequences from the source domain to the sink domain based on the inter-domain topology.
The method of claim 4, wherein the initiating the intra-domain path computation request by the multi-domain controller to the single-domain controller of each domain in the domain sequence comprises:

The multi-domain controller calculates a request from the source node initiated by the single domain controller of the source domain in the domain sequence to the intra-domain path of the border node of the source domain in the domain sequence;

The multi-domain controller initiates an intra-domain path computation request from the source boundary node to the sink boundary node in the domain in the domain sequence to the single domain controller of the intermediate domain in the domain sequence;

The multi-domain controller initiates an intra-domain path computation request from the boundary node of the sink domain in the domain sequence to the sink node to the single domain controller of the sink domain.
The method of claim 1, wherein the route optimization policy is that the minimum number of hops is optimal.