Design documentation
Every runtime runtime policy is defined upon a specific NS. Based on this, for each NS, a set of rules per policy can be defined. Each rule consists of the expressions part, denoting a set of conditions to be met and the actions part denoting actions upon the fulfillment of the conditions. The conditions may regard resources consumption aspects, software-specific aspects, status of a VNF or a NS, while the set of actions may regard resources allocation/disposal aspects, live migration and mobility aspects, horizontal scaling aspects and network functions management or activation aspects.
A network service may be associated with a set of runtime policies, however only one can be active during its deployment and execution time. A runtime policy can be defined by the software developer of the NS, having detailed knowledge of the business logic of the developed software, or the network operator/service platform manager having knowledge of the available resources and the set of active SLAs. Knowledge of SLAs can lead to description of set of rules guaranteeing that such SLAs can be respected in the maximum possible way.
Policies enforcement is realized through a rule-based management system. Based on the set of activated rules associated with the deployed network services and the real time collection of data, inference is realized leading to policies enforcement. Such enforcement takes place over the deployed network services, while the inference follows a continuous match-resolve-act approach. In the match phase, the set of defined conditions are examined, leading to the set of rules that have to be activated, while in the resolve phase, conflict resolution over the set of rules to be activated is taking place. The act phase concerns the triggering of the suggested actions aiming at the guidance of various orchestration components of the 5GTANGO service platform. For each rule, an inertial period is introduced denoting the time period that the same rule should not be re-triggered.
In more detail, the Policy Manager consists of (i) the working memory; facts based on the provided data, (ii) the production memory; set of defined rules, and (iii) an inference engine that supports reasoning and conflict resolution over the provided set of facts and rules as well as triggering of the appropriate actions. Data is fed to the working memory through the monitoring mechanisms that are responsible to collect data based on a set of active monitoring probes and to support a set of data management and processing operations. The production memory is also fed by policies associated with the deployed network services, as provided through the policies editor. The following figure depicts the Runtime Policies Management Framework.
During inference, triggering of actions is realized, taking into account the provided data. Such actions are tackled as suggestions that can be considered by various orchestration mechanisms for enhancing their effectiveness. These suggestions are made available in the Service Platform message broker, and thus can be dynamically consumed. Based on the adopted and successfully realized actions, policies validation is also taking place, leading to insights to network operators regarding the feasibility of the defined rules.
As detailed in 5GTango deliverable d2.2, the Runtime Policies Manager is responsible for the enforcement of such policies over an instantiated NS. Towards the design and enforcement of a runtime policy, the following workflow is followed.
- Runtime policies definition is realised through a Policies Editor by the Service Provider, taking into account - optionally - the set of defined rules already available in the NSD and VNFDs. The final set of rules is based on the selections, insertions and updates on behalf of the Service Provider, avoiding in this way any potential contradictory rules. The outcome of this process is a Policy Descriptor associated with a NS that follows a specific policy description schema.
- The created policy descriptor is validated. Actually, during the policy creation, validation mechanisms are applied within the policies editor, leading to a YAML-valid policies description.
- The validated policy descriptor is translated to Drools (rule based management system with specific syntax for rules description) that regards the engine being used for realizing real-time inference. The outcome of this process is a Drools file containing the set of expressions included in the policy.
- Upon the instantiation of a NS, the Drools file associated with the NS policy is loaded to the Policy Manager components (Production Memory) responsible for keeping track of the set of defined rules.
- Policies enforcement is realized during the overall lifecycle of the NS instance. Upon deployment of a NS, the selected policy is activated, leading to consumption of data and alerts made available in the Message Broker. Real time inference is taking place, taking into account the denoted set of rules, leading to the publication of suggested actions to the Message Broker in order to be consumed by the interested orchestration components. Upon termination of the NS instance, the associated rules are de-activated.
Following, are provided specifications with regards to the runtime policies descriptor, along with an example with the produced Drools file.
Regarding the set of metrics to be included in the conditions part, it can be associated with configuration options of each VNF (component), resources usage metrics, VNF (component) profiling information, NS metrics focusing mainly on virtual links QoS characteristics as well as overall resources usage metrics.
- Component configuration metrics are related to metrics denoted on behalf of the application developer as component specific metrics and made available through the VNF descriptor.
- Resource usage metrics regard the average/min/max consumption of resources from the deployed component image over the virtualized infrastructure.
- Component characterization metrics regard the profiling result of a component and its mapping with one or more characteristics.
- With regards to network link monitoring metrics, a set of QoS characteristics are considered, as they can be mainly provided through the monitoring infrastructure of communication service providers.
The mindmap 
depicts the main conditions categories.
With regards to the actions part of a policy definition, a set of actions are defined based on the targeted entity to apply them, namely VNFs (component) and NS. Prior to detailing the set of potential actions, it should be noted that no specific binding between conditions and actions exist, however some combinations may not be available, taking into account that there is no related business logic.
- Component actions may be associated with an orchestration functionality (e.g. spawn or deprovision a number of VMs), a change in the configuration of custom metrics of a component (e.g. change in the transcoding quality level), a change in the resource allocated to the component (e.g. migration to a different VM that may be requested upon mobility of the end user in an edge computing application scenario), etc.
- NS actions regard activation or altering of configuration of network monitoring and management mechanisms (e.g. monitoring of end-to-end delay among two connection endpoints, deployment of a network function or service, establishment of a VPN, etc.).
A NS Runtime Policy Descriptor (RPD) is a deployment template attached optionally to a NS referencing a set of enforcement rules, upon which certain actions are taken in order to meet some objectives described by specific SLAs. Policies themselves are formulated as event-condition-actions tuples with the semantics of “on event(s), if condition(s), do action(s).”
Our NS policy descriptor schema specifies the runtime policy to be enforced upon an NSD instantiation. It is based on concepts defined by state-of-the-art policy models such as SUPA, DEN-ng Policy Model, XACML and The Policy Continuum. It is, however, adapted and extended to meet the 5GTANGO specific needs.
The schema is written in YAML and can be easily translated to JSON, e.g. by using a json-to-yaml translator.
Following, we discuss the various sections of a policy descriptor. The general descriptor section contains some of the mandatory fields that have to be present in each and every policy descriptor. All other sections might be optional.
At the root level, we first have the mandatory fields, that describe and identify the policy in a unique way. descriptor_schema referenced to the corresponding schema of a descriptor (e.g., URL or local path) $schema (optional) provides a link to the schema that is used to describe the policy and can be used to validate the policy descriptor file. This is related to the original JSON schema specification.
Moreover, the policy signature, i.e the name, is of great importance as it identifies the policy uniquely.
name is the name of the policy. It can be created with any name written in lower letters and no strange symbols.
network_service is the metadata of the network_service this policy refers to. A network_service is defined in an unique way by the following fields (vendor,name,version). A network_service may have more than one policy descriptors, but a policy descriptor always refers only to one network_service.
The general descriptor section also contains optional components as outlined below.
author (optional) describes the author of the policy descriptor. description (optional) provides an arbitrary description of the policy.
A policy has to include a list with at least one policy rule. For each policy rules, the following three fields are mandatory:
name is the unique name of the policy rule. It can be created with any name written in lower letters and no strange symbols.
conditions is a set of expressions that bind with logical operators the conditions and thresholds that should be satisfied in order to trigger the actions list. It is detailed at the Conditions section.
actions is a set of actions that can be enforced upon the satisfaction of the Conditions section. It is detailed at the Actions section.
Each policy rule also contains optional components as outlined below.
salience (optional) Each rule has an integer priority attribute which defaults to zero and can be negative or positive. Salience is a form of priority where rules with higher priority values are given higher priority when ordered in the Activation queue of the inference engine.
inertia (optional) indicates the period of time (minutes, hours, days) the policy rule stays inactive after being triggered.
duration (optional) and aggregation (optional) indicate the specific time window and aggregation function (min,max,average). Sliding time windows allow the enablement of rules that will only match events occurring in the last X time units.
The conditions section contains all the information regarding the events and thresholds that should be satisfied in order to trigger the actions list. The section is mandatory and starts with:
condition represents the logical operator to join with the rule conditions presented by the field "rules".
rules can be a list of expressions as defined at expression section OR can have the form of a nested recursive conditions, e.g. contain a condition and rules fields.
The expression section contains all the information regarding how a threshold can be matched to a specific event. The section is mandatory and contains the following fields:
id the id of the event. field the field as shown to the policy editor. type the type of the event value. This can be string, double or integer. operator the operator of the threshold. This is defined at the operator enumeration and for the time being can be equal, less or greater. value the value of the threshold.
The actions section contains all the information regarding the actions that can be enforced upon the satisfaction of the conditions section. The section is mandatory and starts with: actions contains all the actions that can be enforced by the various orchestration 5GTANGO mechanisms. This section has to have at least one item with the following information:
action_type represents the type of the action. Action types come from a declared enumeration. For the time being, the following types are supported: Infrastructure, Orchestration, LifecycleManagement, NetworkMechanism, AlterConfiguration, Profile & Log.
name represents the name of the action. Action names are also an enumeration and depend on the action types. For example, the LifecycleManagement type can get the name of start, stop or restart. target refers to the NS / VNF / VDU instace where the action is going to be enforced.
Each action also contains optional components as outlined below.
stability_period indicates the period of time (minutes, hours, days) this action should not be enforced again upon being triggered.
A policy descriptor example can be found at here here