Patent Application
20240235972
The present application relates to the field of cloud computing technology, and in particular to a cloud network, a measurement system for a cloud network, a method, a device and a storage medium.
Cloud network is a complex network that integrates a physical network and a virtual network, and the virtual network includes a multi-tenant network. Tenants' applications as well as connections and communications between the applications are hosted on the cloud network. An application request of a tenant will reach a destination end after being processed and transmitted via multiple-layer networks.
The network quality of a cloud network has a direct impact on tenants' applications. However, due to flexible and changeable characteristics of tenants and network topology of a cloud network, existing quality detection technology for a physical network is not suitable for the cloud network. In this case, it is very critical how to simply and accurately measure the network quality of a cloud network.
Various aspects of the present application provide a cloud network, a measurement system for a cloud network, a method, a device and a storage medium, for simple and accurate measurement of the network quality of a could network.
An embodiment of the present application provides a cloud network, including a physical network and a virtual network hosted on the physical network; the virtual network including a multi-tenant network and network element devices responsible for traffic forwarding and interconnection between different end devices in the multi-tenant network; the cloud network further including a scheduling device and an analysis device; the scheduling device being configured for perceiving a measurement intent of a target tenant, generating a measurement rule that complies with the measurement intent and delivering the measurement rule to a source network element device, wherein the measurement rule includes a source end device and a destination end device on a path to be measured, and the source network element device is a network element device on the path to be measured; the source network element device being configured for generating a measurement request message according to the measurement rule and forwarding the measurement request message, wherein the measurement request message is used for enabling the source network element device and other network element devices on the path to be measured that receive the measurement request message to generate measurement record information; the analysis device being configured for performing network quality analysis according to the measurement record information generated by the source network element device and the other network element devices.
An embodiment of the present application further provides a measurement system for a cloud network, including a scheduling subsystem, at least one measurement execution subsystem and a measurement analysis subsystem; the scheduling subsystem being configured for perceiving a measurement intent of a target tenant in the cloud network, generating a measurement rule that complies with the measurement intent and delivering the measurement rule to a target measurement execution subsystem, wherein the measurement rule includes a source end device and a destination end device on a path to be measured, and the target measurement execution subsystem corresponds to the path to be measured; the target measurement execution subsystem being configured for generating a measurement request message according to the measurement rule, transmitting the measurement request message into the path to be measured, so that at least part of network element devices on the path to be measured forward the measurement request message and generate measurement record information; the measurement analysis subsystem being configured for performing network quality analysis according to the measurement record information generated by the at least part of network element devices.
An embodiment of the present application further provides a network quality measurement method, including: perceiving a measurement intent of a target tenant in a cloud network, and generating a measurement rule that complies with the measurement intent, wherein the measurement rule includes a source end device and a destination end device on a path to be measured; generating a measurement request message according to the measurement rule, and transmitting the measurement request message into the path to be measured, so that at least part of network element devices on the path to be measured generate measurement record information; performing network quality analysis according to the measurement record information generated by the at least part of network element devices.
An embodiment of the present application further provides a cloud computing device, including a memory and a processor, wherein the memory is used to store computer programs, and the processor is used to execute the computer programs to implement steps in the method embodiment of the present application.
An embodiment of the present application further provides a computer-readable storage medium storing computer programs, wherein the computer programs, when are executed by a processor, enable the processor to implement steps in the method embodiment of the present application.
An embodiment of the present application further provides a computer program product, including computer programs/instructions. The computer programs/instructions, when executed by a processor, enable the processor to implement steps in the method embodiment of the present application.
Drawings illustrated here are used to provide a further understanding of the present application and constitute a part of the present application. The schematic embodiments of the present application and descriptions of the embodiments are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:
In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and comprehensively described below in combination with the specific embodiments of the present application and corresponding drawings. It is obvious that the described embodiments are only some of the embodiments of the present application, rather than all of the embodiments. All other embodiments obtained based on the embodiments of the present application by those of ordinary skill in the art without any creative efforts shall fall within the protection scope of the present application.
For the existing technical problem that the network quality of a cloud network cannot be effectively measured, in some embodiments of the present application, a measurement system is provided, which may be used to, but is not limited to, measure the network quality of the cloud network. The measurement system may also be applied to a physical network to measure the network quality for the physical network. In a case where the measurement system is applied to a cloud network, the measurement system may perceive the measurement intent of a tenant in the cloud network, generate a measurement rule according to the measurement intent, and based on this measurement rule, transmit a measurement request message into a network element device on a path to be measured by applying the bypass packet injection method. By using measurement record information generated when the measurement request message passes through different network element devices to perform network quality analysis, the network quality of a cloud network can be measured simply, effectively, and accurately. In the following embodiments of the present application, the focus is on applying the measurement system to a cloud network as an example for explanation.
In embodiments of the present application, for a cloud network, by perceiving the measurement intent of a tenant in the cloud network, a measurement rule is generated according to the measurement intent, and based on this measurement rule, a measurement request message is transmitted into a network element device on a path to be measured by applying the bypass packet injection method. By using measurement record information generated when the measurement request message passes through different network element devices to perform network quality analysis, the network quality of a cloud network can be measured simply, effectively, and accurately.
Further, the measurement process is significantly simplified by making a measurement request of a tenant intentional, and the tenant is unaware of the measurement process. There is no need to perform management operations on complex measurement rules, which helps improve tenant's experiences. In addition, by means of the bypass packet injection method, there is no need to deploy measurement services in the tenant's network environment, which is beneficial to reducing intrusion into the tenant's network environment. Meanwhile, since the embodiments of the present application adopt the active packet injection, which can avoid the dependence on tenant's actual application traffic, and the network quality can be measured even in a case where the tenant does not generate any actual application traffic.
First, the cloud network is briefly introduced: the cloud network is a complex network that integrates a physical network and a virtual network, wherein the virtual network further includes a multi-tenant network. That is, the cloud network includes a physical network and a virtual network. The physical network includes physical machines such as servers, cabinets, routers, and switches, as well as physical connection lines used to realize network connections between these physical machines, for example, coaxial cables, network cables, optical fibers, etc. The virtual network is hosted on the physical network, which is a logical network implemented based on virtualization technology on the basis of the physical network. Physical network resources may be virtualized, so that the physical network resources can be upgraded to virtualized and dynamically allocatable virtualized resources.
In the embodiments of the present application, the virtual network includes a multi-tenant network, and network environments of different tenants are isolated from each other. Each tenant network includes but is not limited to: all data in the cloud network that may be used for identifying the tenant, such as various virtualized resources like an account created for the tenant and accounting data in the cloud network, as well as various data set for the tenant in the cloud network and a virtualized end device configured by the tenant, etc. In the embodiments of the present application, an end device in the tenant network refers to a virtualized device that can initiate or terminate network traffic. Generally, an end device can provide a completely isolated network environment for the tenant and is responsible for carrying the tenant's applications which will send and receive network traffic (such as various messages). The end device may be implemented in the form of, but not limited to: a virtual machine (VM), a container, an elastic compute service (ECS), and a configuration object for a subsequent network element device (such as a virtual switch), a cloud database, etc. A tenant generally refers to a user who uses a cloud network or various resources in the cloud network. In the present embodiment, no limitation is made to the implementation of the tenant network. For example, it may be implemented as a virtual private cloud (VPC). For tenants, they may deploy their own VMs, cloud databases and other end devices in their VPC.
In addition to the multi-tenant network, the virtual network further includes a network element device that implements traffic forwarding and network interconnection between different end devices in the multi-tenant network. In the embodiments of the present application, the network element device is mainly used to forward traffic between different end devices, perform message processing, and achieve network interconnection between different end devices which, for example, may be virtual switches, virtual gateways, etc. In an optional embodiment, overlay technology may be used to implement an overlay network in the virtual network. The overlay network is between the physical network and the tenant network, and the above network element device may be implemented in the overlay network. The overlay network is a bridge between the tenant network and the physical network, allowing the interconnection between the end devices in the tenant network to be free of constraints of the physical network, providing conditions for the ultimate realization of flexible definition, on-demand allocation, and on-demand adjustment of network resources. In this way, the entire cloud network may be implemented as a three-layer network architecture including the physical network, overlay network, and multi-tenant network, however, to which the division for a cloud network architecture is not limited. No matter which kind of network architecture is, by means of packaging configuration information of various resources in the virtual network and finally presenting to the tenant in the form of configuration objects, the tenant may accordingly configure the configuration objects according to their own needs, thereby obtaining an end device, a subnetwork and other resources that meet their own needs.
From the above introduction to the cloud network, it can be seen that network quality measurement for the cloud network is no longer limited to physical machines to physical machines, but needs to go deep inside virtualized end devices (such as virtual machines). The virtualized end devices are logical nodes, which have great differences from the deployment and topology of the physical machines. In a cloud network, compared with the topology of a physical network, the topology of a tenant network is flexible and changeable. According to different requirements of tenants, these virtualized end devices (such as virtual machines) may be flexibly added or reduced. Interconnection relationships between end devices and between end devices and other networks (such as private networks) may also be flexibly changed according to tenants' requirements. If the network quality of a cloud network is directly detected by a tenant, the tenant needs to perform complex measurement work, including deploying measurement services, managing measurement objects and measurement rules, etc. Moreover, these tasks also need to continuously adaptively changed according to the topology changes of the virtual network, which is a relatively arduous work for tenants, and it is quite difficult to measure the network quality. The measurement system provided by the embodiments of the present application can solve the technical problem of difficult network quality measurement of a cloud network.
Next, a measurement system provided by embodiments of the present application is introduced. As shown in
In a case where the measurement system is applied to a cloud network, as shown in
The target tenant refers to a tenant in the cloud network, and the number of which may be one or more. The target tenant may refer to all tenants in the cloud network or part of tenants in the cloud network, which may be specifically determined based on network quality measurement requirements. For example, if it needs to understand the network quality of the entire cloud network from the perspective of a cloud network provider, all tenants in the cloud network may be used as target tenants, the measurement intent of each tenant are perceived, and network quality measurement is performed for each tenant, so as to obtain the network quality of the entire cloud network. For another example, if it needs to understand the network quality of the networks of some tenants (these tenants may be tenants who propose network quality measurement requests, or VIP tenants, or tenants whose network quality is lower than the set standard, etc.) from the perspective of the tenants, these tenants may be used as target users, the measurement intents of these tenants are perceived, and network quality measurement is performed for these tenants, so as to meet the network quality measurement requirements of these tenants. For another example, if it needs to understand the network quality of a certain region covered by the cloud network from a regional perspective, tenants in this region may be used as target tenants, the measurement intents of these tenants are perceived, and network quality measurement is performed for these tenants, so as to obtain the network quality of this region. For another example, if it needs to understand the network quality involved for a certain type of applications from the perspective of application category, tenants who deploy such applications may be used as the target tenants, the measurement intents of these tenants are perceived, and network quality measurement is performed for these tenants, so as to obtain the network quality corresponding to this type of applications.
In the present embodiment, the scheduling subsystem 101 perceives the measurement intent of the target tenant. The measurement intent of the target tenant is an intentionalization of the measurement request of the target tenant and can reflect what kind of measurement request that the target tenant needs. The measurement intent may be expressed or described in a language that better fits to the user. It may be understood that the measurement intent is an expression of the measurement request of the target tenant in a way that is close to the user's language expression or description manner. The measurement request here refers to a request to measure the network quality of the cloud network.
In the present embodiment, the scheduling subsystem 101 may use various methods to perceive the measurement intent of the target tenant, no limitation is made thereto. In an optional embodiment, the scheduling subsystem 101 may monitor whether the network topology of the target tenant changes. In a case where the network topology of the target tenant does not change, the measurement intent of the target tenant generally does not change. In a case where the network topology of the target tenant changes, for example, the target tenant purchases a new virtual machine, deletes an existing virtual machine, or changes the configuration information of a virtual machine, etc., the measurement intent for the network quality usually changes. Based on this, the scheduling subsystem 101 may perceive the measurement intent of the target tenant according to the network topology change information of the target tenant. Specifically, the scheduling subsystem 101 may obtain application requirement change information submitted by the target tenant, generate the network topology change information of the target tenant according to the application requirement change information submitted by the target tenant, and determine the measurement intent of the target tenant according to the network topology change information of the target tenant. Changes in the application requirement of the target tenant will directly affect the network topology of the target tenant. For example, because the number of downstream users increases and the target tenant needs to add a virtual machine, the network topology of the target tenant will change due to the addition of a new virtual machine. This virtual machine may need to interconnect with a load balancer, or this virtual machine may need to connect to a dedicated line, or this virtual machine may need to interconnect with other existing virtual machines, which will cause changes in the target tenant's measurement intent to measure network quality. In the present embodiment, no limitation is made to the implementation of the scheduling subsystem 101 obtaining the application requirement change information submitted by the target tenant. The following are examples for illustration.
In an optional embodiment A1, the scheduling subsystem 101 may be implemented as a portal for the target tenant to interact with the cloud network provider. The application requirement information initially submitted or the application requirement change information subsequently submitted by the target tenant may be submitted through the scheduling subsystem 101, so that the cloud network provider can provide corresponding cloud computing services to the target tenant. Based on this, the scheduling subsystem 101 may directly receive the application requirement change information submitted by the target tenant. In the present embodiment, the scheduling subsystem 101 may provide a web page, an application page or a command window to the target tenant. The target tenant opens the web page, application page or command window provided by the scheduling subsystem 101 on a terminal device he/she uses, and submits the application requirement change information to the scheduling subsystem 101 through the web page, application page or command window.
In another optional embodiment A2, the virtual network of the cloud network also includes a network controller, which is a portal for interaction between the tenant and the cloud network provider. In terms of implementation, the network controller may be some software in distributed deployment, which for example, may be an API. Based on the network controller, the target tenant may submit the application requirement information or application requirement change information to the cloud network provider. In the present embodiment, the network controller may provide a web page, an application page or a command window to the target tenant. The target tenant opens the web page, application page or command window provided by the network controller on a terminal device he/she uses, and submits the application requirement change information to the network controller through the web page, application page or command window. Based on this, the scheduling subsystem 101 is in communication connection with the network controller in the cloud network, and obtains the application requirement change information submitted by the target tenant from the network controller.
Further, optionally, in the embodiment A2, the scheduling subsystem 101 may bypass the network controller, and divert the application requirement change information submitted by the target tenant from the network controller to the scheduling subsystem 101 through bypass collection manner. Alternatively, in the embodiment A2, the network controller may provide a subscription service to the scheduling subsystem 101, and the scheduling subsystem 101 may be registered as a subscriber of the network controller to subscribe to the application requirement change information submitted by the tenant, from the network controller. In this way, when the network controller receives application requirement change information submitted by any tenant, it may actively provide the application requirement change information submitted by the tenant to the scheduling subsystem 101.
No matter which method provided by the above embodiments is adopted, after obtaining the application requirement change information submitted by a target tenant, the scheduling subsystem 101 may generate network topology change information of the target tenant according to the application requirement change information, in combination with the maintained network topology of the cloud network, and then determine the measurement intent of the target tenant according to the network topology change information. For example, when the target tenant adds a virtual machine, the scheduling subsystem 101 may add a new virtual machine and network connection related to the new virtual machine on the basis of the original network topology of the target tenant, to obtain the network topology change information of the target tenant. Furthermore, when it perceives that the target tenant may need to measure the network quality between the existing virtual machine and the new virtual machine, the measurement intent may be expressed as: measuring the network quality between the existing virtual machine Vm1 and the new virtual machine Vm2. For another example, in a case where the target tenant newly configures a public network IP address for an existing virtual machine according to application requirements, the scheduling subsystem 101 may add a network connection between the existing virtual machine and the public network on the basis of the original network topology of the target tenant, to obtain the network topology change information of the target tenant. Furthermore, when it perceives that the virtual machine of the target tenant needs to access a public network corresponding to this public network IP, it is necessary to detect the network quality from the virtual machine to the public network. Assume that the public network is the public network-12345, the measurement intent may be expressed as: measuring the network quality to the public network-12345 (measure network-12345).
After perceiving the measurement intent of the target tenant, the scheduling subsystem 101 may generate a measurement rule that complies with the measurement intent. This process refers to a process of analyzing the measurement intent to obtain relevant information required for network quality measurement, and organizing the relevant information according to an information format that can be identified by the measurement execution subsystem 102, to finally obtain the measurement rule. The measurement rule includes relevant information required to measure the network quality of the cloud network according to network quality measurement requirements. This information at least includes information that can indicate the network quality of a path between which end devices needs to be measured. For example, it may include but is not limited to: identification information of a source end device and a destination end device. The source end device and the destination end device may uniquely determine a network path. In the embodiments of the present application, the network path defined by the source end device and the destination end device is called a path to be measured. The identification information here may be any information that can uniquely identify the source end device or the destination end device, such as an IP address, MAC address, or device serial number. There may be one or more groups of the source end device and the destination end device, which depends on the network quality measurement requirements. Further, optionally, the measurement rule may further include a communication protocol used for network communication between the source end device and the destination end device, such as UDP protocol, TCP protocol, to facilitate the network quality measurement for the path between the source end device and the destination end device by using the communication protocol supported by these two devices. Taking the measurement intent being to measure the network quality between an existing virtual machine Vm1 and a new virtual machine Vm2 as an example, the measurement rule generated based on the measurement intent may be expressed as: source end device (Src): Vm1, destination end device (Dst): Vm2, communication protocol (protocol): UDP.
In the embodiments of the present application, no limitation is made to the implementation of generating the measurement rule by the scheduling subsystem 101. In an optional embodiment, the scheduling subsystem 101 may determine a source end device and a destination end device on a path to be measured according to the measurement intent of the target tenant, in combination with network configuration information of the target tenant; and then generate the measurement rule according to the source end device and the destination end device on the path to be measured. The network configuration information of the target tenant refers to various information configured by the target tenant through a tenant network layer, including but is not limited to: routing table entry information, access control list (ACL) information, network element device information, network topology information, etc. Furthermore, when determining the source end device and the destination end device, a source end device to be measured may be analyzed from the measurement intent of the target tenant, which, for example, may be a virtual machine newly added by the target tenant, or a public network or dedicated line that needs to be accessed. etc. After that, network topology where the source end device is located is determined from the topology of the entire cloud network, and a potential path that has an access relationship with the source end device is obtained according to the network topology where the source end device is located, in combination with the network configuration information of the target tenant, wherein the potential path may be one or more; an end device at one end of the potential path is the source end device, and a destination end device corresponding to the source end device is determined from another end device on the potential path. In the present embodiment, no limitation is made to the implementation of determining the destination end device corresponding to the source end device from the other device on the potential path. The following are examples for illustration.
In an optional embodiment B1, the other end device on all potential paths may be used as the destination end device corresponding to the source end device by default, which means that all potential paths will be regarded as paths to be measured, and at least the network quality of all potential paths may be learned by measurement.
In another optional embodiment B2, the maximum number of paths allowed for each measurement may be set, denoted as N. N is a fixed value, for example, it may be an integer value such as 1, 2, 3 or 4. Then, in a case where there are a plurality of potential paths, at least one potential path with a number no greater than N may be randomly selected, and the other end device on the selected at least one potential path is used as the destination end device corresponding to the source end device. Correspondingly, the selected at least one potential path will be regarded as a path to be measured, and the network quality of the selected at least one potential path may be learned by measurement.
In yet another optional embodiment B3, the target tenant is allowed to select a measurement method used. The measurement method that can be selected by the user includes but is not limited to: full coverage measurement method and selective measurement method. The full coverage measurement method refers to a method of measuring all existing potential paths, and the selective measurement method refers to a method of selectively measuring part of potential paths. In this optional embodiment, the target user may choose a measurement method used. If the target tenant chooses the full coverage measurement method, the other end device on all potential paths may be used as the destination end device corresponding to the source end device, that is, all potential paths will be regarded as paths to be measured, and the network quality of all potential paths may be learned by measurement. If the target tenant chooses the selective measurement method, part of potential paths may be selected from all potential paths, and the other end device on the selected part of potential paths is used as the destination end device corresponding to the source end device, that is, the selected part of potential paths will be regarded as the path to be measured, and at least the network quality of the selected part of potential paths may be learned by measurement.
Regarding how to select part of potential paths from all potential paths, in the embodiments of the present application, no limitation is made thereto. For example, a part of potential paths may be randomly selected, or a part of potential paths may be selected according to the maximum path number N allowed for each measurement. Alternatively, the target tenant may also be allowed to set a selection condition, such as the type of the other end device, regional location, network access time, etc., and a part of potential paths may be selected according to the selection condition set by the target tenant.
Further, optionally, in the embodiment B3, the scheduling subsystem 101 may present a human-computer interaction interface to the target tenant, and a measurement method option is provided on the human-computer interaction interface. The option at least includes a full coverage measurement method and a selective measurement method for the target tenant to select. In response to the selection operation initiated by the target tenant on the measurement method option, the measurement method selected by the target tenant is determined, wherein the measurement method selected by the target tenant is either the full coverage measurement method, or the selective measurement method. In addition to this implementation, the scheduling subsystem 101 may also obtain the measurement method selected by the target tenant through the network controller in the cloud network. Specifically, the network controller may present a human-computer interaction interface to the target tenant, and a measurement method option is provided on the human-computer interaction interface. The option at least includes a full coverage measurement method and a selective measurement method for the target tenant to select. In response to the selection operation initiated by the target tenant on the measurement method option, the measurement method selected by the target tenant is determined and provided to the scheduling subsystem 101. In the present embodiment, no limitation is made to the implementation form of the human-computer interaction interface, which may be, for example, a web page, an application page, or a command window, etc.
After obtaining the measurement rule that complies with the measurement intent, the scheduling subsystem 101 may deliver the measurement rule to the measurement execution subsystem 102, and the measurement execution subsystem 102 performs operations related to the network quality measurement according to the measurement rule. In the present embodiment, there may be one or a plurality of measurement execution subsystems 102. No matter whether there is one or a plurality of measurement execution subsystems 102, in the present embodiment, no limitation is made to the deployment location of the measurement execution subsystem 102. The measurement execution subsystem 102 may be deployed at any location on a path except the location where the end device is located. That is, in the present embodiment, the measurement execution subsystem 102 is not deployed in the tenant's end device, which can reduce the intrusion into the tenant's network environment caused by network quality measurement, so that the tenant does not need to manage and maintain the complex measurement rule.
In a case where there is one measurement execution subsystem 102, no matter which path or paths are to be measured, the scheduling subsystem 101 will directly deliver the measurement rule to this measurement execution subsystem 102, and the measurement execution subsystem 102 performs operations related to the network quality measurement for all the paths to be measured. In a case where there are a plurality of measurement execution subsystems 102, the scheduling subsystem 101 in the present embodiment may also be responsible for scheduling the measurement execution subsystems 102, to use a measurement execution subsystem 102 adapted to a path to be measured to measure the network quality of this path to be measured. Further, in the case where there are a plurality of measurement execution subsystems 102, the plurality of measurement execution subsystems 102 may be deployed in a distributed deployment manner, that is, the plurality of measurement execution subsystems 102 will be deployed at different locations. In addition, physical resources occupied by different measurement execution subsystem 102 may also vary. In view of this, when scheduling the measurement execution subsystems 102, the scheduling subsystem 101 may preferentially select a measurement execution subsystem that is closer to the path to be measured, and/or select a measurement execution subsystem 102 with better execution performance, and/or select a measurement execution subsystem 102 with a smaller load, etc., to which no limitation is made.
Specifically, the scheduling subsystem 101 may deliver the above measurement rule to a target measurement execution subsystem. The target measurement execution subsystem is a scheduled measurement execution subsystem in at least one measurement execution subsystem 102. The target measurement execution subsystem is a measurement execution subsystem adapted to or corresponding to the path to be measured, which, for example, may be the one closest to the path to be measured, or the one deployed on the path to be measured, or the one with better execution performance. The target measurement execution subsystem is specifically configured for: when being scheduled, generating a measurement request message in the name of the source end device according to the measurement rule delivered by the scheduling subsystem 101, and delivering the measurement request message into the path to be measured, to enable at least part of network element devices on the path to be measured to forward the measurement request message and generate measurement record information. As shown in
The measurement request message refers to a message sent to the destination end device in the name of the source end device. It should be noted that the measurement request message is not generated by the source end device, nor is it sent from the source end device, but is generated and delivered into the path to be measured by the target measurement execution subsystem instead of the source end device, as shown in
Based on the above message format, when generating a measurement request message, the target measurement execution subsystem may generate a protocol header according to the information of the source end device and the destination end device. If the protocol header is the IP header, the IP header is generated according to the IP address of the source end device and the destination end device; if the protocol header is the UDP header, the UDP header is generated according to information such as the port number and protocol type of the source end device and the destination end device. Furthermore, the measurement header of the measurement request message is generated according to the ID of the target tenant (corresponding to the tenant-id field), detailed information of the source network element device and the first timestamp of sending the measurement request message (corresponding to the timestamp field); and the measurement request message is generated according to the protocol header and the measurement header. The detailed information of the source network element device includes but is not limited to: the ID of the network space to which the source network element device belongs (corresponding to the mea_src_tenant_id field), the IP address of the source network element device and/or the IP address of the physical machine carrying the source network element device (corresponding to the mea src_ip field). For the target measurement execution subsystem, if it is not deployed in the source network element device, the time point at which it delivers the measurement request message into the source network element device may be used as the first timestamp; if it is deployed in the source network element device, the time point at which the source network element device sends the measurement request message may be known and used as the first timestamp.
It should be noted that the above source network element device refers to a network element device into which the measurement request message is delivered on the path to be measured. Optionally, according to the deployment relationship between the target measurement execution subsystem and the source network element device, the manner in which the target measurement execution subsystem delivers the measurement request message into the source network element device will be different. For example, in an optional embodiment, a measurement execution subsystem may bypass each network element device in the cloud network. Based on this, after generating a measurement request message, the target measurement execution subsystem may send the measurement request message to its corresponding network element device. For another example, in another optional embodiment, a measurement execution subsystem may be directly deployed in each network element device in the cloud network. Based on this, the process of the target measurement execution subsystem delivering the measurement request message into the source network element device is actually a process in which the target measurement execution subsystem deployed in the source network element device generates the measurement request message. In this case, the generation time of the measurement request message is basically the same as or consistent with the sending time of the measurement request message.
In the present embodiment, no matter which deployment manner the measurement execution subsystem adopts, no specific limitation is made to the source network element device. The source network element device may be any network element device on the path to be measured. In the present embodiment, in addition to the source end device and the destination end device, the path to be measured also includes at least one network element device connected between the source end device and the destination end device. The target measurement execution subsystem may send the measurement request message to any network element device (i.e., the source network element device) on the path to be measured. The source network element device forwards the measurement request message, so that the measurement request message is forwarded continuously by other network element devices on the path to be measured. It should be noted that the specific network element device to which the measurement request message is delivered and to which the measurement request message is forwarded may be determined according to the network quality measurement requirements. Corresponding to the source network element device, the network element device to which the measurement request message is finally forwarded is called a target network element device.
In an optional embodiment, if the network quality of a local path needs to be measured, the measurement request message may be delivered into a start network element device of the local path, and the start network element device forwards the measurement request message. The measurement request message is forwarded continuously by subsequent network element devices until to the end network element device of the local path. In this optional embodiment, the source network element device above is the start network element device, and correspondingly, the target network element device is the end network element device. The local path refers to a section of the path to be measured. The target measurement execution subsystem may limit the number of forwarding times of the measurement request message, and determine, based on the number of forwarding times, that the measurement request message will not be forwarded after it reaches the end network element device. Alternatively, the target measurement execution subsystem may also send a termination instruction to the end network element device, to instruct the end network element device not to continue forwarding the measurement request message.
Alternatively, in another optional embodiment, the target measurement execution subsystem may send the measurement request message to a first network element device on the path to be measured which is directly connected to the source end device, and the first network element device forwards the measurement request message, so that the measurement request message is forwarded continuously on the path to be measured until to a second network element device, wherein the second network element device is a network element device on the path to be measured which is directly connected to the destination end device.
Further, optionally, in the above embodiments, after receiving the measurement request message, the second network element device no longer forwards the measurement request message, but drops the measurement request message after generating measurement record information. This can reduce the intrusion of the measurement request message to the destination end device and ensure that the tenant is unaware of the network measurement.
In the present embodiment, after the source network element device forwards the measurement request message, other network element devices on the path to be measured that receive the measurement request message may return a measurement reply message to the source network element device. In the present embodiment, no limitation is made to the message format of the measurement reply message. Similar to the measurement request message, an embodiment of the present application provides a standardized format of the measurement reply message. As described below, the measurement reply message at least includes: a protocol header and a measurement header, wherein the protocol header may be an IP header or a UDP header, etc., to support different communication protocols. The field information included in each header is as follows:
The measurement header and field information contained in the measurement reply message are the same as the field information contained in the measurement header of the measurement request message. It may directly copy the field values in the measurement header of the measurement request message. However, certain field values specifically used for the measurement reply message, such as mea_reply_tenant_id, mea_reply_ip, reply-timestamp, are supplemented. Based on this, it can be seen that the field information contained in the measurement header of the measurement reply message is as follows:
Based on the above format of the measurement reply message, for a network element device that needs to return the measurement reply message, the protocol header in the measurement reply message may be generated according to the information of the source end device and the destination end device; the measurement header in the measurement reply message is generated according to information such as the ID of the tenant to which the network element itself belongs, detailed information of the network element itself, and the first timestamp; and the measurement reply message is generated according to the protocol header and the measurement header. It should be noted that when the network element device generates a measurement reply message, some information may be directly copied from the measurement request message; alternatively, relevant information may be directly modified on the basis of the measurement request message to obtain the measurement reply message. For the source network element device, in addition to forwarding the measurement request message, it may also receive measurement reply messages returned by other network element devices.
In the present embodiment, the function of the measurement request message is to make the network element device or end device that the measurement request message passes through generate measurement record information. The measurement record information is some information related to network quality measurement recorded by the network element device or end device that the measurement request message passes through. For example, it may be information such as tenant information, network element device information, and sending and receiving time of the measurement request message. The tenant information may be used to analyze which tenants are involved in the path to be measured and whether it crosses tenants. The network element device information may be used to analyze which network element devices that the measurement request message actually passes through. Further, combined with network element devices that the measurement request message should pass through, it may analyze the packet loss situation of the path to be measured, the tenant network, or the entire cloud network. The sending and receiving time of the measurement request message may be used to analyze the network delay within the network element device, the network delay of the tenant network or the entire path, and may further be used to analyze the network delay of the tenant network or the entire cloud network, etc.
In an optional embodiment of the present application, the measurement record information is divided into two types. One is path record information, which is mainly used to record information of a path that the measurement request message passes through; the other is delay record information, which is mainly used to record transmission delay of the measurement request message during the forwarding process. Each network element device that sends the measurement request message may generate the path record information. The source network element device, that is, the above start network element device or the first network element device, may be responsible for generating the delay record information. The delay record information of the measurement request message may be generated according to information related to the measurement request message and the measurement reply message. In the embodiments of the present application, no limitation is made to the information format of the path record information and the delay record information. The present embodiment provides an exemplary format of the path record information and the delay record information as follows:
It should be noted that each field included in the above path record information may be flexibly adjusted according to application requirements and may be increased or decreased, no limitation is made to these fields. Based on this, the source network element device (i.e., the first network element device or the start network element device) and other network element devices that receive the measurement request message may record at least one of the following information: ID of a tenant to which a network element itself belongs, detailed information of a network element itself, a second timestamp of receiving the measurement request message, and a third timestamp of forwarding the measurement request message, so as to generate the path record information.
In an optional embodiment, other network element devices that receive the measurement request message may generate one piece of path record information, and the GEN-TS field may include two timestamps, i.e., a second timestamp and a third timestamp. The second timestamp indicates the time point at which the measurement request message is received, and the third timestamp indicates the time point at which the measurement request message is forwarded. Alternatively, in another optional embodiment, other network element devices that receive the measurement request message may generate two pieces of path record information. That is, when the measurement request message is received, one piece of path record information is generated, and the GEN-TS field in this path record information records the second timestamp; when the measurement request message is forwarded, one piece of path record information is generated again, and the GEN-TS field in this path record information records the third timestamp.
Based on the above format of the delay record information, the source network element device may generate delay record information according to a first timestamp of sending a measurement request message and a fourth timestamp of receiving a measurement reply message. The source network element device may read the first timestamp from the measurement reply message and record the first timestamp into the delay record information; in addition, record the timestamp of receiving the measurement reply message as a fourth timestamp, and record the fourth timestamp into the delay record information.
After generating the path record information or the delay record information, the above source network element device and other network element devices may report this information to the measurement analysis subsystem 103. On the basis of the path record information and the delay record information, the measurement analysis subsystem 103 may perform network quality analysis from at least one dimension of path, tenant, and cloud network. Specifically, the measurement analysis subsystem 103 may analyze, according to the collected delay record information and path record information, at least one of the network delays of a path to be measured, the packet loss rate of a path to be measured, the network delay of a target tenant, the packet loss rate of a target tenant, the network delay of an entire cloud network, and the packet loss rate of an entire cloud network.
As shown in
The path record information generated by the source network element device or other network element devices is sent to the path analysis module 103a. The path analysis module 103a analyzes to obtain path record information of the same path to be measured according to the message ID in the measurement header of the path record information. That is, path record information containing the same message ID is the path record information of the same path to be measured. The path record information is classified from the path dimension, and pieces of path record information, obtained by classification, of different paths to be measured are provided to the packet loss statistics module 130b, respectively. For the path record information of each path to be measured, the packet loss statistics module 103b may analyze to obtain, in combination with the tenant ID and the IP of the network element device in the path record information, which network element devices that the measurement request message has passed, and may also analyze, further in combination with the reason for packet loss in the path record information, which network element devices drop packets and what is the reason for packet loss. Further according to these pieces of information, the packet loss statistics module may analyze to obtain the packet loss rates of different paths to be measured from the path dimension; further, in combination with the tenant ID, it may analyze to obtain paths to be measured corresponding to the same tenant. According to the packet loss rates of the paths to be measured corresponding to the same tenant, the packet loss statistics module may analyze to obtain the packet loss rate of the tenant network from the tenant dimension. Furthermore, it may also analyze to obtain, according to the packet loss rates of different tenant networks, the packet loss rate of the entire cloud network from the cloud network dimension. The packet loss statistics module 130b provides an obtained packet loss rate in each dimension to the result aggregation module 103d.
The delay record information generated by the source network element device is sent to the delay calculation module 103c. According to the message ID in the measurement header of the delay record information, the delay calculation module 103c may analyze to obtain delay record information of the same path to be measured. Further, according to the first timestamp and second timestamp in the delay record information, the delay calculation module may measure the network delay between the source network element device and different network element devices. Further, from the path dimension, the delay calculation module may analyze to obtain the network delay of the entire path to be measured. Furthermore, from the cloud network dimension, it may also analyze to obtain the network delay of the entire cloud network according to the network delay of different paths to be measured. The delay calculation module 130c provides an obtained packet loss rate from each dimension to the result aggregation module 103d.
Further, optionally, the path record information may also be sent to the delay calculation module 103c. The delay calculation module 103c may identify, in combination with information such as the message ID, network element IP in the path record information, pieces of path record information generated by a same network element device when receiving the measurement request message and forwarding the measurement request message. According to a second timestamp and a third timestamp recorded in the two pieces of path record information, the delay calculation module calculates the processing delay within a network element device, and provides the processing delay within the network element device to the result aggregation module 103d.
The result aggregation module 103d may summarize the packet loss rate from each dimension and the network delay from each dimension, perform network quality analysis according to network quality measurement requirements, and output a network quality analysis result. Optionally, as shown in
Using the measurement system of the embodiments of the present application, by perceiving the measurement intent of a tenant and performing network quality measurement based on the measurement intent, the tenant can be released from the network quality measurement. Compared with the solution in which the tenant actively measures the network quality, the embodiments of the present application avoid tenant's management of complex measurement rule and simplifies network quality measurement work. By applying a bypass packet injection method, there is no need to deploy measurement services in the tenant's network environment, which helps reduce intrusion into the tenant's network environment. In addition, the bypass packet injection method in the present embodiments is active packet injection, which can avoid the dependence on tenant's actual application traffic, and the network quality can be measured even in a case where the tenant does not generate any actual application traffic. Furthermore, the embodiments of the present application provide the standardized measurement request message, standardized measurement reply message, standardized path record information and standardized delay record information. Based on these standardized messages or information formats, a standardized network quality measurement protocol can be implemented. These standardized messages and information can not only carry information of virtual network elements, but also carry information of physical machines and tenants at the same time, thereby realizing the network quality measurement for a three-layer network of the physical network, overlay network and tenant network, which can support the full coverage of quality measurement for network end-to-end and intermediate nodes, with the ability to quickly locate network problems.
In the above embodiments, no limitation is made to the deployment implementation of a measurement system. In an optional embodiment, the measurement system may be independently deployed outside the cloud network and in communication connection with the network element devices in the cloud network, as shown in
The physical network 201 includes physical machines 201a such as servers, cabinets, routers, and switches, as well as physical connection lines 201b used to realize network connections between these physical machines, for example, coaxial cables, network cables, optical fibers, etc. In
In the embodiments of the present application, the network resources in the physical network 201 are virtualized using virtualization technology, thereby obtaining the virtual network 202 hosted on the physical network 201. As shown in
In an optional embodiment, as shown in
Further, as shown in
In the present embodiment, the scheduling device 203 perceives a measurement intent of a target tenant, generates a measurement rule that complies with the measurement intent, and delivers the measurement rule to a source network element device. The measurement rule includes a source end device and a destination end device on a path to be measured. The source network element device is any network element device 202b on the path to be measured. Regarding the detailed implementation of the scheduling device 203 perceiving the measurement intent of the target tenant and generating the measurement rule, please refer to the detailed implementation of the scheduling subsystem 101 perceiving the measurement intent and generating the measurement rule in the foregoing embodiments, to which no description is repeated here.
In the present embodiment, the source network element device is responsible for generating a measurement request message according to the measurement rule and forwarding the measurement request message. The measurement request message is used for enabling the source network element device and other network element devices on the path to be measured that receive the measurement request message to generate measurement record information. The source network element device may be any network element device on the path to be measured, which may be determined according to the measurement requirements. In an optional embodiment, the source network element device is a first network element device on the path to be measured which is directly connected to the source end device. In this case, the measurement request message is forwarded, starting from the first network element device to the target network element device. Similarly, in the embodiments of the present application, there is no limitation made to the target network element device. Optionally, the target network element device is a second network element device on the path to be measured which is directly connected to the destination end device.
In an optional embodiment, the implementation of the source network element device generating a measurement request message includes: generating a protocol header in the measurement request message according to information of the source end device and the destination end device; generating a measurement header in the measurement request message according to an identifier of the target tenant, detailed information of the source network element device, and a first timestamp; generating the measurement request message according to the protocol header and the measurement header, wherein the first timestamp indicates the time point at which the source network element device sends the measurement request message.
In addition to generating and sending the measurement request message, the source network element device or other network element devices further generate measurement record information. Further, optionally, the measurement record information includes path record information. Based on this, generating the measurement record information by the source network element device and other network element devices includes: recording at least one of the following information: an identifier of a tenant to which a network element itself belongs, detailed information of a network element itself, a second timestamp of receiving the measurement request message, and a third timestamp of forwarding the measurement request message, to generate the path record information. The path record information is reported to the analysis device 204 by the source network element device or other network element devices.
Further, after receiving the measurement request message, other network element devices may further generate a measurement reply message and return it to the source network element device. The measurement reply message includes a first timestamp from the measurement request message. Correspondingly, the source network element device is further configured for generating delay record information according to the first timestamp carried in the measurement reply message and a fourth timestamp of receiving the measurement reply message. The delay record information is reported to the analysis device 204 by the source network element device.
Regarding the detailed processes of generating the measurement request message and generating the path record information and delay record information, please refer to the description of the foregoing embodiments, to which no description is repeated here.
In the present embodiment, the analysis device 204 is configured for performing network quality analysis according to the measurement record information generated by the source network element device and other network element devices. Regarding the detailed implementation of the analysis device 204 performing network quality analysis according to the measurement record information, please refer to the detailed implementation of the measurement analysis subsystem 103 performing network quality analysis in the foregoing embodiments, to which no description is repeated here.
In the cloud network of the present embodiment, a scheduling device and an analysis device are added, and functions of network element devices in the virtual network are expanded, so that the cloud network may perceive the measurement intent of a tenant and perform network quality measurement based on the measurement intent. On one hand, the tenant can be released from the network quality measurement, which simplifies network quality measurement work. On the other hand, by applying a bypass packet injection method, there is no need to deploy measurement services in the tenant's network environment, which helps reduce intrusion into the tenant's network environment. In addition, using the bypass packet injection method can avoid the dependence on tenant's actual application traffic, and the network quality can be measured even in a case where the tenant does not generate any actual application traffic. Furthermore, in combination with the standardized message format and the standardized information format provided by the embodiments of the present application, messages and information in the cloud network can simultaneously carry information of virtual network elements, physical machines and tenants, which may realize network quality measurement for a three-layer network of the physical network, overlay network and tenant network, and can support the full coverage of quality measurement for network end-to-end and intermediate nodes, with the ability to quickly locate network problems.
It should be noted here that the cloud network of the present embodiment supports multi-tenants, does not limit the number of tenants, and supports tenants to deploy multiple applications. In addition, the present embodiment does not limit the link length of a cloud network, which can be flexibly deployed and adjusted according to application requirements. Further, the cloud network of the present embodiment has advantages of being easy to deploy and being able to be flexibly and widely deployed according to application requirements.
Furthermore, an embodiment of the present application further provides a network quality measurement method, which is applicable to, but is not limited to, the measurement system or cloud network provided by the above embodiments. As shown in
In an optional embodiment, above perceiving the measurement intent of the target user in the cloud network includes: generating network topology change information of the target tenant according to application requirement change information submitted by the target tenant; determining the measurement intent of the target tenant according to the network topology change information.
In an optional embodiment, above generating the measurement rule that complies with the measurement intent includes: determining the source end device and the destination end device on the path to be measured according to the measurement intent of the target tenant and network configuration information of the target tenant; generating the measurement rule according to the source end device and the destination end device on the path to be measured.
In an optional embodiment, the above determining the source end device and the destination end device on the path to be measured according to the measurement intent of the target tenant and the network configuration information of the target tenant includes: analyzing a source end device to be measured from the measurement intent of the target tenant; obtaining a potential path that has an access relationship with the source end device according to a network topology where the source end device is located, in combination with the network configuration information of the target tenant; determining a destination end device corresponding to the source end device from another end device on the potential path.
In an optional embodiment, above determining the destination end device corresponding to the source end device from the other end device on the potential path includes: determining the other end devices on all potential paths as the destination end device corresponding to the source end device, if the target tenant chooses a full coverage measurement method; selecting part of potential paths from all potential paths and determining the other end devices on the part of potential paths as the destination end device corresponding to the source end device, if the target tenant chooses a selective measurement method.
Further, optionally, the method of the present embodiment further includes: presenting a human-computer interaction interface to the target tenant, wherein a measurement method option is provided on the human-computer interaction interface for the target tenant to select; determining, in response to a selection operation initiated by the target tenant on the measurement method option, a measurement method selected by the target tenant, wherein the measurement method selected by the target tenant is a full coverage measurement method or a selective measurement method.
In an optional embodiment, above generating the measurement request message according to the measurement rule includes: generating a protocol header in the measurement request message according to information of the source end device and the destination end device; generating a measurement header in the measurement request message according to an identifier of the target tenant, detailed information of a first network element device, and a first timestamp; generating the measurement request message according to the protocol header and the measurement header, wherein the first timestamp indicates the time point at which the measurement request message is sent.
In an optional embodiment, above delivering the measurement request message into the path to be measured, so that at least part of network element devices on the path to be measured generate the measurement record information, includes: sending the measurement request message to a source network element device on the path to be measured, and forwarding the measurement request message, starting from the source network element device to other network element devices on the path to be measured, so that the source network element device and the other network element devices generate the measurement record information.
According to the deployment relationship between the method execution subject and the source network element device, the manner of delivering the measurement request message into the source network element device will be different. In an optional embodiment, a measurement execution subsystem may bypass each network element device in the cloud network, and the measurement execution subsystem generates a measurement request message and delivers it into a network element device that has a bypass relationship with this measurement execution subsystem. Based on this, delivering the measurement request message into the source network element device specifically refers to a process in which, after a measurement execution subsystem that has a bypass relationship with the source network element device generates a measurement request message, this measurement execution subsystem sends the measurement request message to the source network element device. In another optional embodiment, functions of each network element device in the cloud network may be expanded, so that each network element device has the function of generating a measurement request message according to a measurement rule. Based on this, delivering the measurement request message into the source network element device specifically refers to a process of generating a measurement request message by the source network element device based on the expanded message generation function.
In an optional embodiment, generating the measurement record information by the source network element device and other network element devices includes: recording at least one of the following information: an identifier of a tenant to which a network element itself belongs, detailed information of a network element itself, a second timestamp of receiving the measurement request message, and a third timestamp of forwarding the measurement request message, to generate path record information.
In an optional embodiment, generating the measurement record information by the source network element device further includes: receiving a measurement reply message send by other network element devices, the measurement reply message including the first timestamp; generating delay record information according to the first timestamp in the measurement reply message and a fourth timestamp of receiving the measurement reply message.
In an optional embodiment, above performing network quality analysis according to the measurement record information generated by at least part of network element devices includes: analyzing network delay and packet loss rate from at least one dimension of the path to be measured, the target tenant and the cloud network, according to the above delay record information and path record information.
In addition to the network quality measurement method as shown in
Optionally, the source network element device may be any network element device on the path to be measured, for example, it may be a first network element device on the path to be measured which is directly connected to the source end device.
Further, an embodiment of the present application also provides a message transmission method. This method is mainly described from the perspective of a network element device in a cloud network. As shown in
In the present embodiment, no limitation is made to the source and generation method of the measurement rule. Alternatively, the measurement rule may be generated using the method in the above embodiment.
Regarding the detailed description and explanation of each step of the above method embodiment, please refer to the foregoing system embodiment, to which no description is repeated here.
It should be noted that the execution subject of each step of the method provided by the above embodiments may be the same device, or different devices may be used as the execution subject of the method. For example, the execution subject of step 31a to step 33a may be device A. For another example, the execution subject of step 31a may be device A, while the execution subject of step 32a may be device B, and so on.
In addition, in some processes described in the above embodiments and drawings, multiple operations that occur in a specific order are included, but it should be clearly understood that these operations may be performed out of the order as stated herein or may be performed in parallel. The sequence number of operations, such as 31a, 32a, is only used to distinguish respective different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be performed sequentially or in parallel. It should be noted that descriptions such as “first” and “second” herein are used to distinguish different messages, devices, modules, etc., and do not represent the order, nor do they limit that “first” and “second” are different types.
The intent perception module 41 is configured for perceiving a measurement intent of a target tenant in a cloud network. The rule generation module 42 is configured for generating a measurement rule that complies with the measurement intent perceived by the intent perception module 41, the measurement rule including a source end device and a destination end device on a path to be measured. The message generation module 43 is configured for generating a measurement request message according to the measurement rule generated by the rule generation module 42. The message delivering module 44 is configured for delivering the measurement request message generated by the message generation module 43 into the path to be measured, so that at least part of network element devices on the path to be measured generate measurement record information. The quality analysis module 45 is configured for performing network quality analysis according to the measurement record information generated by the at least part of network element devices.
In an optional embodiment, the intent perception module 41 is specifically configured for: generating network topology change information of the target tenant according to application requirement change information submitted by the target tenant; determining the measurement intent of the target tenant according to the network topology change information.
In an optional embodiment, the rule generation module 42 is specifically configured for: determining the source end device and the destination end device on the path to be measured according to the measurement intent of the target tenant and network configuration information of the target tenant; generating the measurement rule according to the source end device and the destination end device on the path to be measured.
Further, optionally, when determining the source end device and the destination end device on the path to be measured, the rule generation module 42 is specifically configured for: analyzing a source end device to be measured from the measurement intent of the target tenant; obtaining a potential path that has an access relationship with the source end device according to a network topology where the source end device is located, in combination with the network configuration information of the target tenant; determining a destination end device corresponding to the source end device from another end device on the potential path.
Furthermore, when determining the destination end device corresponding to the source end device, the rule generation module 42 is specifically configured for: determining the other end devices on all potential paths as the destination end device corresponding to the source end device, if the target tenant chooses a full coverage measurement method; selecting part of potential paths from all potential paths and determining the other end devices on the part of potential paths as the destination end device corresponding to the source end device, if the target tenant chooses a selective measurement method.
In an optional embodiment, as shown in
In an optional embodiment, the message injection module 44 is specifically configured for: sending the measurement request message to a source network element device on the path to be measured, and forwarding the measurement request message, starting from the source network element device to other network element devices on the path to be measured, so that the source network element device and the other network element devices generate the measurement record information.
In an optional embodiment, the message generation module 43 is specifically configured for: generating a protocol header in the measurement request message according to information of the source end device and the destination end device; generating a measurement header in the measurement request message according to an identifier of the target tenant, detailed information of a source network element device, and a first timestamp; generating the measurement request message according to the protocol header and the measurement header, wherein the first timestamp indicates the time point at which the measurement request message is sent.
It should be noted here that the network quality measurement apparatus of the present embodiment may be implemented by distributing and deploying in the cloud network. Specifically, the intent perception module 41, the rule generation module 42 and the quality analysis module 45 may be independently deployed in the cloud network, while the message generation module 43 and the message injection module 44 may be implemented by deploying in a network element device in the cloud network. Further, optionally, in a case where the message generation module 43 and the message injection module 44 are implemented by deploying in a network element device, the message generation module 43 and the message injection module 44 may be implemented as one module.
In a case where the message generation module 43 and the message injection module 44 are implemented by deploying in a source network element device, the message generation module 43 or the message injection module 44 are further configured for generating measurement record information. Specifically, the message generation module 43 or the message injection module 44 record at least one of the following information: an identifier of a tenant to which a network element itself belongs, detailed information of a network element itself, a second timestamp of receiving the measurement request message, and a third timestamp of forwarding the measurement request message, to generate the path record information.
Further, optionally, the message generation module 43 or the message delivering module 44 may also receive a measurement reply message sent by other network element devices, the measurement reply message including a first timestamp; and generate delay record information according to the first timestamp in the measurement reply message and a fourth timestamp of receiving the measurement reply message.
In an optional embodiment, the quality analysis module 45 is specifically configured for: analyzing network delay and packet loss rate from at least one dimension of the path to be measured, the target tenant and the cloud network, according to the above delay record information and path record information.
The internal functions and structure of the network quality measurement apparatus are described above, as shown in
The memory 51 is configured for storing computer programs and may be configured for storing various other data to support operations on the cloud computing device. Examples of such data include instructions, messages, pictures, videos, etc. of any application or method operated on the cloud computing device.
The processor 52, coupled to the memory 51, is configured for executing the computer programs in the memory 51, to: perceive a measurement intent of a target user in a cloud network and generate a measurement rule that complies with the measurement intent, the measurement rule including a source end device and a destination end device on a path to be measured; generate a measurement request message according to the measurement rule, and deliver the measurement request message into the path to be measured, so that at least part of network element devices on the path to be measured generate measurement record information; perform network quality analysis according to the measurement record information generated by the at least part of network element devices.
In an optional embodiment, when perceiving the measurement intent, the processor 52 is specifically configured for: generating network topology change information of the target tenant according to application requirement change information submitted by the target tenant; determining the measurement intent of the target tenant according to the network topology change information.
In an optional embodiment, when generating the measurement rule, the processor 52 is specifically configured for: determining the source end device and the destination end device on the path to be measured according to the measurement intent of the target tenant and network configuration information of the target tenant; generating the measurement rule according to the source end device and the destination end device on the path to be measured.
Further, optionally, when determining the source end device and the destination end device on the path to be measured, the processor 52 is specifically configured for: analyzing a source end device to be measured from the measurement intent of the target tenant; obtaining a potential path that has an access relationship with the source end device according to a network topology where the source end device is located, in combination with the network configuration information of the target tenant; determining a destination end device corresponding to the source end device from another end device on the potential path.
Furthermore, when determining the destination end device corresponding to the source end device, the processor 52 is specifically configured for: determining the other end devices on all potential paths as the destination end device corresponding to the source end device, if the target tenant chooses a full coverage measurement method; selecting part of potential paths from all potential paths and determining the other end devices on the part of potential paths as the destination end device corresponding to the source end device, if the target tenant chooses a selective measurement method.
In an optional embodiment, the processor 52 is further configured for: presenting a human-computer interaction interface to the target tenant, wherein a measurement method option is provided on the human-computer interaction interface for the target tenant to select; determining, in response to a selection operation initiated by the target tenant on the measurement method option, a measurement method selected by the target tenant, wherein the measurement method selected by the target tenant is a full coverage measurement method or a selective measurement method.
In an optional embodiment, when delivering the measurement request message into the path to be measured, the processor 52 is specifically configured for: sending the measurement request message to a source network element device on the path to be measured, and forwarding the measurement request message, starting from the source network element device to other network element devices on the path to be measured, so that the source network element device and the other network element devices generate the measurement record information.
In an optional embodiment, when generating the measurement request message, the processor 52 is specifically configured for: generating a protocol header in the measurement request message according to information of the source end device and the destination end device; generating a measurement header in the measurement request message according to an identifier of the target tenant, detailed information of a source network element device, and a first timestamp; generating the measurement request message according to the protocol header and the measurement header, wherein the first timestamp indicates a time point at which the measurement request message is sent.
It should be noted here that the cloud computing device of the present embodiment may be implemented by distributing and deploying in the cloud network. Specifically, functions of generation and injection of a measurement message may be implemented by distributing and deploying in a network element device in the cloud network. Based on this, the processor 52 is further configured for generating measurement record information. The processor 52 is specifically configured for recording at least one of the following information: an identifier of a tenant to which a network element itself belongs, detailed information of a network element itself, a second timestamp of receiving the measurement request message, and a third timestamp of forwarding the measurement request message, to generate path record information.
Further, optionally, for the source network element device, the processor 52 is configured for: receiving a measurement reply message sent by other network element devices, the measurement reply message including a first timestamp; and generating delay record information according to the first timestamp in the measurement reply message and a fourth timestamp of receiving the measurement reply message.
In an optional embodiment, when performing the network quality analysis, the processor 52 is specifically configured for: analyzing network delay and packet loss rate from at least one dimension of the path to be measured, the target tenant and the cloud network, according to the above delay record information and path record information.
Further, as shown in
Correspondingly, an embodiment of the present application further provides a computer-readable storage medium storing computer programs. The computer programs, when executed by a processor, enable the processor to implement each step in the above method embodiments.
Correspondingly, an embodiment of the present application further provides a computer program product, including computer programs/instructions. The computer programs/instructions, when executed by a processor, enable the processor to implement each step in the above method embodiment.
The memory in above embodiments may be implemented by any type of volatile or non-volatile storage device or their combination, such as a static random-access memory (SRAM), an electrically erasable programmable read only memory (EEPROM), an erasable programmable read only memory (EPROM), a programmable read only memory (PROM), a read only memory (ROM), a magnetic memory, a flash memory, a magnetic disk or an optical disk.
The communication component in above embodiments is configured to facilitate wired or wireless communication between a device where the communication component is located and other devices. The device where the communication component is located may access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G/LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component further includes a near field communication (NFC) module to facilitate short range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wide band (UWB) technology, Bluetooth (BT) technology and other technologies.
The power supply component in above embodiments provides power for various components of a device where the power supply component is located. The power component may include a power supply management system, one or more power supplies, and other components associated with generating, managing, and distributing power to a device where the power component is located.
Those skilled in the art should understand that embodiments of the present application may be provided as a method, a system, or a computer program product. Accordingly, the present application may take the form of an entire hardware embodiment, an entire software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied in one or more computer-usable storage medium (including, but not limited to, a disk storage, a CD-ROM, an optical storage, etc.) including computer-usable program codes therein.
The present application is described with reference to flowcharts and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each process and/or each block in a flowchart and/or a block diagram, and a combination of processes and/or blocks in a flowchart and/or a block diagram may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special purpose computer, an embedded processor, or other programmable data processing devices to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices produce an apparatus used for realizing functions specified in one or more processes in a flowchart and/or one or more blocks in a block diagram.
These computer program instructions may also be stored in a computer-readable memory that can guide a computer or other programmable data processing devices to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture that includes an instruction apparatus. Such instruction apparatus implements the functions specified in one or more processes in a flowchart and/or one or more blocks in a block diagram.
These computer program instructions may also be loaded into a computer or other programmable data processing devices, so that a series of operations and steps are executed in the computer or other programmable devices to produce computer-implemented processing, so that the instructions executed in the computer or other programmable devices provide steps for implementing the functions specified in one or more processes in a flowchart and/or one or more blocks in a block diagram.
In a typical configuration, a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and a memory.
The memory may include a non-permanent memory, a random-access memory (RAM), and/or a non-volatile memory in a computer-readable medium, such as a read only memory (ROM) or a flash memory (flash RAM). Memory is an example of the computer-readable medium.
The computer-readable medium includes a permanent or non-permanent, removable or non-removable media that may implement information storage by any method or technology. Information may be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage medium include, but are not limited to, a phase change memory (PRAM), a static random-access memory (SRAM), a dynamic random-access memory (DRAM), other types of random-access memory (RAM), a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a flash memory or other memory technologies, a compact disc read only memory (CD-ROM), a digital versatile disc (DVD) or other optical storage, a cassette tape, a magnetic tape magnetic disk storage or other magnetic storage device or any other non-transmission medium, which may be used to store information that can be accessed by a computing device. As defined herein, the computer-readable medium does not include a transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.
It should also be noted that terms “including”, “containing” or any other variants thereof are intended to cover a non-exclusive inclusion, so that a process, method, article, or device that includes a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also include elements that are inherent to this process, method, article, or device. Without more restrictions, an element defined by a sentence “including a . . . ” does not exclude the existence of other identical elements in a process, method, article, or device that includes such an element.
The above described are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and variations may be made to the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present application shall be included in the scope of claims of the present application.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202110496812.X | May 2021 | CN | national |
The present invention is filed under 35 U.S.C. § 371 as the U.S. national phase of International Patent Application No. PCT/CN2022/090914, filed May 5, 2022, which designated the United States and which claims the benefit of Chinese Patent Application No. 202110496812.X, filed on May 7, 2021, which is incorporated herein by reference in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2022/090914 | 5/5/2022 | WO |
