CN113852553A

CN113852553A - Flow scheduling method and system and SDN controller

Info

Publication number: CN113852553A
Application number: CN202010597725.9A
Authority: CN
Inventors: 刘志华; 卢泉; 贾曼; 黄卓君
Original assignee: China Telecom Corp Ltd
Current assignee: China Telecom Corp Ltd
Priority date: 2020-06-28
Filing date: 2020-06-28
Publication date: 2021-12-28
Anticipated expiration: 2040-06-28
Also published as: CN113852553B

Abstract

The disclosure relates to a traffic scheduling method and system, an SDN controller and a computer storage medium, and relates to the technical field of communication. The traffic scheduling method executed by the SDN controller and used between the first routing device and the second routing device comprises the following steps: receiving a route calculation request of second routing equipment, wherein the route calculation request comprises a first route prefix list of the first routing equipment, and the first route prefix list comprises at least one route prefix which is reachable by the first routing equipment and has the same route calculation constraint condition; determining at least one path reaching at least one routing prefix and a path identifier corresponding to the at least one path according to the path calculation request; sending at least one routing prefix, a path identifier and at least one path to a second routing device, the at least one routing prefix being stored in a second routing prefix list of the second routing device; receiving prefix change information of a first routing prefix list; and controlling the second routing equipment to update the second routing prefix list according to the prefix change information.

Description

Flow scheduling method and system and SDN controller

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to a traffic scheduling method and system, an SDN controller, and a computer-readable storage medium.

Background

In the related art, in an inter-domain traffic scheduling environment of an SDN (Software Defined Network), in response to a routing Computation request including a target routing prefix sent by a routing device serving as an ingress node, an SDN controller issues Path information reaching the target routing prefix to the ingress node by using a PCEP (Path Computation Element Communication Protocol) message according to Network topology information, so that the ingress node always directs traffic reaching the target routing prefix to be forwarded from an designated egress interface between domains according to the issued Path information.

Disclosure of Invention

The inventor thinks that: in the related art, under the condition that a target routing prefix which can be reached by a designated egress interface is dynamically changed, the SDN controller still performs traffic scheduling according to path information which is sent to an ingress node and reaches the target routing prefix, and the path information cannot be updated in time, so that a black hole in a route is easily caused, and bandwidth resources are wasted.

In view of the above technical problems, the present disclosure provides a solution, which avoids a black hole in a route, reduces the waste of bandwidth resources, and improves the utilization rate of the bandwidth resources.

According to a first aspect of the present disclosure, there is provided a traffic scheduling method for use between a first routing device and a second routing device, wherein the first routing device is located in a first autonomous domain system, the second routing device is located in a second autonomous domain system, the traffic scheduling method is performed by a software defined network, SDN, controller, and the traffic scheduling method includes: receiving a route calculation request of the second routing device, wherein the route calculation request comprises a first route prefix list of the first routing device, and the first route prefix list comprises at least one route prefix which is reachable by the first routing device and has the same route calculation constraint condition; determining at least one path reaching the at least one routing prefix and a path identifier corresponding to the at least one path according to the routing request; sending the at least one routing prefix, the path identification, and the at least one path to the second routing device, the at least one routing prefix being stored in a second routing prefix list of the second routing device; receiving prefix change information of the first routing prefix list; and controlling the second routing equipment to update the second routing prefix list according to the prefix change information, so that the second routing equipment performs traffic scheduling according to the updated second routing prefix list, the path identifier and the at least one path.

In some embodiments, controlling the second routing device to update the second list of routing prefixes comprises: and informing the second routing equipment to update the second routing prefix list by utilizing a path calculation unit communication protocol (PCEP) message.

In some embodiments, the prefix change information includes at least one of a reduced routing prefix and an increased routing prefix, the PCEP message includes a message type field that instructs the second routing device to update the second list of routing prefixes, a prefix field that carries a reduced routing prefix or an increased routing prefix, and a control field that instructs the second routing device to delete the reduced routing prefix from the second list of routing prefixes or instructs the second routing device to add the increased routing prefix in the second list of routing prefixes.

In some embodiments, in a case where the reduced routing prefix or the increased routing prefix exceeds a maximum prefix length that can be carried by the PCEP message, the PCEP messages carrying the reduced routing prefix or the increased routing prefix are plural, the plural PCEP messages further include a tag field, the tag field of a last PCEP message of the plural PCEP messages is a first value, and the tag fields of PCEP messages other than the last PCEP message are second values.

In some embodiments, the second autonomous system further includes a plurality of inter-domain border routing devices in an EBGP neighboring relationship with the first routing device, each inter-domain border routing device has an inter-domain label with the first routing device, each path includes an inter-domain label, and the traffic scheduling method further includes: receiving label change information of inter-domain labels of each inter-domain boundary routing device and the first routing device; and controlling the second routing equipment to update the path identifier and the at least one path in the second routing equipment according to the label change information, so that the second routing equipment performs traffic scheduling according to the second routing prefix list, the updated path identifier and the updated at least one path.

In some embodiments, controlling the second routing device to update the path identification and the at least one path in the second routing device comprises: notifying the second routing device to delete the path identity and the at least one path in the second routing device using a path computation element communication protocol, PCEP, message.

In some embodiments, the PCEP message includes a message type field instructing the second routing device to update the path identification and the at least one path in the second routing device, and a control field instructing the second routing device to delete the path identification and the at least one path in the second routing device. Controlling the second routing device to update the path identification and the at least one path in the second routing device further comprises: and after the path identifier and the at least one path are deleted, re-determining the at least one path reaching the at least one routing prefix and the path identifier corresponding to the re-determined at least one path according to the label change information.

In some embodiments, in a case where the label change information is that the inter-domain label is changed from an original value to a target value, the re-determined at least one path includes the target value.

In some embodiments, in a case that the label change information is to delete the inter-domain label, the re-determined at least one path includes an IP address of the second routing device and an IP address of the first routing device.

In some embodiments, the prefix change information is carried by a BGP monitor protocol BMP message, and the label change information is carried by a BGP LS message.

According to a second aspect of the present disclosure, there is provided a software-defined network SDN controller, wherein the SDN controller is configured to perform traffic scheduling between a first routing device and a second routing device, the first routing device being located at a first autonomous domain system, the second routing device being located at a second autonomous domain system, the SDN controller comprising: a first receiving module configured to receive a route calculation request of the second routing device, where the route calculation request includes a first route prefix list of the first routing device, and the first route prefix list includes at least one route prefix, which is reachable by the first routing device and has the same route calculation constraint condition; a determining module configured to determine, according to the route calculation request, at least one path to the at least one routing prefix and a path identifier corresponding to the at least one path; a sending module configured to send the at least one routing prefix, the path identification, and the at least one path to the second routing device, the at least one routing prefix being stored in a second routing prefix list of the second routing device; a second receiving module configured to receive prefix change information of the first routing prefix list; and the control module is configured to control the second routing device to update the second routing prefix list according to the prefix change information, so that the second routing device performs traffic scheduling according to the updated second routing prefix list, the path identifier and the at least one path.

According to a third aspect of the present disclosure, there is provided a software-defined network SDN controller, including: a memory; and a processor coupled to the memory, the processor configured to perform the traffic scheduling method of any of the above embodiments based on instructions stored in the memory.

According to a fourth aspect of the present disclosure, there is provided a traffic scheduling system, comprising: an SDN controller configured to perform the method of any of claims 1 to 11 for traffic scheduling between a first routing device located at a first autonomous domain system and a second routing device located at a second autonomous domain system.

In some embodiments, the traffic scheduling system further comprises: a first autonomous domain system comprising the first routing device; and a second autonomous domain system comprising said second routing device.

In some embodiments, the second autonomous domain system further comprises: a plurality of inter-domain border routing devices in an external border gateway protocol, EBGP, neighbor relationship with the first routing device, each inter-domain border routing device having an inter-domain label with the first routing device, each inter-domain label included in each path for traffic scheduling.

According to a fifth aspect of the present disclosure, there is provided a computer-storable medium having stored thereon computer program instructions which, when executed by a processor, implement the traffic scheduling method of any of the above embodiments.

In the embodiment, the route black hole is avoided, the waste of bandwidth resources is reduced, and the utilization rate of the bandwidth resources is improved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description, serve to explain the principles of the disclosure.

The present disclosure may be more clearly understood from the following detailed description, taken with reference to the accompanying drawings, in which:

fig. 1 is a flow chart illustrating a traffic scheduling method according to some embodiments of the present disclosure;

fig. 2 is a schematic structural diagram illustrating a traffic scheduling system according to some embodiments of the present disclosure;

figure 3 is a schematic diagram illustrating the structure of a PCEP message, in accordance with some embodiments of the present disclosure;

FIG. 4 is a flow chart illustrating a method of traffic scheduling according to further embodiments of the present disclosure;

FIG. 5 is a flow diagram illustrating controlling a second routing device to update route identifications and at least one path in the second routing device according to some embodiments of the present disclosure;

figure 6 is a block diagram illustrating an SDN controller according to some embodiments of the present disclosure;

figure 7 is a block diagram illustrating an SDN controller according to further embodiments of the present disclosure;

FIG. 8 is a block diagram illustrating a computer system for implementing some embodiments of the present disclosure.

Detailed Description

Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions, and numerical values set forth in these embodiments do not limit the scope of the present disclosure unless specifically stated otherwise.

Meanwhile, it should be understood that the sizes of the respective portions shown in the drawings are not drawn in an actual proportional relationship for the convenience of description.

The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses.

Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate.

In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

The traffic scheduling method according to some embodiments of the present disclosure will be described in detail below with reference to fig. 1 and 2.

Fig. 1 is a flow chart illustrating a traffic scheduling method according to some embodiments of the present disclosure.

Fig. 2 is a schematic diagram illustrating an architecture of a traffic scheduling system according to some embodiments of the present disclosure.

As shown in fig. 1, the traffic scheduling method includes steps S110 to S150.

In some embodiments, the traffic scheduling method used between the first routing device PE1 and the second routing device PE2 of fig. 2 is performed by an SDN controller Con in the traffic scheduling system 2. It should be understood that the SDN controller Con is configured to perform a method for traffic scheduling between the first routing device and the second routing device in any of the embodiments of the present disclosure.

For example, in fig. 2, the first routing device PE1 is located at a first autonomous domain system AS100 in the traffic scheduling system 2. The second routing device PE2 is located at a second autonomous domain system AS200 in the traffic scheduling system 2. For example, the second routing device PE2 is an ingress node, also referred to as a source node. In some embodiments, the first routing device PE1 is an egress node, also referred to as a destination node. Traffic scheduling between the first routing device PE1 and the second routing device PE2 means that traffic is scheduled from an ingress node to an egress node.

In some embodiments, second autonomous domain system AS200 of FIG. 2 further includes a plurality of interdomain border routing devices. The plurality of interdomain border routing devices include, but are not limited to, interdomain border routing device PE3 and interdomain border routing device PE 4. For example, the inter-domain border routing device is an ASBR (Autonomous System border Router).

For example, before traffic scheduling, network initialization configuration needs to be performed.

In some embodiments, an IS-IS SR (Intermediate System-to-Intermediate System Segment Routing) network IS deployed within the second autonomous domain System AS200 of fig. 2 through network initialization configuration. For example, the second routing device PE2 and the plurality of interdomain border routing devices PE3 and PE4 respectively assign the

intradomain labels

10, 20 and 30, respectively, using the IS-IS SR protocol. In some embodiments, the inter-domain Border routing device PE3, the inter-domain Border routing device PE4 and the second routing device PE2 respectively have an IBGP (Internal Border Gateway Protocol) neighbor relationship therebetween.

In some embodiments, through network initialization configuration, the inter-domain Border routing device PE3 and the inter-domain Border routing device PE4 in fig. 2 respectively have EBGP (External Border Gateway Protocol) neighbor relations with the first routing device PE 1. For example, the interdomain Border routing devices PE3 and PE4 enable BGP EPE (Border Gateway Protocol Egress peer Engineering) functionality and assign interdomain labels of interface links to the interdomain Border routing devices PE3 and PE 4. The inter-domain egress interface links may also be referred to as inter-domain egress links.

For example, the interdomain border routing device PE3, the interdomain border routing device PE4, and the first routing device PE1 have an interdomain label 1010 and an interdomain label 1020, respectively. For example, the inter-domain label is BGP EPE (Border Gateway Protocol aggregation peer Engineering) inter-domain label.

The inter-domain label identifies an outgoing interface link from each inter-domain border routing device to the first routing device. For example, the inter-domain label 1010 identifies the inter-domain border routing device PE3 with an intra-domain label of 20 to the outgoing interface link of the first routing device PE 1. The inter-domain label 1020 identifies the outgoing interface link from the inter-domain border routing device PE4 labeled 30 within the domain to the first routing device PE 1.

In some embodiments, after the network initialization configuration is completed, the first routing device PE1 in fig. 2 advertises reachable routing prefix information to each of the interdomain border routing devices PE3 and PE 4. Further, the inter-domain border routing devices PE3 and PE4 respectively advertise the route prefix information learned from the first routing device PE1 to the second routing device PE 2. Thus, the second routing device PE2 learns from the first routing device PE1 the first list of routing prefixes that includes its reachable routing prefix information. For example, the routing prefix in the first routing prefix list is a routing prefix that satisfies the information of the requirements of traffic scheduling, such as bandwidth requirements, delay requirements, and guarantee requirements.

In some embodiments, the first routing device PE1 may directly reach each routing prefix in the first list of routing prefixes or may indirectly reach each routing prefix in the first list of routing prefixes through at least one other autonomous domain system other than the first autonomous domain system and the second autonomous domain system. For example, first routing device PE1 reaches each routing prefix indirectly through a plurality of third autonomous domain systems.

For example, in fig. 2, first routing device PE1 indirectly reaches the respective routing prefix through third autonomous domain system AS301 and third autonomous domain system AS 302. In some embodiments, third autonomous domain system AS302 reaches each routing prefix directly.

In fig. 2, the ellipses indicate that there may also be at least one third autonomous domain system between third autonomous domain system AS301 and third autonomous domain system AS 302. The at least one third autonomous-domain system may have the same structure AS the third autonomous-domain system AS301 or the third autonomous-domain system AS302, or may have a structure different from both the third autonomous-domain system AS301 and the third autonomous-domain system AS 302.

In some embodiments, the first routing prefix list of the first routing device PE1 of fig. 2 includes at least one routing prefix 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24 reachable by the first routing device PE1 with the same computational route constraints. In some embodiments, the routing constraints include shortest latency, optimal Metric, forwarding traffic from designated egress nodes between domains, and so on. Metric is a Metric used by routing algorithms to determine the best path to a destination. In some embodiments, Metric is the path length. For example, the routing constraint is set by the user as needed and stored in the orchestrator.

For example, after the second routing device PE2 learns the first routing prefix list, a route calculation request is sent to the SDN controller Con according to the learned first routing prefix list. The route calculation request comprises a first route prefix list of the first routing equipment and a route calculation constraint condition corresponding to the first route prefix list.

After the network initialization configuration is completed, step S110 of fig. 1 is performed. In step S110, a route calculation request of the second routing device is received.

In step S120, at least one path to reach at least one routing prefix and a path identifier corresponding to the at least one path are determined according to the route calculation request. For example, the SDN controller Con in fig. 2 determines at least one path reaching at least one Routing prefix and a path identifier corresponding to the at least one path by comprehensively using measures of SR-TE (Segment Routing-Traffic Engineering) and BGP EPE according to a network congestion condition of each inter-domain outgoing interface link from the inter-domain boundary Routing device PE3 and the inter-domain boundary Routing device PE4 to the first Routing device PE1, which is monitored by the Routing request and the network management system. For example, at least one path is an optimal path that satisfies a computation constraint.

Those skilled in the art will appreciate that the routing prefixes of the same computational route constraint have the same path identifier, one path identifier corresponding to at least one path.

For example, routing prefix 1.0.0.0/24, routing prefix 2.0.0.0/24, and routing prefix 3.0.0.0/24 have the same path identification. In some embodiments, the path identity stored by the second routing device PE2 of fig. 2 may be an SR-TE tunnel identity between the first routing device PE1 and the second routing device PE2, and the at least one path corresponding to the path identity is a tunneled path. One tunnel identification corresponds to at least one tunnel path. For example, at least one tunnel Path constitutes LSP (Label Switching Path) information.

Some embodiments of the disclosure implement Traffic scheduling by using SR-TE tunnel technology, and compared with RSVP-TE (Resource ReSerVation Protocol-Traffic Engineering, Resource ReSerVation Protocol based on Traffic Engineering extension) and other technologies, the embodiments of the disclosure have better scalability, have the characteristics of stateless intermediate nodes and source route forwarding, and can better optimize Traffic scheduling in a network.

In some embodiments, each path includes an interdomain label with an interdomain label between each interdomain border routing device and the first routing device. For example, in the case where each routing device of the second autonomous domain system is assigned an intra-domain label, each path further includes at least one intra-domain label.

For example, the paths used for traffic scheduling between the first routing device PE1 and the second routing device PE2 in fig. 2 may be 20,1010 and 30,1020. The path {20,1010} indicates that traffic from the second routing device PE2 with label 10 in the domain controls traffic from the second routing device PE2 to reach the corresponding routing prefix via the inter-domain border routing device PE3 with label 20 in the domain and the outbound interface link with label 1010 in the domain. The path {30,1020} indicates that traffic from the second routing device PE2 with intra-domain label 10 controls traffic from the second routing device PE2 to reach the corresponding routing prefix via the inter-domain border routing device PE4 with intra-domain label 30 and the outbound interface link with inter-domain label 1020. For example, paths 10-20-1010 and 10-30-1020 each correspond to path identification 1.

In some embodiments, the SDN controller Con determines at least one path to reach the at least one routing prefix and a path identifier corresponding to the at least one path, and needs to obtain intra-domain network topology information of the second autonomous-domain system AS200 and inter-domain label information between the first autonomous-domain system AS100 and the second autonomous-domain system AS200 in advance. And then, determining at least one path reaching at least one routing prefix and a path identifier corresponding to the at least one path according to the pre-acquired intra-domain network topology information and inter-domain label information.

Intra-domain network topology information of the second autonomous-domain system AS200 and inter-domain label information between the first autonomous-domain system AS100 and the second autonomous-domain system AS200 are acquired, for example, AS follows.

In some embodiments, through network initialization configuration, the SDN controller Con of fig. 2 establishes BGP LS (Border Gateway Protocol Link State) session connections with one or more inter-domain Border routing devices PE3 and PE4, respectively. Under the condition of establishing BGP LS session connection with a plurality of inter-domain border routing devices PE3 and inter-domain border routing device PE4, the priorities of the plurality of inter-domain border routing devices PE3 and inter-domain border routing device PE4 are set, and services are provided first with high priorities. The SDN controller Con establishes BGP LS session connections with the inter-domain border routing devices PE3 and PE4, respectively, so that the problem of traffic scheduling failure due to inter-domain border routing device failure can be reduced, and the reliability of traffic scheduling is improved.

In some embodiments, upon completion of the network initialization configuration, SDN controller Con obtains intra-domain network topology information of second autonomous-domain system AS200 and inter-domain label information between first autonomous-domain system AS100 and second autonomous-domain system AS200 from inter-domain border routing device PE3 or inter-domain border routing device PE4 using BGP LS messages.

Returning to fig. 1, after determining at least one path to reach at least one routing prefix and a path identifier corresponding to the at least one path, step S130 is performed. In step S130, the at least one routing prefix, the path identification and the at least one path are sent to the second routing device. At least one routing prefix is stored in a second routing prefix list of the second routing device.

For example, at the time of network initialization configuration, a PCEP session connection is established between SDN controller Con and second routing device PE2 of fig. 2. For example, the SDN controller Con may send the routing prefix 1.0.0.0/24, the routing prefix 2.0.0.0/24, the routing prefix 3.0.0.0/24, the path identity and the at least one path to the second routing device PE2 using existing PCEP messages. The existing PCEP message is used to respond to the way calculation request and send the way calculation result. In some embodiments, the existing PCEP message includes a message type field instructing the second routing device PE2 to store at least one routing prefix, a path identification, and at least one path.

For example, the second routing device PE2 stores the at least one routing prefix as a second routing prefix list, and stores the second routing prefix list and the path identifier in the routing table to establish a correspondence between the at least one routing prefix and the path identifier. The second routing device PE2 also stores the at least one path corresponding to the path identification in a storage space, such as a database, corresponding to the path identification. For example, a path identifier is a pointer to at least one path memory space.

Returning to fig. 1, step S140 is performed after sending the at least one routing prefix, the path identifier and the at least one path to the second routing device. In step S140, prefix change information of the first routing prefix list is received. For example, the prefix change information includes at least one of a reduced route prefix and an increased route prefix. In some embodiments, the reduced routing prefix or the increased routing prefix may be one or more. For example, the prefix change information is a reduced route prefix of 3.0.0.0/24.

In some embodiments, the prefix change information is carried by a Border Gateway Protocol (BGP) BMP message.

For example, at the time of network initialization configuration, BMP session connections are established between at least one of the interdomain border routing device PE3 and the interdomain border routing device PE4 of fig. 2 and the SDN controller Con, respectively. After the inter-domain border routing device PE3 or the inter-domain border routing device PE4 monitors prefix change information of the first routing prefix list of the first routing device PE1, a BMP message carrying the prefix change information is sent to the SDN controller Con.

In some embodiments, the BMP messages comprise BMP update messages and BMP withdraw messages. The BMP update message carries an increased routing prefix and the BMP withdraw message carries a decreased routing prefix. The SDN controller Con determines, through the BMP update message and the BMP gateway message, whether the changed routing prefix belongs to a reduced routing prefix or an increased routing prefix.

Returning to fig. 1, after prefix change information of the first routing prefix list is received, step S150 is performed. In step S150, according to the prefix change information, the second routing device is controlled to update the second routing prefix list, so that the second routing device performs traffic scheduling according to the updated second routing prefix list, the path identifier, and the at least one path.

According to some embodiments of the disclosure, the second routing prefix list is updated in time according to the prefix change information, so that the second routing device performs traffic scheduling according to the updated second routing prefix list, the path identifier and at least one path, thereby effectively avoiding a black hole in a route caused by that the routing information for traffic scheduling of the ingress node is not updated in time due to the change of the routing prefix information reachable by the egress node, reducing the waste of bandwidth resources, and improving the utilization rate of the bandwidth resources. For example, the routing information related to traffic scheduling is original tunnel path information.

For example, the second routing device is notified to update the second list of routing prefixes using a PCEP message. The PCEP message herein is a newly defined PCEP message, unlike an existing PCEP message.

The structure of the PCEP message newly defined by the present disclosure will be described in detail below with reference to fig. 3.

Figure 3 is a schematic diagram illustrating the structure of a PCEP message, according to some embodiments of the present disclosure.

As shown in fig. 3, the PCEP message includes three rows, each row having 32 bits. For example, the 32 bits of each row are 4 8 bits, each 8 bits being identified by a 0-7 number in FIG. 3. In some embodiments, the PCEP message includes a message Type field Type, a prefix field prefix, and a control field AD.

The message type field instructs the second routing device to update the second list of routing prefixes. For example, the message Type field Type is 8 bits, and the value of Type is 37. For example, after receiving a PCEP message from the SDN controller, the second routing device determines whether to update the second routing prefix list according to a value of the message type field.

The prefix field carries either a reduced routing prefix or an increased routing prefix. In some embodiments, the prefix field Prefix is 32 bits. For example, in the case where the prefix change information is that the reduced routing prefix is 3.0.0.0/24, the prefix field carries the reduced routing prefix of 3.0.0.0/24.

The control field instructs the second routing device to delete a reduced routing prefix from the second routing prefix list or to add an increased routing prefix in the second routing prefix list.

For example, the control field AD is 2 bits. In some embodiments, in case the value of the control field AD is 01, the second routing device is instructed to add an added routing prefix in the second routing prefix list. And in case the value of the control field AD is 10, instructing the second routing device to delete the reduced routing prefix from the second routing prefix list. And in the case that the value of the control field AD is 00, indicating the second routing equipment not to perform any updating operation. For example, when the prefix change information is that the reduced route prefix is 3.0.0.0/24, the value of the control field AD is 10.

For example, after determining that the PCEP message from the SDN controller is used to update the second routing prefix list, the second routing device determines whether a subsequent operation is to delete a routing prefix or add a routing prefix according to a value of a control field of the PCEP message. And after determining the subsequent operation, the second routing equipment acquires the reduced routing prefix or the increased routing prefix from the prefix field of the PCEP message, and updates the second routing prefix list by using the acquired routing prefix.

In some embodiments, PCEP messages carrying a reduced routing prefix or an increased routing prefix are plural in the event that the reduced routing prefix or the increased routing prefix exceeds the maximum prefix length that the PCEP message can carry. The plurality of PCEP messages further includes a tag field, the tag field of a last PCEP message of the plurality of PCEP messages being a first value, and the tag fields of PCEP messages other than the last PCEP message being a second value.

For example, the PCEP message in fig. 3 also includes a tag field T, which is 1 bit. The value of the tag field T is a first value or a second value. In some embodiments, the first value is 1 and the second value is 0.

For example, after receiving multiple PCEP messages from the SDN controller, the second routing device determines whether a routing prefix carried in a prefix field of a current PCEP message is complete according to a value of the tag field T. And judging whether the routing prefix carried by the prefix field of the current PCEP message is complete, namely judging whether the reduced routing prefix or the increased routing prefix exceeds the preset maximum message length of each IP message.

And under the condition that the value of the mark field T of the current PCEP message is the first value, the routing prefix carried by the prefix field of the current PCEP message is complete. And the second routing equipment directly updates the second routing prefix list according to the current PCEP message. And under the condition that the value of the mark field T of the current PCEP message is a second value, the routing prefix carried by the prefix field of the current PCEP message is not complete. The second routing equipment caches the current PCEP message and sequentially receives subsequent PCEP messages until the value of the mark field of the PCEP message is the first value, and the second routing equipment updates the second routing prefix list according to the cached PCEP messages. For example, the first value is 1 and the second value is 0.

In some embodiments, the PCEP message also includes the path identification field PLSP-ID shown in fig. 3. The path identification field PLSP-ID is, for example, 20 bits.

For example, when the prefix information of the second route prefix list changes, the value of the path identity field PLSP-ID is a path identity corresponding to a decreased route prefix or an increased route prefix. And under the condition that the prefix information of the second routing prefix list is not changed, the value of the path identification field PLSP-ID is the path identification corresponding to the second routing prefix list. The path identification field PLSP-ID better reflects the correspondence between the dynamic change of the prefix and the path identification and the path.

In some embodiments, the SDN controller determines the value of the path identity field PLSP-ID by using the path identity of the route prefix with the same routing constraint as the routing constraint of the reduced route prefix or the increased route prefix.

For example, in a case where the second routing device includes a plurality of second routing prefix lists and the path identifications corresponding to the second routing prefix lists are different, the second routing device determines, according to a path identification field PLSP-ID of a PCEP message from the SDN controller, the second routing prefix list that needs to be updated.

In some embodiments, the PCEP message also includes a flag bit field Flags and 4 undefined fields U. The 4 undefined fields can be used to define the content it carries by itself. Flags are defined as the existing PCEP messages and are not described herein.

It should be understood that the structure of the PCEP message shown in fig. 3 is merely illustrative. Those skilled in the art can make appropriate settings as desired.

The traffic scheduling method according to other embodiments of the present disclosure will be described in detail below with reference to fig. 2, 3, and 4.

Fig. 4 is a flow chart illustrating a method of traffic scheduling according to further embodiments of the present disclosure. Fig. 4 is different from fig. 1 in that fig. 4 shows other steps S160 to S170 of the traffic scheduling method according to other embodiments. Only the differences between fig. 4 and fig. 1 will be described below, and the same parts will not be described again.

As shown in fig. 4, the traffic scheduling method further includes steps S160 to S170, in addition to steps S110 to S150 which are the same as those in fig. 1. The sequence of steps S160 to S170 and steps S140 to S150 in fig. 4 is only schematic, and actually, steps S140 to S150 and steps S160 to S170 executed by the SDN controller do not affect each other.

In step S160, label change information of the inter-domain label of each inter-domain border routing device and the first routing device is received. For example, the tag change information is carried by BGP LS messages.

For example, BGP LS session connections have been established between interdomain border routing device PE3, interdomain border routing device PE4, and SDN controller Con of fig. 2 at network initialization configuration. After monitoring that the plurality of inter-domain border routing devices PE3 and PE4 reach the label change information of the inter-domain label of the outgoing interface link of the first routing device PE1, the plurality of inter-domain border routing devices PE3 and PE4 send a BGP LS message carrying the label change information to the SDN controller Con.

It should be understood by those skilled in the art that the inter-domain label information obtained through BGP LS is initialized inter-domain label information when the network initializes configuration. After the network initialization configuration is completed, in the process of flow scheduling, the inter-domain border routing equipment monitors the change condition of the inter-domain label in real time and sends a BGP LS message carrying label change information to the SDN controller.

Returning to fig. 4, after receiving the label change information of the inter-domain label of each inter-domain border routing device and the first routing device, step S170 is performed. In step S170, according to the label change information, the second routing device is controlled to update the path identifier and the at least one path in the second routing device, so that the second routing device performs traffic scheduling according to the second routing prefix list, the updated path identifier, and the updated at least one path.

According to some embodiments of the present disclosure, the second routing device is controlled to update the path identifier and the at least one path in the second routing device in time according to the tag change information, so that the second routing device performs traffic scheduling according to the second routing prefix list, the updated path identifier and the updated at least one path, thereby effectively avoiding a black hole in a route caused by that the routing information for traffic scheduling of the ingress node is not updated in time due to the change of the tag information reaching the egress node, reducing the waste of bandwidth resources, and improving the utilization rate of the bandwidth resources

Step S170 is implemented, for example, in the manner as shown in fig. 5.

Fig. 5 is a flow diagram illustrating controlling a second routing device to update route identifications and at least one path in the second routing device according to some embodiments of the present disclosure.

As shown in fig. 5, controlling the second routing device to update the route identification and the at least one path in the second routing device comprises step S171. In step S171, the second routing device is notified to delete the path identity and the at least one path in the second routing device using a PCEP message. Some embodiments of the present disclosure improve the efficiency of traffic scheduling by directly clearing the path identifier and the at least one path corresponding to the second route prefix list in the second routing device.

The PCEP message newly defined by the present disclosure will be described in detail below with reference to fig. 3.

As shown in fig. 3, the message Type field Type of the PCEP message also indicates that the second routing device refines the path identification and the at least one path in the second routing device. The value of the control field AD also includes 11. And under the condition that the value of the control field AD is 11, the control field instructs the second routing equipment to delete the path identifier and at least one path in the second routing equipment.

It will be appreciated by those skilled in the art that the message type field and the control field together determine whether the update operation of the second routing device is to update the routing prefix information or to update the path identification and the at least one path.

For example, in case of a change in inter-domain labels, the path identity field PLSP-ID takes the value of a path identity corresponding to at least one path comprising the changed inter-domain labels. The value of the path identity field PLSP-ID is a path identity corresponding to at least one path comprising inter-domain labels between the plurality of inter-domain border routing devices and the first routing device, in case that no inter-domain labels change.

For example, the SDN controller determines, from the changed inter-domain label, at least one path including the inter-domain label. Further, the SDN controller determines a path identification corresponding to the at least one path. Thereby, the SDN controller determines the value of the path identity field PLSP-ID.

In some embodiments, the first autonomous domain system comprises a plurality of first routing devices. The first routing device and the inter-domain border routing device have a unique inter-domain label between each two. And under the condition that a plurality of inter-domain labels corresponding to different path identifications are changed, controlling the second routing equipment to update the path identifications and at least one path in the second routing equipment by using a plurality of PCEP messages. Those skilled in the art should understand that different inter-domain labels may correspond to different path ids, and may also correspond to the same path id. Under the condition that different labels correspond to different path identifications, a plurality of second routing prefix lists and a plurality of path identifications are stored in the second routing equipment, and the second routing prefix lists correspond to the path identifications.

For example, in a case where the second routing device includes a plurality of second routing prefix lists and the path identifications corresponding to the second routing prefix lists are different, the second routing device determines a path identification and at least one path that need to be updated according to a path identification field PLSP-ID of a PCEP message from the SDN controller.

In some embodiments, in the case that the PCEP message is used to notify the second routing device to delete the path identifier and the at least one path in the second routing device, the value of the tag field T of the PCEP message is the first value. For example, in this case, the prefix field of the PCEP message does not carry any routing prefix information.

For example, controlling the second routing device to update the route identification and the at least one path in the second routing device further comprises step S172. In some embodiments, step S172 is performed after deleting the path identifier and the at least one path.

In step S172, at least one path to reach the at least one routing prefix and a path identifier corresponding to the at least one path are re-determined according to the label change information. In some embodiments, the SDN controller re-determines, according to the changed inter-domain label information and intra-domain network topology information of the second autonomous domain system, at least one path to reach the at least one routing prefix and a path identifier corresponding to the re-determined at least one path.

For example, in a case where the tag change information is that the inter-domain tag is changed from the original value to the target value, the re-determined at least one path includes the target value.

For example, in a case where the label change information is to delete an inter-domain label, the re-determined at least one path includes an IP address of the second routing device and an IP address of the first routing device. In this case, since the inter-domain label is deleted, forwarding can be performed according to the optimal principle of the conventional routing protocol.

In some embodiments, the traffic scheduling system 2 of fig. 2 may comprise a plurality of first autonomous domain systems. For example, the other first autonomous domain systems in fig. 2 other than first autonomous domain system AS100 include, but are not limited to, first autonomous domain system AS 400.

In some embodiments, the first autonomous domain system may further comprise a plurality of first routing devices. For example, in fig. 2, the first autonomous domain system AS100 includes a first routing device, such AS the first routing device PE5, in addition to the first routing device PE 1. The first autonomous domain system AS400 comprises first routing devices PE6, PE7 and the like. The first routing device PE5, the first routing device PE6, and the first routing device PE7 may respectively establish interface links with the inter-domain border routing device PE3 and the inter-domain border routing device PE4, and allocate inter-domain labels. The allocation of inter-domain labels is similar to the allocation of

inter-domain labels

1010 and 1020 and will not be described further herein.

For example, the first routing device PE5, the first routing device PE6, and the first routing device PE7 may each reach respective routing prefixes directly or indirectly through a plurality of third autonomous domain systems. The traffic scheduling method of the present disclosure may also be applied to traffic scheduling between the second routing device PE2 and the first routing device PE5, the first routing device PE6, or the first routing device PE 7.

Figure 6 is a block diagram illustrating an SDN controller according to some embodiments of the present disclosure.

For example, the SDN controller is configured to perform traffic scheduling between the first routing device PE1 and the second routing device PE2 of fig. 2. The first routing device PE1 is located at a first autonomous domain system AS 100. The second routing device PE2 is located at a second autonomous domain system AS 200.

As shown in fig. 6, the SDN controller 60 includes a first receiving module 601, a determining module 602, a sending module 603, a second receiving module 604, and a control module 605. For example, the SDN controller 60 is the same or similar in structure and function as the SDN controller Con in fig. 2.

The first receiving module 601 is configured to receive a route calculation request of the second routing device, for example, execute step S110 shown in fig. 1. The route calculation request includes a first list of routing prefixes for the first routing device. The first routing prefix list includes at least one routing prefix reachable by the first routing device with the same computational route constraints.

The determining module 602 is configured to determine at least one path to reach at least one routing prefix and a path identifier corresponding to the at least one path according to the routing request, for example, perform step S120 shown in fig. 1.

The sending module 603 is configured to send the at least one routing prefix, the path identification and the at least one path to the second routing device, for example to perform step S130 as shown in fig. 1. At least one routing prefix is stored in a second routing prefix list of the second routing device.

The second receiving module 604 is configured to receive prefix change information of the first routing prefix list, for example, execute step S140 shown in fig. 1.

The control module 605 is configured to control the second routing device to update the second routing prefix list according to the prefix change information, so that the second routing device performs traffic scheduling according to the updated second routing prefix list, the path identifier and the at least one path, for example, perform step S150 shown in fig. 1.

Figure 7 is a block diagram illustrating an SDN controller according to further embodiments of the present disclosure.

As shown in fig. 7, the SDN controller device 70 includes a memory 701; and a processor 702 coupled to the memory 701. The memory 701 is configured to store instructions for executing corresponding embodiments of the SDN controller method. The processor 702 is configured to execute SDN controller methods in any of the embodiments of the present disclosure based on instructions stored in the memory 701.

As shown in FIG. 8, computer system 80 may take the form of a general purpose computing device. Computer system 80 includes a memory 810, a processor 820, and a bus 800 that connects the various system components.

The memory 810 may include, for example, system memory, non-volatile storage media, and the like. The system memory stores, for example, an operating system, an application program, a Boot Loader (Boot Loader), and other programs. The system memory may include volatile storage media such as Random Access Memory (RAM) and/or cache memory. The non-volatile storage medium stores, for instance, instructions to perform corresponding embodiments of at least one of the traffic scheduling methods. Non-volatile storage media include, but are not limited to, magnetic disk storage, optical storage, flash memory, and the like.

The processor 820 may be implemented as discrete hardware components, such as a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gates or transistors, or the like. Accordingly, each of the modules, such as the judging module and the determining module, may be implemented by a Central Processing Unit (CPU) executing instructions in a memory for performing the corresponding step, or may be implemented by a dedicated circuit for performing the corresponding step.

The bus 800 may use any of a variety of bus architectures. For example, bus structures include, but are not limited to, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, and Peripheral Component Interconnect (PCI) bus.

The computer system 80 may also include an input-output interface 830, a network interface 840, a storage interface 850, and the like. These

interfaces

830, 840, 850 and the memory 810 and the processor 820 may be connected by a bus 800. The input/output interface 830 may provide a connection interface for input/output devices such as a display, a mouse, and a keyboard. The network interface 840 provides a connection interface for various networking devices. The storage interface 850 provides a connection interface for external storage devices such as a floppy disk, a usb disk, and an SD card.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable apparatus to produce a machine, such that the execution of the instructions by the processor results in an apparatus that implements the functions specified in the flowchart and/or block diagram block or blocks.

These computer-readable program instructions may also be stored in a computer-readable memory that can direct a computer to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart and/or block diagram block or blocks.

The present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects.

By the traffic scheduling method and system, the SDN controller and the computer storage medium in the embodiment, the routing black hole is avoided, the bandwidth resource waste is reduced, and the bandwidth resource utilization rate is improved.

Thus far, traffic scheduling methods and systems, SDN controllers, computer-storable media according to the present disclosure have been described in detail. Some details that are well known in the art have not been described in order to avoid obscuring the concepts of the present disclosure. It will be fully apparent to those skilled in the art from the foregoing description how to practice the presently disclosed embodiments.

Claims

1. A traffic scheduling method used between a first routing device and a second routing device, wherein the first routing device is located in a first autonomous domain system, the second routing device is located in a second autonomous domain system, and the traffic scheduling method is executed by a Software Defined Network (SDN) controller, and the traffic scheduling method comprises the following steps:

receiving a route calculation request of the second routing device, wherein the route calculation request comprises a first route prefix list of the first routing device, and the first route prefix list comprises at least one route prefix which is reachable by the first routing device and has the same route calculation constraint condition;

determining at least one path reaching the at least one routing prefix and a path identifier corresponding to the at least one path according to the routing request;

sending the at least one routing prefix, the path identification, and the at least one path to the second routing device, the at least one routing prefix being stored in a second routing prefix list of the second routing device;

receiving prefix change information of the first routing prefix list;

and controlling the second routing equipment to update the second routing prefix list according to the prefix change information, so that the second routing equipment performs traffic scheduling according to the updated second routing prefix list, the path identifier and the at least one path.

2. The traffic scheduling method according to claim 1, wherein controlling the second routing device to update the second list of routing prefixes comprises:

and informing the second routing equipment to update the second routing prefix list by utilizing a path calculation unit communication protocol (PCEP) message.

3. The traffic scheduling method according to claim 2, wherein the prefix change information includes at least one of a reduced routing prefix and an increased routing prefix, the PCEP message includes a message type field, a prefix field, and a control field, the message type field instructs the second routing device to update the second routing prefix list, the prefix field carries a reduced routing prefix or an increased routing prefix, and the control field instructs the second routing device to delete the reduced routing prefix from the second routing prefix list or instruct the second routing device to add the increased routing prefix in the second routing prefix list.

4. The traffic scheduling method according to claim 3, wherein, in case that the reduced routing prefix or the increased routing prefix exceeds the maximum prefix length that can be carried by the PCEP message, there are a plurality of PCEP messages carrying the reduced routing prefix or the increased routing prefix, and the plurality of PCEP messages further include a tag field, the tag field of the last PCEP message in the plurality of PCEP messages is a first value, and the tag fields of other PCEP messages except the last PCEP message are second values.

5. The traffic scheduling method according to claim 1, wherein the second autonomous system further includes a plurality of inter-domain border routing devices in an EBGP neighbor relationship with the first routing device, each inter-domain border routing device having an inter-domain label with the first routing device, each path including an inter-domain label, the traffic scheduling method further comprising:

receiving label change information of inter-domain labels of each inter-domain boundary routing device and the first routing device;

and controlling the second routing equipment to update the path identifier and the at least one path in the second routing equipment according to the label change information, so that the second routing equipment performs traffic scheduling according to the second routing prefix list, the updated path identifier and the updated at least one path.

6. The traffic scheduling method according to claim 5, wherein controlling the second routing device to update the path identity and the at least one path in the second routing device comprises:

notifying the second routing device to delete the path identity and the at least one path in the second routing device using a path computation element communication protocol, PCEP, message.

7. The traffic scheduling method according to claim 6, wherein the PCEP message comprises a message type field instructing the second routing device to update the path identity and the at least one path in the second routing device and a control field instructing the second routing device to delete the path identity and the at least one path in the second routing device.

8. The traffic scheduling method according to claim 6, wherein controlling the second routing device to update the path identity and the at least one path in the second routing device further comprises:

and after the path identifier and the at least one path are deleted, re-determining the at least one path reaching the at least one routing prefix and the path identifier corresponding to the re-determined at least one path according to the label change information.

9. The traffic scheduling method according to claim 8, wherein in case that the label change information is that the inter-domain label is changed from an original value to a target value, the re-determined at least one path includes the target value.

10. The traffic scheduling method according to claim 8, wherein, in a case where the label change information is to delete the inter-domain label, the re-determined at least one path includes an IP address of the second routing device and an IP address of the first routing device.

11. The traffic scheduling method according to claim 5, wherein the prefix change information is carried by a Border Gateway Protocol (BGP) monitoring protocol (BMP) message, and the label change information is carried by a Border Gateway Protocol (BGP) connection status (LS) message.

12. A software defined network, SDN, controller configured to schedule traffic between a first routing device located at a first autonomous domain system and a second routing device located at a second autonomous domain system, the SDN controller comprising:

a first receiving module configured to receive a route calculation request of the second routing device, where the route calculation request includes a first route prefix list of the first routing device, and the first route prefix list includes at least one route prefix, which is reachable by the first routing device and has the same route calculation constraint condition;

a determining module configured to determine, according to the route calculation request, at least one path to the at least one routing prefix and a path identifier corresponding to the at least one path;

a sending module configured to send the at least one routing prefix, the path identification, and the at least one path to the second routing device, the at least one routing prefix being stored in a second routing prefix list of the second routing device;

a second receiving module configured to receive prefix change information of the first routing prefix list;

and the control module is configured to control the second routing device to update the second routing prefix list according to the prefix change information, so that the second routing device performs traffic scheduling according to the updated second routing prefix list, the path identifier and the at least one path.

13. A software defined network, SDN, controller comprising:

a memory; and

a processor coupled to the memory, the processor configured to perform the traffic scheduling method of any of claims 1 to 11 based on instructions stored in the memory.

14. A traffic scheduling system, comprising:

an SDN controller configured to perform the method of any of claims 1 to 11 for traffic scheduling between a first routing device located at a first autonomous domain system and a second routing device located at a second autonomous domain system.

15. The traffic scheduling system of claim 14, further comprising:

a first autonomous domain system comprising the first routing device; and

and the second autonomous domain system comprises the second routing equipment.

16. The traffic scheduling system of claim 15, wherein the second autonomous domain system further comprises:

a plurality of inter-domain border routing devices in an external border gateway protocol, EBGP, neighbor relationship with the first routing device, each inter-domain border routing device having an inter-domain label with the first routing device, each inter-domain label included in each path for traffic scheduling.

17. A computer-storable medium having stored thereon computer program instructions which, when executed by a processor, implement the traffic scheduling method according to any one of claims 1 to 11.