CN114598636A

CN114598636A - Traffic scheduling method, equipment and system

Info

Publication number: CN114598636A
Application number: CN202011308362.9A
Authority: CN
Inventors: 王九明
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-11-19
Filing date: 2020-11-19
Publication date: 2022-06-07

Abstract

The application provides a traffic scheduling method, equipment and a system, and belongs to the technical field of communication. In the solution provided by the present application, the network device may determine, based on a link requirement of a target service flow, a target physical port whose link performance matches the link requirement from a link aggregation interface, and forward the target service flow through the target physical port. Therefore, the link performance of the member link (namely, the network link corresponding to the target physical port) for forwarding the target service flow can be ensured to meet the link requirement of the target service flow, the accurate scheduling of the service flow is realized, and the reliability of flow scheduling is effectively improved.

Description

Traffic scheduling method, equipment and system

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, a device, and a system for traffic scheduling.

Background

A Link Aggregation Group (LAG) refers to a logical link formed by binding several member links together. The LAG may also be referred to as a logical interface, a link aggregation interface, or a multi-port load balancing group (load sharing group), each member link in the LAG may also be referred to as a member port, and each member port is a physical port of the network device.

In detecting the link performance of the LAG, the link performance of one member link in the LAG is typically used to represent the link performance of the entire LAG. This results in a large error in the determined link performance of the LAG, and a low reliability in scheduling the traffic flow based on the link performance of the LAG.

Disclosure of Invention

The application provides a traffic scheduling method, equipment and a system, which can solve the technical problem of low reliability when a link performance based on LAG schedules a service flow.

On one hand, the utility model provides a flow scheduling method, which is applied to network equipment, wherein the target physical port of the network equipment is a member port of a link aggregation interface; the method comprises the following steps: determining that the link requirement of the target service flow is matched with the link performance of the target physical port, and forwarding the target service flow through the target physical port; wherein, the outgoing interface of the target service flow is the link aggregation interface.

The scheme provided by the application can ensure that the link performance of the member link (namely, the network link corresponding to the target physical port) for forwarding the target service flow can meet the link requirement of the target service flow, thereby realizing the accurate scheduling of the service flow and effectively improving the reliability of flow scheduling.

Optionally, the process of the network device determining that the link requirement of the target traffic flow matches the link performance of the target physical port may include: and determining the link requirement of the target service flow based on the link requirement identification corresponding to the target service flow.

The link requirement identifier may be a numerical identifier of a flexible algorithm, or may be a quality of service (QoS) identifier, or may also be a color (color) identifier in a segment routing policy (SR policy).

Optionally, the process of determining, by the network device, the target routing algorithm corresponding to the target service flow based on the link requirement identifier corresponding to the target service flow may include: acquiring the link demand identification from a target message, wherein the target message belongs to the target service flow; or, obtaining the link requirement identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link requirement identifier.

The link requirement identifier carried in the target packet may be added by the device that forwards the target packet. The corresponding relationship is configured in the network device by the operation and maintenance personnel, or can be issued by the controller. The network device can obtain the link requirement identification in different modes, so that the flexibility of determining the link requirement of the target service flow is effectively improved.

Optionally, for a scenario where the link requirement is identified as a numerical identifier of a flexible algorithm, the method may further include: a network topology for forwarding the target traffic flow is determined based on the numeric identifier, the network topology including network links to which the target physical ports are connected.

In a scenario where a physical port of a network device is a member port of a link aggregation interface, the network device may determine, based on the numerical identifier of the flexible algorithm, not only a target physical port for forwarding the target traffic flow (i.e., determine a member link in the LAG for carrying the target traffic flow), but also determine, based on the numerical identifier of the flexible algorithm, a network topology for forwarding the target traffic flow, i.e., calculate an end-to-end path. Therefore, not only can the accurate scheduling of the target service flow be realized, but also the identification behavior of the network equipment to the numerical identifier of the flexible algorithm does not need to be changed, and the method and the system can be effectively compatible with the existing network technology.

Optionally, the Identification (ID) of the service flow recorded in the correspondence relationship may include: an identifier of a Virtual Private Network (VPN) instance for carrying the service flow, or an identifier of a Virtual Circuit (VC) for carrying the service flow.

For different scenes, the network equipment can adopt different identifiers to distinguish different service flows, thereby effectively improving the reliability and flexibility when distinguishing different service flows.

Optionally, after the network device obtains the link requirement identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link requirement identifier, the process of forwarding the target service flow through the target physical port may include: adding the link requirement identification in the message of the target service flow; and forwarding the target service flow through the target physical port.

By adding the link requirement identifier to the message, other network devices which subsequently receive the message can determine the link requirement of the target service flow directly based on the link requirement identifier.

Optionally, the process of forwarding, by the network device, the target traffic flow through the target physical port may include: and adding the port identification of the target physical port in the message of the target service flow, and forwarding the target service flow through the target physical port.

The port identifier may be a Media Access Control (MAC) address of the target physical port, or may be a port index (interface index) of the target physical port. By adding the port identifier of the target physical port in the message, the network device receiving the message can determine the port information of the physical port sending the message conveniently.

Optionally, before determining that the link requirement of the target traffic flow matches the link performance of the target physical port, the method may further include: and detecting the network link corresponding to the target physical port to obtain the link performance of the target physical port.

The network device may detect the network link corresponding to the target physical port based on the following detection protocol: two-way active measurement protocol (TWAMP), one-way active measurement protocol (OWAMP), simple two-way active measurement protocol (STAMP), Network Quality Analysis (NQA) protocol, or Ethernet service activation testing method (Ethernet service activation testing method) such as y.1564, and the like.

Optionally, the link requirement of the target traffic flow may include a requirement for at least one of the following performance parameters: delay, packet loss rate, and jitter.

Optionally, the multiple candidate physical ports of the network device are all member ports of the link aggregation interface, and the target physical port is included in the multiple candidate physical ports.

Correspondingly, the network device may detect the link performance of the network link corresponding to each candidate physical port, and may determine the target physical port from the multiple candidate physical ports based on the detected link performance of each candidate physical port.

In another aspect, a network device is provided, which may include at least one module, and the at least one module may be configured to implement the traffic scheduling method provided in the foregoing aspect.

In yet another aspect, a network device is provided, which may include: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the traffic scheduling method as provided in the above aspect when executing the computer program.

In yet another aspect, a computer-readable storage medium is provided, in which instructions are stored, the instructions being executed by a processor to implement the traffic scheduling method provided in the above aspect.

In yet another aspect, a computer program product containing instructions is provided, which when run on a computer causes the computer to perform the traffic scheduling method as provided in the above aspect.

In still another aspect, a traffic scheduling system is provided, which may include: a terminal device, and a network device as provided in the above aspect connected to the terminal device; wherein the network device may be configured to forward the traffic flow from the terminal device.

To sum up, the present application provides a traffic scheduling method, device, and system, where a network device may determine a target physical port whose link performance matches a link demand from a link aggregation interface based on the link demand of a target service flow, and forward the target service flow through the target physical port. Therefore, the link performance of the member link (namely, the network link corresponding to the target physical port) for forwarding the target service flow can be ensured to meet the link requirement of the target service flow, the accurate scheduling of the service flow is realized, and the reliability of flow scheduling is effectively improved.

Drawings

Fig. 1 is a schematic structural diagram of a traffic scheduling system according to an embodiment of the present application;

fig. 2 is a flowchart of a traffic scheduling method according to an embodiment of the present application;

fig. 3 is a flowchart of another traffic scheduling method provided in an embodiment of the present application;

fig. 4 is a schematic structural diagram of another traffic scheduling system provided in an embodiment of the present application;

fig. 5 is a schematic diagram of a forwarding path of a packet according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of another traffic scheduling system provided in an embodiment of the present application;

fig. 7 is a schematic structural diagram of a packet forwarded by a forwarding plane of each device according to an embodiment of the present application;

fig. 8 is a schematic diagram of a TWAMP detection procedure provided in an embodiment of the present application;

fig. 9 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of another network device according to an embodiment of the present application.

Detailed Description

The following describes a method, a device, and a system for traffic scheduling according to an embodiment of the present application in detail with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of a traffic scheduling system according to an embodiment of the present application, and as shown in fig. 1, the system at least includes: two network devices 01, and a terminal device 02 connected to one of the network devices 01. The link between the two network devices 01 may be a LAG formed by bundling several member links, and the network device 01 connected to the terminal device 02 may forward the traffic flow from the terminal device 02 through the LAG. For example, referring to fig. 1, the LAG between the two network devices 01 includes three member links, and the three member links may forward the traffic flow from the terminal device 02 in a load sharing manner. Alternatively, the LAG may be formed based on a Link Aggregation Control Protocol (LACP), or may be formed by manual configuration by an operation and maintenance person. If all the member links in the LAG are Ethernet links, the LAG may also be referred to as an Ethernet link aggregation group (Ethernet Trunk, Eth-Trunk).

Wherein, each member link can also be called a member port; or may be understood as: each member link corresponds to a physical port in network device 01, which may be referred to as a member port. Alternatively, a plurality of member ports included in the LAG may belong to the same network device 01. Alternatively, a plurality of member ports included in the LAG may belong to different network devices 01, that is, the LAG may be formed by aggregating physical ports of different network devices 01, and the LAG formed in a cross-device manner may also be referred to as an enhanced link aggregation group (E-Trunk). The E-Trunk can realize link aggregation among a plurality of network devices and can improve the link reliability from a single board level to a device level.

The LAG can effectively improve the link bandwidth by binding a plurality of member links. And, as long as there is a member port in an active state (up) among a plurality of member ports included in the LAG, the state of the LAG may be maintained in the up state. That is, even if the state of some member ports is inactive (down), the state of the LAG is not switched to down, so that it is possible to prevent frequent switching of traffic flows due to switching of the port state to down. Moreover, when interface configuration is carried out, three-layer configuration can be directly carried out on the LAG, so that the interface configuration and maintenance cost of the public network can be reduced.

Referring to fig. 1, for a plurality of member links included in a LAG, because transmission paths of different member links are different, quality indexes such as time delay and the like of different member links may be significantly different, that is, link performances of different member links are different. If the link performance of a certain member link is used to represent the link performance of the entire LAG, the error is large, and accurate scheduling of the traffic flow cannot be realized.

The embodiment of the application provides a traffic scheduling method, which can schedule service flows based on the link performance of member links in an LAG, thereby effectively improving the reliability of traffic scheduling. The method can be applied to a network device 01 in the system shown in fig. 1, and a target physical port of the network device 01 is a member port of a link aggregation interface. Referring to fig. 2, the method includes:

step 101, determining that the link requirement of a target service flow is matched with the link performance of a target physical port, wherein an outgoing interface of the target service flow is a link aggregation interface.

In this embodiment of the present application, the network device may store a link performance of the target physical port, where the link performance may be obtained by active detection of the network device, or may be sent to the network device by other devices. The link performance of the target physical port may refer to the link performance of the network link (i.e., the member link) corresponding to the target physical port.

After receiving the target traffic flow from the terminal device, the network device may determine an outgoing interface of the target traffic flow based on the forwarding table. If the outgoing interface of the target service flow is the link aggregation interface, the network device may continue to determine whether the link requirement of the target service flow matches the link performance of the target physical port. If the link requirement of the target traffic flow matches the link performance of the target physical port, the network device may continue to perform step 102 described below.

Wherein the link requirement of the target traffic flow may include a requirement for at least one of the following performance parameters: delay, packet loss rate, and jitter. Correspondingly, the link performance of the target physical port may include a detection result of the at least one performance parameter.

And 102, forwarding the target service flow through the target physical port.

If the network device determines that the link requirement of the target service flow is matched with the link performance of the target physical port, the network device may forward the target service flow through the target physical port. That is, the network device may forward the target traffic flow using the target member link corresponding to the target physical port. Therefore, the link performance of the member link for forwarding the target service flow can be ensured to meet the link requirement of the target service flow.

It should be understood that the network device may include a plurality of physical ports, at least one alternate physical port of the plurality of physical ports being a member port of the link aggregation interface, the target physical port being included in the at least one alternate physical port. Accordingly, the network device may store the link performance for each alternate physical port.

If the network device has a plurality of candidate physical ports, in step 102, the network device may determine a target physical port, whose link performance matches the link requirement, from the plurality of candidate physical ports based on the link performance of the plurality of candidate physical ports. If the network device has only one alternative physical port, in step 102, the network device may directly determine the alternative physical port as a target physical port whose link performance matches the link requirement.

To sum up, the embodiment of the present application provides a traffic scheduling method, where a network device may determine, based on a link requirement of a target service flow, a target physical port whose link performance matches the link requirement from a link aggregation interface, and forward the target service flow through the target physical port. Therefore, the link performance of the member link (namely, the network link corresponding to the target physical port) for forwarding the target service flow can be ensured to meet the link requirement of the target service flow, the accurate scheduling of the service flow is realized, and the reliability of flow scheduling is effectively improved.

Fig. 3 is another traffic scheduling method provided in this embodiment, which may be applied to the network device 01 in the system shown in fig. 1, and a target physical port of the network device 01 is a member port of a link aggregation interface. Referring to fig. 3, the method includes:

step 201, detecting a network link corresponding to a target physical port to obtain a link performance of the target physical port.

In this embodiment, the network device may include a plurality of candidate physical ports, each of the candidate physical ports is a member port of a link aggregation interface, and the target physical port may be included in the candidate physical ports. The network device may detect the network link corresponding to each alternative physical port according to a certain detection period, so as to obtain the link performance of each alternative physical port. Since the alternative physical port is a member port of the link aggregation interface, the network link corresponding to the alternative physical port is a member link of the LAG.

Optionally, the network device may detect the network link corresponding to the alternative physical port based on the following detection protocol: TWAMP, OWAMP, STAMP, NQA protocol, or ethernet traffic activation test methods such as y.1564, etc.

The link performance of the alternative physical port acquired by the network device may include a detection result of at least one of the following performance parameters: delay, packet loss rate, and jitter. And, the network device may store the detection result of the performance parameter in a session (session) of each alternative physical port.

For example, fig. 4 is a schematic structural diagram of another traffic scheduling system provided in the embodiment of the present application, and as shown in fig. 4, the system may include: a terminal device 02 and a plurality of network devices. The plurality of network devices may include a base station side Gateway (CSG), an Aggregation Side Gateway (ASG), an Autonomous System Boundary Router (ASBR), a Provider Edge (PE) device, and the like, which are connected in sequence. Moreover, the multiple network devices may implement routing interworking via an Interior Gateway Protocol (IGP), where the IGP may include protocols from an intermediate system to an intermediate system (ISIS) or Open Shortest Path First (OSPF). The terminal device 02 may access the CSG through a device such as a Customer Premises Equipment (CPE), and then access the core network, for example, may access an Evolved Packet Core (EPC). The ASBR may also be referred to as a Radio Service Gateway (RSG).

The network device applied by the traffic scheduling method provided by the embodiment of the application can be CSG, ASR or RSG. For example, referring to fig. 4, taking the network device as ASG1 as an example, the three alternative physical ports of the ASG1 are member ports of a link aggregation interface. The ASG1 may detect the link performance of the network links corresponding to the three alternative physical ports, respectively.

Step 202, receiving a target service flow.

The network device may receive the target traffic stream from the terminal device. For example, referring to fig. 4,

ASGs

1 and 2 may receive CSG forwarded target traffic flows from terminal device 02.

Step 203, determining that the outgoing interface of the target service flow is the link aggregation interface to which the target physical port belongs.

After receiving the target service flow, the network device may determine an outgoing interface of the target service flow by searching a forwarding table stored locally. If the outgoing interface of the target traffic flow is the link aggregation interface to which the target physical port belongs, the network device may continue to perform step 204. If the outgoing interface of the target service flow is not a link aggregation interface, the network device does not need to perform the following step 204, but may directly forward the target service flow by using the outgoing interface.

And step 204, determining the link requirement of the target service flow based on the link requirement identifier corresponding to the target service flow.

If the network device determines that the outgoing interface of the target service flow is the link aggregation interface to which the target physical port belongs, the network device may determine the link requirement of the target service flow based on the link requirement identifier corresponding to the target service flow. The link requirements of the target traffic flow may include a requirement for at least one of the following performance parameters: delay, packet loss rate, and jitter. For example, for a distance teaching service, the link requirement of the target service flow may be a low packet loss rate. For telemedicine services, the link requirements of the target traffic stream may be low latency.

As an optional implementation manner, the network device may obtain, from the target packet, the link requirement identifier corresponding to the target service flow. Wherein the target packet belongs to the target service flow. The link requirement identifier in the target message may be added by a forwarding device for forwarding the target traffic flow to the network device.

For example, referring to fig. 4, a CSG may add a link requirement identifier corresponding to a target service flow to a message of the target service flow, so that the target message of the target service flow received by the ASG1 and the ASG2 may carry the link requirement identifier corresponding to the target service flow.

As another optional implementation manner, the network device stores a correspondence between the service flow and the link requirement identifier, and the network device may obtain the link requirement identifier corresponding to the target service flow from the locally stored correspondence. The corresponding relationship may be manually configured on the network device by an operation and maintenance person, or may be issued by a controller connected to the network device.

Optionally, the correspondence may record an identifier of the service flow and a corresponding identifier of the link requirement. The network device may determine, based on the identifier of the target service flow, a link requirement identifier corresponding to the target service flow. In this embodiment of the application, the identifier of the service flow recorded in the correspondence may include: an identification of the VPN instance used to carry the traffic flow, or an identification of the VC used to carry the traffic flow. That is, the network device may use the identifier of the VPN instance or the identifier of the VC to distinguish between different traffic flows. The identifier of the VPN instance may be a name of the VPN instance.

For example, if a terminal device accesses a network through a three-layer virtual private network (L3 VPN), traffic flows from the terminal device may be distinguished by an identifier of a VPN instance. If the terminal device accesses the network by way of a layer two virtual private network (L2VPN), the traffic flow from the terminal device can be distinguished by the identification of the VC. For different application scenes, the network equipment can adopt different identifiers to distinguish different service flows, so that the reliability and the flexibility in distinguishing different service flows are effectively improved.

Optionally, the link requirement identifier corresponding to the target service flow may be a numerical identifier of a flexible-algorithm (Flex-Algo). The numeric identifier may range from 128 to 255. The Flex-Algo is a mechanism for calculating a path satisfying certain constraints according to performance parameters (such as packet loss rate, delay, jitter, etc.), and the path calculation rule of the Flex-Algo is generally represented by a triple including: metric type (metric type), calculation type (calc-type), and topological constraints (topo constraints). Since the numerical identifier of the Flex-Algo can indicate different path calculation rules when the numerical identifier takes different values, the numerical identifier can indicate different link requirements.

Optionally, the link requirement identifier may be a numerical identifier of a flexible algorithm, a QoS identifier, or a color identifier in SR policy.

Step 205, determining that the link requirement of the target service flow matches with the link performance of the target physical port.

After the network device determines the link requirement of the target service flow, a target physical port with the link performance matched with the link requirement is determined from the multiple candidate physical ports based on the link performance of the multiple candidate physical ports in the network device.

Wherein, if the link requirement is a requirement for a target performance parameter, the link performance of the target physical port matching the link requirement may indicate: the target performance parameter of the target physical port is better than other alternative physical ports of the plurality of alternative physical ports. That is, the network device may determine, as the target physical port whose link performance matches the link requirement, the candidate physical port whose target performance parameter is optimal among the multiple candidate physical ports.

For example, referring to fig. 4, it is assumed that a link between ASG1 and ASBR1 is LAG, and a value of a numeric identifier of Flex-Algo of a target traffic flow received by ASG1 is 129. The ASG1 may determine the link requirement of the target traffic flow as low latency based on the numeric identifier 129 and may determine the lowest latency candidate of the three candidate physical ports as the target physical port.

It may be understood that, for the scenario in which the LAG is E-Trunk, if only one of the plurality of physical ports included in the network device is a member port of the aggregated link interface (i.e., the network device has only one alternative physical port), the network device may directly determine the alternative physical port as a target physical port whose link performance matches the link requirement.

Step 206, add the port id of the target physical port in the message of the target service flow.

In this embodiment of the present application, for each aggregation link interface to which a physical port of a network device belongs, the network device may store a member (member) identification table corresponding to the aggregation link interface. The port identifier of each physical port included in the aggregated link interface may be recorded in the member identifier table, and the port identifier may also be referred to as a member port identifier. The network device can distinguish different member ports based on the member identification table and detect the link performance of each member port.

Correspondingly, after determining the target physical port, the network device may further add the port identifier of the target physical port to the packet of the target service flow. Therefore, the network equipment receiving the message can determine the port information of the physical port sending the message conveniently. Optionally, the network device may add the port identifier of the target physical port in a hop-by-hop (HBH) field of the packet. The port identification may be the MAC address of the target physical port or may be a port index for the target physical port.

For example, referring to fig. 6, assume that the link between the CSG and the ASC is LAG, and three alternative physical ports in the CSG belong to an aggregated link interface. The port identities of the three alternative physical ports may be recorded in the member identity table of the CSG: ID1, ID2, and ID 3. If the target service flow received by the CSG: if the link requirement of service flow 2 is low packet loss, the CSG may determine that the link performance of the alternative physical port whose port is identified as ID2 matches the link requirement of the target service flow. Correspondingly, the CSG may add the port identifier of the target physical port to the HBH field of the packet: ID 2.

Step 207, determining the network topology for forwarding the target traffic flow based on the numerical identifier.

In this embodiment, for a scenario where the link requirement is identified as a numerical identifier of a flexible algorithm, the network device may further determine, based on the numerical identifier, a network topology for forwarding the target traffic flow, that is, calculate an end-to-end path for carrying the target traffic flow. Wherein the network topology includes network links to which the target physical ports are connected.

For example, referring to fig. 5, it is assumed that the traffic scheduling system includes 8 network devices R1 to R8, where multiple paths exist between the head-end network device R1 and the tail-end network device R5. Wherein the overhead (cost) and the delay of the link between each two adjacent network devices are shown by the dashed boxes in fig. 5. For example, the overhead of the link between network devices R1 and R2 is 10 and the latency is 100. The overhead of the link between network devices R1 and R6 is 10 and the latency is 10. Assume that the network device R1 determines that the numeric identifier of the Flex-Algo corresponding to the target traffic flow is 128, and when the numeric identifier takes the value of 128, it indicates that the shortest path is used as the constraint calculation path. The network topology (i.e., shortest path) calculated by network device R1 based on the link cost between the network devices to carry the target traffic flow may be: r1 → R2 → R3 → R4 → R5. If the value identifier of the Flex-Algo corresponding to the target service flow is 129 and the value of the value identifier is 129 indicates that the path is calculated with the lowest delay as the constraint, the network topology (i.e., the path with the lowest delay) calculated by the network device R1 based on the link delay between the network devices for carrying the target service flow may be: r1 → R6 → R7 → R8 → R5.

Fig. 5 also shows coordinates (locators) of each network device and a link between two adjacent network devices when the numeric identifier of the Flex-Algo takes different values. For example, when the value of the numeric identifier of Flex-Algo is 128, the locator of the network device R1 is A1:1::1, and the locator of the network device R2 is A2:1:: 1. When the value of the numerical identifier of the Flex-logo is 129, the locator of the network device R1 is A1:2::1, and the locator of the network device R2 is A2:2: 1.

Based on the method provided by the embodiment of the present application, the network device may determine not only the target physical port for forwarding the target traffic flow (i.e., determine the member link in the LAG for carrying the target traffic flow) based on the numerical identifier of the flexible algorithm, but also determine the network topology for forwarding the target traffic flow based on the numerical identifier of the flexible algorithm, i.e., calculate the end-to-end path. Therefore, not only can the accurate scheduling of the target service flow be realized, but also the identification behavior of the network equipment to the numerical identifier of the flexible algorithm does not need to be changed, thereby being effectively compatible with the current network technology.

Step 208, forwarding the target traffic flow through the target physical port and based on the network topology.

After the network device determines that the link performance of the target physical port is matched with the link requirement of the target service flow, the network device can forward the target service flow through the target physical port based on the calculated network topology.

For example, as shown in fig. 6, for a service flow 2 with a low link requirement, the CSG may forward the service flow 2 through a target physical port with a port ID of 2. With continued reference to fig. 6, assuming that the link requirement of traffic flow 1 is low latency and the link requirement of traffic flow 3 is low jitter, the CSG may forward the traffic flow 1 through the target physical port with port ID1 and may forward the traffic flow 3 through the target physical port with port ID 3.

Based on the above analysis, it can be known that, because the network device can forward the service flow by using the target physical ports with different link performances based on different link requirements of different service flows, it can be ensured that the member links for forwarding the service flow can meet the requirements of the service flow, and accurate scheduling of the service flow is realized.

Optionally, if, in the step 204, the network device acquires the link requirement identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link requirement identifier, before executing the step 208, the network device may further add the link requirement identifier to the message of the target service flow. Correspondingly, after receiving the message of the target service flow, the other network device may determine the link requirement of the target service flow based on the link requirement identifier added in the message. Alternatively, the network device may be a device supporting Segment Routing (SR) technology, and the network device may add the link requirement identifier after a segment list (segment list) in the message.

For example, referring to fig. 6, the CSG may add a numeric identifier of Flex-Algo to the packet of the service flow 1: 129 which then forwards the packet to the ASG. Assuming that three alternative physical ports used by the ASG for connecting with the ASBR belong to a link aggregation interface, and an outgoing interface of the service flow 1 in the ASG is the link aggregation interface, the ASG may be based on a numeric identifier of Flex-Algo carried in a packet of the service flow 1: 129, determining the link requirement of the service flow 1 as low delay. The ASG may then forward the traffic flow 1 through the physical port with port ID 1.

It is to be understood that, as shown in fig. 6, the port identifications of the physical ports in each link aggregation interface are different from each other, and the port identifications of the physical ports in different link aggregation interfaces may be the same.

It can also be understood that the traffic scheduling system applied by the method provided in this embodiment of the present application may be a system supporting SRv6, where SRv6 is a network forwarding technology that combines a Segment Routing (SR) technology with an Internet protocol version 6 (IPv 6) technology. Fig. 7 is a schematic structural diagram of a packet forwarded by a forwarding plane of a terminal device and a network device according to an embodiment of the present application. As can be seen with reference to fig. 7, the message received by the CSG may include the following fields: payload (payload), GPRS Tunneling Protocol (GTP), IP, Virtual Local Area Network (VLAN), and Ethernet header (ETH). Wherein the IP field includes a Differentiated Services Code Point (DSCP). GPRS refers to general packet radio service (general packet radio service).

If the traffic scheduling system employs SRv6 Best Effort (BE) technique, referring to fig. 7, the CSG may encapsulate an HBH field and an IPv6 header in a packet, and forward the packet encapsulated with the HBH field and the IPv6 header to the ASG. The IPv6 header may include a VPN Segment Identification (SID), among other things. If the traffic scheduling system adopts SRv6policy, referring to fig. 7, the CSG may encapsulate a Segment Routing Header (SRH), an HBH field, and an IPv6 header in the packet, and forward the packet encapsulated with the SRH, the HBH field, and the IPv6 header to the ASG.

The ASG may in turn forward the received packet to the ASBR. The ASBR may decapsulate the received packet to delete the HBH field and the IPv6 header in the packet, and if the packet further includes an SRH, the ASBR may delete the SRH. Then, the ASBR may forward the packet with the deleted field to the core network.

The TWAMP is taken as an example, and the implementation process of the step 201 is described below. Referring to fig. 8, when detecting link performance of a member link based on TWAMP, one end of the member link may be a client (client) or a sender (sender), and the other end of the member link may be a server or a reflector (reflector). In the process of detecting the link performance, the sending end and the reflecting end may sequentially interact with the following messages: a request TW session (request-TW-session) message, an accept session (accept session) message, a start sessions (start sessions) message, a start response (start-ACK), a session-sender test packet (session-sender packet), a session-reflector test packet (session-reflector packet), and a stop sessions (stop sessions) message.

To implement the detection of the member link, the value of the command number field in the request TW session message may be extended. For example, since the meaning of the command value of 11 to 255 is not defined, it may be defined that when the command value of 11 to 255 is a certain value (for example, 11), it indicates that the link performance of the member links of the LAG needs to be measured.

When the sending end receives the member link measurement command, it may first check whether the port to be subjected to TWAMP measurement is a link aggregation interface. If the port needing to carry out TWAMP measurement is a link aggregation interface, the sending end can send a request TW session message with a command value of 11 to the reflecting end; if the port needing TWAMP measurement is not a link aggregation interface, the sending end may fall back to the normal TWAMP measurement (for example, send a request TW session message with a command value of 5), or may generate a configuration error notification message.

After the reflector receives a member link measurement command (for example, a TW session request message with a command value of 11) sent by the sender, if the reflector does not support member link measurement, the reflector may set the Accept field to 3 in the received session message to respond. If the reflecting end supports member link measurement but encounters some error, a corresponding error code may be generated as specified by TWAMP standards and added to the Accept field of the Accept session message. If the reflection end supports member link measurement and no other error occurs, the Accept field may be set to 0 in the Accept session message to respond, and preparation for performing TWAMP measurement on the member link specified in the member link measurement command is ready, that is, the reflection end may be ready to perform a measurement task.

After the measurement task starts, the sender may generate and send a session sender test packet. After receiving the session sending end test packet, the reflection end can send the session reflection end test packet to respond.

For the member link in the non-authentication mode, a member identification (memberID) field may be newly added in the session sending end test packet, and the member identification field is used to carry an identification of the member link. For the member link in the authentication and encryption mode, 6 bytes can be divided from a field of the session sender test packet that needs to be zero (MBZ) as a member identification field to carry the identification of the member link.

The identifier of the member link is also the port identifier of the physical port corresponding to the member link. For example, for an ethernet member link, the identifier of the member link in the session sending end test packet may be a MAC address of the member link that sends the session sending end test packet, or may be a number, such as a port index, of the member link that sends the session sending end test packet. For a POS member link, the identifier of the member link may be the number of the member link that sent the session initiator test packet. The POS refers to a packet over SONET/SDH (synchronous optical network, SONET) or Synchronous Digital Hierarchy (SDH) based data packet.

After receiving the session sending end test packet through the member link configured with the member link measurement task, the reflection end can send the session reflection end test packet through the member link to be measured to respond. If the reflection end receives the session reflection end test packet through the member link which is not configured with the member link measurement task or the member link which does not belong to the LAG, no response is required, and alarm information can be generated.

For the member link in the non-authentication mode, a member identification field and a sender member identification (sender member ID) field may be newly added in the session reflection end test packet sent by the reflection end. For the member link in the authentication and encryption modes, two MBZ fields of the session reflection end test packet sent by the reflection end can be used as a member identification field and a sending end member identification field respectively. And the reflection end may fill the identifier of the member link that sends the session reflection end test packet in the member identifier field, and may fill the content of the member identifier field in the session sending end test packet that it receives in the sending end member identifier field.

Optionally, for the ethernet member link, the identifier of the member link in the session reflection side test packet may be a MAC address of the member link that sends the session reflection side test packet, or may be a number of the member link that sends the session reflection side test packet, such as a port index. For a POS member link, the identification of the member link may be the number of the member link that sent the session reflection side test packet.

After receiving the session reflection end test packet, the sending end can check whether the content of the sending end member identification field in the session reflection end test packet is consistent with the identification of the member link receiving the session reflection end test packet. If the two link parameters are consistent, the sending end may determine information of an opposite end interface (i.e., the interface of the reflection end) according to the content of the member identification field in the session reflection end test packet, and calculate to obtain the link performance of the member link (for example, the sending end may calculate to obtain information of time delay, jitter, packet loss rate, and the like of the member link). If the content of the member identification field of the sending end in the session reflection end test packet is inconsistent with the identification of the member link receiving the session reflection end test packet, the sending end may discard the session reflection end test packet and may generate alarm information. It can be understood that, for each member link in the LAG, the transmitting end may calculate the link performance of the member link by the above method.

The following illustrates the relevant configuration in a network device. Assuming that three physical ports in the network device belong to Eth-trunk, the configuration of the three physical ports (i.e., member ports) may be as follows:

interface gigabit Ethernet x1/x1/x1// configuration gigabit Ethernet interface x1/x1/x 1;

undo shutdown// active port;

the ID of the eth-trunk 3member-ID 1// configuration member port is 1;

#

interface GigabitEthernet x2/x2/x2；

undo shutdown；

eth-trunk 3member-id 2；

#

interface GigabitEthernet x3/x3/x3；

undo shutdown；

eth-trunk 3member-id 3；

#

assuming that the network device detects the link performance of the physical port by using the TWAMP, the operation and maintenance personnel needs to configure a TWAMP lightresponder (lightweight responder) end. The TWAMP lightweight response end needs to configure parameters such as an IP address of a sending end, an IP address of a reflection end, a User Datagram Protocol (UDP) port number of the sending end, a UDP port number of the reflection end, and a VPN instance name.

For example, the operation and maintenance personnel may configure the following parameters at the TWAMP lightweight response end: test-session 1local-ip192:168: a remote-ip 192:168: b local-port c remote-port d vpn-instance LTE-RAN member-id 1. Wherein, local-IP represents the IP address of the local end (i.e. the reflection end), remote-IP represents the IP address of the far end (i.e. the sending end), local-port represents the UDP port number of the local end, and remote-port represents the UDP port number of the far end.

The operation and maintenance personnel may configure a TWAMP Light Client terminal in a TWAMP Light Controller terminal, for example, the operation and maintenance personnel may configure the following parameters in the TWAMP Light Controller terminal:

test-session 1sender-ip 192:168: b reflector-ip 192:168: a sender-port d reflector-port c vpn-instance LTE-RAN member-id 1. Wherein, sender-IP represents the IP address of the sending end, reflector-IP represents the IP address of the reflecting end, sender-port represents the UDP port number of the sending end, and reflector-port represents the UDP port number of the reflecting end.

And, the operation and maintenance personnel can configure the TWAMP Light Sender terminal in the TWAMP lightweight control terminal. For example, the following parameters may be configured: test start-continuous test-session 1.

The configuration of the operation and maintenance personnel on the Eth-trunk interface can be as follows:

interface Eth-Trunk3

MTU 1600// Maximum Transmission Unit (MTU) 1600;

the control-flap// control interface oscillation characteristic;

IPv6 enable// IPv6 enabled;

ip address 192.168.a.a 255.255.255.0；

ipv6 address 192:168:a:a/112；

ipv6 mtu 9600；

is enable 3// enables ISIS;

ISIS IPv6 enable 3// ISIS IPv 6;

in addition, global enable SRv6 is also needed. For example, the operation and maintenance personnel may configure the following in the network device:

segment-routing ipv6

encapsulation source-address 101:11: 1ip-ttl 150// encapsulation source address;

locator srbe IPv6-prefix 101:11: 64static 32// configuring IPv6 prefix (prefix), configuring locator 101:11: name srbe;

1End-op// static configuration End SID101:11: 1;

locator test1 ipv6-prefix 21:11: 64static 1// configuration locator 21:11: 64, name test 1.

Based on the above configuration, the network device can implement the traffic scheduling method provided in the embodiment of the present application. It should be understood that the above configuration is only an illustration, and an operation and maintenance person or a controller may also configure a network device in other ways, so that the network device implements the traffic scheduling method provided in the embodiment of the present application.

It can also be understood that the order of steps of the traffic scheduling method provided in the embodiment of the present application may be appropriately adjusted, and the steps may also be increased or decreased according to the situation. For example, the step 206 may be deleted according to the situation, that is, the network device may not need to add the port identifier of the target physical port in the packet of the target traffic flow. Alternatively, step 207 may be eliminated as appropriate, i.e. for a scenario where the link requirement identifies a numerical identifier that is not a flexible algorithm, the network device does not need to calculate the network topology based on the numerical identifier. Any method that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application is covered by the protection scope of the present application, and thus the detailed description thereof is omitted.

To sum up, the embodiment of the present application provides a traffic scheduling method, where a network device may determine, based on a link requirement of a target service flow, a target physical port whose link performance matches the link requirement from a link aggregation interface, and forward the target service flow through the target physical port. Therefore, the link performance of the member link (i.e. the network link corresponding to the target physical port) for forwarding the target service flow can be ensured to meet the link requirement of the target service flow, and the reliability of traffic scheduling is effectively improved.

Moreover, with the rapid evolution of the fifth generation mobile communication technology (5th generation mobile networks, 5G), the services carried in the network are more and more abundant, and the requirements of different services on the network transmission quality are also different. For example, the remote teaching service requires a low packet loss rate of the network, and the remote medical service requires a low time delay of the network. Based on the method provided by the embodiment of the application, different services can be loaded in different member ports of the link aggregation interface based on different service demands, so that the accurate scheduling of the service flow is realized.

Fig. 9 is a schematic structural diagram of a network device according to an embodiment of the present application, where the network device may be applied to the traffic scheduling systems shown in fig. 1, fig. 4, fig. 5, or fig. 6. For example, the network device may be the ASG shown in fig. 4, or may be the CSG, ASG, or ASBR shown in fig. 6. The target physical port of the network device is a member port of the link aggregation interface, and as shown in fig. 9, the network device may include:

a first determining module 301, configured to determine that a link requirement of a target traffic flow matches a link performance of the target physical port, where an outgoing interface of the target traffic flow is the link aggregation interface. The functional implementation of the first determining module 301 may refer to the related descriptions of step 101 and step 205 in the above method embodiments.

A forwarding module 302, configured to forward the target traffic flow through the target physical port. The functional implementation of the forwarding module 302 may refer to the related descriptions of step 102 and step 208 in the above method embodiments.

Optionally, the first determining module 301 may be configured to: and determining the link requirement of the target service flow based on the link requirement identification corresponding to the target service flow. The functional implementation of the first determining module 301 may also refer to the related description of step 204 in the above method embodiment.

Optionally, the first determining module 301 may be configured to: acquiring the link demand identification from a target message, wherein the target message belongs to the target service flow; or, obtaining the link requirement identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link requirement identifier.

Optionally, the link requirement is identified as a numerical identifier of the flexible algorithm. As shown in fig. 9, the network device may further include:

a second determining module 303, configured to determine, based on the numerical identifier, a network topology for forwarding the target traffic flow, where the network topology includes network links to which the target physical port is connected. The functional implementation of the second determining module 303 may refer to the related description of step 207 in the above method embodiment.

Optionally, the identifier of the service flow recorded in the correspondence includes: an identification of the VPN instance used to carry the traffic flow, or an identification of the VC used to carry the traffic flow.

Optionally, the forwarding module 302 may be configured to: after the first determining module 301 obtains the link requirement identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link requirement identifier, add the link requirement identifier to the message of the target service flow; and forwarding the target traffic flow through the target physical port.

Optionally, the forwarding module 302 may be configured to: adding the port identification of the target physical port in the message of the target service flow; and forwarding the target service flow through the target physical port. The functional implementation of the forwarding module 302 may also refer to the related description of step 206 in the above method embodiment.

Optionally, as shown in fig. 9, the network device may further include:

a detecting module 304, configured to detect a network link corresponding to the target physical port before the first determining module 301 determines that the link requirement of the target traffic flow matches the link performance of the target physical port, so as to obtain the link performance of the target physical port. The functional implementation of the detection module 304 may also refer to the related description of step 201 in the above method embodiment.

Optionally, the link requirements of the target traffic flow include requirements for at least one of the following performance parameters: delay, packet loss rate, and jitter.

Optionally, the network device may include a plurality of candidate physical ports, each of the candidate physical ports being a member port of the link aggregation interface, and the target physical port being included in the candidate physical ports.

To sum up, the embodiment of the present application provides a network device, where the network device may determine, based on a link requirement of a target service flow, a target physical port whose link performance matches the link requirement from a link aggregation interface, and forward the target service flow through the target physical port. Therefore, the link performance of the member link (namely, the network link corresponding to the target physical port) for forwarding the target service flow can be ensured to meet the link requirement of the target service flow, the accurate scheduling of the service flow is realized, and the reliability of flow scheduling is effectively improved.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the network device and each module described above may refer to corresponding processes in the foregoing method embodiments, and are not described herein again.

It should be understood that the network device provided in the embodiments of the present application may also be implemented by an application-specific integrated circuit (ASIC), or a Programmable Logic Device (PLD), which may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. The traffic scheduling method provided by the foregoing method embodiment may also be implemented by software, and when the traffic scheduling method provided by the foregoing method embodiment is implemented by software, each module in the network device may also be a software module.

Fig. 10 is a schematic structural diagram of another network device according to an embodiment of the present application, where the network device may be applied to a traffic scheduling system shown in fig. 1, fig. 4, fig. 5, or fig. 6. For example, the network device may be the ASG shown in fig. 4, or may be the CSG, ASG, or ASBR shown in fig. 6. The target physical port of the network device is a member port of a link aggregation interface, and as shown in fig. 10, the network device may include: a processor 401, a memory 402, a transceiver 403, and a bus 404. The bus 404 is used to connect the processor 401, the memory 402, and the transceiver 403, among others. Communication connections with other devices may be made through transceiver 403 (which may be wired or wireless). The memory 402 stores therein a computer program for realizing various application functions. When the various modules in the network device shown in fig. 9 are implemented as software modules, the programs corresponding to these software modules may be stored in the memory 402 of the network device 400.

It should be understood that in the embodiments of the present application, the processor 401 may be a CPU, and the processor 401 may also be other general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), GPUs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or any conventional processor or the like.

The memory 402 may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), Enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM).

The bus 404 may include a power bus, a control bus, a status signal bus, and the like, in addition to a data bus. But for clarity of illustration the various busses are labeled as bus 404 in the drawings.

In a specific embodiment, the processor 401 in the network device 400 may be configured to determine that a link requirement of a target traffic flow matches a link performance of the target physical port, and forward the target traffic flow through the target physical port, where an outgoing interface of the target traffic flow is the link aggregation interface. The detailed processing procedure of the processor 401 may refer to the above-described method embodiments. For example, reference may be made to step 101 and step 102 in the embodiment shown in fig. 2, and detailed descriptions of step 201 to step 208 in the embodiment shown in fig. 3, which are not described herein again.

The embodiment of the present application further provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and the instructions are executed by a processor to implement the traffic scheduling method provided in the foregoing method embodiment.

The embodiment of the present application further provides a computer program product containing instructions, which when run on a computer, causes the computer to execute the traffic scheduling method provided by the above method embodiment.

An embodiment of the present application further provides a traffic scheduling system, and referring to fig. 1, the traffic scheduling system may include: at least one network device 01, and a terminal device 02 connected to the network device 01. The network device 01 connected to the terminal device 02 may be the network device provided in the above embodiments, for example, the network device shown in fig. 9 or fig. 10. The network device may forward the service flow from the terminal device 02 by using the traffic scheduling method provided in the foregoing embodiment.

For example, referring to fig. 4 and 6, the network device 01 may be a CSG, an ASG, an RSG, or an ASBR.

Optionally, the traffic scheduling system provided in the embodiment of the present application may be a system supporting SRv 6. The traffic scheduling system can distribute SID based on the link performance of the member link, splice end-to-end SRv6, and enable the service flow to be carried on the SRv6 tunnel meeting the requirement of a specific link, thereby realizing accurate scheduling of the service flow.

The above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, the above-described embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded or executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more collections of available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium may be a Solid State Drive (SSD).

The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more, e.g., a plurality of network devices means two or more network devices. The terms "system" and "network" are often used interchangeably herein.

The above description is only an alternative embodiment of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the present application, and these modifications or substitutions should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A flow scheduling method is characterized in that the method is applied to network equipment, and a target physical port of the network equipment is a member port of a link aggregation interface; the method comprises the following steps:

determining that the link requirement of a target service flow is matched with the link performance of the target physical port, wherein an outgoing interface of the target service flow is the link aggregation interface;

and forwarding the target service flow through the target physical port.

2. The method of claim 1, wherein determining that the link demand of the target traffic flow matches the link performance of the target physical port comprises:

and determining the link requirement of the target service flow based on the link requirement identification corresponding to the target service flow.

3. The method of claim 2, wherein the determining the target routing algorithm corresponding to the target traffic flow based on the link requirement identifier corresponding to the target traffic flow comprises:

acquiring the link demand identification from a target message, wherein the target message belongs to the target service flow;

or, obtaining the link requirement identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link requirement identifier.

4. A method according to claim 2 or 3, wherein the link requirement identification is a numerical identifier of a flexible algorithm; the method further comprises the following steps:

determining a network topology for forwarding the target traffic flow based on the numeric identifier, the network topology including network links to which the target physical ports are connected.

5. The method according to claim 3 or 4, wherein the identification of the traffic flow recorded in the correspondence relationship comprises: and the identifier of the virtual private network VPN instance used for bearing the service flow, or the identifier of the virtual circuit VC used for bearing the service flow.

6. The method according to any one of claims 3 to 5, wherein after obtaining the link requirement identifier corresponding to the target service flow from the correspondence between the service flow and the link requirement identifier, the forwarding the target service flow through the target physical port includes:

adding the link requirement identification in the message of the target service flow;

and forwarding the target service flow through the target physical port.

7. The method according to any of claims 1 to 6, wherein said forwarding said target traffic flow through said target physical port comprises:

adding the port identification of the target physical port in the message of the target service flow;

and forwarding the target service flow through the target physical port.

8. The method of any of claims 1 to 7, wherein prior to said determining that the link requirements of the target traffic flow match the link performance of the target physical port, the method further comprises:

and detecting a network link corresponding to the target physical port to obtain the link performance of the target physical port.

9. The method of any of claims 1 to 8, wherein the link requirements of the target traffic flow include requirements for at least one of the following performance parameters: delay, packet loss rate, and jitter.

10. The method according to any of claims 1 to 9, wherein each of the plurality of candidate physical ports of the network device is a member port of the link aggregation interface, and the target physical port is included in the plurality of candidate physical ports.

11. A network device, wherein a target physical port of the network device is a member port of a link aggregation interface; the network device includes:

a first determining module, configured to determine that a link requirement of a target service flow matches with a link performance of the target physical port, where an outgoing interface of the target service flow is the link aggregation interface;

and the forwarding module is used for forwarding the target service flow through the target physical port.

12. The network device of claim 11, wherein the first determining module is configured to:

13. The network device of claim 12, wherein the first determining module is configured to:

14. The network device of claim 12 or 13, wherein the link requirement identifier is a numerical identifier of a flexible algorithm; the network device further includes:

a second determining module, configured to determine, based on the numerical identifier, a network topology for forwarding the target traffic flow, where the network topology includes a network link to which the target physical port is connected.

15. The network device of claim 13 or 14, wherein the forwarding module is configured to:

after the first determining module obtains the link demand identifier corresponding to the target service flow from the corresponding relationship between the service flow and the link demand identifier, adding the link demand identifier in the message of the target service flow;

and forwarding the target service flow through the target physical port.

16. The network device of any of claims 11 to 15, wherein the forwarding module is configured to:

and forwarding the target service flow through the target physical port.

17. The network device of any of claims 11 to 16, wherein the network device further comprises:

a detecting module, configured to detect a network link corresponding to the target physical port before the first determining module determines that the link requirement of the target service flow matches the link performance of the target physical port, so as to obtain the link performance of the target physical port.

18. A computer-readable storage medium having stored thereon instructions for execution by a processor to perform the method of any one of claims 1 to 10.

19. A traffic scheduling system, the system comprising: a terminal device, and a network device according to any one of claims 11 to 17 connected to the terminal device;

the network device is configured to forward a service flow from the terminal device.