CN110971439A

CN110971439A - Policy decision method and device, system, storage medium, policy decision unit and cluster

Info

Publication number: CN110971439A
Application number: CN201811162422.3A
Authority: CN
Inventors: 王薪渊; 肖雷
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2018-09-30
Filing date: 2018-09-30
Publication date: 2020-04-07
Also published as: WO2020063550A1

Abstract

A policy decision method, a policy decision device, a policy decision system, a storage medium, a policy decision unit and a cluster are provided. The policy decision unit comprises a policy engine module and a time theme manager, wherein the policy engine module is used for creating a policy engine, and at least the following operations are realized by using the policy engine: loading a policy rule, and triggering a corresponding policy action according to the policy rule matched with the event when receiving the event sent by the event theme manager; and the event theme manager monitors an event according to the policy rule, and sends the event to the policy engine corresponding to the event when receiving the monitored event. The scheme provided by the embodiment provides an independent policy decision unit, does not need to distinguish a target network element to which the policy rule is to be issued, and improves the policy execution efficiency.

Description

Policy decision method and device, system, storage medium, policy decision unit and cluster

Technical Field

The present invention relates to, but not limited to, the field of communications, and in particular, but not limited to, a policy decision method and apparatus, a computer-readable storage medium, a policy decision unit, a policy decision cluster, and a network management system.

Background

The telecommunication industry continues to use a vertical integration architecture on the network architecture of a network management system, and the service and network construction is a chimney group mode, so that the development and marketing period of new services is long. Compared with IT manufacturers, the operation and maintenance cost is high, and the automation operation and maintenance is difficult. With the redefinition of a Network architecture based on the SDN (Software Defined Network) concept of 5G (5th Generation, fifth Generation), Network functions of various levels are flexibly realized by quickly deploying and organizing physical resources as required through Network functions and node virtualization and then realizing Network deployment as required on the basis of the Network virtualization.

Disclosure of Invention

In view of this, embodiments of the present invention provide a policy decision method, a policy decision device, a policy decision system, a storage medium, a policy decision unit, and a cluster.

At least one embodiment of the present invention provides a policy decision unit, including a policy engine module and an event topic manager, where:

the policy engine module is configured to create a policy engine, and to use the policy engine to implement at least the following operations: loading a policy rule, and triggering a corresponding policy action according to the policy rule matched with the event when receiving the event sent by the event theme manager;

the event theme manager is used for monitoring events according to the policy rules, and sending the events to the policy engine corresponding to the events when receiving the monitored events.

At least one embodiment of the present invention provides a policy decision cluster, which includes at least one policy decision unit described in any one of the embodiments.

At least one embodiment of the present invention provides a policy decision method, including:

the strategy decision unit creates a strategy engine and loads strategy rules by using the strategy engine;

the strategy decision unit monitors events according to the strategy rules, and when the monitored events are received, the events are sent to the strategy engine, and the strategy engine triggers corresponding strategy actions according to the strategy rules matched with the events.

At least one embodiment of the present invention provides a policy decision device, including a memory and a processor, where the memory stores a program, and the program, when read and executed by the processor, implements the policy decision method according to any one of the embodiments.

At least one embodiment of the invention provides a computer readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement a policy decision method as described in any of the embodiments.

At least one embodiment of the present invention provides a network management system, including a network function virtualization NFV orchestrator, a virtualized network function manager, and a virtualized infrastructure management, and is characterized by further including: the policy decision cluster is managed independently of the NFV orchestrator, the virtualized network function manager, and the virtualized base device.

At least one embodiment of the present invention provides an independent PDP, and the PDP uniformly processes the policy rule without distinguishing a target network element (directly issued to the PDP) to which the policy rule is to be issued, thereby improving policy execution efficiency.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the example serve to explain the principles of the invention and not to limit the invention.

FIG. 1 is a diagram of a network architecture;

FIG. 2 is a diagram of a MANO (Management and organization) network architecture (including policy components) according to an embodiment of the present invention;

FIG. 3 is a general architecture diagram of a policy component provided in accordance with an embodiment of the present invention;

FIG. 4 is a Network architecture diagram of an NFV (Network Function Virtualization) MANO according to another embodiment of the present invention;

FIG. 5 is a flowchart of policy rule file loading according to an embodiment of the present invention;

FIG. 6a is a block diagram of a policy decision unit according to an embodiment of the present invention;

FIG. 6b is a block diagram of a policy decision unit according to another embodiment of the present invention;

FIG. 7 is a flowchart of a policy decision method according to an embodiment of the present invention;

FIG. 8 is a block diagram of a policy decision cluster architecture according to an embodiment of the present invention;

fig. 9 is a timing diagram illustrating a capacity expansion process of a policy-based VNF (virtual network function), according to an embodiment of the present invention;

FIG. 10 is a timing diagram illustrating a policy-based VNF capacity reduction according to an embodiment of the present invention;

fig. 11 is a structural diagram of an intelligent VNF fault self-healing according to an embodiment of the present invention;

FIG. 12 is a block diagram of a policy decision device according to an embodiment of the present invention;

FIG. 13 is a block diagram of a computer-readable storage medium provided by an embodiment of the invention;

fig. 14 is a block diagram of a network management system according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.

A standard architecture, such as the MANO architecture, will be described. As shown in fig. 1, the MANO architecture includes NFVO (NFV orchestrator) 101, VNFM (Virtualized Network Function Manager) 102, VIM (Virtualized Infrastructure management) 103, and the functions are described as follows:

the NFVO101 is an orchestrator of the NFV system, and is responsible for management of network services and global resource management of the NFV. The NFVO101 composes a Network service by arranging different VNFs (Virtualized Network Functions) 104 or VNFs 104 and PNFs (Physical Network Functions), and manages association and mapping relationships between the VNFs 104 and NFVI (Network Functions Virtualization Infrastructure) 105 resources. The deployment or operation and maintenance operation of the NFVO101 is performed based on an NS (Network Service) template. NFVO101 is generally neutral to the logical functions provided by the NS it manages/orchestrates, and the NS instantiated by the NFVO is generally not involved in the configuration of the logical functions. In the network service life cycle management process, the NFVO101 may monitor a Key Performance Indicator (KPI) of a network, and manage and adjust network services according to the KPI. One NFVO101 may manage multiple VNFMs 102 and multiple VIMs 103 simultaneously.

VNFM102 management includes traditional fault management, configuration management, billing management, performance management, and security management (FCAPS), and VNFM102 focuses on end-to-end lifecycle management for installing, initializing, running, scaling, upgrading, and taking the VNF offline on decoupled virtual resources. In the VNF life management process, the VNFM102 may monitor the VNF KPI and perform capacity expansion and contraction according to the KPI indicators. The VNFM102 is independent of the logical functions provided by the VNF it manages/orchestrates, and management of the VNFM for instantiated VNFs typically does not involve configuration of the logical functions. Most VNFM functions are common functions and are applicable to any type of VNF. However, the NFV MANO architecture also requires customization functionality to support VNF instance lifecycle management needs, which can be published as part of the VNF service package. Each VNF instance has a VNFM102 associated with it; one VNFM102 may be responsible for managing one single VNF instance, or multiple VNF instances of the same or different types.

The VIM103 is a virtual infrastructure manager responsible for controlling and managing the computing, storage, and network resources contained by the NFVI105 and provides to the VNFM102 and NFVO101 for scheduled use. One VIM103 may be designated to manage a particular type of NFVI resource (e.g., only compute/storage/network resources), or may manage multiple NFVI resources.

Fig. 1 also includes an OSS (Operation Support System)/BSS (Business Support System) 106 and an EM (Element Management) 107. The OSS is a support system for integration and information resource sharing of a telecommunication operator, and is mainly used for services such as network management, system management, charging, business, accounting, and customer service, and the BSS is also a support system for integration and information resource sharing of a telecommunication operator, and is mainly used for services such as customer relationship management, service supply chain management, and business decision support. EM107 may be used to perform traditional FCAPS functions for VNFs.

FIG. 2 is a diagram of a MANO architecture according to an embodiment of the present invention. Mainly on the basis of the original network architecture of the MANO, the strategy architecture is expanded and improved, in one scheme, the strategy Decision and the strategy execution are realized by NFVO/VNFM/VIM, and in the embodiment, the strategy Decision function in the strategy architecture is stripped from the NFVO/VNFM/VIM, and an independent PDP (Policy Decision Point) is arranged to realize the strategy Decision. As shown in fig. 2 and 3, Policy 201 includes PLCM (Policy Life Cycle Management) 301, PDP (Policy decision unit) 302, PEP (Policy Enforcement Point) 303, and PR (Policy Repository) 304, where:

the PLCM301 is mainly used for full-life-cycle management of policies, including loading of policy templates and addition, deletion, modification, querying, starting, stopping and suspension of policy rules, policy task management, template management, policy query service, and conflict confusion detection and resolution. Specifically, the method receives the policy parameters and the template information, generates a policy rule file, stores the policy rule file in the PR304, and sends description information of the policy rule file to the PDP 302. The description information of the policy rule file includes at least one of: file name, file description information, event subject information and resource warehousing coordinates. Wherein the policy rule file contains one or more policy rules. The basic model of the policy rule is ECA (Events-event, Condition-Condition, Action-Action), that is, the policy rule includes a policy event, a policy Condition and a policy Action, and when the policy event occurs and meets the policy Condition, the corresponding policy Action is executed.

The PDP302 is a decision center of the entire system, and is responsible for receiving the policy operation request, making a decision according to the policy information, and then allocating a corresponding execution action to the PEP to meet the management requirement. Specifically, the PDP302 receives a policy operation request sent by the PLCM301, generates a policy engine, acquires a policy rule file from the PR304 according to description information of the policy rule file carried in the policy operation request, parses the policy rule file to obtain a policy rule, loads the policy rule, monitors an event defined in the policy rule, receives the monitored event, and triggers a corresponding policy action according to the policy rule matched by the event when the event is matched with the policy rule (that is, meets a policy condition). It should be noted that the PDP302 is not limited to acquiring the policy rule file from the PR304, and may also acquire the policy rule file directly from the PLCM301, or acquire the policy rule file from another module, or generate the policy rule file or the policy rule by the PDP302 itself, or the like.

The PEP303 is a network entity that accepts the policy action of the PDP302, and is an execution entity of the policy, i.e. a response topic of the action. It may also forward information to the PDP to make it aware of changes in network or device conditions. PEP303 may be any one or more of NFVO, VNFM, VIM. The PEP includes a plurality of management resources, and the resource types of the PEP may include Cloud, Network, and VNF, that is, software and hardware resources on all Network nodes, but each resource is required to provide an external access capability, and the capability interface is registered, so that when the policy rule file is designed, the policy design can be performed on the interface so as to achieve an execution result required by a user, and then a corresponding policy template or a specific policy execution package is generated and issued.

The PR304 is used for storing a policy rule file, and may also store a resource classification business rule package, and version control of business rules and process models, and the like.

In the solution provided in this embodiment, the PDP and the PEP are separated, an independent PDP is provided, and the PDP uniformly processes the policy rules, and compared with a solution in which NFVO/VNFM/VIM serves as the PDP and the PEP, in this embodiment, it is not necessary to distinguish a target network element (selected from NFVO/VNFM/VIM) to which the policy rules are to be issued, and the policy execution efficiency is improved.

The system further includes an OSS/BSS205, an EM206, a VNF207, and an NFVI208, and the functions thereof are described with reference to corresponding blocks in fig. 1, and are not described herein again. In an embodiment, the PDP302 may be one or more, i.e. form a PDP cluster. The plurality of PDPs 302 are distributed. With the increase of management nodes or resources in the system, there are thousands of policy rules, which can cause performance bottleneck problem and single node failure problem, so the PDP is deployed in a multi-node manner. The number of PDPs is determined according to the traffic size, such as the cell size, or the number of VNF nodes. Through the cluster type deployment of the PDPs, compared with the implementation mode of only a single PDP, the method can realize the quick response of concurrent and high-capacity external module requests, and improve the efficiency and stability of policy decision execution.

In FIG. 3, the policy designer is, for example, VNF, NFVO, etc.

In one embodiment, as shown in FIG. 4, PEP303 is acted upon by NFVO/VNFM/VIM, with PLCM301, PDP302, and PR304 being included in policy component 201.

As shown in fig. 5, a flowchart for loading a policy rule file includes:

step 501, receiving an operation request of an OSS/BSS or NFVO by a PLCM, wherein the operation request comprises a policy parameter and template information;

step 502, the PLCM verifies the policy parameters, generates a policy rule file according to the policy parameters and the template information, and stores the policy rule file in a policy repository;

step 503, the PLCM generates a policy operation request, where the policy operation request carries description information of a policy rule file; the description information of the policy rule file includes at least one of: file name, file description information, event subject information and resource warehousing coordinates.

It should be noted that, the PLCM may also modify, delete, etc. the policy rule file in the policy repository, and then generate the policy operation request.

Step 504, the PLCM sends the policy operation request to a PDP;

step 505, after receiving the policy operation request, the PDP acquires a policy rule file from the policy repository according to the resource repository coordinates in the description information of the policy rule file in the policy operation request, analyzes the policy rule file to acquire a policy rule, and forms a policy rule tree in the memory; and registering and monitoring the event according to the event in the strategy rule.

The PDP is used as a decision center of the policy system and is responsible for performing policy decision work for a policy operation request of an external module, specifically, the PDP receives the policy operation request of the external module, searches a relevant policy rule file matching the policy operation request in a published policy rule base, loads the successfully matched policy rule file into the PEP, and transmits specific execution to the PEP according to policy actions in the policy rule, so that the PEP executes relevant operations.

FIG. 6a is a diagram of a PDP according to an embodiment of the present invention. As shown in fig. 6a, the PDP includes a policy engine module 601 and an event topic manager 602, as well as external interfaces. Wherein:

the policy engine module 601 is used to create a policy engine, and implement the following operations using the policy engine: loading a policy rule and triggering a corresponding policy action according to the policy rule matched with the event when receiving the event sent by the event theme manager; and also for managing the life cycle of the policy engine;

the event topic manager 602 is configured to monitor an event according to a policy rule, and when an event is received, send the event to a policy engine corresponding to the event. It should be noted that, when an event is sent to an event topic, the event topic can be monitored to achieve the purpose of monitoring the event. The policy rules include events, conditions, and actions, and therefore, an event has a corresponding policy rule, and a policy engine corresponding to the event is a policy engine that loads the policy rule corresponding to the event.

Also included in fig. 6a are a plurality of interfaces: PDP management interface 603 (resources of PDP node), theme management interface 604, and engine management interface 605 (policy rules file). The PDP management interface 603 is configured to manage resources of a PDP node, the theme management interface 604 is configured to monitor an event, receive an event, and the like, the engine management interface 605 is configured to transmit information related to a policy engine, for example, receive a policy operation request, receive a policy rule file, and the like, and the message middleware 606 in fig. 6a is a message forwarding unit when a policy action is triggered to send a message to a PEP.

The basic mechanisms of the policy engine are: and retrieving the currently submitted event, matching the currently submitted event with the loaded policy rule according to the current attribute values of the data objects in the event and the relationship between the current attribute values and the data objects, finding out the matched policy rule (meeting the policy condition), and triggering the corresponding operation according to the Action declared in the policy. When the policy rule file in the policy repository changes, the policy engine needs to update in time according to the policy rule file.

The policy engine and the policy rules are in a one-to-many relationship, that is, one policy engine can load multiple policy rules. The PDP and the policy engine are in a one-to-many relationship, i.e. multiple policy engines can be created in one PDP. Of course, the policy engine and policy rules, the policy engine and the PDP may also be one-to-one.

In one embodiment, the policy engine module 601 creating a policy engine includes: and receiving a policy operation request sent by policy life cycle management, and creating a policy engine.

In one embodiment, the loading policy rules includes: and acquiring a policy rule file from a policy repository according to the description information of the policy rule file carried in the policy operation request, and analyzing the policy rule file to acquire the policy rule. It should be noted that the policy rule may not be acquired from the policy repository, for example, when the policy rule is carried in the policy operation request, the policy rule is directly loaded. Alternatively, the PDP itself generates policy rules and loads them, etc.

As shown in fig. 6b, in an embodiment, the PDP further includes a cluster management module 607 and a communication interface 608, and the cluster management module 607 is configured to, when the PDP is a management node of a policy decision cluster, determine whether a PDP in the policy decision cluster can be used as a backup PDP for other PDPs, and, when a PDP in the policy decision cluster is unavailable, replace the unavailable PDP with the backup PDP.

If it can be used as a backup PDP, the status is recorded as cold backup status, and if it cannot be used as a backup PDP, the status is recorded as hot backup status, which is only an example, and other information may be used to indicate whether it can be used as a backup PDP. Wherein, the determination of whether to be available as a backup PDP may be determined according to performance and load (cpu load rate, memory occupancy, etc.) of the PDP, and the like. The status information may be recorded in a status management entity table (StateManagementEntity) shared by PDPs. The communication interface 608 is used for interaction between PDPs.

In an embodiment, the cluster management module 607 is further configured to periodically elect a management node that determines a policy decision cluster.

The algorithm for electing the management node can be determined as required, and the method is not limited in the application. For example, the PDP having the lowest dictionary value (dictionary value, i.e., the order in the dictionary, the dictionary order is a, b, c …, and the corresponding dictionary values are sequentially increased, in this embodiment, the dictionary value of the initial letter identified by the PDP is used) is selected as the management node. Here, only an example, other election algorithm inxS elections may be used.

In addition, when there are a plurality of policy language PDPs, one management node may be selected for each policy language PDP. That is, a plurality of management nodes may be selected, each managing a PDP of the same policy language. It should be noted that this is merely an example, and only one management node may be selected.

Wherein, the election period can be set according to the requirement. Alternatively, instead of periodic elections, elections may be performed when triggered, or when a user instruction is received. In addition, a management node may be directly designated, and the like. It should be noted that, management nodes may not be elected in the policy decision cluster, and other cluster management methods are used for management, which is not limited in the present application. For example, a policy decision cluster is managed using a highly reliable server, and so on.

In one embodiment, the periodically electing a management node that determines a policy decision cluster includes: and periodically electing and determining a management node of the policy decision cluster according to information in a management entity table, wherein the management entity table comprises at least one of the following: the identification, resource name, management state, available state, active/standby state, and creation and modification time information of the policy decision unit.

As shown in fig. 7, an embodiment of the present invention provides a policy decision method, including:

step 701, the PDP creates a policy engine, and the policy engine is used to actually load policy rules;

step 702, the PDP monitors events according to the policy rules, and when receiving the monitored events, sends the events to the policy engine, and the policy engine triggers corresponding policy actions according to the policy rules matched to the events.

In one embodiment, the create policy engine comprises: and receiving a policy operation request sent by policy life cycle management, and creating a policy engine. It should be noted that the policy engine may also be created after receiving a policy operation request from another module. For example, a policy operation request of the NFVO is received.

In one embodiment, the loading policy rules includes: and acquiring a policy rule file from a policy repository according to the description information of the policy rule file carried in the policy operation request, and analyzing the policy rule file to acquire the policy rule.

In an embodiment, the event includes a policy action triggered when other policy decision units match the policy rule.

In an embodiment, the method further comprises, when the PDP is a management node of a policy decision cluster, determining whether the PDP in the policy decision cluster can serve as a backup PDP for other PDPs, and, when the PDP in the policy decision cluster is unavailable, replacing the unavailable PDP with the backup PDP.

In an embodiment, the PDP further includes determining a management node of the policy decision cluster by periodic election according to information in the shared management entity table.

In one embodiment, the management entity table includes at least one of: the identification, resource name, management state, available state, active/standby state, and creation and modification time information of the policy decision unit.

As shown in fig. 8, an embodiment of the present invention provides a policy decision cluster 80, which includes at least one PDP302 described in the above embodiments. Communication interfaces exist among PDPs in the strategy decision cluster, and communication is carried out based on a PDP communication protocol. The strategy rules are distributed in a plurality of PDPs, the same event is monitored to realize the association of the strategy, and the association of the strategy Action is realized through a PDP communication interface. In the related art, the application of the NFV MANO policy is based on the fact that the policies are separated from each other, and no policy association exists. In at least one embodiment of the present application, policy association triggering is implemented through a PDP communication interface, thereby improving decision efficiency.

The strategy can be written in multiple languages, so that if the cross-language strategy execution is required, the cooperation is completed by a message mode aiming at the cross-strategy language type strategy execution bodies; in addition, among the PDPs in the same policy language, scheduling is executed in a message mode according to indexes such as actual cpu load rate, memory occupancy rate and the like.

The PDP communication protocol is a protocol for communicating with each other to manage status and deployment, and the purpose of the interface is mainly to perform cooperative processing between PDPs and complete the associated operation of policies, so as to solve the associated cooperative flow between different policies.

The communication interface between the PDPs comprises at least one of: Intra-PDP Interface and Inter-PDP Interface. Inter-PDP Interface, i.e., Inter-PDP protocol, is a protocol by which instances of any PDP type may communicate with each other to manage state and deployment; the Intra-PDP Interface, i.e., the inter-PDP protocol, is a protocol for the same type of PDPs to communicate with each other to manage state and deployment.

In this embodiment, a state management entity table (StateManagementEntity) is provided, in which at least one of the following is stored: an identification of the PDP (e.g., IP of the PDP), a resource name (i.e., a name of the PDP, such as one displayed to a user for viewing), a management status (i.e., whether the PDP is a management node), an available status, a master/slave status, and creation modification time information. The available state indicates whether the PDP is available, the accessed PDP is the available state, the unaccessed PDP is the unavailable state, and the active and standby state indicates whether the PDP can be used as a standby PDP of other PDPs, wherein the PDP cannot be used as the standby PDP in the hotspot status, and the PDP can be used as the standby PDP in the coldstandby status. The meaning of a backup PDP is that when there is a PDP failure, the function it performs can be replaced by the backup PDP. Such as the backup PDP being loaded with data on the failed PDP (from a database shared by the PDPs). The creation modification time information is the creation modification time of the piece of information. All PDPs share the management entity table and periodically update the state information (management state, available state, active/standby state) in the management entity table.

The election algorithm is run periodically by all PDPs in the PDP cluster (of course, the election algorithm may be run after being triggered), and since each PDP uses the same data (data in the shared state management entity table), all PDPs elect the same management node. The management state of the selected PDP is updated to an active state (or a service providing state, and a node in the state is a management node in the cluster). Thus, the algorithm is distributed without a single point of failure, assuming the database is configured for high availability.

In this embodiment, a shared PDP entity table (PdpEntity) is also provided, and the PdpEntity table records whether the election algorithm of the node is currently running and the time when the node is finally designated as the management node.

Generally, the status of all PDPs is collected periodically. Each node reads the standbystatus (i.e., status information) of all other nodes from the StateManagementEntity table. For the PDP running the election algorithm, no action is required if the PDP is currently elected as a management node and is already a management node before electing. If the current selected node is a management node and the current selected node is not a management node before the selection, modifying the state of the PDP into an active state; if not elected as a management node, no action is performed. Initially, the PDP may be set to the hotspot status (for example only, other statuses are also possible). If the selected PDP is self, it will change from the hotspot status to the active status. If the selected PDP is not itself, it will do nothing. When the PDP is promoted from the hotspot status to the active status, a status change notification will occur and the status change handler will take appropriate action.

In at least one embodiment of the invention, a shared policy module is constructed between the OSS/BSS and the MANO, the policy decision units are separately provided by separating the policy decision units from the policy execution points, the policy decision units are deployed in a cluster mode, and a communication protocol is provided between the policy decision units, so that the problem of policy transition between 3/4G and 5G at present is better realized, the management of the original network equipment is well compatible, and the policy execution efficiency of NFVO is improved.

The application is further illustrated by the following specific application examples.

Policy-based VNF capacity expansion for application instance 1

The network service Auto-scaling policy (NS Auto-scaling policy) is provided by the VNF (i.e. the VNF acts as a designer) and is executed by the VNFM (as a PEP). A policy designer (namely VNF) designs an automatic capacity expansion policy, binds a given type of VNF through a PLCM, packages the VNF in policy information, and issues the policy information to a PDP. An example of an automatic capacity expansion policy may contain the following information:

and if the change of the first index value of the VNF is detected, carrying out VNF instance capacity expansion according to a given action. The first index value may be set as needed, and the present application does not limit this.

The PDP acquires the first indicator information from the analyzer, matches the first indicator information with a current capacity expansion policy, and uses the VNFM as a PEP to finally execute a decision result. See fig. 9 in detail, including:

step 901, after receiving a policy operation request sent by a PLCM, a PDP creates a policy engine;

wherein, after receiving the strategy parameter and the template information sent by NFVO, PLCM creates a strategy rule file to be stored in PR, sends a strategy operation request to PDP, the strategy operation request carries the description information of the strategy rule file, after receiving the strategy operation request, PDP downloads the strategy rule file from PR according to the description information of the strategy rule file carried in the strategy operation request,

it should be noted that, in other embodiments, the PDP may also directly receive the policy parameters and the template information sent by the NFVO to create the policy rule file.

Step 902, the PDP loads a policy rule file using the policy engine, and parses the policy rule file to obtain a policy rule;

step 903, collecting the value of a virtual resource counter of the VIM by the PM to obtain a first index;

step 904, the PDP subscribes to a first index change event of the PM;

specifically, an event topic manager of the PDP subscribes to a first index change event of the PM, and receives the first index change event;

step 905, the event theme manager sends the first index change event to the policy engine module;

step 906, the policy engine module receives the first index change event and matches it with the capacity expansion rule, that is, the change of the first index triggers the capacity expansion rule in the PDP;

step 907, the policy engine module initiates a capacity expansion request to the NFVO according to the policy action in the capacity expansion rule;

step 908, after receiving the capacity expansion request, the NFVO checks the capacity expansion request;

step 909, after the verification is passed, the NFVO initiates a VNF instantiation request to the VNFM;

step 910, after receiving the VNF instantiation request, the VNFM parses a VNFD (Virtualization networking functions Descriptor) to obtain virtual resources required for deploying the VNF, and generates an expansion resource list;

911, the VNFM returns a capacity expansion resource list to the NFVO;

step 912, the NFVO sends the VNF capacity expansion resource event to the PDP, specifically, to the policy engine module of the PDP;

step 913, after receiving the VNF capacity expansion resource event, the PDP matches a resource rule;

step 914, according to the policy action in the resource rule, sending an execution capacity expansion request to the NFVO;

step 915, after receiving the execution capacity expansion request, the NFVO determines to accept the execution capacity expansion request according to the current available resource quantity, the local policy and the like, and requests the VIM to allocate resources, that is, sends a resource allocation request to the VIM;

step 916, after receiving the resource allocation request of the NFVO, the VIM creates a virtual machine;

step 917, the VIM returns the resource allocation result to the NFVO;

step 918, the NFVO sends a resource configuration completion notification to the VNFM;

step 919, configuring the VNF by the VNFM according to the template requirement, and performing application deployment and parameter configuration;

step 920, the VNFM notifies the NFVO of completion of VNF instantiation;

step 921, the NFVO sends an expansion complete event to the PDP to complete the closed loop of VNF automatic expansion.

Application instance 2 policy-based VNF Capacity reduction

A network services Auto-scaling policy (NS Auto-scaling policy) is provided by the VNF (i.e. the VNF acts as a designer) and is executed by the VNFM (i.e. the VNFM acts as a PEP). A policy designer (namely VNF) designs an automatic capacity reduction policy, binds a given type of VNF through a PLCM, encapsulates the VNF in policy information, and issues the policy information to a PDP. An example of an auto-scaling strategy might contain the following information:

if changes in certain VNF index values are detected, VNF instance reduction is performed according to a given action. Specific index values can be set according to needs, and the application does not limit the index values.

And the PDP acquires the index information from the analyzer, the index information is matched with the current capacity reduction strategy for decision, and the VNFM is used as the PEP to finally execute a decision result. With particular reference to fig. 10, comprising:

step 1001, the PDP receives a policy operation request sent by the PLCM, and creates a policy cause;

step 1002, the PDP loads a policy rule file using the policy engine, and parses the policy rule file to obtain a policy rule;

step 1003, the VNFM uses notification of a performance management interface of the VNF/VIM or obtains performance criteria operation to obtain a measurement index of a specific VNF;

step 1004, subscribing the VNF measurement index event of the VNFM by the event topic manager of the PDP, and receiving the VNF measurement index event;

step 1005, the event theme manager of the PDP sends VNF measurement index time to the policy engine;

step 1006, the policy engine module receives VNF measurement index time, matches the capacity reduction rule, and determines to execute capacity reduction;

step 1007, the PDP initiates a capacity reduction request to the NFVO;

step 1008, after receiving the capacity reduction request, the NFVO verifies the capacity reduction request;

step 1009, after the verification is passed, the NFVO sends a VNF capacity reduction request to a VNFM, where the VNF capacity reduction request carries a VNFD;

step 1010, after receiving the VNF capacity reduction request, the VNFM analyzes the VNFD, calculates resources required by releasing the VNF, and generates a resource list;

step 1011, the VNFM returns a resource list to the NFVO;

step 1012, the NFVO sends the VNF abbreviated resource event to the PDP, specifically, to the policy engine module of the PDP;

step 1013, after receiving the VNF capacity reduction resource event, the PDP matches a resource rule to determine capacity reduction;

step 1014, the PDP sends a request to execute the contraction capacity to the NFVO;

step 1015, after receiving the capacity reduction execution request, NFVO determines to accept the capacity reduction execution request according to the current available resource quantity, local policy, and the like, and changes the VNF, including adjusting network parameters and service parameters, changing a distribution mechanism, updating a VNF management list, and the like;

step 1016, NFVO requests VIM to release resources;

step 1017, the VIM releases the corresponding virtual resource (including network resource and virtual machine resource);

step 1018, the VIM returns the resource release result to the NFVO;

step 1019, the NFVO notifies the VNFM to complete resource release;

step 1020, VNFM notifies NFVO of completion of the reduction;

step 1021, the NFVO sends a capacity reduction completion event to the PDP, completing the closed loop of VNF automatic capacity reduction.

The scheme provided by the embodiment realizes automatic capacity reduction through interaction with the PDP.

Application example 3 policy-based VNF alarm self-healing

In the embodiment, VNF alarm automation is realized based on the strategy, and certain alarms are automatically analyzed and solved by setting the strategy, so that intelligent self-healing of the alarms is achieved, and operation and maintenance cost is reduced.

As shown in fig. 11, the system includes an alarm collection module 1101, an alarm root cause analysis module 1102, a machine rule learning module 1103, a policy center 1104 and an intelligent script library 1105, where the policy center 1104 includes PLCM, PDP and PR, where:

the alarm collection module 1101 is configured to collect virtual resource alarms of the VIM based on an alarm subscription request of the NFVO with the VNF as a view point, and report the virtual resource alarms to the alarm root cause analysis module 1102.

The alarm root cause analysis module 1102 is configured to associate VNF alarms, virtual resource alarms, and physical resource alarms with VNF as a view; analyzing the alarm, and sending the alarm which can be automatically repaired to a strategy center 1104; for the alarm which cannot be automatically repaired, manual processing is carried out;

the machine rule learning module 1103 is configured to give an analysis model and policy rules by machine learning and analyzing the historical alarms through big data, where the policy rules include self-healing rules; for example, the short-life cycle of the flash alarm is analyzed by analyzing the historical alarms, and the periodically occurring alarm is analyzed by analyzing the historical alarms.

The policy center 1104 is responsible for policy triggering, and when the PDP receives an alarm and the alarm matches a policy rule managed by the PDP, the action in the policy rule is triggered and executed. The action includes invoking a script library of the intelligent scripting platform 1105. The policy rules include self-healing rules derived from field customization, expert experience import, and machine rule learning modules.

After Root Cause Analysis (RCA) of the alarm, the self-healing rule of the strategy center and the script library of the intelligent script platform are called to carry out self-healing on the root alarm which can be automatically repaired, and after the self-healing is successful, the network element reports the alarm recovery, so that the intelligent self-healing of the alarm is realized, and the operation and maintenance cost is reduced.

As shown in fig. 12, an embodiment of the present invention provides a policy decision device 120, which includes a memory 121 and a processor 122, where the memory 121 stores a program, and when the program is read and executed by the processor 122, the program implements the policy decision method according to any embodiment.

As shown in fig. 13, an embodiment of the present invention provides a computer-readable storage medium 130, where the computer-readable storage medium 130 stores one or more programs 131, and the one or more programs 131 can be executed by one or more processors to implement the policy decision method according to any embodiment.

An embodiment of the present invention provides a network management system, as shown in fig. 14, including NFVO201, VNFM202, VIM203, further including: the policy decision cluster 80 according to any of the above embodiments is independent of the NFVO201, VNFM202, VIM 203.

In one embodiment, the method further comprises: PLCM301 and PR304, wherein,

the PLCM301 is configured to generate a policy rule file after receiving policy parameters and template information, store the policy rule file in a policy repository, and send a policy operation request carrying description information of the policy rule file to a policy decision unit in the policy decision cluster;

the PR304 is configured to store the policy rule file.

It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.

Claims

1. A policy decision unit comprising a policy engine module and an event topic manager, wherein:

2. The policy decision unit according to claim 1 wherein the policy engine module creating a policy engine comprises: and receiving a policy operation request sent by policy life cycle management, and creating a policy engine.

3. The policy decision unit according to claim 2, wherein said loading policy rules comprises: and acquiring a policy rule file from a policy repository according to the description information of the policy rule file carried in the policy operation request, and analyzing the policy rule file to acquire the policy rule.

4. The policy decision unit according to any one of claims 1 to 3, further comprising a cluster management module, wherein the cluster management module is configured to, when the policy decision unit is a management node of a policy decision cluster, determine whether a policy decision unit in the policy decision cluster can be used as a standby policy decision unit for other policy decision units, and, when a policy decision unit in the policy decision cluster is unavailable, use the standby policy decision unit to replace the unavailable policy decision unit.

5. The policy decision unit according to claim 4 wherein the cluster management module is further configured to periodically elect a management node that determines the policy decision cluster.

6. The policy decision unit according to claim 5 wherein said periodically electing a management node that determines a policy decision cluster comprises: and periodically electing and determining a management node of the policy decision cluster according to information in a management entity table, wherein the management entity table comprises at least one of the following: the identification, resource name, management state, available state, active/standby state, and creation and modification time information of the policy decision unit.

7. A policy decision cluster comprising at least one policy decision unit according to any of claims 1 to 6.

8. The policy decision cluster according to claim 7, wherein when a plurality of policy decision units are included in the policy decision cluster, a communication interface exists between the policy decision units.

9. A policy decision method, comprising:

10. The policy decision method according to claim 9, wherein said creating a policy engine comprises: and receiving a policy operation request sent by policy life cycle management, and creating a policy engine.

11. The policy decision method according to claim 10, wherein said loading policy rules comprises: and acquiring a policy rule file from a policy repository according to the description information of the policy rule file carried in the policy operation request, and analyzing the policy rule file to acquire the policy rule.

12. The method according to claim 9, wherein the event comprises a policy action triggered when other policy decision units match a policy rule.

13. The method according to any one of claims 9 to 12, further comprising, when the policy decision unit is a management node of a policy decision cluster, determining whether a policy decision unit in the policy decision cluster can be used as a backup policy decision unit for other policy decision units, and, when a policy decision unit in the policy decision cluster is unavailable, replacing the unavailable policy decision unit with the backup policy decision unit.

14. The method of claim 13, further comprising the policy decision unit periodically electing the management node of the policy decision cluster based on information in the shared table of management entities.

15. The policy decision method according to claim 13, wherein said management entity table comprises at least one of: the identification, resource name, management state, available state, active/standby state, and creation and modification time information of the policy decision unit.

16. A policy decision device comprising a memory and a processor, the memory storing a program which, when read and executed by the processor, implements a policy decision method according to any one of claims 9 to 15.

17. A computer readable storage medium, storing one or more programs, the one or more programs being executable by one or more processors to implement the policy decision method of any one of claims 9 to 15.

18. A network management system comprises a Network Function Virtualization (NFV) orchestrator, a virtualization network function manager and a virtualization infrastructure management, and is characterized by further comprising: the policy decision cluster of claim 7 or 8, managed independently of the NFV orchestrator, the virtualized network function manager, and the virtualization infrastructure device.

19. The network management system of claim 18, further comprising: a policy lifecycle management and policy repository, wherein,

the policy life cycle management is used for generating a policy rule file after receiving policy parameters and template information, storing the policy rule file in a policy repository, and sending a policy operation request carrying description information of the policy rule file to a policy decision unit in the policy decision cluster;

the policy repository is used for storing the policy rule file.